SimpleSSR: Server-Side Rendering at Scale
simplessr.org
simplessr.org
Or maybe I'm just too old and need to get off my own lawn.
Tera templates are rendered during compilation, URL is here if you want to have a look at the syntax: https://tera.netlify.com/
(I'm not affiliated with the project, just think it's rad)
Because they are. The field is full of amateurs and under-trained developers who are positively allergic to history and learning.
I created and maintain VueJS’s other Server Side Rendered library. Express-vue
I’ve spoken on it at a few talks, and every time I do, the eyes of the audience just go blank when I talk about SSR. It’s like I’m talking in some strange language they don’t seem to understand, where the only thing they get is client side everything.
I get the stupidest questions like “so how do I add in <insert unnecessary bloat for a SPA here>” most of these are about state management on the client. Aka redux, or vuex etc. Which I reply. “You don’t need that. State lives on the server. It’s simple”.
Since having this library and it getting as big as it has, having to defend it and defend SSR. I’ve fully burnt out of JavaScript and frontend all together.
We use my library in production at work, and have started talking about migrating to Nuxt. I’m planning on changing teams before that happen.
Javascript is just hype driven development, of the worst kind.
the js world is full of people coming from jquery plugin development. they‘ve been thrown into unknown waters by react, angular & co because „javascript“. but they don‘t know shit about everything that happened before their time.
it seems like they‘re very good at marketing though. i came across folks in management naming react as a solution to everything. even to design problems.
we have at least two problems now. sjw and js.
it‘s sad.
So no, an SPA without SSR doesn't include useful data in the first payload.
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.
All of that for a red rectangle with the word "Patreon" in the middle.
For other thoughts and ideas regarding SSR pros and cons, checkout this presentation given at Polymer Summit (http://www.youtube.com/watch?v=wYGoJ8R3nnM&t=5m35s).
We ended up with a few hundred MB of RAM for Elixir and a few GB for the Node.js servers. Basically our machines are JavaScript application servers with a little bit of Elixir running in a corner. It feels so odd.
The second time the user visits your page, the Service Worker will ideally be installed and will run, intercept the call and download your components separately, when they're needed, and save them on cache, as opposed to let the server render the components to base HTML.
Third time forwards, components are loaded directly from cache and rendered by the Service Workers.
https://webdev.topicdeck.com/ is an example of it hosted.
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.
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.
Next integrates the server and client code in a single framework, and is made for seamless deployment using Now.
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
[2] https://www.google.com/search?q="full+stack"+site:rubyonrail...
[3] https://github.com/zeit/next.js/issues/1933#issuecomment-300...
Next.js is not a 'client side framework' in the usual sense, as it encompasses server side rendering, but it doesn't mean you'll be writing your backend logic in it (unless you want to) or that it will include an ORM.
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/ - 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)
PS I'm really happy that you called out "graceful degredation to an application that continues to function in the abscence of any JS.".
I wish HN allows me to search through all the post I have viewed or favourite, I am pretty sure I asked a similar question or saw something similar with Rails.
Edit: Found it. ( Not Really similar though)
V Dom is used by browser to update your page. The algorithm involved updates only the changed parts instead of the traditional way of updating the whole page. So, I’m not sure how ‘minimum data transfer over the wire’ is involved here. Can you please clarify? Not sure if you meant getting Json data from rest apis
> Texas keeps an elixir data structure representation on the server as a cache of client state and diffs against that.
Sorry, I don’t think that’s scalable. And, in a load balanced environment, you have to have a central server for this purpose
secondly as far as scaling goes you only need to broadcast extremely small messages (on the order of bytes, not kilobytes) across servers to tell clients to update themselves using their local caches
it's extremely scale-able
further texas only builds on top of HTTP semantics - meaning it can fall back to a stateless protocol at any point and the user won't even notice other than their app working a bit more slowly (but still working) for a few seconds while the websocket reconnects to a new node
the first page load is just a typical SSR webpage though - so compression could be applied just as easily as any other SSR webpage
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.
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.
A friend did an experimental library way back using server sent events for the Yii framework. I don’t think I fully appreciated the idea back then. Admittedly Elixir seems a better fit for this pattern than PHP tho
Most of the current SPA frameworks can re-hydrate SSR'd JS without issue, so instead of configuring SSR, just use a headless browser, which is what Roast does.
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.
Disclaimer: I'm not affiliated with Gatsby.
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!
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!
The problem you have is that people are not implementing SSR on their websites and they don't host all of their assets.
That said. Even Gmail is on the order of seconds for being useful nowadays...
* 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
Those times are pretty damn terrible. Even worse, this is with a primed cache!
Trying it out with Chromium, it loaded the direct link after 3.88 seconds. Trying it out with Safari, it loaded the direct link after 6.27 seconds.
Firefox is pretty fast most of the time. Google's web apps are the only things that performs so poorly on it. I don't understand how they can have such a drastic performance disparity between browsers. Maybe they're just not testing enough on Firefox.
It would be one thing if I felt like I was getting something fancy for my wait. I don't.
13 seconds to the compose window for me. Fuck me...
Telling people "we don't like your broken crap" is one way of dealing with it.
The user still receives a page of HTML and CSS, and then JavaScript is loaded.
Yo modern Javascripters:
Stop building crappy, slow and/or unreliable SPAs.
Maybe afterwards you could tell everybody to "deal with it".
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.
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
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.
SSR->static hosting + client framework is the future.
https://githubengineering.com/how-we-made-diff-pages-3x-fast... indicates they were still doing this as late as 2016.
Instagram is also a Python app, AFAIK. Last year they contributed some memory efficiency improvements to CPython.
Shopify is likely the largest RoR site at 80k requests per second but since it's served as tons of different domains it doesn't really count.
>Shopify is likely the largest RoR site at 80k requests per second but since it's served as tons of different domains it doesn't really count.
And Different DB etc... Last time I said this I got massively downvoted for it. I think Github is possibly the largest RoR site out there.
All dynamic languages.
Scaling web apps horizontally invariably becomes more about where your data lives, how it gets scaled out, how it’s accessed, how work get processed (jobs), what caching you do, what memory requirements you have.... yada yada. Rails wasn’t ideal, but rarely are you ever working in a pristine “ideal” tech stack once you’ve hit scale and you’re 5 years into a business.
"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?
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.
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".