> Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.

I can understand the dislike for Next but this is such a poor comparison. If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.

> If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.

This is interesting because every Next/React project I see has a slower velocity than the median Rails/Django product 15 years ago. They’re just as busy, but pushing so much complexity around means any productivity savings is cancelled out by maintenance and how much harder state management and security are. Theoretically performance is the justification for this but the multi-second page load times are unconvincing.

From my perspective, it really supports the criticism about culture in our field: none of this is magic, we can measure things like page-weight, response times, or time to complete common tasks (either for developers or our users), but so much of it is driven by what’s in vogue now rather than data.

+1 to this. I seriously believe frontend was more productive in the 2010-2015 era than now, despite the flaws in legacy tech. Projects today have longer timelines, are more complex, slower, harder to deploy, and a maintenance nightmare.

I'm not so sure those woes are unique to frontend development.

I remember maintaining webpack-based projects, and those were not exactly a model of simplicity. Nor was managing a fleet of pet dev instances with Puppet.

Puppet isn’t a front end problem, but I do agree on Webpack - which is one reason it wasn’t super common. A lot of sites either didn’t try to bundle things or had simple Make-level workflows which were at least very simple, and at the time I noted that these often performed similarly: people did, and still do, want to believe there’s a magic go-faster switch for their front end which obviates the need to reconsider their architectural choices but anyone who actually measured it knew that bundlers just didn’t deliver savings on that scale.

I do kind of miss gulp and wish there was a modern TS version. Vite is mighty powerful, but pretty opaque.

Webpack came out in late 2012 and took a few years to take over, thankfully. I was lucky to avoid it at dayjob™ until around 2019.

I still remember the joy of using the flagship rails application - basecamp. Minimal JS, at least compared to now, mostly backend rendering, everything felt really fast and magical to use.

Now they accomplished this by imposing a lot of constraints on what you could do, but honestly it was solid UX at the time so it was fine.

Like the things you could do were just sane things to do in the first place, thus it felt quite ok as a dev.

React apps, _especially_ ones hosted on Next.js rarely feel as snappy, and that is with the benefit of 15 years of engineering and a few order of magnitude perf improvement to most of the tech pieces of the stack.

It’s just wild to me that we had faster web apps, with better organizarion, better dev ex, faster to build and easier to maintain.

The only “wins” I can see for a nextjs project is flexibility, animation (though this is also debatable), and maybe deployment cost, but again I’m comparing to deploying rails 15 years ago, things have improved there as well I’m sure.

I know react can accomplish _a ton_ more on the front end but few projects actually need that power.

How does Next accomplish more than a PHP/Ruby/whatever backend with a React frontend?

If anything the latter is much easier to maintain and to develop for.

Blazor? Razor pages?

We are having this discussion because at some point, the people behind React decided it should be profitable and made it become the drug gateway for NextJS/Vercel

Worse, because Vercel then started its marketing wave, thus many SaaS products only support React/Next.js as extensions points.

Using anything else requires yak shaving instead of coding the application code.

That is the only reason I get to use them.

They weren't the new shinny to pump up the CV, and fill the Github repo for HR applications.

I sometimes feel like I go on and on about this... but there is a difference between application and pages (even if blurry at times), and Next is a result of people doing pages adopting React that was designed for applications when they shouldn't have.