Hacker News new | ask | show | jobs
by protonimitate 1814 days 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.

6 comments

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.

> 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?

>Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale.

What do you mean 'at scale'. It's a UI framework that runs JS and mutates the DOM - there's no issues with 'scale' here.

That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.

>> That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.

This is complete and utter nonsense. Were you programming seriously before React? There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems. As an incumbent it has staying power because there is benefit in sticking with the herd, it remains a pretty nice developer experience, and because it has essential features other frameworks don't really provide yet (React Native being the biggest one although I do realize other frameworks are working on this now too).

Svelt isn't popular because to disrupt a solid incumbent you need something that is dramatically better at solving problems devs actually care about (not corner case performance benchmarks when React is "good enough" 99% of the time). Svelt has failed to do that, plain and simple.

Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community, maybe is a clue as to why Svelt has failed to be sufficiently introspective in either accepting it is a niche framework (which maybe it is great for) or that it needs to change if it wants to be more mainstream.

>This is complete and utter nonsense. Were you programming seriously before React?

Indeed I was.

>There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems.

I'm not saying React isn't a good framework, it is perfectly nice, though I think you're overstating it. AngularJS was a perfectly fine framework as well, and that was out long before React.

>Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community

I'm not part of Svelt's community. I haven't actually used Svelt at all. I barely know about it. But I've been around for a while. Why certain frameworks go viral and others do not, is not always based on merit. I'll buy the argument that Svelt doesn't have enough of a benefit over React ... it also came out a few years later and doesn't have Facebook's marketing weight behind it either. Does that mean React is the best thing ever? Eh, it's alright. Having done everything from Flash/Flex/Starling, to Silverlight, to Backbone, to AngularJS, to React, I actually get more excited about State management patterns than widget overlays with some declarative patterns and data-biding. By the way, when it comes to ergonomics of building complex SPAs, I think we're just hitting the place that Flash/Flex was 15 years ago in Web Development.

I'm not sure I'd agree that when React took over, Angular was a perfectly fine framework. I mean, what happened with React was actually very unusual and remains very unusual. It took over. There is this popular and snarky notion that js devs are constantly chasing every shiny thing but that is exactly the opposite of what has happened over the last several years with React. Instead I'd argue that js devs were nomads prior to React because none of the existing solutions were solving the big problems they had. Not because they are ADD fad chasers. Also I don't remember seeing React "marketing" any more than any other framework. Of course when Google or FB or any other major player gets behind a framework, we take notice, but that doesn't have anything to do with why React took off. It won because frp in a FE framework with the Flux pattern was a total game changer and made FE development awesome for the first time ever (well since Flex, I'll take your word for it since that is even before my time (I cut my FE teeth on jquery and Dojo!))
When React first come out, the whole notion of mixing HTML and Javascript code was, if anything, widely rejected. Rather than going viral as a kind of fashionable thing, I feel that it really had to earn its position.
>When React first come out, the whole notion of mixing HTML and Javascript code was, if anything, widely rejected.

And it still is. Mixing JS and HTML/DOM does result in fragile code and you shouldn't do it. React VDOM and JSX is not the same thing .. at all. Again, JSX isn't new. XML-based declarative UI frameworks with data-biding were an old thing by the time React arrived on the scene. That's how Flash Flex (MXML) and Silverlight (XAML) worked, for example.

Angular was a hot mess and I found it a nightmare to program with.

It basically embodied the bad side of JS frameworks pre-React.

It managed to take alllll the wrong lessons from Flex.

Whichever framework has a prominent PR lead is "safe" to choose. If it's bad or breaks or whatever, it's not your fault, it's... I dunno, the hive-mind's, I guess. It's the "no-one ever got fired for buying IBM" factor. Whether it's actually any good or the best fit for the case it's been selected for, is very much secondary.
"at scale" here means # of contributors, not # of lines or scope of code base.

Svelte vs React on a single side project I work on in my free time by myself is different conversation than Svelte vs React on a team that's moving fast and has more than a single dev.

>"at scale" here means # of contributors, not # of lines or scope of code base.

I understood what you meant, I just disagree that this is a real consideration. Both are just UI frameworks following modern conventions in architecting your SPA code-base. From that point, both are just fine. Other considerations, like the fact that React is more popular and therefore more likely to be supported in the future, and therefore has more devs familiar with it, are way more important.

The scale argument is really just a chicken-and-egg thing. A few years ago, people were saying the same thing about how Vue wasn't "proven" at scale. But these days there are sizable teams using Vue just fine. The entire point of the components-first paradigm is that you can scale a UI fractally.

Large teams were using jQuery back in the day, with none of that HMR prettier-on-save Redux devtools fanciness. There's nothing inherently "unscalable" about the technology, especially now that most frameworks more or less use the same framework design paradigms.

> nothing about has convinced me to lead a project/team towards picking that over React,

This is just a cost of switching consideration. For better or for worse, first movers advantage is a thing. You're also not likely to switch from date-fns to dayjs or postgresql to mysql because you are invested into your choice of technologies, even though each pair might in theory be perfectly interchangeable.

> 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.

Maybe I worded that incorrectly - yes performance is important. But the negligible gains between framework x and framework y are not high on my evaluation checklist, as long as the minimum performance requirement is met (which is often dictated by the product requirements).

I've been working in React for ~4 years now, at all types of scale. While I've definitely seen performance issues, it's never been a case of a flaw in the approach the React takes.

I guess a better way to phrase my point - until I encounter a scenario where the performance is bad enough in React to warrant looking at other frameworks, choosing a framework based on pure performance is an over-optimization.

Of course, this would be a different conversation if React was known for being the one and only bottleneck in web app performance - but afaik that is a rare case.

> Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale.

One of the lead developers of Svelte uses it at the New York Times on some of their high traffic interactive data visualization pages, including their COVID charts.

I'd say that the NY Times is pretty good for "at scale".
Doesn’t the NYT do a lot of React too? From what I read in other comments Svelte was an experiment.

I think what people mean when they say “at scale” is they want to see a large codebase, with a large team working on it, where Svelte is the primary front-end choice.

The creator of Svelte (Rich Harris) works for the NYT. If you ask him, I'd venture to guess he wouldn't say it's an "experiment" as they regularly use it. I doubt his frontend work there is alone too, so I'd guess it's fairly in-use. But again, that's just my guess.