9 ms·
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 mention
by crftr 3y ago
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.
- dartos 3y agoI hope it works! HTML is in dire need of some tlc
- Cthulhu_ 3y agoI 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.
- tangue 3y agoYep in 2024 we still haven’t found a generic datepicker and hundreds of people on the internet are coding their own version. HTML5 snafu
- runarberg 3y agoWhat is wrong with <input type="date">?
- Koffiepoeder 3y agoTimezone 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.
- nine_k 3y agoBut how about Web Components? Finally, it seems, there's something reusable, and something reasonably framework-neutral.
- bobthepanda 3y agois 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.
- nine_k 3y agoThe 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.
- sharlos201068 3y agoI'm pretty sure a declarative shadow Dom is currently in the works.
- paulddraper 3y agoWeb 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.
- nine_k 3y agoI'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.
- bityard 3y agoHTML5 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.
- dvogel 3y agoWhen 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, such as redirects in the hx- readers on a 200 response. Once I understood that htmx is explicitly trying to move the boundary of the hypermedia client a lot of that discomfort melted away.
- lurking15 3y agoYes htmx is an augmentation of the browser, specifically through enhancing HTML by way of JS. The idea is that JS frameworks became popular due to the lack of additional hypermedia controls which are the basis for how agents (users) interact with websites through hypermedia clients (browsers).
- troupo 3y ago> 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 can create a client that only accepts base32-encoded cat gifs, and that will be a hypermedia client (in its infancy).
- wild_egg 3y ago> Simply put, anything that talks HTTP and understands responses from a server is a hypermedia client to an extent. No, anything that understands hypermedia responses is a hypermedia client. Cat GIFs are not hypermedia so a cat GIF viewer is not a hypermedia client Maybe I'm overly grumpy this morning but words do actually have meanings that we can look up and refer to
- 3y ago
- songbird23 3y agothis is super helpful take. i get it now
- karmarepellent 3y agoAre you sure HTMX aims to be eventually incorporated in some form or another into the HTML spec? I think I read most of the blog articles on the website but I cannot remember such a statement. Another question in the same vein: In your view, why is it so important for the project to advance the HTML spec? By the way I am actually curious about this, I am an avid user of HTMX, but have never contemplated this. Edit: Ok I think I get it now. HTMX provides hypermedia controls that should have been in the standard from the beginning. It also more-or-less maintains the current semantics of the web as defined in the HTML spec. Therefore it is logical to eventually include it into the standard. That it?
- dragonelite 3y agoYeah that was the same impression i had of HTMX it makes sense to integrate HTMX functionality into HTML 6 or whatever.
- radlad 3y agoMaybe 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 https://news.ycombinator.com/item?id=35831981
- recursivedoubts 3y agoyeah, 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
- troupo 3y agoThey 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.
- paulddraper 3y ago
- falsandtru 3y agoAn example on the top page shows that this is an operation that should be written as a program. Therefore, this is not markup. Syntax that is not markup will not be the HTML specification. > <button hx-post="/clicked" hx-swap="outerHTML">
- pphysch 3y agoHow is that different than a standard <a> or <form> element that submits an HTTP request, receives some HTML in response, and uses that HTML to render a new GUI?
- hellcow 3y agoThe point of HTMX is that any element can submit HTTP requests, and you can drop the response anywhere in the document. It no longer has to be just <a> and <form> with full page reloads.
- cqqxo4zV46cp 3y agoYes. That’s the point? So why is it egregious in a way that <form> is not?
- omnimus 3y agoIt's not different. The question is if we would have current JS capabilities in the past would we choose adding handling of <form> to HTML or would we say use JS for that. I am not sure what is the right answer but adding features to both sides is probably not a great idea because you just bloat everything.
- pphysch 3y agoIt's a language paradigm thing. You can implement anything, from HTML to CSS, in pure imperative JS, but the result would be extremely verbose and virtually impossible for machines to interpret on the fly (i.e. little accessibility support). There is concrete value in stating unambiguously "this is a <form>" versus "this is a blob of imperative code that I swear acts like a <form>".
- dfabulich 3y agoI'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML. In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get <form> to target a section of the page that isn't an <iframe> has been argued about and hashed out for years. Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. https://github.com/whatwg/html/issues/new?assignees=&labels=addition%2Fproposal%2Cneeds+implementer+interest&projects=&template=1-new-feature.yml https://github.com/whatwg/html/issues/new?assignees=&labels=... It asks three main questions: * What problem are you trying to solve? * What solutions exist today? * How would you solve it? The goal of these questions is to focus primarily on the problem, and only secondarily on the solution. For comparison, generally standards folks think we don't want to add programming-language features to HTML, e.g. adding <if> <while> and <set-variable> elements. If you want that sort of thing, you want a full programming language; you want JavaScript, actually. So, when people propose features that don't perfectly address their problem, we want to ask: what do you want that for? How could we solve those problems better? HTMX doesn't have really great answers to the "what problem?" question. Look at the home page: * Why should only <a> and <form> be able to make HTTP requests? * Why should only click & submit events trigger them? * Why should only GET & POST methods be available? * Why should you only be able to replace the entire screen? Those questions are all solution-oriented, not problem-oriented. Instead, let's look at the examples. https://htmx.org/examples/ https://htmx.org/examples/ Each of those examples are important problems that HTMX can solve. But it doesn't solve them very well from the perspective of screen-reader accessibility. For example, there's a bunch of stuff there around managing editable data tables (click to edit, bulk update, click to load rows, delete row, edit row). But none of them work well with screen readers. How would a screen reader describe updates to these data tables? (Go on and try those examples in a screen reader, e.g. iOS VoiceOver. It's not great.) Of course, editable data tables are a very widely requested HTML feature; it seems quite likely that a feature like that will be added to HTML. When it is, a screen reader will announce the feature as a data table, describing it to the user clearly, including live updates. Some of the HTMX examples already have recent new HTML features that support them directly, like <dialog>, declarative form validation, using <details> as an accordion (which you can use to support tabs). In the future, I expect to see HTML features landing like these: * Editable data tables * Infinite scroll / lazy loading * Combobox * Skeleton UI / Loading If/when those features get done, it's not totally clear which problems remain that would be a good fit for HTMX's approach to declarative AJAX. Like adding <if> <while> or <set-variable> elements, the problems it solves seem to all have better solutions at a different level. And yet, we'll probably be waiting 5-10 years for those features to be standardized, at a minimum. So it's a bummer that HTMX probably won't be standardized any time soon, and that the standards committee has consistently let the "best" solution become the enemy of a "good enough" solution. But, that's what happened, and I expect it to continue to happen, so I wouldn't hold your breath for HTMX standardization. (If you'd been holding your breath ten years ago, you'd be long dead now.)
- throwaway_08932 3y agoI hope "render itself" was an intentional rendering pun.
- jjkeddo199 3y agoAgreed
- guilhas 3y agoWouldn't it be better to leave HTML as a passive document markup? And add HTMX as an "extension"