27 ms·

The absurd complexity of server-side rendering

• Daishiman 5y ago
  The complexity of web development frontend itself is just absurd. The mess of dependencies, the mess of language transpiling, opaque abstract functions with unreadable call stacks, asset management, sync vs async, the random best practice of the week, etc. I look at the state of web pages and apps and it's not even for the betterment of user experience! Hacker News and old.reddit.com still provide the smoothest, fastest experience at the cost of having to zoom in every once in a while, but the price is worth it.
  • atoav 5y ago
    I handwrite all my CSS directly in the browser and the only "dependency" I use is a reset.css. The zooming issues some of those old themes have can all be solved with a modern css grid template (one for smartphone, one for desktop). Needless to say sites like these can be blazing fast. I only use js for small things like maybe hiding some header when scrolling down (no jquery, handwritten vanilla js with maybe 20 linws of code), but even that would not be strictly needed.
    • kingcharles 5y ago
      And even CSS resets are getting close to zero these days.
      • atoav 5y ago
        That is true and very fortunate, I noticed how this is getting less and less of an issue over the passt years.
  • yoyohello13 5y ago
    My org just bought a professional bootstrap template. It takes 3 build tools and 1500 node packages just to build the SASS into a CSS bundle. It boggles my mind that this is normal in the front end world.
    • ushakov 5y ago
      only 1500? you got lucky! gatsbyjs (React framework) has so many dependencies it breaks GitHub's dependency graph https://github.com/gatsbyjs/gatsby/network/dependencies https://github.com/gatsbyjs/gatsby/network/dependencies
      • dimgl 5y ago
        This is absolutely absurd. This is ammunition for others to not take the Node.js community seriously.
    • icedchai 5y ago
      I ripped out one dependency, and it dropped build times in a recent project by an entire minute! Turns out that one dependency had 100's of megs in transitive dependencies...
  • robertoandred 5y ago
    I take it you haven't taken a look at backend lately. Vagrant? Or Docker? Composer? Maybe Drush. Will this plugin break? Is it even still actively maintained? Which database? Are we still on the NoSQL fad? Maria, or postgres or mysql? And does my production host support my language version, and oh god another php vulnerability
    • gmfawcett 5y ago
      There's maybe two of those questions that you actually have to care about as an architect. Nobody's forcing you to chase fashions except you.
    • yen223 5y ago
      Frontend folks have an excuse. They cannot avoid using JavaScript, since they're limited by what browsers support. Backend developers chose to write mountains of yaml
      • qpiox 5y ago
        I am a proponent of server-side, use Apache Tapestry for most production apps and have only one yaml file in all the projects.
      • richwater 5y ago
        I recall a couple of years ago when Kubernetes was all the rage and jesus christ the amount of YAML was unbelievable.
    • Daishiman 5y ago
      I have done nothing but backend for a decade. Docker's been around for the past 6 years and still going strong. Database? Postgres, always. You have to bend it so far until it breaks it's not even funny. If you need something else, you'll now. Backend lang? Python. Framework? Django. Need data munging? NumPy/SciPy/Pandas/PySpark. Need a really high speed component? C will do, Rust if you feel fancy. OS? Ubuntu, or Debian. They'll do well. Again, you need to have really, really good reasons to use anything else. Of course there's alternatives! But there is absolutely no reason to move away from this stack. For some reason frontend developers seem to be either on a constant treadmill of moving technologies, or being stuck with subpar old tech with clear deficiencies.
  • phist_mcgee 5y ago
    I wouldn't exactly call clicking on the 'reply' button, and loading a brand new webpage, typing this comment, pressing the 'reply' button again, and then getting sent back to the original webpage 'smooth'.
    • Blackthorn 5y ago
      But at the same time, if you wanted to get away from that and have replies inline, that doesn't require very much Javascript at all! It can just be incrementally added to the page you already have with little fanfare.
    • lelanthran 5y ago
      > I wouldn't exactly call clicking on the 'reply' button, and loading a brand new webpage, typing this comment, pressing the 'reply' button again, and then getting sent back to the original webpage 'smooth'. OTOH, making a reply button that drops-down a textarea with "save"/"cancel" buttons requires about 30 lines of Javascript. And yet, almost all "modern" sites that have only this functionality has megabytes of dependencies. Maybe both extremes are bad, and Javascript is like adding salt to food - too little and you'll be able to eat it, but won't enjoy it. Too much and you won't even be able to eat it.
• e67f70028a46fba 5y ago
  throw all that complicated stuff away & use htmx generate html the same ol’ way you always have safe & effective modern hypermedia
  • bdlowery 4y ago
    Just use PHP.
• donatj 5y ago
  Call me old fashioned, but PHP still gets the job done better than just about anything else.
  • pphysch 5y ago
    And usually leads to a BBOM architecture
    • metadat 5y ago
      For the uninitiated, BBOM = Big Ball Of Mud.
    • gmfawcett 5y ago
      I have colleagues using Laravel, and there's nothing muddy-ball about their apps at all. Their code is tidy, modern, readable, and clearly maintainable. In terms of practical effect, frameworks influence developers more than languages do.
      • eurasiantiger 5y ago
        This was my PHP experience with CodeIgniter 15 years ago. Nothing new under the sun.
        • gmfawcett 5y ago
          That's good, I think? I'm not claiming that Laravel was the first or the best PHP framework, just that they were using it. (Admittedly I assume it's a reason their code is so well organized.)
          • eurasiantiger 5y ago
            Laravel inherits its organisation from the underlying Symfony 2 framework, just like Drupal nowadays.
            • 5y ago
• marcosdumay 5y ago
  Hum... You mean JS needs generic monads? TypeScript supports them, doesn't it? This shouldn't be too hard to fix, but it's a matter of rewriting or encapsulating all of the core language's API.
  • epolanski 5y ago
    What does any of the gist has to do with monads.
    • boloust 5y ago
      Principled, explicit handling of various function colours. If implemented like Fantasyland, probably a terrible idea.
      • epolanski 5y ago
        Which, again, has very little to do with any of the gist.
        • Widdershin 5y ago
          Hiya, I wrote this gist. I do actually think Monads or similarly expressive type constructs would allow us to eliminate this class of issue for good. Hopefully the rise of Wasm makes this problem irrelevant for functional programmers, but that’s a whole other can of worms. That said, it’s probably impractical to try and achieve that sort of type safety in JS via the Monad route, but maybe a clever TypeScript extension could be devised.
          • epolanski 5y ago
            Monads are just type constructors with two operations: bind and pure. I fail to see the connection and why do you need a type constructor with a bind and pure operation at all to solve SSR.
            • 5y ago
• bob1029 5y ago
  I've been saying it for years - the hard part is not "server side" vs "client side", it's making sure the state stays consistent between those 2 buckets. If you want to remove the hell from your life, you need to be all in on one or the other. For us, we've been keeping all state server-side using things like Blazor and hand-rolled js-over-websocket UI frameworks. We never have to worry about more than ~10k users, so this works out great for us. If we were webscale, we'd have to consider client side options.
  • deleted 5y ago
    [deleted]
  • jamal-kumar 5y ago
    Even in smaller applications this is incredibly relevant. I've recently written something that's meant to interface on a local area network, just controlling something on another computer, literally just one or two users at a time -- thing is the precision of floating points are a big thing here, and we have to consider that. So all of the bignum stuff had to stay server-side in C++ after much messing around doing math client side in javascript only to learn the hard way how completely broken that is. Fun fact - You can't maintain state when floats start to drift off of values they were supposed to land on due to javascript's crappy math libs
    • xboxnolifes 5y ago
      Javascript can get messy even if you just need integers, since even naively used integers are stored as doubles. This means that sending a random 64-bit identifier from a server to a client and just trying to read it as an int can give the wrong value if you aren't careful.
    • petrocrat 5y ago
      Did you try to use javascript's BigInt data type?
      • jamal-kumar 5y ago
        I clearly stated we were working on floating points here, ones originally provided by the c++ application. There was a thought to just make everything into big integers here but for this particular application it really just was the realization that all of this stuff was better off server side anyways for state maintenance reasons
• jvanderbot 5y ago
  I opened this thinking it would lament the challenges of server side frameworks and templating. But those things seem so, so sane and simple compared to the mess I just read about. It's worse than I could have imagined. Who thinks that's a good workable solution? Who's idea was this?
  • pphysch 5y ago
    Adtech needs a lot of JS to work. JS to determine how long they are hovering over this and that element, how long this or that ad is in their view, and so on and so forth. The logical conclusion is that every single HTML element needs to be wrapped in a bit of JS somewhere. Nothing should happen in the users browser that can't be monitored by JS.
    • giantrobot 5y ago
      Adtech wants that JavaScript. It doesn't necessarily need it. Most of the metrics generated are ultimately worthless. They exist to slap together bullshit graphs to overwhelm clients with "data".
      • pphysch 5y ago
        Sure, analytics doesn't necessarily require JS, but the host client software absolutely does need it to create a gameified experience to attract and retain users over their competitors.
    • matheusmoreira 5y ago
      So adtech is ruining the web. Everything makes sense now.
      • aaaaaaaaaaab 5y ago
        "At that moment the monk attained enlightenment."
      • Keyframe 5y ago
• kraig911 5y ago
  I gave it a shot at one startup using next.js that wanted to pre-hydrate redux state, but also use tracking with session cookies et al the regular bag of beans. I spent maybe 6 weeks on it and basically I grew to realize I was in a miasma of pain. I didn't last much longer. I could've wrote the entire thing just vanilla js/css in probably a weekend... So I can commiserate with this.
  • jamal-kumar 5y ago
    I love starting off projects in vanilla JS because they actually get to a workable state most of the time without a lot of effort. Most of the time when you write stuff in vanilla js/ts you can just fit that logic in to a react or vue or whatever application framework afterwards if you really need all those bells and whistles. I think a lot of people start things off thinking they NEED to have all the authentication, cookies etc sorted out from the get go when really you just need your ideas in a working form first and stuff like HTTP basic auth is mighty fine for development
  • heavyset_go 5y ago
    I'm always impressed by the labyrinthine towers of JS and frameworks people create to ship out relatively simple sites and web apps. By impressed, I mean that I look upon them both in awe and in horror. And I'm guilty of building them myself, as well. One of the worst things is opening such a project that was written 5+ years ago by someone other than yourself.
    • lelanthran 5y ago
      >I'm always impressed by the labyrinthine towers of JS and frameworks people create to ship out relatively simple sites and web apps. By impressed, I mean that I look upon them both in awe and in horror. Well, then... brace yourself for the one[1] I intend to release in a month or so. I've been working on/off it for the last three years.[2] I'm hoping next month to actually build an application with it :-/ [1] A component library for client-side elements. [2] Spent about 8 hours in total on it, over three years[3]. Sometimes I need a deadline to finish stuff. Don't judge me, no one's perfect :-) [3] Still think it took fewer hours than learning React.
• stickfigure 5y ago
  SSR feels like an echo of JSF (that's JavaServer Faces for you youngins) - an exceptionally complicated way of doing simple things. IMO, SSR will follow the same arc in history - a brief period of popularity, followed by a lot of "what on earth were we thinking". Client side rendering is much simpler and cleaner.
  • trinovantes 5y ago
    SSR is generally for SEO and performance
    • hnov 5y ago
      If you need SEO and (to a lesser degree) performance, you're likely serving content rather than an application and likely could've done with SOR (a new moniker I've come up with, Server Only Rendering).
      • trinovantes 5y ago
        Except that many applications have public content that you want to be indexed and interactive for the user e.g. forums and ecommerce
        • tored 5y ago
          For e-commerce probably checkout and perhaps the buy button needs to be interactive. Rest of it can be normal pages. You can use different approaches depending on what you serve.
        • ryanbrunner 5y ago
          I've never seen an ecommerce or forums app that wouldn't be done better by more traditional techniques vs. an SPA. Interactive doesn't need to mean "driven entirely by Javascript", and also sites that use entirely HTML generated by a server can still use Javascript (there's even frameworks for this!)
        • hnov 4y ago
• stevebmark 5y ago
  In Javascript SSR, if you need the same logic on the client and server, define an API module + interface. Make a different API bundle on the server that calls NodeJS functions, file reads, whatever, directly. Make an API bundle on the client that makes AJAX requests to your API endpoints. Now your Javascript can call the same `api.fetchWhatever()` method, and await the result, and it works on the client and server (if you need it). It's a very nice pattern.
  • epolanski 5y ago
    Thus, you are confirming there is a hugh level of complexity. I want to add something else on top of what's in that gist: ssr is slow, rendering an application twice (on server and client) is just slow. We only do that for cache and seo, every other page suffers.
    • stevebmark 5y ago
      I'm not sure what about two bundles causes a huge level of complexity. Granted, I use Next.js, it does all of this out of the box. SSR is fast, it's provably faster than client side rendering for first load. You can optionally do client side hydration, so the time to meaningful content is fast from SSR, and subsequent page loads are done SPA style (if you want). It's never a fair comparison, but Stackoverflow is entirely SSR (not Node.js) and it's very fast. Also, all forum software, which is SSR, despite being 20-30 years old, is usually faster than a SPA. The Jamstack is a recipe for loading spinners, not speed.
      • com2kid 5y ago
        > Also, all forum software, which is SSR, despite being 20-30 years old, is usually faster than a SPA. Only because crap tons of hardware got thrown at the problem. I remember when forums were multi-seconds to load each page. It sucked. People complain about reddit a lot, but even on mobile, the reddit website is fast. It may be janky at times, but navigating between comments on stories is under a second, loading more comments is, well, not fast, but quick. Hacker News is notably one of the few non-crap forum sites out there. phpbb used to be everywhere, and it sucked everywhere. Up until 2012 or so, the old dial up BBSes from the mid 90s had a better user experience than the latest and greatest internet forums. (of course BBSs only had 1 client at a time, a much easier problem to solve!) And yes, phpbb works now, because now a cheap host has an SSDs with gigs of RAM. To do the equivalent of a what a 486 running DOS did back in 1993.
• Animats 5y ago
  This isn't real "server side rendering". This is just generating simpler HTML. Real rendering on the server would mean sending a canvas or an image or video, like "cloud gaming". All this complexity seldom translates into sites that do much. There are real "applications in the browser" that let the user do something, but those are rare, and most are toys. Most of them could have been written in Flash, anyway.
  • colejohnson66 5y ago
    SSR in terms of webdev means what this post describes: generating HTML on the server. “Rendering” is a bit of a misnomer; a more apt title would be “server side HTML generation”, but that’s a bit long. The alternative to SSR is CSR (client side rendering). Think React SPAs.
    • Animats 5y ago
      I know, I know, the webcrap crowd uses that terminology. Nobody else does. As someone who spends most of their time right now inside of 3D game-type renderers, I have a hard time thinking of cranking out HTML as "rendering". What does that crowd call the part of the browser that does layout and display?
      • jclem 5y ago
        Layout and paint. I don’t think using the term “rendering” for interpolating data into a template is anything new, though, nor is it bad or even confusing that it means one thing in the context of computer graphics and another in the context of programming language templates. ¯\_(ツ)_/¯
• kodah 5y ago
  I already know I'm off my rocker (and my lawn with that phrasing) but I really wish the browser supported Python as a language instead of Javascript. I can pickle Python, send it to a client, and run it. Combine that with everything else Python 3 has brought to the table and I'd have a language that runs client side that I can depend on and that I love.
  • eatonphil 5y ago
    Brython, Pyodide, Coldbrew. You do have options. ;)
  • Gigachad 5y ago
    Maybe some day WASM will become the default and you will just compile whatever you feel like to send out.
  • giobox 5y ago
    Isn't this supposedly one of the magical things WebAssembly gets us? While I can sympathise with wanting <insert your favourite language here> in the browser, I'm not sure its so great in reality and I'm really scared of things like Pyodide/Blazor/<programming language to web asssembly> from a debug perspective. Today the fact its JS everywhere client side for most part has made our lives hugely easier in a lot of regards. A world in which many languages can compile down to some web assembly and run will make debugging and developing web apps even more complicated than it already is...
  • lawwantsin17 5y ago
  • boondaburrah 5y ago
    I'm giving Haxe a try for that reason. It's not python however.
  • crate_barre 5y ago
    The browser doesn’t even have modern JS. Well, I mean it does, but for awhile it didn’t. We consider modern history to be anything past 1815. So in web terms, if you had to section it, modern web history is like maybe 2010 onwards? In those years we transpiled new Ecmascript to old ecmascript. So, nothing is stoping us from tranpiling Python to new or old ecmascript. But, I think you’ll see that it won’t solve much. You are just turning one turd into a lesser turd. The problem is fundamentally deeper. The browser and web server tech was not built for app development. That’s the bottom line.
• gfodor 5y ago
  Phoenix LiveView provides a sane solution to this problem.
  • purplerabbit 5y ago
    What if you need optimistic updates?
    • gfodor 4y ago
      You can do optimistic updates with JS
• 65 5y ago
  I've been testing out Alpine.js recently and find it to be very nice to use. You can have reactive state and most of the conveniences of React, but all in your HTML without a build step. I work with SSR React professionally and many times I yearn for being able to just use good old fashioned templating engines and client side Javascript - no builds or anything.
• thyrox 5y ago
  Laravel livewire / Phoenix liveview and a lot of new frameworks are now focusing on bridging this gap between ssr and clientside - almost trying to make it seamless. Though only time will tell, what can of worms that will open later.
  • arnorhs 5y ago
    to be fair, .net had stuff like that for ages. i've never used any of it though.
• codedokode 5y ago
  There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Hacker News. In all these cases, you can save on development time by writing just one application instead of two (server and client), and improve performance (no need to load multimegabyte JS applications and make multiple AJAX requests to display a page). Of course, there are cases when SPA-style application is better, for example: (graphic/circuit/text) editors, IDEs, mobile newsfeed-based apps - everything that resembles an app rather than a page with text, menus and images. But in these cases you usually don't need server-side rendering. And sometimes you cannot even use it - for example, if your code needs to know browser windows size to arrange objects on the page. So I think that SSR (running JS on server) is rarely useful.
  • temp8964 5y ago
    LoL. The truth is most sites don’t need tons of js, but we’re in the sad state where normal websites begins with heavy js framework, junky cookies, annoying notifications as a default. Then add more and more junks …
  • midrus 5y ago
    But it is trendy and fashion, so we still do it /s
  • beaconstudios 5y ago
    In my experience (having implemented React SSR a few times for different companies) it's usually applied halfway between the two, on simpler form-driven websites - process-driven screens, marketplaces, the kind of places where you want either the performance improvement of a prerender or the SEO friendliness.
  • qbasic_forever 5y ago
    VS Code is effectively a SSR IDE. Electron and node are the 'server' side of it and are necessary for interacting with the filesystem and all the native things browsers can't access (running processes, terminals, etc.). It has a somewhat complex RPC model (inherent to all Electron apps in general) where JS code on the browser frontend side has to make requests with JS code on the node side and vice-versa, just like most Next.js style SSR apps. It's a very similar ball of complexity for better or worse as mentioned in this gist/blog post, and in general very necessary as browsers are only taking baby steps to give full access to file systems, processes, hardware, etc.
• paxys 5y ago
  The common mistake teams make getting started with server-side rendering for React is thinking that your entire backend has to be contained in a single JavaScript bundle. Instead, use any language you want to set up your APIs and business logic. Then set up a fully independent pool of servers running Node.js whose only job is SSR. This setup skips over every problem the author mentions.
  • chrisco255 5y ago
    The newest versions of Next.js have API routes that are independently deployed as serverless functions, so they do not interfere with the SSR instance.
    • quickthrower2 5y ago
      Yeah, I have recently learned Next.js WITH that and so I haven't experienced the pain points. Also using Next.js with something like Firestore (etc.) is also helpful. Next.js seem to recommend delegating in their documentation (e.g. need a scheduler? Use Github actions).
  • notriddle 5y ago
    When I realized what the OP was describing, it honestly caught me off-guard. I had never heard of anyone attempting to colocate their API server and their Fastboot/Next.JS server in the same Node instance. Node is single-threaded. If you try to run lots of different things within the same Node VM, a runaway CPU-bound loop in your frontend can wind up causing the backend to lock up. Bad failure mode. If your API server is separate from your Frontend server, you don't just make maintaining it more reasonable (the "server colored functions" are now a strict subset of the "client colored functions"). You also get operational flexibility: run the Frontend server in an edge function system [1], while running the API server alongside your DBMS. Isn't that what edge functions are for? [1]: https://news.ycombinator.com/item?id=31084301 https://news.ycombinator.com/item?id=31084301
• Rauchg 5y ago
  Since the post mentions Next.js, it's worth calling out two streams of ongoing work that solve major painpoints of SSR: 1. A filesystem convention (`*.server.ts`) for more cleanly separating client and server component trees 2. The introduction of a Web standards runtime[1] for SSR. If anything, we're entering the best generation of SSR ever. We'll see new generations of apps shipping less JS to the client, rendering and personalizing at the Edge, closer to the user, and the infrastructure to support this will be serverless and economically every efficient. [1] https://nextjs.org/docs/api-reference/edge-runtime https://nextjs.org/docs/api-reference/edge-runtime
  • nawgz 5y ago
    Is it believed that you'll do less overall compute and bandwidth if you use serverless functions to execute (parts of your) client, in place of sending static bundles to the client and letting them execute it? I don't really get SSR. Isn't it more desirable to have more of the compute required to render the client done by the client machinery? I view this both as true in corporate and public web scenarios, surely it's cheaper to let the public render the SPA than it is to render it for them, surely in corporate this takes better advantage of already purchased machines with already installed programs instead of developer cycles wasted to recreate it, and surely it's better to have less server load and deployment complexity in both cases
    • chrisco255 5y ago
      Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently. Then, once loaded, any server-side data needs to be fetched from an API request and injected into the page in the proper place. Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the fully compiled HTML + CSS + JS as one static file. So you have to have some server-side logic regardless if you have the need for server-side data. The small amount of memory and compilation overhead by the server-side rendering function is more than made up for by the time saved on network latency. It's just not a significant amount of computation regardless. Importantly, the server-side is not loading a full DOM into memory before sending it down the pipe. It's just interpolating the resulting HTML/CSS/JS as if it were static after fetching the prerequisite data.
• togaen 5y ago
  SSR is the dumbest thing I’ve ever heard of. Client and server are different things, treat them that way. The whole web dev community keeps tripping all over itself to make simple things wildly complicated.
  • draw_down 5y ago
• chrisweekly 5y ago
  See https://remix.run https://remix.run for a modern, sane, progressive approach to server-based rendering w/ as-needed hydration.
  • Widdershin 5y ago
    Remix has the exact same issue unfortunately: https://remix.run/docs/en/v1/guides/constraints https://remix.run/docs/en/v1/guides/constraints
    • DangitBobby 5y ago
      Yep. But it does a pretty good job of communicating where the boundaries are and telling you when you've crossed them. It's not even close to a deal breaker.
      • Widdershin 5y ago
        Unfortunately that hasn’t been my experience. I learned about this problem after helping a very confused Remix user overcome this issue. I will give kudos to Remix for having a good docs page about this, something Next.js could do better (unless I just couldn’t find the docs). Also just wanted to say that I love your username.
        • DangitBobby 5y ago
          I agree that the lines are a bit more unclear in practice and in the documentation. It genuinely takes some experimentation. That said, I think Next.js has a good reputation for good reason. And thank you!
    • dimgl 5y ago
      This actually bit me multiple times. I started leaking server-side code to the client, which completely turned me off. Also I've been in several arguments with Remix community members as to why middleware is necessary for server-side frameworks and why there needs to be a global state option. I was going to evangelize them at my current gig... thankful that I didn't go down that route and made my own prototypes. There are solutions (such as implementing your own caching layer) but ugh, why.
• AYBABTME 5y ago
  I find this a very insightful application of the concept of colours to look at the problems of mixing code meant to run on slightly different and subtly incompatible runtimes, within the same code base, without calling out this distinction of "colour" by any particular mean of syntax, or tooling, or explicit documentation. It's a good observation that helps, at least me, shed light and give a name to this problem that many will have experienced and struggled with.
  • Widdershin 5y ago
    Thanks for this comment, this was exactly the point I was trying to get across. I’m glad you found it helpful.
    • lmc 5y ago
      I was never really a fan of the original 'Colors' article but I think the analogy works really well for this client-side vs server-side stuff. Red = client Blue = server Purple = either I think I will use this if I ever have to teach it.
• tedunangst 5y ago
  How can a small site like HN possibly work when SSR is so complicated?
  • sph 5y ago
    SSR isn't the classic model of server rendering. That one is easy. SSR is Javascript client code that also acts as cached server-side pre-rendering with subsequent hydration on the client. It's confusing I know.
  • ConsoleTVs 5y ago
    Ryan Carniato (@RyanCarniato) have a hackernews clone in every major framework with SSR support. Mostly made on streams as well!
    • dimgl 5y ago
      +1, I really enjoy watching his content. His deep dives into certain technologies is truly valuable, if a bit long-winded.
• etchalon 5y ago
  I'm convinced SSR is only a thing because of Lighthouse scores. Client-side rendering with client-agnostic REST APIs is a fantastic architecture. But noooooooooo we can't have nice things
  • lawwantsin17 5y ago
  • alserio 5y ago
    As a developer I like doing CSR apps. As an user I like when my sites are SSRed. There are people who are trying to bridge the gap. https://dev.to/ryansolid/server-rendering-in-javascript-why-ssr-3i94 https://dev.to/ryansolid/server-rendering-in-javascript-why-... https://dev.to/this-is-learning/conquering-javascript-hydration-a9f https://dev.to/this-is-learning/conquering-javascript-hydrat...
    • deleted 5y ago
      [deleted]
  • adamzochowski 5y ago
    because scraping and indexing the site is hard. because getting first response on super slow speeds doesn't accomplish anything because many js devs write buggy code that renders in their browser etc
  • DangitBobby 5y ago
    It's a nice architecture when the API devs get to throw stuff over the fence to the frontend devs. It's less nice when you are the guy throwing stuff over the fence and then running around the fence to catch the stuff you just threw over it. It makes you start to wonder if there's anything you can do about the fence. The answer is "yes."
    • langsoul-com 5y ago
• sph 5y ago
  In this thread: people confusing server rendering (like your old PHP) with SSR (same Javascript codepath for client and server, i.e. Next.js) One is easy, the other is the definition of leaky and crappy abstraction. This article is about the latter technology.
  • DangitBobby 5y ago
    Its a bit leaky, but I wouldn't call it crappy. What's crappy about it? Be specific.
    • sph 5y ago
      This article is a good start.
      • DangitBobby 5y ago
        I've read the article. The pain points exist, but they are not insurmountable. I'd go as far as to say they are being a bit dramatic.
        • grey-area 5y ago
          Compared to traditional server side rendering, the article describes a hellscape of self-imposed complexity. Why would anyone choose this?
          • DangitBobby 5y ago
            You choose something like react for the frontend if you need heavy interactivity, something closer to a desktop application than a traditional web app. Then you choose tools like Next.js that will do SSR for you so you can take advantage of how good browsers are at rendering HTML.
            • grey-area 4y ago
              The needs you describe are incredibly rare. Facebook for example doesn’t have heavy interactivity closer to a desktop app. You can also do interactivity just fine with Ajax. These frameworks bring nothing but complexity and confusion. Also, how good browsers are at rendering html has nothing to do with next js. Browsers don’t care where the html came from.
• galaxyLogic 5y ago
  What is meant by "server-side rendering"? Is it the same as server-side on-demand html generation? If so then I think the term "server-side rendering" is somewhat confusing. Your server is "generating HTML", not 'rendering" it. Rendering in my view means turning code (like HTML) into visual output.. So whether the server serves always the same HTML, or regenerates it for every request, or something in between, the client/browser still has to "render" that HTML into visual output. True server-side rendering I would think should mean the server renders HTML into a gif or jpg which then gets shown in the browser.
  • rodamaral 5y ago
    SSR always means outputting the first html as seen from the user when the app is fully loaded and ready to be interacted with. A SPA usually starts with a minimal, blank html file and a huge JS file that mounts the DOM structure and then the user can see something. SSR does the exact same thing, but on the server. From the user perspective, SSR seems faster. From a SEO perspective, SSR is better because there's some initial content on the page.
• jdrc 5y ago
  whats the reason behind all this endless JS race that s been going on for years. I only had to use it once and it felt like everything was prematurely overabstracted ending in more code doing less. It made me run back to php+jquery, which is more like a car engine rather than an modern abstract art statue. is it the overabundance of programmers? the fact that it makes them look busy? people liking wasting time recompiling most of the day? overengineering making people feel superior? it certainly doesnt feel healthy and makes one question whether the whole SV startup ecosystem is a cargo cult built on shaky grounds by people who are just apeing each other on everything, from design to backend.
  • fatbird 5y ago
    JavaScript based webdev continually makes the next thing you have to do seem easy if you just use this framework, that approach, the latest library for it, and the build tool that finally handles this case. It's a textbook example of the combination of the sunk cost fallacy and short-termism: you continually make amazing web stuff happen quickly by going into just a bit more technical debt. It's a technical debt pyramid scheme. The further you get, the more you're trapped by your previous decisions of convenience. It's an ecosystem addicted to quick fixes, no matter the cost.
  • 5560675260 4y ago
    Webdev shifted from making pages of content with some interactivity to web apps that live and maintain state on the client and occasionally query backend for some data. You don't need or particularly benefit from modern JS frameworks for somewhat interactive pages. But you absolutely can't do web apps with ad hoc jQuery and maintain your sanity.
• geenat 5y ago
  https://htmx.org/ https://htmx.org/ Having spent 36+ years in the computer industry, I consider the advent of htmx to be the first thing in web development to to attempt to pull the industy's head out of it's ass. Don't forget to include a solid remake of css in your project like tailwindcss. It also makes code much more readable.
  • thaumasiotes 5y ago
    > Read the docs introduction for a more in-depth... introduction. Heh. This reminded me of http://itre.cis.upenn.edu/~myl/languagelog/archives/000012.html http://itre.cis.upenn.edu/~myl/languagelog/archives/000012.h... . "PERSONNEL WHO ARE NOT AUTHORIZED TO BE IN THE HANGAR ARE NOT AUTHORIZED TO BE IN THE HANGAR"
    • PaulDavisThe1st 5y ago
      sign seen in Seattle on a housing project in the 90s: ALL ILLEGAL ACTIVITIES ARE PROHIBITED
      • thaumasiotes 5y ago
        That one's not redundant; it says that illegal activities (in addition to violating the law) also violate the rules of the housing project. That kind of thing is bog-standard in all kinds of contracts, because including a clause like that makes your illegal activity grounds for terminating the contract. (In this case, the prohibition on illegal activities presumably allows the project to evict tenants who are convicted of crimes.)
  • lmc 5y ago
    How well does it work for complex projects/component libraries? React is a pain in the ass but there's at least some established patterns for large projects.
    • fredrikholm 5y ago
      You will most likely be using a templating language to re-render the view with new state. If you're lucky your chosen language enables you to do that inlined in your function along with your normal workflow. Otherwise you now have template files, templating logic and domain logic across several files and you're right back where you started (accidental complexity), minus the JS.
• recursivedoubts 5y ago
  Hello. I'm here from 1999 and I'd like to help: https://htmx.org https://htmx.org
  • deleted 5y ago
    [deleted]
  • ryanbrunner 5y ago
    Probably more like ~2005. I was a web developer in 2001 and XMLHttpRequest still felt like secret knowledge that you only found out about by digging deep into Microsoft documentation (and wasn't well supported if you weren't using IE). Most people I knew were making pages interactive by targeting forms to iframes.
    • idkwhoiam 5y ago
      Some of us were using JAVA Applets to make async requests ;)
  • midrus 5y ago
    Say you're travelling back from 2099 and your comment still applies :-)
• silviogutierrez 5y ago
  Shameless plug: If you want seamless SSR with Django logic, but React templates, check out my project at https://www.reactivated.io https://www.reactivated.io . It's like HTMX but uses React, and the JS bits are rendered on the server. You can then hydrate on the client. The Reactivated docs site itself uses the project: https://github.com/silviogutierrez/reactivated/tree/main/website https://github.com/silviogutierrez/reactivated/tree/main/web...
  • dinkleberg 5y ago
    Setting up something like this myself has always been a pain and I’ve just stuck with DRF + React instead. Will need to give this a try, thanks for sharing (and building it)!
    • silviogutierrez 5y ago
      Yea using Django only for DRF APIs always felt limited. I want Django forms and form sets. Reach out if you have any questions! Email is on my GitHub profile.
• nsonha 5y ago
  article crticizes "the absurd complexity of server-side rendering" by starting with "In the olden days, HTML was prepared by the server..."
  • capn_duck 5y ago
    There's a huge difference between traditional server side web applications and the modern meaning of SSR. If you don't know the difference then this article probably isn't for you.
• ddaalluu2 5y ago
  You're all clueless.
  • abxytg 5y ago
    so clueless lol. missing the entire point
• canyonero 5y ago
  > If you're considering using one of these frameworks, I would recommend you carefully consider if the complexity is worth it, especially for less-experienced members of your team. Far too many folks seem to believe that complexity is a binary choice or that it can be avoided wholesale by choosing frameworks (or lack-thereof) to solve their problems. Truth is, when you're building software on the web, you're gonna have gonna have to make a series of decisions on where the complexity that you'll inevitably encounter should live. We're all simply making tradeoffs on where that complexity lives: the browser runtime, the build system, the type system, the server, the platform, their framework, your framework.
• diego_sandoval 5y ago
  > After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload every time that there's a non-trivial state change (usually triggered by user interaction). When the inherent complexity of the application means that there are state changes pretty often, doing a page reload so often would just kill the user experience, and using jQuery or similar libraries would lead to a spaghetti. Is that the reason for client-side rendering being the "default" in the realm of modern javascript? If that's the actual reason, then that seems reasonable, but I think that Javascript culture (frameworks, tutorials, articles) usually erroneously assumes that every application is a complex one with tons of state changes, thus assuming that client-side rendering is the only right way to develop an application (without counting "isomorphic" SSR which is just another way to create a spaghetti). Sure, if I don't like it I can just move over to Django, Laravel, etc. but it feels like I never get an actual explanation of why client-side rendering is the default in these js frameworks, it's just accepted as a fact of life.
  • dinkleberg 5y ago
    I can’t speak to the decisions on the parts of whoever is building the frameworks. But I will say the dev experience working on a frontend app using React, Vue, etc. is substantially greater than using something like Django templates. And I say that as someone who has written a great deal of both. I really wish I could be as productive in Django templates as I am with React, but alas. Once you go to component based UI development it is hard to go back. Especially when you get used to the high quality UI libraries.
    • fuzzy2 5y ago
      But then maybe Django templates are not so great? You can also have UI components in the backend. Interactivity can be a little tricky though.
    • christophilus 5y ago
• deleted 5y ago
  [deleted]
• jasfi 5y ago
  Nexus DocUI is server-side defined, but client-side rendered. It doesn't have real-time updates yet, you have to reload the page, but I'm working on a plan to implement that. Currently renders the front-end with Flutter, the back-end could theoretically be any language since it sends JSON to the front-end. https://nexusdev.tools https://nexusdev.tools
• mjfl 5y ago
  Sorry I'm gonna just stick with server-side rendering with Django templates. All web development 'advances' are a treadmill to nowhere, waste of time.
• pkrumins 5y ago
  That’s why I still use Perl CGI scripts. They just render.
• vmception 5y ago
  I agree with the Next.js people in that thread SPA+SSR has never been easier, and my experience (as of this year) is that its as easy as static websites. Even easier in some cases with making the CSS easier while all the bundles and optimizers to make builds are hidden. I think people need to rethink how they design their websites and complete concept of a viable business. I get the sentiment of the absurdity off web development but its successfully been abstracted away if you keep your app and idea simple. If you’re still doing gigantic web 2.0 apps with hundreds of views, microservices everywhere and API calls going every which way, thats the problem. The stack for those is ridiculous and not even necessary anymore. You can drive [hundreds of] millions of revenue without any of that these days, without even a user account flow or state management, the market is trying to tell you something.
• grey-area 5y ago
  The original server side rendering (HTML rendered on the server by your choice of language) is simple, efficient and most sites on the internet still use it, including this one. The article is talking about ‘modern’ js style server side rendering combined with client side rendering, which is of course a huge dumpster fire and encourages absurd complexity on both sides of the equation, starting with the fact the app is split in two.
  • midrus 5y ago
    It's mind boggling some people don't know you can render plain html on the server, or even submit forms without javascript. Such a basic building block seems to be fading away nowadays, even some times presented as a "novel" thing or a "feature" (eg: remix)
    • ConsoleTVs 4y ago
      We've gone full circle in JS-land already, and it will keep going. In circle...
• IceDane 5y ago
  What an incredibly boring, prosaic post which is almost completely devoid of anything useful. In fact, over half of the post is just the author waxing poetic about some tangentially related things. His arguments boil down to "To me, this seems like a bad idea." Well, OK buddy. Then don't do it. Meanwhile thousands of web developers have been doing it for years and it has never been easier.
  • Widdershin 5y ago
    This is a nice idea, but unfortunately my work involves helping customers with all sorts of stacks integrate our technologies. Rather than quit my job, it’s a bit easier to document and raise awareness about these issues. Unfortunate that you didn’t enjoy the prose, can’t please everyone.
• tonto 5y ago
  my personal worry, could be unjustified, but SSR seems to be much less secure compared to plain old client side stuff. sure, static client side is less seo friendly but...not going to compromise your servers! considering the fast moving and relatively patchy security of npm ecosystem...things like prototype pollution vulns are alerted almost weekly if not daily and you are lucky if a fix exists that you can upgrade to!
• zorr 5y ago
  Honest question: it's clear to me that the term SSR has been repurposed to mean this complex "generate html reusing ~same code on backend/frontend and then hydrate it" thing. What do we call the classic style where the server just renders html using a template language?
  • deleted 5y ago
    [deleted]
• saint-loup 5y ago
  Come on, Trisomorphic rendering or Distributed Persistent Rendering are pretty simple, basically these are just [insert joke about monoid in the category of endofunctors]. https://en.wikipedia.org/wiki/Hydration_(web_development)#Trisomorphic_rendering https://en.wikipedia.org/wiki/Hydration_(web_development)#Tr... https://www.smashingmagazine.com/2022/04/jamstack-rendering-patterns-evolution/ https://www.smashingmagazine.com/2022/04/jamstack-rendering-...
• tored 5y ago
  Except for the confusion about terminology the article has some good points. We had an idea a long time ago in the web dev world that we could run the same language in the browser and in the backend. Basically reuse everything and save time. It think this is bad assumption to begin with. If I have a clean separation between frontend and backend, regardless if doing mostly server rendering or client rendering it is only one thing that makes sense to share, input validation code. Like what is the definition of a first name, last name, age, price, email address etc. That is the one thing that need to be in agreement between the frontend and the backend to be able to exchange data. But to share frontend and backend technology for only the gain of input validation seems like a heavy price to pay for little gain.
  • deepstack 5y ago
    Being used server side JS since before NodeJS came along on JVM. I would say your assessment is correct (input validation) around that time. However React, Vue, Preact, Svelt, SolidJS (not to mention web components) changed that. We now have a group of people ONLY associated html rendering with those type of frameworks and components. So HTML rendering on the server side is pivoted to cater to those type of front end developer with 'Hydration'. The EJS templating type of rendering has being phased out. It is not good or bad, it is catering to what developers are use to.
  • dgb23 5y ago
    That has not been my experience. Input validation or more broadly data integrity is just the first, obvious issue. There are things that can help with that like json-schema, openapi, graphql and so on, which solve some part of this at some level. Let's go for json-schema, which is the simple, focused data driven and pretty well designed. Great isn't it? But it doesn't stop there. You now have at least two libraries in different languages with different levels of support for the spec, so you need to settle on the lowest common denominator. That's just the validation part, now you want error reporting, which means duplicating logic again. You probably want to convert the schemas or at least the data structures they validate into something that your languages work well with, that's duplicated logic again. Then you also need to somehow pull them in, build them etc. which is duplicated tooling around your language environments. Now you have version dependencies of somewhat the same thing in two different ecosystems with different versioning issues. Whenever I said "duplicating" I really meant "solving the same-ish problem in two different ways", so "duplicating" is an euphemism here. It's a proliferation of accidental complexity and coupling. Isomorphic code is not just a 1:1 thing. It's not necessarily the same functionality that you maintain on both sides (like validation) it's _all_ the other stuff as well, unrelated in terms of single features. Aside from validation and data integrity - and the whole jungle of stuff that comes with it - you also need a bunch of fundamental data structures, network I/O, possibly routing logic if you're doing anything that's dynamic on the frontend and serves UX beyond just displaying text and images in a nice way. You want quick, optimistic feedback on the client, so you're coordinating more state and data, which means more duplication again. You might want to move stuff from the server to the client and vice versa, when you discover basic optimization issues. Isomorphic code is _leverage_ to a high degree from tooling to standard libraries to knowledge, familiarity and mastering a language and ecosystem as a programmer. If you decide to use a heterogeneous ecosystem you better have good reasons for it such as legacy code, specific powerful libraries and integrations you need to use or high expertise in a particular language that cannot talk to both sides.
• locallost 5y ago
  The complaint in the article is technical, but my issue with the SSR + hydration approach is that it doesn't actually work for the users. Mainly because if you need a page that is indexed by Google, there is a high chance your users will browse it and open pages in new tabs. So the approach of "there is a small initial penalty, but everything is faster later" no longer applies -- you get that initial hit quite often.
  • dbbk 5y ago
    What initial hit are you referring to? If it's the origin request, just chuck it behind a CDN with some Cache-Control headers and call it a day.
    • locallost 4y ago
      The initial hit to hydrate / initialize the app.
• jwr 5y ago
  I've been using server-side rendering for many years now and I find it to be almost zero overhead at this point. Yes, I had to do some initial work to set things up, but these days I don't even remember it's there. Most people make an assumption that in order to have SSR you need to run JavaScript (e.g. Node most of the time) on your backend. That is not a valid assumption. I think the title of the article could benefit from adding "using Node", because much of the complexity described is something I do not encounter at all. I'm using Clojure and ClojureScript with Rum as a React interface. Much (if not most) of my code is in cljc files, which get compiled with Clojure (for JVM on the backend) or ClojureScript (for JavaScript on the frontend). And the ClojureScript advanced compilation takes care of only including what is strictly necessary in the frontend compiled JavaScript. I mean, sure, you need to be careful not to do stupid things like trying to read from files, but otherwise I just don't encounter much friction. And I reap the benefits of using a single language for both backend and frontend, with most of my data model (e.g. business logic) code written only once, with SSR being a nice cherry on top.
  • christophilus 5y ago
    This is a really nice combo, I agree. But… I think it’s safe to say it’ll probably remain niche forever. I wish there were more stacks like Clojure/Script. While I’m wishing, I’d love to have a modern ML with simple tooling, a good stdlib like Go (with a high performance http server baked in), and a good full stack story that doesn’t produce a 1MB “hello world”, and doesn’t require 1K dependencies. Does anyone know what the closest thing to this is these days?
    • isaacimagine 5y ago
      It's still a long way from being complete, but I'm working on something like that[0]. Eventual plans are to have good Rust library interop (e.g. bindings to hyper for http) while also being able to compile to Wasm (to run on an erlang-style distributed runtime / the browser). The language is currently interpreted, but one I get typechecking working, I should be able to merge in the Wasm codegen backend I'm working on (with eventual plans for LLVM). Current compiler has zero external dependencies. Language itself could be described as a mix of OCaml, Scheme, and Lua. Currently working on the hygienic procedural macro system and system injection through algebraic effects. [0]: https://github.com/vrtbl/passerine https://github.com/vrtbl/passerine
• cersa8 5y ago
  Do I live in a parallel universe where building SSR/SPA sites with Next.js is somehow incredibly complex? I know below the abstractions there is complexity, but building SSR rendered SPA's today with something like Next.js has never been more simple. I think web development has taken a huge leap forward where we now have stable tooling, a strongly typed language with TypeScript and top notch boilerplate free state management with MobX. To top it off you can write performant backend API's in Node.js with again TypeScript sharing contracts (Interfaces) between backend and frontend. I for one am really happy with the current state of affairs.
  • marcus_cemes 5y ago
    It's easy to server-side render Next.js apps, but usually they still have to talk to a backend. I don't think Next.js' API routes are good for this, especially if you need messages queues, cron jobs, etc. Now you have three distinct parts, client-side rendering, server-side rendering and the API, usually all communicating via JSON. Traditionaly with PHP, C#, Ruby, Elixir, etc, your backend and frontend was tightly coupled, your code has complete access to backend resources, and the view/template would map the state to a HTML document. Now, for the sake of interactivity, the view has effectively moved from the backend to the frontend with the introduction of SSR/SPA, JSON everywhere and code duplication so that they can all talk and understand each other. It's cool when it works, but it is easily at least 3x the amount of work. There is of course the argument of "just write both the client and server in JS/TS and use a monorepo", that brings its own challenges. Limiting the backend stack to what browsers support is not great, especially when Node.js is single-threaded with cooperative scheduling. No, lambda functions don't solve this entirely, and they're freaking expensive for CPU time. Honsetly, other ecosystems have it so much simpler IMO, even if it isn't as flashy. I say all this as a svelte developer, guilty.
    • langsoul-com 5y ago
    • andrewingram 5y ago
      In Next.js you'd typically use getServerSideProps on a page to talk to the backend at runtime. API routes have their place of course, but I've built fairly large-ish websites that almost entirely get their data via getServerSideProps.
• ki_ 5y ago
  foreach($seo_urls as $path){ $hash = sha256($path); exec('wget http://mywebsite.com/$path http://mywebsite.com/$path -o $project_root/seo/pages/$hash'); } ----- if($agent_type == 'search_engine_bot'){ $path = $request->path; if(in_array($path, $seo_urls)){ $hash = sha256($path); echo file_get_contents($project_root/seo/pages/$hash); exit; } } ---- Would this work? Edit: well i guess not.. because wget cant render javascript.. so.. maybe with a headless browser?
• globular-toast 5y ago
  Ah, someone who has discovered that writing in tiny paragraphs makes for addictive reading even if the substance is minimal.
• franze 5y ago
  I make a difference between website and webapp. a website is a collection of webpages, where the maingoal is to display some mostly static information (i.e. an article) a webapp has the main goal of managing and reacting to a complex, non trivial user state. website, go server side all in, do not add the tax of client side rendering / hydration to the frontend. if necessary embed small enclosed client side webapps on the frontend. webapp, go client side all in, screw server side rendering. yes, you can marry website and webapp via server side rendering / hydration. but the cost to make this really really fast and spiralling complexity and edge cases, does not make it worth it. choose the right tool for the job, and just because it has web** in its name, does not make it automatically a job for react/angularjs/newest-coolest-framework
  • gherkinnn 5y ago
    There is a lot of value in rendering the shell of an app on the server and populating the rest on the client. The outer layout of a given view is mostly static. Doing this correctly gives you stable loading with no reshuffling as the rest loads. And some views in apps can have page-y aspects like reports that might as well be static. Though this is an optimisation, and can be deferred till later.
  • 2143 5y ago
    In principle I agree with what you say, but I'd like to make a more fine grained distinction. If the website is just static content, go for static-site generation. If it's a webapp, where you have some interactions but there's only a few of these and the site is not that complex, then go for server-side rendering. If it's a web app with complex interactions, go for client-side rendering.
  • kumarvvr 5y ago
    A great distinction and way to think about your work. However, I would prefer server side rendering as the best thing to do in all cases, because, while user state may be complex in webapp, it can be easily handled securely in a server side environment. More so, until the ecosystem around webassembly becomes more mature, the choice of languages and frameworks on the server side are far more than what is available on the client side. Thinking and architecting apps that render on the server is much easier than client apps. Also, client apps are slow and laggy. It takes a lot of effort to make them work well, effort that could be used to improve bottomline otherwise.
• cryptica 5y ago
  I figured this out several years ago when I tried to build a full-stack framework to seamlessly connect the front end and back end into a single development experience (kind of like what Meteor and Next.js turned out to be). I ended up cancelling that project, pulled out the RPC + pub/sub internals and spun it off into a separate set of libraries which became successful on their own. I've been saying this for years. Although code reuse is possible between server and browser and sometimes it saves a lot of time, it's not common enough to be a default (as part of a monolithic framework) and there are security implications which make it highly desirable to differentiate between the two. I do think frameworks are overused. IMO, frameworks make more sense in DevOps for infrastructure orchestration to provide resilience and scalability. For example, I think Kubernetes makes sense as a framework - Critiques of its complexity are not related to its frameworkness; there is literally no other way to do orchestration - Orchestration is the top layer which runs everything and sits above everything (including hosts and processes). Frameworks don't make much sense in development space IMO; they're mostly a way for companies to achieve lock-in. Even on the front end, Google Polymer had already proved through their WebComponents polyfills that frameworks were not necessary to achieve reactivity on the front end. A simple, lightweight library is usually enough.
• pjmlp 5y ago
  What is absurd is doing SSR with SPA frameworks, instead of how it has always been done.
• midrus 5y ago
  The moment you need SSR, you'd be in a better place if you were using just plain old server rendered (componetized) views, such as the ones you can do with laravel's Blade system, and do your client side interactions with Alpine and your server interactions with unpoly/HTMX. SSR per se is not a "big problem", specially if using something like Next. The problem comes when you have to mix in translations, i18n, data fetching from external sources, authentication, cookies forwarding, etc, etc, etc... in my opinion complexity grows so exponentially that I don't see the advantage anymore. I'm working on a project built with Laravel + Tailwind + Unpoly + Alpine and it is such a walk in the park to implement anything thrown at us. Although it is not "cool" tech, so some people around here don't want to work on it because they only want React all the things :-s
• pygy_ 4y ago
  This could probably be mitigated by a combination of algebraic effect handlers and session types for effects. Algebraic effect handlers let you dynamically (re)define how effects are handled for a given piece of code. and - session types for effects, that would let one specify protocols for effects (i.e. a HTTP response handler would not be granted access to the socket, but would be allowed to use dedicated effects: `statusCode`, `header`, body` and `trailer` effects and would not be allowed to use them in a way that violates HTTP. Session types let you check that at compile time.
• exabrial 4y ago
  The only thing 'absurdly complex' about this is the Javascript portion. Server side component based frameworks exist and work very well for this purpose.
• engineeringwoke 4y ago
  Front end complexity - Making applications isomorphic so you can re-use code on the client and server Hacker News commenter: Ugh, why is this problem so over-engineered. It's completely unnecessary Back end complexity - Two hour Google article from yesterday that goes through layers of C++ and raw assembly that results in a 2-3% speed up by basically using SIMD and turning off branch prediction Hacker News commenter: Wow! So cool!