Hacker News new | past | comments | ask | show | jobs | submit login

>99% of apps are basic CRUD apps

You run into the edges of pure HTML forms on day 1 of the project if you have to listen to any feedback or requests from the users.




So because a few forms need validations you turn your whole application into a JS hellhole?

That's the crux of the issue. It's not that JS isn't needed and small pieces of interactivity aren't nice. But we chose to turn everything into JS despite only really needing it for very small pieces of the app.

Back a few years I'd have small JS bundles included in specific pages that needed interactivity. Later people frowned upon that practice because it meant a ton of requests for the client, so we bundled everything.

Now, new JS frameworks send small JS bundles as you open each page, lol.

Why not have micro React (or whatever framework makes sense) pieces in pages that need it for the interaction?

Plus, server-side form validation is extremely easy to do and also removes duplication. Its been a solved problem for over a decade. I'd even argue back-then it was harder since browsers were much worse and basic elements were lacking. Today you add a `required` attribute in an input and it simply works.

I stand by it. Aside from a few exceptions, most apps have no business being SPAs. They go on to emulate a subpar version of a MPA, and people have to resort to absurdities like these server components to achieve the same experience we've had for 20+ years with server-side rendering.


You can absolutely render react components into non-root nodes to inject interactivity into static sites. It's a good approach if you're serving a bunch of static content and you want a calculator or interactive visualization, for example.

The point at which you should consider a SPA is when you are sharing data between most of the "pages" in your app, and there are multiple data sources surfaced in any given "page." In this case, you're going to have to jump through indexdb/localstorage hoops just to avoid losing that data on every page transition, dehydrating/rehydrating multiple types of records then passing them around via a context or somesuch. In that case you're on the hook for complexity either way, but the SPA version performs better at the cost of some SEO.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: