This is a good development. Honestly one thing I very much think is a downside about React is the fact that your template is also JavaScript. Don't get me wrong this is incredibly powerful and can be very expressive, but it comes at a cost.
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:
> a downside about React is the fact that your template is also JavaScript
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.
What is it you don't get? The parent post clearly states why this can have performance costs. Other modern frameworks like e.g. Svelte solves rendering without making templates JS.
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.
Sticking to the past? You talk as if JSX is the final solution in dev productivity, after which nothing else is even worthy of consideration. JSX has pros and cons, as does e.g. Vue's and Svelte's templating approaches. Something even better will surely appear, or already has.
All good points. Haven't read the code so I don't know how deep the similarity goes but the new React Concurrent UI Patterns is at a surface level conceptually similar to Ember's interruptible route transitions, though more fine-grained.
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.
What I really like about JSX is when you use it with TypeScript, you get type checking in your view layer all the way to the "top". When switching back to things like MVC Razor or Angular that have a separate template, I often hit bugs that a type system would have prevented.
It's true that React can't pause in the middle of any individual component's render function, but when there are many components being rendered, React is able to pause and interrupt rendering between different component instances' render functions.
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/