5 ms·

The main problem with SSR is that the moment you want to do something a little bit outside of the-happy-path of your framework o choice, you're knee deep into s

The main problem with SSR is that the moment you want to do something a little bit outside of the-happy-path of your framework o choice, you're knee deep into sh. Let me give you the simplest possible example. A form with multi-dependant inputs: you select an option from a dropdown, and depending of the choice you made, you see another dropdown with some options, or maybe an entire new set of inputs. Maybe there is a button that will open a popup with another form, dynamically generated based on what you choose. Or maybe there is data you must dynamically fetch from the server, based on some combination of actions that the user did. You can play the ".show()" and ".hide()" game with plain JS, but if you have more than 5 inputs, I promise you, you'll be really sorry for choosing that method. You can also "inject" somehow any SPA just into that particular view in your project, but then you'll be already dealing with the cons of both SPA and SSR. It doesn't pay off. I have been doing all types of FE and BE development, and what has given me the best results is making the BE a REST API and doing the rendering on the frontend. Just my 2 cents.

save_ferris 8y ago
This is where the hybrid approach they mention in the article really shines. Embed front end frameworks where you need it, and stick to SSR where you don't. It doesn't have to be a binary choice.
- alexandernst 8y ago
  Yes, that's what I said in my comment. But if you choose that path, you automatically have to deal with the problems from both worlds. "How do I configure webpack?", "Why is babel not working?", "How do I do _this_ or _that_ in React or Vue or whatever?". Going the hybrid approach is choosing to deal with the problems from both worlds.
  - save_ferris 8y ago
    But configuring webpack is usually just an initial set-up cost. I've never had to go back and rejigger webpack once it's set up. You might have to touch it again if you make major changes to how you serve assets or something, but these one-time costs are part of development. > Going the hybrid approach is choosing to deal with the problems from both worlds. This is true of any technology. Every framework, language, library, etc. comes with a cost in setup, design, maintenance, etc. For us, the cost of dealing with problems from both worlds is much, much lower than trying to shoehorn a SSR app with SPA-like functionality. By limiting the size and scope of the SPA, you avoid a lot of the really hairy state management problems that can arise when an SPA is trying to keep track of too much state.

save_ferris 8y ago

This is where the hybrid approach they mention in the article really shines. Embed front end frameworks where you need it, and stick to SSR where you don't. It doesn't have to be a binary choice.

alexandernst 8y ago
Yes, that's what I said in my comment. But if you choose that path, you automatically have to deal with the problems from both worlds. "How do I configure webpack?", "Why is babel not working?", "How do I do _this_ or _that_ in React or Vue or whatever?". Going the hybrid approach is choosing to deal with the problems from both worlds.
- save_ferris 8y ago
  But configuring webpack is usually just an initial set-up cost. I've never had to go back and rejigger webpack once it's set up. You might have to touch it again if you make major changes to how you serve assets or something, but these one-time costs are part of development. > Going the hybrid approach is choosing to deal with the problems from both worlds. This is true of any technology. Every framework, language, library, etc. comes with a cost in setup, design, maintenance, etc. For us, the cost of dealing with problems from both worlds is much, much lower than trying to shoehorn a SSR app with SPA-like functionality. By limiting the size and scope of the SPA, you avoid a lot of the really hairy state management problems that can arise when an SPA is trying to keep track of too much state.