[christophilus]

Ah, yes. Everyone’s favorite whipping boy: the front end developers. I don’t think the last decade was a mistake. React (and Preact and similar) are my favorite ways to build out UIs. I prefer it to every other thing I’ve tried— and I’ve tried just about every other thing, including building native UIs for a decade.

It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better.

I hate the poor UX often produced by React— fat, slow, clunky pages with loading spinners and jank. So, I sympathize with the author. I hope something like Quik gets it’s footing.

But until there’s a better way to build UIs from this subjective developer’s perspective, I’m sticking with React.

[Beltalowda]

> It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better.

People have been building UIs for quite a while now; from before a large percentage of people reading this were born. It's not exactly a new thing. I have generally found building UIs a bit painful in any language, so sure, let's go find a better solution, I'm all for that.

But ... 2 weeks ago I took over a half-finished Go project that's been left to "bitrot" for almost 3 years after the previous developer took a different job. Updating the Go dependencies was pretty easy; updating from 1.4.3 to 1.8.9 and such; maybe 1 or 2 with major version bumps, which were minor incompatibilities. Even the usage of the now-deprecated github.com/golang/protobuf wasn't a big deal, and updating to use the new conventions was boring and unexciting, but fairly painless.

The frontend part ... yikes... Things need to be updated from 3.0.2 to 6.8.4 and nothing works if I update it. There are what seem like to be 500 releases in the meanwhile and a lot of changes to go through. It seems in those 3 years the entire world changed. I spent a day on this, and eventually resigned to just accepting the 100+ security vulnerabilities that npm install throws at me. Most, if not all, probably aren't a huge deal in a browser context, but still...

Certainly from my perspective, there seem to be some problems here. I just want to solve real-world problems and write code, not babysit my 1000+ dependencies for what is actually not a very complex project at all. Of course, you don't deal with any of this for new projects, but a 3 year jump really isn't that long of a period. Some churn is expected, but "yeah, maybe just throw a lot of it away and start from scratch"-kind of churn? Meh.

[christophilus]

No argument from me, there.

I’m not going to defend the instability of the rest of the JS ecosystem. It’s totally insane. I try to minimize my deps as much as possible, but even so, they’re in the double digits.

My side project at the moment is a zero-dependency stack.

That said, React itself is pretty stable. My guess is that an upgrade from a 3 year old version would be painless. And I still think React / Preact are the best approach that I’ve found for building UIs. It’s quite painful to go back to templating (ERB or Go templates) by comparison.

[bass3l]

Well, a lot of the “modern” frontend frameworks/libs are having the same symptoms that you describe as the entire world has changed, because it’s actually IS… Good luck working on a two years old Android project where Android Studio won’t even open it.

[Beltalowda]

That sounds like a problem with Android or Android Studio. Two years really isn't that long of a time, and I don't really see anything in the world that really fundamentally changed in that time.

[hombre_fatal]

Client side development isn’t trivial on any platform. Comparing a Go project with a client application just reveals that client apps rot faster because the devices that run them and the software on them are moving targets, esp mobile devices.

[Beltalowda]

Nothing fundamentally changed in the last few years AFAIK. I see no reason why it should rot faster. I've written things over ten years ago that work just fine today.

Client-side JavaScript is actually very compatible; see for example .at() to fix the [] subscripting behaviour (the reason [] wasn't changed was due to compatibility concerns; arr[-1] gets treated as arr["-1"], and changing it may break a script or two).

[Aeolun]

React is the worst form of front-end development. Except for all others.

[cehrlich]

Yeah, I think people who pretend that modern FE is possible without React or another similar framework haven't built a modern frontend and dealt with all the demands for interactivity that users have nowadays and the complexity this brings regarding rendering logic, state, etc.

There's still a time and place for sending HTML and maybe a few tiny JS files down the wire, but for anything "application-like" it's just not feasible, unless your business is so big and performance matters so much that hundreds/thousands of engineering hours are a valid tradeoff to achieve it.

Regarding data loading and performance, there is a lot of exciting stuff in the near future - Remix loaders, Next.js RFC, React 'use' RFC, Quik, Astro, better bundling/build tools, etc.

[Beltalowda]

I've built quite a few highly interactive webapps over the years both with and without "modern FE" (although more without), and I found the more "classic" approaches tend to be quite a bit faster than SPAs, and never really had serious problems with complexity.

I never understood this whole "it is literally impossible to do it without React" (or React alternatives) thing. I've seen it a few times now and it reminds me of 2005 when people were saying it's literally impossible to build any serious program without OOP. I don't really want to have a fight about which approach is "better"; I don't really care, maybe SPAs are better. And if you want to build SPAs then by all means do. If my boss wants me to build an SPA I'll go do it without complaining; maybe not my favourite approach but that's okay. But clearly they're not the only approach that can work well. The insistence that it is, is something I find rather off-putting.

I absolutely think you can do SPAs well; my favourite example is FastMail's web UI, it's pretty good and quite a bit of attention has gone in to various details such as the way the scrollbar/pagination works for large mailboxes. It's just hard to build a good SPA.

I borrowed quite a bit from FastMail's design when we built our own email solution a few years back with a more "classic" server-side templated approach, and I felt the UX was on par, and it was a very manageable project technically.

[thunky]

> all the demands for interactivity that users have nowadays and the complexity this brings regarding rendering logic, state, etc.

Are you sure users are really the ones demanding this?

It's more likely that "modern FE" is imposing this additional complexity on itself for other reasons, because most sites are still boring old crud apps that don't need anything "modern". The canonical example is the Todo app, which is...crud.

I don't think it's the users fault.

[expanseoftrees]

I cannot wait for the next.js rfc. React server components are going to be awesome. You could say they’ve been a decade in the making.

[Existenceblinks]

There are a couple of full-blown text editors written in vanilla js so it's very capable of doing highly interactive.

[cehrlich]

Of course it's _possible_. If you go deep enough, React is just vanilla JS after all. The question is how fast a team can build and maintain something with each method.

[Existenceblinks]

This is what I do. Make the core pattern solid (barely touch this), and extended functionalities in vanilla way; i.e. just write another function receive context and return expected things. You can use solid/uhtml/preact/lit "the view part" they all have it separated from component model. It's 6-8kB (.min). Everything else is just application logic. react-dom is 130kB now and even slower than the rest.

[bayraktar]

I hate my spouse's lousy cooking; the slow, clunky way their hips move when they walk; but most of all, their cringe poetry. But until I find someone better or at least less embarrassing to be seen with in public, I'm sticking with 'em.

OK, so what about Vue.js? Or is it dead to you already?

[nl]

I think you are missing the point.

React/Vue/Angular/Whatever are different flavours of the "framework oriented front end development" thing. Yes there differences in both technices and degree you are forced to use only that framework but the principles are essentially the same.

[bayraktar]

So what other kind of thing do you suggest (and which currently has some traction)?

[berkes]

What about the tried and trusted "have some backend generate HTML and push that to the client"?

It still works for me, has many benefits, and many downsides. But so do the "react-alike" frontend frameworks. There's no silver bullet.

It cracks me up (and makes me sad) to see all the effort going into "hydrating, SSR and whatnots" in JS frameworks, where we move our ball of react-js-spagetti onto some deno-based-edge-function-container thing, in order to serve clients plain HTML... I mean, this problem was solved in 1998 already!

[bayraktar]

Okay, I'm with you - but I meant for, like, people who have some idea of what they're doing (and don't just impulsively reach for a massive framework to deal with routine content dispatch).

What do you suggest for manageable SPA-like development -- for those of us who have actually thought the matter through and have decided that's what we need (at least in certain corners of this otherwise lean and mean, mostly static / old-school website we're building)?

[berkes]

I'm not familiar enough with the current space.

But my preference would be something like: plain old server side rendered HTML with JS that enhances the site, adds some dynamicity etc. But in which a link or button-click usually is just fetching a new page over the wire.

This JS can (also) fetch data over the wire, websockets or such. And I wouldn't even expect it to be some fancy "progressive enhancement" - fine if the web-app doens't work without JS for me.

[nl]

I don't agree with the Twitter thread but the implied alternative is serverside HTML and unclear what is the solution for rapid UX on the client.

[drcongo]

> React (and Preact and similar) are my favorite ways to build out UIs

Sadly, they're not what your users want.