4 ms·

It feels like we're running in circles. We used languages like PHP/Ruby to produce HTML/CSS that browser renders. Then Microsoft introduced XHR. Then we starte

by zmxz 4y ago

It feels like we're running in circles. We used languages like PHP/Ruby to produce HTML/CSS that browser renders. Then Microsoft introduced XHR. Then we started with "saving bandwith" and "page does not to be reloaded" and AJAX was born (although it was Asynchronous HTTP and HTML instead of XML). Then such sites weren't indexed by Google so we started to pre-render content again for the most visited URLs. And now there's so many buzzwords and bland excuses about server side rendering, such as "SSR improves user experience: users don't have to wait for CPU-bound JavaScript to run on the client". JavaScript itself is not what makes websites slow. It's the 50 megabytes of advertising material I've to load from various "content delivery networks" that are everything except fast and auto-play videos that I'm not interested in. Today's personal computers are stupidly fast, smartphones too. There's so little gain in the argument that pre-rendering the first request on the server improves performance while it does nothing for the network-related problems (resolving the domains and transferring so much content). SSR is great, don't get me wrong, but the reasoning that encourages devs to use it is misplaced (not WRONG, misplaced). Yes, it does improve user experience, but it doesn't do so because our computers are slower in parsing and executing JavaScript.

quickthrower2 4y ago
SSR feels like it feels a niche where you have public, dynamic and seo sensitive data. If it is not public (like a web app you log into say canva) then SPA is fine and for most public stuff static pages (generated or cached dynamic pages) are fine.
sdevonoes 4y ago
> SSR is great, don't get me wrong, but the reasoning that encourages devs to use it is misplaced (not WRONG, misplaced). The reason we do SSR is because we want developers to use the same language, libraries and frameworks in the frontend and in the backend. I just don't know which kind of developers are those who cannot bother to learn something else besides JS/TS. I have heard many times the argument "we are saving developer time by using the same technologies everywhere!", but I just don't buy it.
- trinovantes 4y ago
  If you have a monorepo, it is pretty convenient to have synchronized Typescript definitions for communication between frontend/backend because they reference the same file. If you use different languages, then you'll need a translation layer/tool for shared interfaces and that can occasionally desync over time.
  - rad_gruchalski 4y ago
    If you use something else as a source of truth, for example generate your definitions from protobuf or openapi spec, why would it get desynchronised? I’ve done a couple of openapi-based systems recently and it’s a pretty good experience. I can generate server and client stubs next to models in various languages.
    - trinovantes 4y ago
      Not every project needs to use protobuf or openapi. It's an overkill dependency for internal APIs to solve the problem of mismatching interfaces that's easily solved with a shared Typescript file used by both codebases.
      - rad_gruchalski 4y ago
        Assuming that one can afford working with TypeScript on both ends, maybe. But what if you need to support other languages? brew install protobuf && some-proto-gen-wrapper.sh job done.
  - johtso 4y ago
    Even bigger than that is reusing the same validation logic client side and server side.
- dismantlethesun 4y ago
  On the backend, I use Python and C, however rather than use yet another underpowered slow tempting language I opted to use JavaScript for the front end views. We deliver the HTML to the client, hydrate, and everything works seamlessly. Since the static and dynamic views are built from the same code, we never have to worry about any disjunction where they fall out of sync. Also hot reloading a live JS view is a lot faster than restarting the Django server, and refreshing the page. It’s not that the team doesn’t want to learn Mako or Jinja or another language (heck one of our members designed their own language for fun) but it’s simpler and better to use JS. If it was another project maybe the trade offs would work out differently though.
1vuio0pswjnm7 4y ago
To improve user experience, regulate online advertising. Widespread use of ad blockers hints at what users actually want. (Not what developers say they want.) I get the most from the web by using a text-only browser that does not run Javascript. Page retrieval is fast and generally consistent in speed.
eyelidlessness 4y ago
> JavaScript itself is not what makes websites slow It is, but not inherently. Lots of sites are shipping: - far too much of it, even if it’s not in use - wildly inefficient code which blocks unnecessarily - lots of stuff cobbled together from third parties without regard for its impact - far too much on load, both in terms of payload and what gets executed right away This isn’t just advertising materials or whatever. Most of these points are true by default with eg a Next.js site, even if it’s also SSR/SSG.

by zmxz 4y ago

quickthrower2 4y ago

SSR feels like it feels a niche where you have public, dynamic and seo sensitive data. If it is not public (like a web app you log into say canva) then SPA is fine and for most public stuff static pages (generated or cached dynamic pages) are fine.

sdevonoes 4y ago

> SSR is great, don't get me wrong, but the reasoning that encourages devs to use it is misplaced (not WRONG, misplaced). The reason we do SSR is because we want developers to use the same language, libraries and frameworks in the frontend and in the backend. I just don't know which kind of developers are those who cannot bother to learn something else besides JS/TS. I have heard many times the argument "we are saving developer time by using the same technologies everywhere!", but I just don't buy it.

trinovantes 4y ago
If you have a monorepo, it is pretty convenient to have synchronized Typescript definitions for communication between frontend/backend because they reference the same file. If you use different languages, then you'll need a translation layer/tool for shared interfaces and that can occasionally desync over time.
- rad_gruchalski 4y ago
  If you use something else as a source of truth, for example generate your definitions from protobuf or openapi spec, why would it get desynchronised? I’ve done a couple of openapi-based systems recently and it’s a pretty good experience. I can generate server and client stubs next to models in various languages.
  - trinovantes 4y ago
    Not every project needs to use protobuf or openapi. It's an overkill dependency for internal APIs to solve the problem of mismatching interfaces that's easily solved with a shared Typescript file used by both codebases.
    - rad_gruchalski 4y ago
      Assuming that one can afford working with TypeScript on both ends, maybe. But what if you need to support other languages? brew install protobuf && some-proto-gen-wrapper.sh job done.
- johtso 4y ago
  Even bigger than that is reusing the same validation logic client side and server side.
dismantlethesun 4y ago
On the backend, I use Python and C, however rather than use yet another underpowered slow tempting language I opted to use JavaScript for the front end views. We deliver the HTML to the client, hydrate, and everything works seamlessly. Since the static and dynamic views are built from the same code, we never have to worry about any disjunction where they fall out of sync. Also hot reloading a live JS view is a lot faster than restarting the Django server, and refreshing the page. It’s not that the team doesn’t want to learn Mako or Jinja or another language (heck one of our members designed their own language for fun) but it’s simpler and better to use JS. If it was another project maybe the trade offs would work out differently though.

1vuio0pswjnm7 4y ago

To improve user experience, regulate online advertising. Widespread use of ad blockers hints at what users actually want. (Not what developers say they want.) I get the most from the web by using a text-only browser that does not run Javascript. Page retrieval is fast and generally consistent in speed.

eyelidlessness 4y ago

> JavaScript itself is not what makes websites slow It is, but not inherently. Lots of sites are shipping: - far too much of it, even if it’s not in use - wildly inefficient code which blocks unnecessarily - lots of stuff cobbled together from third parties without regard for its impact - far too much on load, both in terms of payload and what gets executed right away This isn’t just advertising materials or whatever. Most of these points are true by default with eg a Next.js site, even if it’s also SSR/SSG.