|
|
You don't even need a fancy "send html fragments over the wire" approach to create a better user and developer experience. Just sending full pages, server side rendered, like Hacker News and Wikipedia do is fine: Going from the HN homepage to this topic we are on: 36 KB in 5 requests.
Going from the Wikipedia Homepage to an article: 824 KB in 25 requests
Going from the AirBnB homepage to an apartment listing: 11.4 MB in 265 requests.
Going from the Reddit homepage to a Reddit thread: 3.74 MB in 40 requests
In comparison to AirBnB and Reddit, HN and Wikipedia feel blazingly fast. And I am sure the developer experience is an order of magnitude nicer as well.
|
|
 |
|
Is that AirBnB stat including “content” stuff like images or embedded maps? It’s still worth critiquing the bandwidth spent on that stuff, of course, but it wouldn’t really be fair to include it here when the discussion is about the architecture of page transitions.
|
|
|
|
Page transitions are much faster for me on Wikipedia than on AirBnB. Whatever I click on AirBnB, I get a white screen, then some placeholders, then the placeholders one after the other get replaced by the actual content. Whatever I click on Wikipedia - its just there instantly.
|
|
|
|
|
|
A bit of Ajax here and there is fine. Look at how HN handles it when you upvote/unvote a comment. Look at how old.reddit.com handles it when you click "load more comments" in a long thread.
|
|
|
|
isnt ajax fancy sending html over the wire? or is it just the non fancy way?
|
|
|
|
AJAX stands for Asynchronous JavaScript And XML--it was originally designed for asynchronously manipulating XML data using JavaScript because at the time, the future was XML. The act of using JavaScript to send requests is still sometimes referred to as AJAX, despite usually not dealing with XML in any way. The most common use for sending asynchronous requests is making API calls, which today generally return JSON, but you could use AJAX to load HTML and dynamically add it to the page.
|
|
|
|
|
|
old.reddit feels fast, which is why I use the Old Reddit Redirect extension.
|
|
|
|
Yes, I also use the old Reddit. What's funny is that the old Reddit makes use of dynamic loading of content here and there the right way. The "load more comments" of the old Reddit is nice and fast. While the "continue this thread" of the new Reddit is annoying and slow.
|
|
|
|
Indeed it is; the UX/UI is also better compared to the low density of information with the new design.
|
|
|
|
People have gotten way too religious over SPAs, SSR, etc. Should you use X? Maybe it depends. I have been burned by using SSR when the complexity of the app increased and suddenly doing SSR was getting in the way and now I was uncomfortably mixing JS with server rendered pages and struggling to maintain state. I've also been on the other side, using React and creating more complexity than was needed. The point is: don't be dogmatic. Get requirements, extrapolate what could happen in the future, use first principles, ask yourself if your decisions are for your own personal reasons or have significant positive user impact. Engineers who rush to use one technology over the other without doing their homework are just doing bad engineering. It has nothing to do with "fighting the good fight".
|
|
|
|
old man alert Back in my day, we wrote ASP.NET that was all server-side-rendered HTML. Once in a while we got REAL FANCY and used JQuery to make PARTIAL HTML requests and update only FRAGMENTS of the page. Hooboy I knew that fashion was cyclical but not tech!
|
|
|
|
I wonder if people nowadays know that Ajax (aka. partial HTML requests to update fragments of the page) was a huge leap. Gmail is one of the first to have adopted this paradigm.
|
|
|
|
Back in the days of MySpace, we were working for a client in UK Sports betting (Littlewoods Pools) - and we managed to persuade MySpace to let us have a script tag on the page, pointing to a JS file we controlled. The script injected jQuery, then we replaced the page with HTML fragments. We had an Adobe Air installer, a Flash game and even had an RSS feed. Funnily enough today we're mostly working towards using ESI - which reminds me of mod_include back in the day.
|
|
|
|
Webforms has an UpdatePanel control sending partial HTML (and even additional JavaScript) to web pages.
|
|
|
|
Is “HTML over the wire” a new buzzword for SSR or is there a difference I'm missing?
|
|
|
|
It is rendered server side, but typically the server keeps track of only what needs to change and sends as small as possible an update to dynamically update the DOM. You end up with a user experience that feels close to an SPA, but a dev experience that feels close to traditional SSR.
|
|
|
|
Having only worked at SPA places, it's hard for me to imagine not having tools like Storybook, Chromatic, and Mocked Service Workers. Building the UI in isolation means with mocked API responses means I can, in parallel, validate 1000's of use cases with pixel-level precision. The backend teams can keep their focus on scalable, performant APIs. The frontend teams can focus on accessibility, consistency, etc. I've found a secret sauce that works very well in my organization, and I'd be curious to know what the equivalent would look like for SSR apps. But I can't overstate of much of a boon it's been to develop the client in isolation. Nearly all my bug reports go straight to the backend teams. It's bliss.
|
|
|
|
Yeah, I hear the HTML-only case more from people who were full-stack or backend. Giving up the tooling around SPAs would be hard. I'm not sure what the equivalent is - is there any frontend-specific advice for backend devs that amounts to "wouldn't it be cool if you gave up all your developer tooling?"
|
|
|
|
Tech like LiveView (Phoenix) and LiveWire (Laravel) are great examples of this.
|
|
|
|
|
Also Blazer Server (C#) and the upcoming Blazor United slated for .NET 8
|
|
|
|
|
|
|
The first time I saw the concept codified in a library was in a jquery function that allowed you to replace a part of the DOM. Either the method signature or the documentation pointed you to using it in pairing with AJAX requests. The first webapp framework I saw it in was Rails (turbolinks). I came to Rails late and didn't stay long so I was never clear how old or how broadly used that feature was. Mostly what I got from Rails was being more comfortable writing NodeJS code, which stole shamelessly from Rails.
|
|
|
|
I think it's HTMX etc, so yes SSR. That was how I started building web apps in my first job as a dev, crazy how the loop of front-end technologies is only like 10 years.
|
|
|
|
I think it's referring to partial server-side renders. SSR is usually used to refer to statically rendering pages, while the "new" thing is to dynamically update pages with chunks of SSR-created HTML.
|
|
|
|
Others already answered but that's why I bothered making that little quip about HTTP. It's kind of a ridiculous name but also funny and appropriate since it's trying to state that it's a return to form. My brother who is just started working with web tech recently didn't even realize that it was possible to send HTML over HTTP, lol.
|
|
|
|
Maybe we need to invent some sort of server-side MVC framework? lol
|
|
|
|
My last gig used Rails' Hotwire, and my new gig is using Phoenix Liveview. Thankfully people are waking up and seeing that JS is most appropriate as a "last resort" technology.
|
|
|
|
|
We are using Django+HTMX for internal applications. Some random tips: - Write a "Django context processor" to inspect requests for "Hx-Request" header, and set a "base_template" variable accordingly. This means that any template that {% extends base_template %} will react to being a full page or just a fragment and you don't even have to think about that in your view logic. - You can get reactive JS elements (for example, a d3.js viz that updates when new data comes in) in a few lines of inline JS by using MutationObserver, and "abusing" HTMX by using views that return JSON targeting a <script> element (`json_script` templatetag can also be used here). In summary, you tell your fancy JS element to render or update whenever a particular <script> element is mutated, and all of it is orchestrated by HTMX.
|
|
|
|
I'm building a webapp[0] for turning Clickup docs into static sites, using CF Workers. There isn't a framework for Workers that has the flexibility I need, so I home-rolled one that only sends rendered HTML over the wire. Async components are supported too, so if I have a particularly data-intensive component the renderer just inlines a tiny JS script that sends a request to the worker again, which then returns just that component in HTML. Could be worth releasing on its own as a GitHub project! [0] https://intenso.app
|
|
|
|
|
Well I'm glad I've discovered HTMx with this thread, I will try it out with my next project, really tired of SPAs and their bulkiness
|
|
|
|
You can also go to the extreme of "jpeg over the wire". Your "web browser" could probably be implemented in <1000 lines of of code ;) No state, no cookies, no million lines of bundled JavaScript.
|
|
|
|
If a "real" browser is used that needs javascript to request a jpeg of a size appropriate for the screen. There might be something that's good enough through css, not sure.
|
|
|
|
Little problems with scrolling but constant updates when a page is resized (changes in layout) - maybe it's worth it...
|
|
|
|
All companies using Elixir / LiveView, there are quite a few
|
|
|
|
I had a job writing Elixir but it was a terrible fit. Most Elixir jobs want people with multiple years of Elixir experience and I have 8 months, lol. I do have an interview lined up with an Elixir shop, though.
|
|
|
|
For those mentioning frameworks that update the page by getting HTML from the server and patching it into the page: how do you deal with server-client skew?
|
|
|
|
I work for a B2B SaaS and we use Ruby on Rails with Hotwire and it's great! Almost zero JS (no Vue.js, no React, or else).
|
|
|
|
Are you hiring? lol. I'm a rails dev who shifted over to Elixir for a bit, but I'm currently building a project with Hotwire.
|
|
|
|
FWIW most of the companies using Phoenix (Elixir) that I've talked with are sending HTML over the wire, either with LiveView or traditional Views.
|
|
|
|
I used to work for one, but many companies using Phoenix want more years of Elixir experience than I have.
|
|
|
|
|
|
I'm building a completely native HTML spa app over at lona.so (just html + js web components and i bundle it myself). Still very much so early days but check it out!
|
|
|
|
|
|
|
Considering their stack, I'd say probably GitHub?
|
|
|
|
|
Unpoly ( https://unpoly.com/) should be mentioned as well. Much like htmx but with more features.
|
|
|
|
Isn't making a request for almost any user interaction a bit too much? I am more in favour of BE telling FE what to render. I honestly believe many apps could be simplified with better abstractions than hard coding html into messy components. Not saying it's a great approach for super complex layouts, of course.
|
|
|
|
It depends on the usecases & application reqs. There are times when server-rendered content can have enormous benefits over a SPA. Check out this djangocon talk where a SaaS product moved from react to htmx. https://www.youtube.com/watch?v=3GObi93tjZI
|
|
|
|
I'm talking about tech like LiveView, Hotwire, LiveWire, Blazor, etc. They use JS (in some cases with websockets) behind the scenes to send small bits of html which are patched into the DOM. The win here is that you can write all your business logic on the server and don't need an intermediary API for your frontapp to talk to your backend app, you just send HTML. If you're building an where you are going to open up an API, there is a little less benefit, but I've worked on projects in recent years where the API exists solely to be consumed by one client.
|
|
|
|
When I use apps like this - GitLab - I am struck by how much wasted user time such an approach leads to. Everything is a page refresh Send me some counter examples? Im a big SPA fan and there’s lots of good examples
|
|
|
|
Everything in a page refresh typically only happens with these solutions as a fallback when Javascript is disabled. And if Javascript is disabled, what do you really expect to happen other than everything is a hyperlink?
|
|
