261–270 of 318 posts
My biggest beef with htmx has more to do with the fact that it gets hyped as a React/Vue/Svelte alternative, when it's more accurate to describe htmx+ as an alternative. Also the constant use of pretentious memes on the official blog. But otherwise, I'm looking forward to trying it out for my next pet project.
> htmx+ You can use React with any backend.
A React app can live entirely in an .html file.
I like this fuzzy definition better than "your code calls a library; a framework calls your code." The sweet spot for HTMX I've found involves liberally using the hx-boost attribute enhance links and forms that already work without JavaScript. You definitely sacrifice some of the expressivity of HTMX, but you also get a website that is much less coupled to the (library|framework).
Earlier quoted context omitted.
> 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…
> 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 first HTML specification intended to be treated as a standard against which future implementations should be based.
But I can see what you mean and arguing over the meaning of "basic" isn't a hill I'm particularly interested in dying on.
> No, you're appropriating the definition, contorting it to pretend that it only means HTML as extended by HTMX, e.g. this
That's my definition of a Hypermedia-Driven Application, a term I made up to contrast with SPAs. I agree with you that a hypermedia can be imposed on top of JSON, which does not have native hypermedia controls, but I hope you can agree that this is not the way it is typically used today, and I also hope that most readers would understand that. I think the level of detail is appropriate for a high-level introduction to a concept that I created, but I see your point.
XML is another example of something that is not a natural hypermedia, but I included https://hyperview.org in the https://hypermedia.systems book, so I hope that demonstrates that I'm not wedded to the idea of HTML being the only hypermedia in the world.
I also agree entirely that a proper hypermedia client is crucial for a properly functioning hypermedia system:
https://htmx.org/essays/hypermedia-clients/
> 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.
I don't know, I think we agree I am using the term "hypermedia controls" properly, and I don't know if you have different feelings around my idea of generalizing them in HTML, given that fact. Does that change anything for you?
I certainly don't feel htmx is the only true way. I have never said that, and I try to be explicit when the hypermedia-based approach will be effective and when it won't here:
htmx is one of those things, like SQLite on the server, that you will incessantly see on HN, but rarely see used at large profitable companies. Say you use python and Django. Why use htmx instead of Django templates? Same with ruby and rails, elixir and phoenix, etc. the trend is clearly towards live view/hotwire OR things like server side react. Htmx is in a weird position that makes no sense unless you want to use…
People use it for the sake of not using JavaScript. To a React client-side developer everything should be done in React on the client-side, with maybe a sprinkle of backend for unavoidable things, like where API keys live. They’ll foot-gun as much backend stuff into the front end as possible. To a certain kind of backend developer, everything should be done typesafe in non-JavaScript on the backend, with a sprinkle o…
It’s a shame htmx wasn’t invented 10 years ago, but it makes sense that it’s bursting onto the scene now as a reaction to end-stage SPA mania.
If htmx-like functionality gets rolled into browsers with native optimizations (i.e. faster than the Virtual DOMs and custom JS runtimes of SPA frameworks, not to mention the no-build-step benefits we’re already seeing with htmx), then it hopefully won’t be just htmx that will get rendered obsolete; Angular, Ember, React, Svelte, Vue, etc. need to go even more urgently.
Pardon my enthusiasm, I really am looking forward to an HTML Renaissance.
Earlier quoted context omitted.
Does the lock file render the need to update dependencies obsolete? Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble. Lock files are not a substitute for sane dependency management.
There's no reason that you absolutely have to update every dependency after 6 months. Not updating anything at all is perfectly fine. Nobody in their right mind thinks you can change major versions without some elbow grease in any other language.
I have an old project that I didn't touch in more than 5 years. Last week, I decided to give it another spin, and booked the entire afternoon to deal with any issues that may arise from the update process.
It went from Python 3.6 to 3.11, and from Django 2.2 to 4.2. Postgres jumped from 11 to 16! There were 10 other libraries (PIL, ...) that I had to update too.
The only special procedure that I had to do was dumping data from the old database and restoring it from the new one, as recommended by PG when doing major-point updates. (And adding a single line to Django's `settings.py` for the new `CSRF_TRUSTED_ORIGINS`.)
When I typed `docker compose up` on my terminal, the app just run smoothly without as single problem. I even had to check that I didn't invoke the old configuration by mistake.
All in all, the process took me less than 15 minutes.
Earlier quoted context omitted.
Does the lock file render the need to update dependencies obsolete? Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble. Lock files are not a substitute for sane dependency management.
This is the same in any language then.
Earlier quoted context omitted.
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.…
HTMX breaks the "separation of concerns" paradigm. It's not going to help anyone doing anything complex, and it's going to be a crutch for anyone getting started. It breaks down quickly when the problem is anything more complex than clicking a button to load some content, and then what - rewrite everything in a more capable framework?
Simple answer: yes.
Earlier quoted context omitted.
How is that a problem?
People like to interact with interpreted languages
What is the core thing(s) I should be appreciating about HTMx?