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

Is htmx Just Another JavaScript Framework?

htmx.org

Post reply on HN
Print view View original

271–280 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#271

Post by mlhpdx »

bilalq wrote: post #237
mlhpdx wrote: post #236

As a humble, new user of HTMX I don’t care what noun you choose for it (stereotyping by another word still smells the same). The facts as I have experienced them are a) it’s simple to do simple things; and b) it keeps difficult things possible. My highest praise. So, I’m using it. I’m a bit of a nut, and my backend is pure AWS Step Functions. Declarative web app, all the way down. Yes, because of HTMX the backend is…

What do you write your step functions in? Are you using ASL or something that compiles to it?

Straight ASL.

Re: Is htmx Just Another JavaScript Framework?

#272

Post by recursivedoubts »

drbawb wrote: post #229
recursivedoubts wrote: post #128

I am the author of htmx. I think htmx is a library using the following definition: - a library you call - a framework calls your code in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework. I liked alex's analy…

I agree with your definition, and I also believe it's an important distinction and a _better definition_ than the article author's. However I'm not sure I agree with your self-assessment of htmx being a library. HTML is not the host programming language: that'd be JavaScript. Arguably, in this case, it's also whatever is on the other side of the HTTP requests htmx is making; which is almost certainly _not_ HTML. htmx…

i agree with your analysis and find no flaw in you logic, but i continue to insist htmx is a library

Re: Is htmx Just Another JavaScript Framework?

#273

Post by recursivedoubts »

klysm wrote: post #255
recursivedoubts wrote: post #128

I am the author of htmx. I think htmx is a library using the following definition: - a library you call - a framework calls your code in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework. I liked alex's analy…

So it delegates the framework part to the browser?

that's actually not a bad way to frame cough it

Re: Is htmx Just Another JavaScript Framework?

#274

Post by Koffiepoeder »

runarberg wrote: post #231
tangue wrote: post #168

Earlier quoted context omitted.

Yep in 2024 we still haven’t found a generic datepicker and hundreds of people on the internet are coding their own version. HTML5 snafu

What is wrong with ?

Timezone support, no date ranges (eg from-to), date formats are a mess (mdn: "At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker."), often rules are needed (eg only weekdays), non gregorian calendars, ...

A good date input would cover at least like 80-90% of use cases in my opinion. From experience it's currently more something like ~40% or so.

Re: Is htmx Just Another JavaScript Framework?

#275

Post by bityard »

Cthulhu_ wrote: post #77
dartos wrote: post #29

Earlier quoted context omitted.

I hope it works! HTML is in dire need of some tlc

I was ultimately disappointed in HTML5 even though it was supposed to bring HTML into this era, with things like audio/video tags and new input methods for phone numbers and the like for mobile users. But ultimately it fell flat, was incomplete, and it feels like it's been stagnant again since HTML5 came out.

HTML5 was definitely a mixed bag. On the on hand, it gave us cleaner markup.

On the other hand, now we have auto-playing videos on every other page.

Re: Is htmx Just Another JavaScript Framework?

#276

Post by radicalriddler »

jokethrowaway wrote: post #108
taeric wrote: post #96

Earlier quoted context omitted.

This feels extreme? Any chance you could share numbers or more details on these prototypes? I agree that the ecosystem seems crazy fast on moving. I wouldn't have thought it was that bad. React, in particular, I thought had been fairly stable? (Yes, there are new ways of doing things, but most of the old still work there, to their credit.)

I don't think it's been the case for the last few months in particular, but Next has been historically terrible for this case. It sucks because it's also the best way of developing a React app without worrying much about tons of boilerplate crap. I have different next projects started at different times and whenever I need to change a single line of text, I have a 50% chance something won't work and I'll have to debu…

> and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host

Oh, you're not using Vercel? There's your first mistake \s

Re: Is htmx Just Another JavaScript Framework?

#277

Post by nine_k »

davexunit wrote: post #228
nine_k wrote: post #197

Earlier quoted context omitted.

Often you want to limit the expressive power, in order to obtain other important guarantees. E.g. much of the time you don't want a Turing-complete language, because it must be able to express a never-terminating program. HTMX is expressive enough for many smaller cases. If your case requires more richness, you can always pick React, Vue, Elm, etc, and be able to do basically anything on the client side.

Give a programmer a non-Turing complete language and they will use a Turing complete language to compile down to it. When a program is only configurable in YAML, someone will use jinja2 to generate it so they can have loops. SASS exists because CSS isn't expressive enough. Etc. etc. etc. I just really don't subscribe to purposely limiting expressive power via non-Turing completeness. I've never wanted to do this in m…

There are underpowered languages / tools, that can only solve a problem for which they are intended poorly. But not all limited tools are like that.

Say, eBPF is prominently not Turing-complete, which allows to guarantee that a eBPF program terminates, and even how soon. Still eBPF is hugely useful in its area.

Or, say, regular expressions are limited to regular languages; in particular, they famously [1] cannot process recursive structures, like trees. Still tools like grep / ag / rg are mightily useful.

Yes, I agree that YAML is underpowered for proper k8s configuration! But it's also too powerful for its own good in other aspects [2]. I wish Google used Dhall [3] or their own purely functional config language (FCL? I already forgot the name) instead of YAML; sadly, they did not.

[1]: https://stackoverflow.com/a/1732454/223424

[2]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...

[3]: https://dhall-lang.org/

Re: Is htmx Just Another JavaScript Framework?

#278

Post by nine_k »

bobthepanda wrote: post #205
nine_k wrote: post #194

Earlier quoted context omitted.

But how about Web Components? Finally, it seems, there's something reusable, and something reasonably framework-neutral.

is it that nice? the beauty of HTML markup is that it's declarative. at least from the tutorials I've seen, WebComponents drag you firmly back into imperative land with document.addChild everywhere.

The imperative part is required to build a Web Component.

When you merely import it. you can use it as declaratively as any other HTML tag. Basically Web COmponents allow you to add your own tags that are rendered as components, and freely mix "built-in" and "custom" DOM nodes in your document.

Re: Is htmx Just Another JavaScript Framework?

#279

Post by nine_k »

paulddraper wrote: post #227
nine_k wrote: post #194

Earlier quoted context omitted.

But how about Web Components? Finally, it seems, there's something reusable, and something reasonably framework-neutral.

Web Components are how you can create user-land HTML elements. But there is a widespread desire for better native HTML elements. E.g., a date range input.

I'd say that it's the other way around, and native elements that are not system-dependent (say, a video player) should lose prominence. There's no reason to have a "native-looking" button on a web page, which otherwise cannot (and should not) be made native-looking.

Instead I expect the industry to stabilize around a few widespread sets of web components, much like a lot of CSS for controls stabilized around Bootstrap's styles.

Re: Is htmx Just Another JavaScript Framework?

#280

Post by wutwutwat »

Don't know anything about htmx, just popping in to see if anyone else remembers "dhtml", and "dhtml guru". A different time. A different internet.

htmx triggered that random memory, and then a flood of others, like:

the gold rush of people, sometimes kids, renting servers or colocating space, installing cpanel, and starting a shared hosting company

dreamhost, remember dreamhost?

vps hosting providers that offered emulated systems, before public cloud was a thing, before vmware or hypervisor OSs, before kvm, or virtualization in general

webmin/virtualmin (which is still going strong it seems)

turnkeylinux (which is also still going strong)

linux from scratch

macromedia

betaarchive.com

Chris Pirillo

Post reply on HN