What companies are embracing “HTML over the wire”?

Question

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 :)

JonathanBeuys · Accepted Answer

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.

danielrhodes · Answer

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

pphysch · Answer

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

noveltyaccount · Answer

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!

jerjerjer · Answer

Is &ldquo;HTML over the wire&rdquo; a new buzzword for SSR or is there a difference I'm missing?

jay-barronville · Answer

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 &ldquo;simple&rdquo; 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&rsquo;ve watched web development go through so many phases, it&rsquo;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&rsquo;t use it. Backbone.js anyone?In my experience, I&rsquo;ve found that most folks can&rsquo;t even tell you WHY they use React or insert JavaScript framework here.Not too long ago, I was stepping through some &ldquo;hello world&rdquo; code for a trendy framework and the amount of code that was touched just to write &ldquo;hello world&rdquo; 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&rsquo;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.

thrownaway561 · Answer

I was just watching a talk about htmx which is awesome looking. i'm a rails guy myself so i am really interested in using hotwire in some projects. htmx looks like a very nice crossplatform approach.https://htmx.org/Here is the talk: https://htmx.org/essays/a-real-world-react-to-htmx-port/

MrPatan · Answer

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 · Answer

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 · Answer

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 · Answer

You can also go to the extreme of "jpeg over the wire". Your "web browser" could probably be implemented in

lordpankake · Answer

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

lolinder · Answer

> Even if you use React in small areas where it pulls its weight but generally try and stick to simplicity of sending plain ol' HTMLThe 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 · Answer

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 allP.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 · Answer

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 · Answer

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

freedomben · Answer

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 · Answer

All companies using Elixir / LiveView, there are quite a few

nelsonic · Answer

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&rsquo;t written JS in months (except maintaining old Open Source packages) don&rsquo;t miss it at all.

beebeepka · Answer

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.

turtleyacht · Answer

Browsing HN on lynx (not logged in, haven't figured out cookie jar, settings, etc) in the early morning, it was a completely different experience: a dark screen, monocolored text, and comments.It felt like a darkened cafe of inquisitive, sometimes humorous--at turns indignant or snarky--conversation: even intimate, close-quarters, sipping at coffee or wine.That's what I miss about HN's past feature: we can't browse to a segment of a day. The front page changes across twenty-four hours, an ebb and flow of ephemeral delights.I guess that's what I'll set lynx with next: sessions, printing, and a way to quickly save snippets of text. The comments are so valuable for follow-up.

xjay · Answer

This seems like a good time to ask web people to stop using the private unicode range for icons. It's bad practice because downloadable fonts are considered optional, and there is no fallback equivalent to alt text for undefined glyphs.

realrocker · Answer

Been working on a html over the wire library in Go: https://github.com/livefir/fir. It mostly works but still work in progress

root_axis · Answer

Eschew developer fashion (and fashion contrarianism) and use the best tool for the job. It doesn't make sense to pick the tool before you even know what problem you're trying to solve.

alexbezhan · Answer

We use htmx + Node, and we are hiring. PM me on Twitter @alexblearns

pictur · Answer

It is quite easy to say &ldquo;you should definitely use x&rdquo; by giving examples of simple applications. however, the vast majority of examples given will turn the app into a soup if you want to do a thorough study. If you're happy with this soup, it's up to you. So enjoy your soups and stop criticizing the useful things people produce with empty arguments. If you have a worthy alternative, offer them. Please stop suggesting things like htmx as alternatives.

super256 · Answer

https://www.otto.de/I used them this week for the first time and was impressed by the responsiveness on my phone. I looked into the network tab and what I saw was an over-the-wire solution.However, I'm sure that you can also achieve responsiveness this without HTML over the wire. I scimmed a few blog posts, and it seemed to me like they use Java EE, although I'm not entirely sure.

reaktivo · Answer

Basecamp, Github

rahatarmanahmed · Answer

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?

tracker1 · Answer

It depends... are you delivering mostly static content or creating and interactive application front-end? Most sites are somewhere in the middle and so should the responses.For me, if it's an application ui/ux, then the rendering should be almost exclusively on the front-end. It's just delivered via a web server instead of installed. Yeah, it's larger than server-sent. It's also emphatically not tying up server resources for template processing, instead using the super computer on your desk or in your pocket.I frankly feel ill when I see more than a couple hundred kb of compressed JS go over the wire... why a couple hundred, that's just where I draw the line... React + MUI with some optimizations and all the application logic should easily fit in under 300k compressed payload. If you're going over that, you're probably doing something very, very wrong. Not that you can't go much smaller and hand crafted. It's a trade-off.I also think edge development tools like Cloudflare Workers and Deno are exceedingly nice and can seriously bridge the gap closer to server rendered, but still not the same as a lot of classic legacy apps.On the flip side, I look at how much memory and resources applications use on a server as it is... They're often massively under-utilized as well. So who knows. I just know that there's nothing wrong in using the client's system to render the client.

albertgoeswoof · Answer

We&rsquo;re using Hotwire extensively at https://mailpace.comIt&rsquo;s a joy! But we&rsquo;re not hiring&hellip;

boia01 · Answer

Laminar (Scala framework) hasn't been mentioned yet so dropping it here as an awesome framework that support HTML-over-the-wire. It can be used together with React, HTMX, and many other frontend frameworks -- but doesn't have to be.https://laminar.dev/

half0wl · Answer

I've been having a blast writing plain old HTML templates for the past few weeks. It's a traditional Django app. I also use plain old CSS instead of frameworks like Tailwind (well, I use Bootstrap, but I don't use its utility classes).It's practical, pragmatic, and allows me to ship faster.

ravagat · Answer

How timely, I, too, am in the market for a new job and I've noticed that ridiculous new buzz of "HTML over the wire" or related to "over/on the wire". Thanks for writing this.

seydor · Answer

Most of us are small-time businesses that never bought the overcomplexification of anything and we were constantly shamed about it. "Server-side-rendering" is still a laughable phrase though.

nawgz · Answer

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 refreshSend me some counter examples? Im a big SPA fan and there&rsquo;s lots of good examples

lakomen · Answer

In the Go world, the only implementation I personally know of is in Kyoto, but that tool has still a long way to go.I'd be happy to learn of other Go tools using this.

gardenhedge · Answer

Remix Run is what you want

mgamache · Answer

I have been using Blazor for projects in the last year. It's okay (still immature). It uses Websockets when available (HTTP fallback) to transfer the rendered page.

yuzuquat · Answer

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!

leishman · Answer

We&rsquo;ve used LiveView/Phoenix for 4 years at River.com and are very happy with it.

revskill · Answer

SPA is to manage "CLIENT" side state, not about server-related stuff ?

alxmng · Answer

Look for companies that use Rails, Phoenix, or Laravel.

Vosporos · Answer

Considering their stack, I'd say probably GitHub?

smrtinsert · Answer

lol. We're going to end up with xslt again aren't we, it's just a matter of time.

adiabatty · Answer

Fresh does this, but I don't know who's using it in production, other than possibly the Deno people.https://fresh.deno.dev/docs/introduction