4 ms·

A bit of history revisionism, haha ExtJS, Ember, Angular, and Next are all "full-stack" frameworks and the all were released at very different times. I would

by k__ 5y ago

A bit of history revisionism, haha ExtJS, Ember, Angular, and Next are all "full-stack" frameworks and the all were released at very different times. I would say the "eras" were more like: Direct manipilation with custom architecture and models (JQuery) -> MVC/P (Ember/ExtJS/Angular) -> Components (React/Vue).

magnio 5y ago
That's how the article delineates it too. The term "Full-stack Frameworks" for the fourth era is a bit confusing: what the article means is the battery-included wrappers for popular component libraries like Next.js, Remix (React) or Nuxt.js (Vue) and not just any full-stack framework per se.
deleted 5y ago
[deleted]
Tade0 5y ago
+the next generation: "compiler-frameworks"(or "UI compilers"). Overall this division seems weird. SSR is neither a revolution, nor universally desirable. The real revolution is in what these next-generation frameworks like Svelte or SolidJS offer: small bundles combined with high performance achieved through eschewing virtual DOM in favour of precise changes in the DOM.
- josephg 5y ago
  Yep. SSR has been around for ages. The very first "web frameworks" were pure SSR. And by that I'm referring to PHP and the old CGI! The big leap forward from Solidjs and Svelte is that they do complex source-to-source compilation to avoid virtual dom diffing. That approach lets them get the best of both worlds - the programmer can pretend their components are pure & reactive. (Solidjs looks almost identical to react.) Thats great because it means there's no bugs due to fiddly or forgotten DOM updating. But the javascript executed by the browser doesn't need any of react's complexity. The JS output by the compiler simply makes direct DOM manipulation calls when content changes. There's no heavy re-rendering of view trees, and no virtual dom to track. Unlike react, you don't need to apologize for mutating variables or re-render your entire page when you do. So we can do away with redux and all of that. A hello world app in solid or svelte is a few kilobytes, compared to 200kb+ for a react project. And it renders instantly. It took us a few years to get here, but I'm delighted by the direction UI code in the browser is headed. I hope these ideas make it into native applications.
  - Tade0 5y ago
    Also let's not forget about something that hasn't been the case over a decade now: the stack is readable again. I've found bugs in my Svelte code just by looking at the stack.
  - fabiospampinato 5y ago
    Actually that's just a common misconception, which I believed too. The complex compile-time transforms enable almost no performance improvements. As a proof just take a look at the js-framework-benchmark table [0], my framework (Voby [1]) is faster than both in the benchmark despite having an API very similar to Solid and no requirement for a Babel transform or other compile-time transform (though the basic React-like JSX transform is supported for convenience). Those transforms actually exist 99% just for providing some convenience features to the developer. If that weren't the case it wouldn't be possible to make something similar without a transform that's faster than both. In fact Svelte is actually quite a bit slower than both Voby and Solid. Svelte is even slower than Inferno, which is a (very optimized) V-DOM framework. [0]: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... [1]: https://github.com/fabiospampinato/voby/ https://github.com/fabiospampinato/voby/
    - woojoo666 5y ago
      It seems like a lot of these benchmarks are manipulating rows in a table? Are there any benchmarks that involve complex component trees with a lot of nesting? Very cool framework though, I'll have to look more into how it works someday
      - fabiospampinato 5y ago
        I'm not sure. But FWIW I don't think more complex nesting would change anything in this regard. Those transforms essentially just avoid you having to wrap some things in functions manually, and avoid some extra function calls. Avoiding manual wrapping is a convenience feature and those extra function calls are not really that expensive (or it wouldn't be possible for Voby to be faster than something optimized like Solid in the benchmark). If you'd like to come up with a different sort of benchmark where you think Solid would shine I'd be happy to write an implementation of it with Voby and see what happens. Or you can just try that yourself, the API is fairly similar. --- I should probably add that js-framework-benchmark is heavily biased toward measuring creation time actually, which is something where compile-time optimizations should shine. If you are more interested in updating things, like you would be in a rich application, Voby is actually some 20% faster than Solid at replacing rows with other rows, because it support reusing of older nodes (opt-in) (this also lowers memory pressure in some cases by the way, no need to make and gc lots of stuff in some cases). This optimization is not supported in Solid nor Svelte, and interestingly it's not a safe optimization that can be applied all the time, so it must be opt-in, but how are you supposed to tell to Solid or Svelte when it's safe to apply it if something like Voby's "template" function, which is also used for this, is abstracted away entirely from you? In some sense the transform actively goes against performance here.
pzuraq 5y ago
By "full-stack" here I mean frameworks which handle both the frontend and backend simultaneously, in a seamless way. The closest thing framework that I remember from the MVC/P era which attempted this was Meteor.js, but it was really horrendous to use in my experience. Otherwise, it was very common practice to serve an Ember or Angular app as static files Nginx or directly on a CDN. Wrapping them in a server-side framework was always a bespoke process which required you to effectively maintain two frameworks, and stitch them together yourself (unless you count Ember + Rails in the early days, but even that is a stretch IMO). When SSR was introduced in any framework, it was usually not used to its full potential to be able to accomplish the use cases I discuss in the post, like authentication, API endpoints, etc. It was just used to render the app on the server. It did not fundamentally change the DX of the framework. I honestly was pretty skeptical of these latest frameworks until I gave them a shot! It doesn't sound that revolutionary until you actually start using them, and things which were previously quite difficult become absolutely trivial. I highly recommend trying them out some time.
mrits 5y ago
I'd say JQuery and ExJS were part of the same era. JQuery was used by a lot of people that didn't embrace javascript at all and tried to not use it (e.g ASP.NET coders) I feel like backbone deserves its own era as it seemed like all the cool kids would exclusively use that for a couple years. Then Angular and a ton of others flooded the scene.

by k__ 5y ago

magnio 5y ago

That's how the article delineates it too. The term "Full-stack Frameworks" for the fourth era is a bit confusing: what the article means is the battery-included wrappers for popular component libraries like Next.js, Remix (React) or Nuxt.js (Vue) and not just any full-stack framework per se.

deleted 5y ago

[deleted]

Tade0 5y ago

+the next generation: "compiler-frameworks"(or "UI compilers"). Overall this division seems weird. SSR is neither a revolution, nor universally desirable. The real revolution is in what these next-generation frameworks like Svelte or SolidJS offer: small bundles combined with high performance achieved through eschewing virtual DOM in favour of precise changes in the DOM.

josephg 5y ago
Yep. SSR has been around for ages. The very first "web frameworks" were pure SSR. And by that I'm referring to PHP and the old CGI! The big leap forward from Solidjs and Svelte is that they do complex source-to-source compilation to avoid virtual dom diffing. That approach lets them get the best of both worlds - the programmer can pretend their components are pure & reactive. (Solidjs looks almost identical to react.) Thats great because it means there's no bugs due to fiddly or forgotten DOM updating. But the javascript executed by the browser doesn't need any of react's complexity. The JS output by the compiler simply makes direct DOM manipulation calls when content changes. There's no heavy re-rendering of view trees, and no virtual dom to track. Unlike react, you don't need to apologize for mutating variables or re-render your entire page when you do. So we can do away with redux and all of that. A hello world app in solid or svelte is a few kilobytes, compared to 200kb+ for a react project. And it renders instantly. It took us a few years to get here, but I'm delighted by the direction UI code in the browser is headed. I hope these ideas make it into native applications.
- Tade0 5y ago
  Also let's not forget about something that hasn't been the case over a decade now: the stack is readable again. I've found bugs in my Svelte code just by looking at the stack.
- fabiospampinato 5y ago
  Actually that's just a common misconception, which I believed too. The complex compile-time transforms enable almost no performance improvements. As a proof just take a look at the js-framework-benchmark table [0], my framework (Voby [1]) is faster than both in the benchmark despite having an API very similar to Solid and no requirement for a Babel transform or other compile-time transform (though the basic React-like JSX transform is supported for convenience). Those transforms actually exist 99% just for providing some convenience features to the developer. If that weren't the case it wouldn't be possible to make something similar without a transform that's faster than both. In fact Svelte is actually quite a bit slower than both Voby and Solid. Svelte is even slower than Inferno, which is a (very optimized) V-DOM framework. [0]: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... [1]: https://github.com/fabiospampinato/voby/ https://github.com/fabiospampinato/voby/
  - woojoo666 5y ago
    It seems like a lot of these benchmarks are manipulating rows in a table? Are there any benchmarks that involve complex component trees with a lot of nesting? Very cool framework though, I'll have to look more into how it works someday
    - fabiospampinato 5y ago
      I'm not sure. But FWIW I don't think more complex nesting would change anything in this regard. Those transforms essentially just avoid you having to wrap some things in functions manually, and avoid some extra function calls. Avoiding manual wrapping is a convenience feature and those extra function calls are not really that expensive (or it wouldn't be possible for Voby to be faster than something optimized like Solid in the benchmark). If you'd like to come up with a different sort of benchmark where you think Solid would shine I'd be happy to write an implementation of it with Voby and see what happens. Or you can just try that yourself, the API is fairly similar. --- I should probably add that js-framework-benchmark is heavily biased toward measuring creation time actually, which is something where compile-time optimizations should shine. If you are more interested in updating things, like you would be in a rich application, Voby is actually some 20% faster than Solid at replacing rows with other rows, because it support reusing of older nodes (opt-in) (this also lowers memory pressure in some cases by the way, no need to make and gc lots of stuff in some cases). This optimization is not supported in Solid nor Svelte, and interestingly it's not a safe optimization that can be applied all the time, so it must be opt-in, but how are you supposed to tell to Solid or Svelte when it's safe to apply it if something like Voby's "template" function, which is also used for this, is abstracted away entirely from you? In some sense the transform actively goes against performance here.

pzuraq 5y ago

By "full-stack" here I mean frameworks which handle both the frontend and backend simultaneously, in a seamless way. The closest thing framework that I remember from the MVC/P era which attempted this was Meteor.js, but it was really horrendous to use in my experience. Otherwise, it was very common practice to serve an Ember or Angular app as static files Nginx or directly on a CDN. Wrapping them in a server-side framework was always a bespoke process which required you to effectively maintain two frameworks, and stitch them together yourself (unless you count Ember + Rails in the early days, but even that is a stretch IMO). When SSR was introduced in any framework, it was usually not used to its full potential to be able to accomplish the use cases I discuss in the post, like authentication, API endpoints, etc. It was just used to render the app on the server. It did not fundamentally change the DX of the framework. I honestly was pretty skeptical of these latest frameworks until I gave them a shot! It doesn't sound that revolutionary until you actually start using them, and things which were previously quite difficult become absolutely trivial. I highly recommend trying them out some time.

mrits 5y ago

I'd say JQuery and ExJS were part of the same era. JQuery was used by a lot of people that didn't embrace javascript at all and tried to not use it (e.g ASP.NET coders) I feel like backbone deserves its own era as it seemed like all the cool kids would exclusively use that for a couple years. Then Angular and a ton of others flooded the scene.