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

151–160 of 291 posts

Re: htmx

#151

Post by seattle_spring »

robertoandred wrote: post #115
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…

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.

Re: htmx

#152

Post by bee_rider »

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

Re: htmx

#153

Post by kkapelon »

vnorilo wrote: post #128
mkesper wrote: post #110

Earlier quoted context omitted.

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.

Re: htmx

#155

Post by pavlov »

Long arguments here about whether HTMX or React or something else can qualify as idiomatic HTML.

But the truth is, HTML itself does so very little that it’s barely useful as a starting point for building applications.

Arguing about idiomatic HTML in this context is like arguing about how to write a scientific paper in idiomatic toddler language. One faction thinks you should stick to monosyllabic words. Another believes drawings of colorful balloons are key. Both are held back by the fundamental assumption.

Re: htmx

#156

Post by egeozcan »

pphysch wrote: post #109
dmix wrote: post #106

Earlier quoted context omitted.

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…

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.

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.

Re: htmx

#157

Post by jdthedisciple »

julianeon wrote: post #138
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 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 b…

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.

Re: htmx

#158

Post by brabel »

number6 wrote: post #134
The_Colonel wrote: post #129

Earlier quoted context omitted.

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?

You're outdated. Everyone is using Parcel now.

Re: htmx

#159

Post by dmix »

number6 wrote: post #134
The_Colonel wrote: post #129

Earlier quoted context omitted.

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?

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.

Re: htmx

#160

Post by hardwaregeek »

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…

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.

Post reply on HN