Live data from Hacker News

htmx

htmx.org

21–30 of 291 posts

Re: htmx

#21

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…

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.

Re: htmx

#22

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…

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 maki…

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

Re: htmx

#23

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…

[deleted]

Re: htmx

#24

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…

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.

Re: htmx

#25
post #14

Earlier quoted context omitted.

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

Re: htmx

#26

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…

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.

Re: htmx

#27
post #21

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…

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

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.

Re: htmx

#28
post #22

Earlier quoted context omitted.

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 maki…

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

Re: htmx

#29
I use htmx heavily on https://golfcourse.wiki

It’s nice and easy to work with, and lets me keep almost everything in python (flask).

It’s a bit more bandwidth, but it’s a hobby/bootstrapped project right now, and since it’s an api, if I ever make any money, it’ll be easy to rewrite and heavy lifting.

I like it because I’ll write 3x the code in the same amount of time if it’s python. I just don’t like js much even though I know it’s fine.

Re: htmx

#30
This is VERY cool. I’m very excited to see a project like this. Is it me or there has been a lack of wow-factor projects lately like when jquery was introduced. Or templating engines like handlebars. Or when angular and react took over. Browsing the htmx site felt like learning about those aforementioned projects for the first time.
Post reply on HN