3 ms·
> If it's really a web application you're after, then get ready for some complexity. I beg to differ. In many cases it is perfectly acceptable to build a web a
by dom0 10y ago
> If it's really a web application you're after, then get ready for some complexity.
I beg to differ. In many cases it is perfectly acceptable to build a web application with most of the logic in the server, and comparatively little scripting in the client. Not everything has to be a one-page app / SPA with lots of scripting and the complexities of client-side state.
There are also many cases where a SPA is really what is needed and then you indeed need the complexity of a SPA. (And even without being a SPA a frontend has plenty of room for complexity)
tl;dr what I'm trying to say here: Know your requirements.
- dcwca 10y ago> Know your requirements. I agree with you and had my own way of saying it off the top of my post. If your application has a simple data workflow such as "ask server for document, show document" and "store document on server, show new document" then by all means do not build a client-side web application. However, fully reloading a document for interactivity is a very crude model, and doesn't allow for complex interactions, state transitions, offline support, the ability to package your app and deliver it to app stores, and so much more. Additionally, I often see teams who build their UI application directly into the server fail to develop a robust API for 3rd party applications such as mobile apps and data integrations.