1. 2

  2. 3

    Never really used Laravel, though PHP people seem to rate it and those examples look fine. But the thing that prompted me to comment here is that I find most of the assumptions and premises of this article to be just … baffling. Maybe PHP wouldn’t be my first choice either(!), but node.js most certainly would not be my obvious first choice for a back-end component. Even ignoring for a moment the multiple, frequently-bemoaned foibles of JS as a language, toolchain and environment (let alone the npm “ecosystem”!), the whole “it’s the same language = easier and self-evidently better” is just weird and not at all self-evident, and the “full glory of the full JS stack” is, how shall I put this … cognitively dissonant. Having to write async code for literally everything you do on the server side is definitely not “glorious”, for me anyway. Maybe someone who’s so utterly bought into “JS MUST RULE ALL” would be baffled as to why anyone would use anything else, but, well, it works both ways, and a lot of the points taken for granted here are manifestly not clear to me.


    Node.js allows server-side rendering. This means you can render your page on the server before it hits the browser, allowing users to see the page quicker. (There are attempts to achieve this with PHP/JS extensions, but for the time being, these do not work with many SPA frameworks like Vue, and if they do, they’re much slower).

    What am I missing here? Last I checked, browsers don’t have some magical method for sharing distributed pre-rendered DOM components with node.js processes on the backend, so what’s magic about rendering even fragments of HTML on the server that other languages can’t do perfectly competently, perhaps much faster than node.js and without all the single-threaded business? Are they talking about something actually different here, or is it literally “I want all my rendering code to be splurged across server and client so there’s no clear demarcation and everything just kinda splats into everything else”?

    1. 1

      The server side rendering here is just that using Node/JS allows you to use the same (JS) code to pre-render a given page. This has uses in SEO and/or making the first load of a page faster. This is more of an issue for SPAs that want to have SEO than anything else. See also “Isomorphic Rendering” (another name for the same concept)

      This is not strictly related to the general rendering of most web sites on the server.

      1. 1

        Got it, thank you. Just read up a bunch on that. Something still smells funny to me about it though, in that if one’s already using JS on the server, fine (although spreading out this way seems to me like a really fast way to blur what I think of as some important distinctions) - but if not, there must be plenty of ways to fix rendering just the relevant components without having to push a whole node.js stack onto the server. I get that having the same templates is appealing, but by the admission of the articles I read about it, it’s only really a concern for a few specific scenarios, so personally I’d rather come up with something else and steer clear of node if possible. Guess that’s just my bias - maybe if I had to do a standard web project (rather than a websocket/etc one) with node then I’d appreciate it.

        1. 1

          Don’t forget that Go and/or Elixir are both strong runtimes for websocket style applications/servers.

          1. 1

            Oh totally. I’d likely use Erlang & Cowboy for that. Just meant that in my world WS is at least a better fit for node’s async model than “normal” back-end stuff.

        2. 1

          Please correct me if I’m incredibly, irremediably wrong and beyond redemption, but here’s what I understand from this all: Isomorphic rendering has become an argument in favor of server-side JS as a byproduct of JSX being pretty awesome; the problem itself can be solved using any number of template languages that both have decent server- and client-side implementations, but as far as I can tell, it became a thing again in the recent past. Am I understanding this correctly? Am I being trolled by the front-end development community all the way to the dark recesses of my comfortably deep back-end development cave?

          I don’t understand how a clever use of the Accept header combined with a portable template language doesn’t solve this.

          1. 1

            The only thing that comes to mind at the moment is that some front end applications have been adopting increasingly complex client-side data stores, like Redux, and you might have a large number of interacting components that feed into a page render. But that’s the only major use-case I see. (Thinking of rendering a bunch of sub-parts of the page or whatnot). However, I’m not a front-end focused dev. I still haven’t managed to fully investigate Vue.JS yet.

            That being said, if you’re building a website or webapp that leverages the backend a fair bit, I don’t see a reason one couldn’t use something like handlebars on both sides. That would probably reduce the JSX/virtual dom side of things, but horses for courses.