Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> without the traditional UI affordances (spinners etc) to indicate that the application was waiting on the network.

This part is obviously trivially solvable. I think the same basic idea is going to at some point make it but it’ll have to be through explicit annotations first and then there will be tooling to automatically do this for your code based upon historical visits where you get to tune the % of visitors that get additional fetches. Also, you could probably fetch the split off script in the background anyway as a prefetch + download everything rather than just 1 function at a time (or even downloading related groups of functions together)

The idea has lots of merit and you just have to execute it right.



I agree with most of your comment, but don't get what you mean about explicit annotations.

Note that most of the unused code is located in libraries, not in the app code directly.


split async function handle_button_press() { … }

This would cause the bundler to inject a split point & know how to hide that + know what needs bundling and what doesn’t. GWT pioneered almost 20 years ago although not a fan of the syntax they invented to keep everything running within stock Java syntax: https://www.gwtproject.org/doc/latest/DevGuideCodeSplitting....


Why do you want them explicit in the code?

The tooling producing such annotaion based on historical visits whould constantly change the annotated set of functions, I suspect, whith app versions evolving.

Note, the inactive code parts are very often in 3rd party libraries.

Some are also in your own libraries shared between your different application. So the same shared library whould need one set of split-annotated functions for one app, and another set for another app. So these conflicting sets of annotations can not live in the library source code simultaneously.


For example the automated system could take your non-split codebase & inject splits at any async function & self-optimize as needed. The manual annotation support would be to get the ecosystem going as an initial step because I suspect targeting auto-optimizing right from the get go may be too big a pill to swallow.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: