Live data from Hacker News

Is htmx Just Another JavaScript Framework?

htmx.org

291–300 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#291
post #146
post #41

Earlier quoted context omitted.

When I initially read the htmx documentation I was confused because it kept talking about a hypermedia client. The context clues suggested they were referring to htmx but my brain kept saying "isn't the browser the hypermedia client?" Eventually it sank in that htmx is an extension of the hypermedia client. When I first tried to use htmx I experienced a lot of discomfort regarding areas where htmx feels non-standard,…

> Once I understood that htmx is explicitly trying to move the boundary of the hypermedia client a lot of that discomfort melted away. What do you mean by "moving the boundary of hypermedia client"? HTMX tries to claim that hypermedia to only applies to HTMX because something something browsers and html. Simply put, anything that talks HTTP and understands responses from a server is a hypermedia client to an extent.…

you keep saying this despite the fact that I explicitly include https://hyperview.org as an example of another hypermedia in https://hypermedia.systems. I am very open to other types of hypermedia and often refer people to “RESTful Web Cliebts” by mark amundsen (https://www.oreilly.com/library/view/restful-web-clients/978...) to learn how build them.

Re: Is htmx Just Another JavaScript Framework?

#292
post #279

Earlier quoted context omitted.

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

Which controls stabilized around Bootstrap styles (now there's a a name I haven't heard in a long time)?

No, industry should not and will not stabilize around "few widespread sets". For the simple reason: it's extremely difficult to create a proper userland UI control in the browser. How many custom drop downs fail even the most basic keyboard behaviours? How many custom UI elements fail even the most basic screenreader interactions? etc. etc.

What you really truly need is a rich browser-native set if controls, and https://open-ui.org/ is slowly working towards that.

Related: You can't capture the nuance of my form fields https://web.archive.org/web/20230208235009/https://drewdevau...

Re: Is htmx Just Another JavaScript Framework?

#293
post #38

Earlier quoted context omitted.

Dependency management is an unrelated issue and it exists for any platform. Unless you copy paste code or unless you just avoid dependencies. Which is easy to do in TypeScript as well. Nobody says you need to install hundreds of packages.

> Nobody says you need to install hundreds of packages. If I need one, I have to get that package's dependencies. People don't choose to say "Damn, I'd really love to have 1800 dependencies!" But if you have 4-5, you automatically get dozens or hundreds out of your control. Yes, could you build everything yourself by hand? Sure. That's a hard sell to many depts/projects. "This will take 3 weeks to build" vs "This wil…

Publishing & importing 3rd party code is so easy with npm that everyone is blindly importing code that wouldn't pass their own peer reviews.

Re: Is htmx Just Another JavaScript Framework?

#294

Earlier quoted context omitted.

> words do actually have meanings that we can look up and refer to It's odd to insist on strict word choice when transferring GIF images using the hypertext transfer protocol.

It's not though? Gifs are media, but they are not hyper media because they don't support hypertext (can't link to to other media). As such, they're ancillary sub-resources to hypermedia but not themselves hypermedia.

Yeah. PDFs would be a better example. They can link to other media :)

But I wouldn't be surprised if there's a crazy project somewhere using GIFs as a way to render HTML pages with clickable links :D

Re: Is htmx Just Another JavaScript Framework?

#295
post #259

Earlier quoted context omitted.

> The W3C seems to agree w/my language: Ah. Interesting. I stand corrected. Skimming through the document it looks like a very late retrofit and attempt at standardization for some parts of the w3c tech stack like RDF, web of things etc. > What about forms? And script tags. And all the other stuff? None of them existed in the "basic idea of HTML". "All the other stuff" accumulated over the years. Until early 2002 the…

OK, good, so I think we agree I am using the term "hypermedia control" correctly then? > None of them existed in the "basic idea of HTML". Well, the form tag was introduced in HTML 2, which was in some ways the first "standard" for it, so relatively early in the game: After the HTML and HTML+ drafts expired in early 1994, the IETF created an HTML Working Group. In 1995, this working group completed "HTML 2.0", the fi…

> That's my definition of a Hypermedia-Driven Application, a term I made up to contrast with SPAs.

There's no contrast. It's not even a made up term. I was doing "hypermedia-driven applications" with HATEOAS in 2012.

> I agree with you that a hypermedia can be imposed on top of JSON, which does not have native hypermedia controls

The way you extend browser behaviour with Javascript to use non-standard attributes, non-standard headers etc. is literally no different from literally any other lib/framework doing the same with literally any other format.

> XML is another example of something that is not a natural hypermedia

There it goes again. "Natural hypermedia".

There's no such thing as "natural hypermedia". You're inventing stuff as you go along to try and contort terms and concepts to fit the extremely narrow definition of "hypermedia is HTML with HTMX attached to it".

It's not.

> if you have different feelings around my idea of generalizing them in HTML,

You're not "generalising them in HTML". You're literally, and I quoted, pretending that hypermedia is HTML, and HTML only (with HTMX sprinkled on top).

> I certainly don't feel htmx is the only true way. I have never said that

--- start quote ---

An HDA uses declarative, HTML-embedded syntax rather than imperative scripting to achieve better front-end interactivity

An HDA interacts with the server in terms of hypermedia (i.e. HTML) rather than a non-hypermedia format (e.g. JSON)

--- end quote ---

Literally here: you claim that hypermedia apps are is only based HTML, only use HTML-based syntax and only use HTML to communicate. Because "other formats are not hypermedia". That is, you literally claim that HTMX is the only true hypermedia driven app or something.

Also, elsewhere someone put it even more succinctly: https://news.ycombinator.com/item?id=38965060

Re: Is htmx Just Another JavaScript Framework?

#296
post #290

Earlier quoted context omitted.

It's not though? Gifs are media, but they are not hyper media because they don't support hypertext (can't link to to other media). As such, they're ancillary sub-resources to hypermedia but not themselves hypermedia.

If you're going to get that picky (and please be aware I'm only doing this for the sake of the argument) media can never be hypermedia in the absence of the client. HTML opened in notepad is just text. Cat GIFs, rendered in the correct client, would absolutely be hypermedia (you could inline link data as QR codes, if you felt like being perverse). Hypermedia starts with the client, not with the file format.

You are the one being overly picky. Of course given this gif-hypermedia-client your gif is hypermedia. But the client you mentioned above is not.

How you transfer the data is irrelevant BTW. I don't get why you include that in your argument.

Re: Is htmx Just Another JavaScript Framework?

#297
post #21

HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`. The discussion about Library vs. Framework misses the core objective of the HTMX project.

Wouldn't it be better to leave HTML as a passive document markup?

And add HTMX as an "extension"

Re: Is htmx Just Another JavaScript Framework?

#298
post #250

Earlier quoted context omitted.

> The author posits that these features should be in the spec Does he? The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both. And that's about it. Nothing about "this should be in the spec"

> The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both. Does he? Evidence or it didn't happen.

They literally have an entire book written to contort those definitions to mean HTMX

Re: Is htmx Just Another JavaScript Framework?

#299
post #146

Earlier quoted context omitted.

> Once I understood that htmx is explicitly trying to move the boundary of the hypermedia client a lot of that discomfort melted away. What do you mean by "moving the boundary of hypermedia client"? HTMX tries to claim that hypermedia to only applies to HTMX because something something browsers and html. Simply put, anything that talks HTTP and understands responses from a server is a hypermedia client to an extent.…

you keep saying this despite the fact that I explicitly include https://hyperview.org as an example of another hypermedia in https://hypermedia.systems . I am very open to other types of hypermedia and often refer people to “RESTful Web Cliebts” by mark amundsen ( https://www.oreilly.com/library/view/restful-web-clients/978... ) to learn how build them.

> I am very open to other types of hypermedia

Of course you're not. And I already pointed it out to you elsewhere. Your entire writing and marketing revolves around one idea, and one idea only: HTML is "natural hypermedia", and everything else is not.

Re: Is htmx Just Another JavaScript Framework?

#300
post #105

Earlier quoted context omitted.

Maybe not an explicit aim, but it sounds like Carson Gross holds a positive view of browsers implementing these features directly: https://news.ycombinator.com/item?id=35831981

yeah, i don't think the htmx API would be the right thing to add to HTML, it's too specific to htmx, but the idea of generalizing hypermedia controls is something i hope the browser people look at

They have, and it failed. "Hypermedia controls" are for machines, first and foremost. That's what RDF and semantic web were supposed to be about, but that never took off in any significant shape or form.
Post reply on HN