[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.