23 ms·

> Developing SPAs is easier than server-render applications. Not sure about "easier". I'm a backend person so take this with a grain of salt but, to me, nothin

by trimbo 8y ago

> Developing SPAs is easier than server-render applications. Not sure about "easier". I'm a backend person so take this with a grain of salt but, to me, nothing on the web is easier than doing everything server side. All of your code can be in one language (plus a template) and the same build. Consider what it takes to make a change in each model. In an SPA with one of the frameworks mentioned, it requires several changes, across directories and languages in both the front and back-end, and usually two different build chains.

petilon 8y ago
You have to deal with multiple languages in any case: Java/C#/etc for the server logic, HTML for rendering and CSS for styling. You also have to deal with whatever syntax you are using to embed expressions in the template. If you use SPA there is one additional language (unless you use Nodejs for server logic) that's true. And you also have two different build chains. But the advantage is that the server logic becomes much simpler because you don't need session state or rendering logic. Your server can focus on being a stateless REST service which is more scalable (since you don't have session state clients can connect to a different server on each request). Your server is also more future-proof because it won't need to be rewritten to support native mobile clients.
- fyfy18 8y ago
  > Your server can focus on being a stateless REST service which is more scalable You can do exactly the same with server side rendering. In all the applications I've built over the past decade, the only state I've had is an encrypted session cookie to say which user you are logged in as - but that's send by the browser on each request, so it doesn't matter which server handles it. The urls I've built are basically the same as you would for a REST API, to view a widget you do a GET /widgets/1, to view the form to edit you do GET /widgets/1/edit, to save the update you to PATCH /widgets/1, which redirects you to the list of widgets at GET /widgets. I admit that trying to fit multi-step workflows into this scheme doesn't always fit so nicely, but with good API design (that's what you are building, an API for the browser to call directly without JavaScript) you can make it perfectly stateless.
jamespollack 8y ago
I think that "I'm a backend person" says it all -- most of the people in this thread are probably not JS natives or front-end natives. All of the complaints about JS fatigue, or not knowing how to use client-side routing are because you've done things differently on the backend. Is it such a surprise that front-end frameworks and tools make more sense to people who actually enjoy and have experience working on the frontend? If you provide an API schema, with a SPA the whole frontend can be developed separately of ever touching backend code. Okay, so you changed the name of model.thing to model.anotherThing - quick change in the reducer that is consuming that end point and call it a day.
- deleted 8y ago
  [deleted]

by trimbo 8y ago

petilon 8y ago

You have to deal with multiple languages in any case: Java/C#/etc for the server logic, HTML for rendering and CSS for styling. You also have to deal with whatever syntax you are using to embed expressions in the template. If you use SPA there is one additional language (unless you use Nodejs for server logic) that's true. And you also have two different build chains. But the advantage is that the server logic becomes much simpler because you don't need session state or rendering logic. Your server can focus on being a stateless REST service which is more scalable (since you don't have session state clients can connect to a different server on each request). Your server is also more future-proof because it won't need to be rewritten to support native mobile clients.

fyfy18 8y ago
> Your server can focus on being a stateless REST service which is more scalable You can do exactly the same with server side rendering. In all the applications I've built over the past decade, the only state I've had is an encrypted session cookie to say which user you are logged in as - but that's send by the browser on each request, so it doesn't matter which server handles it. The urls I've built are basically the same as you would for a REST API, to view a widget you do a GET /widgets/1, to view the form to edit you do GET /widgets/1/edit, to save the update you to PATCH /widgets/1, which redirects you to the list of widgets at GET /widgets. I admit that trying to fit multi-step workflows into this scheme doesn't always fit so nicely, but with good API design (that's what you are building, an API for the browser to call directly without JavaScript) you can make it perfectly stateless.

jamespollack 8y ago

I think that "I'm a backend person" says it all -- most of the people in this thread are probably not JS natives or front-end natives. All of the complaints about JS fatigue, or not knowing how to use client-side routing are because you've done things differently on the backend. Is it such a surprise that front-end frameworks and tools make more sense to people who actually enjoy and have experience working on the frontend? If you provide an API schema, with a SPA the whole frontend can be developed separately of ever touching backend code. Okay, so you changed the name of model.thing to model.anotherThing - quick change in the reducer that is consuming that end point and call it a day.

deleted 8y ago
[deleted]