5 ms·

I can't say I fully comprehend the SSR vs SPA war. Both concepts are definitely being misused/overused, one is "dated" and the other "modern", but surely the mi

I can't say I fully comprehend the SSR vs SPA war. Both concepts are definitely being misused/overused, one is "dated" and the other "modern", but surely the middle ground where best usage of both can be attained is prefered. I don't know of any terms that mediate the opposition other than perhaps "hydration"?

sam0x17 8y ago
This is the key. There are super developed SSR frameworks and super developed SPA frameworks, but getting the two to work together is like pulling teeth. No one tries to write an SSRSPA framework because that would be considered too "opinionated", but maybe that's exactly what we need.
- friedman23 8y ago
  Ok, I was confused by your comment and the other person's comment. SSR and SPA are not mutually exclusive things.
  - sam0x17 8y ago
    They aren't mutually exclusive, but they are either a) at odds with each other because the frontend is in javascript and the backend is in Rails or Python or something else, or b) completely in sync because the backend and front end is in javascript, but terrible because the backend and the front end is in javascript. With web assembly on the horizon we will soon have Rust/Crystal/Go-driven unified backend+frontends, and then we can finally exit this dark age of JS being the only front end language.
    - friedman23 8y ago
      As someone that prefers python it is unfortunate that the only way to get SSR is to commit to JS but with web assembly I think we will eventually have tools such as React and Redux be translated to other languages. As far as performance goes js isn't too bad. It's async by default and a lot of effort has gone into making it run fast.
      - sam0x17 8y ago
        Yeah I actually have few problems with js itself. It's npm and this tendency to have a million 3 line dependencies. In, for example, the ruby gems ecosystem, there just isn't that problem.
    - goliatone 8y ago
      I have not had the chance yet to play with it but it’s very high in my list, drab an extension library for the Phoenix framework “providing an access to the browser's User Interface (DOM objects) from the server side”. A friend did an experimental library way back using server sent events for the Yii framework. I don’t think I fully appreciated the idea back then. Admittedly Elixir seems a better fit for this pattern than PHP tho https://tg.pl/drab https://tg.pl/drab
- kraftman 8y ago
  Doesn't nextjs do this already? You write an SPA that nextjs implicitly also knows how to render server side
  - leetbulb 8y ago
    Yeah, that's essentially the purpose of Next.js and it does it very well.
- btmorex 8y ago
  If you're using node.js and redux, then https://github.com/faceyspacey/redux-first-router https://github.com/faceyspacey/redux-first-router pretty easily gets you there. Other than turning route changes into redux actions, I don't find it particularly opinionated.
- jotto 8y ago
  I made https://www.roast.io/ https://www.roast.io/ because of this. Most of the current SPA frameworks can re-hydrate SSR'd JS without issue, so instead of configuring SSR, just use a headless browser, which is what Roast does.

sam0x17 8y ago

This is the key. There are super developed SSR frameworks and super developed SPA frameworks, but getting the two to work together is like pulling teeth. No one tries to write an SSRSPA framework because that would be considered too "opinionated", but maybe that's exactly what we need.

friedman23 8y ago
Ok, I was confused by your comment and the other person's comment. SSR and SPA are not mutually exclusive things.
- sam0x17 8y ago
  They aren't mutually exclusive, but they are either a) at odds with each other because the frontend is in javascript and the backend is in Rails or Python or something else, or b) completely in sync because the backend and front end is in javascript, but terrible because the backend and the front end is in javascript. With web assembly on the horizon we will soon have Rust/Crystal/Go-driven unified backend+frontends, and then we can finally exit this dark age of JS being the only front end language.
  - friedman23 8y ago
    As someone that prefers python it is unfortunate that the only way to get SSR is to commit to JS but with web assembly I think we will eventually have tools such as React and Redux be translated to other languages. As far as performance goes js isn't too bad. It's async by default and a lot of effort has gone into making it run fast.
    - sam0x17 8y ago
      Yeah I actually have few problems with js itself. It's npm and this tendency to have a million 3 line dependencies. In, for example, the ruby gems ecosystem, there just isn't that problem.
  - goliatone 8y ago
    I have not had the chance yet to play with it but it’s very high in my list, drab an extension library for the Phoenix framework “providing an access to the browser's User Interface (DOM objects) from the server side”. A friend did an experimental library way back using server sent events for the Yii framework. I don’t think I fully appreciated the idea back then. Admittedly Elixir seems a better fit for this pattern than PHP tho https://tg.pl/drab https://tg.pl/drab
kraftman 8y ago
Doesn't nextjs do this already? You write an SPA that nextjs implicitly also knows how to render server side
- leetbulb 8y ago
  Yeah, that's essentially the purpose of Next.js and it does it very well.
btmorex 8y ago
If you're using node.js and redux, then https://github.com/faceyspacey/redux-first-router https://github.com/faceyspacey/redux-first-router pretty easily gets you there. Other than turning route changes into redux actions, I don't find it particularly opinionated.
jotto 8y ago
I made https://www.roast.io/ https://www.roast.io/ because of this. Most of the current SPA frameworks can re-hydrate SSR'd JS without issue, so instead of configuring SSR, just use a headless browser, which is what Roast does.