Hacker News Reader

Comment by tomashubelbauer | Hacker News Reader

FWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for React these days and I agree with probably 99 % of it, but the problem in my eyes is not React itself, but the ecosystem that spurred around it. If you stick to just React and take some care with your craft, React is a joy to use IME.

View on HN

Not everything needs to be a SPA. I genuinely believe that the web would've been a much better place today on most important metrics (performance, simplicity, accessibility etc.) if this SPA shift would've never happened. The opportunity cost seems massive to me.

Most software I've used could have been a few hundred lines of PHP. But then they'd be done in like a day, which is great if you're a business owner (and the reason Pieter Levels uses PHP, for example), but not so great if you need to get paid to keep churning the code indefinitely (i.e. most people's situation)... and ideally hire all your friends to help too ;)

There are indeed less user-centric metrics with surprising weight when it comes down to it. I've also noticed that "We read a FAANG blog post and got enchanted" is easily remembered as "Everything was bad and we had to change it all" ;).

I don't find litigating this to be useful or interesting. Debating what is needed could show us lots of things we could cut. But would that bring real gain?

SPA's have really nice performance characteristics. Code is all loaded. The page can transition between states rather than total redraw. A good SPA should offer the same capabilities too, ought have URL routing and good history support.

I do think the web would be faster and simpler without SPAs. But it wouldn't be anywhere near as capable, as interesting, and as loved.

> I don't find litigating this to be useful or interesting.

I think it is useful because our field is woefully inept at anything resembling backtracking, and it's having concrete detrimental effects all over the field by, for example, increasing mountains of bloat eating up hardware improvements.

> SPA's have really nice performance characteristics. [..] A good SPA should offer the same capabilities too

The problem is that not even large teams without any obvious lack of resources are also unable to prevent sluggishness from creeping in to SPAs. So I guess there's a theoretical SPA and a de facto one.

> But it wouldn't be anywhere near as capable, as interesting, and as loved.

Capable sure, if you're creating Google Earth style apps. But when you start using vague and extremely subjective adjectives like "interesting" and "loved" it should be a signal that something's off here.

What you say sounds like we ought have suffocated and starved the web. I feel like "vague" and "subjective" is actually just pretty fucking obvious, didn't need a ton of support for it: the web is the go-to platform for app development because its featureful and works everywhere and is connected by default and nothing else comes close.

The web is where it is (literally everywhere) because it is capable and powerful, and it's because we didn't listen to retrogressive gate keepers insisting the web shouldnt really be for those uses cases.

The alternative to this is nothing. Is to not have had connected software. But we aspired to make great systems. That made some people very mad.

Nothing of that requires SPA, and the alternative is certainly not “nothing”. Not sure how you even get to that conclusion, strange rant. The meaning of alternative cost is not standing still.

> Nothing of that requires SPA, and the alternative is certainly not “nothing”.

Yes actually dev teams did have a massive leap in capability with dynamic HTML & updating the page.

> Not sure how you even get to that conclusion, strange rant.

Not sure how you even can miss that shift, strange miss.

(So, uh, do you always have to be such a deorgatory shit that I have to turn your crap faced mean shit back around? Can you talk like not a flaming shit bag? I don't super love turning your shitty mean crap ass personally aggressive negative worded words back at you, but you just have no vision & are ongoingly a mean shit about everything & so personally shitty about how you phrase things? And you are in such obvious denial. In ways that make zero sense. I don't think anyone sees how the web would grow while meeting your ridiculous constraints and that just seems obvious. Whatever third way you are trying to advocate for is clear as mud. And you cover for saying nothing with aggression! But mostly just stop being such an aggressive ass & engage like you can get over yourself, pull your head out of your ass, stop being a belittling shit, and make a God damned case, rather than throwing endless more empty bile.)

Personally, I like to look at the source for a page. And that, for anything React, winds up being useless (<go-suck-an-egg-because-EVERYTHYING-is-loaded-dynamically/>). I find React very hard to debug whenever anything doesn't work as expected.

I agree with this and consider this to be a massive downside to React.

The react dev tools browser extensions deal with this pretty well. Not sure what the issue is. You can even inspect all the props.

I work on a React based web app in my Day Job and have genuinely enjoyed it.

That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app).

For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been pretty glorious!

I don’t think I’d recommend building a complex web app this way, but for some mild JS interactivity, form submission, etc, handlebars works.

Bonus: I find it much easier to get 100 across the board on Lighthouse scores this way.

> it always feels like so much boilerplate to get up and running for a greenfield project

This is why I love Bun + React. The setup is so easy I can do it off memory. I always hated boilerplate, templates etc. so this is a huge selling point for me.

> and have genuinely enjoyed it.

People who haven't work with other frameworks like svelte, Vue - normally say they are enjoying React.

I wanted to like Vue but when I tried it I didn't. For writing ordinary business applications I wish React reified lists more than it does, but what I like about React is that I know how to draw absolutely anything with it, including 3-d worlds, see

https://aframe.io/

This is a bit reductive.

For what it’s worth, I’ve used Vue and don’t like it (stuff like custom directives that are nonstandard html, not as explicit about event handling and data flow, etc).

I’ve seen a lot of buzz (particularly on HN) about Svelte but have lacked the motivation to try it.

I wish more people would criticise Svelte but most people just don't care because it's irrelevant. It's like complaining about Backbone or something, not worth the effort.

I've tried both and disliked both. Already before I did I was wary of patronizing-feeling statements like these, though. The Vue community in particular, or at least the vocal pockets of it I've come across online, seem like a web dev counterpart to the Rust evangelism strike force.

Vue and Svelte both introduce too much mystery-symbol syntax for my taste, and two way data binding has felt bad since Angular 1.

Hard feelings here. I like react and have to work with it, still it is all insanely wrong.

The best approach I've found so far is egui , and I hope people are moving that direction. Draw whole frame, collect events, process, update internal state.

I came to really appreciate React over time.

My initial objections were: (a) circa 2006 I was making very demanding RIAs such as knowledge graph editors and GIS decision support software and I've yet to see any modern framework that is as good as what I was using then (not in JS but rather GWT and Silverlight w/ the same async comms) and (b) the React model is not a 100% match for the form-based applications that we usually write with it (but boy do I love react-hook-form)

React is like the code in Graham's On Lisp [1] in that functional programming is used to create a sort of DSL. There are a lot of ways to implement reactivity that usually require a special interpreter (spreadsheets) or compiler (Svelte). React's system does show seams (you really need to be on top of identity and equality) but it is remarkably simple.

React shines, in my mind, for things that aren't form applications. For instance, VR applications with AFrame -- it's somewhere between VRML and Unity. I am working on a (mainly) heart rate variability biofeedback application [2] and it is so easy to make dashboards that display real-time metrics as well as Poincare sections and time series. That is, I can slap together a few data processing functions and widgets and make a new dashboard with new metrics and charts or new sensors. One goal is to get it working on a tablet in a two player version.

The disadvantage of React is that it does not work so well for highly dynamic layouts. In my case I have a library of functions to "fetch" the data stream and put them into the top of the component (may even package as hooks) and then put the layout together with JSX. I'd like to have a version where the user can drag and drop the components to make a custom layout and the system figures out the dependencies for the data fetching, preparation and processing like the things I made in 2006 and that kind of application with a dynamic layout (think programs like Photoshop with lots of different little widgets and property sheets) wants a different approach to reactivity.

[1] use of macros in that book is a red herring, the one example in it where you really need macros is when he is implementing cooperative multitasking, a feature that Python and Javascript already have -- most examples from that book as with Norvig's Lisp book can be coded up just fine with

[2] see https://github.com/paulhoule/VulpusVision it might "just work" if you npm install, npm run dev, and look at it in Chrome and connect with a Polar H10 or other BT monitor

Reply on news.ycombinator.com