If not React, then what? • Hacker News Board

Re: If not React, then what?

#241

Post by hasanhaja » Sat, Nov 30, 2024, 9:34 PM UTC

ht85 wrote: post #165

lucsky wrote: post #153

Earlier quoted context omitted.

So he's basically publishing a 20 pages philosophical logorrhea to make the simple point that developers should pay more attention to the difference between a web SITE and a web APP and choose their stack accordingly, which is a totally fair point to which I 100% agree with. What I fail to see is how React is responsible for any of this because this sort of reads like his wife left him for one of the React engineer o…

Another thing is that almost every complaint I see about React (except bundle size maybe, but who cares?) exists in the APP context. If your use case is a simple website, React is just a nice templating lib and you won't need to use any of the things people generally dislike about it. That AND your experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS. As for the bui…

> is just a nice templating lib

Are these templates only used on the server-side to generate the HTML upfront? Or is it being generated on the client?

> experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS

I don't believe this can quantified. How are you measuring DX improvements? Are you also able to continue to measure these improvements as your application/codebase scales?

Re: If not React, then what?

#242

Post by riku_iki » Sat, Nov 30, 2024, 9:34 PM UTC

quantadev wrote: post #235

riku_iki wrote: post #217

Earlier quoted context omitted.

> In case I was unclear, I consider Angular dead and obsolete. maybe you would expand on this? I have no intention to challenge you, just genuinely curios if and why I should consider vue over agnular for new project (I use angular already).

Maybe Angular is still used a lot, in legacy projects. I just mean for starting a new project, imo most people will choose React or Vue in 2024, right? I never used Angular myself, but have used both React and Vue a lot.

I don't have strong insights about current agnular popularity. I think at least teams/companies which built strong expertise in angular will continue using it for new projects unless there is some big reason not to.

SO trends show that angular is more popular, while vue is loosing share (not necessary absolute number): https://trends.stackoverflow.co/?tags=angular,vue.js,reactjs

Re: If not React, then what?

#243

Post by lihaoyi » Sat, Nov 30, 2024, 9:35 PM UTC

The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish

People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to manage O(n^2) UI state transitions via recursive mutating callbacks. Simple things like "have a the list of photos shown always kept in sync with a label showning count of photos" was incredibly error prone, and the complexity of implementation went up quadratically with the complexity of your app (due to the n^2 state transitions you needed to worry about!)

Today React is not the only one to do this O(^2) to O(n) complexity reduction, but it was the first to go mainstream, and very much deserves its success in spite of its various shortcomings

Re: If not React, then what?

#244

Post by afavour » Sat, Nov 30, 2024, 9:37 PM UTC

satvikpendem wrote: post #236

afavour wrote: post #228

Earlier quoted context omitted.

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…

With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS c…

React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch that allows this to continue but that doesn’t mean it’s healthy.

My main contention with the OP’s point was the assertion that React is almost always the right answer. One of my biggest bugbears about any web dev discussion (particularly on HN) is that everyone treats it as a one size fits all argument and it isn’t.

If you’re making a webapp with interactivity levels like Gmail has then React is a sensible choice. The page reloads very irregularly. But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.

Re: If not React, then what?

#245

Post by hasanhaja » Sat, Nov 30, 2024, 9:37 PM UTC

flimsypremise wrote: post #208

deergomoo wrote: post #147

Earlier quoted context omitted.

I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case. The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively…

Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization…

> Building a web application with a UI in a professional context without a frontend build is borderline malpractice.

Why do you think that? What problem is a build tool solving for you that without it you think you're being irresponsible for not doing it by hand?

Re: If not React, then what?

#246

Post by edflsafoiewq » Sat, Nov 30, 2024, 9:39 PM UTC

mdaniel wrote: post #226

chimpanzee wrote: post #218

Earlier quoted context omitted.

Care to be specific? Is it the documentation you don’t like? Is it the example application’s design you don’t like? Or is it something about Mithril itself?

Two things, in descending order of rage-close-tab for me: that m(.., [m(), m()]) is deeply unserious, and .then((result) => User.list = result) just seems oppressively singleton (although I'm open to that being a tutorialism but why even show users antipatterns if that's not how it's going to work for real?) I tried to be neutral in my reply, so if you like it then I'm glad for you, and I hope your colleagues find ga…

JSX vs hyperscript is a religious issue. You can use JSX with Mithril if you prefer (after all the m() thing is what JSX compiles to).

Re: If not React, then what?

#247

Post by chimpanzee » Sat, Nov 30, 2024, 9:39 PM UTC

mdaniel wrote: post #226

chimpanzee wrote: post #218

Earlier quoted context omitted.

Care to be specific? Is it the documentation you don’t like? Is it the example application’s design you don’t like? Or is it something about Mithril itself?

Two things, in descending order of rage-close-tab for me: that m(.., [m(), m()]) is deeply unserious, and .then((result) => User.list = result) just seems oppressively singleton (although I'm open to that being a tutorialism but why even show users antipatterns if that's not how it's going to work for real?) I tried to be neutral in my reply, so if you like it then I'm glad for you, and I hope your colleagues find ga…

Yes, that whole page you cited is simply tutorialism.

And Mithril supports jsx. (Not to mention the advantages gained by avoiding JSX in favor of hyperscript)

Might be best to actually use it in a small (or large) application of your own design rather than judging prematurely.

(I’m not suggesting large orgs use Mithril, as other commenter mentioned, community in some situations is more important than the tooling. But “building a web app” does not necessarily imply “employing a team of local developers to build a web app asap for less than x usd”.)

Re: If not React, then what?

#248

Post by michaelcampbell » Sat, Nov 30, 2024, 9:40 PM UTC

afavour wrote: post #228

johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…

Reacting to assertions of broad averages with specific counter examples doesn't necessarily invalidate their point.

Re: If not React, then what?

#249

Post by hmeh » Sat, Nov 30, 2024, 9:42 PM UTC

johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief.

Likely many developers don’t even know how to build something without React. They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along and its siren song drew away many developers, and, worse, created an entire generation that fits the criteria I’m describing.

The author doesn’t need to describe an alternative any more than he did, because the alternative is supposed to be self-evident. If it’s not, the person is supposed to take the plethora of breadcrumbs in the article and figure out how we used to do things before bloated, convoluted, and typically unnecessary frameworks.

When you look at something like Remix and Next you see people trying go back to the simple (forms, server rendering) by adding additional complexity. It’s doubling down on complexity, rather than finding simplicity.

Re: If not React, then what?

#250

Post by afavour » Sat, Nov 30, 2024, 9:42 PM UTC

michaelcampbell wrote: post #248

afavour wrote: post #228

Earlier quoted context omitted.

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…

Reacting to assertions of broad averages with specific counter examples doesn't necessarily invalidate their point.

OK, let me restate something from my previous component explicitly: a site that’s concerned with SEO is not a “specialized domain”. It is very, very common.