5 ms·

Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast. Definitely fast enough for 99% o

by harel 4y ago

Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast. Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base components are done. I'm sure another person will say "I use Svelte because A, B and C". etc.

metadaemon 4y ago
I agree. Getting kind of sick of these posts that are thinly veiled political campaigns against the other framework. Great libraries tend to speak for themselves in terms of adoption. You shouldn't have to convince people not to use other options.
- ralmidani 4y ago
  It’s not always bashing other frameworks gratuitously; an important aspect of human progress is recognizing what works well, what works less well, and what seemed like a good idea at the time but either became obsolete or was a bad idea to begin with. JSX and VDOM were at one time necessary (or at least helpful), but Web Components and Tagged Template Literals can do everything React does, only better and with less overhead (in both the developer’s mind as well as the computer’s runtime). I say that as someone who learned and taught bootcamps with React, and has yet to dive too deeply into lit-html and LitElement.
lordgroff 4y ago
100% There's a vanishingly small number of applications where it's really going to make a difference. Use what your work uses, or if personal project what you like. The more I use React and co. the more I feel like it's all the same thing.
- commandlinefan 4y ago
  > There's a vanishingly small number of applications where it's really going to make a difference Developers (and especially deadline-conscious managers) keep saying this, but their web sites keep slowing down my computer to a crawl. As a consumer, I really wish that development teams paid at least some attention to performance.
  - npteljes 4y ago
    The truth is, performance doesn't bring in the dollars, features do, and marketing, and sales. The incentives are just not there, and these issues what we're having, show that.
afavour 4y ago
> They are all fast I would say they all can be fast. But try browsing the web on a low end Android device and tell me all sites are fast. To my mind the differentiator is how easy a framework makes it to shoot yourself in the foot. And React makes it very easy to re-render a huge swathe of your app when you've only changed one tiny element. React also needs to hydrate every element even when it isn't ever going to change, which usually involves parsing some JSON payload for props on page load. None of this is world-ending stuff. But it is very easy to keep putting wonderful, carefully crafted components together and not realise the entirety of what you've made is getting slower and slower over time.
- TurningCanadian 4y ago
  > React also needs to hydrate every element even when it isn't ever going to change That is no longer true with Server Components https://beta.nextjs.org/docs/rendering/server-and-client-components#server-components https://beta.nextjs.org/docs/rendering/server-and-client-com...
  - afavour 4y ago
    ...which are a whole damn thing. Don't get me wrong I'm glad the React team is tackling the problem but it's telling that the answer requires an entire server side solution when other JS frameworks are able to solve this in the client or at build time. And just looking at those docs screams "patching over a fundamental issue" to me.
  - ghusbands 4y ago
    You lose all client-side performance benefits if the components are only on the server. Ideally, you would improve the performance of hydration or only hydrate when necessary.
- PaulHoule 4y ago
  There are problems that have to do with the systems built on top of React if not React itself. It is not unusual at all to find some "simple" UI update causes the render() method to be called 20 times. You might blame the application developer for this but other than "keep all the state at the top level of the application and pass it down in props", React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways. There are a number of half-baked libraries such as Redux, MobX that maybe help some of the time but frequently make very simple application logic very complicated to write. When I started writing high-complexity SPAs circa 2005 or so I realized right away that you had to be very systematic about what happened when an AJAX call returned and where the data goes, something the industry still hasn't entirely learned. It is possible to make React applications work right but I think people work harder at it than they have to and there is a lot of reciting shibboleths that people don't understand (hooks for one thing) and the cost of it is the render function getting called over and over and over again. But maybe it is not a bug but a feature for the advertising supported web where every rerender and layout shift creates a chance you'll accidentally click on an an ad when you are trying to click on something else. Most studies seem to show that psychologically normal people of normal intelligence in possession of their faculties never choose to click on ads and maybe Google's whole business is driven by accidental clicks caused by layout shifts and doing something about those layout shifts would put them out of business.
napkin 4y ago
Saying they're fast is a relative statement. I primarily use an MNT Reform. On 4x ARM Cortex-A53 cores, most modern web apps are slow (the new reddit interface, the new gmail, virtually every airline booking UI, my music player of choice, etc.). I hate the web.
- wruza 4y ago
  Do you believe that these sites would be fast if built with other non-SPA or non-“modern” libraries? It’s like thinking that a faster car or a bicycle could be faster in a city with bad traffic light logistics. All of Svelte, React, Vue, jQuery, DOM are equally visibly fast until you attach these 10 megabytes of /metrics-n-spyware/**/*.js.
- mmis1000 4y ago
  Reddit is just written s**tty. It is the worst case you can use to recommend react to peoples. Their desktop version is even worse. It eats a whole core of r7 2700x for 1 seconds just to update vote counters on page. https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesign_has_very_high_cpu_usage_during/ https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig... Although I also think it is fault of react partially. React don't really have a proper guideline about how to not write page like this.
commandlinefan 4y ago
> They are all fast When you say "fast" - I assume you mean runtime speed, not time to market/developer speed? Because FTA (quoting Pete Hunt in regard to React itself): > Just like you can drop into assembler with C and beat the C compiler, you can drop into raw DOM operations and DOM API calls and beat React if you wanted to Even the React people acknowledge that just working with plain-old Javascript is going to beat React (or Svelte, or X, Y, Z) is going to perform better at run time, they're just offering to speed up the development cycle - always with the tradeoff of runtime performance.
jcelerier 4y ago
> Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast. we don't live in the same universe. even with powerful computers, browsing any friggin modern website is an exercice in pain and frustration, everything, literally every interaction is slow when you compare to the average desktop app
- Closi 4y ago
  Agree, and I think this is the point of the article too. If we are going to say things like "React is fast" then it needs a further clarification - fast compared to what? Are we comparing it to C, jQuery, Angular, Pure Javascript, or a Commedore 64? Because it doesn't make sense to say it is fast if there isn't something to compare it against. (In reality, I suspect it is only really "fast" if you compare it with something slow).
- harel 4y ago
  If a developer coded a slow app in react they will code a slow app in svelte. We need to stop blaming the language.
deleted 4y ago
[deleted]
mmis1000 4y ago
React is fast in the sense it eat tons of computation power without lagging the ui. In my opinion, this is a dead end. They should really try to reduce the actual computation power required to render the ui. The growing rate of cpu speed is stalled. There already isn't too much room for it. And what about user with a low end Android machine? Not lagging the ui isn't helpful here. Because it still need seconds to render the whole thing.

by harel 4y ago

metadaemon 4y ago

I agree. Getting kind of sick of these posts that are thinly veiled political campaigns against the other framework. Great libraries tend to speak for themselves in terms of adoption. You shouldn't have to convince people not to use other options.

ralmidani 4y ago
It’s not always bashing other frameworks gratuitously; an important aspect of human progress is recognizing what works well, what works less well, and what seemed like a good idea at the time but either became obsolete or was a bad idea to begin with. JSX and VDOM were at one time necessary (or at least helpful), but Web Components and Tagged Template Literals can do everything React does, only better and with less overhead (in both the developer’s mind as well as the computer’s runtime). I say that as someone who learned and taught bootcamps with React, and has yet to dive too deeply into lit-html and LitElement.

lordgroff 4y ago

100% There's a vanishingly small number of applications where it's really going to make a difference. Use what your work uses, or if personal project what you like. The more I use React and co. the more I feel like it's all the same thing.

commandlinefan 4y ago
> There's a vanishingly small number of applications where it's really going to make a difference Developers (and especially deadline-conscious managers) keep saying this, but their web sites keep slowing down my computer to a crawl. As a consumer, I really wish that development teams paid at least some attention to performance.
- npteljes 4y ago
  The truth is, performance doesn't bring in the dollars, features do, and marketing, and sales. The incentives are just not there, and these issues what we're having, show that.

afavour 4y ago

> They are all fast I would say they all can be fast. But try browsing the web on a low end Android device and tell me all sites are fast. To my mind the differentiator is how easy a framework makes it to shoot yourself in the foot. And React makes it very easy to re-render a huge swathe of your app when you've only changed one tiny element. React also needs to hydrate every element even when it isn't ever going to change, which usually involves parsing some JSON payload for props on page load. None of this is world-ending stuff. But it is very easy to keep putting wonderful, carefully crafted components together and not realise the entirety of what you've made is getting slower and slower over time.

TurningCanadian 4y ago
> React also needs to hydrate every element even when it isn't ever going to change That is no longer true with Server Components https://beta.nextjs.org/docs/rendering/server-and-client-components#server-components https://beta.nextjs.org/docs/rendering/server-and-client-com...
- afavour 4y ago
  ...which are a whole damn thing. Don't get me wrong I'm glad the React team is tackling the problem but it's telling that the answer requires an entire server side solution when other JS frameworks are able to solve this in the client or at build time. And just looking at those docs screams "patching over a fundamental issue" to me.
- ghusbands 4y ago
  You lose all client-side performance benefits if the components are only on the server. Ideally, you would improve the performance of hydration or only hydrate when necessary.
PaulHoule 4y ago
There are problems that have to do with the systems built on top of React if not React itself. It is not unusual at all to find some "simple" UI update causes the render() method to be called 20 times. You might blame the application developer for this but other than "keep all the state at the top level of the application and pass it down in props", React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways. There are a number of half-baked libraries such as Redux, MobX that maybe help some of the time but frequently make very simple application logic very complicated to write. When I started writing high-complexity SPAs circa 2005 or so I realized right away that you had to be very systematic about what happened when an AJAX call returned and where the data goes, something the industry still hasn't entirely learned. It is possible to make React applications work right but I think people work harder at it than they have to and there is a lot of reciting shibboleths that people don't understand (hooks for one thing) and the cost of it is the render function getting called over and over and over again. But maybe it is not a bug but a feature for the advertising supported web where every rerender and layout shift creates a chance you'll accidentally click on an an ad when you are trying to click on something else. Most studies seem to show that psychologically normal people of normal intelligence in possession of their faculties never choose to click on ads and maybe Google's whole business is driven by accidental clicks caused by layout shifts and doing something about those layout shifts would put them out of business.

napkin 4y ago

Saying they're fast is a relative statement. I primarily use an MNT Reform. On 4x ARM Cortex-A53 cores, most modern web apps are slow (the new reddit interface, the new gmail, virtually every airline booking UI, my music player of choice, etc.). I hate the web.

wruza 4y ago
Do you believe that these sites would be fast if built with other non-SPA or non-“modern” libraries? It’s like thinking that a faster car or a bicycle could be faster in a city with bad traffic light logistics. All of Svelte, React, Vue, jQuery, DOM are equally visibly fast until you attach these 10 megabytes of /metrics-n-spyware/**/*.js.
mmis1000 4y ago
Reddit is just written s**tty. It is the worst case you can use to recommend react to peoples. Their desktop version is even worse. It eats a whole core of r7 2700x for 1 seconds just to update vote counters on page. https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesign_has_very_high_cpu_usage_during/ https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig... Although I also think it is fault of react partially. React don't really have a proper guideline about how to not write page like this.

commandlinefan 4y ago

> They are all fast When you say "fast" - I assume you mean runtime speed, not time to market/developer speed? Because FTA (quoting Pete Hunt in regard to React itself): > Just like you can drop into assembler with C and beat the C compiler, you can drop into raw DOM operations and DOM API calls and beat React if you wanted to Even the React people acknowledge that just working with plain-old Javascript is going to beat React (or Svelte, or X, Y, Z) is going to perform better at run time, they're just offering to speed up the development cycle - always with the tradeoff of runtime performance.

jcelerier 4y ago

> Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast. we don't live in the same universe. even with powerful computers, browsing any friggin modern website is an exercice in pain and frustration, everything, literally every interaction is slow when you compare to the average desktop app

Closi 4y ago
Agree, and I think this is the point of the article too. If we are going to say things like "React is fast" then it needs a further clarification - fast compared to what? Are we comparing it to C, jQuery, Angular, Pure Javascript, or a Commedore 64? Because it doesn't make sense to say it is fast if there isn't something to compare it against. (In reality, I suspect it is only really "fast" if you compare it with something slow).
harel 4y ago
If a developer coded a slow app in react they will code a slow app in svelte. We need to stop blaming the language.

deleted 4y ago

[deleted]

mmis1000 4y ago

React is fast in the sense it eat tons of computation power without lagging the ui. In my opinion, this is a dead end. They should really try to reduce the actual computation power required to render the ui. The growing rate of cpu speed is stalled. There already isn't too much room for it. And what about user with a low end Android machine? Not lagging the ui isn't helpful here. Because it still need seconds to render the whole thing.