Hacker News Reader

Comment by lominming | Hacker News Reader

I did an evaluation on the various frameworks 2 years ago, and it largely came down to only these 2 choices:

- React (if you want the largest support, packages, community, but sacrifice on performance) - SolidJS [1] (best performance, composability, low-level primitives, but sacrifice on packages/community)

Every other choice like Angular, Vue, Svelte are just somewhere in between these 2 spectrums which I felt was not worth it. Either choose the one with the largest ecosystem or one which has the best primitives & performance.

- React (vdom, slow) (largest ecosystem) - Vue (vdom, faster than react) (large community) - Svelte (fine-grain, faster) (best dx pre-v5) (composability is still not as flexible in v5 compared to SolidJS) (small ecosystem) - SolidJS (fine-grain, fastest, most consistent) (dx similar to react) (small ecosystem)

[1] https://www.solidjs.com/

View on HN

People who love Angular really love it, so I trust that there's a legitimate place for it. I think one of the main things people love is that the convention and tooling eliminates a ton of the noise and redundancy that the other tools tend to lead to as teams slap applications together without sufficient guard rails.

Essentially a lot of the tools we use are only meant to be view layers, and we constantly cobble together supporting layers (models and controllers for example) ad-hoc. Angular handles that off the shelf. I suspect a lot of people are put off by this because it feels imposing and they might not realize they're implementing the same stuff manually, and likely doing it worse.

I used to think it's plain old garbage but realized that's ridiculous. There are reasons people prefer it in some scenarios.

SolidJS is my favourite by a long shot, but I find myself using React because I know so many people I write for and work with are more comfortable with it. I'd be glad to use it more often if it made sense.

I'm currently learning Angular and it's an absolute dumpster fire of a framework in the sense that it offers no clear philosophy. It's just a jumbled mess of concepts and syntax.

I think where it shines though is that it's completely batteries included, which I can see being useful for large enterprises where it's near impossible to change things.

Having recently worked on a very legacy React app, it became apparent to me the value of frameworks like Angular. If you can maintain it and upgrade it gradually, React is arguably the better choice. But if you're leaving it to stagnate, Angular is a far better proposition.

So much of Angular versus React is "No one got fired for picking Google tech" versus "No one got fired for picking Meta tech" with some of the obvious problems of their "parent" organizations' approaches visible in the maintenance efforts.

I think we're on the same page here. I've also found that a non-trivial number of teams actively maintaining React apps are still totally capable of rendering them into a state of dysfunction and paralysis in the same way that stagnating apps can devolve.

They think they don't need batteries included because it's 'bloat' or the opinionated patterns are inferior, but after a couple years they've got a couple dozen seriously bad patterns and a 400kb application that could easily be pared down to 100 or so.

This isn't so much a virtue of Angular or React specifically, but a reality of the deficiencies in our industry when it comes to the human side of the equation. These people would be better off following Angular's general conventions whether they realize it or not.

In all honesty, I think neither one of those are the main measurement you should be using from a business point of view. React has a huge ecosystem, but many packages are out of date or poorly maintained. This means you either still roll your own or you take on the pain of working with the bugs or compat mismatches you inevitably get (looking at you, React 18). On the other end, I would say for the majority of modern web apps, performance doesn't matter too much, so long as it isn't absolutely abysmal. So what are the right metrics, in my subjective opinion? Readability, and by extension refactorability, and ease of iteration. In other words, developer experience, because that will literally save your business actual time and money.

Never met a corporate SPA that didn't have abysmal performance.

That said, framework choice isn't the problem, frontend devs having no clue how to design and use API's is.

Corporations fill their ranks with junior developers, more breaking news at 11.

I remember plenty of multi page applications from big corp that ran like a dead dog too, back in the day. Or ASP sites that wrapped the ENTIRE page in a form, with all of the frustrating complications that entailed.

Hated ASP.Net WebForms over dialup for sure... massive view state, it was a mess.

ASP.NET WebForms is a mess even on localhost.

I think that's what lead into a lot of "Alt.Net" development and tooling... when the blessed ASP.Net MVC came out a lot of the alternatives just died quickly though.

I switched to straight HTML, JS + .ASHX handlers for a lot of things leading up to that point.

I think bringing in component libraries that include the kitchen sink, the farmhouse and the farm... as well as the neighbors farm are a big issue too.

If you really think the performance of the framework is something you need to optimize but want to keep the react ecosystem, you could also use react (or preact) with preact signals which I think should make react perform more like newer frameworks like solidjs in terms of not rerendering entire trees of components unnecessarily.

I'm not sure this is really the first thing that needs to be optimized for most people though, despite there being a lot of frameworks whose sole reason for existence seems to be fixing this aspect of react's performance.

Any slow app would be just as slow if the team had built it using different tech, because it's the design of the software that makes it slow, not the framework.

There is no framework that has a "pit of success" that makes it inherently easy to build a fast app, so any team that uses a framework poorly is just as likely to use a different framework poorly. If they switch and things improve it's probably because the new framework happens to fit their mental model rather than any inherent function of the framework itself.

A good team that designs their code to make the most of a framework could write a good, fast app using any particular tech.

I've spent a lot of time thinking about what the "pit of success" looks like for a framework to make it inherently easy to build a well performing app ("fast" is a different subjective matter), even in some of the worst cases of a naive developer doing naive things. (I think I got really close to a "pit of success" with Butterfloat if you enjoy working with RxJS. Its defaults are tuned for smooth performance even if you are doing too much work in a component.)

There's no framework that has a "pit of success" on every subjective performance quality metric, but I do think some frameworks more than others have larger "pits of failure" that make it too easy to get bad performance even doing what you think is supposed to be the right thing. Because I've vocally picked on it many times at this point, an easy example to mind is Angular's Zone.js is a big opaque library that can accidentally drop you into a "pit of failure" without you realizing how you got there. I'm glad a couple years after I raised some warning flags about Zone.js that Angular is finally addressing that elephant in the room and removing Zone.js as the suggested option and are close to removing it as the default option.

(I'm less glad that the reason that finally pushed them to do that is adding Signals. It seems wild to me to have proper Observables and also Signals and that just seems like another potential pit full of accidentally doing the wrong thing because it looks easy but the interactions between imperative code, Signals, and Observables is going to necessarily be complex and fraught with scheduling problems. I can't say that I'm surprised that Angular development is again moving one step forward while also two steps back at the same time.)

I know others with similar rants about React Hooks and how easy it is to miss needed dependencies in the dependency list of a Hook and too easily fall into a pit of failure.

It is useful to evaluate frameworks with some small eye to "how hard does this make it to do performance right if we follow its 'best practices', even in the case of simple mistakes?"

This seems to completely throw out DX. Svelte is an enormous productivity increase from SolidJS, trading microseconds of performance for that (Svelte is still very fast) does not seem worth it at all. That's like saying your two choices are Python and C, Rust not being worth it.

> That's like saying your two choices are Python and C, Rust not being worth it.

Not a great example since that’s actually why all the other propositioned system language replacements never took off in the way rust did. Rust is (or can be, but importantly, when used idiomatically and not just “in some form”) as fast as C.

There were lots of other languages that tried to replace C with better DX but failed because they weren’t Pareto optimal. So I kind of get GP’s point: DX alone won’t cut it.

> Svelte is an enormous productivity increase from SolidJS

Could you expand on this? SolidJS DX seems pretty great.

I wouldn’t call the ecosystem of svelte small. Since it adheres to HTML and javascript so closely, the effective ecosystem is pretty much the things supporting plain javascript and plain HTML, which is a lot of things.

(Though two years ago I think sveltekit — the app framework for svelte, without which svelte is incomplete for many cases — may not have been quite ready for production, so it was probably fair at the time.)

The value proposition of Vue to me is, “We looked hard at all tools out there, especially react, and iterated on it to make it nicer to use.”

Well TBH svelte works just fine with vanilla javascript libraries, so you could argue that the ecosystem is not as small as you think. Almost every other library/framework in this space requires a wrapper around the vanilla javascript library.

You can make the same argument then for SolidJS. Almost every vanilla JS library works fine with it without a need for wrappers.

> react - sacrifice on performance

Define performance. Comparing render cycles is pointless. A better measure would be Google's web vitals, if you care about user experience.

One of my criteria these days is portability… web components are a frustrating API to use directly but one of the reasons I develop with Svelte is that it can produce web components that, should we pivot frameworks some day in the future, will be able to live inside another framework.

React absolutely fails in that regard. I try not to be a conspiracy theorist but I think React actively avoids web component compatibility as a form of vendor lock in.

React 19 has full support for web components and it scores perfectly on the “does your framework play nicely with web components” test suite whose name I don’t recall.

React 19 release was just postponed to God knows when, the post says.

> best dx pre-v5

Did something bad happen to dx in svelte in v5?

v5 is not even released yet, so I would ignore that statement.

They are moving to "Runes"[0] which IMHO feel clunky compared to previous reactive declarations. There's some perf reasons, but Svelte performance was not an issue for me to begin with.

[0] https://svelte.dev/blog/runes

Bad is subjective too.

There's new syntax for props, reactivity and state that's slightly more complicated for hello world applications but you really notice the differences for even mildly complicated components.

export let foo;

const {foo} = $props()

looks far worse until your doing something like extending an input and you no longer have to deal with $$RestProps ugliness

type Props = {foo: number} & HTMLInputAttributes

const {foo, ...rest} : Props = $props()

does this change at all with react compiler? honest question i dont know

Reply on news.ycombinator.com