Hacker News Reader

Comment by chatmasta | Hacker News Reader

I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well have setup a JS bundler in the first place, and yet the debugging, testing and deploying challenges will continue to push you into less-trodden territory.

I believe there might be a sweet spot for small projects unlikely to grow in complexity, maintained by a Python dev who is allergic to JS. But I don't see why you would want to invite yet another abstraction into the web stack, when it's built on top of the very language you're trying to avoid, and which you'll inevitably encounter in all its automagically obfuscated glory as soon as you run into a moderately complex problem.

View on HN

I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving and it has burned so many people over the years that folks just don’t want to deal with it.

I’m fine learning JS, but with the ecosystem it isn’t just learning JS. It’s learning the new hotness for packaging / versioning, it’s the frameworks that are constantly in flux, it’s the inconsistent abstractions that seem to be mercurial and constantly changing.

If we were to sit down and write some frontend code to say, make a simple kanban board every 9 months using “current” JS best practices or popular frameworks over the last 6 years…

How many different tools might you run across?

How easy would it be to take that 6 year old code and bring it up to modern standards?

The reason you see people allergic to the JS ecosystem is because it is incredibly opinionated while simultaneously being a free for all.

The "new hotness" only matters if you're going to try and get a job as a FE dev in a large team. The "old hotness" still works, and likely has the more obscure bugs worked out of it.

And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about how you write your JS, you may not need a framework (you'll end up creating your own, probably).

I'm with you that the JS ecosystem is a seething mess, but I don't think that's actually a problem unless you want a job as a FE dev. You can just ignore it ;)

I usually oppose the use of any new "hotness" in a project until that "hotness" is ~10 years old.

This.

90% of the toolchain is not required at all. Just quality of life improvements.

Good ES6 (and TS) idiomatic code feels actually closer to reading Scala than reading a legacy Jquery app.

And the V8 engine has so much investment in optimizations today that is actually closer to Java and in some cases lighter than Go.

IMHO people don't hate JS in reality. They hate the strawman made of the worst parts of Junior code ever encountered and inconsistencies that really don't happen in practice unless you actively look for them.

Same could be said for php…

htmx is another tool just like that, another goalpost in the frontend webdev world. It's just happens that the most recent hype is "don't write JS", but fundamnetally it's no different. Just another framework/library that has gotten some traction. In a few years we'll be back full cycle and it will be in vogue to write JS again, probably because htmx and associated projects have grown to complex.

A key difference is the promise to be working even without JavaScript.

"Htmx is a dependency-free, browser-oriented javascript library."

https://htmx.org/docs/#installing

The framework itself is written in Javascript

The end user is NOT writing Javascript.

It's no different from anything else. The promise if every framework is to abstract away some low-level details. Whether that means writing "higher-level JS" like jQuery did many years ago already, and hundreds of other frameworks do today, or inventing some new DSL like htmx does that translated to JS internally. No difference.

I’m pretty sure you can continue to use jquery and everything still works fine :D

I’m over here continuing to use react for 9+ years but every post on here acts like it’s changing every day.

Classes? Components as functions? Classes again? Hooks?

Classes still work fine if you want to keep using them.

This doesn't appear to be what the docs recommend anymore, which is exactly what my (obviously flippant) post was meant to highlight.

Hooks were introduced five years ago and have been stable since then. So that's half a decade with no changes to the API.

Great! I bailed in the first four years I guess, after the fourth change in API.

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

As a Vue user things have changed a lot.

What I hate is that you don't even write JavaScript anymore.

You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time you change a file.

There's actually no need for that anymore. JavaScript as is supported right now in the latest Chrome, Firefox and Safari is already pretty good. You can get quite far without any backend tooling these days.

The only thing which I believe is still needed is a bundler when your project grows to a certain size. Fetching a complex graph of thousands of files will likely never be fast.

Do you still use gulp or is it webpack nowadays?

It's JavaScript. Everyone is moving on to Turbopack. Or Vite. Or ESBuild. Or Bun.

I definitely like the batteries included and speed of bun.

Please don't tempt me.

You're outdated. Everyone is using Parcel now.

Funny, how even the sibling comment states something different. Maybe there are a lot of bundler bubbles in the JS world?

sorry, I said that 9 hours ago... now we're using Bun actually :D

Gulp is extremely out of date these days.

Using webpack resulted in some of the most painful experiences of supporting serious production software in my career.

The progress and maturity of JS tooling/DX as a result of stuff like esbuild and Vite, or Typescript more generally, can not he understated.

For people not doing frontend it can seem like a neverending series of new stuff but there is a very rational and tangible level of progress being made. Especially for serious JS devs not jumping on hype trains.

I don't miss the days of gulp and webpack at all and I don't blame anyone for hating on JS if they experienced using them professionally.

Gulp / Babel and then transition to webpack was my introduction to JS.

Now Vite seems to be all the rage? But is it a bundler?

Wepack seems to be very hard to configure. Looks like nginx config vs caddy config.

Tools such as babel, webpack, esbuild, postcss, etc. are now considered a bit low-level, and usually do not need to be set up manually these days.

Rather, one would opt for something like vite, the spiritual successor to react-scripts, that bundles all of these tools together with some good defaults/plugins, a means to configure them, and usually also some kind of dev server with hot module reloading, for a complete developer experience using your preferred toolchain.

Check out 'parcel' for something pretty modern, universal, and low effort, IMHO.

> Using webpack resulted in some of the most painful experiences of supporting serious production software in my career.

I never invested too much time in understanding webpack but it does feel like fighting it a lot of the time when I want to change something in my personal projects.

Care to share some anecdotes of those painful experiences?

Even bundlers can be pretty stupid and simple. I still just use r.js for even large apps. Webpack isn't hard to set up, either. But my frontend code has almost no dependencies... I refuse to deal with React, Angular, etc etc. I have a very nice, simple component-building / screen scaffolding system that's about 1000 LOC. You extend the component and load up some HTML and just work with it directly in JS when you want to update data, resize it, etc. There's no need for all these frameworks that try to plant logic back into HTML. I love having the HTML templates pure and the logic unbound from them.

> The only thing which I believe is still needed is a bundler

And a type system... And maybe a styling system... Oh and let's have some nice Rx data flows!

But, jokes aside, even if you go that Route you still end up with a complex npm project that involves dozens of libraries.

I've been at that point every year since starting doing npm spas in 2014ish (mostly as side projects, my work is typically more serverside). At some point I just decided that the upkeep wasn't worth it any more as you create the same stack every year but with wildly different libs. For me the solution was to switch to an elm+sass+webpack boilerplate that hasn't changed since 2018 or there abouts.

Out of curiosity, what features are you using that aren't already supported by all major browsers?

Maybe the tail-call optimization?

With evergreen browsers, you can write modern JavaScript and it'll run in the browser just fine. And it's not like TC39 is pumping out lots of wild changes. The largest recent change is what, top level await? That's not exactly a wildly different language feature.

A lot of this JavaScript criticism was appropriate circa 2017, but these days JavaScript's gotten a lot more stable.

Sure. With evergreen browsers. For anyone using old devices with outdated hardware--tough luck! They can, I guess, go buzz off and leave you in peace to write Modern JS. After all, that's the most important thing.

At this point you'd need a 10 year old never-updated browser to run into this issue. Which, sure, maybe you need to cater to people who use browsers 10 years out of date. I don't think it's a huge market frankly and 10 year old browsers have larger issues like security.

I mean, JavaScript doesn't just run in browsers. Some older forms of JavaScript run in all kinds of software--embedded in Windows (JScript), embedded JavaScript engines in other runtimes (Java, Qt Quick), older Node.js software that people are stuck on for whatever reason. I'm sure many people don't care about making all of those devices obsolete but maybe with a slight amount of effort we can try to slow down the inevitable filling of landmines with perfectly workable devices?

Okay, those cases seem like situations where you'd need to be explicitly targeting those devices. Like if you're shipping new code to users that is being run on an old runtime, then sure, you should make sure that code is legacy JS. I don't see how that is unreasonable?

This is my problem with a lot of HN comments about JS: they read like they were written in 2014 (see also the “a new framework every week!” jokes)

ES2015 was the one big language update, and although it took a while to all roll out and for older browsers to die off, at this point we’re now living in “the future” and almost all language changes are incremental.

Like, you can write ES modules with async/await and run it in all modern browsers without any compilation. If you add an HTML import-map element you can even import node_modules by name.

Now, most people still prefer to use a bundler so that their users can load a single script instead of dozens of tiny ones, but that’s optional, and the gap between “the code you write” and “code that runs in the browser” hasn’t been this small in years.

Part of it could be different audiences.

Not everyone is on a greenfield project with full authority to grab the freshest and latest. Some of us are effectively living in 2014-- they can't say "no, you can't use IE11" to paying customers, or committed to a platform at the wrong phase of maturity, and remain stuck around a state-of-the-art-in-2014 build process.

I think this comment is a bit out of date, especially if you’ve been watching JS from a distance for the past couple decades. This would’ve been true circa 2014. In 2023 it’s obsolete.

There’s one framework that won, that’s all you have to learn, as far as the industry goes (as opposed to hobbyists) it’s been decided. React won. React is the framework you learn.

“Popular frameworks for the past 6 years” - React has been dominant over that entire time period, from beginning to end. React is what you would’ve reached for 6 years ago (it was already mature then, in 2017) and it’s what you’d turn to now. This is what I mean. You could update your React code to use hooks instead of classes - or you could not, it will continue to work if you don’t.

The “JS changes all the time” take is frankly out of date in 2023. “Which framework do I learn…” you learn React, the framework that won. It’s pretty much that simple.

That’s a bubble. You are in a bubble. React is dominant, sure, like the US is dominant, but it’s not The World.

The important part is that it's a bubble you can choose to live in. Companies everywhere use React and almost no one need ever choose to learn something else. As long as you know it you will be employable for another 20 years, just like with Java.

But people in that bubble keep shaming people who aren’t… and react keeps changing, so it’s not like you learn it once, it requires careful study and understanding of all the different permutations that are used in different environments.

You generally can’t go from company A to company B who both use react and have the same calling convention, code structure or tool chains even though they are both using react.

Ouch, 20 years? I sincerely hope so for their sake, but I wouldn’t bet 10 dollars on it.

20 years is very optimistic; React is already losing users: https://2022.stateofjs.com/en-US/libraries/front-end-framewo...

Retention shows a clear trend for all frameworks and even in general conversation Solid.js has been taking up more and more of peoples' attention with signals.

The compound advertisement of hearing about Svelte and why it's always going to be faster than React because of not having a VDOM along with Solid.js will make a dent in React and it will become the next Angular. 20 years is not going to happen.

> React won. React is the framework you learn

So nobody should learn AngularJS any more?

Nope.

I don't use React.

Only VanillaJS.

And my clients are happy it seems.

So React clearly isn't the only choice, unless you're a new graduate with no clue about anything, then sure start with React.

Hard disagree… react is probably one of the best examples of this. React 15/16/17/18 over this period of time is a nightmare to maintain for people who don’t keep up with react if they want to casually jump in or out of.

If you built an app in react 16 and wanted to upgrade to 18, using the documentation it almost resembles 2 different frameworks. Sure, maybe the code executes, but all the js devs would be like “why did you write it like that”?

This is a great post. I'm not a web dev myself, but I have a couple on my team. I criminally underrated the challenge of maintaining a complex web app. It is madness: endless incompatible, forced upgrades.

Real Question: Why does this ecosystem have this issue, but others have it less? For example: Why doesn't Python or Java have the same madness?

Please don't read the question as criticizing web dev / JavaScript / etc. My curiosity is genuine.

To be fair, it does feel like C++ is more maddening than Python or Java, but part of can be explained by (1) native code generation (build is way harder than languages that run in a VM) and (2) the insane complexity of the language which _traditionally_ made IDEs much weaker than other languages. MSFT Visual Studio and JetBrains CLion have come a long way. (I can already feel the HN pitchforks poking at me for these C++ comments!)

Because the originals parts where broken. I am speaking of 90s JavaScript, the DOM/Browser API and the not so much "batteries included". They could neither get fixed without a standard by committee approach of the browser vendors.

So we started to compensate: end state: Typescript to fix JS, React/Angular/Svelte to fix DOM API and a npm package hell to have batteries included. And all of that bundles, compressed, etc to have a good download time.

Yes. When JavaScript is your only option, the only solution to JavaScript is... more JavaScript :(

Seems like the old joke about XML:

"XML is like violence: if it doesn't solve your problem, you're not using enough of it."

> I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving

Welcome to real life.

Beware the ecosystem that does not change (COBOL).

Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance. It's totally fine if you're not personally down with HTMX!

However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic? These are literally the antithesis of HTML.

Perhaps the real reason we're happy is that we're experiencing a huge productivity increase, lower cognitive load, fewer difficult bugs, terrific performance, and a great dev experience.

Here's some code that I don't find especially idiomatic:

    <form hx-post="/test">
        <input _="on htmx:validation:validate
                    if my.value != 'foo'
                        call me.setCustomValidity('Please enter the value foo')
                    else
                        call me.setCustomValidity('')"
            name="example"
        >
    </form>

It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language.

https://htmx.org/docs/#validation-example

Programming languages contain English words like if, self, else, then, function, def, this, exception…

Me/my is rarer: Reminds me of VB

it's a separate project, hyperscript:

https://hyperscript.org

it's based on HyperTalk, the scripting language of HyperCard:

https://hypercard.org/

with some Web-specific syntax thrown in to make things cleaner:

  add .visible to <section.fade-in/>

I would likely agree, however this example makes heavy use of hyperscript, which is an associated project by the same author, but is distinct from HTMX.

How do you do validation with custom error messages without it? It seems pretty table stakes for forms to me.

Where are the docs that make it easy to avoid hyperscript, if it's usable without hyperscript? This has hyperscript sprinkled in: https://htmx.org/docs/

HTML already has a native validation API for form elements. https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va... HTMX wraps that with some custom events and enables you to use the same API for non-form elements.

In the example above, if you need custom validation logic, you could handle the HTMX:validation:validate event with any normal JS event handler.

Of course, it's up to you to decide how much effort to put into client-side validation that can be easily bypassed.

Mostly, you validate on the server and send html with error messages back.

If you really need client-side, yes, of course you have to script it. If hyperscript is not to your taste, you use a bit of js.

That was implicit in my question. We aren't talking about writing purely server side web apps here, and it's reasonable to expect something like client side validation, given that this is meant to be an easy way to do full stack web apps. I think it is but not really easier than other major ones.

> We aren't talking about writing purely server side web apps here

Ok, but note that a big part part of the appeal of htmx is that yes, you work mostly server-side. If your use case absolutely needs client side code, htmx might not be the right fit. (But in many cases you don't need as much client-side Code as you might think at first.)

the code here is hyperscript, not htmx:

https://hyperscript.org

i use hyperscript because I created it and like it, but the example could just as easily use JavaScript, the point is to show that htmx respects custom validations

The docs don't seem to suggest using it for non-trivial things without hyperscript. https://htmx.org/docs/

They do suggest being able to use it without learning a lot of hyperscript, but I see the same with Svelte, where you can get by on copying and pasting a great deal. https://learn.svelte.dev/

most of the examples don't have any hyperscript in them

htmx generalizes HTML as a hypermedia, making any element a hypermedia control that can issue any type of HTTP request in response to any event and target any element in the DOM for replacement

that's the concept, improve HTML, and it gives you quite a bit more than plain HTML, but it is intentionally constrained to not go beyond that

for things beyond what that gives you, I am not afraid to recommend scripting: Fielding explicitly included scripting as an optional constraint his description of the REST-ful architecture of the web

A good example of how we like to see scripting used w/ a hypermedia system is the Sortable.js demo, which shows htmx integrating w/ Sortable.js via events, the cleanest way to integrate hypermedia controls w/ client side scripting:

https://htmx.org/examples/sortable/

we have a chapter on client-side scripting in hypermedia systems here:

https://hypermedia.systems/book/client-side-scripting/

> for things beyond what that gives you, I am not afraid to recommend scripting

I'm not suggesting that you don't. I'm suggesting that it's quite similar to SvelteKit, Remix, and now Next.js, and other form-friendly frameworks in what you'd need to know in order to do a non-trivial full stack JavaScript project that supports progressive enhancement.

The difference is that with HTMX you're not stuck in "full stack JavaScript" land. Any language that can generate HTML becomes a viable full stack option without the headaches of modern JS tools being forced into the mix.

Good luck having editor support, linting, formatting, intellisense or anything at all here. This is a f*ng nightmare.

Non native speaker here.

The unfamiliar programming language (which I've never used) seems to be binding some code to some type of validation event. "my" and "me" seem to refer to the input tag. "my.value" probably refers to the value of the input. If it's not foo it calls a setCustomValidity method with the input tag as the caller. Could be some built in method that you can call on any input tag or anything validatable.

Ok I just checked the link and setCustomValidity is part of the HTML5 Validation API (haven't worked on web dev in years).

I can assure you that the first person pronoun is among the first things we learn when studying English and assuming the code snippet does what I assume it does I'd say it's pretty intuitive to learn. Especially if we are comparing it to JS where "this" is not what you'd expect from using it in other languages, but the late-bound called of the function... except in all the cases where it isn't.

In any case, trying to guess how a programming language works is a very bad idea so it doesn't matter how obvious the language manages to be, you still should read the documentation.

Why do I continue to see people imply that React is the only way of writing frontend web applications with JavaScript? There are plenty of alternatives to React that I would say are far more "idiomatic". I highly recommend taking a look at Vue 3 or Svelte to get a better idea of what frontend JavaScript can be.

React isn't the only way, of course, but it's likely the most popular. Why do you consider Vue or Svelte to be valid alternatives but not HTMX, despite plenty of people endorsing it and openly proclaiming how successful it's been in their projects?

I personally do consider HTMX to be a valid alternative to React, but I also think that a lot of usage / promotion of it comes from people who are misinformed and think that the entirety of the JavaScript ecosystem is React. I consistently see a lot of people use HTMX over React alternatives purely because of a "distaste for JavaScript" or an understanding that everything is or has to be as complex as React unless you're using HTMX.

If people are "misinformed", that's a marketing fail by those other frameworks, despite many years of headstart. How are people even finding HTMX (with a single developer and until very recently, no corporate support) in a marketplace which includes Angular, backed by Google?

Or maybe people are kinda informed, and simply drawn to HTMX because it's easier to learn than Vue, Svelte, Mithril, Cycle, whatever (or they just don't want to try a zillion frameworks) and it works really well and developers seem to love it and recommend it a lot?

> or they just don't want to try a zillion frameworks

But isn't HTMX one of said zillion frameworks? What makes it any different?

It's easy? It works? It feels like HTML? No build steps? No JSON? The primary documentation fits in a single page? Most common patterns (i.e. polling, and then stopping if necessary) are built-in? Because fundamentally, it's just standard HTML forms? The entire dev experience is focused on a single application (backend) as opposed to writing a backend and a seemingly separate frontend project, in a different language (unless you use JS on the backend)? Simply replacing HTML fragments is conceptually simpler than maintaining a shadow DOM? It embraces web standards/APIs (see client validation discussion above)?

Here's polling in Svelte: https://stackoverflow.com/questions/61391174/how-to-do-polli...

and in HTMX:

  hx-trigger="every 2s"

https://htmx.org/docs/#polling

Maybe Svelte has an easier way, but Google isn't directing me straight to it, which is all part of the "easy to learn" aspect.

> Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance

Sure you have: literally any frontend framework post, from React and Vue to roll-up, webpack, and everything in between. Tons of non-FE engineers or engineers that work on small and trivial apps will flood in to say why the lib in question, and usually the entire FE ecosystem, are crazy, rapidly changing, undecipherable, etc.

Is it really easier? Yes.

The project I’m currently building is an enterprise b2b SaaS and I’ve gotten it fully functional without writing a single line of JavaScript. By functional I mean it looks and behaves like there is JavaScript, because there is with HTMX, but it’s abstracted away to the point of taking none of my time, which is what matters.

There’s no way I could learn the JavaScript ecosystem in a day. Maybe I could get something functional in a day but the technical debt would be too costly. I’m not sure any human could learn it in a day with acceptable technical debt trade offs.

For my situation of an enterprise app that’s mostly declaring resources in the backend via API, it’s been much faster to write in my preferred backend language only. I build the API, make a command line tool in the same language that calls the API, then add a basic HTML form for the demo and it’s great.

I think what you're saying demonstrably doesn't apply to the majority of developers. You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte

However you would just be able to do what you can do with SvelteKit (Parts 3 and 4). Not too different from what you can do with HTMX.

You would need to deploy SvelteKit but could have SvelteKit call your backend API for all of the heavy lifting and its deployment requirements would be minimal.

Yes, a bigger chunk of the JavaScript ecosystem takes longer to learn, but you can also do more with it. If you make an apples to apples comparison I think they're effectively in the same ballpark, and JavaScript is better just by having more resources.

> You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte

I think if you are, like me, someone who for various reasons never followed the JavaScript ecosystem for various reasons over the last few years (in my case because I was working on exclusively backend APIs in C#), coming back into trying to do any frontend website is just ten thousand people saying "it's not that hard, just follow something like this: x", where 'x' is any one of forfty hundred humungous different frameworks.

If you don't want to have to learn a whole new ecosystem but just want to bang out something that can take advantage of a bunch of modern-ish nice front end paradigms like being able to selectively update individual components without having to do a full page reload then htmx feels like it would hit the spot for a lot of different use cases.

(I say this having only read the site several times, usually when it pops up here in some context, and I always think "oh damn yeh that thing exists, I have to give it a go at some point!" but never actually have yet)

I doubt it – I haven't seen any indication of HTMX being a silver bullet.

Here's your list of examples: https://htmx.org/examples/

Here's validation: https://htmx.org/docs/#validation-example

It looks kinda like ruby.

I'd argue that neither is any particular JS framework a silver bullet. If HTMX works for their use cases without needing to write any JS then more power to them!

It is explicitly NOT a silver bullet

https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...

I'd like to point out that if you require offline functionality in one project that it likely isn't a good fit for your other project that doesn't require offline functionality. We all have finite time and it's great to learn something once and be able to use it multiple times.

Offline functionality naturally requires client-side code to handle storage, caching, synchronization etc, so client oriented frameworks are preferable in those scenarios. However, this comes at the cost of additional complexity, and I argue that this complexity may be unnecessary and htmx may help you achieve your goals easier

You said it yourself:

> We all have finite time and it's great to learn something once and be able to use it multiple times.

We all have finite time and it's great to use tools that help us work efficiently, following the strengths of those tools, instead of having to maintain unnecessarily complex solutions

htmx is yet another one of those forty hundred humongous different frameworks.

It also uses a DSL that has no application outside of its specific corner.

It also forces you to return HTML fragments via AJAX.

By the way I did use intercooler.js (prev. iteration of htmx) intensively and while I liked it at first, it really added up to being an HTML/JS soup when other developers started extending.

> humongous

14kb

> It also forces you to return HTML fragments via AJAX.

not true, you can return anything. support client-side templating for JSON etc

Is any of this available or would you be willing to share or discuss? I’ve done some HTMX/_hyperscript for prototypes and hobby projects and loved it; contributed a few of the cookbook examples. Overall it is a pleasant ecosystem. I’m curious how this worked out in your use-case because I’m considering it myself. What are the hurdles? Any lessons learned? Recommendations?

Software developers, especially DOM fearing front developers love using the word easy. It isn’t so much an infatuation but more like a fatal attraction obsession where obstruction means war on a very emotional level. Ironically, people are loathe to confront these feelings openly and thus cannot define the word easy with any kind of clear practical application.

So, I did the world a favor and wrote just such a definition: https://github.com/prettydiff/wisdom/blob/master/Easiness.md...

For a certain kind of application HTMX is a convenient way to work. It lets you write a webapp the way you did in 1999 except you can update pages partially. Here is a screenshot of an my HTMX-powered RSS reader

https://mastodon.social/@UP8/110432673973724419

This is a research project, but it's a research project by an applications programmer so it has to be solid. Yet I have to be able to change anything when I want to do it and if I used the "standard model" I'd have to change both the back end and the front end when adding a new task but this way I can add a new form once and add it to the rotation, pop it up in a modal, split it out on another page, etc. If this was a big production system with lots of people tagging things I could roll out new tasks by rolling out new forms and not force reloading of a front end.

I use it together with other client-side Javascript, for instance with D3.js for highly customized charts and visualizations.

A major time saver is that it skips the Javascript build. When I make I change I reboot a Python server and it comes up in 1.6s.

You don't have to build JavaScript; it runs natively in the browser. In fact, the only time when you would have to consider a dedicated build step is if you were using something like TypeScript, or if you wish to use external modules. In the case of external modules, check out ES6's import syntax. You can import from a URL just like it's an NPM module. I believe a few CDNs are designed to facilitate this use-case too.

That's how I use D3.js. But for the React programs I work on at work we are already committed to a build process, there are bits of Typescript, SCSS, and for production at least tree-shaking and minimization seem a most for something with that many moving parts.

SCSS? Never used it myself -- normally CSS in JS. I definitely understand that it's hard to move away from big build processes though.

Hey! I'm also building an HTMX-powered RSS reader, although it's more a side project than a research project. Good luck, it's been lots of fun for me so far!

I've also found the productivity of a "strong" decoupling from frontend and backend to be super satisfying.

One architectural advantage is this.

Suppose you want to add a ‘plug-in’ such as a new social media share button: often this is going to involve front and back end changes. In my RSS reader this could be a python package with declared entry points so the application could read it, enabling a few more http endpoints and also adding templates to extension points.

In a ‘standard model’ application you need to have an npm package and a Python package and corresponding extension mechanisms on both sides. You can probably make a system that wraps an npm package inside a Python package or maybe the other way around but it will be a struggle.

(The architecture of my current system was inspired by a system I worked in that not only used Scala, Typescript and Python but also Docker such that builds took 20 minutes! They could afford to do that on a venture capitalist’s dime but I can’t.)

I've used htmx to write some relatively simple internal tools, and it's been really useful for that. I know a little javascript, but my web skills are really outdated - I acquired them back when you rendered HTML on the server and maybe added a little interactivity with jquery. With that background, using htmx to swap out elements (rendered server-side with Jinja templates in flask) has been a lot more productive for me than trying to overcome my unfamiliarity with modern JS. The modular structure of Jinja templates actually works really well the htmx paradigm IMO.

This is exactly what I use it for. It keeps me working mostly in python, flask, and jinja, which I know a lot better than js. For just doing some background requests and element swapping, it’s absolutely more efficient for me.

I view it more as server-side first modern app development. If you have a Django app for example htmx is a fast and easy way to make it feel fluid and dynamic like a modern SPA, but still using all your server generated Django logic, templating, etc.

I seriously doubt many people decide they prefer coding up logic in attributes. It's just what HTML gives you as an extension point.

htmx removes abstractions from your web project, by extending the existing abstraction of hypermedia to the point that it can implement many common UI patterns without any other concepts:

https://htmx.org/examples

i have a free book available on the hypermedia approach and how it contrasts with the SPA/thick client approach (both its strengths and weaknesses) here:

https://hypermedia.systems

I think you could expand your definition of small projects somewhat.

I used to work at a marketing agency many years ago, there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email.

Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking reservations, some mom and pop store's contact form, or a local newspaper's letter to the editor form.

HTMX supports that flow with a couple of HTML attributes. Barely anymore "code" than authoring and styling the actual form.

To be fair, a callback and fetch() call aren't much harder but provides just enough complexity to make shooting yourself in the foot easy when you bill hourly on a $200 budget.

> there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email.

You don’t need JavaScript or htmx for this. It’s been in the html standard since 1.0. Forms work from plain vanilla html.

> Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking reservations, some mom and pop store's contact form, or a local newspaper's letter to the editor form.

All of these things can be done without htmx or JavaScript. It’s just forms.

(You “need” htmx or JavaScript if you need to dispatch a request without actually submitting the form and triggering a new page load, for example to autocomplete an email or get search suggestions. None of your examples need that.)

This response is an excellent example of how, when stating a case or making an argument on HN, you should provide as little concrete information as possible and avoid a specific example if possible.

The point they were making was that for many small single-purpose sites the interactivity needs are low but for various technical or social reasons may be higher than exposed with pure html/css, and htmx meets those needs adequately without adding much additional complexity.

But they used forms as an example, and now you're deep in the nitpicky weeds about the semantics and capabilities of html forms, having missed the point and left it in a ditch miles ago.

Not really, I was directly refuting their bigger point, which was that htmx is not in an uncanny valley between basic HTML and real Javascript because there are all kinds of simple use cases where htmx is ideal. They then listed off use cases that in fact do not require htmx :-)

If you're going to make a point like that via examples, they should be (in aggregate) useful examples that make your point!

Even setting aside that examples made up basically that poster's entire point, the reason people provide examples even for more developed argumernts is because concrete evidence is important to persuasiveness (not because they are being charitable). When someone tries multiple examples and none prove their point, it's perfectly valid to point that out.

How do you make a request to a URL and then turn the response into HTML without JavaScript?

By submitting the form with a post request and then load an entire page with a thank you message or the form again with validation errors. Like it’s 1999.

It's not that I avoid JavaScript, it's that I want my work to be accessible to someone without JS as a requirement, for whatever reason they may be in that state and configuration, whether by choice or not.

I write plenty of JS (12% of my biggest project, according to GitHub), but it's added onto HTML in such a way that the HTML still works for:

* a security-minded person who has it turned off in their browser,

* a user of a browser without JS support, such as Links, Lynx, w3m, Dillo,

* someone with an older device using NoScript for performance reasons,

* someone with a slow network connection who can't load the included library,

* a server operator who chooses to disable JS rendering/injection and serve plan HTML, such as the website for a Bitcoin conference,

* another scenario I haven't even thought of or imagined yet.

My conscience as a developer and enabler of information access just does not allow me to write off all these people as undeserving of accessing my websites. You may feel differently, and I think that is OK, too...

I get what you're saying but I the context of the discussion, Htmx requires JavaScript, doesn't it?

Every site I build works with JavaScript disabled. I use Next.js with server side rendering so that the initial page load is an accessible HTML document that is progressively enhanced for those with JS enabled during hydration by adding interactivity and smooth client side page transitions without full page reloads.

None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX is to import a JavaScript file from a CDN, and none of the features for partial page replacement will work without it. Whereas with Next.js, with JavaScript disabled, a Link will revert to a full page load where the next page is rendered on the server. It will be progressively enhanced to what appears to be a partial page load by using the same JavaScript that would render the full page on the server to instead render it on the client starting from the current state of the DOM.

> None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX is to import a JavaScript file from a CDN, and none of the features for partial page replacement will work without it.

Umm, progressive enhancement is a general concept that can be applied to any stack, not just Next.js. With htmx we can just use good old anchor and form tags to fall back to full-page loads if JavaScript is disabled. In fact it makes it more obvious because usually those are the tags we're using even with htmx and JavaScript enabled.

How do you do that if your backend is setup to respond to requests with partial content? You now need to make sure your backend can render both the full page and also individual components of it. That's not functionality that's provided by HTMX itself.

It's fairly easy. Htmx sends an `HX-Request: true` header with all requests. You can check for the presence of this header and have an if/else in your handler to render a partial or a full page. Or if you want to enable caching you can configure the `Accept` header with a customized content type like `text/html;hx=1`. That way you can set a response header `Vary: Accept` to ensure that caching is correct.

The community is convinced that their form of HTML attribute salad is hypermedia and others, that look better IMO, are not. That explains some of the excitement over it.

They have a tiny bit of a point, in that the forms are able to work without client-side JavaScript* thanks to progressive enhancement, and only Svelte and maybe Remix and a handful of others do that. Svelte does a better job of explaining it and making it customizable IMHO though. https://learn.svelte.dev/tutorial/progressive-enhancement

Though Svelte has this, I think perhaps most Svelte devs prefer JSON to form data, because it's directly nestable. That in general is good for full-stack development. You don't see very much TOML in the framework written by the author of TOML, but you do see a little. :) https://redwoodjs.com/ form-data is very TOML like in its data model.

* Except nowadays most of them depend on it to be usable.

> thanks to progressive enhancement, and only Svelte and maybe Remix and a handful of others do that.

Notably, since a few weeks ago, Next.js (by far the biggest of the pack) has support for progressive enhancement with Form Actions.

https://nextjs.org/docs/app/building-your-application/data-f...

I hadn't realized that, but knew that's where it's headed, because I remember when they were accused of ripping features from Remix. https://news.ycombinator.com/item?id=31485733 Never a dull moment in the JavaScript community. ;) I'm helping with a Next 13 project so I'll see it firsthand soon though.

I think there is something to HATEOAS. It gets around the state sync issue of a distributed system in a clever way. As someone who has mostly built React based SPAs it’s like the network is just part of the unidirectional flow of a reactive app. It doesn’t work for all cases but I think it might work for 80% of them. It also feels right to be so close to just html in the browser.

htmx isn't about avoiding JS, it's about removing arbitrary limitations from HTML that have elsewhere been circumvented with JS. Users write less JS as a side effect of having an actually useful, modern "HTML", and with any luck the core features of htmx will eventually make it into standard HTML

That makes no sense, HTML is by design not supposed to be dynamic, that's the point of JS. There's a nice, clean, separation of concerns with HTML, CSS, and JS.

As an aside, htmx uses JS under the covers to make HTML dynamic.

> HTML is by design not supposed to be dynamic, that's the point of JS.

You are putting far too much faith in the design of web standards.

Anyways, here's a counterexample to your claim:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

A dialogue doesn't need javascript. You can render in html and can use server side logic to decide to display it

<audio> and <video> are older examples.

And of course <button type="submit">, <button type="reset">, annnnnd cough <a>.

There was <blink> and for some reason still <marquee> if you wanna consider animations dynamic.

Thanks, yeah, there are lots of examples of standard HTML features that wouldn't make any sense in a true static document DSL like LaTeX, or a paper document.

HTML is interactive and dynamic.

I was just augmenting your answer as I liked it! It was also sort of a response to my sibling responder as they didn't seem to get what you were saying.

EDIT: Oh wait, maybe they did now that I re-read it... maybe? I think it's time for bed.

HTML is designed to be dynamic via hypermedia controls, that is, elements embedded in documents that communicate some sort of hypermedia interaction to a user agent. The two common hypermedia controls are anchors and forms.

htmx simply generalizes this concept, allowing any element to be a hypermedia control, issuing any sort of HTTP request, in response to any sort of event and replacing any element in the DOM.

I have written an essay on an alternative software design principle to the traditional separation of concerns that we see in web development here:

https://htmx.org/essays/locality-of-behaviour/

Where in the spec for html did it specify that it's isn't meant to be dynamic?

HTMX effectively used js for a polyfill of potential html standards, very similar to using babel or postcss to prototype a proposed spec.

A lot of htmx is just a smoother version of what people used to do with forms and iframes.

I don’t do any webdev stuff, so I don’t k or about setting up a stack and all that stuff. But, it would be nice from a user point of view if this became popular enough that I could go back to browsing with JavaScript turned off.

Just look at Wordpress for the demand for shoehorning things into something because it seems easier on the surface and accessible without learning harder programming stuff, or at least investing in the initial overhead.

There will always be demand. It's likely very practical for certain usecases but that won't stop people from abusing it in full SaaS web apps before some CTO joins and has to abandon it all when requirements evolve. Although I've seen some highly capable apps built on top of jquery plugins like Select2, which were extended well beyond their initial intent. Things that work is all that matters at the end of the day when it comes to making $$$.

Wordpress is a platform or framework, HTMX is neither. If you don't like what HTMX offers for your next feature... just don't use HTMX attributes on those elements. So comparing it to WordPress, or React, etc. is not accurate.

If you think this analogy is about frameworks vs libraries you missed the point.

It's the exact sort of technology option that is simple and accessible on the surface which is why someone inexperienced would adopt it in the early days. Then requirements naturally evolve and it gets shoehorned into ever more complex situations it was never intended for.

I'm speaking from experience and anyone who has worked in web app dev / JS for any length of time can see this coming from a mile away. The mountain of jQuery libraries alone should be enough but in the history of the internet WordPress is the classic cliché example of a simple technology that frequently gets abused beyond its original design. If your project is small and niche then obviously this critique isn't relevant. Nor is it dismissing the utility of htmx.

Then you need to explain it better.

There is nothing wrong with offering simple solutions.

The problem with WordPress is that you can't just stop using it and painlessly swap to a more powerful framework/platform. You can really dig yourself into a hole.

This doesn't apply to HTMX.

You must not work on frontend because I've seen plenty of "simple" libraries exactly like htmx adopted and turned into monsters that power entire SaaS products the same way WordPress is turned into pseudo custom Web apps by non-programmers countess times.

Being the guy who has to decipher it is not a fun job and gives you perspective on early technology choices.

I've read enough discourse on HN re htmx to recognize people seeing it as an adequate solution for serious business usecases because they don't grasp the natural evolution in demands for complexity and interactivity in browser UIs.

People love downplaying why more serious JS frameworks are adopted in the first place then find themselves in situations that need it but try to pretend they can just force it on primitive "simple" libraries, as we saw with jquery ad nauseam. Or more likely they leave their mess for the next developer to do the job properly from scratch.

Every framework or library can be abused, but as a fellow software janitor I feel much better if the mess consists of just HTML templates and endpoints, rather than insane JS/TS/TSX build chains with invalid NPM dependency graphs (or a WordPress monstrosity).

One of the benefits of HTMX is that it doesn't add many abstractions, it primarily builds off existing ones. A HTMX dev must understand the basics of HTTP and the DOM, and not much else, to be functional.

All your endpoints are delivering partial HTML instead of JSON and you can switch to, say, React for your next feature?

I mean, you technically can, but for that amount of work and/or friction you can pretty much go between any 2 frameworks.

There is nothing preventing you from having new endpoints serve frontend JSON, or from refactoring select endpoints away from HTMX.

If you are refactoring everything because a small subset of features didn't fit the HTMX glove, that's an engineering management failure.

You can say the same for the conversion between any 2 frontend frameworks, or even wordpress (you can just add another php file and do whatever next to your existing stuff), what's the special thing about htmx here?

You accept 5% complexity to completely drop all the rest. “Bundlers”? Please.

I know that from a webdev bubble it seems the world is made of JS - I should rather say “and its various frameworks” - but that is not the case. There are lots of places where keeping the surface area small is very much appreciated and the concept of using “bundlers” for your moderately complex crud interface will get you laughed out the room. I guess that is where htmx can shine, not in webdev consultancies.

I think one big up with this html-centered approach is you don't have to worry about SSR

i will have you know that i wrote an awful lot of javascript to avoid writing javascript!

> I continue to be impressed at the effort people will put into avoiding writing any JavaScript

I continue to be impressed with the amount of handwaving the already-initiated do to downplay the horrors that are starting JS development in 2023.

It’s very clear at this point that we need real browser APIs instead of implementations (real interfaces that can be implemented and run in any language using web assembly).

Many people may disable js when browsing. So there's that.

HTMX requires JavaScript to work. If your goal is to render a usable page on the server and return it to the client, you can do that with plenty of full stack JS frameworks like Next.js, and as a bonus, it uses the same code to render it as it does on the frontend.

Htmx is for backend devs who think frontend must be simple stuff for simple devs. Then when they realize it’s not, they come up with some crazy new framework to prove to themselves that they know better and can still act superior.

I'm not saying I agree with your point, but I will say that the worst engineers I've worked with in my career are backend engineers who look down on frontend engineers/engineering.

It makes sense to me that good web developers would be multifunctual enough to implement a solution based on the complexity of the required design. React is conversely way too complicated for a lot of the stuff that's easy to do in HTMX, so you should be able to do both in my opinion.

Reply on news.ycombinator.com