9 ms·

SimpleSSR: Server-Side Rendering at Scale

136 points by momonga 8y ago

CharlesW 8y ago
> Is this a joke? Sort of, not really. "SimpleSSR: Don't do SSR" is as humorous as "SimpleC++: Don't use C++". I'm guessing it's funny to SSR haters? (Related question: Are "SSR haters" a thing?) So is the essence of this particular hot-take that it's better to render pages per-request with Ruby or PHP than to serve a rendered result that has no additional per-request overhead?
- allover 8y ago
  It's not that simple. (I say this as a JS dev who develops SPAs for a living). For one, "no additional per-request overhead" is an oversimplification, that is not the case for most SPAs that grow beyond 'small' size, see 'code-splitting'. Modern SSR involves re-using the same client-side rendering code on the backend (which typically means a Node backend), and modern SPAs may employ some techniques to code-split the client side app, either by-route or other means. You can make a decent case that for a lot of 'sites' this whole setup is more complex than the server-side rendered frameworks of old mentioned by this site.
  - CharlesW 8y ago
    > For one, "no additional per-request overhead" is an oversimplification… That's fair, but setting aside packaging decisions like code-splitting (which aren't unique to SPAs), my point is that SSR is typically used to deliver content and app logic that would otherwise require round-trips to code running on a server. It hardly seems like a huge win for "SimpleSSR".
- deialtrous 8y ago
  Was the page edited after it was submitted here? It doesn't say "don't do SSR", or imply it.
  - CharlesW 8y ago
    It does—that's the point of the page.
    - deialtrous 8y ago
      Where? It says use one of the many frameworks that do SSR. How is that saying not to do SSR?
highwind 8y ago
You can't beat serving useful data to the user on the first payload (base HTML), no matter how fast or clever client-side rendering gets.
- CharlesW 8y ago
  Are you arguing for or against SSR here? (Both would include base HTML, no?)
  - antoncohen 8y ago
    A single page application (SPA) without server side rendering (SSR) doesn't serve "useful data to the user on the first payload". It serves an empty HTML shell with a script tag (or multiple tags) linking to the Javascript app bundle (or multiple bundles). If the app bundling doesn't break up the app into smaller bundles that are asynchronously loaded, the initial JS payload will probably be 10+ MB. At which point the browser needs to download the 10 MB of JS, execute it, and have the JS fill in the HTML with "useful data". So no, an SPA without SSR doesn't include useful data in the first payload.
    - scottmf 8y ago
      10mb of JS — Examples?
      - romed 8y ago
        I was going to say Slack but it "only" transferred 5MB.
      - antoncohen 8y ago
        10 MB could be an exaggeration on average, but not by a huge amount. Not even trying to find something crazy big, this is the first site I checked because I went to it earlier today and noticed it took a long time to load: https://help.salesforce.com/articleView?id=000232181&language=en_US&type=1 https://help.salesforce.com/articleView?id=000232181&languag... It is simple help article, but instead of serving the actual help article it spends about 2 seconds serving 4 MB of JS and rendering the article. After that I typed 'app.' into my URL bar and went to the first site that came up, that was 3.9 MB of JS on the login page. Numbers are for uncompressed JS, including the larger of the inline scripts.
dmcbrayer 8y ago
Yeah this is a little too on the nose.
- scottmf 8y ago
  Also probably shouldn’t put RoR as the first item in your list of full-stack frameworks if your title says “at scale”
  - hamandcheese 8y ago
    Lots of companies successfully use RoR at scale.
    - deialtrous 8y ago
      I think both statements depend on the definition of "at scale". I am no expert, but every RoR thing I have ever seen has been tiny in terms of traffic and still performed terribly. Is there anything in the top 100 sites using RoR?
      - wrs 8y ago
        There's quite a distance between "tiny" and "top 100 sites"! Some pretty darn popular sites that use Rails (afaik) are GitHub, Shopify, Hulu, Twitch, and Airbnb.
        deialtrous 8y ago
        Not really. The web has become massively centralized with almost all traffic going to a small number of sites. The bottom of the top 100 list is only getting about 50 million pageviews a month, even poorly written sites in slow languages can easily do that on very cheap low end hardware. Pretty much anything not in the top 100 is dealing with a tiny amount of traffic, even a fair bit of the top 100 is. So it is github and twitch, neither of which actually do anything substantial in RoR any more. That seems like a pretty good reason to think RoR's strength isn't high traffic volumes.
stanislavb 8y ago
Let's make SSR great again
- phuz10n 8y ago
  Haha!
scottmf 8y ago
React SSR is not a problem, and I can get quicker TTFB than I ever remember getting with even a simple RoR app (300+ms yikes). I can also work faster with the React ecosystem (and find it much more enjoyable) than RoR and SSR makes the end result the same anyway. People like component-based frameworks and modern JavaScript (and its supersets). Things are different now. Deal with it!
- wrl 8y ago
  > Deal with it! We, your users, do deal with it. Constantly. Usually, we deal with it by waiting 30 seconds for your single-page application blog article to load because we only get intermittent 3G reception on the metro. I don't really care what sort of frameworks you like. Stop building shit webapps!
  - juststeve 8y ago
    some sites are just modern Goldberg machines
  - friedman23 8y ago
    Your complaint has nothing to do with using React over using other frameworks such as django. The problem you have is that people are not implementing SSR on their websites and they don't host all of their assets.
  - scottmf 8y ago
    You missed the entire point of my comment.
- taeric 8y ago
  300ms for a simple RoR site? Sounds suspicious. That said. Even Gmail is on the order of seconds for being useful nowadays...
  - TheAceOfHearts 8y ago
    Gmail has gotten painfully slow over the years. I just ran a quick timing test with a high-end 2017 MacBook Pro on Firefox: * It takes 2.53 seconds from hitting enter to being able to see my inbox. * It takes 9.96 seconds from hitting enter and clicking compose for the new message window to pop up. * It takes a whopping 15.95 seconds from hitting enter until the new message window pops up if you use the the following link: https://mail.google.com/mail/u/0/#inbox?compose=new https://mail.google.com/mail/u/0/#inbox?compose=new Those times are pretty damn terrible. Even worse, this is with a primed cache!
arborsoftware 8y ago
NextJS - GG
kenOfYugen 8y ago
I can't say I fully comprehend the SSR vs SPA war. Both concepts are definitely being misused/overused, one is "dated" and the other "modern", but surely the middle ground where best usage of both can be attained is prefered. I don't know of any terms that mediate the opposition other than perhaps "hydration"?
- sam0x17 8y ago
  This is the key. There are super developed SSR frameworks and super developed SPA frameworks, but getting the two to work together is like pulling teeth. No one tries to write an SSRSPA framework because that would be considered too "opinionated", but maybe that's exactly what we need.
  - friedman23 8y ago
    Ok, I was confused by your comment and the other person's comment. SSR and SPA are not mutually exclusive things.
    - sam0x17 8y ago
      They aren't mutually exclusive, but they are either a) at odds with each other because the frontend is in javascript and the backend is in Rails or Python or something else, or b) completely in sync because the backend and front end is in javascript, but terrible because the backend and the front end is in javascript. With web assembly on the horizon we will soon have Rust/Crystal/Go-driven unified backend+frontends, and then we can finally exit this dark age of JS being the only front end language.
      - friedman23 8y ago
        As someone that prefers python it is unfortunate that the only way to get SSR is to commit to JS but with web assembly I think we will eventually have tools such as React and Redux be translated to other languages. As far as performance goes js isn't too bad. It's async by default and a lot of effort has gone into making it run fast.
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
shaunpersad 8y ago
Gatsby.js (and some other recent tools) makes the SSR vs. SPA argument moot. There's no need to pick one when you can have both. Disclaimer: I'm not affiliated with Gatsby.
- city41 8y ago
  I’m a fan of gatsby and think it’s a sensible approach for many sites. But it has limitations. Most obvious being it essentially reverts to an SPA if you need the user to be logged in before you can render any real data.
- deleted 8y ago
  [deleted]
friedman23 8y ago
I've been using Next.js and SSR with react is dead simple. I use React even when building standard web pages because the React way of doing things makes more sense to me as a programmer than the html/css/js way of doing things. I like building composable building blocks with self contained state. The old model of separate html, css, and js never worked well for me. My main complaint with React SSR is that it almost forces on me the requirement of using Node for the backend. I'd prefer to use a language like python.
- raihansaputra 8y ago
  Is there any way to do use python as the backend? I feel the same way about handling raw HTML/CSS/JS. Either I haven't learned enough about handling those or I should learn React/Angular/Vue, but I do want to stay on python for my backend.
  - friedman23 8y ago
    I mean, the way to do it is to have a server for ssr and standard requests and another server for the api written in the language of your choice.
toolz 8y ago
disclosure: I'm the biased author texas https://gitlab.com/dgmcguire/texas https://gitlab.com/dgmcguire/texas is a library that brings development back to the server. You can integration test without headless browsers, get SPA-like UX without writing a line of JS and basically just write SSR apps with only adding a few lines of code to make you apps realtime and SPA-like. It works by leveraging persistent connections (websockets) first page load is entirely SSR and subsequent updates are SSR, but only by V-DOM diffing html fragments, sending only the minimum amount of patch data over the wire. Your apps will be faster, your development process will be faster with less code and removing all kinds of complex tooling. Here's a todoapp that does all rendering SSR https://warm-citadel-23442.herokuapp.com/ https://warm-citadel-23442.herokuapp.com/ - you can see just how fast it is even on a free tier of heroku - open it up in multiple clients and you'll see that all operations are realtime broadcasted too and believe it or not there's only like 3 lines of code you write to make that happen (plus all the code necessary to get a normal SSR app running)
- Rovanion 8y ago
  Hi, I just watched through the first two parts of your three part intro to Texas on YouTube. I noted that you restart the server process each time you make a change to the elixir application and coming from the Clojure universe I have the following question: Is it possible to insetad of restarting the server program each time you make a change to it's source code instead modify the program as it is running? This is usually how I work on my Clojure programs and I find that doing that which results in near instant feedback while I am programming.
  - toolz 8y ago
    yeah, phoenix already has live-reloading included, I just probably hadn't setup the watchers properly or I was being dumb xD - it's pretty trivial to have everything setup to give instant feedback, though
- hnzix 8y ago
  Is Texas much different to Rails Turbolinks? Or is it like Turbolinks for Phoenix? PS I'm really happy that you called out "graceful degredation to an application that continues to function in the abscence of any JS.".
SomeCallMeTim 8y ago
On-demand Server Side Rendering should be killed for 98% of applications. SSR->static hosting + client framework is the future.
nemanja 8y ago
Upcoming Phoenix LiveView is actually pretty viable for SSR - https://www.youtube.com/watch?v=Z2DU0qLfPIY https://www.youtube.com/watch?v=Z2DU0qLfPIY
RantyDave 8y ago
I can't help feeling that edge rendering is greatness personified ... but that it's perhaps not any more useful than just server side rendering. An edge renderer is still going to have to either access a model/controller held centrally (getting our latency times up again) or use some godforsaken distributed/replicated state that's a bitch to debug. Perhaps an edge renderer can hold open a connection to the central logic and knock a hundred millis or so off the set up time as a result, but none of the proposed models for doing this would seem to support that. They don't seem to support stateful anything.
tylerjwilk00 8y ago
I may get hate for this but watching JavaScript development mature makes me feel like I am taking crazy pills. So much shit was figured out decades ago but it's like everyone is just learning this shit for the first time. I don't know if it is because the standard library is so lacking or that it's been historical a client side only language but it makes me feel completely disillusioned with programming. It's like we're not progressing at all, merely learning that same shit over and over again each generation in a series of cycles. Or maybe I'm just too old and need to get off my own lawn.
- mohammedbin 8y ago
  No, it's not you. I read the title and I immediately understood the context and said to myself- welcome to 1997.
  - nodeBro 8y ago
    "Isomorphic."
- dplgk 8y ago
  You are correct. It's why constantly see things like "Show HN: A Javascript until for making strings upper case"
- juststeve 8y ago
  Have you tried templating in Golang or Rust? Tera templates are rendered during compilation, URL is here if you want to have a look at the syntax: https://tera.netlify.com/ https://tera.netlify.com/ (I'm not affiliated with the project, just think it's rad)
- weyland108 8y ago
  You are not alone
- s_kilk 8y ago
  > it's like everyone is just learning this shit for the first time. Because they are. The field is full of amateurs and under-trained developers who are positively allergic to history and learning.
BigJono 8y ago
I'm seeing a lot of posts about NextJS here... Adding a (huge) abstraction on top of another (huge) abstraction to solve a problem introduced by the first abstraction is rubbish software engineering. It's one of the oldest anti-patterns in the book. I get that these libraries provide some utility beyond their core purpose, and that it's a bit more nuanced than A -> B -> A, but I'm highly suspicious of people that recommend these libraries without giving much context behind it.
- smokeyj 8y ago
  The industry norm for SPA seems to be moving towards SSR along with code-splitting and offline workers. The main SSR framework for React is NextJS. Vue and others have their equivalents. Honestly I don't see a reason not to use it. I could write a traditional website using Next/react at the same speed as someone using Django/rails/etc.
  - deleted 8y ago
    [deleted]
  - subsection1h 8y ago
    Next.js is a front-end framework, right? So how can you build a traditional website using only a front-end framework at the same speed as someone using Django or Rails?
    - ricardobeat 8y ago
      It's not like it's hard to find: https://nextjs.org https://nextjs.org Next integrates the server and client code in a single framework, and is made for seamless deployment using Now.
      - subsection1h 8y ago
        I previously visited nexjs.org and read the docs, and it wasn't clear that Next.js is a full-stack framework. The term "full stack" isn't used anywhere at nextjs.org[1], unlike rubyonrails.org[2]. Furthermore, there are numerous references on the web to Next.js being a front-end framework, including statements made by Next.js maintainers[3]. Do these statements not reflect the current state of Next.js? If Next.js is a full-stack framework, then this seems to be another instance of JavaScript tools having inadequate documentation. Speaking of which, if Next.js is a full-stack framework that's comparable to Rails and Django, why is the documentation just one page (!) and there's no mention of database migrations or other basic features that are included with every full-stack framework? [1] https://www.google.com/search?q="full+stack"+site:nextjs.org https://www.google.com/search?q="full+stack"+site:nextjs.org [2] https://www.google.com/search?q="full+stack"+site:rubyonrails.org https://www.google.com/search?q="full+stack"+site:rubyonrail... [3] https://github.com/zeit/next.js/issues/1933#issuecomment-300476550 https://github.com/zeit/next.js/issues/1933#issuecomment-300...
iamgopal 8y ago
My golang template render in tens of ms. About same time my slow computer browser take for spa.
wishinghand 8y ago
For those saying to forgo Next.js and to also serve templates from a non-Node server, how are sub-views handled? Same as JavaScript but the AJAX call returns a sub-template and data?
quantummkv 8y ago
I really don't get this whole SSR thing. You take a framework designed explicitly for dynamic client side code and use it to make a glorified old school framework (insert your choice of RoR, Django, Laravel, etc). Why does anyone think this is a good idea? You end up re-implementing Rails on a foundation of quicksand and manage to throw the excellent standard libraries that come with those languages out in one stroke. Is this a result of too much kool-aid? Or have we ended up with hippie bootcampers without a shred of knowledge in high level positions? It's depressing to watch really.
- silviogutierrez 8y ago
  I firmly believe defaulting to SSR/old-school is the way to go. And only add dynamic behavior when needed. But when you do need to add that dynamic behavior... things get hairy. See this comment for more info: https://news.ycombinator.com/item?id=18289460 https://news.ycombinator.com/item?id=18289460
  - kraftman 8y ago
    I went to a conference recently where one of the talks was a guy from comcast on 'Progressive Web App performance'. The two takeaways were that they had decided against ever using SSR (he didnt say why just acted like it was ridiculous), and that through various clever performance tricks they'd managed to get their page load time down from 30 seconds.. to 15.
mosselman 8y ago
The number of use cases that people implement with SPAs is huge while the number of use cases where a SPA is actually better than just rendering some HTML can be counted on one hand.
philippz 8y ago
After reading all the comments here... "TRY ALL THE NEW FANCY FRAMEWORKS"
deleted 8y ago
[deleted]

136 points by momonga 8y ago

> Is this a joke? Sort of, not really. "SimpleSSR: Don't do SSR" is as humorous as "SimpleC++: Don't use C++". I'm guessing it's funny to SSR haters? (Related question: Are "SSR haters" a thing?) So is the essence of this particular hot-take that it's better to render pages per-request with Ruby or PHP than to serve a rendered result that has no additional per-request overhead?

allover 8y ago
It's not that simple. (I say this as a JS dev who develops SPAs for a living). For one, "no additional per-request overhead" is an oversimplification, that is not the case for most SPAs that grow beyond 'small' size, see 'code-splitting'. Modern SSR involves re-using the same client-side rendering code on the backend (which typically means a Node backend), and modern SPAs may employ some techniques to code-split the client side app, either by-route or other means. You can make a decent case that for a lot of 'sites' this whole setup is more complex than the server-side rendered frameworks of old mentioned by this site.
- CharlesW 8y ago
  > For one, "no additional per-request overhead" is an oversimplification… That's fair, but setting aside packaging decisions like code-splitting (which aren't unique to SPAs), my point is that SSR is typically used to deliver content and app logic that would otherwise require round-trips to code running on a server. It hardly seems like a huge win for "SimpleSSR".
deialtrous 8y ago
Was the page edited after it was submitted here? It doesn't say "don't do SSR", or imply it.
- CharlesW 8y ago
  It does—that's the point of the page.
  - deialtrous 8y ago
    Where? It says use one of the many frameworks that do SSR. How is that saying not to do SSR?

highwind 8y ago

You can't beat serving useful data to the user on the first payload (base HTML), no matter how fast or clever client-side rendering gets.

CharlesW 8y ago
Are you arguing for or against SSR here? (Both would include base HTML, no?)
- antoncohen 8y ago
  A single page application (SPA) without server side rendering (SSR) doesn't serve "useful data to the user on the first payload". It serves an empty HTML shell with a script tag (or multiple tags) linking to the Javascript app bundle (or multiple bundles). If the app bundling doesn't break up the app into smaller bundles that are asynchronously loaded, the initial JS payload will probably be 10+ MB. At which point the browser needs to download the 10 MB of JS, execute it, and have the JS fill in the HTML with "useful data". So no, an SPA without SSR doesn't include useful data in the first payload.
  - scottmf 8y ago
    10mb of JS — Examples?
    - romed 8y ago
      I was going to say Slack but it "only" transferred 5MB.
    - antoncohen 8y ago
      10 MB could be an exaggeration on average, but not by a huge amount. Not even trying to find something crazy big, this is the first site I checked because I went to it earlier today and noticed it took a long time to load: https://help.salesforce.com/articleView?id=000232181&language=en_US&type=1 https://help.salesforce.com/articleView?id=000232181&languag... It is simple help article, but instead of serving the actual help article it spends about 2 seconds serving 4 MB of JS and rendering the article. After that I typed 'app.' into my URL bar and went to the first site that came up, that was 3.9 MB of JS on the login page. Numbers are for uncompressed JS, including the larger of the inline scripts.

dmcbrayer 8y ago

Yeah this is a little too on the nose.

scottmf 8y ago
Also probably shouldn’t put RoR as the first item in your list of full-stack frameworks if your title says “at scale”
- hamandcheese 8y ago
  Lots of companies successfully use RoR at scale.
  - deialtrous 8y ago
    I think both statements depend on the definition of "at scale". I am no expert, but every RoR thing I have ever seen has been tiny in terms of traffic and still performed terribly. Is there anything in the top 100 sites using RoR?
    - wrs 8y ago
      There's quite a distance between "tiny" and "top 100 sites"! Some pretty darn popular sites that use Rails (afaik) are GitHub, Shopify, Hulu, Twitch, and Airbnb.
      - deialtrous 8y ago
        Not really. The web has become massively centralized with almost all traffic going to a small number of sites. The bottom of the top 100 list is only getting about 50 million pageviews a month, even poorly written sites in slow languages can easily do that on very cheap low end hardware. Pretty much anything not in the top 100 is dealing with a tiny amount of traffic, even a fair bit of the top 100 is. So it is github and twitch, neither of which actually do anything substantial in RoR any more. That seems like a pretty good reason to think RoR's strength isn't high traffic volumes.

stanislavb 8y ago

Let's make SSR great again

phuz10n 8y ago
Haha!

scottmf 8y ago

React SSR is not a problem, and I can get quicker TTFB than I ever remember getting with even a simple RoR app (300+ms yikes). I can also work faster with the React ecosystem (and find it much more enjoyable) than RoR and SSR makes the end result the same anyway. People like component-based frameworks and modern JavaScript (and its supersets). Things are different now. Deal with it!

wrl 8y ago
> Deal with it! We, your users, do deal with it. Constantly. Usually, we deal with it by waiting 30 seconds for your single-page application blog article to load because we only get intermittent 3G reception on the metro. I don't really care what sort of frameworks you like. Stop building shit webapps!
- juststeve 8y ago
  some sites are just modern Goldberg machines
- friedman23 8y ago
  Your complaint has nothing to do with using React over using other frameworks such as django. The problem you have is that people are not implementing SSR on their websites and they don't host all of their assets.
- scottmf 8y ago
  You missed the entire point of my comment.
taeric 8y ago
300ms for a simple RoR site? Sounds suspicious. That said. Even Gmail is on the order of seconds for being useful nowadays...
- TheAceOfHearts 8y ago
  Gmail has gotten painfully slow over the years. I just ran a quick timing test with a high-end 2017 MacBook Pro on Firefox: * It takes 2.53 seconds from hitting enter to being able to see my inbox. * It takes 9.96 seconds from hitting enter and clicking compose for the new message window to pop up. * It takes a whopping 15.95 seconds from hitting enter until the new message window pops up if you use the the following link: https://mail.google.com/mail/u/0/#inbox?compose=new https://mail.google.com/mail/u/0/#inbox?compose=new Those times are pretty damn terrible. Even worse, this is with a primed cache!

arborsoftware 8y ago

NextJS - GG

kenOfYugen 8y ago

I can't say I fully comprehend the SSR vs SPA war. Both concepts are definitely being misused/overused, one is "dated" and the other "modern", but surely the middle ground where best usage of both can be attained is prefered. I don't know of any terms that mediate the opposition other than perhaps "hydration"?

sam0x17 8y ago
This is the key. There are super developed SSR frameworks and super developed SPA frameworks, but getting the two to work together is like pulling teeth. No one tries to write an SSRSPA framework because that would be considered too "opinionated", but maybe that's exactly what we need.
- friedman23 8y ago
  Ok, I was confused by your comment and the other person's comment. SSR and SPA are not mutually exclusive things.
  - sam0x17 8y ago
    They aren't mutually exclusive, but they are either a) at odds with each other because the frontend is in javascript and the backend is in Rails or Python or something else, or b) completely in sync because the backend and front end is in javascript, but terrible because the backend and the front end is in javascript. With web assembly on the horizon we will soon have Rust/Crystal/Go-driven unified backend+frontends, and then we can finally exit this dark age of JS being the only front end language.
    - friedman23 8y ago
      As someone that prefers python it is unfortunate that the only way to get SSR is to commit to JS but with web assembly I think we will eventually have tools such as React and Redux be translated to other languages. As far as performance goes js isn't too bad. It's async by default and a lot of effort has gone into making it run fast.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

shaunpersad 8y ago

Gatsby.js (and some other recent tools) makes the SSR vs. SPA argument moot. There's no need to pick one when you can have both. Disclaimer: I'm not affiliated with Gatsby.

city41 8y ago
I’m a fan of gatsby and think it’s a sensible approach for many sites. But it has limitations. Most obvious being it essentially reverts to an SPA if you need the user to be logged in before you can render any real data.
deleted 8y ago
[deleted]

friedman23 8y ago

I've been using Next.js and SSR with react is dead simple. I use React even when building standard web pages because the React way of doing things makes more sense to me as a programmer than the html/css/js way of doing things. I like building composable building blocks with self contained state. The old model of separate html, css, and js never worked well for me. My main complaint with React SSR is that it almost forces on me the requirement of using Node for the backend. I'd prefer to use a language like python.

raihansaputra 8y ago
Is there any way to do use python as the backend? I feel the same way about handling raw HTML/CSS/JS. Either I haven't learned enough about handling those or I should learn React/Angular/Vue, but I do want to stay on python for my backend.
- friedman23 8y ago
  I mean, the way to do it is to have a server for ssr and standard requests and another server for the api written in the language of your choice.

toolz 8y ago

disclosure: I'm the biased author texas https://gitlab.com/dgmcguire/texas https://gitlab.com/dgmcguire/texas is a library that brings development back to the server. You can integration test without headless browsers, get SPA-like UX without writing a line of JS and basically just write SSR apps with only adding a few lines of code to make you apps realtime and SPA-like. It works by leveraging persistent connections (websockets) first page load is entirely SSR and subsequent updates are SSR, but only by V-DOM diffing html fragments, sending only the minimum amount of patch data over the wire. Your apps will be faster, your development process will be faster with less code and removing all kinds of complex tooling. Here's a todoapp that does all rendering SSR https://warm-citadel-23442.herokuapp.com/ https://warm-citadel-23442.herokuapp.com/ - you can see just how fast it is even on a free tier of heroku - open it up in multiple clients and you'll see that all operations are realtime broadcasted too and believe it or not there's only like 3 lines of code you write to make that happen (plus all the code necessary to get a normal SSR app running)

Rovanion 8y ago
Hi, I just watched through the first two parts of your three part intro to Texas on YouTube. I noted that you restart the server process each time you make a change to the elixir application and coming from the Clojure universe I have the following question: Is it possible to insetad of restarting the server program each time you make a change to it's source code instead modify the program as it is running? This is usually how I work on my Clojure programs and I find that doing that which results in near instant feedback while I am programming.
- toolz 8y ago
  yeah, phoenix already has live-reloading included, I just probably hadn't setup the watchers properly or I was being dumb xD - it's pretty trivial to have everything setup to give instant feedback, though
hnzix 8y ago
Is Texas much different to Rails Turbolinks? Or is it like Turbolinks for Phoenix? PS I'm really happy that you called out "graceful degredation to an application that continues to function in the abscence of any JS.".

SomeCallMeTim 8y ago

On-demand Server Side Rendering should be killed for 98% of applications. SSR->static hosting + client framework is the future.

nemanja 8y ago

Upcoming Phoenix LiveView is actually pretty viable for SSR - https://www.youtube.com/watch?v=Z2DU0qLfPIY https://www.youtube.com/watch?v=Z2DU0qLfPIY

RantyDave 8y ago

I can't help feeling that edge rendering is greatness personified ... but that it's perhaps not any more useful than just server side rendering. An edge renderer is still going to have to either access a model/controller held centrally (getting our latency times up again) or use some godforsaken distributed/replicated state that's a bitch to debug. Perhaps an edge renderer can hold open a connection to the central logic and knock a hundred millis or so off the set up time as a result, but none of the proposed models for doing this would seem to support that. They don't seem to support stateful anything.

tylerjwilk00 8y ago

I may get hate for this but watching JavaScript development mature makes me feel like I am taking crazy pills. So much shit was figured out decades ago but it's like everyone is just learning this shit for the first time. I don't know if it is because the standard library is so lacking or that it's been historical a client side only language but it makes me feel completely disillusioned with programming. It's like we're not progressing at all, merely learning that same shit over and over again each generation in a series of cycles. Or maybe I'm just too old and need to get off my own lawn.

mohammedbin 8y ago
No, it's not you. I read the title and I immediately understood the context and said to myself- welcome to 1997.
- nodeBro 8y ago
  "Isomorphic."
dplgk 8y ago
You are correct. It's why constantly see things like "Show HN: A Javascript until for making strings upper case"
juststeve 8y ago
Have you tried templating in Golang or Rust? Tera templates are rendered during compilation, URL is here if you want to have a look at the syntax: https://tera.netlify.com/ https://tera.netlify.com/ (I'm not affiliated with the project, just think it's rad)
weyland108 8y ago
You are not alone
s_kilk 8y ago
> it's like everyone is just learning this shit for the first time. Because they are. The field is full of amateurs and under-trained developers who are positively allergic to history and learning.

BigJono 8y ago

I'm seeing a lot of posts about NextJS here... Adding a (huge) abstraction on top of another (huge) abstraction to solve a problem introduced by the first abstraction is rubbish software engineering. It's one of the oldest anti-patterns in the book. I get that these libraries provide some utility beyond their core purpose, and that it's a bit more nuanced than A -> B -> A, but I'm highly suspicious of people that recommend these libraries without giving much context behind it.

smokeyj 8y ago
The industry norm for SPA seems to be moving towards SSR along with code-splitting and offline workers. The main SSR framework for React is NextJS. Vue and others have their equivalents. Honestly I don't see a reason not to use it. I could write a traditional website using Next/react at the same speed as someone using Django/rails/etc.
- deleted 8y ago
  [deleted]
- subsection1h 8y ago
  Next.js is a front-end framework, right? So how can you build a traditional website using only a front-end framework at the same speed as someone using Django or Rails?
  - ricardobeat 8y ago
    It's not like it's hard to find: https://nextjs.org https://nextjs.org Next integrates the server and client code in a single framework, and is made for seamless deployment using Now.
    - subsection1h 8y ago
      I previously visited nexjs.org and read the docs, and it wasn't clear that Next.js is a full-stack framework. The term "full stack" isn't used anywhere at nextjs.org[1], unlike rubyonrails.org[2]. Furthermore, there are numerous references on the web to Next.js being a front-end framework, including statements made by Next.js maintainers[3]. Do these statements not reflect the current state of Next.js? If Next.js is a full-stack framework, then this seems to be another instance of JavaScript tools having inadequate documentation. Speaking of which, if Next.js is a full-stack framework that's comparable to Rails and Django, why is the documentation just one page (!) and there's no mention of database migrations or other basic features that are included with every full-stack framework? [1] https://www.google.com/search?q="full+stack"+site:nextjs.org https://www.google.com/search?q="full+stack"+site:nextjs.org [2] https://www.google.com/search?q="full+stack"+site:rubyonrails.org https://www.google.com/search?q="full+stack"+site:rubyonrail... [3] https://github.com/zeit/next.js/issues/1933#issuecomment-300476550 https://github.com/zeit/next.js/issues/1933#issuecomment-300...

iamgopal 8y ago

My golang template render in tens of ms. About same time my slow computer browser take for spa.

wishinghand 8y ago

For those saying to forgo Next.js and to also serve templates from a non-Node server, how are sub-views handled? Same as JavaScript but the AJAX call returns a sub-template and data?

quantummkv 8y ago

I really don't get this whole SSR thing. You take a framework designed explicitly for dynamic client side code and use it to make a glorified old school framework (insert your choice of RoR, Django, Laravel, etc). Why does anyone think this is a good idea? You end up re-implementing Rails on a foundation of quicksand and manage to throw the excellent standard libraries that come with those languages out in one stroke. Is this a result of too much kool-aid? Or have we ended up with hippie bootcampers without a shred of knowledge in high level positions? It's depressing to watch really.

silviogutierrez 8y ago
I firmly believe defaulting to SSR/old-school is the way to go. And only add dynamic behavior when needed. But when you do need to add that dynamic behavior... things get hairy. See this comment for more info: https://news.ycombinator.com/item?id=18289460 https://news.ycombinator.com/item?id=18289460
- kraftman 8y ago
  I went to a conference recently where one of the talks was a guy from comcast on 'Progressive Web App performance'. The two takeaways were that they had decided against ever using SSR (he didnt say why just acted like it was ridiculous), and that through various clever performance tricks they'd managed to get their page load time down from 30 seconds.. to 15.

mosselman 8y ago

The number of use cases that people implement with SPAs is huge while the number of use cases where a SPA is actually better than just rendering some HTML can be counted on one hand.

philippz 8y ago

After reading all the comments here... "TRY ALL THE NEW FANCY FRAMEWORKS"

deleted 8y ago

[deleted]