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

121–130 of 291 posts

Re: htmx

#121

Post by TekMol »

Hmmmm... no.

This:

    
        Click Me
Should be just this:

    
        Click Me
This way, no magic would be needed, a lot of indirection and complexity would be avoided and everybody who knows HTML and JS could immediately read and understand it:

    - When does something happen here?
      When the button is clicked.

    - What does happen?
      htmx.post() is called.

Re: htmx

#122

Post by baby »

genmud wrote: post #52
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 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 abstract…

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

Re: htmx

#123

Post by hakfoo »

genmud wrote: post #52
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 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 abstract…

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.

Re: htmx

#125

Post by jedberg »

whatscooking wrote: post #43

Ah yes…the daily htmx post

Seriously, why does this keep popping up? I get it, it's cool. But I feel like in a month we're going to see "How I gamed the HN front page to put my website on the top every day for a month".

Re: htmx

#126

Post by 0xblinq »

cpitman wrote: post #19
laex wrote: post #3

Can HTMX be used with static site generators, such as Hugo, to create interactive documentation websites?

I think that unpoly( https://unpoly.com/ ) would be easier for that use case. htmx generally expects succesive http requests to only return the fragment of html that will be swapped into the target, not the entire page. So you generally want something server side that can check the request and either return the full page (either for a first hit or disabled javascript) or return just a fragment (an htmx request). Unpo…

Unpoly is great. I used it a few years ago for reimplementing the UI of an application built with a traditional MVC framework and I was impressed with the results. Nobody could tell it was not React/vue/etc from the outside and the frontend code was quite simple and minimal.

Re: htmx

#127

Post by zackify »

baby wrote: post #122
genmud wrote: post #52

Earlier quoted context omitted.

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

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.

Re: htmx

#128

Post by vnorilo »

mkesper wrote: post #110
loveparade wrote: post #99

Earlier quoted context omitted.

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

Re: htmx

#129

Post by The_Colonel »

hakfoo wrote: post #123
genmud wrote: post #52

Earlier quoted context omitted.

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

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…

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.

Re: htmx

#130

Post by inbx0 »

hakfoo wrote: post #123
genmud wrote: post #52

Earlier quoted context omitted.

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

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…

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