2 ms·
As you probably know, building a sophisticated application can easily become quite complex. This is the case even if the application is designed to look non-sop
by Yoric 9y ago
As you probably know, building a sophisticated application can easily become quite complex. This is the case even if the application is designed to look non-sophisticated, as Twitter or Facebook, for instance. Now, when we are discussing desktop applications or mobile applications, people typically do not care all that much about the codesize, because it is essentially invisible to the user. For instance, who cares that the Steam binary (just the binary, without resources or dynamic dependencies) weighs 3.1Mb or that the Gimp binary (again, without resources or dynamic dependencies) weighs ~9Mb or that the Telegram binary weighs ~11Mb?
On the web, of course, since the application is downloaded dynamically, rather than being installed, people don't expect to wait and they start noticing. In some cases, web developers can fine tune their JS to make sure that less of it is shipped. Very quickly, however, this becomes horribly expensive, because it's a complicated problem with any language and JS is really not suited to static analysis and static code optimizations.
Of course, another part of the problem is that the delivery format of JS (i.e. the source code) is optimized for small files. For larger files, we can do much better. This is the objective of this project.
- deleted 9y ago[deleted]
- codedokode 9y ago> or that the Telegram binary weighs ~11Mb? The memory footprint of a native and JS app is very different. While 11Mb Windows app won't require more than 11Mb of memory for the code, JS 11Mb app might require some 50-100 Mb of memory only for keeping the code, different caches and internal structures.
- Yoric 9y agoI'm more than happy to discuss memory footprints, but since this proposal is about parsing speed and file size, that might be a little off-topic :)