4 ms·

+the next generation: "compiler-frameworks"(or "UI compilers"). Overall this division seems weird. SSR is neither a revolution, nor universally desirable. The

by 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.
      - kaba0 5y ago
        I am absolutely not well-versed in JS framework internals, but isn’t this reuse the difference between Solid’s <For> vs <Index>?
        5y ago

by Tade0 5y ago

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.
    - kaba0 5y ago
      I am absolutely not well-versed in JS framework internals, but isn’t this reuse the difference between Solid’s <For> vs <Index>?
      - 5y ago