8 ms·

I couldn't disagree with this article more. Developing SPAs is easier than server-render applications. The problem is React, Redux, and other such libs make thi

I couldn't disagree with this article more. Developing SPAs is easier than server-render applications. The problem is React, Redux, and other such libs make this more complicated than necessary. React is all about surgically making the smallest possible change in the DOM to refresh the page. But is that really needed? Most of the time it is not. Why not re-render the whole page? This is what happens in the case of server-render applications any way, right? Turns out 99% of the time it is performant for the SPA to rerender the whole page. Instead of Angular and React, if you use simple libraries such as UIBuilder ( https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder ) and MVC router ( https://github.com/Rajeev-K/mvc-router/ https://github.com/Rajeev-K/mvc-router/ ) you can build simpler applications that work well and are super easy to develop and maintain. Each of those libs is less than 500 lines, so super easy to learn and use. This article says traditional web servers are stateless, but in the case of SPAs servers are stateful. The opposite is true. Traditional web servers have session state, but in the case of SPAs the servers can be stateless because all servers are responsible for is persistence and query/search. This article says maintaining browser history is a mess in SPAs. Not true. The same MVC architecture that works so well on the server can be done just as easily on the client, see this lib: https://github.com/Rajeev-K/mvc-router/ https://github.com/Rajeev-K/mvc-router/ This article says server-rendering has fewer more mature tools. That may be true. There are so many new tools for SPAs. But you can ignore them and build SPAs trivially using the libs mentioned above. This article says server-rendering is better for SEO. Not true anymore. Google and Bing crawlers now execute javascript to crawl your content. This is more work for Google and Bing but not more work for you. If you know how to do it SPAs are the easiest and best approach because all the server needs to do is implement persistence and query/search using a REST API. If you later need a native mobile client this approach is already more compatible with mobile than if the server renders HTML in addition to persistence and query/search.

s_y_n_t_a_x 8y ago
You don't need React, Redux, and other such libs, true. But you're missing the point of them. It's to prevent the problems that cropped up after years of jQuery development. Too many side-effects and poor state management lead to very hard to find bugs. When you follow the redux (or whatever state lib) flow you prevent a lot of these issues.
- petilon 8y ago
  React, Redux and other such libs solve the problem while overcomplicating the programming model. My point is that 99% of applications don't need the complexity introduced by surgically making the smallest possible change in the DOM to refresh the page. There are simpler libs out there that eliminate 99% of the complexity of React, Redux etc while providing 99% of the benefits.
  - s_y_n_t_a_x 8y ago
    You don't get much simpler than Redux. And React by itself is very simple, you don't even have to use JSX. It's a great templating library, with great documentation and a huge community.
    - petilon 8y ago
      >You don't get much simpler than Redux. Not true. With Redux you write reams of actions and reducers and other such unnecessary crap in the name of state management, when in fact most client apps don't have state, all they do is fetch data from the server, display it, send updates back to the server. React used to be a simple lib, now it is getting more and more complicated. Look at the libs I mentioned they are way simpler. >you don't even have to use JSX But JSX is the good part of React. You get compile-time checking of your expressions if you use TypeScript and you get syntax coloring, intellisense etc for both HTML and JavaScript.
      - s_y_n_t_a_x 8y ago
        If you don't need state, don't include it. That's the beauty of React. But as far as a state management lib goes, Redux is one of the simplest, go look at the source. I agree JSX is very nice. It's one of the best features of React, and another reason React is a great templating lib. My point was you don't need it. React does a lot of other nice things like browser compatibility, event management. If you want a smaller implementation, use preact or some other template lib. When dealing with React and Redux you are just dealing with functions. You could do everything in pure functions.
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.
- 8y ago

s_y_n_t_a_x 8y ago

You don't need React, Redux, and other such libs, true. But you're missing the point of them. It's to prevent the problems that cropped up after years of jQuery development. Too many side-effects and poor state management lead to very hard to find bugs. When you follow the redux (or whatever state lib) flow you prevent a lot of these issues.

petilon 8y ago
React, Redux and other such libs solve the problem while overcomplicating the programming model. My point is that 99% of applications don't need the complexity introduced by surgically making the smallest possible change in the DOM to refresh the page. There are simpler libs out there that eliminate 99% of the complexity of React, Redux etc while providing 99% of the benefits.
- s_y_n_t_a_x 8y ago
  You don't get much simpler than Redux. And React by itself is very simple, you don't even have to use JSX. It's a great templating library, with great documentation and a huge community.
  - petilon 8y ago
    >You don't get much simpler than Redux. Not true. With Redux you write reams of actions and reducers and other such unnecessary crap in the name of state management, when in fact most client apps don't have state, all they do is fetch data from the server, display it, send updates back to the server. React used to be a simple lib, now it is getting more and more complicated. Look at the libs I mentioned they are way simpler. >you don't even have to use JSX But JSX is the good part of React. You get compile-time checking of your expressions if you use TypeScript and you get syntax coloring, intellisense etc for both HTML and JavaScript.
    - s_y_n_t_a_x 8y ago
      If you don't need state, don't include it. That's the beauty of React. But as far as a state management lib goes, Redux is one of the simplest, go look at the source. I agree JSX is very nice. It's one of the best features of React, and another reason React is a great templating lib. My point was you don't need it. React does a lot of other nice things like browser compatibility, event management. If you want a smaller implementation, use preact or some other template lib. When dealing with React and Redux you are just dealing with functions. You could do everything in pure functions.

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.
8y ago