Hacker News Reader

> Like jQuery before it, React hasn't aged well.

jQuery has aged beautifully!

In case you or anyone else reading don’t realize it, jQuery aged so beautifully the APIs are now built into (or in many cases fixed/standardized in) every browser in C++.

Yes that means the downloadable version is no longer needed, but please keep in mind every time you use a selector (for those that don’t call them “selectors” anymore some basic examples: “#content” or “.dropdown”) in JavaScript, you’re “using jQuery”. Even the fetch API was roughly pioneered by jQuery’s Ajax helpers, and slightly refined and included in every modern browser.

To discredit jQuery for being redundant is exclusively a lack of knowing browser history.

This is a great comment!

Id also add that Jquery's principle of simplifying and making JS accessible is legendary. A junior with a few weeks of Jquery can jump on a legacy codebase without much apprehension.

Thanks for making the record right!

Not to mention in 2022 jQuery is STILL pretty useful and relevant.

> What deep tradeoffs are Solid or Svelte making in exchange for their speed?

For Svelte, the comment you replied to already said that:

> Svelte gets those gains by putting another compiler in your build pipeline, a tradeoff unacceptable to many.

To emphasise, this was also the reason why it took so long for it to get TypeScript support (and I'm still not sure if everything's properly typed now, which is a common problem with template-based languages, but let's assume it is).

Additionally, I think (but haven't worked with Svelte, so could be wrong) that Svelte is a lot harder to write unit tests for? As in, you can just use React's virtual DOM in Node without needing to spin up a browser. With a quick glance I don't see any references to testing in the Svelte docs.

Solid I'm less familiar with, but AFAIK its architecture requires you to put logic back into your templates again, with components like <For>, <Switch> and <Match>, presumably limiting what you can do. And I totally get that the advantages of Solid's architecture make that worth it, but usually, if you can't spot trade-offs in advance, the reason is that you'll run into them later, rather than that there aren't any. So I'm sure I'd find more if I were to actually work with either of these frameworks. And yet I might then still conclude that they're worth it!

I find the granular reactive paradigm of Solid to be both harder to build composable pieces with, and harder to debug in a few ways. Having a render function that re-runs on updates where you can set a debugger or log is a massive thing.

Svelte has a whole host of similar and differing problems.

Personal opinion - I’d choose React today over the rest, as someone who built my own frameworks much like Svelte and Solid 5+ years ago.

I feel React has similar problems as Python, it was here first and thus it has become too ingrained in the culture, too many things were built on top of it. It will take a long time before something comes along that will de-throne them and even then you'll still see a lot of demand for devs who know it because there is too many codebases that people don't want to re-write. I don't think you can say the same thing for jQuery because first of all you couldn't build the same things with it and if you tried you probably hated it enough that you would jump at the chance to re-write your project with something like React.

> it has become too ingrained in the culture, too many things were built on top of it. It will take a long time before something comes along that will de-throne them

The reality is that nobody cares what you use to make your webpage or app. It might take a while to dethrone python and react, but who cares? Make software using whatever tools you want. There's lots of jobs, and these things are super easy to learn anyway.

I'm convinced that half of the jobs listing React are using Svelte or Vue or something, but know they'll get more candidates applying if they hire for react and then just train the person in vue after they start.

> I'm convinced that half of the jobs listing React are using Svelte or Vue or something, but know they'll get more candidates applying if they hire for react and then just train the person in vue after they start.

Easy to convince yourself of this, but in reality what is the benefit of having to sift through even more applications and waste time to go through the processes just to say "oh by the way we don't use React, we actually use Vue, hope that's ok" and think that the candidate, expecting to be hired to do React will just be like "yeah sure no problem, I actually mastered all the frameworks so it's fine that you lied about what you use."

Fantasy land.

You're framing "benefit" as it relates to the hiring process. The main benefit of a better framework or tool is that its a better tool.

But as for your points in hiring -

First, there's no need to lie on a job posting. "We use Vue, but we'll hire people with no vue experience. Show us your react chops and we'll train you up".

Doing something like this will get you fewer, but better candidates. If I see a job posting looking for frontend devs where they use SolidJS, I know the team isn't just a feature factory. They're interested and invested in the search for better ways of working. And I know they're given leave to do so by management. Thats a great sign for a good working culture. And from the other side, the kind of people who apply to jobs like that are the sort of people who don't see programming as a 9-5 grind.

I've seen this play itself out a bunch of times. At a startup I worked at many years ago, we took a chance and built our own data pipeline on top of Operational Transform. So all user data was updated live, character by character in our frontend app. It was really cool tech. We worried it'd hurt our ability to hire but it did exactly the opposite. We ended up putting it front and center in our job ads because high quality applicants were super excited by the opportunity to work on cool technology.

Let's be fair to jQuery: it has served its actual purpose well, and was a huge influence on modern browser APIs, thus making itself redundant. React and jQuery were never competitors.

The same is true of react. Modern web frameworks ooze with lessons learned from React’s design.

jQuery and React are apples and oranges. React was more part of a paradigm shift than a better jQuery.

I agree with you. The paradigm shift is from imperative programming, jQuery, to declarative programming, React. Completely different ways of reasoning about code.

Mixing HTML and JS is also novel to me. I’ve always been taught to separate concerns, only to find myself browsing files all the time. Mixing JSX and JS the sane way makes me feel 20 years younger.

It’s kind of like webcomponents (separate concerns by component, not by language), I wish webcomponents had been part of one of the initial steps of HTML.

Separating concerns is still good. The idea that we can achieve that by writing HTML and JS code in separate files is mistaken, however.

1. The concept of HTML being for layout, CSS for design, and JS for interactivity has not been true ever since web apps became a thing, if it was ever true. It’s been a decade and a half at least since JS wasn’t integral to both layout and design. So separating HTML, JS and CSS into separate files does not actually “separate concerns” because the concerns overlap.

2) Placing in different files is not the only way to separate concerns. You can still separate concerns within your .jsx file. Encapsulate your JSX generation code into a separate function, set of functions, and you can achieve similar separation of concerns, while still keeping code that are intrinsically tied together highly co-located. If you really think that separating them into different files is critical, you can put these JSX generating functions into their own file that can then be imported into your main component file.

The fact that no library/codebase actually does this, indicates to me that separating HTML into a different file provides minimal to no benefit in a component based codebase.

> What deep tradeoffs are Solid or Svelte making in exchange for their speed

I wonder why so many folks care about performance. I guess it's the only objective thing you can throw in someone's face as an argument.

But I think one of the major benefits of Svelte is a better mental model for state management. It hides the right pieces of complexity, while both React and Solid throw them in your face.

> I wonder why so many folks care about performance.

Its been shown repeatedly that application performance dramatically moves the needle on retention, eg [1].

Personally I care about it because using slow software makes me feel like I'm ill. And developing slow software makes me feel like I'm bad at my job.

Your users have spent thousands of dollars buying hardware that can run billions of operations per second. They do that in order to run your software fast. (If they didn't care about performance, they'd be using old hardware.)

Your users didn't spend thousands of dollars buying super fast hardware just to get you off the hook for doing good engineering. Slow software is a sign of sloppy craftsmanship. I hate it.

[1] https://helda.helsinki.fi/bitstream/handle/10138/273640/Mast...

I absolutely despise slow software. But what I meant to say is that performance of modern frameworks is comparable. There's a huge UX difference between 250ms and 500ms page render. Not so much between 25ms and 50ms.

When I'm looking at Svelte or Vue I care about developer experience way more than their performance compared to React.

If performance mattered as much as you're claiming, React would never gain traction. After all, Virtual DOM is pure overhead.

I agree that the performance difference between svelte and vue is negligible most of the time. It might matter more for giant websites - but it’s hard to evaluate that from the microbenchmarks people keep doing.

React’s performance has never been that great. The library is large (a cost you pay for even on tiny websites). Time-to-interactive is quite long. And I can count on one hand the number of times I’ve seen shouldComponentUpdate used in the wild. Most apps just do a full rerender whenever the state changes.

React performs well enough when websites are small, and by the time a website is big, people don’t want to change their framework. The users are asked to put up with vaguely sluggish websites. They often aren’t given a lot of choice.

I think users bounce from websites due to sloppy performance all the time. But dev teams have no idea how much it happens because it doesn’t show up on metrics.

And it’s hard to fix a big, slow react website like new reddit. As they say, you can’t fix a problem with the same thinking that created the problem.

I wonder why so many folks care about owning a fast computer. I guess it's the only objective reason to justify dropping thousands of dollars on a new computer (and ruining the planet) to do the same things they could do on their old hardware, if not for software becoming progressively less efficient.

I took a look at Svelte and I think it is useless. Having a template language i stead of the syntax sugar of jsx/tsx takes the whole thing back at least 10 years (probably more).