Right, and that's what happens today, the JS for the secondary functionality is loaded on demand.
Here's what I have in my FB homepage during a random load:
- Search bar for searching people/groups/posts/pages
- News ticker
- Friend requests, Notifications
- Sidebar ads
- A rich text editor for sharing my status
- A newsfeed story with a special "memory - 3years ago" feature
- Comments & commenting UI under newsfeed stories
- Suggestions for "People You May know"
- A video auto-playing a clip from a friend, with capability to auto-select between tracks of different video quality based on bandwidth (including bandwidth estimator code)
- And probably a dozen different A/B experiments that I'm a part of
It takes a lot of code just to render all these UI elements. If I interact with any of them, additional code is loaded (you can see this in the Network monitor).
This homescreen UI is as rich as any desktop application and requires no less code to render. The problem being addressed in this proposal is that a native version of this app would start a lot faster than the web version. And that's because a browser will parse all the code files loaded on startup in an app (inefficiently, by necessity), but a native app will only read the code for the code paths that are actually executed.
Basically, O(code executed) is a lot better than O(all files containing code that is executed). And this proposal features a more parser-friendly encoding and change to the parsing semantics.
Here's what I have in my FB homepage during a random load:
It takes a lot of code just to render all these UI elements. If I interact with any of them, additional code is loaded (you can see this in the Network monitor).This homescreen UI is as rich as any desktop application and requires no less code to render. The problem being addressed in this proposal is that a native version of this app would start a lot faster than the web version. And that's because a browser will parse all the code files loaded on startup in an app (inefficiently, by necessity), but a native app will only read the code for the code paths that are actually executed.
Basically, O(code executed) is a lot better than O(all files containing code that is executed). And this proposal features a more parser-friendly encoding and change to the parsing semantics.