19 ms·

Server-side rendering is a better choice for many applications (2020)

178 points by krab 3y ago

deleted 3y ago
[deleted]
nuc1e0n 3y ago
Finally. Google's Angular.js did a lot of damage to the web. Client side rendering was never a good engineering approach and was critisized a lot at the time when it became popular.
- deleted 3y ago
  [deleted]
AzzieElbab 3y ago
vim vs emacs, anyone?
sthuck 3y ago
[dead]
motoboi 3y ago
React is slowly becoming JSF, just 25 years later.
tacker2000 3y ago
So it seems we are coming full circle again now. Since the dawn of time, backends running on PHP/Java/Ruby/etc… were used to render pages serverside and send them to the client, maybe even sprinkled with a little JS. Now that the whole JS stack and ecosystem has grown so big and unwieldy, we search for solutions to the problems we have created. Added to that, many have huge incentives and lots of skin in the game, and many have only knowledge of JS and nothing more, so we try to reinvent the wheel again.
- tiffanyh 3y ago
  > ”So it seems we are coming full circle again now.” This is common in tech. Decades ago, companies rented time slices on beefy servers. This was called “mainframes”. Today, it’s called “cloud”.
- deleted 3y ago
  [deleted]
somery 3y ago
I mostly agree with the author. After working a couple of years with React client render and API a pure server render seems to be a way more productive. For my recent OSS project (https://github.com/docusealco/docuseal https://github.com/docusealco/docuseal) I use server render everywhere except of the 2 most complex/dynamic UI parts (drag&drop form builder and the signing form). I think just figuring out which approach fits best for which part of the software is the most important thing, doing both SSR and CSR in a single project is completely fine when done right.
fridder 3y ago
Kinda a reason why LiveView has garnered so much attention
rwalle 3y ago
I am surprised that this topic keeps coming back and gets attention. I thought in the year 2023 this is a settled topic. Lots of hype from people who obviously never managed a real website or a real-world software project. On the non-technical side, traditional server/client separation is well understood by everyone and has all the tools any team ever needs, while SSR takes some learning -- it is added cost that does not transfer in many places. On the technical side, SSR only has clear advantage for very specific scenarios, e.g. e-commerce site where rendering time and responsiveness across different devices is a top priority. For the vast majority of websites out there, SSR likely only increases your server load and cost when you could leave all the rendering to client which is free resource. As browsers and computers themselves get faster, you don't even need to do anything to get better performance on client machines. Otherwise, this does not matter any more than Pepsi vs Coca-Cola or vim vs emacs. If SSR is clearly the better choice for a team/product, go ahead, otherwise don't waste time on it.
- halfmatthalfcat 3y ago
  Server Side Rendering been established practice for a long time, going back to PHP/JSP/etc. It's just taking on new life the past couple years. There's pros and cons to both server and client rendering.
- deleted 3y ago
  [deleted]
bofadeez 3y ago
Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality stifles the very innovation it claims to promote. The future of web development should focus on lean, framework-agnostic solutions, even if it means revisiting 'outdated' technologies. The most secure and maintainable code isn't necessarily wrapped in the latest framework; it's code that is simple, well-documented, and, above all, understandable without needing a 'decoder ring' of npm packages.
- ecshafer 3y ago
  I think the reality of web development is that outside a few minority of “apps”: figma, google maps, etc. is that basic html, js and css is more than enough. Maybe some jquery, or something like rails or php to update values server side before it’s sent out. Most websites are just text, with some pictures and some forms. Most frameworks are total overkill.
  - deleted 3y ago
    [deleted]
- thrashh 3y ago
  Even every significant website built 15 years ago not in JavaScript involved a framework. In Java, you got Spring. In Python, you got Django. In Ruby, you got RoR. In PHP, you got Symfony. etc. Blaming frameworks seems misguided.
  - pjmlp 3y ago
    Yes, they have been relatively stable for the last 20 years, and focus on delivering what the browser does best, HTML and CSS.
- pjmlp 3y ago
tamimio 3y ago
Key word: “many applications”, and I would be more specific to say many CRUD applications, but definitely not all web applications, there are so many cases that SSR is the worst choice, in my field, we do robotics/IoT/edge computing/etc., at the edge, most likely you will have an SBC with not so much resources (or resources you would like to save and use for edge computing like computer vision and such) to use to prerender a webUI for the user, one of the platforms I built it uses Cesium and WASM and the same time to control a swarm of drones, each SBC in there (and server) does the minimum load to serve some API requests while saving the rest for video/vision processing, while shouldering the rest to user’s machine. SSR might make sense for data centers building your average CRUD webapp but definitely not all.
RedShift1 3y ago
I come from the php heyday of SSR apps (now I write vuejs with graphql backend apps) where I used just plain php files that render a Smarty template. Is that still the goto solution or are there better alternatives?
- james2doyle 3y ago
  I honestly miss these days. I'm currently using Next 13 with the app directory and server components, calling a headless CMS with graphql, generating types from introspection, all to statically render HTML in a proprietary build system that takes 6 minutes to deploy. Only to find you need to build a whole "preview" workflow because you can't see your drafts with SSG - which means you need a server anyway...
davewritescode 3y ago
This is one of those vague "it depends on your organization" type answers. I've worked in apps where frontend folks did the JSPs and backend folks did everything else and it wasn't really optimal either. You end up with messy and/or non existing contracts between UI and the backend. Also, in my experience it's easier to handle partial functionality degradation in the client than on the server side which may be important or not at all depending on your app. So what I'm saying is there's a reason people ran to client side rendering and blindly running the other way for the sake of being a contrarian is equally silly.
synergy20 3y ago
You're absolutely correct, which is why we had Rails, Django, Laravel,etc. Why do we need node.js-based SSR and hydration etc these days? It seems it's just remaking an already solved problem with fancier terms, bottom line is that it's way more complex, what's the point?
- deleted 3y ago
  [deleted]
p0w3n3d 3y ago
Client side rendering are sure pain in the abdomen, but they require good MVC separation, and that's nice comparing to big ball of mud which people often create on SSR
pictur 3y ago
my favorite coworker model. the friend who emphasizes that something is best because he uses it himself. yes my friend, SSR can even provide immortality.
slackfan 3y ago
Ah, what is old is new again.
_iobt 3y ago
It has its merits but Thiel Truth is a bit of a reach
xnx 3y ago
Most "apps" don't need the level of front end interactivity that frameworks support. Simple forms and pages would make a lot of users happier. Apps that do justify heavy front-end interactivity (e.g. Google Docs, Slack, CAD tools) will probably move to techniques like canvas rendering and WASM.
deleted 3y ago
[deleted]
irvinej00 3y ago
[flagged]
trollied 3y ago
I swear people must get so lost in the development of some sites that they don't realise how bad they are. Pathetic load times, unnecessary page animations, confusing UIs, hijacking scrolling.
- AllegedAlec 3y ago
  The best thing is those fucking sites where after the page seems to be completely loaded suddenly new components or even worse: ads pop in, and you accidentally click on those instead of what you intended to click on.
  - ransackdev 3y ago
    Sounds like it’s by design. Payouts for clicks is way higher than impressions. Sneaky sneaky. Or, malicious payloads await on the other side. My favorite is when a full react site loads up, doesn’t have error boundaries, hits some unimportant js exception, and the entire page that was fully rendered and ready to go just pops out of existence and you are looking at a white page. That doesn’t seem like forward progress at all.
    - gabereiser 3y ago
      This is why I shun any and all front-end frameworks. They all suffer from this (except lit) with their shadow-dom. If a page is presented, it better be f&@king usable
    - archerx 3y ago
      Mozilla’s famous docs do this on my iPad pro rendering it utterly useless and honestly reflects badly on them, how can you claim to be an authority on documenting html/js when your site doesn’t even render? People like to talk badly about w3schools but at least it manages the bear minimum of actually being able to render and display the information I’m looking for.
- deleted 3y ago
  [deleted]
vlovich123 3y ago
I think the next major change will be unified hybrid rendering. Render the initial view via SSR for speed, framework automatically injects more and more of the page transparently as user-driven events happen. All of this will be transparent and you only write the app once.
- pathartl 3y ago
  I have been using Blazor for the past year and I've got to say it's pretty incredible. It has some downsides and .NET 8 with Blazor United is going to be a very welcome change, but I can have my cake and eat it too. I finally get to use components, write some client-side stuff in C#, and I don't have to touch a lick of JavaScript or TypeScript. I get how irritating it is for people to beat the "JS IS BAD" drum, but man, it's nice to use proper typing in a language that has some pretty damn good syntax.
- xu_ituairo 3y ago
  Do you mean something similar to Svelte becoming dominant?
  - sanderjd 3y ago
    I think from the comments here: probably? I don't know anything about Svelte, so I can't really say, but you're the third person I've seen say "this sounds like Svelte", so I'm inclined to think you're all right :) So has it taken off / is it taking off? If not, why not? Or more to the point of my original comment: Why is something like this just now taking off? Has something new enabled this in the last few years? It's not a new idea was my point in my comment, so I'm curious why the idea never seemed to take off in the past, and why it might be poised to now.
  - dinoreic 3y ago
    I can't understand how Svelte is not more popular. From first time I saw it 4y ago I thought it was game changer, did not change opinion.
- sanderjd 3y ago
  So, I was trying to do this literally a decade ago (as in, I remember it being 2013 when I started trying to make an angularjs site work this way). I haven't been doing front-end or "full stack" for awhile, so I'm a bit out of the loop. Why has this seemingly failed to progress in the last decade?
ysleepy 3y ago
More honest, or less clickbaity would be: "is my thiel truth"
- sanderjd 3y ago
  Even better would be to use normal words rather than expecting people to know what "thiel truth" means.
  - hug 3y ago
    I have trouble distinguishing the difference between Thiel Truths and Bathory Truths so this would be helpful for me.
    - bryanrasmussen 3y ago
      what is a Bathory truth - is this something like "She didn't really bathe in virgin's blood"?
  - LudwigNagasena 3y ago
    Nobody knows what it means because it’s a phrase the author of the article invented.
- euroderf 3y ago
  If I see "thiel truth" without other context, it means that any dodgy character with enough money can take down an entire web publishing enterprise.
filleted 3y ago
Isn't "Thiel Truth" just a euphemism for a strongly-held opinion? Not sure why this banal concept has to be attributed to some venture capitalist. Seems like clickbait. That aside, just use whatever fits best for the task at hand. If server-side rendering works better for you, use that. If client-side rendering is preferable, do that instead. Or a mix of the two. No need to be dogmatic about it.
- xu_ituairo 3y ago
  It’s a strongly held opinion that you think most people would disagree with you on. A contrarian belief, not just an opinion.
  - deleted 3y ago
    [deleted]
LorenDB 3y ago
> users would prefer your app as a website I hope by app you mean "webapp", because I sure don't want all my apps becoming websites. That's how Electron becomes more prevalent. Also, great to see a shout-out to D :)
- sanderjd 3y ago
  I think they mean, if it isn't an application but should just be a website. Many things are designed as applications with a lot of behavior, when really they are just documents that would be better structured as a hypertext "site" with linked pages of content. I really think this should be the first question on a project: Should this be a website or an application? I think the answer to a huge number of technical questions is dependent on the answer to this product question. And it seems like too few people are asking it, and are instead diving straight into making an application (whether web and native).
- philote 3y ago
  Personally, I'd prefer website to apps. Most apps don't have good reason to be an app over a website other than to better track users (like reddit's app for example). Also, I can easily visit a website from any web browser, but apps need to be installed first.
dools 3y ago
First I’ve heard of this interview question but if anyone is wondering here is a guaranteed way to fail a job interview with Thiel by answering the question thusly: Money has never existed without taxation
- nvm0n2 3y ago
  He would undoubtably respond with, "What about cryptocurrencies?".
  - sanderjd 3y ago
    What about them? Taxation applies to them...
  - dools 3y ago
    To which I would of course reply that they are not money ;)
    - chrisco255 3y ago
      To which I would reply that money is defined by three properties: 1. Store of Value 2. Unit of Account 3. Medium of Exchange Of which it's fair to say that several crypto currencies fit that bill.
      - a_bonobo 3y ago
        Oh good, so Beanie Babies are also money :)
        ensignavenger 3y ago
        Beanie Babies would make a rather poor unit of account. As at any given time, two of the same model Beanie Baby can be worth two very different amounts in trade based on their condition. Whereas a dollar bill does not matter what its condition is (at least within a reasonable range), it is still worth a dollar. Also, two different models of Beanie Babies will vary in value with relation to each other, whereas a one dollar bill will generally always be worth 1/100th of a 100 dollar bill.
Pxtl 3y ago
Not really sure why this person is quoting the weird old vampire just to talk about something as banal as server side rendering.
- djbusby 3y ago
  Ad-Hom is generally frowned upon in this establishment.
  - Pxtl 3y ago
    I mean it's not really as hominem is it? I'm not arguing the point at all. I just mean that invoking a controversial like Thiel for something as reasonable as discussing the merits of server side rendering is a very odd choice.
    - jakelazaroff 3y ago
      Agreed, I came into this article emotionally prepared to disagree after just reading the title.
      - Pxtl 3y ago
        At the risk of reductio ad absurdum: "Title: A Stalin-inspired Look at Webfarm Management Body: Apocryphally, Stalin once said that quantity has a quality all its own. As such, our hosting system involves an absolutely bonkers number of servers."
        LAC-Tech 3y ago
        We both know that on HN in 2023 Thiel is much more despised than Stalin.
deleted 3y ago
[deleted]
nickdothutton 3y ago
Whenever I encounter a server-side rendered app which _doesn't_ work well, and I make a cursory examination of why, I usually find it's down to poor choices. Ads causing reflow, embedding of other elements (off-site) with poor performance, the Cambrian explosion of trackers and other cancerous marketing-related cruft, labyrinthine page layouts because someone wanted a pixel-perfect visual. All things which are not the core app itself. This leads me to suspect that most apps would work just fine with a few easily anticipated exceptions.
mtkd 3y ago
It also usually means an app can be MVP'd a lot faster with less resource and fewer vertical skillsets Large structural changes can often then be made early in the project by a single person or alternate concepts quickly prototyped when it's effectively a monolith -- you don't as quickly get locked into "we'll just have to live with that now" I'm not against introducing client-side once the final functional form is reached if justifiable gains somewhere -- but from day-one it's usually just a headwind on a project of any complexity
nvm0n2 3y ago
> What important truth do very few people agree with you on? Seems like answering with SSR would fail a Thiel interview for two reasons: 1. It's not important (in the grand scheme of things) 2. It's not a view that very few people hold. SSR was the standard way to do things for a couple of decades up until frameworks like React, and React itself now implements SSR, doesn't it? Thiel uses this question to try and determine if someone is or can be a free thinker, someone who can discern something to be true even in the face of significant social opposition. That's valuable if you're an investor looking for overlooked opportunities, or an entrepreneur trying to find an edge in a highly competitive market. But there is no taboo or significant social opposition to SSR webapps, and bluntly, no edge to be found there.
- deleted 3y ago
  [deleted]
- lultimouomo 3y ago
  > 1. It's not important (in the grand scheme of things) > 2. It's not a view that very few people hold. And yet it makes the author feel a contrarian free thinker. It turns out, it's the prototypical Thiel truth!
  - greenie_beans 3y ago
    imo it's a prototypical anti-truth because it's not that contrarian even though the speaker thinks it is.
- otikik 3y ago
  It’s still the way to do things today. Most web apps today don’t need React and Co.
- water9 3y ago
  SRS is more secure because it doesn’t send down any links a role can’t see including even the link to get-based access from the account. It’s hard to attack a surface that is small.
collaborative 3y ago
> It's cheaper > You will need a backend anyway. It'll need to expose data to users. Exposing it as HTML is no harder than doing it via JSON or GraphQL Sure, if your "app" is just buttons and UI that interacts with a backend DB, I agree. However, many PWAs and native apps do lots of heavy lifting on the client side, and loading the backend with that is not cheap at all!
- em-bee 3y ago
  exactly, exposing the backend with HTML is harder, if that is supposed to mean the complete interface which includes CSS and javascript. without interface it would just be XML, at which point JSON would be the better choice. even more, many backends can be simple CRUD. i reuse my backend for all websites and haven't had to do any custom backend coding in years. so my current backend cost is zero, because i can do it all in the frontend.
- philote 3y ago
  Yeah, I don't get how it'd be cheaper at all. Yes you need a backend anyway, but unless you're not paying for usage and have spare CPU cycles and bandwidth available, it's not cheaper. It's cheaper to send your frontend html+js and let the browser cache it so it's only sent once, and let the frontend pull only the data it needs to render the html. The backend isn't having to process a template, or resend similar html constantly to the frontend since most of that likely cannot be cached.
  - collaborative 3y ago
    I don't get it either. I suspect it's investor hype, just like they hyped using "the cloud" which is also a huge money waster
sph 3y ago
Truth is not a product. You don't need to brand it with "Thiel truth". It's called truth, period, never mind that pillock. There is enough cult of personality in SV already.
gv83 3y ago
All this noise around "back to the roots" template rendering seems to ignore the elephant in the room that FE devs DON'T want to work with jinja2, django templates and all this jazz as it is perceived as a devaluation of the role + they need to learn specific syntaxes instead of having a "one size fits all" approach like with js frameworks.
- DylanSp 3y ago
  Speaking as a primarily BE dev with a preference for static typing - what I love about React is that TSX makes writing view code much easier. I get type safety to check that I'm passing in all parameters I'm using, type checking + the editor's autocomplete helps with HTML and CSS that I'm not as familiar with, and TSX being a relatively light sugar over Typescript provides more flexibility/power/ease-of-use than any templating language I've worked with. Go templates and ASP.NET .aspx templates (I think those are for Web Forms, specifically?) are much more annoying to work with.
- kaendo 3y ago
  My thoughts exactly. Although I don't see it as a devaluation. It's just not that convinient. And yes I admit, after years of working with a clear component system it is hard to go back to templates. They are just not it... I would really appreciate some advice, which template engine is good enough and how to organize with it something similar to how we write components in all these FE frameworks.
- archerx 3y ago
  The market will find the developers who will do that and the lazy ones who want a “one size fits all solution” will have to adapt or get left behind.
- muspimerol 3y ago
  As a frontend dev I can give you a few more reasons why I don't want to go back to writing templates as part of some backend framework: JavaScript is eventually needed for any non-trivial app. JS without a build system/dependency management is a maintenance nightmare. JS without linting, TypeScript, module syntax and unit tests is a maintenance nightmare. Reuse of components is much easier and more testable with framework abstractions (compare a react/vue/svelte component to e.g. a laravel blade component). Strict separation of CSS, HTML and JS means things like class names drift. With a JS build system you can easily introduce tooling to combat this (auto-removal of unused styles, enforcing that all classes are used, linting for CSS code, etc). I just can't imagine building an app of more than a few thousand lines without a framework and frontend build tooling. I would end up needing to reinvent these tools myself to ensure code quality as the project grows. I'm not saying it's impossible to add these features into, say, a Django or Rails app, just that it's more work for a worse outcome.
jiggawatts 3y ago
Wait until they find out that you don't even need to use client-side JavaScript frameworks to do their rendering on the server...
- sanderjd 3y ago
  Sure, but the advantage is that if you can write your rendering logic once and have it run both server-side and client-side, you've saved a ton of work.
mg 3y ago
I honestly wonder if everything that is a best practice on the backend and frontend these days is a net negative compared to "Write your own PHP or Python code which outputs your own HTML+CSS+JS". Especially for indiemakers and startups by technical founders. All the frameworks add so much complexity and confusion. And I have seen several startups fail because when the developer was confronted with breaking changes of their framework, they said "Ok, that's enough. I'm not going to plow through this". The simple "PHP or Python talks to the DB and outputs an HTML interface" type startups have a pretty good success ratio on the other hand.
- ransackdev 3y ago
  I’ve rolled my own mvc framework before, In php even! This was years ago when CakePHP was the new hotness and Laravel didn’t exist. Take it from someone who had your mentality and set off to make a tiny and no bs mvc that just gets the job done, the amount of work these frameworks are doing for you (backend frameworks) that you don’t consider, is why you should run a framework. You don’t want to deal with processing a raw http request from the web server. You don’t want to split headers. You don’t want to sanitize input params, deal with character encoding, content types, gzipping, cache control, etags, basic authentication, flushing headers, chunking bodies, file streaming, tcp sockets, slow client avoidance, and probably 1000 other things I can’t recall. No matter how unnecessarily complex you think a http framework might be, I assure you, it’s saving you from a mountain of already solved by people smarter than you or I complexity.
  - mg 3y ago
    You don’t want to deal with ... Well, I do all that and it works just fine for me. All my projects are 100% my own code down to the core. No frameworks, nothing. There might be some traces of jquery in there from when browsers were more unreliable. I don't even use that these days. To get to know those frameworks, I built some projects with Symfony, Laravel, Django and some others. But it didn't stick. They are too aggressive in their "do it my way, don't worry what happens behind the scenes, let me do the magic" approach. I had the best impression of Django. That is the only one I might give another try.
datastack 3y ago
Lot of bashing of this idea, not sure why. The entire industry has shifted from "web developer" to frontend/backend developers. What used to be a web developer is now called full stack. It seems like a big deal to me and the entire shift is an indicator of how much the IT community is behind front end clients talking to a separate back end. Server side rendering is no longer considered normal. Server site rendering now means something entirely different. It is about running your frontend code on the back end, So you still have the separation, but instead running it on the same machine. Now the same ui code has to be compatible with two different run times. This is much, much more complex than traditional server side rendering. I'm glad we now have things like single page apps and client site interactive applications, because some apps were really not possible with server side rendering unless with a lot of Jquery hackery that quickly becomes unmaintainable... However, I do think that front end technologies are overused, so I agree with the author, And I also think this is objectively a contrarian opinion, considering my initial point.
- DarkNova6 3y ago
  > I'm glad we now have things like single page apps and client site interactive applications, because some apps were really not possible with server side rendering And maybe server side rendering is just the right answer for websites which are not the two you mentioned.
  - datastack 3y ago
    that's the point, glad you understood
- safety1st 3y ago
  I wouldn't say server side rendering is a "Thiel Truth," because it's a thing that is already popular and uncontroversial and agreed upon by millions. There is an echo chamber where this happened: * Facing massive datacenter costs, Google and Meta realized that if they could hand off rendering to the client, they could have smaller datacenters and save a lot of money. Things like React and Angular were born. Other companies with large datacenter costs followed suit, many monies were saved. * This is when things started to get a little crazy. VCs started pushing heavy client-side SPA this and that because if anyone knows how to cargo cult, it's VCs. Devs started pushing it because it was a hard way to do things and if anything improves your salary, it's being involved with the hard bleeding edge stuff. Also inventing another JS framework turned out to be a great way to pad your resume. Design and UX people realized this was a whole new can of worms they could get paid to open, and dug right in. (In all cases note that the original point, saving money on compute at massive scale, was totally lost, and people just made up new reasons.) * Outside of this echo chamber which is utterly convinced it's filled with the smartest people in tech, life has actually gone on pretty normally for the rest of us, we're still doing stuff on the server whenever we can, and caching the hell out of everything we can, and being judicious with fancy client side frosting because complexity is generally the enemy. That said, it's definitely true that an entire generation of young web developers has been lost to madness because young web developers also like to cargo cult a lot, and the damage will take years to repair. But yeah, not really a Thiel truth
superb-owl 3y ago
The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.
- spinningslate 3y ago
  Big fat "it depends". Specifically, it depends on context. How big is the app? How many people are involved in building it? As with many things, separation of front and back ends grew out of web-scale companies and products. If you're buiding Facebook or Spotify or Gmail, then you need a way to partition your app - because you need to partition your people. Humans need structure, we don't deal well with single teams of multiple hundreds. Many apps don't fit that model. Lots of apps - e.g. business internal apps - might target at most small 100s of users and justify a dev team of < 10. In that world, separation of front end and back end devs & stacks is a disadvantage. Single language, single build apps mean less technical surface for the team to cover. Which means each person can more flexibly turn their hand to the requirements. Most people can do most things end to end. Features are business-driven and end to end. A single PR can deliver a meaningful piece of user-accessible value. There's no unionised demarcation. None of which says "separate UI & back end is universally wrong". But it's not universally right either. As is so often the case, it degenerates into a discussion that is technical and absolute when the underlying forces are organisational and relative.
- Transpire7487 3y ago
  > The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point. You say this as if it is necessarily good, but I disagree and would even say it's actually a hindrance for many teams. It often adds inefficiences, increases costs and makes planning and collaboration more difficult. > the fact that you get an API by default with CSR is also nice The vast majority of applications don't need an API.
caporaltito 3y ago
Oh yes, bring back the PHP days! My god...
bob1029 3y ago
I saw the effect of silently forcing hard-core SSR on my team over the last few years. My trick was to not give anyone any say in the matter. I built a product vertical that demonstrates how it is possible to handle not just the happy path, but also the unhappy edge cases. It is one thing to push an abstract policy/principle. It is another to hand someone a live, working implementation of a policy and request that they keep moving down the indicated path. I don't think SSR is a Thiel Truth. I think leadership is. If you want to see more SSR in the world around you, you have to build more SSR experiences and teams around them. Letting a room full of arbitrary developers sit around a conf call and come up with "the tech stack" is how you wind up in a hurricane of bullshit most of the time. At some point someone needs to ask the question "are we here to make money or have fun?" which should quickly highlight your ideal candidates for CTO/dictator.
Glench 3y ago
A good reference in this space is Rich Harris' talk on "transitional" web apps: https://www.youtube.com/watch?v=860d8usGC0o https://www.youtube.com/watch?v=860d8usGC0o ("Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes") SvelteKit, in my opinion, did a fantastic job implementing the best of both server-side rendering and client-side hydration and navigation by default (with any amount of route-level mixing and matching you want to do). I was skeptical of client-side navigation in particular, but it really does make my app feel so much snappier.
vbezhenar 3y ago
Whether you're doing server rendering or client rendering, you need to separate markup from business logic. Modern architecture fashion tells us that we need to use micro services. So even if I generate markup on the server, I need to talk to micro services using HTTP to get data. So the question is: which technology provides best tools for writing server-side rendering module? My wishes: 1. Strict-typed language. 2. Compiler-checked HTML output. 3. Flexible CSS output. So one should be able to write reusable components and easily write required markup. IMO best tool nowadays is TypeScript + React.
- tacker2000 3y ago
  Honest question: have you ever used anything besides JS and related stuff (TS/react)?
- yakshaving_jgt 3y ago
  > 1. Strict-typed language. 2. Compiler-checked HTML output. 3. Flexible CSS output. Haskell can do that.
- anonymoushn 3y ago
  > Modern architecture fashion tells us that we need to use micro services. So even if I generate markup on the server, I need to talk to micro services using HTTP to get data. I can only hope that this is satire
Lolaccount 3y ago
JFC ... is a Thiel Truth (2004|)
spacecadet 3y ago
Heres mine: Longevity tech... who benefits from living forever? The wealthy... What does living longer even mean? Does it mean I live 10 years longer in pain? I see longevity tech as code for ensuring the poor are here in the event we stop reproducing, or our decisions prevent us from being able to... and before you black and white nerds jump on me, Im not talking about biotech and healthcare!
- spacecadet 3y ago
  Down votes. Robber barons!
ninkendo 3y ago
One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.
- MatthiasPortzel 3y ago
  Hitting the “Reply” button on HN takes you to a new page with a textbox, taking over 500ms and a complete page reload. On some websites, that amount of latency is acceptable. But that could be instantaneous.
  - leecb 3y ago
    > taking over 500ms and a complete page reload For me this is 45ms to transfer the 2 kB (compressed) of HTML; the whole process takes under 60ms total, which is pretty darn close to "instantaneous" for the "complete page reload." EDIT: I'm in Texas, so most of this time is probably just round trip time to the west coast.
  - icedchai 3y ago
    Where are you located? It's about 120 ms here (wifi off of gigabit fiber, east coast US.) Based on ping time, over 60% of that time is network latency to the west coast. Actual "processing" would be in the 50 ms range which is super fast.
    - MatthiasPortzel 3y ago
      It may be <100ms, but that completely misses my point. My point is that it could be <1ms, and no reload, if the Reply box was added in JavaScript to the previous page.
  - tedunangst 3y ago
    Gives you more time to think about your reply. The fact that people on other sites comment in less than 500ms could be considered a negative.
karmakaze 3y ago
There are too many hedges and hand-wavy generalizations to take this seriously. > Client-side apps are wads of Javascript that must be loaded and parsed before it can load and parse JSON which it can then transformed into HTML. Precisely nothing about this is optimal for browsers and networks. Many applications are used infrequently and browser caches are not magic (and disagree with you about how important you app is), therefore arguing 'each user only has to load it once' is bullshit. The "wads of Javascript" is optional. The "must be loaded and parsed" can be trivial, and js is fast, so the "load and parse JSON ... into HTML" is FUD. As for the infrequency of app use, CDNs cache and deliver app source fast. I'd like to see some actual numbers of the best-case Client-side apps and critique that, say maybe Svelte. Perhaps this post was somewhat relevant in 2020. > Unless your app is something used frequently and for a decent period, with lots of low-latency interaction (forms do not count: think editing, iterating), it will certainly be faster server-side rendered. Then it goes on to talk about mobile apps--I never considered this to be an either/or. The biggest gains of SSR was SEO. I'm not a webdev, last I recall a hybrid SSR for first load, then Client-side app for rest is state-of-the-art.
- deleted 3y ago
  [deleted]
greenie_beans 3y ago
i don't think this is as contrarian as the writer thinks it is, even in 2020. everyday there is a post on the front page of HN glorifying server-side rendering/html/htmx/hotwire or denigrating react.
- evantbyrne 3y ago
  Yeah, this seems to be a very popular opinion outside of Node.js circles.
deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
paxys 3y ago
Really? This is the most controversial idea in the world according to the author? If the interview was about the largest strawman one could attack then maybe they would pass it, otherwise probably not.
- deleted 3y ago
  [deleted]
exabrial 3y ago
Really being stated is SSR is far simpler (less moving parts, less latency, less things to break, 100% control of environment, etc) and therefore superior, which should make it the first and best choice for nearly all web applications.
- pookha 3y ago
  Have to disagree with you. Plenty of web applications are using WebGL and have been for years (Cesium\GoogleEarth). I also like my applications to function when they're offline, especially if I'm flying or working without a network. I also might want to use WASM tools and use my local device as something more than just a dumb terminal. All of those use cases would make me prefer to use a more client centric approach and adding in SSR wouldn't add value (unless it's security).
  - exabrial 3y ago
    Literally most applications aren't Google Earth. But even google earth would be better as a desktop application.
flimsypremise 3y ago
This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency management and builds, and any dev team who knows what's up is going to include a frontend build for their app. So, given that the frontend build is baked into _any_ application build, if you decide to do template rendering in any language other than JS/TS, you are adding another build to your project. That means you need to configure that build for all environments, configure CI, and support that build going forward. Save yourself the trouble and just render everything server-side in JS. As for speed concerns, server rendering is almost never the bottleneck for any application. DOM rendering can be slow, but even JS renders several magnitudes faster than any network action. So your latency to the server alone is always going to be much, much slower than your render. Same with any network calls your app has to make, DB access, etc. In my many years of building SSR apps I have never had to optimize a render.
- ipaddr 3y ago
  "Frontend builds are basically a requirement for any application with a UI" I disagree with this premise. Dynamic languages don't have builds either.
  - threatofrain 3y ago
    Since JS people target multiple browser versions and vendors, building is basically a requirement.
    - mvdtnz 3y ago
      Builds are absolutely not a requirement for targeting multiple browser versions and vendors.
      - threatofrain 3y ago

178 points by krab 3y ago

deleted 3y ago

[deleted]

Finally. Google's Angular.js did a lot of damage to the web. Client side rendering was never a good engineering approach and was critisized a lot at the time when it became popular.

deleted 3y ago
[deleted]

AzzieElbab 3y ago

vim vs emacs, anyone?

sthuck 3y ago

[dead]

motoboi 3y ago

React is slowly becoming JSF, just 25 years later.

tacker2000 3y ago

So it seems we are coming full circle again now. Since the dawn of time, backends running on PHP/Java/Ruby/etc… were used to render pages serverside and send them to the client, maybe even sprinkled with a little JS. Now that the whole JS stack and ecosystem has grown so big and unwieldy, we search for solutions to the problems we have created. Added to that, many have huge incentives and lots of skin in the game, and many have only knowledge of JS and nothing more, so we try to reinvent the wheel again.

tiffanyh 3y ago
> ”So it seems we are coming full circle again now.” This is common in tech. Decades ago, companies rented time slices on beefy servers. This was called “mainframes”. Today, it’s called “cloud”.
deleted 3y ago
[deleted]

somery 3y ago

I mostly agree with the author. After working a couple of years with React client render and API a pure server render seems to be a way more productive. For my recent OSS project (https://github.com/docusealco/docuseal https://github.com/docusealco/docuseal) I use server render everywhere except of the 2 most complex/dynamic UI parts (drag&drop form builder and the signing form). I think just figuring out which approach fits best for which part of the software is the most important thing, doing both SSR and CSR in a single project is completely fine when done right.

fridder 3y ago

Kinda a reason why LiveView has garnered so much attention

rwalle 3y ago

I am surprised that this topic keeps coming back and gets attention. I thought in the year 2023 this is a settled topic. Lots of hype from people who obviously never managed a real website or a real-world software project. On the non-technical side, traditional server/client separation is well understood by everyone and has all the tools any team ever needs, while SSR takes some learning -- it is added cost that does not transfer in many places. On the technical side, SSR only has clear advantage for very specific scenarios, e.g. e-commerce site where rendering time and responsiveness across different devices is a top priority. For the vast majority of websites out there, SSR likely only increases your server load and cost when you could leave all the rendering to client which is free resource. As browsers and computers themselves get faster, you don't even need to do anything to get better performance on client machines. Otherwise, this does not matter any more than Pepsi vs Coca-Cola or vim vs emacs. If SSR is clearly the better choice for a team/product, go ahead, otherwise don't waste time on it.

halfmatthalfcat 3y ago
Server Side Rendering been established practice for a long time, going back to PHP/JSP/etc. It's just taking on new life the past couple years. There's pros and cons to both server and client rendering.
deleted 3y ago
[deleted]

bofadeez 3y ago

Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality stifles the very innovation it claims to promote. The future of web development should focus on lean, framework-agnostic solutions, even if it means revisiting 'outdated' technologies. The most secure and maintainable code isn't necessarily wrapped in the latest framework; it's code that is simple, well-documented, and, above all, understandable without needing a 'decoder ring' of npm packages.

ecshafer 3y ago
I think the reality of web development is that outside a few minority of “apps”: figma, google maps, etc. is that basic html, js and css is more than enough. Maybe some jquery, or something like rails or php to update values server side before it’s sent out. Most websites are just text, with some pictures and some forms. Most frameworks are total overkill.
- deleted 3y ago
  [deleted]
thrashh 3y ago
Even every significant website built 15 years ago not in JavaScript involved a framework. In Java, you got Spring. In Python, you got Django. In Ruby, you got RoR. In PHP, you got Symfony. etc. Blaming frameworks seems misguided.
- pjmlp 3y ago
  Yes, they have been relatively stable for the last 20 years, and focus on delivering what the browser does best, HTML and CSS.
pjmlp 3y ago

tamimio 3y ago

Key word: “many applications”, and I would be more specific to say many CRUD applications, but definitely not all web applications, there are so many cases that SSR is the worst choice, in my field, we do robotics/IoT/edge computing/etc., at the edge, most likely you will have an SBC with not so much resources (or resources you would like to save and use for edge computing like computer vision and such) to use to prerender a webUI for the user, one of the platforms I built it uses Cesium and WASM and the same time to control a swarm of drones, each SBC in there (and server) does the minimum load to serve some API requests while saving the rest for video/vision processing, while shouldering the rest to user’s machine. SSR might make sense for data centers building your average CRUD webapp but definitely not all.

RedShift1 3y ago

I come from the php heyday of SSR apps (now I write vuejs with graphql backend apps) where I used just plain php files that render a Smarty template. Is that still the goto solution or are there better alternatives?

james2doyle 3y ago
I honestly miss these days. I'm currently using Next 13 with the app directory and server components, calling a headless CMS with graphql, generating types from introspection, all to statically render HTML in a proprietary build system that takes 6 minutes to deploy. Only to find you need to build a whole "preview" workflow because you can't see your drafts with SSG - which means you need a server anyway...

davewritescode 3y ago

This is one of those vague "it depends on your organization" type answers. I've worked in apps where frontend folks did the JSPs and backend folks did everything else and it wasn't really optimal either. You end up with messy and/or non existing contracts between UI and the backend. Also, in my experience it's easier to handle partial functionality degradation in the client than on the server side which may be important or not at all depending on your app. So what I'm saying is there's a reason people ran to client side rendering and blindly running the other way for the sake of being a contrarian is equally silly.

synergy20 3y ago

You're absolutely correct, which is why we had Rails, Django, Laravel,etc. Why do we need node.js-based SSR and hydration etc these days? It seems it's just remaking an already solved problem with fancier terms, bottom line is that it's way more complex, what's the point?

deleted 3y ago
[deleted]

p0w3n3d 3y ago

Client side rendering are sure pain in the abdomen, but they require good MVC separation, and that's nice comparing to big ball of mud which people often create on SSR

pictur 3y ago

my favorite coworker model. the friend who emphasizes that something is best because he uses it himself. yes my friend, SSR can even provide immortality.

slackfan 3y ago

Ah, what is old is new again.

_iobt 3y ago

It has its merits but Thiel Truth is a bit of a reach

xnx 3y ago

Most "apps" don't need the level of front end interactivity that frameworks support. Simple forms and pages would make a lot of users happier. Apps that do justify heavy front-end interactivity (e.g. Google Docs, Slack, CAD tools) will probably move to techniques like canvas rendering and WASM.

deleted 3y ago

[deleted]

irvinej00 3y ago

[flagged]

trollied 3y ago

I swear people must get so lost in the development of some sites that they don't realise how bad they are. Pathetic load times, unnecessary page animations, confusing UIs, hijacking scrolling.

AllegedAlec 3y ago
The best thing is those fucking sites where after the page seems to be completely loaded suddenly new components or even worse: ads pop in, and you accidentally click on those instead of what you intended to click on.
- ransackdev 3y ago
  Sounds like it’s by design. Payouts for clicks is way higher than impressions. Sneaky sneaky. Or, malicious payloads await on the other side. My favorite is when a full react site loads up, doesn’t have error boundaries, hits some unimportant js exception, and the entire page that was fully rendered and ready to go just pops out of existence and you are looking at a white page. That doesn’t seem like forward progress at all.
  - gabereiser 3y ago
    This is why I shun any and all front-end frameworks. They all suffer from this (except lit) with their shadow-dom. If a page is presented, it better be f&@king usable
  - archerx 3y ago
    Mozilla’s famous docs do this on my iPad pro rendering it utterly useless and honestly reflects badly on them, how can you claim to be an authority on documenting html/js when your site doesn’t even render? People like to talk badly about w3schools but at least it manages the bear minimum of actually being able to render and display the information I’m looking for.
deleted 3y ago
[deleted]

vlovich123 3y ago

I think the next major change will be unified hybrid rendering. Render the initial view via SSR for speed, framework automatically injects more and more of the page transparently as user-driven events happen. All of this will be transparent and you only write the app once.

pathartl 3y ago
I have been using Blazor for the past year and I've got to say it's pretty incredible. It has some downsides and .NET 8 with Blazor United is going to be a very welcome change, but I can have my cake and eat it too. I finally get to use components, write some client-side stuff in C#, and I don't have to touch a lick of JavaScript or TypeScript. I get how irritating it is for people to beat the "JS IS BAD" drum, but man, it's nice to use proper typing in a language that has some pretty damn good syntax.
xu_ituairo 3y ago
Do you mean something similar to Svelte becoming dominant?
- sanderjd 3y ago
  I think from the comments here: probably? I don't know anything about Svelte, so I can't really say, but you're the third person I've seen say "this sounds like Svelte", so I'm inclined to think you're all right :) So has it taken off / is it taking off? If not, why not? Or more to the point of my original comment: Why is something like this just now taking off? Has something new enabled this in the last few years? It's not a new idea was my point in my comment, so I'm curious why the idea never seemed to take off in the past, and why it might be poised to now.
- dinoreic 3y ago
  I can't understand how Svelte is not more popular. From first time I saw it 4y ago I thought it was game changer, did not change opinion.
sanderjd 3y ago
So, I was trying to do this literally a decade ago (as in, I remember it being 2013 when I started trying to make an angularjs site work this way). I haven't been doing front-end or "full stack" for awhile, so I'm a bit out of the loop. Why has this seemingly failed to progress in the last decade?

ysleepy 3y ago

More honest, or less clickbaity would be: "is my thiel truth"

sanderjd 3y ago
Even better would be to use normal words rather than expecting people to know what "thiel truth" means.
- hug 3y ago
  I have trouble distinguishing the difference between Thiel Truths and Bathory Truths so this would be helpful for me.
  - bryanrasmussen 3y ago
    what is a Bathory truth - is this something like "She didn't really bathe in virgin's blood"?
- LudwigNagasena 3y ago
  Nobody knows what it means because it’s a phrase the author of the article invented.
euroderf 3y ago
If I see "thiel truth" without other context, it means that any dodgy character with enough money can take down an entire web publishing enterprise.

filleted 3y ago

Isn't "Thiel Truth" just a euphemism for a strongly-held opinion? Not sure why this banal concept has to be attributed to some venture capitalist. Seems like clickbait. That aside, just use whatever fits best for the task at hand. If server-side rendering works better for you, use that. If client-side rendering is preferable, do that instead. Or a mix of the two. No need to be dogmatic about it.

xu_ituairo 3y ago
It’s a strongly held opinion that you think most people would disagree with you on. A contrarian belief, not just an opinion.
- deleted 3y ago
  [deleted]

LorenDB 3y ago

> users would prefer your app as a website I hope by app you mean "webapp", because I sure don't want all my apps becoming websites. That's how Electron becomes more prevalent. Also, great to see a shout-out to D :)

sanderjd 3y ago
I think they mean, if it isn't an application but should just be a website. Many things are designed as applications with a lot of behavior, when really they are just documents that would be better structured as a hypertext "site" with linked pages of content. I really think this should be the first question on a project: Should this be a website or an application? I think the answer to a huge number of technical questions is dependent on the answer to this product question. And it seems like too few people are asking it, and are instead diving straight into making an application (whether web and native).
philote 3y ago
Personally, I'd prefer website to apps. Most apps don't have good reason to be an app over a website other than to better track users (like reddit's app for example). Also, I can easily visit a website from any web browser, but apps need to be installed first.

dools 3y ago

First I’ve heard of this interview question but if anyone is wondering here is a guaranteed way to fail a job interview with Thiel by answering the question thusly: Money has never existed without taxation

nvm0n2 3y ago
He would undoubtably respond with, "What about cryptocurrencies?".
- sanderjd 3y ago
  What about them? Taxation applies to them...
- dools 3y ago
  To which I would of course reply that they are not money ;)
  - chrisco255 3y ago
    To which I would reply that money is defined by three properties: 1. Store of Value 2. Unit of Account 3. Medium of Exchange Of which it's fair to say that several crypto currencies fit that bill.
    - a_bonobo 3y ago
      Oh good, so Beanie Babies are also money :)
      - ensignavenger 3y ago
        Beanie Babies would make a rather poor unit of account. As at any given time, two of the same model Beanie Baby can be worth two very different amounts in trade based on their condition. Whereas a dollar bill does not matter what its condition is (at least within a reasonable range), it is still worth a dollar. Also, two different models of Beanie Babies will vary in value with relation to each other, whereas a one dollar bill will generally always be worth 1/100th of a 100 dollar bill.

Pxtl 3y ago

Not really sure why this person is quoting the weird old vampire just to talk about something as banal as server side rendering.

djbusby 3y ago
Ad-Hom is generally frowned upon in this establishment.
- Pxtl 3y ago
  I mean it's not really as hominem is it? I'm not arguing the point at all. I just mean that invoking a controversial like Thiel for something as reasonable as discussing the merits of server side rendering is a very odd choice.
  - jakelazaroff 3y ago
    Agreed, I came into this article emotionally prepared to disagree after just reading the title.
    - Pxtl 3y ago
      At the risk of reductio ad absurdum: "Title: A Stalin-inspired Look at Webfarm Management Body: Apocryphally, Stalin once said that quantity has a quality all its own. As such, our hosting system involves an absolutely bonkers number of servers."
      - LAC-Tech 3y ago
        We both know that on HN in 2023 Thiel is much more despised than Stalin.

deleted 3y ago

[deleted]

nickdothutton 3y ago

Whenever I encounter a server-side rendered app which _doesn't_ work well, and I make a cursory examination of why, I usually find it's down to poor choices. Ads causing reflow, embedding of other elements (off-site) with poor performance, the Cambrian explosion of trackers and other cancerous marketing-related cruft, labyrinthine page layouts because someone wanted a pixel-perfect visual. All things which are not the core app itself. This leads me to suspect that most apps would work just fine with a few easily anticipated exceptions.

mtkd 3y ago

It also usually means an app can be MVP'd a lot faster with less resource and fewer vertical skillsets Large structural changes can often then be made early in the project by a single person or alternate concepts quickly prototyped when it's effectively a monolith -- you don't as quickly get locked into "we'll just have to live with that now" I'm not against introducing client-side once the final functional form is reached if justifiable gains somewhere -- but from day-one it's usually just a headwind on a project of any complexity

nvm0n2 3y ago

> What important truth do very few people agree with you on? Seems like answering with SSR would fail a Thiel interview for two reasons: 1. It's not important (in the grand scheme of things) 2. It's not a view that very few people hold. SSR was the standard way to do things for a couple of decades up until frameworks like React, and React itself now implements SSR, doesn't it? Thiel uses this question to try and determine if someone is or can be a free thinker, someone who can discern something to be true even in the face of significant social opposition. That's valuable if you're an investor looking for overlooked opportunities, or an entrepreneur trying to find an edge in a highly competitive market. But there is no taboo or significant social opposition to SSR webapps, and bluntly, no edge to be found there.

deleted 3y ago
[deleted]
lultimouomo 3y ago
> 1. It's not important (in the grand scheme of things) > 2. It's not a view that very few people hold. And yet it makes the author feel a contrarian free thinker. It turns out, it's the prototypical Thiel truth!
- greenie_beans 3y ago
  imo it's a prototypical anti-truth because it's not that contrarian even though the speaker thinks it is.
otikik 3y ago
It’s still the way to do things today. Most web apps today don’t need React and Co.
water9 3y ago
SRS is more secure because it doesn’t send down any links a role can’t see including even the link to get-based access from the account. It’s hard to attack a surface that is small.

collaborative 3y ago

> It's cheaper > You will need a backend anyway. It'll need to expose data to users. Exposing it as HTML is no harder than doing it via JSON or GraphQL Sure, if your "app" is just buttons and UI that interacts with a backend DB, I agree. However, many PWAs and native apps do lots of heavy lifting on the client side, and loading the backend with that is not cheap at all!

em-bee 3y ago
exactly, exposing the backend with HTML is harder, if that is supposed to mean the complete interface which includes CSS and javascript. without interface it would just be XML, at which point JSON would be the better choice. even more, many backends can be simple CRUD. i reuse my backend for all websites and haven't had to do any custom backend coding in years. so my current backend cost is zero, because i can do it all in the frontend.
philote 3y ago
Yeah, I don't get how it'd be cheaper at all. Yes you need a backend anyway, but unless you're not paying for usage and have spare CPU cycles and bandwidth available, it's not cheaper. It's cheaper to send your frontend html+js and let the browser cache it so it's only sent once, and let the frontend pull only the data it needs to render the html. The backend isn't having to process a template, or resend similar html constantly to the frontend since most of that likely cannot be cached.
- collaborative 3y ago
  I don't get it either. I suspect it's investor hype, just like they hyped using "the cloud" which is also a huge money waster

sph 3y ago

Truth is not a product. You don't need to brand it with "Thiel truth". It's called truth, period, never mind that pillock. There is enough cult of personality in SV already.

gv83 3y ago

All this noise around "back to the roots" template rendering seems to ignore the elephant in the room that FE devs DON'T want to work with jinja2, django templates and all this jazz as it is perceived as a devaluation of the role + they need to learn specific syntaxes instead of having a "one size fits all" approach like with js frameworks.

DylanSp 3y ago
Speaking as a primarily BE dev with a preference for static typing - what I love about React is that TSX makes writing view code much easier. I get type safety to check that I'm passing in all parameters I'm using, type checking + the editor's autocomplete helps with HTML and CSS that I'm not as familiar with, and TSX being a relatively light sugar over Typescript provides more flexibility/power/ease-of-use than any templating language I've worked with. Go templates and ASP.NET .aspx templates (I think those are for Web Forms, specifically?) are much more annoying to work with.
kaendo 3y ago
My thoughts exactly. Although I don't see it as a devaluation. It's just not that convinient. And yes I admit, after years of working with a clear component system it is hard to go back to templates. They are just not it... I would really appreciate some advice, which template engine is good enough and how to organize with it something similar to how we write components in all these FE frameworks.
archerx 3y ago
The market will find the developers who will do that and the lazy ones who want a “one size fits all solution” will have to adapt or get left behind.
muspimerol 3y ago
As a frontend dev I can give you a few more reasons why I don't want to go back to writing templates as part of some backend framework: JavaScript is eventually needed for any non-trivial app. JS without a build system/dependency management is a maintenance nightmare. JS without linting, TypeScript, module syntax and unit tests is a maintenance nightmare. Reuse of components is much easier and more testable with framework abstractions (compare a react/vue/svelte component to e.g. a laravel blade component). Strict separation of CSS, HTML and JS means things like class names drift. With a JS build system you can easily introduce tooling to combat this (auto-removal of unused styles, enforcing that all classes are used, linting for CSS code, etc). I just can't imagine building an app of more than a few thousand lines without a framework and frontend build tooling. I would end up needing to reinvent these tools myself to ensure code quality as the project grows. I'm not saying it's impossible to add these features into, say, a Django or Rails app, just that it's more work for a worse outcome.

jiggawatts 3y ago

Wait until they find out that you don't even need to use client-side JavaScript frameworks to do their rendering on the server...

sanderjd 3y ago
Sure, but the advantage is that if you can write your rendering logic once and have it run both server-side and client-side, you've saved a ton of work.

mg 3y ago

I honestly wonder if everything that is a best practice on the backend and frontend these days is a net negative compared to "Write your own PHP or Python code which outputs your own HTML+CSS+JS". Especially for indiemakers and startups by technical founders. All the frameworks add so much complexity and confusion. And I have seen several startups fail because when the developer was confronted with breaking changes of their framework, they said "Ok, that's enough. I'm not going to plow through this". The simple "PHP or Python talks to the DB and outputs an HTML interface" type startups have a pretty good success ratio on the other hand.

ransackdev 3y ago
I’ve rolled my own mvc framework before, In php even! This was years ago when CakePHP was the new hotness and Laravel didn’t exist. Take it from someone who had your mentality and set off to make a tiny and no bs mvc that just gets the job done, the amount of work these frameworks are doing for you (backend frameworks) that you don’t consider, is why you should run a framework. You don’t want to deal with processing a raw http request from the web server. You don’t want to split headers. You don’t want to sanitize input params, deal with character encoding, content types, gzipping, cache control, etags, basic authentication, flushing headers, chunking bodies, file streaming, tcp sockets, slow client avoidance, and probably 1000 other things I can’t recall. No matter how unnecessarily complex you think a http framework might be, I assure you, it’s saving you from a mountain of already solved by people smarter than you or I complexity.
- mg 3y ago
  You don’t want to deal with ... Well, I do all that and it works just fine for me. All my projects are 100% my own code down to the core. No frameworks, nothing. There might be some traces of jquery in there from when browsers were more unreliable. I don't even use that these days. To get to know those frameworks, I built some projects with Symfony, Laravel, Django and some others. But it didn't stick. They are too aggressive in their "do it my way, don't worry what happens behind the scenes, let me do the magic" approach. I had the best impression of Django. That is the only one I might give another try.

datastack 3y ago

Lot of bashing of this idea, not sure why. The entire industry has shifted from "web developer" to frontend/backend developers. What used to be a web developer is now called full stack. It seems like a big deal to me and the entire shift is an indicator of how much the IT community is behind front end clients talking to a separate back end. Server side rendering is no longer considered normal. Server site rendering now means something entirely different. It is about running your frontend code on the back end, So you still have the separation, but instead running it on the same machine. Now the same ui code has to be compatible with two different run times. This is much, much more complex than traditional server side rendering. I'm glad we now have things like single page apps and client site interactive applications, because some apps were really not possible with server side rendering unless with a lot of Jquery hackery that quickly becomes unmaintainable... However, I do think that front end technologies are overused, so I agree with the author, And I also think this is objectively a contrarian opinion, considering my initial point.

DarkNova6 3y ago
> I'm glad we now have things like single page apps and client site interactive applications, because some apps were really not possible with server side rendering And maybe server side rendering is just the right answer for websites which are not the two you mentioned.
- datastack 3y ago
  that's the point, glad you understood
safety1st 3y ago
I wouldn't say server side rendering is a "Thiel Truth," because it's a thing that is already popular and uncontroversial and agreed upon by millions. There is an echo chamber where this happened: * Facing massive datacenter costs, Google and Meta realized that if they could hand off rendering to the client, they could have smaller datacenters and save a lot of money. Things like React and Angular were born. Other companies with large datacenter costs followed suit, many monies were saved. * This is when things started to get a little crazy. VCs started pushing heavy client-side SPA this and that because if anyone knows how to cargo cult, it's VCs. Devs started pushing it because it was a hard way to do things and if anything improves your salary, it's being involved with the hard bleeding edge stuff. Also inventing another JS framework turned out to be a great way to pad your resume. Design and UX people realized this was a whole new can of worms they could get paid to open, and dug right in. (In all cases note that the original point, saving money on compute at massive scale, was totally lost, and people just made up new reasons.) * Outside of this echo chamber which is utterly convinced it's filled with the smartest people in tech, life has actually gone on pretty normally for the rest of us, we're still doing stuff on the server whenever we can, and caching the hell out of everything we can, and being judicious with fancy client side frosting because complexity is generally the enemy. That said, it's definitely true that an entire generation of young web developers has been lost to madness because young web developers also like to cargo cult a lot, and the damage will take years to repair. But yeah, not really a Thiel truth

superb-owl 3y ago

The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.

spinningslate 3y ago
Big fat "it depends". Specifically, it depends on context. How big is the app? How many people are involved in building it? As with many things, separation of front and back ends grew out of web-scale companies and products. If you're buiding Facebook or Spotify or Gmail, then you need a way to partition your app - because you need to partition your people. Humans need structure, we don't deal well with single teams of multiple hundreds. Many apps don't fit that model. Lots of apps - e.g. business internal apps - might target at most small 100s of users and justify a dev team of < 10. In that world, separation of front end and back end devs & stacks is a disadvantage. Single language, single build apps mean less technical surface for the team to cover. Which means each person can more flexibly turn their hand to the requirements. Most people can do most things end to end. Features are business-driven and end to end. A single PR can deliver a meaningful piece of user-accessible value. There's no unionised demarcation. None of which says "separate UI & back end is universally wrong". But it's not universally right either. As is so often the case, it degenerates into a discussion that is technical and absolute when the underlying forces are organisational and relative.
Transpire7487 3y ago
> The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point. You say this as if it is necessarily good, but I disagree and would even say it's actually a hindrance for many teams. It often adds inefficiences, increases costs and makes planning and collaboration more difficult. > the fact that you get an API by default with CSR is also nice The vast majority of applications don't need an API.

caporaltito 3y ago

Oh yes, bring back the PHP days! My god...

bob1029 3y ago

I saw the effect of silently forcing hard-core SSR on my team over the last few years. My trick was to not give anyone any say in the matter. I built a product vertical that demonstrates how it is possible to handle not just the happy path, but also the unhappy edge cases. It is one thing to push an abstract policy/principle. It is another to hand someone a live, working implementation of a policy and request that they keep moving down the indicated path. I don't think SSR is a Thiel Truth. I think leadership is. If you want to see more SSR in the world around you, you have to build more SSR experiences and teams around them. Letting a room full of arbitrary developers sit around a conf call and come up with "the tech stack" is how you wind up in a hurricane of bullshit most of the time. At some point someone needs to ask the question "are we here to make money or have fun?" which should quickly highlight your ideal candidates for CTO/dictator.

Glench 3y ago

A good reference in this space is Rich Harris' talk on "transitional" web apps: https://www.youtube.com/watch?v=860d8usGC0o https://www.youtube.com/watch?v=860d8usGC0o ("Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes") SvelteKit, in my opinion, did a fantastic job implementing the best of both server-side rendering and client-side hydration and navigation by default (with any amount of route-level mixing and matching you want to do). I was skeptical of client-side navigation in particular, but it really does make my app feel so much snappier.

vbezhenar 3y ago

Whether you're doing server rendering or client rendering, you need to separate markup from business logic. Modern architecture fashion tells us that we need to use micro services. So even if I generate markup on the server, I need to talk to micro services using HTTP to get data. So the question is: which technology provides best tools for writing server-side rendering module? My wishes: 1. Strict-typed language. 2. Compiler-checked HTML output. 3. Flexible CSS output. So one should be able to write reusable components and easily write required markup. IMO best tool nowadays is TypeScript + React.

tacker2000 3y ago
Honest question: have you ever used anything besides JS and related stuff (TS/react)?
yakshaving_jgt 3y ago
> 1. Strict-typed language. 2. Compiler-checked HTML output. 3. Flexible CSS output. Haskell can do that.
anonymoushn 3y ago
> Modern architecture fashion tells us that we need to use micro services. So even if I generate markup on the server, I need to talk to micro services using HTTP to get data. I can only hope that this is satire

Lolaccount 3y ago

JFC ... is a Thiel Truth (2004|)

spacecadet 3y ago

Heres mine: Longevity tech... who benefits from living forever? The wealthy... What does living longer even mean? Does it mean I live 10 years longer in pain? I see longevity tech as code for ensuring the poor are here in the event we stop reproducing, or our decisions prevent us from being able to... and before you black and white nerds jump on me, Im not talking about biotech and healthcare!

spacecadet 3y ago
Down votes. Robber barons!

ninkendo 3y ago

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

MatthiasPortzel 3y ago
Hitting the “Reply” button on HN takes you to a new page with a textbox, taking over 500ms and a complete page reload. On some websites, that amount of latency is acceptable. But that could be instantaneous.
- leecb 3y ago
  > taking over 500ms and a complete page reload For me this is 45ms to transfer the 2 kB (compressed) of HTML; the whole process takes under 60ms total, which is pretty darn close to "instantaneous" for the "complete page reload." EDIT: I'm in Texas, so most of this time is probably just round trip time to the west coast.
- icedchai 3y ago
  Where are you located? It's about 120 ms here (wifi off of gigabit fiber, east coast US.) Based on ping time, over 60% of that time is network latency to the west coast. Actual "processing" would be in the 50 ms range which is super fast.
  - MatthiasPortzel 3y ago
    It may be <100ms, but that completely misses my point. My point is that it could be <1ms, and no reload, if the Reply box was added in JavaScript to the previous page.
- tedunangst 3y ago
  Gives you more time to think about your reply. The fact that people on other sites comment in less than 500ms could be considered a negative.

karmakaze 3y ago

There are too many hedges and hand-wavy generalizations to take this seriously. > Client-side apps are wads of Javascript that must be loaded and parsed before it can load and parse JSON which it can then transformed into HTML. Precisely nothing about this is optimal for browsers and networks. Many applications are used infrequently and browser caches are not magic (and disagree with you about how important you app is), therefore arguing 'each user only has to load it once' is bullshit. The "wads of Javascript" is optional. The "must be loaded and parsed" can be trivial, and js is fast, so the "load and parse JSON ... into HTML" is FUD. As for the infrequency of app use, CDNs cache and deliver app source fast. I'd like to see some actual numbers of the best-case Client-side apps and critique that, say maybe Svelte. Perhaps this post was somewhat relevant in 2020. > Unless your app is something used frequently and for a decent period, with lots of low-latency interaction (forms do not count: think editing, iterating), it will certainly be faster server-side rendered. Then it goes on to talk about mobile apps--I never considered this to be an either/or. The biggest gains of SSR was SEO. I'm not a webdev, last I recall a hybrid SSR for first load, then Client-side app for rest is state-of-the-art.

deleted 3y ago
[deleted]

greenie_beans 3y ago

i don't think this is as contrarian as the writer thinks it is, even in 2020. everyday there is a post on the front page of HN glorifying server-side rendering/html/htmx/hotwire or denigrating react.

evantbyrne 3y ago
Yeah, this seems to be a very popular opinion outside of Node.js circles.

deleted 3y ago

[deleted]

deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

deleted 3y ago
[deleted]

paxys 3y ago

Really? This is the most controversial idea in the world according to the author? If the interview was about the largest strawman one could attack then maybe they would pass it, otherwise probably not.

deleted 3y ago
[deleted]

exabrial 3y ago

Really being stated is SSR is far simpler (less moving parts, less latency, less things to break, 100% control of environment, etc) and therefore superior, which should make it the first and best choice for nearly all web applications.

pookha 3y ago
Have to disagree with you. Plenty of web applications are using WebGL and have been for years (Cesium\GoogleEarth). I also like my applications to function when they're offline, especially if I'm flying or working without a network. I also might want to use WASM tools and use my local device as something more than just a dumb terminal. All of those use cases would make me prefer to use a more client centric approach and adding in SSR wouldn't add value (unless it's security).
- exabrial 3y ago
  Literally most applications aren't Google Earth. But even google earth would be better as a desktop application.

flimsypremise 3y ago

This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency management and builds, and any dev team who knows what's up is going to include a frontend build for their app. So, given that the frontend build is baked into _any_ application build, if you decide to do template rendering in any language other than JS/TS, you are adding another build to your project. That means you need to configure that build for all environments, configure CI, and support that build going forward. Save yourself the trouble and just render everything server-side in JS. As for speed concerns, server rendering is almost never the bottleneck for any application. DOM rendering can be slow, but even JS renders several magnitudes faster than any network action. So your latency to the server alone is always going to be much, much slower than your render. Same with any network calls your app has to make, DB access, etc. In my many years of building SSR apps I have never had to optimize a render.

ipaddr 3y ago
"Frontend builds are basically a requirement for any application with a UI" I disagree with this premise. Dynamic languages don't have builds either.
- threatofrain 3y ago
  Since JS people target multiple browser versions and vendors, building is basically a requirement.
  - mvdtnz 3y ago
    Builds are absolutely not a requirement for targeting multiple browser versions and vendors.
    - threatofrain 3y ago