For those questioning why the data is stored as a javascript file (as opposed to json): it seems the final target is to include the data as a script tag inside your website. This is also very useful for static site generators.
The problem with json is that you can’t include it in the page using the <script> tag (i.e., can’t do <script>type="application/json" src='foo.json'></script>), you have to either embed the object itself inside a script tag (bloating the file, and requiring a preprocessing step), fetch the document using json (requires a server), or craft a javascript file that exports your document as a variable. If you have to craft a javascript file anyway, it seems useful to combine the data and the module so you can use it directly.
Its not clear to me why this is a good idea. I‘m not very familiar with JavaScript databases, but what are the actual benefits of this?
For those questioning why the data is stored as a javascript file (as opposed to json): it seems the final target is to include the data as a
script
tag inside your website. This is also very useful for static site generators.The problem with json is that you can’t include it in the page using the
<script>
tag (i.e., can’t do<script>type="application/json" src='foo.json'></script>
), you have to either embed the object itself inside a script tag (bloating the file, and requiring a preprocessing step), fetch the document using json (requires a server), or craft a javascript file that exports your document as a variable. If you have to craft a javascript file anyway, it seems useful to combine the data and the module so you can use it directly.Looks interesting and easy to use. But the data-serialized-as-code bits seems really odd and would make me shy away.