[0xEFF]

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.

[austin-cheney]

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

[benatkin]

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.

[trog]

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

[egeozcan]

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.

[elchief]

> 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

[benatkin]

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.

[user32456]

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!

[renerick]

It is explicitly NOT a silver bullet

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

[benatkin]

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.

[renerick]

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

[tomberek]

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?