Ask HN: What companies are embracing “HTML over the wire”? | Hacker News Reader

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

147 pointssodapopcan179 comments

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

View on HN

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.

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.

The new Reddit is the best example of how shitty can get things when you use the fancy tool instead of the tools you need for the job.

IF you want the page to be interactive without refreshes though, you gotta do something. Unless you are advocating a completely pre-ajax web.

https://en.wikipedia.org/wiki/Ajax_(programming)

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?

It's so fancy in fact that it sends xml

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.

the person I replied to said "we dont need any of this fancy hotloading" and then gave examples of fancy hotloading, hence me asking, and pointing out the contradiction.

Like you said, AJAX isnt limited to XML, and is really just referring to any use of XMLHttpRequest to hotload data whether its XML, JSON etc.

I wasnt asking what ajax was. I was asking if it falls into the definition of "fancy."

I think my parent proved the opposite point they meant to. old reddit and hn and wp ARE the fancy html over wire sites, and airbnb and reddit are NOT the fancy over wire sites.

AJAX was the original name for doing asynchronous Javascript calls to a server.

> Look at how HN handles it when you upvote/unvote a comment.

How?

For me, HN handles votes using deep links, since I have JS disabled.

I’ve never tried it, but my understanding is when JS is disabled HN fires off a GET request (via a link) and returns a 204 to prevent browser navigation, right?

Interestingly enough, although javascript gets used, the vote links don't trigger an XHR request - instead the javascript parses the vote URL from the vote button element and then a GET request is made by creating an Image object in JS.

You can see votes appear on your network tab under the image tab instead of Fetch/XHR, even though their response return type is text/html -- interesting little hack, although I'm not quite sure why it's done this way instead of fetching since it already requires JS.

This is simply how it was done before XMLHttpRequest existed. If it ain't broke don't fix it, I guess.

The vote/downvote buttons do not require JS. You can verify this in the same, under the network tab. There is disallowed JS request, but the vote succeeds independent of the JS not being allowed.

Why are refreshes assumed to be bad?

if the page is large and you only need to bring back a little data it's probably better to just grab the little data. or upvote so your just sending a little bit of info back to the server.

Refreshes can be very fast, and often essentially invisible in modern browsers, when you don't bloat the page unnecessarily, but I think AJAX still has a use for things like the voting button on HN or "add to cart" buttons in a web shop. It would be annoying to lose the scroll position (and perhaps other state) for each item you want to add/upvote.

(Although modern sites that try to sweep latency under the rug by immediately updating the state on the client side and later reverting the change when the server responds are perhaps more annoying.)

Also browser refreshes should definitely not lose scroll position, though I can understand how with full ones the former position might not be the "correct" one any more with dynamic content like HN... or substack comments (and how did those manage to be so slow and buggy displaying what is almost exclusively text ?!)

Not a refresh of the same page, but if you perform some action (e.g. adding an item to a shopping card), that would imply a POST request which then (according to the common pattern) redirects to the original page... so then you do lose the original scroll position, I think?

"Refreshes can be very fast, and often essentially invisible in modern browsers"

That's thanks to a fantastic browser feature that was introduced a few years ago that hardly anyone knows about: Paint Holding - https://developer.chrome.com/blog/paint-holding/

"... where the browser waits briefly before starting to paint, especially if the page is fast enough. This ensures that the page renders as a whole delivering a truly instant experience."

This is why you don't see flashes of a blank white page while a new page is loading on most sites these days.

I'm not convinced that it is... but it's not as smooth as client load-once rendering can be.

What is/was painful was, as an example, the first versions of ASP .Net Web Forms, where every client action was a full server round-trip... Server-rendered Blazor over the wire (not local or in-office server) is roughly as painful by today's standards.

I do think that it's a mix... start with basic html and enhance, or start with a component toolkit with client rendering, and inject server donut or other pre-rendering. With Cloudflare and Deno, I think the latter definitely has some traction.

I find it much less smooth having a webpage consuming constant CPU.

That's a different issue. There's no reason CPU consumption should be high when you aren't interacting with an application.

Most of the time there is no need for "it" to be an application, when it can be a page with some buttons.

There's theory, and there's practice....

Latency between page going blank and FCP, poor recovery mechanisms. Significant number of users is still on occasionally bad connections (e.g. on a train, walking into the part of the building with poor signal etc). If interaction in SPA does not work, they can try again, because they still have the UI. If page goes blank and does not load, not every user will recover from this.

If you have a complex user interface with the possibility that many parts might be in use at any given moment, full page refreshes mean your users could lose work.

This would definitely be a bad user experience.

But it doesn't mean refreshes are bad, just that the architect of that application hasn't factored them into the user experience appropriately, or they've made their interface unnecessarily complex.

All modern browsers have enough tools baked in that we can work around this without reinventing the execution and rendering pipeline (e.g. localStorage).

"HTML over the wire" generally refers to tech like [0] LiveView, [1] Hotwire, [2] LiveView, [3] Blazor, etc. They aren't about about ditching JS and more about not writing your HTML in JS (and yes, SSR).

[0] https://github.com/phoenixframework/phoenix_live_view

[1] https://hotwired.dev/

[2] https://laravel-livewire.com/

[3] https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

and https://htmx.org/ which is ... access to AJAX, among other things

Or mvc?

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.

"Plain HTML" gmail vs. any other version. It's way faster to navigate.

Remember when AJAX was supposed to make pages faster? LOL. Of course, back then we were just sending HTML to be injected, not JSON that has to be processed by 50+ Javascript functions before finally becoming HTML (or, some DOM entities, anyway).

> "Plain HTML" gmail vs. any other version. It's way faster to navigate.

And offers far less features. Attaching a file to an email takes ages without drag and drop, this alone is worth waiting few more milliseconds to most people (Gmail loads in less than 2 seconds on my crappy hotel wifi)

It is not milliseconds on older devices and network is not always the bottleneck

Most of the time you read e-mails, not write them.

When you write e-mails, most of the time you don't need multiple attachments. The first attachment is reasonably fast to add.

Bear in mind that serving Wikipedia pages (static text documents) is much simpler that AirBnB listings (dynamic image heavy content).

It is possible to create a faster AirBnB by changing some of the underlying constrained imposed on the system (eg by accepting to serve cached, stale, listings; or by lowering the amount of telemetry) but apparently Airbnb management does not think the tradeoff is worth it.

Of course you are entitled to think that these decision from Airbnb are wrong and that they are hurting their sales. But you know the saying: « The least you know about a problem, the more convinced you are that you have the right answer »

Wikipedia - fancy html over wire (for example the searchbox)

AirBnB - client side spa.

the kind of page you like is the fancy html over wire kind

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.

Yeah, I cannot even begin to imagine what it would be like to develop AirBnb without some sort of front end framework. I used to write pure JS and jquery back in the day, and it was super easy to end up with a rat’s nest of spaghetti code. And those apps were several orders of magnitude less complex!

The alternative to SPA frameworks is not spaghetti jquery and vanilla js and full page reloads.

As mentioned everywhere around this thread, the way to do server side rendered apps has also evolved. Hotwire, htmx, Unpoly, Livewire, etc, etc, etc.

You cannot wait on round trips to the server for user interactions

Old Reddit still works fine, and I’d argue better than new front end heavy Reddit. You are right it may be for the benefit developers, but Reddit isn’t complicated enough that a heavy front end provides much benefit to the users.

Old Reddit is significantly faster than new Reddit and I found it far nicer to use, but people in general didn’t like the “old, clunky” UI. Old Reddit was much maligned for how how it looked compared to modern sites.

> Old Reddit was much maligned for how how it looked compared to modern sites.

By young people, probably. Me and my friends that I know still use it prefer old.

I do much prefer the look of new reddit, but the performance is painful. I don't see why you couldn't have a nicer looking UI, but with the performance of old reddit.

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.

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.

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.

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.

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.

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

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

Very well said

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.

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

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.

do you have any code examples you'd be able to share that uses the base_template thing?

Sure, Django docs say this about custom context processors: https://docs.djangoproject.com/en/4.1/ref/templates/api/#wri...

So in my context_processors.py file, I write something like:

    def base_template(request):
        template = "templates/base.html"  # full page

        if "HX-Request" in request.headers:
            template = "templates/base_ajax.html"  # minimal template

        return {"base_template": template}

And then my template just needs to start with `{% extends base_template %}`. Nothing needs to be done in the view (although you could technically override "base_template" there, if you need to).

I’m all in into the sprinkles approach (I’m a big fan of Hotwire and most of the times that’s what I use) but the Django templates are extremely outdated and limited. I don’t miss it at all. They’re really bad.

Compare it to Blade (Laravel) or even ERB (Rails) and it’s night and day.

Django templating is limited, but it's not necessarily a problem because you should be putting most of the business logic in the view/service/model anyways. After some initial friction, I don't have any issue with how limited they are.

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!

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.

ESI is awesome and really connects "let's just cache it" with "but what if this tiny detail in the footer changes and we'll spent hours refreshing the cache". I would've loved to do more with it, but we added a lot more optimization that need to happen before the cache and require access to the whole page, so now I do a poor man's ESI transparently caching all kinds of widgets and shortcodes (Frankenstein's WP).

I guess one could potentially have tiered caches with an optimization layer in the middle and ESI on the backend-facing cache, but that feels extreme and more brittle.

Webforms has an UpdatePanel control sending partial HTML (and even additional JavaScript) to web pages.

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.

Computer tech has been cyclical since at least the 1960s, mostly moving the cleverness back and forth between the server and the client.

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.

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

That’s exactly what we are still doing in our bootstrapped SaaS tool! Using asp.net mvc though, not web forms.

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.

Equally is putting it midldly. Jquery sites are blazingly fast today. Anything that involves compiled javascript is impossible to load on bad connections.

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.

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

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?

Atleast Fashion runs on yearly cycles, we run on 3-week cycle.

Is “HTML over the wire” a new buzzword for SSR or is there a difference I'm missing?

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.

Was it a loop? I thought it was stagnation due to the fact that everyoen was trying to copy mobile apps and bring them to the web. It was a bad decision because mobile apps are by definition constrained and not very versatile. In any case, people seem to be picking up where they left in 2011, not a loop.

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.

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

And htmx for a language-agnostic one

I've been working on one of those frameworks, although the dev experience feels more like a SPA in this one. https://github.com/mayu-live/framework

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

Like "lets use firebase"?

At what cost? You can validate 1000s of use cases but you can't validate one that doesn't include that 25m download and simulate what a real user experiences.

Are developer tools more important than the product they create?

We do browser based end-to-end testing which tests the frontend and backend at the same time using a single tool (Capybara in our case). We take snapshots at various points during the test runs which are then compared to previous runs for visual regression testing.

Nothing is isolated so it's probably slower. The tradeoff is that the tests are really simple for how much they cover, and they're entirely separate from the implementation details so refactoring/changing technologies becomes really easy. It's an old project and we've incrementally migrated from jQuery to Backbone to React to Stimulus with the same tests. Conceivably we could change the app to a SPA and keep the tests.

I have no way to really know if it's better than anything else (though I am interested in that question!), but I think it has worked out pretty well for us. One metric might be that our main app has been around for 10+ years, we're still delivering features daily, and nobody is complaining about a rewrite.

How do you test cases like, "the app should show an error screen when an error occurs in the database or server-side application layer"? In the SPA approach, I find these things quite easy to model with a service worker; just mock JSON API with the non-200 response code with body. I do see the merits of end-to-end testing but I've found it quite simple to mock the interface rather than ensure the database is primed with my situation in mind, or setup or teardown those records to ensure my 404 page renders correctly. And then I have to know how those parts of the system work, to create my test case. It does seem like an increase in cognitive load.

We have some tests like that. We're injecting a stub to generate the error condition and then testing the output. The test code runs in the same thread as the server so we can temporarily inject a stub into the server for some cases.

You're right we have to know something about the system to know where to inject the stub, and in fact it makes the test brittle in case that implementation detail changes (which has actually happened and failed these tests before), but it doesn't really matter where we inject the stub to cause the error response, so it's not as bad as it sounds. I think it might be pretty analogous to knowing where to mock the JSON API w/ a non-200 response code.

We very rarely stub anything and consider it a code smell, this is one case where we made an exception though because there is otherwise no way to generate an error message via the user interface.

it looks no different with ssr apps, and you don't have to give up any of what you mentioned at the beginning

Indeed this is one of the challenges of hiring front end for SSR apps. There's now a whole generation of front end engineers who have never had to build a plain old SSR html page, and never had to use or read any language other than JS. Learning this style of development is starting from scratch for them. Yes SSR is a radically simpler stack, but not until you learn it. And you probably need to learn at least on more language.

That sounds really expensive for the server.

Partly, but it especially means things like Phoenix LiveView[0] or htmx [1]. With these you can create SPA like experiences by sending partial html updates from the server and applying them by some light JS to the UI (which you don't have to write yourself).

[0] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html [1] https://htmx.org/

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 wouldn't call Element.replaceWith a codification of html-over-the-wire

Nor would I. I was talking about load(): http://api.jquery.com/load/

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.

Maybe we need to invent some sort of server-side MVC framework? lol

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.

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.

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/

Unpoly (https://unpoly.com/) should be mentioned as well. Much like htmx but with more features.

Are you aware of any ecommerce sites currently using unpoly?

I wrote my own unpoly (so to speak) to transition from React, for a pretty big ecommerce marketplace: https://solovyov.net/blog/2020/a-tale-of-webpage-speed-or-th...

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!

There are user-focused reasons to build sites without (requiring) javascript.

For example, respecting the wishes of users who disable scripts to avoid most of the web's privacy, security, and attention disruption problems.

Crafting the HTML is embracing the browser, no?

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/

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

You could probably split up the image into smaller pieces (let's call it slicing), put them together in a table, and only update the cells that changed.

Add "no scrolling" to my list. None of the military-industrial browsers that I built in the late 80s and early 90s had scrolling.

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

ColdFusion!!! Nice!!!

CF = Cloudflare. I would hope nobody is still writing things in ColdFusion these days :-)

the client i'm working with right now uses ColdFusion extensively.

Someone added a ColdFusion Markup Language generator to https://curlconverter.com/cfml/ last year and after a few months I decided to remove it since I've never heard of it so nobody could possibly be using it, and the next day the guy who added support for it and 3 other people complained about it, so it seems like they're out there.

https://github.com/curlconverter/curlconverter.github.io/pul...

I wonder how much visitors you have, i.e. how much popular is it? If its not a secret of course.

I couldn't imagine any web developer need such kind of tool [knowing curl by heart], but obviously I'm in my own bubble and I'm wrong on my assumptions.

70,000-90,000 unique monthly visitors, according to client-side analytics.

Someone wanted to buy the site so we added client-side analytics in August to December 2022

https://plausible.io/curlconverter.com?period=custom&from=20...

We also moved the site from GitHub Pages to Cloudflare Pages just for August 2022, to run server-side analytics to count the people that block ads and that said 116k "visits", compared to 67k "unique visitors" and 112k "total pageviews" from client-side analytics for the same time period (August 31st is missing because Cloudflare only lets you see 30 days). 116k and 112k are really close, which makes me suspect that I misunderstood and Cloudflare is actually also doing client-side analytics, but if that's not the case then it's 120,000-150,000 monthly visits.

Back in September 2021 the site used to have Google Analytics and that said 25k users with 60k sessions from Sept 17 to Oct 17 2021.

They offered us 15K for the site so we didn't sell it and they cloned it, since it's all open source. We removed the analytics again in January 2023 for the same reason we removed them before, curl commands copied from the browser might contain cookies or auth tokens and it's easier to not worry about the possibility of them accidentally getting logged by the analytics and also because it's kind of expensive and I got laid off in November. Knowing people are using your code is nice though.

> I couldn't imagine any web developer need such kind of tool [knowing curl by heart]

There might be some edge cases in Bash syntax or curl's option parsing you might miss that the tool won't (or vice versa), but you're right, rewriting a curl command in another language by hand is straightforward. But if you're doing it a lot it gets tedious and some people are writing web scrapers and bots full-time. You usually start with a curl command from the browser or some API's documentation, and if you want to do something with the returned data, you rarely want to do it in Bash. You could call the curl command and read the output in Python but you'll have better error handling and less code if you use an HTTP library. A better solution would be adding "Copy as Python", "Copy as R" etc. to Chrome directly and I opened a PR for Python but I haven't polished it enough for them to just merge it

https://chromium-review.googlesource.com/c/devtools/devtools...

curl is kind of complex and expects you to understand HTTP. It's better if developers that don't want/need to learn it can bypass it.

> curl is kind of complex and expects you to understand HTTP. It's better if developers that don't want/need to learn it can bypass it.

That's my understanding what is meant to be web developer.

I'm correcting my understanding of reality with comments like yours, thanks!

The behaviour seems very similar to the Astro framework.

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

I've come to the same conclusion. Heck, as a solo developer, it is quite hard to keep in mind all the different states (server, client, request, session...) and on top of it make it also reactive. Mixing things increases the complexity.

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.

Would you please provide any hint on what company this is at? I am really curious.

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.

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.

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.

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.

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.

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.

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.

Is there a way to collapse HN comments on lynx? I tried it but could not tell which comments were replies to others vs stand-alone comments.

There may be a way to collapse comments, but I didn't try it yet. If there's no complete page refresh on click, it could be Javascript manipulating the DOM, and that may not work on lynx.

I couldn't tell which are replies versus standalone, since everything is left-indented. However, some comments are definitely replies if there's ">" for example, or abbreviated and curt. But I found this "contextual friction" let me be more forgiving in a way.

The comments all seem to float in the ether, utterances in the night. The extra effort to traverse to each comment--arrow, arrow, arrow, arrow--somehow made the whole thing like an exercise in deliberate consciousness: I was seeking after content, rather than having it just be laid out and scrollable.

I was also using the framebuffer. It didn't take much to fill the screen. Moving to the next page happens more often and is so manual; you almost want to wring meaning out of every screen.

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.

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

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.

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

It is quite easy to say “you should definitely use x” 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.

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.

https://builtwith.com/?https%3a%2f%2fwww.otto.de%2f

Ablecommerce (asp.net)

What led you to think it was Java EE ?

I checked out the profile by their main software architect Guido Steinacker [1], their job offerings on otto.de [2], their github (they have repos for classic Java EE patterns, like their Wicket component tester and HAL stuff, which is a default in spring data) [3], and their stepstone, which mostly shows spring and java jobs [4]. There is no single asp.net job listed and they also don’t have anything asp.net related on their github. I don’t think that builtwith is an accurate data source.

[1] https://www.xing.com/profile/Guido_Steinacker

[2] https://www.otto.de/jobs/de/jobsuche/-java/index.php

[3] https://github.com/orgs/otto-de/repositories

[4] https://www.stepstone.de/cmp/de/Otto-GmbH-Co-KG-28607/jobs.h...

Basecamp, Github

yeah, i thought github was moving away from html over the wire; rails to react.

https://news.ycombinator.com/item?id=33576722

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?

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.

I wouldn't assume building the html on the server uses any more server resources than building JSON. Either way you are just building a giant blob of text. With html fragment caching the server could easily be doing less work this way.

Unless you are doing string interpolation to generate JSON, it is absolutely more resources... and how much will depend on the framework(s) in use. To/From JSON is a straight serialization/deserialization, where templates are a bit more involved.

It's not a crazy amount of overhead... and even then, it's a matter of how interactive the site/application is or needs to be. You can have a horrible or great UX in either direction in different use cases.

We’re using Hotwire extensively at https://mailpace.com

It’s a joy! But we’re not hiring…

Link: https://hotwired.dev/

It is indeed. I’ve used it with a Laravel backend and it worked great.

Now using it in a node project and it also works wonderfully

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/

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.

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.

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.

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?

You serious man? I see it every day when I have to use this god-forsaken Rails shit, it's so fucking slow to load the view and THEN it loads the data, literally the worst of both worlds

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.

Remix Run is what you want

No thanks.

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.

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!

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

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

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

Considering their stack, I'd say probably GitHub?

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

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

Reply on news.ycombinator.com