I'm loving htmx! as backend developer this just eliminates all the js monstrosity of packaging, dependencies and deployments..

I personally prefer sending JSON or CSV over the wire, and keeping all presentation logic on the client side. This allows me to adjust the presentation layer based on what's best for each specific client.

Why do you prefer to send HTML over the wire?

I feel that it empowers me as a Backend developer and makes me productive on both the BE and the FE.

For one it adds a simple set of primitives I need to learn on top of HTML (a basic tech to know), so no large JS frameworks or patterns to learn.

Secondly, it's really fast with regards to development speed, application speed and just getting up to speed in general. A basic MVC framework (such as Django but others also) is all you need in addition to the primitives I talked about above. With modern frameworks such as Vue or React, I need a backend with basically the Model and Controller part and then a different framework for the View part.

If you are confident that HTML will be your only target over time, then for sure this works.

The challenge can come if/when your backend needs to start servicing a mobile app, or some other channel that doesn't use HTML.

But again if you know that won't happen, no need to prematurely optimize for it.

If you structure your backend correctly, it should be trivial to build a JSON API on top of your service layer. Unless you're coupling your http endpoints to your service logic.

With webview based applications becoming more and more common, maybe HTML is all we’ll ever need.

I'm a Front End Dev and work with SPAs for the past 2 years. Working an offline-enabled PWA powered by Svelte and Redux. Honestly, I have a hunch that an HTML-based oriented development can still provide a great (measured) offline experience, without needing to rebuild wholesale to SPA.

It's a totally different ballgame if the app is mostly client-side utility anyway (calculators, etc), but the HTML + a bit of JS handling Service Worker and offline presentation should enable a great offline experience. I haven't seen it done in a large scale, but it should work.

Not if you want to adjust your views to different screen sizes and types.

Here you go:

https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queri...

In the wild, media queries are simply not enough. Often you need some JavaScript to really make things workable on smaller screens.

Why couldn't the client provide information to the server for selecting the appropriate HTML and CSS code for that particular client?

"Some Javascript" != SPA.

It's not exactly a lot of work to handle HTML for web apps and have an API for mobile clients or services. For example, if you are using Django, just add DRF with some serializers etc and re-use any common backend logic with both frontends.

1. Hotwire uses this approach for mobile as well (Hey and Basecamp are built this way)

2. Or you expose an API for those mobile clients. You might still be saving more work (but this is subjective and depends on the project).

Performance is the main one. Particularly on older android devices where script execution is absurdly slow, and network traffic is also often slow, pure HTML is a big win.

HTMX (and HTML over the wire) is giving me some hope for frontend development. React / SPAs have their place and are great technologies, but 98% of the time they are not needed.

Looks like what we used to do more than 15 years ago with taconite. I guess I'm now old enough to see history repeating in web development tools.

I'm curious if you can link me to more information on Taconite? I have been explore the techniques used by "HTML over the wire" and htmx and would like to delve deeper into older systems or technologies that were using these before.

I guess everything really is cyclical :)

I was having the same thoughts...

yep and thanks to /u/recursivedoubts for delivering an excellent package. I use htmx then mithril for those pages that really need client side interactivity. and it's refreshing.

From https://htmx.org/:

> Why should only <a> and <form> be able to make HTTP requests?

> Why should only click & submit events trigger them?

> Why should only GET & POST be available?

> Why should you only be able to replace the entire screen?

I love their motivation points, but do you really need 11kb of gzipped js to do this? At that point it's almost like a frontend library itself (mithriljs is only 9.5kb gzipped).

You can tear out some of the stuff (sse support, web sockets) and shrink it ~2k. Do away with the events mechanism and extension points, knock down the configuration options, drop IE support and probably get it down to around 6 or 7k.

It could certainly be smaller, but to support things like CSS transitions and so forth it takes some code. I've tried to keep the power-to-weight ratio high by creating a rich events model and extensions mechanism to take pressure off the core library. My goal was to keep it under 10k, but I couldn't do it (I may pull SSE and WebSocket support out to try to tuck it under 10k again.)

On the other hand, compare it with the average image on a website, and 11k isn't bad.

How would you do a data table with HTMX? Just send over the whole tbody?