Hacker News Reader

Hacker News

Comment by JohnBooty | Hacker News Reader

Full thread

JohnBooty

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.

View on HN

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.

Phoenix LiveView gives you excellent interactivity with backend rendering.

I desperately want to check that out when I have some free time.

(In other news, I would desperately like some free time)

There are quite a few others inspired by Liveview. On ASP.Net , PHP Laravel, Python Django and Stimulus Reflex on Ruby Rails.

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.

> 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.

> 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.

What security risks are removed by using a client side app instead of a server side one?

None, you're just shifting the risk to the user.

No database, no code running on your system other than nginx which I trust a whole lot more than myself.

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.

Many of us also choose to write it because it’s fun and the results can be excellent.

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.

I run into very few people who claim this.. oh you mean on Twitter? well there's the problem.

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.

> Twitter is where a large percentage of web devs hang out

Source?

> Twitter is where a large percentage of web devs hang out

This isn't true, Twitter is a place where a large percentage of Twitter users who are interested in web development talk about it.

Twitter is not a lens on the entire internet, it is a lens on a bubble of a bubble.

This happened when Mongo started getting popular, too. Mongo supporters would get nasty if you suggested using a relational database. That, eventually, cooled off. Hopefully this "React or nothing" phase will too.

    developers who only know how to write fat JS frontends

Yeah. This is often a big challenge for small companies / small teams.

Nearly every web app is now two apps, and it's increasingly infeasible for any developer to have a mastery of both backend and frontend stacks.

Not necessarily a terrible problem when you have dozens of developers, but a lot of dev teams are 1-3 people. Instead of web dev circa 2010 where you might reasonably have a 3-person team of people who can each individually work anywhere in the stack, now your already-small team is bifurcated.

In many ways this is an inevitable price of progress... 100 years ago you had one doctor in town and they could understand some reasonable percentage of the day's medical knowledge. Today, we can work medical miracles, but it requires extreme specialization.

At least in the development industry, we can choose not to pay that price when it's not necessary.

I don’t understand why members of a dev team back in the day would’ve been more capable of being full-stack than today...

The front/back divide also existed back then, with barely any possibility of a front person ever touching the back-end (a possibility that exists nowadays, without going into its merits or demerits).

For a reasonably ambitious and industrious individual nowadays it’s not unreasonable to become really good at one client and one server technology. There’s more to it than writing server-side code with HTML templating for presentation, for sure, but it remains well within the grasp of many people.

> I don’t understand why members of a dev team back in the day would’ve been more capable of being full-stack than today...

Because the stack in the old days was smaller and level of quality was far lower. In the '90s there was no css and javascript, nor did anyone care for accesability, multiple languages, security or interactive features. In the old days we had real documents with links and simple structure, not apps and mature frameworks. It was something on the level you get today with simple markup like markdown or org-mode.

It is because we understood the full-stack.

There was not "frontend" and "backend" developers. There were designers and developers. Designers created designs. They were usually delivered as PDFs, because the bulk of them came from print design backgrounds.

Their designs were then implemented by developers. Senior level developers tended to more of the application level heavy lifting (server-side scripting & db), with junior level developers working on converting designs to html, then to templates. By the time a junior developer moved on to app code, they were well versed and had mastered HTML and all the weird edge cases. They knew HTML.

The first real wave of "frontend" and "backend" developers came on the scene when you had designers learn Flash. They started driving more complex applications and there was a more bifurcation.

Granted even in small teams of the era, you had developers prefer "front" or "back". We tended to value "A jack of all trades is a master of none, but oftentimes better than a master of one"

I missed the era with flash though. I remember the original Gorillaz website which was a full flash-based game / exploration / gallery type of thing. It was so cool and I've not seen anything like that I ended up spending hours and hours on that site...extremely patiently because of the slow internet speed at that time in my college dorm in China (2002-ish I think?). The quality was astonishingly good.

Phoenix liveview solves this and the overhead of Ex is much lower than the overhead of mainting separate codebases and APIs, in our experience.

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.

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

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.

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.

Except that phones have only gotten thinner and thinner since the 1990s... And PC's (laptops, at least) are not far behind.

https://wikipedia.org/wiki/Thin_client https://wikipedia.org/wiki/Fat_client

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

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.

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.

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

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.

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.

> 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.

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.

Reply on news.ycombinator.com