Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

651–660 of 756 posts

Re: If not React, then what?

#651

Post by hmeh »

gf000 wrote: post #615
hmeh wrote: post #593

Earlier quoted context omitted.

> So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back. "Now" being what specifically? The technologies I mentioned allow everything to happen on the server. We've got a relatively complex set of applications: 30 deployed apps, composition using SSI (server-side include), collaborative form entry for complex form including…

Then every significant (you can get away a lot with very tiny js and/or css, like menus) user interaction will necessarily cause a server round-trip, which is definitely perceptible by humans, no matter how fast your internet is - so it's a bit dishonest to claim that React is "slow". As I said, this is definitely a viable approach, but so is react. Both would fit like 80% of all websites just fine, given that they a…

Human perceptibility is only relevant in certain contexts. Are you in one? Ok, maybe you need client side interactivity. This is what I mean by "highly interactive" applications like Linear, Miro, Superhuman, etc. Having to wait for a server round trip in those wouldn't be good and I would build one of those using an SPA framework/library. This isn't in question.

A forms over data application can be built with React. That's "valid", but what is the cost? The latency in showing/hiding things can be seen with slower internet connections, but so what. What is the cost of that? Have you ever used an air travel booking site? Many of those interactions are painfully slow but you still booked your travel, right? Now take those slow interactions and make them so they are actually just on the edge of human perceptibility (which is easy with server rendering) and you've got a perfectly great experience for your users. If your users are captive (it's their work application, or they need to book travel, etc) then you have even more (but we wouldn't need it) leeway.

If you're a shopping site where revenue is tied latency, maybe it's necessary? But have you used Amazon? There's all sorts of server loading there and they do pretty well.

I'm not claiming that React is "slow". It's slowER on time-to-interactive on average. It can be slower to develop applications. It is certainly more costly from a maintenance perspective due to the unstable nature of JavaScript dependencies.

I'm not going to be able to convince you of any of this. I'm only here holding a sign saying that things aren't as straightforward as they seem. There are costs and costs and costs to this stuff that many see as a normal day in the office.

I'm just saying there's more productivity beyond the horizon, and you're not going to find it by embracing and extending complexity. React is complexity. All the things that come with it to compensate for its complexity are more complexity.

Teams go faster permanently by embracing simplicity. Using React for a forms over data application is the opposite of that. You can do it. You can get your first version out "quick" but over time, that complexity will rear its head and you will slow down.

Have you ever been on a team that wasn't as fast as it was on the first day of a project?

Re: If not React, then what?

#652

Post by eawgewag »

vessenes wrote: post #458
hmeh wrote: post #249

Earlier quoted context omitted.

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 kn…

Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay. I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I h…

I really appreciate this comment. You've very eloquently put into words how I feel about React and the ecosystem, and also my exhaustion towards these "anti-React" posts, which stoke an angry mob without offering obvious alternatives.

And I think the crux of the problem is that there is no obvious alternative. That isn't to say it can't, or shouldn't exist. I'm not a React loyalist. I was a working frontend developer when React came out and I remember how it took the web community by storm, because it was an obvious step forward.

When the alternative exists, it will be as purely obvious.

Re: If not React, then what?

#653

Post by yawaramin »

johnfn wrote: post #463
yawaramin wrote: post #391

Earlier quoted context omitted.

That's the norm in the React world nowadays. You should take a look at https://infrequently.org/2024/08/object-lesson/

This article is better, but has very little to do with React. The major issues I see are 1) loading a 2.5 MB AWS library (not React), 2) not doing SSR (not React) and 3) not tree shaking (not React). I agree these are all problems. But shouting to the skies about React is not going to solve them.

'React' is really just a stand-in for the excesses of client-rendered apps. Do you really think Alex Russell, after writing all these blog posts about the general problem, thinks that React specifically is to blame? Of course not. He is picking it as an example that often causes higher complexity.

Re: If not React, then what?

#654

Post by flimsypremise »

coddle-hark wrote: post #167
flimsypremise wrote: post #134

I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward: • A large portion of the cost of maintaining a code repository goes toward maintaining the build. • Multiple builds per repo create significant costs. • Any web application with a UI _requires_ a frontend build f…

> Any web application with a UI _requires_ a frontend build for CSS/JS. Except it really doesn't. Core web technologies have gotten so much better since the jQuery/pre-SASS days that you can absolutely get by without a build step. - http/2 makes bundling a questionable choice - polyfills are pretty much no longer a thing - CSS now has most (all?) of the features that people used SASS for (variables, nesting, etc.) -…

In web application terms, the "build" is everything that needs to happen to get your application running into production. That means a runtime and dependencies. Speaking of dependencies, does your perfect frontend simply not have any of them? Is every tool you will need to use perfectly packaged with vanilla CSS and ES6 modules? Browser support for import maps is around, but its nothing I would build a production application on. And god help if you if you work in a context that requires support for older browsers.

Maybe in 5 years this will be a practical approach, but there's a reason that old ways of doing thing hang around: they're well-documented and reliable.

Re: If not React, then what?

#655

Post by yawaramin »

kaoD wrote: post #576
yawaramin wrote: post #388

Earlier quoted context omitted.

> Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing. Colour me doubtful. As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM. And no one is going to transfer the DOM into WASM and break every JavaScript app out there.

> As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM. I'm curious, why?

For the same reason that it's not now. It needs to be native on one side and bridged on the other.

Re: If not React, then what?

#656

Post by flimsypremise »

deergomoo wrote: post #267
flimsypremise wrote: post #208

Earlier quoted context omitted.

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…

Nowhere in my comment did I say abandon a build step? I’m saying—if you do not have high interactivity requirements, which I would claim is most things on the web—you will encounter a lot less overall complexity shipping mostly server-rendered pages with isolated, self contained JS bundles where you need them. I was using multi-entrypoint build steps outputting separate per-page or per-feature CSS and JS bundles long…

What's rendering the pages on the server? Because if its not javascript, and you still have a frontend build, you have a repository with two separate builds, and builds are expensive to maintain. If your containerizing, you need two different containers, each with a dependency management system, a runtime, probably a separate workflow for development and production.

There are many ways to render pages on the server using a single JS builds, most template rendering engines have a node implementation, and most javascript frontend frameworks have a mechanism to render components statically to a string. If we're talking about a simple, mostly-static website, the content is going to be cached so the performance of the backend isn't a huge factor. So just use JS for the whole thing, and save yourself a build.

Re: If not React, then what?

#657

Post by flimsypremise »

baggy_trough wrote: post #319
flimsypremise wrote: post #208

Earlier quoted context omitted.

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. This is outdated nonsense for most sites.

What does "most sites" even mean? I do this professionally, and I assume that most of the people replying here do as well. The article we're discussing is written by a professional for an audience of professionals. The number of sites I've had to build that were entirely static with no interactivity I can count on one hand.

Re: If not React, then what?

#658

Post by flimsypremise »

gherkinnn wrote: post #343
flimsypremise wrote: post #208

Earlier quoted context omitted.

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…

> I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler Modern CSS is amazing. Why on earth would anyone use SCSS? It pays to look at what Vanilla can do these days. > Even a "thin" layer of JS on top requires some degree of dependency management Use modules and import away. If it is truly a thing layer, there's no need for further optimisation until far along in the pr…

Modern CSS has _some_ of the features of SCSS/SASS. It does not have all of them. But most importantly, many of dependencies one might want to use also make use of SCSS/SASS downstream. If you're happy to build everything from scratch and eschew any dependencies that require a build system, then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-built component in some frontend library somewhere.

Re: If not React, then what?

#659

Post by flimsypremise »

tmnvix wrote: post #336
flimsypremise wrote: post #208

Earlier quoted context omitted.

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. I sincerely disagree. I am not about to add node to a project that gets by fine with Django + HTMX. I'm tempted to say that adding hundreds of perishable npm packages to a project is a better heuristic for 'malpractice'.

Very funny that you think a build with an entire CMS involved is somehow "simpler". You apparently have a lot of patience for Django's static asset management pipeline, but I do not.

Re: If not React, then what?

#660

Post by hmeh »

eawgewag wrote: post #652
vessenes wrote: post #458

Earlier quoted context omitted.

Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay. I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I h…

I really appreciate this comment. You've very eloquently put into words how I feel about React and the ecosystem, and also my exhaustion towards these "anti-React" posts, which stoke an angry mob without offering obvious alternatives. And I think the crux of the problem is that there is no obvious alternative. That isn't to say it can't, or shouldn't exist. I'm not a React loyalist. I was a working frontend developer…

To be fair, 4 years ago I would have too. The cracks started to show with Phoenix LiveView and turbo and I took a leap of faith on the alternative I describe in my other comments. I haven’t looked back.

I’m not sure I would rely on obviousness. Things are only obvious to the late majority after the innovators and early adopters have moved on. The thing to pay attention to is when people who have extensive experience doing the exact thing you are doing say there’s another way.

The really tricky part here is that that “other way” in this case looks similar to the “old way” and thus is easy to dismiss. It also doesn’t come with any of the dopamine inducing things like hot reloading and really cool tech like virtual dom diffing, etc. in other words, it doesn’t speak to the parts of us that are drawn to the “cool” factor. It’s simple, it’s basic, it’s sometimes tedious, but it’s productive — in the long run.

Post reply on HN