3 ms·
It's all about resource efficiency. If you do that (bundle), you're not resource efficient (memory), but the resulting solution is easy to use (no dealing with
by skratlo 10y ago
It's all about resource efficiency. If you do that (bundle), you're not resource efficient (memory), but the resulting solution is easy to use (no dealing with dependency conflicts where A depends on X-v1 and B on X-v2, and you need A and B running in the same system). How important is resource efficiency, and what it even means today vs. yesterday varies wildly.
- zwetan 10y agoI experienced different results. One of the main problem with JS engines is that they load external code on demand, even with something like JSDB (see [1] based on SpiderMonkey engine) where you can bundle all of your JS inside a zip that you then bundle/merge with the runtime, the JS files still have to be extracted from the zip and loaded "as file" from memory. In the case of the AVM2, wether the files are AS3 or JS they are first compiled to bytecode (like Java) and that's what you bundle with the runtime, the bytecode still have to be loaded but it is "one big file", so wether your sources are many 100s of JS files it does not matter. That matter a lot for the resource efficiency, and it influence a lot the memory footprint (~10MB for AVM2, ~50MB for a Node.js, see [2]), eg. the more files you load the more memory you gonna use. For the dependencies conflict yep it make things easier too, not only for the versioning of libraries as you describe but also for the versioning of the runtime itself, eg. runtime v2 could be installed system wide but your self-contained exe could use an older runtime v1. [1]: http://www.jsdb.org http://www.jsdb.org [2]: https://github.com/eclipse/kura/wiki/Footprint https://github.com/eclipse/kura/wiki/Footprint