Everytime I read this (and it still seems to happens in 2019) I just don't get it--I don't get why people want to stick to the past. It's the best thing which could happen, everything is JS, FE development finally got bearable, no, enjoyable! It freed us from all the subpar patterns before.
They are overstated. You are not building Photoshop in the browser 99% of the time. Dev productivity should have a higher prio => everything in JS and nobody needs some FE VM with bytecode (wtf, I mean when we already talk about Ember, Ember interfaces are not really the fastest one despite having their own small VM).
This is what I don't get, sticking to the past and requiring stuff which doesn't make sense.
Also really like the new <Suspense> Component! I created a {{render-on-resolve promise=foo}} Component for the app I worked on in Ember back in 2016, and we got a ton of use out of it. If you set up your data layer right, and use it well, it completely removes the need to ever manually manage a loading spinner again.
That cost has the same cost as other JavaScript - it's blocking, cannot be paused and has all the possibilities of de-optimizations that might occur in the JIT. The Ember team faced a similar problem in the past and I find their solution to this problem quite intriguing, even in it's obscurity. Instead of compiling their templates to JavaScript they instead compile them to opcodes in a binary format which is executed by a virtual machine.
This has several advantages. Since the template file is represented as an optimized binary the size of the file itself is incredibly small, excellent since templates can be a large part of your eventual code. Not only that but since the instructions are opcodes, this mean the VM can pause at a moment when the browser is too busy with other stuff.
Since a large part of your templates is probably static and not prone to any changes the template file also indicates which parts of the instructions are dynamic and which are static. This allows the VM to generate a separate set of instructions just for subsequent updates, only updating those parts which are dynamic.
Now I am not saying this is a silver bullet, it is however an interesting and fresh approach. In case you're interested in this check out the Glimmer site or Tom Dale's excellent talk (can't recommend this enough) on the subject:
- Tom Dale's talk: https://www.youtube.com/watch?v=nXCSloXZ-wc - The Glimmer JS site: https://glimmerjs.com/