55 ms·

The future (and the past) of the web is server side rendering

• mikece 4y ago
  And the future beyond that will be client-side rendering. In the beginning everything was rendered on the mainframe; then CICS allowed partial screen updates and even dynamic green screen design. Then the early web where everything was server which made the job of web indexing much easier. Then we moved back to rich client apps -- applets, flash, eventually SPAs -- with no way for search engines to easily index things. A best of all worlds scenario is a rich UI that only needs to make API calls to update the display, keeping performance fast and content flicker-free (and the server-side API could have an agreed upon standard for being indexed -- or submitting updates for indexing -- to search engines). There is no truly perfect scheme, only ways in which we think we can improve on the status quo by swinging the pendulum back and forth.
  • ErikAugust 4y ago
    "eventually SPAs -- with no way for search engines to easily index things." It's funny Google can't index a SPA, given the tie to Angular (2500 apps in use in-house). Wouldn't be so hard to build something that could.
    • mikece 4y ago
      I would have thought they could spin up headless Chrome instances to simply pull down, render, and then index websites. Apparently this is too resource intensive for them? I'm sure the idea has come up (there's no way I thought of this and they didn't).
    • xemoka 4y ago
      You'd think right? There must be other reasons then... how does Google benefit from not building better SPA crawling infrastructure? It's certainly gotten _better_ over the last few years, but still seems lacking.
    • npretto 4y ago
      It does indeed render and index them: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics https://developers.google.com/search/docs/crawling-indexing/...
    • csixty4 4y ago
      Googlebot has been able to index SPAs since 2019. They use a Headless Chrome instance and allow a number of seconds for things to render after each interaction.
      • deleted 4y ago
        [deleted]
      • spiffytech 4y ago
        With the caveat that server-generated HTML is indexed immediately, while pages that need client-side rendering get put into a render queue that takes Google a while to get to (days?).
        • super256 4y ago
          That's why you write down your use case for every project. Have a news site which needs to be indexed by Google immediately? SSR. Have some Jira or whatever? CSR. Most CSR applications are behind a login wall anyway. Thinking of the core applications of services like WhatsApp, Discord, Gmail, Dropbox, Google Docs etc. Bottom line, whether SSR really being “the future”: “it depends”.
        • capableweb 4y ago
          Hence you don't build documents with SPAs, they are meant for applications. And usually you don't care about indexing the inside of applications, only the landing pages and such, which are documents (should not be a part of the SPA). A blog built as a SPA? Sucks. A blog built as a collection of documents? Awesome.
  • OliverJones 4y ago
    The client-server wheel of life just keeps turning, and turning, and turning. It's an eternal human truth: each generation yearns to improve on the previous generation's efforts. This server-client zeal to improve has been tremendously productive of good ideas over the last few decades. It will continue. Hopefully saving power and CO2 can be the focus of the next couple of turns of the great wheel.
    • oakwhiz 4y ago
      Extracting money and creating walled gardens, while removing user choice, is also a focus of this server side cycle.
    • makmanalp 4y ago
      Don't know why this comment was downvoted - it's the truest take here I can spot. The fact is that the factors that make one versus the other more preferable (the state and quality of frontend / backend tooling and environments, compute power and rendering capabilities of servers vs clients, round trip time cost vs responsiveness requirements etc etc) are continually changing over time and that's what's causing the back and forth swing, but lessons from previous iterations are generally learned. I wouldn't be shocked if we sooner or later saw language-level support (think of something like Elm, improved) for writing "just" code and then later marking up which parts execute where, and the communications and state synchronization crud and compiling down to the native language is just handled.
  • deleted 4y ago
    [deleted]
• JohnFen 4y ago
  If web sites have to so dynamic, I much prefer that the computation involved is done on their machine than on mine. I simply don't trust random web sites enough to let them run code on my machines.
  • rektide 4y ago
    What is it you dont trust? This Fear Uncertainty & Doubt clashes heavily with the excellent security sandbox the web browser is. What is the harm you are afraid of? What are you supposing the risk is/what's in jeapordy here?
    • JohnFen 4y ago
      Relying on sandboxes seems unwise to me. They're a useful backstop, but shouldn't be the primary defense. The primary defense is to minimize the exposure to risk in the first place. As to what harm I'm avoiding, it's mostly around tracking -- which is something that browsers have a very difficult time preventing, especially if sites are allowed to run code in them.
      • MrOwnPut 4y ago
        So lets say a resume generator website, or a document converter, etc. You trust uploading your personal information to a server to generate the pdf/image/whatever vs doing it in solely in the browser? Doing more on the server would lead to more tracking, not less.
        • JohnFen 4y ago
          Well, I wouldn't use such a website anyway (especially a document converter -- that is better done using a real application), regardless of where the processing was done, unless I was very certain that the website was trustworthy. For one thing, even if the website purports to not move my data to their servers, how do I know they're being truthful without going to extremes such as sniffing traffic? There have been plenty of sites that have lied about such things.
• computing 4y ago
  "The future of the Web is what suits our business model" /s But in all seriousness, the web has websites, it has apps, it has games. Pick a tool that's appropriate for the job and forget about what is the past/present/future.
  • spiffytech 4y ago
    The rise of metaframeworks is interesting because it brings nuance to this. The line between site and app can be blurry. For example, my app has a main screen that needs to be client rendered. It also has a user settings screen that could be implemented as a traditional server rendered page with no JavaScript, except it's a lot more practical to build everything inside the same project and technology. Apps and their marketing pages are often put on different subdomains for the same reason. Metaframeworks that blend rendering modes help users get a lighter page load where appropriate, with less developer effort.
    • arcanemachiner 4y ago
      Pardon my ignorance, but what do you mean by metaframework? I just learned about Astro the other day. It allows you to blend components from SPA frameworks together. Is that what you mean?
      • spiffytech 4y ago
        'Metaframework' is a term for frameworks that wraps React or Vue or similar. Next.js, Nuxt, Gatsby, etc. I think Astro is considered a metaframework too. They're sometimes called stuff like "a React framework", depending on whether the speaker considers React a library or a framework.
        • arcanemachiner 4y ago
          Ah, that makes sense. Thanks.
    • computing 4y ago
• rado 4y ago
  npm install common-sense
  • mikece 4y ago
    Error: package cannot be found or is incompatible with your system.
  • qbasic_forever 4y ago
    We regret to inform you the common-sense package has been compromised and it has been removed from the ecosystem.
  • bartmika 4y ago
    npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/left-pad https://registry.npmjs.org/left-pad
  • deleted 4y ago
    [deleted]
• seydor 4y ago
  I think it's a bit ridiculous to call it "server side rendering". It is called HTTP
  • superkuh 4y ago
    It is ridiculous. It's pretty much newspeak. Like calling installing applications "sideloading" when you're not using some megacorp's walled garden. Also, I'd say "HTML" not "HTTP". What's HTTP(/3) these days is not what HTTP(1.1) was in the past.
    • anthk 4y ago
      Discord "server". The amount of ignorance of the newer generations it's astounding. They keep reinventing the wheel over and over.
  • _visgean 4y ago
    Depends on what exactly it is. If you for example take a react app that was doing rendering on user side and change it so that it is "pre-rendered" on the server it makes sense to call it server side rendering..
  • rightbyte 4y ago
    Ye ... I get flashbacks from coding jsp-pages in Java with FancyBeans.
  • Existenceblinks 4y ago
    It's called sending HTML from server.
    • seydor 4y ago
      aka a protocol for transferring hypertext from server
      • Existenceblinks 4y ago
        I get what are saying, basically all the MIME types of body is under the grand scheme of server side rendering. Fine.
• dragonelite 4y ago
  And the cycle starts anew...
• recursivedoubts 4y ago
  I may be misunderstanding this, but isomorphic SSR sounds an awful lot like the Java Server Faces concept of a server side DOM that is streamed to the client. JSF was largely dropped by java developers because it ended up scaling poorly, which makes sense since it violates one of the main constraints that Roy Fielding proposed for the webs REST-ful architecture: statelessness. An alternative approach is to retain the statelessness of the first option they outline (I don't understand why it isn't "true" SSR): use normal, server-rendered HTML, but improve the experience by using htmx (which I made) so that you don't need to do a full page refresh. This keeps things simple and stateless, so no server side replication of UI state, but improves the user experience. From what I understand of the isomorphic solution, it appears much simpler. And, since your server side doesn't need to be isomorphic, you can use whatever language you'd like to produce the HTML.
  • deniz-a 4y ago
    In the sample code, there is no "streaming" going on -- the server simply uses the client code as a template to generate HTML and sends it as a normal HTTP response. In pseudocode: import "client.js" as client on request: document = new ServerDOM(), client.render(document, data), respond with document.toHtmlString() > I don't understand why it isn't "true" SSR This article seems to be using the term SSR exclusively in the frontend framework sense, where client code is run on the server. It's not how I use the term but it is a common usage. Another possible reason that the htmx approach isn't discussed: the any-server-you-want nature of htmx is terrible for selling Deno Deploy :]
    • recursivedoubts 4y ago
      Ah, I thought there was some sort of diff-and-send going on to the client. I do know there are folks using htmx and deno (we have a channel on our discord) so I don't want to come across as oppositional! Rather, I just want to say that "normal" SSR (just creating HTML) can also be used in a richer manner than the plain HTML example given.
  • quechimba 4y ago
    I think JSF was ahead of its time. I'm working on a server side framework and someone told me it reminded them of Java Server Faces. I think the approach works really well and latency is low enough when you can deploy apps all over the world. Also they didn't have HTTP2 or websockets back then... What I'm doing is basically a clone of Preact, but server side Ruby, streaming DOM-patches to the browser...
• trollied 4y ago
  “Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that. I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.
  • deleted 4y ago
    [deleted]
  • dylan604 4y ago
    I'm of two minds. I want agree with you of well formed DOM for the browser to render. That's great. Now, do we have to go all the way back to flat files where the whole page has to refresh to update one silly field or selection update? No, we don't have to go full cave man for that. We can still use the front end to make changes after the initial load. we don't need an app to be running in each user's browser for a large majority of places where this is happening.
    • forgotmypw17 4y ago
      Yes, the best of both worlds. Fast-loading, complete, cacheable, archivable pages. And DOM changes for updating them without reloading the entire page.
  • wg0 4y ago
    Basically, by those standards, ngnix is the most popular server side renderer ATM. It can beautifully render HTML and pretty much any file format. It can even render video files and with Ngnix plus, you get bit more server side rendering for vidoe files too. Apache used to be a good server side renderer too but those were the old days.
  • revskill 4y ago
    I guess you're a backend dev watching all frontend framework shines with a jealous eyes. Keep watching :) Those heavyweight framework exist for a reason, they're not born out of thin air. It's about your use case, you don't need it for other's use case.
• underbluewaters 4y ago
  Mindshare will go towards rendering javascript components on the server since that's another complex problem that's fun to solve. That's good! We shouldn't have to give up the productivity gains of tools like React to improve time-to-interactive and other performance stats. That said... I'm not going to pretend it's an urgent need and will wait for these tools to mature.
• ArcaneMoose 4y ago
  The issue I have with SSR is that it offloads processing power onto the server. That means I have to pay more as the host instead of relying on user's browser to handle the compute "for free".
  • trashburger 4y ago
    The problem with this idea is that the user's browser's compute is not "free". Offloading the computing means the users have a worse experience, which will affect your userbase and page rankings.
    • ArcaneMoose 4y ago
      That sort of depends. If the compute needs to happen regardless and now you add a layer of shipping data to and from the server, that could add even more latency and make for a worse experience.
    • jasonlotito 4y ago
      The argument against this is the cost of a user's bandwidth. If I have all the computation done on the server side, then I have to wait for the round trip every single time just to download the results. In this case, the browser's compute is more free, as the cost to send a remote request is more than likely higher. Like most things, there is no simple right answer, and it depends on what you are doing. But blindly assuming the experience will be worse using CSR is as silly as assuming SSR will always be worse as well.
      • butlerm 4y ago
        It depends on the style of application. For most line of business applications the data on the client side is potentially out of date as soon as it requested, and as a consequence very little can be done on the client side except arrange or rearrange data for display. All requests that make any substantive changes must be sent to a server somewhere anyway and client side data caching is almost useless.
    • Havoc 4y ago
• anonymousDan 4y ago
  Is SSR still much better for seo?
  • ushercakes 4y ago
    Yeah, big time. It's faster, so crawlers give you better scores for page speed, which is important. Secondly, it automatically renders all of your content, vs if you dynamically load content, the crawler may just see a page with a "Loading" element and never actually view the content itself. Google argues that it is able to handle javascript heavy client side code in it's crawlers, but the data seems to show otherwise.
    • linkjuice4all 4y ago
      Perhaps the best method is a mix of static or SSR content for the content-heavy stuff that you want indexed and SPAs for the truly dynamic experiences. This is easier said than done but there’s a good chance your marketing team is separated from “product” anyway. Marketing can continue to use WordPress or some other CMS with a static export or SSR and product gets the full app experience stuff. It’s mentioned in other threads that SSR is more expensive as your scale - so you might as well make the “outside” layer of your site light weight and static/SSR for fast client loading and then give them the full SPA once they’ve clicked through your landing pages.
  • blobster 4y ago
    Yes. There's a separate queue for sites that need js rendering and it eats much more into your crawl budget. Best way to avoid it imo is to use something like Rendertron, which is made and recommended by Google.
    • somehnguy 4y ago
      https://github.com/GoogleChrome/rendertron https://github.com/GoogleChrome/rendertron appears to be deprecated and no longer recommended by Google. They are now recommended basically what this article is about.
    • 4y ago
• rbanffy 4y ago
  My first contact with HTTP and HTML forms was an immediate throwback to my mainframe experience. The browser was like a supermodern 3270 terminal, getting screens from the server, sending data back, getting another screen and so on. There were a number of products that allowed a web app to maintain a 3270 connection to the mainframe and render the terminal screens as an HTML form. Fascinating stuff.
• jhp123 4y ago
  > Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work, probably an absolute increase because some logic is duplicated. If there is a speed improvement it is because the server has more clock cycles available than the client, but this is not always true. > Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase. Huh? It takes less code to build a string in a datacenter than it does in a browser?
  • HideousKojima 4y ago
    >but the page is loaded later because you have to wait for the server to perform this work. What is caching?
    • nicoburns 4y ago
      Caching also works for client side rendering of course (you can usually cache the entire client side app so that the browser doesn't have to hit the network at all to start running client side code).
      • runako 4y ago
        > you can usually cache the entire client side app so that the browser doesn't have to hit the network at all to start running client side code This is also true for Web apps that do not have meaningful amounts of client-side code. > Caching also works for client side rendering There are obviously a lot of differences in how caching works, but client-side caching is generally strictly worse than doing so on the server. Using the e-commerce example in TFA, every browser has to maintain their own cache of the product information, which may include cache-busting things like prices, promotional blurbs, etc. The server can maintain a single cache for all users, and can pre-warm the cache before any users ever see the page. Adding fragment caching, which allows parts of a page to be cached, a server-side caching strategy will typically result in less total work being done across the user population, as well as less work done at request time for each visitor.
• brap 4y ago
  >ctrl+f “State” >ctrl+f “Effect” >0 results I only skimmed through the post, but seems like it’s ignoring the main reasons why CSR is needed?
• pictur 4y ago
  It is tragicomic that the slogan "We should do things on the server instead of the browser" is becoming popular again as browser technologies evolve.
• rafaelturk 4y ago
  Can someone explain me: Deno is becoming such a confusing framework, initially NodeJS alternative now it seems to me that is trying to compete with NextJs?
  • deniz-a 4y ago
    It's not trying to compete with Next, but advertising how Deno's similarity to the browser and being able to run on CDN-like networks (which i refuse to call "the e*ge") can let you build a better version of Next's features yourself.
  • deleted 4y ago
    [deleted]
• ChrisMarshallNY 4y ago
  Anyone remember There? It's still around[0], but I don't know how active it is. I'm pretty sure it relied on in-browser XSLT to do a lot of its magic. [0] https://there.com https://there.com
• advisedwang 4y ago
  This is why I'm really excited about htmx [1]. No need to write isomorphic javascript at all. You can still use server side templates but have interactive web pages. [1] https://htmx.org/ https://htmx.org/
  • deleted 4y ago
    [deleted]
  • seti0Cha 4y ago
    I just started playing around with it after fumbling around with Vue for a bit. I really like that there is so much less magic involved, no getting lost in a twisty maze of proxies. A real breath of fresh air. But then I haven't done real frontend development since JSPs were hot, so I'm not sure my liking it is a good thing.
  • silver-arrow 4y ago
    It really is so terrific. After using it for over a year, I agree with the creator's of htmx when they say that this is how web development would have been if HTML as hypermedia was continually improved all these years. When you start using htmx, you raise your eyebrows and think - hmmm this could be something interesting. When you use it for many months, you then open your eyes very wide and think - this is something special! In hindsight is so damn obvious, why didn't it happen much earlier?!?!
  • Existenceblinks 4y ago
    It's a banger for docs type of site. All html partial pieces are pre-generated and put in cdn. Sort of like how search utilizes index stuff.
• ChewFarceSkunk 4y ago
  [dead]
• szastamasta 4y ago
  I think that biggest issue with page size is not due to client side rendering, but rather thanks to bundling and idea that you need to download the same minified Lo-Dash on each and every page. Why can’t we just use public CDNs is beyond my understanding. I really like client side apps. They are so much more responsive. The only problem is with bundle sizes.
  • IanCal 4y ago
    > Why can’t we just use public CDNs is beyond my understanding. Privacy issues iirc. I think you can use the setup to introduce tracking/reveal information about your history.
    • afandian 4y ago
      It could have worked with a trusted, open broker. I'm sure there could be a compatible sustainability model. I feel like a lot of potential trust was broken by the likes of Facebook and Google.
      • IanCal 4y ago
        I'm not sure. I think the issue was not the provider but that if you visited pages it was possible for that page to gain information about your history based on whether resources were cached.
  • verdverm 4y ago
    You can CDN your own bundles which include your libraries without much issue. You don't even have to really CDN them as much as make them cache friendly (name them with hash) and set the TTL to 30d. Download once then the browser will keep a copy for future page visits
• andrewstuart 4y ago
  I really don’t like server side rendering. I like my react apps to be static files served from a plain HTML server.
  • deleted 4y ago
    [deleted]
  • timw4mail 4y ago
    Server-side rendering is so much simpler from platforms that were designed to do it. As a user, I despise seeing a white screen with a spinner.
  • dbbk 4y ago
    Depends what you're building. If it's a dashboard app gated behind a user login, sure, have it be a static HTML file. SEO is irrelevant and you wouldn't be server rendering anything anyway. If it's a public site and you want people to find it (ie SEO) you really should be server rendering and caching on a CDN.
• pcmaffey 4y ago
  Client-side rendering needs to rebrand as local-first. Then the cycle will start anew.
  • deleted 4y ago
    [deleted]
• EugeneOZ 4y ago
  No. Because HTML is not the future of the Web.
  • anthk 4y ago
    HTML5 can do audio and video by itself calling native video decoders in the hosts such as FFMPEG and yet people kpt choosing crawling JS players. It's idiotic.
• runako 4y ago
  In theory, the "modern" frontend frameworks could be useful for a subset of applications. In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them. If I gave this as an example, people would say I'm being unfair to the front-end folks. But since Deno posted it, I think it's fair say that it's overkill to use a front-end framework like React (mentioned as a comparator in TFA) to implement add to cart functionality on an e-commerce site. And that for users with slow browsers, slow/spotty Internet, etc., an architecture that uses a heavy front-end framework produces a worse overall experience than what most e-commerce sites were able to do in 1999. Edit: IMHO all of this is an artifact of mobile taking a front seat to the Web. So we end up with less-than-optimal Web experiences due to overuse of front-end JS everywhere; otherwise shops would have to build separate backends for mobile and Web. This, because an optimal Web backend tends to produce display-ready HTML instead of JSON for a browser-based client application to prepare for display. Directly reusing a mobile backend for Web browsers is suboptimal for most sites.
  • revskill 4y ago
    There's always a "what if". What if you don't just stop at "adding a add to cart button" ?
    • runako 4y ago
      Correct. The design tradeoff is dependent on knowing how much of a Lisp interpreter you need to build. For most sites, the answer is "none" and it's not worth degrading user experiences just in case your e-commerce site ends up needing the ability to also serve as a designer for Minecraft levels. (Even if it does, there is no requirement to ship the heavy JS needed for the Minecraft editor to all the e-commerce product description pages.)
  • teaearlgraycold 4y ago
    IMO the big value add from React and friends is all of your rendering logic is in the same language and the same code base. I do not want to go back to templated HTML from Ruby/Java/PHP/whatever combined with ad hoc JS to handle whatever parts need to be dynamic. If you know your UI can be almost completely static (like with HN) then the trade-off from the old way is acceptable. But if you don't know where your site's going to go because you're a startup then it's hard to buy into old school SSR. NextJS, when done right, can be an acceptable 3rd option.
• gfodor 4y ago
  If you’re interested in server side rendered multiplayer 3D worlds, my project webspaces[1] lets you render HTML and get a 3D World. [1] https://webspaces.space https://webspaces.space
  • majestic5762 4y ago
    Very cool!
• tlarkworthy 4y ago
  It's obviously nonsense. The lowest latency cache and state storage is clientside. You can piss around with multi regions and SSR to minimize latency but that's just placing a lot of regional caches near your users. The nearest place is in their actual browser -> offline first is the future
  • deleted 4y ago
    [deleted]
  • deleted 4y ago
    [deleted]
  • timw4mail 4y ago
    Client-side storage sucks, especially if you want to visit the same site from multiple devices. Without more code to sync this data, it's not great.
    • tlarkworthy 4y ago
      Being dependant on a reliable internet connection sucks, especially when travelling. SSR just won't work for mobile. With offline first, the client is the lowest latency server possible. Yes you should sync too. Offline first, not offline only
• pookha 4y ago
  WASM-side rendering. :)
  • The_Colonel 4y ago
    Getting shivers, sounds like reincarnation of Flash websites.
    • thorncorona 4y ago
      Still haven't replaced half the functionality of flash websites. So many flash games are gone forever.
      • imbnwa 4y ago
        > Still haven't replaced half the functionality of flash websites. Nor the intuitive tools to create their behavior
• silver-arrow 4y ago
  Much more prefer the htmx way of SSR parts of the page dynamically. Also, totally server-side agnostic, so we can use what we prefer. Clojure in our case. https://htmx.org/ https://htmx.org/
  • robertoandred 4y ago
    So any change in the UI means sending a request to the server, waiting for it to render, and waiting for that response with the new markup?
    • silver-arrow 4y ago
      Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns. As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button that will call for the TR HTML chunk from the server. You can imagine replacing all the rows for a paging click etc. Again check out the example for cool stuff.
      • robertoandred 4y ago
        Sounds pretty slow. At least a second before the UI responds to any action?
        • berkle4455 4y ago
          What sort of slow backends do you work with? My PHP htmx application responds in ~30ms including network transmit. Even if you’re across an ocean it’s maybe 300ms.
          • b4je7d7wb 4y ago
            300ms feedback on user action is unacceptable. But I read another comment saying there can be loading indicators so in that case its fine.
• brundolf 4y ago
  I love Deno, I hope it succeeds, but I'm disappointed to see them so confidently publishing a broad assertion like this that's very weakly argued, and heavily biased towards promoting their own position in the stack > Compatibility is higher with server-side rendering because, again, the HTML is generated on the server, so it is not dependent on the end browser. Excuse my bluntness, but this is complete nonsense. Browser incompatibility in 2023 is mostly limited, in my experience, to 1) dark corners of CSS behavior, and 2) newer, high-power features like WebRTC. #1 is going to be the same regardless of where your HTML is rendered, and if you're using #2, server-side rendering probably isn't an option for what you're trying to do anyway. I can confidently say browser compatibility has roughly zero effect on core app logic or HTML generation today. > Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase. This, again, is totally hand-wavy and mostly nonsensical. It's entirely dependent on what kind of app, what kind of features/logic it has, etc. Server-rendering certain apps can definitely be simpler than client-rendering them! And the opposite can just as easily be true. > Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. This is only partly true, and it's really the only partly-valid point. Modern statically-rendered front-ends will show you the initial content very quickly, and then will update quickly as you navigate, but there is a JS loading + hydration delay between seeing the landing page content and being able to interact with it at the beginning. You certainly don't need "a desktop...with a wired internet connection" for that part of the experience to be good, but I'm sure it's less than ideal for people with limited bandwidth. It's something that can be optimized and minimized in various ways (splitting code to make the landing page bundle smaller, reducing the number of nested components that need to be hydrated, etc), but it's a recurring challenge for sure. The tech being demonstrated here is interesting, but I wish they'd let it stand on its own instead of trying to make sweeping statements about the next "tock" of the web trend. As the senior dev trope goes, the answer to nearly everything is "it depends". It shows immaturity or bias to proclaim that the future is a single thing.
  • adeon 4y ago
    +1 agreed. There are some pretty crappy bloated client-side apps but when it's done well and it is appropriate for the app in question, it's amazing. I've been playing novelai.net text generation and I think their app is mostly client-side. It's one of the most responsive and fast UIs I've seen. Also, the article has this sentence: "Performant frameworks that care about user experience will send exactly what's needed to the client, and nothing more. " Ironically, a mostly client-side app that's only loaded once, cached, and is careful about when to request something from the server, might be more bandwidth friendly than a mostly server-side app.
• Glench 4y ago
  Shoutout to Sveltekit which does SSR and client-side navigation by default! https://kit.svelte.dev/ https://kit.svelte.dev/
  • mmcnl 4y ago
    Next and Nuxt also do this.
• bool3max 4y ago
  "Server-side rendering" is destined to rule the future purely because of control. In the future consumer devices will be simplified, much more streamlined, and completely locked down. They will be used for the single purpose of displaying streamed, pre-packaged, pre-layed-out content from servers.
• amadeuspagel 4y ago
  You can do HTML templating directly in JS using tagged template literals[1], and a library to deal with problems like XSS attacks[2]. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]: https://workers.tools/html/ https://workers.tools/html/
• lbriner 4y ago
  The thing that went wrong with front-end frameworks imho was that instead of being what was promised: you could update UI elements with NO NEED to contact the server at all, only posting back when something needed persisting, instead it became an excuse that every action on the front-end needed to call an API or 3 so we've ended up with over-complicated apps that instead of not relying on the backend are relying on it more than ever. Any little glitch, slowdown or unavailability is affecting you not only once on page load but potentially with every single interaction. To make it worse, a lot of backend interactions are not made interactively or synchronously where the user might expect to wait a little while, they are made in the background causing all manner of edge cases that make apps somewhere from very slow to virtually unuseable. I guess it's that old adage that people will make use of whatever you offer them, even if they go too far.
  • deleted 4y ago
    [deleted]
• FpUser 4y ago
  The future is not to stick to a single religion but to apply one's brains when architecting solution as it all depends on multiple factors and there are no silver bullets in this universe.
• Animats 4y ago
  I'm always amused to hear web types speak of grinding HTML, CSS, and JavaScript down to somewhat simpler HTML, CSS, and JavaScript as "rendering". Rendering, to graphics people, is when you make pixels.
  • deleted 4y ago
    [deleted]
  • pvg 4y ago
    It's consistent with the use of 'render' or 'paint' to describe what a UI component does to, well, render itself. For most UI systems this has involved higher level APIs than directly pushing pixels for a long time.
  • deleted 4y ago
    [deleted]
• gavinray 4y ago
  The article seems to contradict itself: The first example shows the server rendering a handlebars template and then sending that as a response to the client -- it's then stated that this "isn't true SSR" Then the same thing is done without a template language, using strings instead, and this is some different kind of SSR altogether and the "true SSR". Which also seems to insinuate that only JS/TS are capable of SSR? Server-side rendering! Well, kinda. While it is rendered on the server, this is non-interactive. This client.js file is available to both the server and the client — it is the isomorphic JavaScript we need for true SSR. We’re using the render function within the server to render the HTML initially, but then we're also using render within the client to render updates.
  • deleted 4y ago
    [deleted]
  • brundolf 4y ago
    I'm not sure it's a "contradiction" so much as a weird bending/re-branding of the term "server-side rendering". One of many issues with the article
• ravenstine 4y ago
  The future of the web is most web developers losing their jobs for failing to be good stewards of their platform.
  • deleted 4y ago
    [deleted]
  • sublinear 4y ago
    How can there be a future if nobody develops it anymore? I think it's clear the opposite is happening. Do you mean frontend-only devs losing their jobs? That's also unlikely since web dev went full stack over a decade ago. People don't build SPAs just because they don't know how else to build a web app. If you have specific examples of crappy SPAs you should blame that shop for sucking, not the concept.
  • cgdub 4y ago
    The future of the web is web developers creating more work and thus more jobs for web developers. It's the same reason Java, with all its boilerplate, is so widely used.
• gwbas1c 4y ago
  Does anyone know the stats about what's being served? For things like blogs, server-side HTML with a sprinkle of client-side Javascript (or WASM) makes a lot of sense. But for applications, where you're doing, you know, work and stuff, in-browser HTML makes a lot more sense. The thing is, as a developer, most of the work is in applications. (It's not like we need to keep writing new blog engines all the time.) Thus, even though most actual usage of a browser might be server-side HTML, most of our development time will be spent in in-browser HTML.
• beej71 4y ago
  "But all that code is necessary to make our sites work the way we want." Yes, but, on the other hand, is it?
• bigmattystyles 4y ago
  If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties. Obviously, you want the standard DDoS and security protections, but this fact alone, has turned me off server side rendering alone. Isn't it also nice from a computation cost standpoint to let the client do the rendering? I suppose UX could suffer and for external facing apps, this is likely of the utmost importance. Happy to be educated if I'm unaware of something else.
  • the_gastropod 4y ago
    As an example, Ruby on Rails makes this relatively trivial using respond_to https://apidock.com/rails/ActionController/MimeResponds/respond_to https://apidock.com/rails/ActionController/MimeResponds/resp...
  • ttymck 4y ago
    What difference does it make, with respect to security, whether the server returns html or json that needs to be formatted into html? The computation for rendering (in every case I've seen, and I have to speculate in 80% of cases ever) is so trivial compared to the actual retrieval of the data to be rendered.
    • bigmattystyles 4y ago
      None really, I was not eloquent about it - just that returning well structured data makes easier to extract data. You could also argue that if you render locally, you might return data used only for rendering that's not output and that also leaves your server's boundary where it wouldn't be necessary to leave at all with SSR. But like you said, these are things that are not really security.
  • zelphirkalt 4y ago
    > Isn't it also nice from a computation cost standpoint to let the client do the rendering? Aside from all other implications, letting each client render the same stuff is a massive waste of energy and compute.
• w4eg324g 4y ago
  Idk Im not so much into web development but isn't ssr rendering much more expesive? I just move all the processing/calculation to my/server side instead of the clients. This means for a business with many clients I have to pay for the stuff that the clients themselves could have done instead...
  • ketralnis 4y ago
    Is it though? Is composing a response into a graphql or JSON or XML format that much more expensive than into an HTML format? Is {"comment": {"body: "lol"}} notably expensive than <Comment body="lol"/>
    • w4eg324g 4y ago
      I assume a modern webpage has some logic to it which besides the redering also needs to be processed and if you apply that to a scale of billions x years I guess yes. But as I said I'm not an expert in the field nor have I any numbers. It's just what I thought. Edit: Thinking of having only to serve a state once and having each action processed on the client side instead of making for each a call the backend which has to return a fully rendered page. Maybe I have a misconception goin on here!
      • cmoski 4y ago
        The server doesn't [have to] return the entire page on a change. Return small chunk of HTML or small chunk of JSON. There will be a small cost to do the HTML on the server but there is also a cost to do the HTML on the client: sending them 50000000000kb of JavaScript initially.
    • cafebean 4y ago
      Web page design will have to fundamentally change to accommodate surgically updating web pages, for the large overhead to disappear.
      • TrispusAttucks 4y ago
• EVa5I7bHFq9mnYK 4y ago
  Next step: server rendered PNGs. Browser not required.
  • deleted 4y ago
    [deleted]
• flippinburgers 4y ago
  The "modern" state of the web. I miss old school html with little to no javascript. It is all java in the browser all over again. Or flash. Same old same old. Very few websites need any of this stuff. It is just a bunch of junior devs wishing they worked for FB I guess ergo them guzzling react like there is no tomorrow.
  • deleted 4y ago
    [deleted]
• BackBlast 4y ago
  > Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. If you can reasonably cache the response, SSR wins on first page load, no question. On the first page dynamic render "it depends", can be SPA or SSR. 2nd page render a well built SPA just wins. "it depends....." Server CPU cores are slower than consumer cores of similar eras. They run in energy efficient bands because of data center power concerns. They are long lived and therefore are often old. They are often segmented and on shared infrastructure. And if the server is experiencing load, seldom an issue on the client's system, you have that to deal with also. Your latency for generating said page can easily be multi-second. As I've experienced on many a dynamic site. Using the client's system as a rendering system can reduce your overall cloud compute requirements allowing you to scale more easily and cheaply. The user's system can be made more responsive by not shipping any additional full page markup for a navigation and minimizing latency by avoiding network calls where reasonable. On dynamic pages, do you compress on the fly? This can increase latency for the response. If not, page weight suffers compared to static compressed assets such as a JS ball that can be highly compressed well ahead of time at brotli -11. I never brotli -11 in flight compression. Brotli -0 and gzip -1. This is for well built systems. Crap SPAs will be crap, just as crap SSR will similarly be crap. I think crap SPAs smell worse to most - so there's that. > Compatibility is higher with server-side rendering because, again, the HTML is generated on the server, so it is not dependent on the end browser. If you use features the end client doesn't support, regardless of where you generate the markup, then it won't work. Both servers and clients can be very feature aware. caniuse is your friend. This is not a rule you can generalize. > Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase. Meh. Debatable. What's hard is mixing the two. Where is your state and how do you manage it? If you're primarily a backend engineer the backend will feel more natural. If you're primarily a front end engineer the SPA will feel more natural.
  • roncesvalles 4y ago
    Yes it's totally moronic. In fact we should be moving more server-side work to client machines, with WASM and such.
  • 4y ago
• Existenceblinks 4y ago
  There are 2 things that are orthogonal in current trend. This SSR buzz is not actually selling Server Side Rendering, they are selling 'one language to rule them all' (they call this dumb name "isomorphic"). Therefore, they are not solving all the problems of client-server + best UX constraints. Basically the problems we have all this time comes from: 1) There's a long physical distance between client and server 2) Resource and its authorization have to be on server. 2) There's the need for fast interaction so some copy of data and optimistic logic need to be on client. The "isomorphic" reusable code doesn't solve [latency + chatty + consistent data] VS [fast interaction + bloat client + inconsistent data] trade-off. At this point I don't know why they think that is innovation.
  • deleted 4y ago
    [deleted]
• MentallyRetired 4y ago
  It depends on what you're building. Choose the best tool for the job. Every time. Don't just default to your favorite.
• blank_fan_pill 4y ago
  IME the big gains nearly always come from how data is surfaced and cached from the storage layer. You may get some nominal gains from sending less JS or having the server render the html, but IME the vast majority of apps have much bigger wins to be had further down the stack.
• xrd 4y ago
  I've been using svelte for years and love it. I've been using sveltekit for years and still struggle with it. With sveltekit, I'm never really sure when to use prerender. I'm never sure how and where my code will run if I switch to another adapter. With pure svelte, my most ergonomic way of working is using a database like pocketbase or hasura 100% client side with my JavaScript, so the server is a static web server. It's got real time subscriptions, graphql so my client code resembles the shape of my server side data, and a great authentication story that isn't confusing middleware. I'm sure SSR is better for performance, but it always seems to require the use of tricky code that never works like I expect it to. Am I missing something?
  • another_story 4y ago
    In Sveltekit it's SSR on first load and then client following as the components in that page change, as far as I know. How SSR is done, not where it's done, depends on the adapter. It's always server first unless you specially opt out.
• henning 4y ago
  But all that code is necessary to make our sites work the way we want. It's necessary to make shitty websites that are impossible to load on slow/flaky connections.
• koromak 4y ago
  I feel behind here, my company doesn't do any SSR and theres basically no way we could port it over. Definitely missing out on some key concepts. I could build some SSR apps on my own but like, the real hard stuff about development comes >1 year in when you start running into those deep complexity issues. Can't really simulate that in a tiny pet project.
• klysm 4y ago
  It’s also totally fine to not SSR if the benefits aren’t important to you.
• eric4smith 4y ago
  Most SPA is totally unnecessary and a big waste of time. People are worrying about the speed of SSR when they should be worrying about the developer time on the client which is several orders of magnitude more. I think people have fallen in love so much with complex Javascript frameworks that they’ve forgotten how easy it is to get to an MVP with SSR. Speed is important. Speed of development is even more important for businesses in this era who have to get to revenue faster. And that’s why things like Phoenix LiveView and its counterparts in other languages is catching on so quickly. People are getting fatigued with the latest flavor of the month JS framework. But what do I know… I’m just a lowly “developer” working for crumbs. Never even finished a CS degree. Sigh.
  • zarzavat 4y ago
    For simple projects it really doesn't make much difference. Depending on your available tools, client-side or server-side rendering might be easier. In the end the only difference is what is going down the wire: data or HTML. That said, client-side rendering is strictly more general than server-side rendering. So I prefer to use client-side rendering everywhere so that I don't have to switch between two different modalities and maintain two sets of tooling (or worse switch in the middle of a project!) I gather this is against the current fashion but whatever.
    • DangitBobby 4y ago
      There comes a point in a project where the amount of client-side features requested makes you wish you had started with a fully-fledged modern framework like React. New features could be a single React component plus some updates to existing callbacks, and a new API call, but instead requires adding to a big accreting ball of HTML templates and a hodge-podge of vanilla (and maybe jQuery) js amounting to a bespoke framework that someone had to develop to manage the complexity. I absolutely love Django and old-style web frameworks, but they are not without their own complexity risks.
    • eric4smith 4y ago
      Makes HUGE difference. All the front-end work is another complete app with all the work that entails.
• cutler 4y ago
  What on earth does this tangled mess "simplify"? I've been at it with web dev for over 20 years and I was left scratching my head. The trouble with going down the JS rabbit hole is that you lose perspective on simplicity. **d help us if this becomes the new hotness. Oh, wait it already is. Oh well, until next month ...
  • chrischen 4y ago
    Simplicity is a facade. Great experiences are often complex behind the scenes. The JS ecosystem just tends to splay things open so the complexity is visible.
  • Existenceblinks 4y ago
    I still don't get it. We went from great backend languages with widgets approach on frontend to letting the whole shiny thing taking over the whole system and impose weakness here and there in architecture. My theory is that incompetent technical leads or CTOs reading too much tech twitter but not immune to all the echo bullshit.
    • ebiester 4y ago
      I don't remember those as the good old days, especially on true web applications. I remember more bugs than I'd care to recount with the back button and scope and that's not even talking about having to simultaneously think in JavaScript and your server side rendering language of choice. I also think there is a lot of room for multiple choices. For web applications, I think server side rendering as a default is a poor choice. For information conveyance, I think server side, or even pure static sites, makes a lot of sense. What problem are you trying to solve?
• gardenhedge 4y ago
  I use Remix for this. Remix is 4 things: A compiler A server-side HTTP handler A server framework A browser framework You can actually use Remix as just a server-side framework without using any browser JavaScript at all.
• benatkin 4y ago
  Haha. Lolnope.jpg
• cyanydeez 4y ago
  Am fairly certain the move back to the server has more to do with the development of heavy AI data modelling that can't be offloaded to the client. Don't believe the tech itself is Anything but a sign of where the utilities are moving
• floodfx 4y ago
  If you are looking for server-side rendering that enables rich, react-like user experiences, check out LiveViewJS (http://liveviewjs.com http://liveviewjs.com). Supports both Deno and Node runtimes. (Full disclosure: am author)
• nubinetwork 4y ago
  > JavaScript got good "A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete." - would like to have a word with you...
• WuxiFingerHold 4y ago
  There are only few use cases, where the new kind of SSR (with hydration) is worth it. An example are e-commerce sites where you want the customer to see all your great products as soon as possible and then some seconds later to be able to interact with your side fluently to buy something. These kind of scenarios paired with low end devices are the only proper use case. And I say consciously "only proper" because SSR comes with downsides as well: - SSR is always slower than static sites - SSR is often slower than CSR - especially when using a small and fast framework like Solid, Svelte or Vue3 - When rendering on the edge and using a central API (e.g. for the DB) SSR is always slower when interacting with the site than CSR because of the extra hop from your central API to the edge to the browser instead of from the central API directly to the browser - SSR is always more complex and therefore more fragile, however this complexity is handled by the frameworks and the cloud providers - SSR is always more expensive - especially at scale. - Traditional SSR with html templates will scale your site much better, simply because traditional languages like Go or Java or C# are scaling much better than NodeJS rendering the site via JS We owe the technology of the "new" SSR and genius stuff like islands many very smart and passionate people. Overall, this article not balanced at all. It is pointing out only some potential benefits. It simply is a marketing post for their product.
  • benatkin 4y ago
    > It simply is a marketing post for their product. For something that could be a single point of failure, like Cloudflare workers was according to this post: https://news.ycombinator.com/item?id=34639212 https://news.ycombinator.com/item?id=34639212 Edge workers are cool and all but if you don't need them, why add them as an intermediary / source of lock-in?
  • simonhorlick 4y ago
    Have a look at Qwik, it’s a new framework from the author of Angular. It does SSR without the need for client-side hydration. It’s fast and immediately interactive. I’m really hoping it gains some momentum because I’d love to use it in some client projects.
    • aatd86 4y ago
• ericls 4y ago
  The claim that server side rendering is faster than client side rendering is interesting.. How come one machine(the server), is better than 1000 machines(the client)?
  • stingraycharles 4y ago
    Perhaps most significant is that a lot of data, state that is needed to render the content doesn’t have to be transferred to the client?
    • zeroonetwothree 4y ago
      If you need to show data to the client then you need to transmit it, either in JSON or HTML. If you don't need to show it then why are you transmitting it? But realistically the amount of data is likely small for most applications and it's probably not the bottleneck.
• slimebot80 4y ago
  Note: Remix is not built on React, as the article states. Of all the new ways of thinking, Remix is the leader in not promoting a specific paid delivery platform. So in that sense I can see why people might want to mitigate its advantages by trying to tie it to React. (having said that, Shopify might tie it down more, but I see no evidence so far)
  • Alifatisk 4y ago
    I thought Remix was buiit on top of React? Like Nextjs.
    • DangitBobby 4y ago
      Remix is a React framework.
• zeroonetwothree 4y ago
  > Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. I don't see why we should assume the server is faster at processing the input data into HTML than the client is. It could very easily be that the client device does this faster. SSR additionally prevents progressive rendering, since you must generat eall the HTML ahead of time, which can make pages feel slower. Also HTML+JS data size can be larger than data+JS size (and you /may/ need the data anyway for the SSR version to do hydration). Of course all this varies, which is why it's silly to claim a general principle.
  • mmcnl 4y ago
    Performance is not _only_ determined by the processing time. Downloading the JS bundle and parsing it takes a lot of time. There's no need for that on the server. First page load is always very slow for CSR. Any client-side navigation after that is fast. SSR has a low initial page load and uses client-side navigation after that.
• albertopv 4y ago
  "A fully server side rendered version with isomorphic JS and a shared data model" Seriously, how did we get there? Having dealt with jsp, jsf (myfaces, trinidad, adf...), asp.net, asp mvc, angular, plain html/css/js, how is is possible for FE web dev to be such a mess? So much complexity, for what? How many have to deal with millions of visit per day? Or even month? It seems to me history is quickly forgotten and new generations know very little about the past. Keep it simple, please.
• 0x445442 4y ago
  The problem is more fundamental and it’s this; web apps are broken and have been from the beginning. They were created to solve the problems related to software distribution and updates but these problems were solved in the early 2000s when broadband became prevalent and it was no longer painful to download large software packages. The early straw man was that downloading apps was too daunting a task for users and yet some how they managed to download and update email clients, word processors, iTunes and ironically browsers themselves. Since I began my career in 1995 I’ve seen application architecture pundits proclaim the correct way to develop applications go from thick client native to thin client native to thin client web to thick client web back to thick client native (iOS & Android) and now, according to the article back to thin client web. I’ll submit the best model is thick client native using the “web” as a communication backbone for networked features.