7 ms·

I can't wait for server-side rendering to take its place in the sun again. There are many use cases for which a client-side framework like React is eesential.

I can't wait for server-side rendering to take its place in the sun again. There are many use cases for which a client-side framework like React is eesential. But I feel the vast majority of use cases on the web would be better off with server-side rendering. And... There are issues of ethics here. You are kidding yourself to an extent when you say that you are building a "client-side web app." It is essentially an application targeted at Google's application platform, Chromium. Sure, React (or whatever) runs on FF and Safari too. For now. Maybe not always. They are already second-class citizens on the web. They will probably be second-class citizens of your client-side app unless your team has the resources to devote equal time and resources to non-Chromium browsers. Unless you work in a large shop, you probably don't. Server-side rendering is not always the right choice, but I also do see it as a hedge against Google's, well, hegemony.

untog 6y ago
I think there's a lot of truth in what you're saying and the core problem is that we somehow decided there was one correct way to make a web site, and that was to use React. Are you creating a complex webapp? Use React. Go nuts! But are you making a mostly static page (blog, marketing site, whatever)? Then don't use React. It adds entirely unnecessary bloat and complication.
- gpapilion 6y ago
  The industry has gone back and forth here forever between thick and thin clients, and I view this as an extension. Largely we all use thick clients now (PCs, phones, and things with way too much compute power), and the move to chrome or chromium based browsers made the behavior predictable. The pendulum swinging back is really an acknowledgement that the advantages provided client side rendering, don't always outweigh the networking costs. Data visualization is one of these areas I wonder if the javascript methods provide a real advantage vs server side rendering.
  - zozbot234 6y ago
    Except that phones have only gotten thinner and thinner since the 1990s... And PC's (laptops, at least) are not far behind.
    - alphazino 6y ago
      https://wikipedia.org/wiki/Thin_client https://wikipedia.org/wiki/Thin_client https://wikipedia.org/wiki/Fat_client https://wikipedia.org/wiki/Fat_client
- jacobr 6y ago
  If I only evaluated our tech stack on a pure “what’s the most efficient way to deliver HTML to the user” I’d not choose React, but I don’t know of any other framework that ticks the other boxes required in a large organization. - Code sharing - how do you share reusable snippets of code that includes both the SSR logic and the JS that is also required on the frontend. React’s component model is fantastic where a team can develop a component independently - Skill set - getting 50 React developers to write HTML and JS should be fine if other problems were solved, but often the suggested solution is obscure things like Elm or Elixir - Even if most of what a company builds is static marketing content, other parts can be more app-like and having developers be able to share code and use the same basic technology is a great productivity booster
tpmx 6y ago
Back in the 90s I was working on a commercial server-side rendering "content management solution". Revision control and team workflow (with quite nice conflict resultion UIs). Templating using XSLT (sadly, because it's insane). Super expressive and solid stuff in general though. We used the actual cvs binary as a version control backend. I left this part of the business space for the browser business at this time, but I assumed that the server-side rendering stuff would keep evolving. It didn't. Then the "PHP CMS" wave came, and dumbed everything down. Then the "reduce the server to an API" and "let insanely complex javascript frameworks/apps deal re-invent the browser navigation model" came... and here we are.
- techhackblob 6y ago
  It's been a ride watching all this abstraction and design patterns make everything more complex
Polylactic_acid 6y ago
The less stuff on the server the better imo. Whenever I can get away with it I use a static site generator or I use vuejs with a json file containing all the data for the site. Being able to just drop a static set of files in to a webserver without any risk of security issues in my code is great. I also hate the tools for backend rendering since if you need any kind of interactivity it becomes so much easier if you had just built it all in vue/react with no downsides other than not running in someones cli web browser.
- lawn 6y ago
  Phoenix LiveView gives you excellent interactivity with backend rendering.
  - JohnBooty 6y ago
    I desperately want to check that out when I have some free time. (In other news, I would desperately like some free time)
    - ksec 6y ago
      There are quite a few others inspired by Liveview. On ASP.Net , PHP Laravel, Python Django and Stimulus Reflex on Ruby Rails.
- djhaskin987 6y ago
  At my old company they were moving from client-side to server side because they had 30 different clients -- Roku, desktop, smartphone, Xbox, etc. -- and all of them had to reproduce the same logic. At the time I left they were trying to centralize all of that logic on the server and then just put the lipstick on the pig at the end.
- y-c-o-m-b 6y ago
  > I use vuejs with a json file containing all the data for the site Seconded. It makes hosting a breeze; especially when you can just throw it on GitHub Pages within minutes. I also like being dependent on only a text editor and a browser ... a combo still performant on just about any device from the last 20 years if not longer. No need to install full-featured IDEs and the various dependencies.
deleted 6y ago
[deleted]
bob1029 6y ago
I am aggressively pursuing a universal 100% server-side UI framework (not just targeting the web). If AMD has demonstrated anything to me, it's that the server is the place to do as much work as you can. Offloading work to client devices feels like stealing to me at this point. Websites are very abusive with your resources.
- chooseaname 6y ago
  > Offloading work to client devices feels like stealing to me at this point. Kinda is. It makes my mobile work harder and thus uses more battery.
rudolph9 6y ago
https://nextjs.org/ https://nextjs.org/ is a react wrapper framework that has some nice SSR features. It makes a ubiquitous dev experience where the majority of the app can be rendered server or client side. Last time I worked with it about a year ago it was only the first page load that was rendered server side though but the first one the one that arguably affects the user experience the most.
- pdxandi 6y ago
  I love ️Vercel (formerly nextjs). It's such a great platform and their free tier services do a lot of the heavy lifting of configuring a website and managing deployments.
  - Kingdutch 6y ago
    Slight correction to avoid confusion between Open Source product and PaaS(?) company in people's searches: Next.js the product is still named Next.js. The company behind it, Vercel was formerly Zeit :) Their command line tool "Now" has been renamed to Vercel
- deleted 6y ago
  [deleted]
- DrFell 6y ago
  Despite the literal phrasing, server-side rendering, as in SSRing a SPA, is not even close to what was happening in the 90's. That was much simpler, pure, and fun.
peruvian 6y ago
There’s an exponentially growing recruiting, training, and hiring industry based on developers who only know how to write fat JS frontends. I think everyone has probably experienced high growth in their company’s frontend team. Many developers choose to write them not out of expertise but to have them in their resume and for job security.
- arcturus17 6y ago
  Many of us also choose to write it because it’s fun and the results can be excellent.
  - esperent 6y ago
    Nobody denies React and co. are excellent tools. The frustration occurs when people who enjoy these tools claim that, if you choose not to use them, or suggest they're not fit for a certain task, you're WRONG. In the case of React in particular, this happens a lot. Then of course the people who don't want to use a framework feel frustrated, and next thing you know it's a flame war. I've seen this happen multiple times on Twitter.
    - iphone_elegance 6y ago
      I run into very few people who claim this.. oh you mean on Twitter? well there's the problem.
      - esperent 6y ago
        Twitter is where a large percentage of web devs hang out. If something is problematic, you can't dismiss it as "but that's just Twitter". If it's a common mode of discourse on Twitter, then it's legitimately a part of developer culture. In any case, discussions around front end frameworks and especially React are scarcely any better here. Although they are usually politer at least.
        globular-toast 6y ago
s_y_n_t_a_x 6y ago
React isn't bound to web, there's quite a few React Native targets (ios, android, macos, windows, qt, gtk) I recommend React when making an app, web or otherwise. I recommend vanilla HTML + CSS with optional JS when making a website.

untog 6y ago

I think there's a lot of truth in what you're saying and the core problem is that we somehow decided there was one correct way to make a web site, and that was to use React. Are you creating a complex webapp? Use React. Go nuts! But are you making a mostly static page (blog, marketing site, whatever)? Then don't use React. It adds entirely unnecessary bloat and complication.

gpapilion 6y ago
The industry has gone back and forth here forever between thick and thin clients, and I view this as an extension. Largely we all use thick clients now (PCs, phones, and things with way too much compute power), and the move to chrome or chromium based browsers made the behavior predictable. The pendulum swinging back is really an acknowledgement that the advantages provided client side rendering, don't always outweigh the networking costs. Data visualization is one of these areas I wonder if the javascript methods provide a real advantage vs server side rendering.
- zozbot234 6y ago
  Except that phones have only gotten thinner and thinner since the 1990s... And PC's (laptops, at least) are not far behind.
  - alphazino 6y ago
    https://wikipedia.org/wiki/Thin_client https://wikipedia.org/wiki/Thin_client https://wikipedia.org/wiki/Fat_client https://wikipedia.org/wiki/Fat_client
jacobr 6y ago
If I only evaluated our tech stack on a pure “what’s the most efficient way to deliver HTML to the user” I’d not choose React, but I don’t know of any other framework that ticks the other boxes required in a large organization. - Code sharing - how do you share reusable snippets of code that includes both the SSR logic and the JS that is also required on the frontend. React’s component model is fantastic where a team can develop a component independently - Skill set - getting 50 React developers to write HTML and JS should be fine if other problems were solved, but often the suggested solution is obscure things like Elm or Elixir - Even if most of what a company builds is static marketing content, other parts can be more app-like and having developers be able to share code and use the same basic technology is a great productivity booster

tpmx 6y ago

Back in the 90s I was working on a commercial server-side rendering "content management solution". Revision control and team workflow (with quite nice conflict resultion UIs). Templating using XSLT (sadly, because it's insane). Super expressive and solid stuff in general though. We used the actual cvs binary as a version control backend. I left this part of the business space for the browser business at this time, but I assumed that the server-side rendering stuff would keep evolving. It didn't. Then the "PHP CMS" wave came, and dumbed everything down. Then the "reduce the server to an API" and "let insanely complex javascript frameworks/apps deal re-invent the browser navigation model" came... and here we are.

techhackblob 6y ago
It's been a ride watching all this abstraction and design patterns make everything more complex

Polylactic_acid 6y ago

The less stuff on the server the better imo. Whenever I can get away with it I use a static site generator or I use vuejs with a json file containing all the data for the site. Being able to just drop a static set of files in to a webserver without any risk of security issues in my code is great. I also hate the tools for backend rendering since if you need any kind of interactivity it becomes so much easier if you had just built it all in vue/react with no downsides other than not running in someones cli web browser.

lawn 6y ago
Phoenix LiveView gives you excellent interactivity with backend rendering.
- JohnBooty 6y ago
  I desperately want to check that out when I have some free time. (In other news, I would desperately like some free time)
  - ksec 6y ago
    There are quite a few others inspired by Liveview. On ASP.Net , PHP Laravel, Python Django and Stimulus Reflex on Ruby Rails.
djhaskin987 6y ago
At my old company they were moving from client-side to server side because they had 30 different clients -- Roku, desktop, smartphone, Xbox, etc. -- and all of them had to reproduce the same logic. At the time I left they were trying to centralize all of that logic on the server and then just put the lipstick on the pig at the end.
y-c-o-m-b 6y ago
> I use vuejs with a json file containing all the data for the site Seconded. It makes hosting a breeze; especially when you can just throw it on GitHub Pages within minutes. I also like being dependent on only a text editor and a browser ... a combo still performant on just about any device from the last 20 years if not longer. No need to install full-featured IDEs and the various dependencies.

deleted 6y ago

[deleted]

bob1029 6y ago

I am aggressively pursuing a universal 100% server-side UI framework (not just targeting the web). If AMD has demonstrated anything to me, it's that the server is the place to do as much work as you can. Offloading work to client devices feels like stealing to me at this point. Websites are very abusive with your resources.

chooseaname 6y ago
> Offloading work to client devices feels like stealing to me at this point. Kinda is. It makes my mobile work harder and thus uses more battery.

rudolph9 6y ago

https://nextjs.org/ https://nextjs.org/ is a react wrapper framework that has some nice SSR features. It makes a ubiquitous dev experience where the majority of the app can be rendered server or client side. Last time I worked with it about a year ago it was only the first page load that was rendered server side though but the first one the one that arguably affects the user experience the most.

pdxandi 6y ago
I love ️Vercel (formerly nextjs). It's such a great platform and their free tier services do a lot of the heavy lifting of configuring a website and managing deployments.
- Kingdutch 6y ago
  Slight correction to avoid confusion between Open Source product and PaaS(?) company in people's searches: Next.js the product is still named Next.js. The company behind it, Vercel was formerly Zeit :) Their command line tool "Now" has been renamed to Vercel
deleted 6y ago
[deleted]
DrFell 6y ago
Despite the literal phrasing, server-side rendering, as in SSRing a SPA, is not even close to what was happening in the 90's. That was much simpler, pure, and fun.

peruvian 6y ago

There’s an exponentially growing recruiting, training, and hiring industry based on developers who only know how to write fat JS frontends. I think everyone has probably experienced high growth in their company’s frontend team. Many developers choose to write them not out of expertise but to have them in their resume and for job security.

arcturus17 6y ago
Many of us also choose to write it because it’s fun and the results can be excellent.
- esperent 6y ago
  Nobody denies React and co. are excellent tools. The frustration occurs when people who enjoy these tools claim that, if you choose not to use them, or suggest they're not fit for a certain task, you're WRONG. In the case of React in particular, this happens a lot. Then of course the people who don't want to use a framework feel frustrated, and next thing you know it's a flame war. I've seen this happen multiple times on Twitter.
  - iphone_elegance 6y ago
    I run into very few people who claim this.. oh you mean on Twitter? well there's the problem.
    - esperent 6y ago
      Twitter is where a large percentage of web devs hang out. If something is problematic, you can't dismiss it as "but that's just Twitter". If it's a common mode of discourse on Twitter, then it's legitimately a part of developer culture. In any case, discussions around front end frameworks and especially React are scarcely any better here. Although they are usually politer at least.
      - globular-toast 6y ago

s_y_n_t_a_x 6y ago

React isn't bound to web, there's quite a few React Native targets (ios, android, macos, windows, qt, gtk) I recommend React when making an app, web or otherwise. I recommend vanilla HTML + CSS with optional JS when making a website.