6 ms·

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with ev

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flows. While there are pathological cases where you can notice the overhead of the virtual DOM diff it's pretty rare that it meaningfully affects the user experience in practice, especially when compared to the overhead of downloading static resources like JS and rendering antipatterns like layout thrash. And in the situations where it is noticeable there are escape hatches to fix it (as mentioned in the article). 2. I disagree with the last sentence strongly. I would argue that Svelte makes huge sacrifices in expressive power, tooling and predictability in order to gain performance that is often not noticeable or is easily achieved with React's memoization features. React was always about enabling front-end engineers to take advantage of software engineering best practices so they could level up velocity and quality. I think Svelte's use of a constrained custom DSL is a big step backwards in that respect so while I appreciate the engineering behind it, it's not a technology I am interested in using. Even though I disagree on these points I think it is a well-written article and is a pretty fair criticism of React outside of those two points, and I could see reasonable people disagreeing on these trade-offs.

norswap 4y ago
As a seasoned engineer (compiler background), but beginner in frontend, I'm curious aboutthe lack of expressive power that Svelte incurs. Could you (or someone) characterize things that are hard to do in Svelte?
- SebastianKra 4y ago
  Once a data is transformed into a view in Svelte, you can't do anything with it in JS. For example, a component can't iterate over the children in a slot [1]. This is limiting when designing generic Component-APIs. As an extreme example: In React, I could trivially define a tabbed interface by mixing strings, JSX, and components, without imposing any DOM-structure. The component that reads this definition could use it to build a tabbed-view on mobile, and a master-detail-view on desktop. ...or it could build a table of contents. When defining the tab names, I can mostly use strings, but fall back to JSX if necessary. Importantly, the API is completely independent from the implementation. const tabs = [ { name: "Tab 1", icon: <img ... />, content: MainTab }, { name: <>Tab with <b>bold<b/> text</>, icon: <MyIcon ... />, content: SecondTab }, ] return <MyLayout tabs={tabs} /> [1]: https://github.com/sveltejs/svelte/issues/5381 https://github.com/sveltejs/svelte/issues/5381
deleted 4y ago
[deleted]
The5thElephant 4y ago
Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from doing something you can do in React, and Svelte/Vue make getting into a codebase far more accessible for people with a wider range of skillsets. The secondary effects of React's popularity have been a significant loss in emphasis on HTML and CSS skills over doing everything in JS which often results in div-soup that is less performant and less capable. HTML and CSS not being first class-citizens as they are in other frameworks means developers simply aren't encouraged to learn them nearly as well as they used to. Front-end frameworks should not be just for front-end developers. They should be understandable and accessible to people who are not JS first and who come from backgrounds that are not purely engineering. In my experience it is much easier to teach someone familiar with design and HTML/CSS how to explore a Vue or Svelte codebase than a React one, and the JS devs I have worked with who fully learn these libraries have not complained about any limitations compared to React.
- nwienert 4y ago
  It's great to argue for Vue/Svelte, but just to clarify - the entire point about HTML/CSS isn't really true, there's no difference in support between React or any other framework there. And disagree on HTML/CSS skill loss being a thing, or being proximately caused by React. And no it doesn't have any div-soup causative effect either. I get that templates are simpler for non-coders. Unfortunately, in all but the simplest cases the cost-benefit is towards the React model as you are just "using the platform" to build your views - ie, JS and not some arbitrary DSL.
  - The5thElephant 4y ago
    How can you say there is no difference? What do you think Vue and Svelte SFCs are? Where does React have built-in component style scoping? Where does React have automatic passing of classes and properties to components? Can I write SCSS in a React JS file and have it just work? Nope. The platform is more than just JS, and React has plenty of stuff going on that is "magic" enough to be no different for me than the abstraction of a DSL. How is the cost-benefit better for React when I keep seeing developers who actually try other frameworks have their minds blown at how much easier it is to do the same things? The CSS skill loss is very real, particularly with the number of straight-to-React bootcamps that barely touch on it and the insistence on using CSS-in-JS which makes it way harder for people to explore a production website and learn the fun way. I'm not some HTML/CSS purist, and React was a big step forward for the industry, but now its time is past and we have way better alternatives.
alserio 4y ago
At least in my team the "constrained custom dsl" has been a net productivity win. The only people struggling for a bit were the ones used to react, since they tried to apply react solutions to every problem. It appears you need to unlearn a lot of react when using svelte, so I would argue that it's actually react that wants you do develop in a specific way. The same does not appear to be true for devs coming from other technologies. Other experiences may of course vary.
tobr 4y ago
I think your conclusion in point 2 is misguided, but I can see where you’re coming from. It’s true that virtual DOM has a lot of expressive power, and Svelte’s templating features are more limited in how you can approach certain problems. I find Svelte’s slots especially challenging for more advanced use cases, and wish they were more composable. But in my experience, React’s openness to expressive experimentation is not a net positive for maintainability, productivity, or quality. There are lots of footguns, and bad ideas embraced by the ecosystem. HoCs were a terrible idea, and were replaced with an even worse idea, hooks. Compared to that, Svelte’s reactive statements and stores are a bliss. Arguably, it’s because React has experimented and made those mistakes that Svelte has been able to focus on a constrained DSL that mostly supports the features that are actually a good idea.
- peterhunt 4y ago
  I think there are two things that are interesting about your point of view. First, I think a mistake the react team made was not exerting more control over the ecosystem. I think a lot of questionable content marketing pieces ended up as “best practices” which we are still unwinding as a community. Second, I totally buy the idea that there are multiple personas and that different tools speak to different personas. The sustained popularity of constrained dsls among subsets of the frontend community speaks to this.
  - tobr 4y ago
    But are you against constrained templating DSLs on principle, or just the specifics of how Svelte does it? I think the reason bad ideas take hold is because people are looking for guidance; constraints, if you will. In React that is offered through libraries, frameworks and best practices, but not all of those are good. Svelte has a lot more control of its ecosystem because the constraints are built in to a compiler. And as I said, I think it falls short in certain areas, but all in all I think those restrictions are a net win.
    - peterhunt 4y ago
      I am against constrained DSLs in general unless it buys you something. In the general case, with a DSL you sacrifice expressivity in order to gain security guarantees or improved performance. In this case you are sacrificing expressivity to gain performance but I don't think the performance gains are meaningful enough to be worth sacrificing all of that expressivity. So to answer your question, I am generally opposed to constrained templating DSLs for web frontend applications overall.
satvikpendem 4y ago
Isn't SolidJS supposed to be like React (in that it has JSX, hooks etc) but without the VDOM? So I guess that would sidestep your point #2, but curious to hear your thoughts on it. Personally I don't use Svelte, Vue, Solid etc simply due to the (lack of) library support compared to React. For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparable in the non-React world.
- JadedBlueEyes 4y ago
  > reached for react-three-fiber, there simply isn't something comparable in the non-React world. This came out a year ago now. https://svelthree.dev/ https://svelthree.dev/ https://github.com/vatro/svelthree https://github.com/vatro/svelthree Svelte, Vue, etc. all have plenty of awesome libraries - you just need to be aware of them.
- peterhunt 4y ago
  SolidJS also sacrifices expressivity for performance (ie you need to do contortions like this[1] to build dynamic lists), so I prefer React to it. However, I like its approach more than Svelte because there’s less of a DSL to learn. [1] https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_for
- leetrout 4y ago
  > For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparable in the non-React world. Respectfully, that is because you dont _need_ anything other than ThreeJS in the other frameworks. I do find it interesting that it says it performs faster due to reacts scheduler.
  - satvikpendem 4y ago
    > Respectfully, that is because you dont _need_ anything other than ThreeJS in the other frameworks. Not really, ThreeJS is imperative, react-three-fiber is declarative. I use the latter for the same reason I use React over jQuery, I don't have to mess around with appending nodes, I can lay out my view declaratively and have the framework fill in the rest.
ricardobeat 4y ago
> performance that is often not noticeable or is easily achieved with React's memoization features. React was always about enabling front-end engineers to take advantage of software engineering best practices so they could level up velocity and quality I've been working daily with React for almost 6 years now. Another 10+ years of web development before that. And I have yet to see these benefits be realized. It's not easy, at all, to "optimize performance using memoization" in React, best practices are mostly tied to JSX/React and its tooling, not general software engineering, and they change yearly based on the latest version and current third-party library trends. Velocity and quality are both hurt. Your best bet is to use an all-in-one framework like next.js, which delegates most of the pain to the authors - but not all of it. The big improvements that React brought to the mainstream were componentization, and popularizing declarative rendering. I think we have better options today. Svelte does not limit expressiveness in my experience, in fact it makes it way easier to do what you actually want to do, without contorting yourself to the framework. It's liberating. This is a viewpoint I hear frequently though, so it definitely depends on your personal path as a developer and what you've been exposed to.
aidenn0 4y ago
#1 might be true today, but it was definitely not when react was new. I made a fairly simple react site that worked great on my workstation, and then I tried using it on my Android phone and it was unusably slow. Mobile phones have gotten faster, and so have mobile js improvements, so I wouldn't be surprised if it's negligible overhead these days.
HorizonXP 4y ago
As a complete aside, happy birthday bud!
wildermuthn 4y ago
“A constrained DSL” is precisely what is wrong with so many React alternatives. Anyone who had to deal with writing Angular 1 directives and fight with the digest loop understands how very real the pain is. Also, there are two types of performance: how fast code runs and how fast a team can maintain and extend code. Does one optimize for running code or for building code? React won because it optimized for the latter. And thank god, because who wants to mess with digest loops and magical DSLs?

norswap 4y ago

As a seasoned engineer (compiler background), but beginner in frontend, I'm curious aboutthe lack of expressive power that Svelte incurs. Could you (or someone) characterize things that are hard to do in Svelte?

SebastianKra 4y ago
Once a data is transformed into a view in Svelte, you can't do anything with it in JS. For example, a component can't iterate over the children in a slot [1]. This is limiting when designing generic Component-APIs. As an extreme example: In React, I could trivially define a tabbed interface by mixing strings, JSX, and components, without imposing any DOM-structure. The component that reads this definition could use it to build a tabbed-view on mobile, and a master-detail-view on desktop. ...or it could build a table of contents. When defining the tab names, I can mostly use strings, but fall back to JSX if necessary. Importantly, the API is completely independent from the implementation. const tabs = [ { name: "Tab 1", icon: <img ... />, content: MainTab }, { name: <>Tab with <b>bold<b/> text</>, icon: <MyIcon ... />, content: SecondTab }, ] return <MyLayout tabs={tabs} /> [1]: https://github.com/sveltejs/svelte/issues/5381 https://github.com/sveltejs/svelte/issues/5381

deleted 4y ago

[deleted]

The5thElephant 4y ago

Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from doing something you can do in React, and Svelte/Vue make getting into a codebase far more accessible for people with a wider range of skillsets. The secondary effects of React's popularity have been a significant loss in emphasis on HTML and CSS skills over doing everything in JS which often results in div-soup that is less performant and less capable. HTML and CSS not being first class-citizens as they are in other frameworks means developers simply aren't encouraged to learn them nearly as well as they used to. Front-end frameworks should not be just for front-end developers. They should be understandable and accessible to people who are not JS first and who come from backgrounds that are not purely engineering. In my experience it is much easier to teach someone familiar with design and HTML/CSS how to explore a Vue or Svelte codebase than a React one, and the JS devs I have worked with who fully learn these libraries have not complained about any limitations compared to React.

nwienert 4y ago
It's great to argue for Vue/Svelte, but just to clarify - the entire point about HTML/CSS isn't really true, there's no difference in support between React or any other framework there. And disagree on HTML/CSS skill loss being a thing, or being proximately caused by React. And no it doesn't have any div-soup causative effect either. I get that templates are simpler for non-coders. Unfortunately, in all but the simplest cases the cost-benefit is towards the React model as you are just "using the platform" to build your views - ie, JS and not some arbitrary DSL.
- The5thElephant 4y ago
  How can you say there is no difference? What do you think Vue and Svelte SFCs are? Where does React have built-in component style scoping? Where does React have automatic passing of classes and properties to components? Can I write SCSS in a React JS file and have it just work? Nope. The platform is more than just JS, and React has plenty of stuff going on that is "magic" enough to be no different for me than the abstraction of a DSL. How is the cost-benefit better for React when I keep seeing developers who actually try other frameworks have their minds blown at how much easier it is to do the same things? The CSS skill loss is very real, particularly with the number of straight-to-React bootcamps that barely touch on it and the insistence on using CSS-in-JS which makes it way harder for people to explore a production website and learn the fun way. I'm not some HTML/CSS purist, and React was a big step forward for the industry, but now its time is past and we have way better alternatives.

alserio 4y ago

At least in my team the "constrained custom dsl" has been a net productivity win. The only people struggling for a bit were the ones used to react, since they tried to apply react solutions to every problem. It appears you need to unlearn a lot of react when using svelte, so I would argue that it's actually react that wants you do develop in a specific way. The same does not appear to be true for devs coming from other technologies. Other experiences may of course vary.

tobr 4y ago

I think your conclusion in point 2 is misguided, but I can see where you’re coming from. It’s true that virtual DOM has a lot of expressive power, and Svelte’s templating features are more limited in how you can approach certain problems. I find Svelte’s slots especially challenging for more advanced use cases, and wish they were more composable. But in my experience, React’s openness to expressive experimentation is not a net positive for maintainability, productivity, or quality. There are lots of footguns, and bad ideas embraced by the ecosystem. HoCs were a terrible idea, and were replaced with an even worse idea, hooks. Compared to that, Svelte’s reactive statements and stores are a bliss. Arguably, it’s because React has experimented and made those mistakes that Svelte has been able to focus on a constrained DSL that mostly supports the features that are actually a good idea.

peterhunt 4y ago
I think there are two things that are interesting about your point of view. First, I think a mistake the react team made was not exerting more control over the ecosystem. I think a lot of questionable content marketing pieces ended up as “best practices” which we are still unwinding as a community. Second, I totally buy the idea that there are multiple personas and that different tools speak to different personas. The sustained popularity of constrained dsls among subsets of the frontend community speaks to this.
- tobr 4y ago
  But are you against constrained templating DSLs on principle, or just the specifics of how Svelte does it? I think the reason bad ideas take hold is because people are looking for guidance; constraints, if you will. In React that is offered through libraries, frameworks and best practices, but not all of those are good. Svelte has a lot more control of its ecosystem because the constraints are built in to a compiler. And as I said, I think it falls short in certain areas, but all in all I think those restrictions are a net win.
  - peterhunt 4y ago
    I am against constrained DSLs in general unless it buys you something. In the general case, with a DSL you sacrifice expressivity in order to gain security guarantees or improved performance. In this case you are sacrificing expressivity to gain performance but I don't think the performance gains are meaningful enough to be worth sacrificing all of that expressivity. So to answer your question, I am generally opposed to constrained templating DSLs for web frontend applications overall.

satvikpendem 4y ago

Isn't SolidJS supposed to be like React (in that it has JSX, hooks etc) but without the VDOM? So I guess that would sidestep your point #2, but curious to hear your thoughts on it. Personally I don't use Svelte, Vue, Solid etc simply due to the (lack of) library support compared to React. For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparable in the non-React world.

JadedBlueEyes 4y ago
> reached for react-three-fiber, there simply isn't something comparable in the non-React world. This came out a year ago now. https://svelthree.dev/ https://svelthree.dev/ https://github.com/vatro/svelthree https://github.com/vatro/svelthree Svelte, Vue, etc. all have plenty of awesome libraries - you just need to be aware of them.
peterhunt 4y ago
SolidJS also sacrifices expressivity for performance (ie you need to do contortions like this[1] to build dynamic lists), so I prefer React to it. However, I like its approach more than Svelte because there’s less of a DSL to learn. [1] https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_for
leetrout 4y ago
> For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparable in the non-React world. Respectfully, that is because you dont _need_ anything other than ThreeJS in the other frameworks. I do find it interesting that it says it performs faster due to reacts scheduler.
- satvikpendem 4y ago
  > Respectfully, that is because you dont _need_ anything other than ThreeJS in the other frameworks. Not really, ThreeJS is imperative, react-three-fiber is declarative. I use the latter for the same reason I use React over jQuery, I don't have to mess around with appending nodes, I can lay out my view declaratively and have the framework fill in the rest.

ricardobeat 4y ago

> performance that is often not noticeable or is easily achieved with React's memoization features. React was always about enabling front-end engineers to take advantage of software engineering best practices so they could level up velocity and quality I've been working daily with React for almost 6 years now. Another 10+ years of web development before that. And I have yet to see these benefits be realized. It's not easy, at all, to "optimize performance using memoization" in React, best practices are mostly tied to JSX/React and its tooling, not general software engineering, and they change yearly based on the latest version and current third-party library trends. Velocity and quality are both hurt. Your best bet is to use an all-in-one framework like next.js, which delegates most of the pain to the authors - but not all of it. The big improvements that React brought to the mainstream were componentization, and popularizing declarative rendering. I think we have better options today. Svelte does not limit expressiveness in my experience, in fact it makes it way easier to do what you actually want to do, without contorting yourself to the framework. It's liberating. This is a viewpoint I hear frequently though, so it definitely depends on your personal path as a developer and what you've been exposed to.

aidenn0 4y ago

#1 might be true today, but it was definitely not when react was new. I made a fairly simple react site that worked great on my workstation, and then I tried using it on my Android phone and it was unusably slow. Mobile phones have gotten faster, and so have mobile js improvements, so I wouldn't be surprised if it's negligible overhead these days.

HorizonXP 4y ago

As a complete aside, happy birthday bud!

wildermuthn 4y ago

“A constrained DSL” is precisely what is wrong with so many React alternatives. Anyone who had to deal with writing Angular 1 directives and fight with the digest loop understands how very real the pain is. Also, there are two types of performance: how fast code runs and how fast a team can maintain and extend code. Does one optimize for running code or for building code? React won because it optimized for the latter. And thank god, because who wants to mess with digest loops and magical DSLs?