Most languages aren't built with asynchronous behavior in mind. But the nature of the web is that everything is asynchronous: user actions, CRUD operations, image/script/css/asset retrieval. All of it.
The advantage of single threaded behavior is in the challenge such a limitation presents. Why do ES6/ES7 bring the
async/await specs? Because these are needs and APIs that JS developers battle tested while trying to maintain non-blocking IO. How did the runLoop in
node turn into such a big deal? Because it showed that non-blocking IO on a single thread could far outperform a thread based solution when scaling requests.
Could your app use the efficiency boost of being able to strictly cast some vars? We'll get that eventually. Strict classes? We'll get that too. JS runtimes have already made JS an extremely fast language, it won't take the language evolving much to close the 17% gap between optimized JS and optimized C++.
Need threads? Try WebWorkers or Shared WebWorkers. Need threaded rendering?
Yeah, I just said that. I'll say it again. Need threaded rendering?
What if we treat the main thread as just the ui-assembly-thread, nothing more? Want a snappy application with super fast route rendering? Choose the ideal spot, swap out. Fast internet connection? Reach out to the server. Nothing going on on the main thread? Render there. Where exactly could/will this go?
- if WebWorkers are given the ability to create a
- if Ember or React's
fastbootservers are embedded within your Cordova application
Imagine the possibilities. You have a complex and demanding interface. Possibly you've used
react-canvas or a customized webView or similar to improve your rendering (don't worry, better solutions ARE coming). Regardless of final rendering environment, your one thread has a lot to handle. What if it just assembled?
Your route hits a Shared WebWorker which delegates various components on the page to be rendered by other threads, each with then transfers a completed
documentFragment to the
ui-assembly-thread for DOM insertion. This could end the
native vs. HTML5 debate. Native is HTML5 is native.