15 ms·

Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works. If your app is spending

by jchw 5y ago

Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works. If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead. Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here. In practice. So Svelte has a lot to prove to get people to try to move. And this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” (while simultaneously admitting that plenty of frameworks were slower at the time.) That’s not going to work. That’s going to classify you as “insane person” to many people. It reminds me of the claims G-WAN made: over-exaggerations in a smarmy tone based on micro-benchmark wins. I’m not saying there’s anything wrong with Svelte. But, this is not how you sell something. React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. It delivered exactly that. And yet: > the alternative is to do something no-one actually does Somehow this article manages to contradict itself in pursuit of unnecessary smarminess. I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion. The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.

madeofpalk 5y ago
> this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.
- cwillu 5y ago
  It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones. But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.
- jchw 5y ago
  That’s the weird part. I agree with you, but then at the end, they say the important part: > It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. I find this bewildering because it makes me feel like the article does actually understand React. It realizes it was faster than frameworks it initially competed against, it understands that virtual DOM is a means to an end. But then at the same time it is classified as a meme that only wins in performance against things nobody would ever do. In a way, writing it like this makes it harder to critique.
  - vinnymac 5y ago
    Strangely, after having read the article, now I am wondering why the React team can't just borrow some of these optimizations. It would take a massive overhaul, but it's not like React has ever stood still, it's constantly evolving and changing. I wouldn't be surprised if the under the hood stuff continues to change in a huge way, just like it did when React Fiber was completed. At the end of the day, I've never spoken to a developer who was using React because it was fast, but because it was easy to use and understand.
    - engineeringwoke 5y ago
      I was quite involved in the project around 2017-2018, and this is just what I feel, but I think the API is pretty much hardened at this point. Context was a disaster. Hooks are useful but more difficult to reason about compared to classes. They have said straight out that JIT optimizations don't work well when the main pattern was to heavily manipulate a singular state object, and that was a culture that I think they failed to change with Hooks. If Facebook comes up with something else, I think it will be something new. Maybe that is Reason, or something that abuses WASM/Rust in the core architecture. Who knows. The project has a lot of tech debt, and the ecosystem has changed quite a bit as well.
deleted 5y ago
[deleted]
progx 5y ago
Performance is not a problem for the most developers, as long as the app runs smooth. React gave us not a better programming model, it gave us an other programming model. In some cases template based enignes are better than JSX, but that discussion has nothing todo with Svelte or React. React boomed cause at that time everybody has enough of bloated frameworks and with JSX you had a wonderfull thing to tinker code... thats what developers like, tinker all the day complex bloated code. Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more. I rememnber the day when everybody was shouting, Redux is the best thing every ;) And now "hooks" Really?
- arcturus17 5y ago
  > Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more. You can keep telling yourself that React only took over because it makes things more complex and it came from Facebook, if that's what makes you happy.
  - progx 5y ago
    No you can tinkle complex code, i did not say that anybody does it. It remembers me on WordPress, where many "pro" devs mixed nice complex unreadable code, that is only necessery, because they use WordPress. If they would use something else, they would not have complex code.
- mumblemumble 5y ago
  > Performance is not a problem for the most developers, as long as the app runs smooth. On their machines. That's often a critical distinction. Developers often get the nicest computers, and they often get to have good, fast Internet connections that are close (in terms of Internet topology) to the server where the site is running. So they can't necessarily perceive the effects of the browser being starved for resources, or jank from the app being chatty over a high latency connection, or resources failing to load due to a spotty connection, or anything like that. What some of these technical decisions add up to is situations like a family member who's using a cheap Chromebook and has flaky Comcast cable internet, bewilderedly asking me why this site they're trying to use keeps showing them a blank page or somesuch. They know that, if the page doesn't load at all, the browser usually gives them a, "We couldn't load that page. Try refreshing," error. What they don't get is that, if it's a React app and some JS resource fails to load, it'll stop the rendering of the site cold, and they'll just see a blank page, or a half-loaded page, or some other confusing state. And I've yet to figure out a way to explain things to them that gets them to see this as, "The Internet is being flaky." They see it as, "Your site is flaky." They're not entirely wrong about that. The people who develop Internet and Web standards have put a lot of time trying to engineer the Web to tend toward failing gracefully. React (and frameworks like it) seems to have, in one stroke, undone all that and instead engineered things to tend toward failing catastrophically. I don't know if you could get a JS-first framework that doesn't behave that way, so maybe it's a necessary evil? But, I get that React solves a real problem that some people have, so it'd sure be nice if it weren't.
protonimitate 5y ago
> React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output. Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale. The reason I think React works so well and is so popular atm is because it works just as well at a small scale as it does on a team with 5-6 active contributors (in my experience, at least). That isn't to say that Svelte can't deliver the same wonderful experience at scale, I've just yet to see a truly shining example of it. I may also be in the minority, but performance of front end frameworks is near the bottom of my evaluation checklist. I've used svelte for some one off personal projects, just to get a feel. And it's fine but nothing about has convinced me to lead a project/team towards picking that over React, Vue, or even some SSR framework.
- progx 5y ago
  That is true, Svelte did not have a big benefit over React, so no need to change. And i use Svelte. When you start or build a new product/team and can freely choose which Framework you want to use, you can have a look at Svelte. For our company Svelte is easier to use, it has (in our opinion) less bloated code (e.g. state handling) in our app as React or Vue (which we used before). BUT, Svelte has other problems, especially when you heavily use dynamic components, which are easier to handle in Vue or React. That React has better active contributers is one big point for React. But it depends on Facebook.
  - RivieraKid 5y ago
    > BUT, Svelte has other problems, especially when you heavily use dynamic components, which are easier to handle in Vue or React. Do you have an example?
- yladiz 5y ago
  > performance of front end frameworks is near the bottom of my evaluation checklist Sorry to pick on this point but depending on your application this should be more (or much more) important. Too many teams have this same opinion and it's glaringly obvious how little they care about performance. I'd agree that raw performance isn't really important, but the ways you can and the tools you have to optimize the performance of the app are if you find that you have bottlenecks is and this does partially depend on the framework. That said, I would agree, all frameworks would probably be fast enough for most use cases, and even with the optimization aspect arguably the most important aspects are about application structure and how the framework forces you to structure your application. As you mention, I think this is why React wins, the way it forces you to think about things unidirectionally, think about state and components separately, etc. are all big wins for understanding your application. Also worth noting is that Svelte doesn't really have a big company backing it like React does and so the ecosystem is smaller, which could contribute to its relatively small size.
apatheticonion 5y ago
I liked Svelte reactivity but the component props are unergonomic to use and TypeScript support is lacklustre
- danaw 5y ago
  Care to expand on this? Component props seem quite straightforward where I stand and Typescript support has improved drastically over the preceding months
macspoofing 5y ago
>The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code. In this way, whether you go with Vue or React or Angular, it makes no effin difference to performance. But yes, there is overhead in managing the virtual DOM and yes, you can get yourself in trouble if you don't structure your application in line with how the framework expects you too. >React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. React made a stronger claim. It wasn't just about React vs some Templating framework. React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim. >Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead. And it's not a bad argument. The DOM is an abstraction and the underlying implementation is highly optimized. DOM mutations are not the expensive thing, it's the final render, and that part has had an enormous amount of work done to make it smart and fast. By the way, Flash had a great built-in rendering model. The Flash display list hierarchy was very well architected and it wouldn't re-render the entire page if only a part of it changed. >But this isn’t how you sell a framework to programmers, in my opinion. Claiming your framework is faster than the other guys IS how you sell a framework to programmers. That's how React and Vue were/are being sold.
- ubercore 5y ago
  I seem to remember that when React was first introduced, DOM mutations _were_ very expensive. I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?
  - lhorie 5y ago
duxup 5y ago
>But, this is not how you sell something. I feel that way about a lot of articles like this. I want to know what you do well, I don't want to hear someone complain about something else. Sell me on what you do well and what that means for me. I work in React a lot and I don't feel like I run into this “pure overhead” type concept in the way they describe it and thus this article makes me: 1. Wonder what they're doing in React that they feel this way. 2. The article quickly becomes much less relevant to whatever it is I'm thinking about.
throwaway894345 5y ago
> If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. I think you're interpreting their messaging as "Svelte's compiled DOM is faster than virtual DOMs ergo Svelte is appropriate for every application" whereas the implication is certainly "Svlete's compiled DOM is faster than virtual DOMs ergo Svelte may be a good choice for applications that are constrained by virtual DOM". I don't think it's a reasoning failure, but rather a misunderstanding (an inadvertent straw man on your part). > Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here I think this makes a fair amount of sense. Often an incumbent needs to be quite a lot better in order to justify the learning curve, and I'm not sure that Svelte is. That said, I've been part of a lot of Python projects because Python's problems don't often manifest for new projects, but rather at scale (real workloads suffer from Python's poor performance, development velocity decreases at scale due to type annotations, package managers crawl as the dependency tree grows beyond the "toy" category, etc). I wonder if perhaps there's a similar effect in which React is "good enough" for new projects but not enough for > The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead. I don't understand this claim. In order for it to be "strictly overhead" we have to assume that Svelte's compilation step has no benefit i.e., the output code doesn't reduce the JIT's workload but even more than that, the output code has no advantages (i.e., performance advantages) over React? > I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion. The way you sell a framework to programmers is largely by the backing of huge tech companies who use it in large, noteworthy projects. That's presumably not an option available to Svelte developers?
edave64 5y ago
> However, this article is overly focused on just one element of how React works. Because that is the topic of the article. It never even says "The virtual DOM overhead is a problem". It actually says exactly the opposite, it's often fast enough and not a problem. It didn't call Virtual DOM a meme, it called "the virtual DOM is fast" a meme. Performance wise, as the article says, it is pure overhead. Virtual DOM is the solution to a problem the javascript frameworks create themselves. I've had argue against managers that no, using a virtual DOM will not magically make our pure JS app run any faster. Especially once I put in the work to make the DOM as seldom accessed as I could. There is a fantastic reason these JS frameworks work that way. Instead of building creating and update logic, you just need creation logic and always rebuild the widget. But that's super slow, so you use a virtual DOM to make it faster. Just not as fast as it would have been if you hadn't used the framework. The tradeoff being that your code is often significantly simpler and easier to maintain. Though that also breaks down in some parts.
darepublic 5y ago
>However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. a more catastrophic failure of reasoning, that is far more prevalent, is not understanding that virtual DOM is overhead on top of the regular DOM, not some magic fairy dust invented by facebook geniuses that just makes the web better (tm) because you are a dev whose first exposure to web development was via a React tutorial where you built some <popular app> clone as it held your hand every step of the way, and now you are loosed into the jungle of problems in the wild ready to crush the spirits of those old tired jquery devs. bwahahahaha.
kujino 5y ago
Svelte hasn't taken over because React is way too popular already. If you want a job you have to learn React (the same way Java is still one of the top lang to get a job but it's for legacy rather than technical reasons). Svelte performance is a nice bonus but it is the last reason I prefer Svelte over React. I prefer Svelte because it is truly reactive (unlike React) which makes everything easier, cleaner & more readable. Svelte is the only framework you can grasp in 10min by just looking at a few examples. To get started, you don't even have to read a tutorial or documentation, the code is self-explanatory. React is a complex beast and, in my opinion, all this is an overkill / overengineered environment for expressing UIs. I find Svelte to be the only framework that "make sense". Ultimately UI is not that complex, it's a store -> derived variables -> UI where each step is a reactive function of the previous one. A framework should let you express this very concisely and take care of everything else for you. If x = y + z then I want to write x = y + z, end of the story. Like in a Excel sheet, just write the formulas and that's it. No useStates, hooks, componentShouldUpdate(), and other wierd stuff. Svelte is to React what Pluto is to Jupyter Notebooks, less popular because of legacy, but, in my opinion, obviously more elegant & cleaner
- jamra 5y ago
  I’m in agreement with you that the performance is only a part of why Svelte is so nice. The state management in Svelte is fantastic.
slver 5y ago
> The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead. Modern software commonly goes through multiple transformation (compilation stages) and it's increasingly common for some of them to be AOT, and some to be JIT, and neither AOT or JIT is overhead, even in combination. They have different pros/cons and in fact together you get the best of both worlds. This doesn't negate your main point, but I wish you didn't end with an example of "irony" that actually is incorrect.
rich_harris 5y ago
Firstly, as the article emphasises, _diffing_ is far from the only issue with virtual DOM. And this isn't about microbenchmarks; plenty of people have run up against React's performance limits in real world applications and have had to spend time engaging in menial optimisation work as a result. Secondly, you're dismissive of the idea that 'the virtual DOM is fast' is a meme (in the original Dawkinian sense; I'm not talking about gifs with Impact-typefaced captions), which suggests you haven't spent a lot of time around developers on places like Twitter and Stack Overflow. This misperception _absolutely_ exists, and this article was written to correct it, not to 'sell' Svelte. Svelte isn't intent on 'taking over'. We're quite happy providing developers with an alternative to React that enables them to write less code and not have to worry about performance. That said, I'd argue the 'irrelevant' label is somewhat unfair (https://twitter.com/swyx/status/1409529125539254277 https://twitter.com/swyx/status/1409529125539254277, https://2020.stateofjs.com/en-US/technologies/front-end-frameworks/ https://2020.stateofjs.com/en-US/technologies/front-end-fram...).
alserio 5y ago
Svelte does two things very well: it's easy to integrate with other vanilla and not js technologies and opens up the space of your solutions. You don't have to have full buy in in it. You are not forced to do things how the framework want you to think about them. That's alone is a big win against React in my book, where you are not doing web dev, you are doing React dev, and sometimes that is way too constrained. That's is also a reason why Svelte is not irrelevant. It doesn't need to become React to be useful.
rualca 5y ago
> Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second And this, ladies and gentlemen, is how we ended up with web pages that lead modern mid- and even high-end personal computers grind to a halt.

by jchw 5y ago

madeofpalk 5y ago

> this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.

cwillu 5y ago
It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones. But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.
jchw 5y ago
That’s the weird part. I agree with you, but then at the end, they say the important part: > It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. I find this bewildering because it makes me feel like the article does actually understand React. It realizes it was faster than frameworks it initially competed against, it understands that virtual DOM is a means to an end. But then at the same time it is classified as a meme that only wins in performance against things nobody would ever do. In a way, writing it like this makes it harder to critique.
- vinnymac 5y ago
  Strangely, after having read the article, now I am wondering why the React team can't just borrow some of these optimizations. It would take a massive overhaul, but it's not like React has ever stood still, it's constantly evolving and changing. I wouldn't be surprised if the under the hood stuff continues to change in a huge way, just like it did when React Fiber was completed. At the end of the day, I've never spoken to a developer who was using React because it was fast, but because it was easy to use and understand.
  - engineeringwoke 5y ago
    I was quite involved in the project around 2017-2018, and this is just what I feel, but I think the API is pretty much hardened at this point. Context was a disaster. Hooks are useful but more difficult to reason about compared to classes. They have said straight out that JIT optimizations don't work well when the main pattern was to heavily manipulate a singular state object, and that was a culture that I think they failed to change with Hooks. If Facebook comes up with something else, I think it will be something new. Maybe that is Reason, or something that abuses WASM/Rust in the core architecture. Who knows. The project has a lot of tech debt, and the ecosystem has changed quite a bit as well.

deleted 5y ago

[deleted]

progx 5y ago

Performance is not a problem for the most developers, as long as the app runs smooth. React gave us not a better programming model, it gave us an other programming model. In some cases template based enignes are better than JSX, but that discussion has nothing todo with Svelte or React. React boomed cause at that time everybody has enough of bloated frameworks and with JSX you had a wonderfull thing to tinker code... thats what developers like, tinker all the day complex bloated code. Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more. I rememnber the day when everybody was shouting, Redux is the best thing every ;) And now "hooks" Really?

arcturus17 5y ago
> Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more. You can keep telling yourself that React only took over because it makes things more complex and it came from Facebook, if that's what makes you happy.
- progx 5y ago
  No you can tinkle complex code, i did not say that anybody does it. It remembers me on WordPress, where many "pro" devs mixed nice complex unreadable code, that is only necessery, because they use WordPress. If they would use something else, they would not have complex code.
mumblemumble 5y ago
> Performance is not a problem for the most developers, as long as the app runs smooth. On their machines. That's often a critical distinction. Developers often get the nicest computers, and they often get to have good, fast Internet connections that are close (in terms of Internet topology) to the server where the site is running. So they can't necessarily perceive the effects of the browser being starved for resources, or jank from the app being chatty over a high latency connection, or resources failing to load due to a spotty connection, or anything like that. What some of these technical decisions add up to is situations like a family member who's using a cheap Chromebook and has flaky Comcast cable internet, bewilderedly asking me why this site they're trying to use keeps showing them a blank page or somesuch. They know that, if the page doesn't load at all, the browser usually gives them a, "We couldn't load that page. Try refreshing," error. What they don't get is that, if it's a React app and some JS resource fails to load, it'll stop the rendering of the site cold, and they'll just see a blank page, or a half-loaded page, or some other confusing state. And I've yet to figure out a way to explain things to them that gets them to see this as, "The Internet is being flaky." They see it as, "Your site is flaky." They're not entirely wrong about that. The people who develop Internet and Web standards have put a lot of time trying to engineer the Web to tend toward failing gracefully. React (and frameworks like it) seems to have, in one stroke, undone all that and instead engineered things to tend toward failing catastrophically. I don't know if you could get a JS-first framework that doesn't behave that way, so maybe it's a necessary evil? But, I get that React solves a real problem that some people have, so it'd sure be nice if it weren't.

protonimitate 5y ago

> React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output. Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale. The reason I think React works so well and is so popular atm is because it works just as well at a small scale as it does on a team with 5-6 active contributors (in my experience, at least). That isn't to say that Svelte can't deliver the same wonderful experience at scale, I've just yet to see a truly shining example of it. I may also be in the minority, but performance of front end frameworks is near the bottom of my evaluation checklist. I've used svelte for some one off personal projects, just to get a feel. And it's fine but nothing about has convinced me to lead a project/team towards picking that over React, Vue, or even some SSR framework.

progx 5y ago
That is true, Svelte did not have a big benefit over React, so no need to change. And i use Svelte. When you start or build a new product/team and can freely choose which Framework you want to use, you can have a look at Svelte. For our company Svelte is easier to use, it has (in our opinion) less bloated code (e.g. state handling) in our app as React or Vue (which we used before). BUT, Svelte has other problems, especially when you heavily use dynamic components, which are easier to handle in Vue or React. That React has better active contributers is one big point for React. But it depends on Facebook.
- RivieraKid 5y ago
  > BUT, Svelte has other problems, especially when you heavily use dynamic components, which are easier to handle in Vue or React. Do you have an example?
yladiz 5y ago
> performance of front end frameworks is near the bottom of my evaluation checklist Sorry to pick on this point but depending on your application this should be more (or much more) important. Too many teams have this same opinion and it's glaringly obvious how little they care about performance. I'd agree that raw performance isn't really important, but the ways you can and the tools you have to optimize the performance of the app are if you find that you have bottlenecks is and this does partially depend on the framework. That said, I would agree, all frameworks would probably be fast enough for most use cases, and even with the optimization aspect arguably the most important aspects are about application structure and how the framework forces you to structure your application. As you mention, I think this is why React wins, the way it forces you to think about things unidirectionally, think about state and components separately, etc. are all big wins for understanding your application. Also worth noting is that Svelte doesn't really have a big company backing it like React does and so the ecosystem is smaller, which could contribute to its relatively small size.

apatheticonion 5y ago

I liked Svelte reactivity but the component props are unergonomic to use and TypeScript support is lacklustre

danaw 5y ago
Care to expand on this? Component props seem quite straightforward where I stand and Typescript support has improved drastically over the preceding months

macspoofing 5y ago

>The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code. In this way, whether you go with Vue or React or Angular, it makes no effin difference to performance. But yes, there is overhead in managing the virtual DOM and yes, you can get yourself in trouble if you don't structure your application in line with how the framework expects you too. >React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. React made a stronger claim. It wasn't just about React vs some Templating framework. React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim. >Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead. And it's not a bad argument. The DOM is an abstraction and the underlying implementation is highly optimized. DOM mutations are not the expensive thing, it's the final render, and that part has had an enormous amount of work done to make it smart and fast. By the way, Flash had a great built-in rendering model. The Flash display list hierarchy was very well architected and it wouldn't re-render the entire page if only a part of it changed. >But this isn’t how you sell a framework to programmers, in my opinion. Claiming your framework is faster than the other guys IS how you sell a framework to programmers. That's how React and Vue were/are being sold.

ubercore 5y ago
I seem to remember that when React was first introduced, DOM mutations _were_ very expensive. I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?
- lhorie 5y ago

duxup 5y ago

>But, this is not how you sell something. I feel that way about a lot of articles like this. I want to know what you do well, I don't want to hear someone complain about something else. Sell me on what you do well and what that means for me. I work in React a lot and I don't feel like I run into this “pure overhead” type concept in the way they describe it and thus this article makes me: 1. Wonder what they're doing in React that they feel this way. 2. The article quickly becomes much less relevant to whatever it is I'm thinking about.

throwaway894345 5y ago

> If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. I think you're interpreting their messaging as "Svelte's compiled DOM is faster than virtual DOMs ergo Svelte is appropriate for every application" whereas the implication is certainly "Svlete's compiled DOM is faster than virtual DOMs ergo Svelte may be a good choice for applications that are constrained by virtual DOM". I don't think it's a reasoning failure, but rather a misunderstanding (an inadvertent straw man on your part). > Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here I think this makes a fair amount of sense. Often an incumbent needs to be quite a lot better in order to justify the learning curve, and I'm not sure that Svelte is. That said, I've been part of a lot of Python projects because Python's problems don't often manifest for new projects, but rather at scale (real workloads suffer from Python's poor performance, development velocity decreases at scale due to type annotations, package managers crawl as the dependency tree grows beyond the "toy" category, etc). I wonder if perhaps there's a similar effect in which React is "good enough" for new projects but not enough for > The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead. I don't understand this claim. In order for it to be "strictly overhead" we have to assume that Svelte's compilation step has no benefit i.e., the output code doesn't reduce the JIT's workload but even more than that, the output code has no advantages (i.e., performance advantages) over React? > I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion. The way you sell a framework to programmers is largely by the backing of huge tech companies who use it in large, noteworthy projects. That's presumably not an option available to Svelte developers?

edave64 5y ago

> However, this article is overly focused on just one element of how React works. Because that is the topic of the article. It never even says "The virtual DOM overhead is a problem". It actually says exactly the opposite, it's often fast enough and not a problem. It didn't call Virtual DOM a meme, it called "the virtual DOM is fast" a meme. Performance wise, as the article says, it is pure overhead. Virtual DOM is the solution to a problem the javascript frameworks create themselves. I've had argue against managers that no, using a virtual DOM will not magically make our pure JS app run any faster. Especially once I put in the work to make the DOM as seldom accessed as I could. There is a fantastic reason these JS frameworks work that way. Instead of building creating and update logic, you just need creation logic and always rebuild the widget. But that's super slow, so you use a virtual DOM to make it faster. Just not as fast as it would have been if you hadn't used the framework. The tradeoff being that your code is often significantly simpler and easier to maintain. Though that also breaks down in some parts.

darepublic 5y ago

>However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. a more catastrophic failure of reasoning, that is far more prevalent, is not understanding that virtual DOM is overhead on top of the regular DOM, not some magic fairy dust invented by facebook geniuses that just makes the web better (tm) because you are a dev whose first exposure to web development was via a React tutorial where you built some <popular app> clone as it held your hand every step of the way, and now you are loosed into the jungle of problems in the wild ready to crush the spirits of those old tired jquery devs. bwahahahaha.

kujino 5y ago

Svelte hasn't taken over because React is way too popular already. If you want a job you have to learn React (the same way Java is still one of the top lang to get a job but it's for legacy rather than technical reasons). Svelte performance is a nice bonus but it is the last reason I prefer Svelte over React. I prefer Svelte because it is truly reactive (unlike React) which makes everything easier, cleaner & more readable. Svelte is the only framework you can grasp in 10min by just looking at a few examples. To get started, you don't even have to read a tutorial or documentation, the code is self-explanatory. React is a complex beast and, in my opinion, all this is an overkill / overengineered environment for expressing UIs. I find Svelte to be the only framework that "make sense". Ultimately UI is not that complex, it's a store -> derived variables -> UI where each step is a reactive function of the previous one. A framework should let you express this very concisely and take care of everything else for you. If x = y + z then I want to write x = y + z, end of the story. Like in a Excel sheet, just write the formulas and that's it. No useStates, hooks, componentShouldUpdate(), and other wierd stuff. Svelte is to React what Pluto is to Jupyter Notebooks, less popular because of legacy, but, in my opinion, obviously more elegant & cleaner

jamra 5y ago
I’m in agreement with you that the performance is only a part of why Svelte is so nice. The state management in Svelte is fantastic.

slver 5y ago

> The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead. Modern software commonly goes through multiple transformation (compilation stages) and it's increasingly common for some of them to be AOT, and some to be JIT, and neither AOT or JIT is overhead, even in combination. They have different pros/cons and in fact together you get the best of both worlds. This doesn't negate your main point, but I wish you didn't end with an example of "irony" that actually is incorrect.

rich_harris 5y ago

Firstly, as the article emphasises, _diffing_ is far from the only issue with virtual DOM. And this isn't about microbenchmarks; plenty of people have run up against React's performance limits in real world applications and have had to spend time engaging in menial optimisation work as a result. Secondly, you're dismissive of the idea that 'the virtual DOM is fast' is a meme (in the original Dawkinian sense; I'm not talking about gifs with Impact-typefaced captions), which suggests you haven't spent a lot of time around developers on places like Twitter and Stack Overflow. This misperception _absolutely_ exists, and this article was written to correct it, not to 'sell' Svelte. Svelte isn't intent on 'taking over'. We're quite happy providing developers with an alternative to React that enables them to write less code and not have to worry about performance. That said, I'd argue the 'irrelevant' label is somewhat unfair (https://twitter.com/swyx/status/1409529125539254277 https://twitter.com/swyx/status/1409529125539254277, https://2020.stateofjs.com/en-US/technologies/front-end-frameworks/ https://2020.stateofjs.com/en-US/technologies/front-end-fram...).

alserio 5y ago

Svelte does two things very well: it's easy to integrate with other vanilla and not js technologies and opens up the space of your solutions. You don't have to have full buy in in it. You are not forced to do things how the framework want you to think about them. That's alone is a big win against React in my book, where you are not doing web dev, you are doing React dev, and sometimes that is way too constrained. That's is also a reason why Svelte is not irrelevant. It doesn't need to become React to be useful.

rualca 5y ago

> Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second And this, ladies and gentlemen, is how we ended up with web pages that lead modern mid- and even high-end personal computers grind to a halt.