Htmx 2.0.0 has been released | Hacker News Reader

Htmx 2.0.0 has been released

htmx.org

500 pointslsferreira42140 comments

One of the happiest days of coding in the last 10 years for me happened in September last year when I added htmx to an internal self serve web app I develop for our company. With the addition of maybe 5 htmx attributes I was able to delete about 500 lines of client side JS.

The app is now chock full of htmx interactions and has very little client side JS for the size of the app and it’s a joy to work on.

Without htmx I would not be able to turn around features as quickly as I do for the wider team so thank you, thank you, thank you.

I’ve been in web dev for 20 years and this feels like what we should have made all along.

The one area I would like to see some development is the file upload experience, I’ve had to do something a bit weird to get htmx and dropzone playing nice.

can you comment on what those 500 lines actually were? react+redux?

all htmx does is replace divs on the page, so probably just code that did that

can anyone comment on what 500 lines of react+redux actually do ?

Also what line N+1 does, please.

It was all normal JS code to handle a complicated form we have on a customer facing portal page. By moving to htmx I was able to rely on the server side to handle basically everything with only a small addition of code to what it was already doing.

Isn’t that moving code around, not deleting it?

Most likely that code already existed server-side and was duplicated client-side. It's what usually happens since frontend code can't enforce invariants.

Near enough exactly this

Could you elaborate on what you mean by "frontend code can't enforce invariants" ?

Frontend code can be easily bypassed or changed so you can't trust it to keep the state of your application in good condition. Nothing prevents me from picking the same username as someone else if there is no server-side code stopping it. Nothing prevents me from replying to a deleted comment if I don't check with the server.

That means that any validation that you do client-side you need to repeat server-side. Any business logic that you have client-side you also need to repeat server-side.

I'm qurious what that code was doing that could be just moved to the backend. Usually forms have some validation for a better experience with the final validation on the server. Did you get rid of that and just show an error if the submission failed?

Near enough yes but it was a nice helpful error message with the form fully populated as they left it - as far as it looks the user it’s client side validation as the service responds with just the correct html for the form and htmx swaps out the chunk of html.

Its like old school for validation back in the CodeIgniter days.

So the 500 lines removed was literally just removing functionality in the first place (you should always validate on both sides anyway).

You deleted 500 lines of JS and added 44KB of (minified) HTMX. Better use HTMZ, which is only 166 bytes (sic!) and provides most of the interactivity: https://leanrada.com/htmz/

The problem is not the download size. The problem is the amount of code to maintain.

It's both. All the JS code has to be parsed and interpreted by web browser, which is affecting especially low end smartphones. Better use plain HTML and CSS whenever possible, see e.g. PHOOOS: https://github.com/niutech/phooos (demo: https://kodus.pl)

I don't think the author of the original comment would really care about the download size, given that it was an "internal self serve web app".

htmz looks very cool, though.

I would say, this and the CSS grid/flex system has made web development almost... enjoyable.

hey folks, i'm the creator of htmx

this isn't much of a feature upgrade, but we took the opportunity to clean up a few things and drop IE support, which will help us slim down the library over time

hopefully it's an easy upgrade for most htmx users, upgrade guide is here:

https://htmx.org/migration-guide-htmx-1/

happy to answer any questions

Huge congrats on the major number release. HTMX is simply wonderful. Using it for a major project as we speak!

Would love to hear more about how you’re using it

We are building an enterprise application that manages (create, update data) and interacts with (read, display, enable user to browse via linked entities) a large-scale knowledge graph. In some views we have live updates from the server with SSEs (alerts, logs, etc.). Everything is rendered server side with Go + stdlib templates, Material Design Bootstrap for CSS, and HTMX for all the in interactive bits like fetching and rendering an entity's properties panel, enabling add/edit for entity or edge properties, and so on. Search updates results with HTMX. Entity/property edits are done with HTMX "panels".

The entire experience using Go + Fiber (gofiber.io) + templates + HTMX (htmx.org) is fantastic. This approach has allowed us to create a beautiful modern application that's highly performant, interactive in all the places you'd expect, and simple code, deps, devops, etc.

Sounds great thanks

do you use alpinejs for better client side reactivity?

We use the alpinejs for when we choose not to round trip the server (like data validators, for example) and for cases when we need to do some client side JSON work. Mostly htmx handles what we need. You could also consider it’s client-side template rendering extension, as needed.

Thank you. htmx has me (a c++ dev) back in the web game. I can finally build entire web frontends without a single line of explicit js.

really great to hear, i love that htmx helps folks that have been knocked out of web development get back into it

No question but I wanted to say, I was pulling my hair out trying to figure out which js framework was less of an overkill, and finding htmx was pure joy

:) that's great to hear, i hope you find it useful

Are there any efforts to push functionality like this into the HTML standard? It would be nice if htmx eventually became unnecessary as browsers implemented it, and the work you're doing with proving it out in the wild seems like a crucial part of that.

yes, there are, alex petros, an htmx maintainer, gave a talk at Big Sky Dev Con on the shortest path to htmx-like functionality in HTML here:

https://www.youtube.com/watch?v=inRB6ull5WQ

we are talking w/the chrome developers about these ideas, i'm cautiously optimistic

> we are talking w/the chrome developers about these ideas

I hope this does not become a chrome-only feature in that case

agreed, but the chrome team is in communication w/the other browser makers and often drives new standards (e.g. https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...)

their latest features have started leaning into improving the hypermedia infrastructure of the web so i'm optimistic

Do you also plan on talking with the Mozilla people? And with Apple? Or will this be a kind of big daddy Google knows what's best for you, ads included?

I don't have contacts in those groups, but chrome is in contact w/them and has pushed forward hypermedia-friendly features e.g. https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

i have told my chrome team contacts about bugs in other browsers (e.g. safari not properly updating completion results when datalist elements are replaced asynchronously) and they have communicated these issues to those teams and gotten them fixed

if anyone reading this from other browser teams is interested in getting in contact w/me they can email me at carson at bigsky dot software

HTML already allows a lot of HTMX functionality with just 166 bytes of JS glue code, see HTMZ: https://leanrada.com/htmz

You can make tabs, accordions, carousels, modals, popovers and even Pure HTML Out-Of-Order Streaming (PHOOOS) using only HTML & CSS: https://kodus.pl

yep, it's an interesting idea

we are planning on implementing a minimalist version of alex's ideas from "The Birth & Death of htmx" talk as a POC for people to look at too.

Please do.

As someone that has long since soured on frontend things despite having tried everything from the start - mootools, jQuery, backbone.js, SproutCore, Ember, React, Vue, etc.

I genuinely think htmx is the only one I have liked even after I built something substantial in it.

To me that is big, to be able to walk away from a significant amount of time with something and say "yeah! I want to use that again!" instead of some variant of "it's the least bad option" is both rare and cherished so thanks for all the hard work.

:) glad to hear it, definitely appeals to some people (and disgusts some other people!)

Does this release have head-support built in or still requires an extension? I thought 2.0 was going to release with head support...

we went back and forth on it but ultimately concluded that it bloated the core too much so we kept it as an extension

https://htmx.org/extensions/head-support/

is returning 404.

Looks like it moved to here

https://extensions.htmx.org/

But this is weirdly hard to find on the new site as searching just opens a scoped google search.

Probably would be good to setup redirects to the new extensions site.

yes, need to improve that aspect of the docs, sorry!

no need to apologize :)

big congrats on the launch!

As long as hx-boost is in core, it would make more sense to have head support in core? It's difficult to really leverage hx-boost without being able to manage the head in responses.

yeah, i go back and forth on it a lot

could still fold it in at some point in the 2.x line!

Thanks for all your hard work; htmx is a breath of fresh air and an escape from the morass of needless complexity.

My only question: how can I get a set of those sweet sweet floppy disks?

working on it, need to see if the disk guy will dropship

What is your opinion on https://github.com/unpoly/unpoly as a competitor ?

unpoly is a great library that sets the standard for progressive enhancement

i often recommend it for people that want a more "batteries included" hypermedia-oriented library

Another, “I really like htmx” comment, currently using it for an internal corporate webapp, it’s great.

Oddly specific. Why implementing "forEach" and "toArray" instead of using the functions from Array.prototype? [1] I can see `Array.from` used elsewhere on the code.

---

1: https://github.com/bigskysoftware/htmx/blob/master/src/htmx....

IE support, haven't removed some of the shims, planning on doing so over time

I'll join the others in praise of HTMX, it's a joy adding dynamic functionality to any website now. Thank you!

:) thank you i hope you continue to find htmx useful

Thank you for building htmx!

Do the docs https://htmx.org/docs/ reflect 2.0 or 1.x?

2.x

He's the creator, but not the CEO. That title belongs to me...and you.

so true

https://htmx.ceo

Have you considered replacing xhr with fetch? I believe it would allow htmx to be used in even more places. Fetch can be hijacked so returning data to the htmx framework isn't limited to the network. You could "run" a server in the browser or have a native app render HTML as well.

Perhaps, there's already a good way to hijack xhr that I'm unaware of too.

Edit: Relevant link: https://logankeenan.com/posts/client-side-server-with-rust-a...

yeah, looked at it, unfortunately fetch() and xhr have a non-intersecting set of features (in particular, upload progress for xhr) so we decided not to touch it

i may restructure the internals to allow for mocking out responses using events, it comes up, especially w/ extensions

That'd be great, and I'd love to help in any way I can! Feel free to @mention me on Github. https://github.com/logankeenan

Thanks for making htmx!

Not a question, but I just wanted to say that HTMX is a joy to work. I’m using it in production to slowly replace VueJS wherever full SPA interactions aren’t needed, and it has made development so much simpler. HTMX is such a breath of fresh air from the over-engineered jenga tower that web dev has evolved into over the past decade.

Thank you!

:) great to hear

aren't mixing vuejs and htmx making things more complicated?

Not really. We were lucky that we used a hybrid multi-page architecture that makes the transition easy to manage. HTMX and VueJS are being used on different views with different routes/endpoints, so we can re-write any VueJS-based views one at a time.

This architecture was chosen partly because I am a boomer who remembers when websites were HTML files uploaded via FTP and couldn't understand why we shouldn't just return HTML for pages that didn't need app-style functionality, partly because we wanted something easy to manage with a small number of devs (HTML+vanilla js shines here), and partly because SPAs were new-ish when we first began development and the ecosystem was very immature and a long way from coalescing around a single winner (as it has now with React).

So in this case, HTMX is used with HTML templates and ordinary routing, while VueJS is isolated to single purpose SPA-style views with their own endpoints (for example, WebRTC video). And I suspect that we will even be able to eliminate the Vue-based pages altogether with a combination of HTMX and vanilla js if we want to, with how good vanilla js has gotten.

Your front page still says “IE11 compatible”.

As for slimming down over time, HTMX 1.0 was 26KB minified, now version 2.0 is 48KB minified. Why has it blown up by 184%, when it dropped IE support? Why don't keep it lightweight? Compare it with e.g. Petite Vue, which is 16KB minified.

htmx 1.9.12 was 44kb:

https://bundlephobia.com/package/htmx.org@1.9.12

and 2.0.0 was 45.3:

https://bundlephobia.com/package/htmx.org@2.0.0-beta4

i think that the better web components support blew is up a little. there is a reasonable amount of fat we can cut around IE support that is still in there, planning on doing so over the next few months & slowly

17ms over emerging 4G (and hopefully cached forever after that) doesn't freak me out too much

I was referring to HTMX 1.0.0, which was 26KB: https://bundlephobia.com/package/htmx.org@1.0.0

It's not only about bandwidth, but JS code has to be parsed and executed, which takes CPU time, which is especially affecting low end mobile devices. Compare HTMX with e.g. Ajaxial, which is only 5KB minified: https://ajaxial.unmodernweb.com

One more suggestion: use `<script src="https://unpkg.com/htmx.org@2.0.0" defer>` in `<head>` (https://htmx.org/docs/#installing).

ah, yeah, i don't know what to tell you, i've gone through the code base a bunch and there isn't much i feel like i can take out that would make much of a difference without a major step back in functionality: history support is a big one, input gathering has gotten more complex as i behave the way forms in HTML actually work, i have a lot of events that i fire, there's the queuing behavior of requests, etc.

my understanding from the browser engineers is that javascript files are compiled and kept in a cache for the browser, and i never see compilation or execution times in htmx profiles unless someone is processing a ton of htmx attributes (1000+ row tables w/ loads of hx-* attributes per row) which is an orthogonal problem

end of the day i don't think grinding out another few K on the minified source is gonna make a big diff, although we do plan on doing things like moving to modern closures (i assume gzip nukes most of that advantage, idk)

i think a minimal preact-like htmx might be interesting, not as minimal as htmz, but something close. might be worth looking at if you are interested, the concept isn't hard and w/ different design decisions you could prob keep it really small

Hey Carson! I'm using HTMX on quite a number of internal tools. It's completely revolutioned the way we've done things, especially coupled with Django. Extremely grateful for your work - you're a net positive for humanity.

HTMX is like a glimpse into the road not taken, where HTML is the main language of the web instead of JS. Sometimes the grass really is greener on the other side, and I hope as an industry we make the switch.

I believe he makes some good arguments that we really still need both, but HTML could be more powerful and allow for less JS.

This is a good essay on the topic: https://htmx.org/essays/when-to-use-hypermedia/

Definitely one place htmx can be abused is oob-swap: https://htmx.org/attributes/hx-swap-oob/, which allows any given HTMX request to replace any part of the page. It sort of destroys the concept of locality of concern that HTMX pushes for.

My cynical take: this is by design. Those web committees are staffed by companies that each have their non-web platform they're pushing (or were, until it died, see Microsoft), so even the most well meaning members are somehow contorted into compromises that make the web as a platform a bad technical choice in terms of actual design, but the best one in terms of flexibility and of course ubiquity.

It's completely stupid HTML, by default, doesn't have basic controls found in EVERY UI toolkit since circa 1980. The standard examples being ListView and TreeView.

> It's completely stupid HTML, by default, doesn't have basic controls found in EVERY UI toolkit since circa 1980. The standard examples being ListView and TreeView.

This is one of my greatest frustrations with the web as a platform. These controls are so basic they should just be there, eliminating the need to sift through dozens of third-party implementations all with wildly varying feature sets, performance profiles, framework compatibility, levels of upkeep, etc to find one that works for your project.

Well, they're not, and I can't find any good reason for why they aren't, when we're putting entire GPUs languages in there, except for the fact that somewhere in the HQ of one or more of those companies guiding web standards there is a discussion that goes something like:

Web Platform Dev: Boss, can we add TreeView to HMTL?

Web Platform Boss: Sounds cool, what are the advantages and disadvantages of doing this?

Web Platform Dev: Advantage: cross platform widget that's going to be super useful to many developers, replacing 3rd party ones of varying quality. Disadvantage: would take N months to implement and M years to have full adoptions, and yeah, it would probably increase adoption of the web platform, maybe even on mobile platform, where there is a chance that indirectly we will lose about $1-2bn per year from our walled garden, coupled with other web platform enhancements we should also make, regarding progressive web apps, local storage, etc.

Walled Garden Boss: Hey, SVP, can we please FIRE Web Platform Dev and Web Platform Boss as what they said amounts to a 2% drop in our share price?

Don’t attribute to malice… Many people working on frontend came from application or backend development and preferred the JavaScript model to a more declarative one. Not understanding enough the document context that drives the web. This makes everything more fragile and slow but hey “functionality” wins over everything else in todays world.

This doesn't explain ListView and TreeView. Or the lack of a DatePicker widget.

Look at Windows, MacOS, iOS, Android, Gtk, Qt.

Which of those doesn't have these widgets?

I'm tired of defending mega corps with thousands of employees with IQs through the roof, working on this for decades. It has to be latent malice. Banality of evil, if you will.

It is possible for normal everyday people to make contributions to the standards. I'm sure if you created a patch that showed these things working in firefox/webkit/chrome and wrote up a proposal and sent it to the correct listserv, you would at least have something more than baseless conspiracy to be mad about

I'm not a C dev and it's not my job to do something when people are literally paid for this stuff, a lot more than me. Every mainstream OS has what I'm talking about.

One example of this is the lack of an include-tag that could fetch a fragment from the server (useful for headers/footers). Developers have wanted it for decades and have been forced to reproduce the functionality themselves using frames and/or javascript.

https://www.w3.org/TR/xinclude/

The W3C specced out such a tag nearly 20 years ago, but because the browser devs are terrified of all things XML it was never implemented.

I thought the 2.0.0 release was a bit of a joke from the BigSkyDev conference, as he was doing stuff like this:

https://twitter.com/htmx_org/status/1799661735781261592

There's even some sweet ascii art on the disk: https://twitter.com/jcs224/status/1799586838161621339

Great to see the continued love of this framework. (don't throw anything at me)

released exclusively on floppy disk for the first week! :)

@dang, i know there is an htmx filter on HN due to so many posts, but it'd be nice if this one could go to the top, it's a major release

+1, if there’s so many posts then there’s clearly pent up demand to talk about it

Htmx users, can you please share your backend stacks and approaches? Me specifically interested in templaters for node (+ts) and your thoughts on endpoint management, but all ideas are welcome I guess.

I'll be trying things out with FastAPI and Jinja templating

NestJS with Handlebars templates. I don’t love Handlebars but I have past experience with it so was the most pragmatic choice.

I’m interested in trying EdgeJS as a templating alternative to HB but haven’t got round to it yet.

I’ve added a NestJS error handler that looks to see if the request came from an htmx request and then serve the error response as html, if not then it sends back json since I do have json api end points as well in the back end.

Go: go templates and fiber for http serving. I have a mini framework for adding some structure to the templates (folder per feature: contains controller, templates, etc, and some naming conventions)

This is my stack as well and it works great.

I too use go + fiber + htmx.

> mini framework for adding some structure to the templates

Would be good to read little more about this mini-framework

My backend for a simple web application I'm working on is entirely in Rust. Highlights:

- axum: web application framework - https://github.com/tokio-rs/axum

- axum-htmx: axum extractors, responders, guards for htmx - https://github.com/robertwayne/axum-htmx

- rusqlite: SQLite bindings - https://github.com/rusqlite/rusqlite

- maud: HTML templating as a macro - https://maud.lambda.xyz

The way maud lets you compose markup works very nicely with htmx. The HX-Request header lets you know if the request is coming from htmx or if it is a regular request. You either call the top-level function if it's a regular request to get the entire page rendered, or call a subset of functions to get the appropriate partial rendered if it's an htmx request.

It's also nice to easily have tests for the rendered pages. My unit tests cover verification of the rendered HTML, too.

Do you use something like cargo-watch for "hot reload"?

No, I just stop and restart when I feel like I'm in a good spot. Nothing fancy.

rust and ryde (my own framework on top of axum and rusqlite)

Flask+SQLite+TailwindCSS.

It's basically cheating. The setup is dead-simple to operate.

What do you use for templating/HTML generation?

The default Flask Jinja2 templating engine. It can get you very far.

True, it works just fine. But doing non trivial things in a templating language never quite sat well with me. So I am trying out dominate as a way of just doing everything in Python. Jury is still out though.

Well, as I expected, templating is the hardest part of migrating to htmx on nodejs.

After reviewing few templaters/etc (handlebars, ejs, lit-html, virtual-dom) and few abstractions (html``, just ``, h()), barely anything seems too easy and too freedom-y. Arcane syntaxes, high character noise (ejs, lit, js), lack of typing (all non-`` based), trivial screw ups (virtual-dom, handlebars), experimental status (lit ssr). Sigh.

This was my experience as well. No great template generator on the node side.

I use PUG. I don’t like to close HTML tags. This cuts 30% of the visual bloat out of my templates.

removingspacesgotridofalotofmybloatonregulartexttoo.

One man's structure is another man's "bloat", I guess.

PUG actually adds spaces: it's indentation based.

What it removes is the visual bloat of closing html tags.

So instead of:

    <div id='foo' class='bar baz'>
         <p>Some content</p>
    </div>
    <div id='foo2' class='bar2 baz2'>
         <p>More content</p>
         <p>Another paragraph</p>
    </div>

In PUG you do:

    #foo.bar.baz
        p Some content
    #foo2.bar2.baz2
        p More content
        p Another Paragraph

Even without syntax highlighting, it's plain at a glance where markup stops and content starts in PUG.

And it's easier to visually parse element IDs and chained classes this way too.

Go with fasttemplate.

Most people prefer templ but I don't like logic in templates, I just want to parse values. I keep different states in different template files.

Each template file is a portion of a full page which makes it easy to create an endpoint that pulls the partial with the latest values. HTMX can then hit that endpoint to load or refresh values.

Endpoints are usually

    domain/page/partial

so if I'm on a configuration page at

    example.com/config

then the endpoint for the privacy settings partial would be

    example.com/config/privacy

Going directly there in a browser would get a 404 because I check for the HX-Request header.

Endpoint handlers return a processed template with the current state. I use those functions to both compose the full page on the backend, and to build the output for the partial endpoint.

I don't automatically expose all partials. I add endpoints as I need them. This is probably more idiomatically Go than anything to do with htmx.

Django user here. HTMX fits in perfectly with the Django templating system. A fairly common approach is to use the same view but check for the HTMX header and then return a template file with the specific bit of HTML being swapped. There's also work in the Django space to be able to return parts of a template based on the request, which will suit HTMX perfectly too.

We use Django with https://htpy.dev/ as templating system.

Htmx + Kotlin with ktor and the html dsl was really fun to play with on a personal project. Static typing, autocomplete and a full-fledged programming language available to use in your html markup is a game changer. I was structuring my endpoints as pairs of "data" and "render", where the render endpoint just reused the function for the date endpoint.

Go + Templ + htmx

Templ is great when you need to separate reusable components.

I usually use Clojure, Huff for html templating, and whatever DB libs. Pretty much whatever is in Biff[1] is what I want to use.

[1] https://biffweb.com/

perl + Template Toolkit (using the underdocumented support for the fragment pattern with EXPOSE_BLOCKS), before finding htmx we used Jemplate, which let you compile Template Toolkit templates into Javascript functions

My hot take: We initially used this library to allow us to iterate faster. But its is a pain once you reach a certain point, where it doesn't make sense to have this type of logic in HTML. I especially don't like how this library does error handling. I feel like this is the new jQuery. There is better way to represent interaction logic with open JS standards like Web Components.

I just want to take advantage of this news to say: I love HTMX so much! :D It makes web development fun again. I can still use all the fancy js libs I want -- but my main logic lives on the server, using plain HTTP and HTML. Really clear and simple.

Love the upgrade music. Wish more libraries would add upgrade music with major releases

I looked around but I can’t find the upgrade music you are referencing.

bottom of this page: https://htmx.org/migration-guide-htmx-1/

Has anyone here used htmx for embedded devices? That is to provide web UI served by the device, for configuration / data access / control? Can you share the experience and if you would use it again?

i havent used htmx yet, but it sounds like a breath of fresh air. no npm library with 1000 dependencies with slow build times. just plain simple js library like the good old days ^_^

React's had such dominance for the last 10 years. I'm glad there's an alternative.

Vue? Svelte? Preact? Solid? Even Angular is much saner than React. Nobody needs to use React. Never had to. HTMX is no alternative for highly interactive web apps, btw.

HTMX + static site generators is DOPE. If we had just these two things back in the 90's...

I'm probably totally ignorant, but how would htmx work with a static site generator? Isn't the whole point of htmx that it extends the front end to dynamically interact with the server and get responses to inject?

On a documentation site, photo gallery, etc, it is very reasonable to use something like htmx to implement navigation without triggering full page loads.

You could have static elements pre-rendered, but only loaded on demand. For example, if you had a blog with comments, you could have the comments pre rendered in htmx fragments, but only loaded when they are clicked.

Or a photo gallery with thumbnails that are enlarged when clicked.

At least, that’s one way it could work.

I used it on a couple of static sites. Sometimes you just want that "SPA" navigation without a full page reload but you dont need a full JS framework

we did... almost in the 90s.

one example which I distinctively remember using before AJAX was a word: https://github.com/twisted/nevow/blob/master/nevow/stan.py

Anybody know if there’s something like HTMX that plugs into Turbo? Every time I start using a stimulus controller, I have the thought that it should be more like HTMX instead.

Well done

https://extensions.htmx.org/ Has a big where the “no-load” extension is listed twice

as htmx CEO I approve this message

It has already been pirated by various groups and made available for download assuming you have the bandwidth. Unbelievable. Big Sky has to make money somewhere.

unfair!

htmx works great with dotnet btw (wrote a series on that)

Sounds very interesting! Do you have a link by any chance?

Not OP (and late to the game), but searching his handle led me to https://xakpc.info/series/htmx-dotnet

I knew about Htmx and that HN loves it. But this post is what I actually got to take a good look, and oh my god it felt like such a fresh breath!

We have a few jQuery-era websites (that still work today because why not), and Htmx could be where we trim hundreds of lines.

Reply on news.ycombinator.com