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

251–260 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#251

Post by troupo »

nine_k wrote: post #194
Cthulhu_ wrote: post #77

Earlier quoted context omitted.

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.

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

You will need to wait another 10-15 years before they overcome the issues that they caused for themselves (while twisting and contorting the platform in unpredictable ways): https://threadreaderapp.com/thread/1717580502280867847

Re: Is htmx Just Another JavaScript Framework?

#252

Post by satvikpendem »

zo1 wrote: post #244
satvikpendem wrote: post #201

Earlier quoted context omitted.

Not really. Python's is worse for example.

Sorry, I have to call BS on this. I'm hugely familiar with Python and used it for over 10 years, pretty much always on "latest version" instead of pinning. And had issues with incompatible versions less than 5 times. JS? Pretty much every single project, if any apreciable chunk of code gets ignored for a few months its almost guaranteed that it has breaking changes somewhere.

I've been using Python longer than you have and I've always had issues. JS is bad for sure, but it's not "highly unique" to JS as the parent states.

Re: Is htmx Just Another JavaScript Framework?

#253

Post by recursivedoubts »

theultdev wrote: post #232
recursivedoubts wrote: post #218

Earlier quoted context omitted.

welp, when you are coordinating things it's often a tremendous simplification to have a centralized source of truth and then present representations of that truth in the form of hypermedia to hypermedia clients, using hypermedia as the engine of application state of course, it's not right for everything and there are alternative approaches that work better or worse, depending on context, but i'd say it's hard to not…

a centralized source of truth is a pretty successful approach to distributed systems? seems more like a successful escape hatch. yes it's simpler, but it's antithetical to the goal.

well, i mean, the web is a distributed system of servers providing resource representations specified by universal resource locators

it seems to have been fairly successful to me

i think you are associating 'distributed' w/peer-to-peer models, whereas i'm using it in the broader sense of networked software that can interact (link) to one another

i have no beef w/ peer-to-peer and it would be interesting to think about how hypermedia could layer on top of that model, but i'm not an expert on that sort of stuff so I can't have particularly informed opinions on it

Re: Is htmx Just Another JavaScript Framework?

#254

Post by satvikpendem »

chatmasta wrote: post #207
zo1 wrote: post #199

Earlier quoted context omitted.

No, this is highly unique to JS/TS. I've worked in plenty other languages and it's bo where near as bad. Yes they all have some form of this, but it's an order of magnitude smaller. One big contributor is JS's proclivity to have lots of smaller libraries. This increases the chances of one of the included libraries having a breaking change. Pile ontop of that this insane notion of constant version pinning and "semanti…

I agree that many packages in the JS ecosystem don't respect semantic versioning, which is why I pin my dependencies to an exact version. For updates, I rely on automated bots submitting PRs that update a single package at a time and run my test suites. But even if they did respect semver, I'd still use exact versions, because I want full control over when I update my dependencies, and I don't want lockfile updates l…

Exactly, people don't use (or commit to git) lockfiles and then are surprised when dependencies update, which is literally the point of what a lockfile is supposed to prevent.

Re: Is htmx Just Another JavaScript Framework?

#255

Post by klysm »

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?

Re: Is htmx Just Another JavaScript Framework?

#256

Post by recursivedoubts »

troupo wrote: post #246
recursivedoubts wrote: post #161

Earlier quoted context omitted.

all of those projects are much more magical, particularly the live* flavor of hypermedia driven applications htmx generalizes the standard hypermedia controls found in HTML: anchors & forms this makes it more work to implement some things, but sticks closer to the basic ideas of HTML and, as always, if nothing magically works, nothing magically breaks

> all of those projects are much more magical, Oh, they are not. They are more powerful, but they use rather simple concepts. Speaking as the user of Phoenix LiveView who even created his own templating library to work with it. > htmx generalizes the standard hypermedia controls found in HTML: anchors & forms Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit. > the…

> Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit.

What would you call links & forms? The W3C seems to agree w/my language:

https://www.w3.org/2019/wot/hypermedia

"This document introduces an ontology for links and forms, the main hypermedia controls in use on the Web."

> The "basic idea of HTML" is "render a text page with a few images in one rendering pass with links to other such documents". That is it.

I don't know about that. What about forms? And script tags. And all the other stuff?

> You're not better. This is not what founders envisioned.

I don't claim to be better, i don't know what that means in this context. I'm trying to generalize what I understand to be hypermedia controls (links & forms) in HTML, in a way that conforms to Roy Fielding's definitions of the uniform interface.

I don't understand the hostility here. htmx isn't perfect or some sort of amazing piece of software, it's a flawed implementation by a flawed human of a perhaps flawed idea of generalizing hypermedia controls. But it's not obviously terrible either: people are having success using it, as a quick cruise around the other comments in this thread would indicate.

Re: Is htmx Just Another JavaScript Framework?

#257

Post by gameman144 »

candiddevmike wrote: post #174
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…

IMO, a library is easily swappable with another library, a framework is not, it's all over your codebase. Htmx meets the definition of the latter.

This is an interesting definition to me. Any library is going up make implementation-specific assumptions, so unless you're using a library that's purely an interface that multiple implementations conform to (e.g. SQL, and even then not fully) then there's necessarily going to be some migration work when switching libraries.

Re: Is htmx Just Another JavaScript Framework?

#258

Post by masklinn »

paulddraper wrote: post #188
wild_egg wrote: post #165

Earlier quoted context omitted.

> 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

> 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 hypermedia 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.

Re: Is htmx Just Another JavaScript Framework?

#259

Post by troupo »

recursivedoubts wrote: post #256
troupo wrote: post #246

Earlier quoted context omitted.

> all of those projects are much more magical, Oh, they are not. They are more powerful, but they use rather simple concepts. Speaking as the user of Phoenix LiveView who even created his own templating library to work with it. > htmx generalizes the standard hypermedia controls found in HTML: anchors & forms Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit. > the…

> Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit. What would you call links & forms? The W3C seems to agree w/my language: https://www.w3.org/2019/wot/hypermedia "This document introduces an ontology for links and forms, the main hypermedia controls in use on the Web." > The "basic idea of HTML" is "render a text page with a few images in one rendering pass with…

> 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 whole idea was still to lay out the page in one rendering pass (and this was only changed IIRC sometime in 2001-2002 with optimisations for tables).

> I'm trying to generalize what I understand to be hypermedia controls (links & forms) in HTML, in a way that conforms to Roy Fielding's definitions of the uniform interface.

No, you're appropriating the definition, contorting it to pretend that it only means HTML as extended by HTMX, e.g. this [0]:

--- start quote ---

The Hypermedia Driven Application (HDA) architecture...

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

Nope. JSON (or literally anything else) can also be hypermedia as long as there's a client which can understand it and present it to the user, and can follow links etc.

> I don't understand the hostility here.

I'm just getting tired of people hijacking specific terms to suit their own narrow definitions (however many hoops they have to jump through to get there), and present these narrow contorted definitions as the only true way.

[0] https://htmx.org/essays/hypermedia-driven-applications/

Re: Is htmx Just Another JavaScript Framework?

#260

Post by masklinn »

dfabulich wrote: post #141
crftr wrote: 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.

I'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 to target a section of the page that isn't an has been argued about and hashed out for years.…

> I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML.

I don't think the point is for HTMX to get standardised, but rather for HTMX to drive conversation and evolutions in the spec.

After all jQuery did not get standardised. Rather the issues solved by subsets of jquery were looked at, and considered for solving in the standard.

Post reply on HN