Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes, but all of the React web apps that don’t have a companion mobile app aren’t just cargo culting (but there is a lot of that in the industry). Managing UI state the React way is easier for anything non-trivial. Sure, for forms the web has you covered. But that’s about as far as things go. I remember seeing the small amount of React code required for a typeahead search for the first time and realizing how much more I could now do. The problem is that we have opened ourselves up to all sorts of new troubles by taking on that power. I still wouldn’t go back. But I will complain when some rookie dev makes me download 10MiB of JS to look at a blog.


>we have opened ourselves up to all sorts of new troubles by taking on that power

I guess we'll never know for certain whether we'd have thought SPAs were a good idea in the absence of having reusable APIs hanging around from mobile dev. It certainly made it easier for the browser to talk to the backend.

OTOH, we could just as easily have consumed the API from the app server and continued to render everything server-side. And, as you say, there are serious costs ("troubles") with going the SPA-route.

So, I believe we accepted the pain of SPAs because we thought it was a superior UX. But, I think it was a massive error and the costs have been far too high for the "gain".

There are much easier ways to boost the UX. Examples like typeahead that you mentioned can be just as easily simplified with a standalone JS-lib like typeahead.js. If you add in something like HTMX, it gets even easier to manage the dynamic bits.

Overall, I'd say we could've gotten +80% of the UX gain by sprinkling in dynamic interaction where most impactful, but continuing to render and manage state on the server. I've come to believe that React, Angular, Vue, etc solve a problem that should never have existed.


I think eventually we’ll see a popular framework come around that provides a simpler alternative to React but with optimal ergonomics. For me there’s no going back to the Ruby on Rails world after using Typescript. I’ve used sorbet a bit but I think it’s pretty rough. Someone needs to put together a traditional MVC web framework for Typescript. It won’t be able to do everything that a React app can, but it will handle most needs just fine.


Yeah, there needs to be more emphasis on server-side frameworks in general; preferably, built from the ground up with dynamic front-end interactivity in mind. Maybe they integrate HTMX or similar in a way that allows you to write everything as components or modules that can be seamlessly rendered as a collection in the context of assembling a full page when needed, or individually when a partial/dynamic update is required. So, that code is write-once.

I think these are beginning to emerge. But, bonus points if these were abstracted in a way that it's the same framework (idioms, APIs, etc) and you could just choose your preferred language.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: