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.…
Is htmx Just Another JavaScript Framework?
291–300 of 318 posts
Re: Is htmx Just Another JavaScript Framework?
#292Earlier 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…
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?
#293Earlier 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…
Re: Is htmx Just Another JavaScript Framework?
#294Earlier 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.
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?
#295Earlier 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…
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?
#296Earlier 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.
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?
#297HTMX 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.
And add HTMX as an "extension"
Re: Is htmx Just Another JavaScript Framework?
#298Earlier 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.
Re: Is htmx Just Another JavaScript Framework?
#299Earlier 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.
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?
#300Earlier 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