WingNews logo WingNews GitHub [2]
top | item 34744348

Ask HN: What companies are embracing “HTML over the wire”?

147 points| sodapopcan | 3 years ago

I'm a web developer who has been in the market for a new job for a while now. As someone who has never enjoyed working with frontend JS frameworks (yes, I sucked it up and learned them and have worked with them professionally) I'm wondering who all the companies are who have embraced the semi-recent "HTML over the wire" movement (Can you imagine... using hyper text transfer protocol for transferring hyper text? Seems nuts, I know). It's a massive slog shifting through endless React/Vue/etc-focused jobs out there. Even if you use React in small areas where it pulls its weight but generally try and stick to simplicity of sending plain ol' HTML, I'd love to know who you are. Even if you aren't hiring, it's nice knowing you're out there fighting the good fight :)

179 comments

order
[+] JonathanBeuys|3 years ago|reply
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.
[+] tshaddox|3 years ago|reply
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.
[+] phiy|3 years ago|reply
This disregards the business model behind the companies. There are no transactions for wikipedia or hacker news.

Both AirBnB and Reddit are incentived to collect a massive amount of data on their users and to maximize the experience in any way possible. They need the data to understand user behavior and feed it back into the recommendation algorithms. For both hospitality and social media, users look for images/video content since it is much more powerful than text for most people. All of their competitors have equally bad performance for similar reasons, so they don't lose a competitive edge.

Hacker news specifically goes for a retro look with an interface that has not changed significantly in decades. Wikipedia simply doesn't have the money or engineering capacity to support a more robust platform like airbnb or reddit.

[+] _Donny|3 years ago|reply
I am incredibly annoyed by slow websites. I noticed that I have started using my browser in a very asynchronous way where I open multiple tabs, do a single action, and move to the next one. When I get to my last tab, the first is hopefully ready.

For instance, on GCP, I:

  0. Open 2 tabs for a 2 google cloud instance
  1. For each tab, I click on the action I want. E.g Logs, deployment, and networking. 
  2. Then, for each tab again, I click on the nested action I want
  3. Repeat step 2
It might sound like a lot, but each click easily takes 5-10 seconds, which is an excruciatingly long time if you spend a lot of day on that site -- and yes, it takes just as long doing it sequentially. Furthermore, I usually use fairly capable machines, so performance should not be an issue IMHO.

It does not happen on all sites, and I know GCP is a very complex site, but it happens often enough that it has become a habbit to me.

I love sites like Wikipedia or HN where everything is snappy.

[+] jonatron|3 years ago|reply
old.reddit feels fast, which is why I use the Old Reddit Redirect extension.
[+] basicallybones|3 years ago|reply
Frontend frameworks developed in response to the need to develop/maintain very complex browser-based applications like Facebook across a large team of developers. AirBnB/Reddit have dramatically more complex user behavior and are much more input- and media-oriented. You cannot wait on round trips to the server for user interactions, and you cannot just do hybrid client/server the old jQuery way on big applications because you get spaghetti code.

Comparing Reddit and Wikipedia is like comparing a motorcycle to a bicycle. They are different, with specific strengths and weaknesses. Both design/engineering paradigms have a place, imo.

[+] keizo|3 years ago|reply
I’ve been working on a note taking app exactly because of this.

https://grugnotes.com

I can load 3 years of notes on a single page 100kb.

[+] nicbou|3 years ago|reply
Too much of the web is developed on fast machines with fast internet and high quality monitors.

I spend a lot of time in trains, hotels and airports, and I carry a 2017 12" MacBook. It strongly influences how I build websites. It's infuriating to wait for pure content to load because it's tied to a bunch of crap that isn't what you want to read.

In that context, developer docs are often the best kind of websites.

[+] bradgessler|3 years ago|reply
I did a similar test on news websites at https://legiblenews.com/speed about 6 months ago that made the rounds here. It’s insane how many MB some news sites push over the wire and the number of requests they make from ads and other JS “features” that should be a few hundred KB.
[+] danielrhodes|3 years ago|reply
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, weigh decisions against team capabilities, ask yourself if your decisions are for your own personal reasons or have significant positive user/business 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".

[+] jacobsenscott|3 years ago|reply
People also need to work within the constraints of the chosen stack. You can make a very good experience in either a SSR and SPA app. But you can't make identical experiences.

Product designers are notoriously bad at working within the constraints of a stack - so when you choose SSR with hotwire or whatever, you definitely need to push back when a product designer hands you a mock up of something that can't be done easily with SSR. Don't create some mess of SSR and JS. Tell the designer to go back and redesign the experience so it meets the constraints of the stack.

So when I hear "the complexity of the app increased" I'm hearing "the designer invented something that doesn't work with our stack" and rather than saying no, the devs just tried to forge ahead with the wrong tools. (Obviously I'm projecting experiences I've had :))

[+] sodapopcan|3 years ago|reply
I agree 100%. Doing everything on the client has its place, but those aren't the type of apps I'm interested in working on. My problem is that for the bulk of web apps out there, a frontend JS framework (I'm sorry I don't have hard data on that but going by experience and the experiences of people I know). The "good fight" I'm referring to is not defaulting to React to build your information app that has very little interactivity. The recent "HTML over the wire" frameworks lean heavily on abstracted away JS to give you a middle ground between SPAs and pure SSR.
[+] ivan_gammel|3 years ago|reply
Exactly. My rule of thumb is that SSR is good when you optimize conversion (hence focus on bounce rate, FCP, time to interactive), SPA is good when you optimize UX (hence focus on interactivity, response time, recoverability etc). On the customer journey SSR is usually everything before registration and login, SPA is for most of the things after (except some embeddable static content like help pages).
[+] pphysch|3 years ago|reply
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. Great for progressive enhancement.

- 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.

[+] noveltyaccount|3 years ago|reply
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!
[+] gpvos|3 years ago|reply
Computer tech has been cyclical since at least the 1960s, mostly moving the cleverness back and forth between the server and the client.
[+] matwood|3 years ago|reply
Same. AJAX was around, but quite new. Browser JS engines were hit and miss speed wise. Creating elements in the dom could be super slow depending on the browser. My solution then was to have the server send html as a string and then drop it into an existing element. Felt super hacky at the time haha.
[+] lukaszkorecki|3 years ago|reply
I wrote some jQuery-based code to enhance a page rendered by Rails this week, it felt pretty great as compared to waiting for Webpack to do its thing
[+] 88913527|3 years ago|reply
Returning html fragments is quite stateful and contextual to the rest of the DOM structure. Ex: You might be referencing class names; is there already a stylesheet loaded that defines those styles? Are those styles actually what you want? I try to avoid these sort of "hidden dependencies" because it makes it harder to reason about a system and make changes to it without unknowingly breaking something.
[+] snorkel|3 years ago|reply
ASP! bah! Perl was all we needed!! Kids these days with the Reacts and Angulars messing up a perfectly fine cyber space that wasn’t broken! “HTML over the wire” hah! Where did all the Netscape buttons go?
[+] tanepiper|3 years ago|reply
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.

[+] nickswan|3 years ago|reply
That’s exactly what we are still doing in our bootstrapped SaaS tool! Using asp.net mvc though, not web forms.
[+] tracker1|3 years ago|reply
Until the page gets complex and viewstate gets ugly too... Add in a dialup connection and you were in for worlds of pain. By today's standards of interactivity, I find the modern take (server rendered Blazor) as equally painfully slow to respond.
[+] antoniuschan99|3 years ago|reply
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.

[+] ravagat|3 years ago|reply
I forgot where I saw it but I recently read that McMaster-Carr has their setup with ASP.NET and their website is truly a beautiful form of software
[+] wvenable|3 years ago|reply
Webforms has an UpdatePanel control sending partial HTML (and even additional JavaScript) to web pages.
[+] ryloric|3 years ago|reply
Atleast Fashion runs on yearly cycles, we run on 3-week cycle.
[+] jerjerjer|3 years ago|reply
Is “HTML over the wire” a new buzzword for SSR or is there a difference I'm missing?
[+] jay-barronville|3 years ago|reply
I understand your frustration. I feel the same way. I think the web development landscape has become unnecessarily complex. I sometimes miss how simple it used to be to just throw some PHP files together and have a working website up and running. Granted, those “simple” websites came with their own set of issues (especially security-wise), but I still miss that simplicity.

Over the past 10-ish years alone, I’ve watched web development go through so many phases, it’s not even funny. Anyone remember gulp.js? Well, I remember a time when every conference talk mentioned it and you were weird if you didn’t use it. Backbone.js anyone?

In my experience, I’ve found that most folks can’t even tell you WHY they use React or insert JavaScript framework here.

Not too long ago, I was stepping through some “hello world” code for a trendy framework and the amount of code that was touched just to write “hello world” in the browser felt absolutely ridiculous to me.

Let me stop myself before I go on a prolonged rant . . .

Anyway, all that said, this is why I’m a fan of SvelteKit (Svelte) and Remix (React). I think they provide a decent balance of modern features while building on native web features/protocols properly.

[+] MrPatan|3 years ago|reply
I think I get it. You really don't want to shift your mind to the browser. Your mind is in the server, you know what's up in there, and distributed systems are complicated, so one of the ends should be made as dumb as possible. I get it.

Except, guess where the mind of the user is? On the other side of the browser. Embrace the browser, server people, it's closer to the user!

[+] gwbas1c|3 years ago|reply
Where I work we're currently developing an administration / employee-only pages using server-side Blazor.

I don't know if this counts as "HTML over the wire" because server-side Blazor contains some magic to make the page kinda-sorta act like AJAX. It's a little laggy, but for our purposes, it's "good enough."

(The customer-facing pages are going to be SPAs, for very good reasons.)

https://optirtc.com/company/careers/

[+] bunnyswipe_com|3 years ago|reply
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
[+] intrasight|3 years ago|reply
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.
[+] someweirdperson|3 years ago|reply
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.

[+] lordpankake|3 years ago|reply
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

[+] degun|3 years ago|reply
The behaviour seems very similar to the Astro framework.
[+] lolinder|3 years ago|reply
> Even if you use React in small areas where it pulls its weight but generally try and stick to simplicity of sending plain ol' HTML

The reason why so many apps use React/Vue/whatever for everything is because this hybrid setup is far from simple. It leaves you with two different ways of rendering views, which creates unnecessary context switching for developers, and the interface between the two is often ugly and complicated and prone to memory leaks if you're not careful. It also prevents you from taking advantage of the most powerful patterns in these frameworks, which rely on the assumption that it's running as a single page app.

The fact is, if your app has functions that require a JavaScript framework to work, the most straightforward answer is to build the whole app in that framework, rather than trying to cobble together multiple front end systems.

[+] kbuchanan|3 years ago|reply
We embraced Hotwire with a Clojure backend. Favorite things:

- One language model (i.e. no JS, just our favorite backend language)

- Extremely minimal front-end tooling

- All data is manipulated with the same tools

- No client-side routing, validation, or... really much at all

P.S. We even wrote our own import-maps solution to avoid needing a JS bundler for the small stuff you can't do without JS.

[+] brink|3 years ago|reply
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.

[+] marcopicentini|3 years ago|reply
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).

[+] sodapopcan|3 years ago|reply
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.
[+] freedomben|3 years ago|reply
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.
[+] jeanlucas|3 years ago|reply
All companies using Elixir / LiveView, there are quite a few
[+] sodapopcan|3 years ago|reply
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.
[+] nelsonic|3 years ago|reply
100% JS fatigue after having worked as a professional full-stack JS dev for 8 years. Using Phoenix LiveView to build our MVP: https://github.com/dwyl/mvp haven’t written JS in months (except maintaining old Open Source packages) don’t miss it at all.
[+] beebeepka|3 years ago|reply
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.