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

161–170 of 291 posts

Re: htmx

#161

Post by dmix »

sodapopcan wrote: post #92
dmix wrote: post #11

Earlier quoted context omitted.

I count about ~6 generic submissions to htmx root domain or direct /docs with upvotes. More generally it's higher if you include blog posts or self-HN posts. The original submission had 728 upvotes: https://news.ycombinator.com/item?id=23330881 react.dev and reactjs.org has had 2 root url submissions: (728 upvotes) https://news.ycombinator.com/item?id=35186812 and older https://news.ycombinator.com/item?id=15366446 v…

> I suspect HTMX is more of an idea that people like to talk about on HN more generally, like Clojure and Erlang. Being the underdog matters on social media. Maybe it feels more authentic or relevant to discourse because it's still niche. Pretty glib take. The more exposure this stuff gets the better. I'd really like to have more job options out there that don't involve maintaining an internal web API so that two app…

I might have been using HN too long but you start to notice some pet technologies everyone here loves to safely upvote on HN but IRL stays niche for a reason. Especially in the serious business world of software development, not side projects or stuff we like talking about on social media. And I say that as a big fan of both Erlang and Clojure.

Re: htmx

#162

Post by oaiey »

throwaway2037 wrote: post #139
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…

This is a great post. I'm not a web dev myself, but I have a couple on my team. I criminally underrated the challenge of maintaining a complex web app. It is madness: endless incompatible, forced upgrades. Real Question: Why does this ecosystem have this issue, but others have it less? For example: Why doesn't Python or Java have the same madness? Please don't read the question as criticizing web dev / JavaScript / e…

Because the originals parts where broken. I am speaking of 90s JavaScript, the DOM/Browser API and the not so much "batteries included". They could neither get fixed without a standard by committee approach of the browser vendors.

So we started to compensate: end state: Typescript to fix JS, React/Angular/Svelte to fix DOM API and a npm package hell to have batteries included. And all of that bundles, compressed, etc to have a good download time.

Re: htmx

#163

Post by alex_lav »

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 continue to be impressed at the effort people will put into avoiding writing any JavaScript

I continue to be impressed with the amount of handwaving the already-initiated do to downplay the horrors that are starting JS development in 2023.

Re: htmx

#164

Post by eimrine »

inbx0 wrote: post #130
hakfoo wrote: post #123

Earlier quoted context omitted.

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?

Maybe the tail-call optimization?

Re: htmx

#165

Post by emodendroket »

Seems like a horrible idea that totally breaks separation of concerns, so I’m sure it will be a huge success you’ll see everywhere very soon.

Re: htmx

#166

Post by emodendroket »

adamredwoods wrote: post #97

I'm not a fan of adding functionality to hypertext attributes. I want an expected set of attributes to a component, not a new set of attributes that extend existing components. A lot of functionality can get obfuscated.

Strictly speaking you could already do this with x- attributes and plain JS, right?

Re: htmx

#167

Post by number6 »

dmix wrote: post #159
number6 wrote: post #134

Earlier quoted context omitted.

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

Gulp / Babel and then transition to webpack was my introduction to JS.

Now Vite seems to be all the rage? But is it a bundler?

Wepack seems to be very hard to configure. Looks like nginx config vs caddy config.

Re: htmx

#168

Post by emodendroket »

KevinChen6 wrote: post #76

Learning to use any new tool comes at a time cost, and if I learn this and then a newer, more convenient tool emerges that can replace it, I get stuck in the question. Are people driving the tools? Or are the tools binding people?

Perhaps too cynical from my dislike of frontend but I sometimes suspect the churn is spicing up monotonous work for some people.

Re: htmx

#169

Post by theK »

The_Colonel wrote: post #129
hakfoo wrote: post #123

Earlier quoted context omitted.

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.

> The only thing which I believe is still needed is a bundler

And a type system... And maybe a styling system... Oh and let's have some nice Rx data flows!

But, jokes aside, even if you go that Route you still end up with a complex npm project that involves dozens of libraries.

I've been at that point every year since starting doing npm spas in 2014ish (mostly as side projects, my work is typically more serverside). At some point I just decided that the upkeep wasn't worth it any more as you create the same stack every year but with wildly different libs. For me the solution was to switch to an elm+sass+webpack boilerplate that hasn't changed since 2018 or there abouts.

Re: htmx

#170

Post by the_gipsy »

TekMol wrote: post #121

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.

You're missing the "swap".
Post reply on HN