Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

htmx

htmx.org

Post reply on HN
Print view View original

31–40 of 291 posts

Re: htmx

#31

Post by tomberek »

0xEFF wrote: post #21
chatmasta wrote: post #6

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…

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?

Re: htmx

#32

Post by asah »

can htmx be used offline? i.e. am I screwed if I load an htmx page, close a laptop and get on a plane?

Re: htmx

#33

Post by rafark »

chatmasta wrote: post #6

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…

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

Re: htmx

#34

Post by trog »

benatkin wrote: post #27
0xEFF wrote: post #21

Earlier quoted context omitted.

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…

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

Re: htmx

#35

Post by benatkin »

trog wrote: post #34
benatkin wrote: post #27

Earlier quoted context omitted.

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…

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

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.

Re: htmx

#37

Post by eduction »

graypegg wrote: post #26
chatmasta wrote: post #6

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

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

Re: htmx

#38

Post by ipaddr »

pphysch wrote: post #25
candiddevmike wrote: post #20

Earlier quoted context omitted.

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

Re: htmx

#39

Post by earthboundkid »

llambda wrote: post #10

How does htmx compare with alpinejs ( https://alpinejs.dev/ )?

Alpine is more of a Vue replacement and HTMX is more of a fetch replacement. You can use both, although it’s a little redundant.

Re: htmx

#40

Post by tentacleuno »

PaulHoule wrote: post #24
chatmasta wrote: post #6

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

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.
Post reply on HN