3 ms·

As a new web developer, where do you draw the line between a web application rendered server side and a SPA? I'm trying to develop a web app for creating invoic

As a new web developer, where do you draw the line between a web application rendered server side and a SPA? I'm trying to develop a web app for creating invoices for a niche market but in this case I don't see huge advantages for a SPA over rendering HTML server side, the added complexity of a SPA doesn't have that big of a reward, I still plan to separate the frontend and backend, for example, writing a HTTP API that outputs json and in another process(or server) consume the json and render HTML in the frontend server (and maybe add some JS to improve interactivity). But everything this days seems about creating SPAs for new apps and that's definitely the future it seems, I'm wrong following this route or is that I'm just consuming to much SPA hype?

mercer 11y ago
Perhaps in the future there will be a time where an 'old-fashioned' server-side app is a bad idea, but right now I think it's still a perfectly valid approach, and even preferable in some cases. Consider whether your app will actually benefit from being an SPA. Does it negatively impact the user experience to have page refreshes? Or does it provide significant benefits to do things client side? If the answer is 'no', you might as well take what is currently still easier and more standardized, and go for server-side. But the next step is to ask these questions about parts of your app. In those cases using React or Vue or something similar for just those parts might be a good idea. And if you've already separated front- and back-end, it shouldn't be too difficult to realize (and it's a good reason to use React server-side even if that's all you use it for initially!).
ohnomrbill 11y ago
I've found that it makes sense to outline what actions it is convenient to view on screen at any given time, and group those things into an app (here, one JS file that is served along with some HTML by the server). So my typical applications have a handful of traditional routes serving HTML and a few small single page apps. To the extent that functionality is shared, I'll create a Clojurescript or Javascript library and reuse it. It keeps JS files small and quick to serve. I've found it to be a good balance between server-side rendering and having a massive SPA.

mercer 11y ago

Perhaps in the future there will be a time where an 'old-fashioned' server-side app is a bad idea, but right now I think it's still a perfectly valid approach, and even preferable in some cases. Consider whether your app will actually benefit from being an SPA. Does it negatively impact the user experience to have page refreshes? Or does it provide significant benefits to do things client side? If the answer is 'no', you might as well take what is currently still easier and more standardized, and go for server-side. But the next step is to ask these questions about parts of your app. In those cases using React or Vue or something similar for just those parts might be a good idea. And if you've already separated front- and back-end, it shouldn't be too difficult to realize (and it's a good reason to use React server-side even if that's all you use it for initially!).

ohnomrbill 11y ago

I've found that it makes sense to outline what actions it is convenient to view on screen at any given time, and group those things into an app (here, one JS file that is served along with some HTML by the server). So my typical applications have a handful of traditional routes serving HTML and a few small single page apps. To the extent that functionality is shared, I'll create a Clojurescript or Javascript library and reuse it. It keeps JS files small and quick to serve. I've found it to be a good balance between server-side rendering and having a massive SPA.