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

No not really.

Yes there are two approaches, but you can switch between the two with 98% of the code intact.




and you have identified the problem. web dev tooling, despite the extreme churn, is still absolutely poo-poo to use the technical term.

of course, mostly because very few oh-new-shiny-woah-such-modern tools doesn't even attempt to solve the problem of backend-frontend state sync. sure, maybe you get a piece of the puzzle (eg. a library that conveniently rerenders on state change, React, or one that you can wire up with all the fancy observables, Angular, or one that's super simple, sleek, even has magical runes that help with only rerendering the things affected by the state change, Svelte ... and maybe on top of these you get a state manager library, and then you still end up writing a thousand mutator/reducer in Redux by hand).

So we are still nowhere near a nice end-to-end full-stack tool that helps model both backend and frontend changes and then helps to design and implement an efficient API between them. (Because, obviously, it seems that this is not obvious to most people. Hence we get solutions like expose your DB as REST API and ship your DB via WASM sqlite, and so on.) That said, even those might be better than one more frontend-only state management lib.


I think you're discounting (1) the fact that there is only one front end runtime, and any number of backend runtimes (2) the application is distributed across a network.

Those are the reasons why SPA and MPA are so different




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

Search: