hi there, as many of you know, i am the creator of htmx and I'm happy to answer any questions about it
htmx has seen a surge in popularity, triggered by a video by fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) and a series of videos by ThePrimeagen, a popular twitch streamer on it
hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here:
while I am a fan of htmx, obviously, I think the deeper concept that it touches on is hypermedia, which is a worthwhile idea for people to explore even if they don't plan on using it in day-to-day programming.
There are also lots of other great hypermedia-oriented libraries worth checking out such as Hotwire from 37signals, or, my favorite after htmx, https://unpoly.com
I remember few month ago I was making a post liking system, before htmx, I had to use jQuery to fetch the json api server and update the like count, but with the use of HTMX, oh boy it was like I was just writing plain html along with my django logic.
This is one of the greatest thing I've found.
Also, handling forms with HTMX is also very easy.
HTMX really improve both user and developer experience.
I've also found htmx a great way to retain server side rendering with minimising the recalculation cost of client changes.
By avoiding needing to add lots of client side logic to still get very low latency updates, it's given me the best of both worlds.
The way Django's template system works also makes it so easy to render a full page initially, then expose views for subcomponents of that page with complete consistency.
On a tangent, Django's async support is still half-baked, meaning it's not great for natively supporting long polling. Using htmx to effectively retrieve pushed content from the server is impeded a little by this, but I slotted in a tiny go app between nginx and gunicorn and avoided needing async he'll without running out of threads.
The other day I wrote an htmx extension for aws api. You could describe an element using the common htmx tag such as for confirmation, triggers etc, but the ajax fetched any aws object like ec2 instances, pipelines, whatever. It's awesome!
and it will just work with any params such as form inputs or hx-vals etc
the reason i haven't posted it yet is i want to find a good way of mapping parameters since the aws api can have some notoriously complicated parameter formats
I think HTMX makes alot of sense for content that is a bit static but still needs some update and interactivity. Im building a job site right now and using htmx for job postlistings, search etc. And liveview for logged in view of creating and managing job posts.
For those curious, here's some numbers for the last 6 weeks to put things into context:
- 4147 new stars
- 86 new contributors
- New contributors account for most of the commits and issues created which is a very strong sign of growth. Even in very popular projects, it is usually existing contributors that contribute most of the code.
we've had a new person come on the project who is focused on auditing PRs and getting the good ones in front of me, which helps a lot w/ getting new contributors in
This is a great project, and reminds me a lot of where folks saw hypertext going many years ago.
I have read a little of the website and picked through many of the online examples. One thing I did notice is the preference to update client state (DOM rewrites) based on server HTTP request responses containing full-blown markup. Does the HTMX framework provide concessions for client-side-only triggers and client generated content?
The reason why I ask is that an advantage of the current crop of JS heavy-client frameworks is they offload as much work to the browser as possible. This can result in less resource use on the server end (e.g. data, CPU), which is a big deal for web-scale apps. Is HTMX able to meet these kinds of engineering goals or is the project intended to do something different entirely? I totally get that something like a Facebook client is not at all hypermedia oriented, but folks are going to draw the comparison anyway.
however, I would encourage most folks to use HTML as the network format: it typically isn't much more CPU to generate the equivalent HTML string that corresponds to a JSON string (sometimes even less, as with tables)
for pure client-side, htmx is largely hands off. We support an `hx-on` attribute to address the fact that HTML doesn't support general `on*` attributes, but that's it
it does, however, emit a large number of events that you can hook into to extend things:
Another benefit of using HTML is ease of progressive enhancement. If the default behavior of the server is to render a full HTML page, anyone hitting that URL directly will get the full HTML from the server with no additional back-end work. Additionally, if JS is disabled in the browser, links still work as traditional links.
Mobile phones have less powerful CPUs. Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server (where you already have it loaded into memory anyway).
I always see these claims but isn't network the more limiting factor?
Or do people study this while thinking about IoT which may use more limited resources while still relying on the internet?
Especially since a server has to handle multiple request concurrently, it doesn't seem to be remotely the same workload that a single device CPU would see anyway?
I can't speak to any kind of general principle here, but viewing any standard modern web page e.g. Twitter, Discord in a Web browser reliably takes more CPU and memory than running a late-game Factorio save.
I will allow that it is probably theoretically possible to do client-side rendering in a CPU-efficient way, but it sure isn't the standard.
I'm not the GP but I'd say it's not "just" doing that render-blocking work on a single thread on a potentially under-powered mobile device, it's also introducing significant latency to fetch, parse and execute the code that will render to the DOM.
JavaScript is single-threaded, so whatever CPU work is going on will compete with the UI responsiveness. Even mobile apps, which run a dedicated thread for each, probably won't do one single clean UI update in response to the server-response.
It's not enough to be a novel approach. It also has to be demonstrably better from a performance standpoint, a developer experience standpoint, or arguably both.
Frameworks like SolidJS and Svelte simply got rid of the virtual DOM and reaped massive performance wins from it. I find it hard to believe that adding a worker and a virtual DOM back would end up making them faster. Quite the opposite in fact.
Then there's the dev experience. Would it be easier for a developer to work out what to do in a separate thread and post messages back into the UI thread? Seems like extra cognitive overhead to me.
Ideas are great. They move the state of the art forward. But if your idea doesn't comport with positive results from testing, it's not useful. Intriguing, to be sure, but not useful.
Very fair assessment, though not everyone is using, or will use, Svelte or Solid. Including people who are using htmx.
I meant to suggest that frameworks might be able to take this approach internally and make the DX transparent. I actually had a go at this using Mercury back in the day, but didn't have the motivation to finish it properly.
I just had a fresh read of the docs and htmx is refreshingly, gloriously simple--such a breath of fresh air. So natural, self-documenting, and well thought out. It _does_ feel like a natural extension of html.
To me, the only "missing" piece of htmx is a component model, but for anyone looking for that, htmx would pair amazingly well with Astro[1] which allows you to define and use html components without the runtime overhead of say Vue or React.
Not sure what you mean by html components. That's kind of missing the point of HTMX, no? Most backend frameworks like Django or templating engines like Jinja2 have the concept of blocks or fragments so its easy to render out component pieces to send back to the frontend. If you combine that with the OOB options in HTMX and/or the Hyperscript or Alpine libraries, then I'm not sure what you would gain by using Astro.
I mean, I just don’t think you should have to have Django for a simple website. Astro is an alternative to those backend frameworks. It’s a backend framework itself in many ways.
That's a great video explaining the core use-cases of htmx in 100 seconds. Would be great if all projects had such a thing! Htmx reminds me of tailwind in that you've created a set of attribute names and values that are picked up at runtime by a singular library. There's no front-end build required, which is a Very Big Deal for most devs who don't want (and shouldn't have to) to mess with npm and webpack. It looks like the "breaking point" for page size is something like a small SPA - when it gets to big, make another SPA.
Particularly for react/vue devs I think the thing they'll miss is the idea of a uniform, singular object representing global state that is rendered by a single function (defined hierarchically in your component codebase) into the UI. However, it must be accepted that this idea is very demanding in itself, resulting in lots of opinions and hurt feelings, and in addition comes with the weight of a front-end build (and all the confusing variation there).
I don't use it but I'm already a big fan. Congrats!
One minor thing. This is not an issue directly with htmx, but more on the backend. This always feels clumsy for me:
I land on the index page, and get the full site, then click on about page, and now htmx swaps the content for the about page. However if i refresh the url stays the same, but i now only get the content without the container.
I know this can be solved with checking for a htmx header, but i feel like "there must be a better way" like raymond httinger of python fame has said multiple times.
i typically have a middleware component that decides whether to render the "chrome" around a given response, so my controller methods aren't junked up with it
You make two skeleton templates: One for full documents, one that has nothing in it except the parts that change (say, the meta > title, the body > main and the body > header > nav parts) each wrapped in a hx-swap-oob.
In general, out of band swaps are really, really convenient for non-hierarchical layout relationships.
This can be solved by returning the full about page always, but swapping only the content part of in the index page by selecting which element to swap from the requested page. Htmx supports it
That's interesting. I discovered Unpoly after HTMX (which I like) and decided to stay with Unpoly for a few reasons. Do you think hypermedia libraries will converge or do you think there is space for different interpretations ?
i definitely think there is room for multiple implementations
unpoly is higher level than htmx, with different design sensibilities and concepts like 'layers' (https://unpoly.com/up.layer) which is something that doesn't make sense from htmx's "just extend HTML" perspective
Just wanted to say thank you for what you do. I've long been a fan of HATEOAS and I'm very happy that there's finally a movement towards it and ecosystem growing. Also, the memes are unparalleled.
Adam Stepinski, the creator of Hypreview, built it after his experience with intercooler.js, the predecessor to htmx. It is a very interesting piece of technology and, through the magic of HATEOAS, allows you to update your mobile app instantly for all your users, without dealing with the mobile store!
There is an entire section on Hyperview, written by Adam, in part three of our book:
Looks cool but it seems it requires React which makes it a lot more difficult to use than regular HTMX. Form the GitHub repo: “More importantly, the client is designed to be incorporated into an existing React Native project”
Do you think that at some point in the future, browsers could bundle in htmx or something similar, and that we could imagine web pages that have javascript disabled but with great interactivity due to htmx? This could perhaps be used as a security feature.
Thank you for all your hard work put into htmx and indeed promoting hypermedia driven applications!
Since htmx works by way of custom attributes, can you write a bit about a11y recommendations for developers using htmx? It would seem to me that a lot of things that we get from using standard attributes are lost, and we’d need to do more nuts-and-bolts type work with regards to dom structure and aria attributes. Or does the htmx engine deal with this to generate relevant aria attributes etc.? I couldn’t find any references to this in the documentation.
Hi, I've been skimming over your book. There might be a typo under [1], where you write: "An HTTP response to this htmx-driven request might look something like this", but then the next figure's header is "JSON"
As someone relatively new (few months in) to full-stack development, what can HTMX offer me? I've been semi interested since Prime mentioned it a handful of times, but I feel maybe I'm too new to fully understand what I gain from it. As soon as I'm finish with my current project, I'd like to check it out.
For reference, I'm currently working within the T3 Stack.
HTMX is just a convenient way of handling user-initiated UI updates AJAX calls (for whatever purpose). So instead of writing some JavaScript that looks for a specific element to attach an `onclick` event and subsequently makes an AJAX call then again searches for an element on the page to update with the result you can put some (very simple) HTMX code in the HTML directly and it'll handle that sort of thing automatically; "without having to think."
It's just a nice, convenient way of handling such things. The argument in the article is that "this is how HTML should've been from the start" because it lets you do some pretty sophisticated stuff just by adding some simple/intuitive attributes to the HTML.
So my apis need to return html specific to the page its called from with the data embedded? I guess my apis would need different endpoints that return json for other clients. And different endpoints for the exact same data if they need to be displayed differently? It just seems like a bad thing to couple. What about CSS? I guess you have to look at what the server returns to figure out how to select/style it.
I recognize thats how templates work but for some reason it seems weirder when applied to the element, rather than page level.
In there book, the authors specify that it is valid and normal to have additionnal endpoints for json. For exemple, Mastodon provide html endpoints as a interface for the user's browser, but also json endpoints for other clients (mobile app, cli tools, or others web app providing an alternative ui)
Stupid question, why doesn't htmx parse the response html and extract from that the relevant data out needs to fulfill the configuration? Feels a bit cumbersome to return the exact part of the response on server side, like the next page of the table, if it was requested with htmx, else return the full page.
This way htmx would be even easier to implement in any front-end.
Rails does this with Turbo Frames [1]. When clicking a link that is contained in a <turbo-frame> element, the frame is automatically replaced if the response contains a frame with the same ID.
How do you organize a backend for a htmx based frontend? Specifically getting templates that serve as reusable components, but also endpoints (there is some proliferation of endpoints which I remember from my days with ASP.NET MVC partials.
So you start by just re-sending the entire page but with content changed. Generally you'd use query parameters, like say you have a page with a table and you need to sort it. Add to your query parameters what order you want them in, re-render the whole page.
Then once you've got it figured out you just return the part of the template that you actually need to. Makes sense when you think of it as a progressive enhancement on a plain html page.
I don't think the bundle size will shrink too much, especially if we include the morph-style merge, which is somewhat complicated
yes, I think you could do a stripped down htmx that doesn't support a lot of the stuff htmx does, particularly life cycle events and more elaborate swapping mechanism
for example, most response headers could be just done as the HX-Trigger response header + some client side scripting
history support and form-value gathering is likewise a source of complexity and code that could be omitted or done less completely
Sounds like reasonable places to strip out stuff while keeping the fundamental features. I think the history support would be important enough to keep though.
Maybe stupid question, but what are the downstream implications for folks like Vercel/Netlify/etc. who bet the farm on complex server rendered JS pipelines?
i don't think there are major implications: the web development world is still very react/javascript/JSON-centric
there is no reason that they can't tweak their services to be more hypermedia friendly if and when this approach becomes more popular
netlify (which offers free hosting for https://htmx.org, so is a sponsor of the project) is very HTML/hypermedia friendly as far as I can tell, and I don't have enough experience w/ vercel to say much other than a vague sense that they are extremely react-oriented
no reason that can't change as the market changes though: hypermedia pushes the main value locus of applications back on the server side and so server-side companies should like that
Guillermo Rauch is the ceo of vercel. In this tweet, he's effectively saying that the bulk of what his company was built upon (SPAs) is bullshit (zero interest rate phenomenon is a reference to when financial interest rates are very low/zero, as they've been for many years, all sorts of things will seem great and successful because you can borrow money for free. When rates go up, only actually viable projects will survive - as we're seeing in the startup world now).
can htmx work for restful backend that requires client side rendering and routing? my understanding is that htmx only fits for server side rendering such as Django.
HTMX pulls text from your backend, so normally folks serve HTML snippets... but you could have a bit of js that takes JSON and turns it into HTML in the browser, and HTMX will pull the JSON (or any other text) into the browser, so you could still use it with a JSON api, if you wanted to
I use DRFs renderrers so my Django backend can render either JSON or HTML, so my API is still "restful", it just serves HTML to clients that request HTML like browsers with HTMX and JSON to other clients that request JSON.
interesting,using DRF for json and Django for html at the same time for browser and nonbroswer clients.
my use case is embedded systems that can typically do client side rendering in browsers, the only server side rendering I can afford is some simple lua or c/c++ mvc alike backend,Django is too 'fat' on resources. there are some of them but none that is great and actively maintained as far as I know.
You mean "This just won't die"? Because it seems to me that Web Components are here to stay, especially since something like htmx boosts their functionality with absolutely minimal added cognitive load.
I feel that, pretty soon, the choices for a full-functioned web application that is easy to maintain with high development velocity is going to be:
1. Master HTMX and Web components in a day, and be productive
Or
2. Spend a month learning React, and still get hit by all the footguns.
Thank you, reading now - do genuinely want to know. I understand how my message came across, but I do intentionally reflect how many attempts there have been to change the paradigm so far.
Not a valid excuse, dude. You have every right to be skeptical or to avoid "bleeding edge" but to assume the whole thing is just a front to raise someone's speaking/blogging/social media profile, to buzz in from nowhere and start off by declaring that it's going to "die" is not the way to act if you "genuinely want to know."
Recursivedoubts has legitimately demonstrated he's not a one-trick pony (previously built intercooler, concurrently building hyperscript) and he deals with skeptics like yourself dozens of times every time an HTMX article gets posted on this site (which all seem to go to #1, if that serves as an indicator of the library's popularity). He handles himself with grace and patience and humor, far better than most of us would do.
You don't even state what your "current approach" happens to be in order for him, or anyone else, to provide you with a satisfactory answer.
no problem, i try not to take things personally online: i've said plenty of things that either were mean or came across as mean in my life, especially when I was younger
i think one of the strengths of htmx is that it isn't really trying to change the paradigm to something brand new, it is instead going back to the original web paradigm of hypermedia and asking how HTML could have advanced within that paradigm, in contrast with the SPA paradigm that replaced it
so less of a wild bet, with more known advantages and disadvantages
I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR.
Once htmx clicks for you, you are almost left stunned by how simple and flexible it is. You can't believe that this isn't how HTML evolved to as a hypermedia. It becomes very obvious that this is how web development should have evolved. I hope someday that what htmx is doing through javascript becomes baked right into HTML and the browser clients.
If you are mistakenly believing it is just some derivative of Angular or you are not grasping the significance of its advancement of the architecture of hypermedia, please do yourself a favor and read the excellent essays on their site; you will then truly understand what REST is and what the importance of real HATEOAS means: https://htmx.org/essays/
We made a costly wrong turn 10 -15 years ago by attempting to rebuild thick clients on the web with a JSON API architecture instead of expanding and enriching the new and powerful idea of the early web: hypermedia.
> It becomes very obvious that this is how web development should have evolved.
I have to disagree with that. I’m happy htmx exists and that it works for many but in my professional life I've found few cases where it's the best choice. And that’s fine! It’s a wonderful thing that the web has been able to grow in so many diverse ways, there should be no one way it “should have evolved”.
IMO this is the biggest mistake in web dev in the last decade or so: that there should be One Right Way. No matter if you’re making the next Gmail or if you’re making a static blog the cargo cult of an industry tells you it should all be done the same way when common sense would tell you that’s not the case at all.
I fully agree with you. I'm a fan of htmx, can recommend it and have used it in some projects by now. But...
For one, htmx is not a full solution to avoid JS. It's excellent for the parts that are AJAX/CRUD, which certainly covers a lot of ground. You still need something more if you're doing stuff that doesn't fit here like interactive visualizations and many other use cases. However, it integrates very well with other lightweight libraries.
Secondly, htmx is great if you're developing full-stack (like GP). Meaning you touch every part of a site from the data model to coordinating messages to the frontend etc. If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. IMO there are plenty of good reasons to do either.
Third, and this is a bit of a combination of the first two points, if you directly fetch data from a third party, say a JSON API, then htmx doesn't help you at all.
So really as you said, there is no one right way. For me it has been working very well though. People should look into it for sure though. There's an opportunity to combine htmx with orthogonal libraries that do the dynamic parts like lit etc.
> If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool.
The point to take away from htmx and hypermedia more broadly is that there isn't a clean separation between the front end and back end of a site. The concept of completely separate front and back end teams building SPAs/JSON APIs has been a very costly development that has brought substantial complexity that is wholly unnecessary for most applications.
Your banking/project management/todo list/budgeting/insurance/education/whatever app almost certainly doesn't need to be an SPA and would be developed faster or for less money if it leaned into server side rendering (SSR) and used a library like htmx or Stimulus to enhance the user experience as needed.
That's fair. I agree - that type of blanket statement is not helpful in the technical realm. I should have kept it at just: HTML should have continued to be expanded into what htmx is doing.
I'm kind of guessing / reading into their comment here but. Using htmx doesn't give me the feeling of "this is the only way I ever want to do this" but more "if html worked like this I wouldn't use js most of the time." The sense that an opportunity was missed and now we're paying for it in complexity.
1. Server-side rendered sites in Python using either Django or FastAPI/Jinja2 and htmx;
2. Dotnet back end with Angular front end.
In practice - for the apps I've been involved with - option (1) provides a more than acceptable user experience. There's no doubt Angular can go beyond the capabilities of SSR+htmx. But, in practice, it's in the long tail. Throw in the odd js lib, e.g. for charting, and option (1) is good enough for the vast majority of things.
The complexity is not comparable: (1) is much simpler. For a start, all logic is in one language. There's no separate build for the front end and back end; no need to reconcile state in a front end cache with the back end. There's no need to export every view as a REST API; it's a native function that gets called from the view handling function.
Others will have different experience: I'm not saying this is universal. But in my experience, objectively, it's not true that the complexity moves from js to htmx. At least, not if that implies the complexity is equivalent. It's just not the case.
Not sure you've solved the complexity when you've just slotted in another front to a general solution that is over-engineered. You could have replaced either scenarios with a single NextJS or SvelteKit solution. Go above and beyond in "complexity", write your Node backend (keeping it one language, JavaScript), and use vanilla HTML and JS to consume that.
To me, htmx isn't as revolutionary as people make it out to be, and possibly that's due to the fact I'm just not burdened by the old days of gigantic Angular apps and massive ASP.Net stacks. My history was mostly JQuery where needed (which was all the time before JS got its act together).
The difference is those were already tools we were using. You _(hypothetically?)_ can't eliminate the complexity of dynamic apps without limiting flexibility. However you can move the complexity in-band, to a domain you are already using and preferring.
Plus, if it's done right, you can get a lot of functionality while remaining No-JS friendly.
> With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language.
Can you elaborate on what you mean by this? Front-end framework don't care what language back-end logic is written in. For example, I have a Vue/Vite site that calls back-end functions that I'm gradually migrating from one language to another, and no front-end changes have been required.
Much of your business logic can live in the backend, and it keeps your frontend really tiny. The idea is to generate HTML on the backend, instead of using a front-end framework to generate HTML on the client from an API call.
You can also do the same in Node if you want to, I currently have a TS website that is mostly templated HTML in production (without htmx). Htmx would be perfect for that site.
> Much of your business logic can live in the backend, and it keeps your frontend really tiny.
Ah, so "with htmx you can use any language" is true because its users are no longer using a programming language per se for the front-end, but instead are defining logic with htmx's DSL?
Yes but vue is far more involved than htmx though. Vue has its own way of architecturing your project. htmx is closer to a progressive enhancement of html
I see it as much more, many things can be stripped out altogether. Client-side state management. Client-side input validation. Fallbacks for when data hasn't been loaded yet. Less async-based code, less coordination-required and event-driven code (this stuff happens but much easier and often code-free with HTMX).
Its not a fit for every site or use case but more than any other front-end tool or library or framework, it has enabled me to actually realize the UI concepts in my head to the actual screen, and usually a lot quicker than I'd expect.
So you only do input validation on submit? Isn’t that user hostile?
This is what I don’t get about HTMX, you can’t give a good experience without client-side JS, sure some developers might love it, but that shouldn’t be the yardstick.
Not hostile at all, and we arent degrading the user experience -- much improving it, in my opinion. With HTMX you can do real-time validation on each input element on the server and provide instant visual cues to the user anytime one fails. https://htmx.org/examples/inline-validation/
Moreover, HTMX makes it incredibly easy to change the whole paradigm of submitting data. You can eliminate some forms entirely and just enable a series of individual questions/inputs/selects one at a time, especially useful when a single static form isn't always appropriate (multiple pathways, questions/options that are contingent on the response to a previous question, etc).
In my experience the UI flow and degree of detail for avoiding common errors is greatly improved.
Disagree that it’s good UX. Now the user only gets feedback when they lose focus on the field, forcing them to go back and refocus it. In conventional React they get feedback on each keystroke allowing errors to be fixed while the field is still focused.
So when the person is starting to enter an email address, the page goes red until he enters the .com at the end? He gets an error for the first 9 digits of a phone number? Do you implement debouncing?
My frontend experience predates the rise of react etc. I have used jquery.
The advantage of htmx over jquery is declaring the replace condition & behavior inline as part of the component. Conceptually this is easy to reckon with as a separation of concerns thing as well as a sandi metz-ish "when would this code need to be changed" thing. The html tag is responsible for its own update, and so its update is part of the html tag.
Jquery does the same things but requires you to declare the behavior separately from the component, decide on & maintain abstractions and reuse patterns. And manage code organization so that for any updatable template code you can find the corresponding behavior declarations and understand their scope w/r/t other template code.
Most of my experience using jQuery was on sites that required progressive enhancement, and the easiest way to do that was to create an htmx-style framework anyway.
I think the biggest change from jQuery flows is that the behavior is attached to the elements themselves instead of a script over here poking at the dom from the outside.
>You can't believe that this isn't how HTML evolved to as a hypermedia.
That is why I wish HTMX to be merged into HTML5 spec. For something like 98%+ of the web it will be good enough. You then have a small JS library for the other 1.9%.
What are technical differences between HTMX and early versions of Angular 1? It has the same idea of sprinkling some attributes over HTML to make it dynamic for easy cases. There were many frameworks that started like this (Angular 1, Vue, etc), and after getting some traction they grew into full-blown SPA frameworks, because there is a real need for more difficult cases.
If I had to pick an “Angular-1-like” framework, I would pick the one that clearly documents it’s boundaries and provides a clear way to use a mature SPA framework when there is a need to cross those boundaries. If anyone is aware of such framework, please share.
htmx uses hypermedia, rather than client-side managed state
as much as possible, htmx tries to take HTML to its logical conclusion (from my perspective) as a hypermedia, rather than imposing other ideas on top of it
You keep using the term hypermedia and I'm not certain what is meant by that term (I was thinking it referred to linked media). Hyper means over, right? So is hypermedia more about the environment media is in than it is about links?
yes, I prefer the term hypermedia over hypertext because it stresses the systemic nature of a hypermedia system: a hypermedia (e.g. HTML, a hypertext), a hypermedia client (e.g. a web browser), a hypermedia protocol (e.g. HTTP) and hypermedia servers.
As far as what the term _hypermedia_ means: it is a media, such as a text, that includes within it _hypermedia controls_. Those hypermedia controls allow non-linear branching and interactions with the media, hence the term _hyper_, that is, above, "normal" media, which is consumed passively.
The hypermedia controls we are all most familiar with are anchors/links & and form tags. htmx attempts to generalize the concept of a hypermedia control.
The book goes into gory detail if you are interested in further exploring the idea.
Out of curiosity, I presume you were working on the frontend part using Clojurescript? Have you used some kind of wrappers around htmx or just a simple js interop was enough?
We moved away from ClojureScript entirely. We just run a plain ole java uberjar with the Clojure/ring/hiccup/Compojure spitting out the HTML with whatever htmx attributes and response headers we need. There are instances where we may need to sprinkle in some javascript for some extra dynamic things - which turns out to be very infrequent. Instead of sprinkling in the javascript, we have been using _hyperscript instead - love _hyperscript.
Yeah, so moving to htmx has allowed us to jettison ClojureScript which just entailed too many parts. As a matter of fact, before going more htmx with our projects, we had moved away from ClojureScript to React directly.
I am happy with HTMX for my RSS reader. The issue with front end apps is, and always has been, the complexity of updating the UI after a user makes a change.
For instance, inside an HTMX application, I just coded up a plain ordinary <script> (no framework, no build system) that displays a count of how many characters are in a text field and also disables or enables a submit button according to that size. It's 9 lines of code plus an attribute on the input. It might be less if I did it in
Immediately it faces the problem that there are two paths: (1) the initial setting of the length display (the field is pre-populated with text, I ended up setting it in the SSR) and (2) what happens when the text content changes.
If you use signals or hooks or useEvent or lifecycle methods or whatever you always see a certain amount of awkwardness that stems from the above.
Note I could have done the above with "pure HTMX" in that I could have had the event handler trigger a server round trip that repaints the text field and the submit button, it wouldn't be as bad as it sounds in performance, but boy it seems like a waste.
I've built applications that were a lot like Figma, Photoshop, or Eclipse, where the user could update some data and it could have very arbitrary effects on the UI because the user is able to add and remove many different UI elements and in a case like that you need some system that can manage dependencies at runtime.
React has revolutionized how people build widget-based frameworks, there is never going to be anything like Tk, Cocoa, GTK, WPF, Spring, JavaFX ever again, or if it is it is going to be influenced by React. There's the awkward fact that React is overkill for the typical form processing and e-Publishing applications people write with it but it is not up to the task (without an additional state management frameworm) of applications like Figma.
Personally I'd like to see a mostly declarative form processing framework with a sprinkle of scripting: before there was the iPhone there was WAP
(one of the most visionary books of all time... the authors built an enterprise software development framework for Microsoft that was nowhere near as cool as their vision)
or a "no-code" app builder could be great.
I'm still trying to get my head around websockets. I've built some small demos that are awesome, like a program that controls the volume of my smart speakers and has the sliders move when I change the volume with the remote control. I really wish my RSS reader could update my "favorites" window as soon as I add a favorite in another window, but doing that efficiently requires answering questions all the way from the front end to the back end to the database. I'll probably find a half-baked way to do it but it's sad that I'm settling on a web application to have the limitations web applications had 15 years ago.
Very happy for the recent attention and "success". Also enjoying the shitposting and backlash mostly from the front-end crowd who believe the Web was invented in 2013 and they "made that city". :)
I'm biased since the time Backbone.js came around, I understood part of the pain but was moderately skeptical, fast forward to React with the young energetic bros building dead simple 5 page websites with a Rube Goldberg setup of front-end frameworks, I've cashed out my tech chips and never touched those things.
Many of the ideas and concepts in htmx are things we worked on starting around 2012 at a top tier investment bank. Implementation details differ quite significantly, but the idea of hypermedia driven applications was core to everything we did.
We unfortunately weren't able to win hearts and minds around these concepts in the long run, and blog driven development (a.k.a. cargo culting) replaced our efforts. I feel somewhat redeemed now that HTMX seems to increase in popularity, it's nice to see that we weren't alone in thinking along these concepts.
Of course, if the concepts were strong that implies my execution wasn't, so maybe I shouldn't feel so good about it after all... :o)
This was a time when people were shouting "separation of concerns" without really understanding what that meant. Mixing the html/css/js required to make up one discreet UI concern? Heresy! Requiring at least three files to describe a discreet UI concern? TheOneTrueWay!
I remember the issue to be also that managing UI state on the server side was a load issue that many places didn’t want to deal with (e.g. Wicket, etc). The vibe at the time JS client apps came out in my circles was "thank God we can get rid of this UI stuff."
That’s still an issue I have with HTMX, but I understand for simple use cases it’s fine. I’d rather use HTMX than JQuery that’s for sure.
Or your marketing might not have been the best possibly, or people didn't spend enough time with alternative approaches to appreciate their downsides and why hypermedia based solutions could be better. (Just pointing out other possibilities because I don't know if it's a good idea to be hard on oneself when one isn't sure about what went wrong.)
These were internally developed tools, so nothing we really marketed externally but yes we definitely could have done a better job at our marketing within the organization. A lot of the criticism to our approach was typically not so much that the ideas were bad, but that they were "different from how everyone else does it" and by everyone else they typically meant Facebook and Google.
For example, global state management approaches like Redux were more or less incompatible with how we approached state management. We thought it was insane to build apps around the idea of global state stores (and I still do) but Redux became all the rage and eventually won the day. There was a lot of collateral damage as people then tried to shoehorn Redux everywhere. I left around that time, but hear that the cycle have repeated a few times since. Redux (and other tooling) didn't work out as expected so wheels have been invented again over and over. It's the way things go I guess, I don't dwell too much on it.
We probably could've done a better job at communicating why our approach was better, but ultimately we had limited ability to force anyone to use our tooling. There's also a hiring aspect in there. As Redux and other libraries that were "the thing" started to make their way into job descriptions it became harder and harder to convince talent that they should join us, because we didn't have that brand recognition and used in-house tooling. At some point you have to make trade offs and sadly top tier financial institutions aren't necessarily known for leading the pack in terms of innovation. It's kind of sad really.
Anyway I'm not particularly hard on myself or bitter about it at all actually. The self deprecating jab about poor execution should be read as tounge-in-cheek really, I'm very proud of the work we did back then.
A good idea or a good product are never enough. You have to sell the product in order to have it be successful.
In your situation, you were at a bank, so your TAM was roughly 1 enterprise (or maybe a dozen, tops, if divisions had federated or siloed tech). And your 1-to-a-handful of potential customers were probably of the large and difficult to change variety. That's a huge constraint, and not landing it there doesn't mean your idea was bad, it just means you weren't successful in selling it and I'm going to tell you that you probably _couldn't_ have been successful in selling it where you were, when you were there. I worked for your lazy cousins at the same time - big insurance - and had the same issues selling my own ideas internally, if that makes you feel any better.
HTMX has no such constraints. It's a decade later and the TAM is more or less everyone doing or preferring to do SSR. The same/similar good idea, but different place and time.
React didn't get much adoption initially and FB didn't spend money on marketing their framework, like Google did with Angular. Developers started using React to speed-up table rendering in Angular application, and only after some performance-related blogposts adoption started to grow.
Absolutely, brand recognition is hugely important in whether something's a success. It can also go the other way, great ideas and tooling simply die because the brand is tainted.
Not everything Microsoft has produced is terrible, but for a while there it seemed all developers I knew couldn't see past the brand even if the tooling/products/ideas were solid. I feel it's gotten better since Nadella took the reins, but the smell still seem to linger sometimes.
I agree - I'm a greybeard, so it's a bit of a bizarre world to me where Microsoft is actually a lovely, valued open source brand and probably the most ethical (depending on your definition) of all the big tech companies these days.
Time to go snow skiing in hell, I guess. It's deeply frozen over.
I'd give Microsoft more of a chance, but the way updates and the UI are handled in Windows really puts a sour taste in my mouth. I've heard many good things about stuff like WSL2, PowerShell, and other things that can make Windows feel more accessible for power users, but I'm still looking at a Windows 7 machine without a TPM. I'll be able to update to W10, but after that I'm hosed and have no choice but to 'upgrade' to a chip that has a nanny CPU in it.
If Microsoft provided a Developer's Edition of Windows -- without telemetry and ads -- that also came with access to a knowledge-base of best practices for Windows-based software, and why you want to use each major Windows component, for a flat, one-time fee, I'd strongly consider building things for that environment.
I feel like Microsoft's current approach of buying their way under the free software world via GitHub is kinda scummy, and all that code's now under Copilot and other LLMs. If they were a bit more upstanding and had a clean, mutually respectful business model, I might consider buying their products.
In the mean time, I'd rather use something written by a random hacker, because I can at least read their code, or even hit them up and have a conversation about their project.
I agree. I think what we're seeing is investment risk assessment as a proxy for a deep understanding in technology. After all, if you don't know how anything works, all you can do is look to what _has_ worked for you and other investors in the past.
I'm guessing here, but it's plausible that once a given stack has proven to make money, the fix is in. It wouldn't matter if it's the best choice out there or not. The track record itself makes it more attractive. Example: Ruby on Rails.
This is a fun semantic game. You can also tell them it uses a Von Neumann architecture and also 8 bit bytes. Or how about it uses Linux, or the latest Linux 6.5-rc6?
Haha, software has more seasons than the fashion industry. If you observe it for long enough everything seems somewhat derivative. But I wouldnt want it any other way. All diversions are welcomed within the choices of those working within the choices of those before us.
I enjoyed building webapps with Backbone, it was rich web applications that felt like true apps instead of trying to make parts of a site more dynamic using jquery. It was a clean separation between front- and back-end.
But Backbone was a bit sloppy, not very enterprisey, until Angular came around.
Anyway, this string of web applications became popular (in my world) because it meant that we could separate back-end from front-end, and have one back-end (usually REST/JSON) fueling mobile and web clients separately. That was it, that was why we built SPA's, but by now that has been forgotten again.
And in my world, it made sense because the apps were behind a login. But then They wanted to make SPA's facing the internet, for things like webshops. And I get that too; I've made a few websites using Gatsby, they're crazy fast for navigating AND still indexed by search engines.
Anyway, in some cases it did get more and more complicated, then with server-side React and the like. I never had to touch that, thankfully.
:) I appreciate you being a long time user and I certainly do a lot of s-word posting on the ol' twitters
on the other hand, my hope is that eventually htmx (and, more generally, hypermedia) is accepted as a tool, a useful too, but just a tool, even by the front-end folks who haven't thought very much about hypermedia in a while
i don't see the two approaches as mutually exclusive and agree w/ Rich Harris' concept of 'Transitional' web applications that mix the two approaches. I would just draw the line where you abandon hypermedia for a more elaborate client side approach in a different place than him.
I was recounting the past. I'm sure it is "diverse" ( whatever that means ) now because it became kind of a industry standard for front-ends.
Good to see diversity all around, I just wish there also would be diversity of thought and it comes to building web pages. But I guess that would lead to people admitting ~80% of all the stuff they build does not require React or equivalent js frameworks and that would be both an ego and economic/résumé problem..
I inferred that the intent was to say that not all people using React fit into one category.
> ~80% of all the stuff they build does not require React or equivalent js frameworks
I'm well aware of this for some portion of the things I build, but I don't agree that these frameworks are generally unnecessary or not preferable. It's also hard to say when something "requires" these tools or not. Arguably you could say nothing requires them these days.
I like to build with all kinds of tools though, and React and Vue are for example are often more helpful than harmful to my development experience. I'm speaking as someone who has been building things for the internet for around 20 years, so I remember life without these tools.
> that would be both an ego and economic/résumé problem
Maybe. I think this might be more true in roles that are closer to entry level, though.
edit:
From your previous comment,
> fast forward to React with the young energetic bros building dead simple 5 page websites with a Rube Goldberg setup of front-end frameworks
This is a good point. It's still a thing and will probably never go away, regardless of which frameworks we have. I think it stems from people fundamentally misunderstanding our core web technologies and not realizing how easy it is to do what they're doing without React or Next or Nuxt or what have you.
In many cases I've worked with people who wanted to do the most trivial things in their UIs and they worked tirelessly and earnestly to implement it with React or Vue, but it was something that already exists in the Web API or HTML elements. Basic stuff like reinventing checkboxes. Or reinventing the button element by styling an anchor and altering its behaviour with JavaScript to submit a form. So many younger people have started their careers in web development on frameworks, and they genuinely don't understand how the fundamentals work.
It's an industry standard for people who like React. It's really that simple. This idea that they are so dominant and everyone is forced to use it is complete hogwash. JQuery and Wordpress still dominate the web completely.
I started with Perl in ‘96 and have lived through what feels like everything — PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL, and NextJS. Htmx feels like a divergence from the trend, and is worth thinking about.
Htmx asks us a good question: “does the complexity of your work reside essentially on the server or essentially on the client?”
The complexity for the vast majority of websites resides essentially on the server. Most of us are not building Figmas and Google Sheets. Most websites, even if heavily interactive, are just CRUD apps with pleasant interfaces. Frameworks like NextJS attempt to rectify the problem of overly complex clients by moving React to the server, but this often magnifies complexity rather than minimizing it.
Wouldn’t it make sense to remove React from the stack? For complex clients, skip the DOM and JS with canvas and compiled web assembly. For complex servers, use some form of server-driven granular updates to the DOM.
The problem I see with this approach is that although most complexity reside on the server for most websites, there are almost always a few high-complexity task that needs to reside on the client — image editing, real-time sorting/filtering/calculation, drag-touch gestures, etc.
A hybrid approach is necessary. It isn’t good enough to allow compatibility. Although htmx and React can be used on the same web page, they need to be kept in isolation. But I’m not looking for isolation; I’m looking for fundamental integration.
My ideal framework would allow for reactive granular updates to the DOM while also being tightly integrated with compiled web assembly powering complex client operations. I’d write all my code in a powerful language rather than JavaScript. My debugger would operate on both server and client because the difference between the two has disappeared. It would be true full-stack development — a single-stack application (SSA)
Clojure + ClojureScript comes close to being an SSA, but only superficially.
If ever there was a killer framework for Common Lisp, I think an SSA fits the bill.
This approach is consistent with htmx and friends, and we're using it on an htmx project with simple vanilla JS for the pieces of interactivity. For small and medium projects and a small team, this can be enough, and it's a breath of fresh air to be able open up dev tools, point to part of a page, and understand everything there just by looking at the html and small snips of JS.
> A hybrid approach is necessary. It isn’t good enough to allow compatibility. Although htmx and React can be used on the same web page, they need to be kept in isolation. But I’m not looking for isolation; I’m looking for fundamental integration.
Blazor United promises this hybrid approach. You code in C# in one way regardless of server or client. On first page load it renders everything from server-side. Then webassembly gradually takes over and it starts loading C# code on the client to speed up UI interactions that don't require server side data.
It works well but their current challenge is reducing webassembly files size which is about multiple MBs.
Other than not moving away from Javascript, don't React Server Components mostly do what you describe here? A single stack, with both server side logic and client side interactivity?
Congratulations! I had a fun time making a little project with Htmx, though ultimately went with something else as I ended up heavily using a openlayers, and map libs are notoriously heavy with clientside javascript and Svelte ended up being a better tool for the job.
I plan on using it again for a future Golang project and look forward to following it's development. If you're in need of a simple/medium complex front end for your app, and _especially_ if you're already using template fragments[0], I really recommend giving HTMX a shot. It's pretty fun to work with coming from Javascriptland.
Also, the guy who runs their Twitter account[1] is hilarious.
I’ve had good luck combining HTMX with D3.js but I’ve treated D3.js visualizations as “just another HTML element” with any particularly complex interaction with the rest of the site.
I've a hard time taking htmx serious for building a modern web app/site. It makes is impossible to build features that users have come to expect:
* Faceted search with configurable filters, like filter date on before, between or after, but only show the filter if the user wants it.
* Configure result view with different columns or even different views like maps or drawing something on a canvas like charts. You can maybe do some of this stuff with htmx but at some point you'll just need the json.
Even Angular can do this, and with something like SolidJS it is actually a pleasant thing to do.
A JSON api can be re-used by other apps while htmx feels like someone reinvented Thymeleaf
You can check this talk out https://youtu.be/3GObi93tjZI I was thinking the same but in the video they specifically talk about faceted search and how they did it with htmx.
For the second part you probably go with your own javascript or get away with hyperscript
That is the talk I've watched before coming to the above conclusion. The faceted search demonstrated in the talk is still an order of magnitude simpler then what I have build. It is still a cool example of what you can do with htmx and it certainly pushes the envelope but the UX choices are dictated by what is possible in htmx. I also think that the talk is somewhat dishonest, it is by a backend developer that want to keep writing Django while I would suggest replacing that with Postgrest. I estimate that what is shown here can be done with 500 to a 1000 lines of SolidJS for the entire app.
> what is shown here can be done with 500 to a 1000 lines of SolidJS
If you replace a 22,000 LOC React + Python app with 1,000 LOC of whatever framework you choose, I would be very, very, very, very impressed. I don't believe you.
Impossible is a strong word. I've looked at their API and I can certainly imagine ways to do everything you list above in HTMX. I would need to build and use it in anger to know if it's a good way to do so but I can imagine scenarios where it definitely is.
The point about a JSON API is a good point and if you need a public API then you should probably factor that into your decision making but not everything has this constraint.
In a well-designed system, these two are not mutually exclusive but simply two facets of the same request pipeline. The JSON API simply serializes the model as JSON.
The HTMX-specifc API applies a template/transform over the model and returns HTML instead. If one thinks of hypertext as another serialization target, it's easy to see how one would easily be able to serve both JSON for pure APIs and hypertext for HTMX.
Oh definitely. You could control it with the `Accept: text/html` http header too so you can use the same endpoint. But as I said, you need to take that into consideration if you adopt htmx.
On the topic of filtering, this is literally something I tend to do only client side anymore, unless it is something where the size of the payload matters. Even smartphones don't have any issue with search through tables with a thousand lines.
So for such things I would give the user a very broad set of data via htmx and then allow for further (realtime) filtering via JS.
If I want them to be able to search through data that isn't displayed initially I just deliver it with a hidden css class and remove that class if it is searched for.
Htmx, like any technology, is very well suited for a certain set of problems — iif you don't try to make it do tricks it is not good at, you should be fine.
Depends on the framework and what you're using to render the html with. For example, in PHP Swytch Framework, you can just `$this->rerender($state)` in an api response.
The twists and turns my career has taken had me pretty much skip the whole front-end JavaScript framework wars so it's nice to see "plain old HTML" make an enhanced comeback.
That's a shame, and bad use of htmx, these examples shouldn't be showcase examples.
It takes careful but not extraordinate thinking to think of ways to get consistent results with or without JavaScript turned on. Indeed, when a visitor hits a site for the first time they get the full response so everything for a graceful degradation should already be there to use. If I can figure it out, I'm sure big CS brains can.
Yes but for your own projects you could have a first page with a "no JS" div and attach a HTMX load request. That's how I did my first HTMX project and it works well informing you to turn on JS.
I think we need an impressive "made with htmx" example that will trail blaze an new class of web experiences.
People have typecast htmx as something to use for simple use cases that dont "warrant" getting out the serious guns. There is something to that, but it is limiting. Htmx and related 'back-to-the-server' approaches are a distinct category that could have been explored much earlier but for various reasons isnt
I think you misunderstand HTMX. It’s the revival of an old class of apps in a backend agnostic way.
It’s not doing anything new, or anything that warrants a “new class of apps.”
It’s a way to build hypermedia (read: content) focused sites.
Classic sites like shopping catalogs, forums, admin front ends, blogs, etc.
It’s just jquery/liveview/turbolinks, but backend agnostic and without needing you to maintain much (or any) frontend js logic.
Once you need heavy interactivity (think google docs or figma) it stops providing much benefit.
The problem with that is you need (one of many) server-side options to respond to the events... you could do a TodoMVC HTMX front end, but what would you use for the backend to work with it? Go, C#, Rust and a handful of others seem like pretty natural options, but as with all things, YMMV.
I mention C# in that ASP.Net MVC + Razor seems like a very clean match to the HTMX paradigm.
Not affiliated with them in any way, but it's made with htmx and some JS for more complex features
As for "new class of web experiences", given that htmx explicitly aims to expand upon what is considered the Old Good approach, not sure if it can provide that
I like the look of htmx at first but then when I want to do something where I would usually reach for JavaScript (vanilla or framework), such as a dropdown button, I inevitably consider hyperscript and then I see an example like "<div class="dropdown"
_="on mouseenter toggle .is-active on me until mouseleave">" and decide I don't like having sentences in code like that and I move on to something else.
Maybe I should give htmx a go without hyperscript or maybe I should give hyperscript more time. But on anything that I'm expecting to be maintaining for years it's just too unfamiliar and I don't want to be stuck with it if I wind up never using it again.
I am fully on board with htmx but hyperscript doesn't necessarily interest me. The htmx side doesn't care even one bit what client-side interactivity you use at all, so it's not really material to whether htmx can be useful for you. Personally, if I am trying to keep JS build tools and stuff out of the equation I'll go with htmx + Alpine.js.
I was helping with an application that used htmx and had two issues. I’m wondering if anybody had similar experience and if these issues are from misusing technology or maybe there’s some ongoing work to address them.
1. A lot of custom middleware in controllers to decide if endpoint should return HTML for whole page or only fragment that htmx needs. On the side of htmx that sounds simple but it is something that probably every project using htmx have to reinvent.
2. Bookkeeping around `hx-trigger`. If UI is getting complicated, many elements need to react to external changes. Instead of reading some state and hope that framework will schedule updates, I have to manage a list of events to react by hand.
I did a lot of sideprojects in Knockout and one large one in Angularjs 1.
I feel all the frontend frameworks need to talk about what they see the problems are and decide how to fix them.
I would like some solid foundations and avoidance of common pain and gotchas of scale and complexity.
My old sideprojects are broken because I didn't fix library versions. My JSBIN sqlite file with my knockout projects in is also in an unknown version of JSBIN which latest JSBIN doesn't work with.
The speed that frontend development moves has broken lots of my code.
This is great news. It's an unfortunate fact, but the validation of htmx simply by its inclusion in the GitHub OpenSource Accelerator may unstick some folks that were on the fence about its "legs"; not its utlity as such, but more about its safety for adoption. Nobody wants to be fired for selecting a library that may just go away. It's a very good library and it (and things like Turbo) are incredibly useful when developing canvases that slot into SFDC with the least amount of friction, allowing you to simplify interactions between SFDC and your back-end systems, where those systems themselves depend on SFDC data.
There are many applications where htmlx is objectively the best tool. But i really hate all the hype around it and people pushing it as react replacement.
Had an heated debate with someone that was really angry at everything react, for good reasons, but being oblivious that htmx can't replace client side logic. React hype + backend crowd I guess.
as a primarily backend dev I really don't see the appeal here. So now I need to make endpoints for every little UI element that I want to be updated by user interactions? And somehow keep it styled and matching all of the UI elements rendered on the frontend? No thanks, I'll just give you data and you can present it however you please.
> So now I need to make endpoints for every little UI element that I want to be updated by user interactions?
No. Htmx supports extracting a subset of received HTML and merging it with the current page.
So, for a typical form, you _could_ do a request to validate the entire form then extract the relevant error message for the input field that triggered said request.
This would re-use most code of the actual form submit endpoint except it _only_ does the validation.
> And somehow keep it styled and matching all of the UI elements rendered on the frontend?
When using Htmx, the backend would typically own the frontend. So the styles and UI elements are already "matched" as it were.
> No thanks, I'll just give you data and you can present it however you please.
This makes sense when there are multiple frontends and/or consumers of the API. When there is exactly one API consumer, and that API consumer is the frontend, Htmx can save a lot of time by reducing the overall complexity of the project.
> So now I need to make endpoints for every little UI element that I want to be updated by user interactions?
What's the alternative?
You want interactivity that users can trigger. You'd need to call an endpoint in some way or another, giving you updated data, no?
> And somehow keep it styled and matching all of the UI elements rendered on the frontend?
Wait, how are your other UI elements rendered? How are they styled?
Somewhere in your code, you'll have a step where you generate HTML with CSS classes. It's popular to use React for this step, or some form of SSR where you render HTML templates.
With HTMX, you can simply reuse the same backend SSR templates that you were already using, and extract some parts of it which you want to be interactive.
These will be rendered whenever you trigger an action, by HTMX fetching that part of the template.
If you want to strictly split frontend and backend development for some reason, you can totally do it: You'd have a business logic layer that provides data to the view layer within your app (be it JSON, or POJOs), and the frontend team styles that data in the view layer however they please.
And the benefit is that you'd all render it on the server. No need for the client's browser to do anything anymore. It's all coming pre-rendered, cacheable and indexable. Done.
Most applications that would leverage this (e.g. server-side rendered Rails or Laravel or Django) already have those templates as partials for their views, so leveraging the functionality is trivial.
I think there is definitely a place for “unobtrusive JS” “HTML over the wire” framework. But it should have a clear path for upgrading to conventional SPA stack where needed. Maybe the upcoming Next.JS replacement will have SPA part as optional and will be “unobtrusive JS” “HTML over the wire” by default.
For first-time-devs, configuring + understandings development environments is usually 10 times more daunting than "learning to code". With respect to Typescript, NPM, Webpack, React, transpiling, sourcemaps, broken IDE probably makes webdevnewbies quit before actual code syntax.
In my dream world, HTMX could become part of the HTML6 spec, and beginners could spend more time dipping their toes in the water testing their .html files in Chrome before they face getting gobsmacked by the greater JS ecosystem.
Congrats. I will be very curious to see how this (and other companies that are built around an open source frontend/web library) work on monetizing themselves. Are there any successful businesses in that space?
I worry it will be truly challenging without a big compromise to morals/openness/etc. I kind of wonder if stuff like htmx should just be funded with a big grant so it never needs to worry about selling out users for profits and operating income. Or at the very least that it learns to run extremely lean, to not chase expensive fads, and to build itself into something that can survive off a modest "please donate/buy some stickers/tshirts or my book" income stream. I hope we don't see the day that suddenly there's no download link on their site and it's replaced with a, "please contact our sales team for a demo!".
htmx is bsd licensed and I will not allow it to be anything but that (I may actually move to BSD-0, the two clauses are kind of dumb when you are talking about javascript)
i have a day job (a couple) so there is no financial pressure around it
i hope that it will be a long term public asset for developers
Love Htmx but confident the hardest part of implementing will be convincing managers and designers to fully rethink how to approach UX and product in a way that privileges simplicity over presentation.
Can someone explain to me how state management is done in HTMX? I'm a native Django developer, and I really do like HTMX and wrote my own personal website with it (nothing special, a digital garden). But for my startup, I chose react, and it has pretty much become a SPA, where I need to keep track of so much state. Now, I would love to transition to HTMX, because I find Django a lot more ergonomic to work with. But I couldn't imagine not running into issue managing state.
I don't think there is a single answer to state management with htmx as in "put your key-value pairs here“. Instead the page depicts the application state and offers ways to change it or to change what is depicted each time updating parts of the page. So the state is what's on the page so to say. However some options are: 1. you can have some form of state in your url by having every user actions change a param, returning the updated page with updated links/forms. 2. You could keep a session on the backend. Never used this myself, however Django which you speak of above should have support for sessions without a user/login. 3. you can keep state in the database if is important enough and you have a user. 4. htmx also sends a lot of js events which you can react to by using some plain Javascript yourself. You can also send your own events and have htmx listen on them to have different components react to a page/state update elsewhere with their own page update.
State management is done in whatever day your backend does it. HTMX is mostly concerned with sending requests to the backend and shoving the HTML response in the right place in the DOM
I haven't written anything meant to be seen by the wider web since geocities/myspace and I don't know anything front end besides apache and PHP -- is this a return to roots?
(I don't like javascript and i think making websites sentient was a mistake)
Can anyone explain why Htmx is such a big deal? I really don't get their 'motivation' section on their landing page.
I mean, for example, the first motivation it lists is 'Why should only <a> and <form> be able to make HTTP requests?', why is that an issue? And 'Why should you only be able to replace the entire screen?', I mean that hasn't been an issue since XMLHttpRequest or am I missing something?
> 'Why should only <a> and <form> be able to make HTTP requests?', why is that an issue?
I wouldn’t call it an issue, but maybe you would like individual elements to fetch their own data. Sure you can do the same thing with JS in the browser (calling fetch or XMLHttpRequest), but htmx lets one do it with attributes on tags.
The “replace the entire screen” business is a jab at React-like frameworks. Although they all claim to update only the DOM parts that change, it’s very easy for a codebase to [accidentally] force a full page redraw.
HTMX is meant to relatively cleanly interact with updating portals on a rendered page. Where the serve-side handles the post data and simply returns the HTMX fragment that gets injected/replaced.
I can see the appeal, it's what ASP.Net WebForms probably should have been. And for that matter could probably cleanly fit with ASP.Net MVC and Razor views.
Htmx's biggest upside is no pressure to use JS/TS on the backend.
So many stories start with "I used htmx with (rust|go|ocaml|django|etc) and had good results".
Feels hard to not use JS/TS on the backend if you are already using it on the frontend (unless you have a specific need node can't fit). Why intentionally use two different languages, yadda yadda, etc, if you don't have too.
Great news! I'm not using the full feature set (e.g. hyperscript) but really like the general approach as opposed to usual suspects like react or svelte. One of my last projects runs just fine on htmx + 3-4 stimulusjs controllers for all interactivity
hyperscript is a separate project. It is not a feature of htmx. htmx handles the hypermedia interactions with the back-end server. For pure in-page interactivity (hiding/showing side-navs, etc), you get to decide how you want to do it: VanillaJS, AlpineJS (my favourite), hyperscript, Web Components (lit.dev, etc), StimulusJS (what you used), a big framework component (Svelte, Vue, React, ...), etc, etc. htmx does not bundle anything into itself to make that decision for you. You may have thought hyperscript is a feature of htmx because sometimes you'll see the two used in examples (both have the same creator).
If you think htmx is cool, check out _hyperscript https://hyperscript.org/. Made by the same people, available with htmx I believe.
After seeing _hyperscript, it looks like they may have invented that first, and a lot of people's heads exploded, so they decided to try to make a "gateway drug" to sneakily introduce _hyperscript, and came up with htmx.
i dropped that attribute (along w/ the jQuery dependency) when I created htmx, but I felt there was some merit to the idea of a lightweight scripting language that abstracted away async behavior. Once htmx had stabilized I revisited the idea, remembered my experience w/ HyperTalk as a young programmer, and decided to take a shot at that, but for the browser.
I'm very happy with how it worked out, although I expect it will always be niche when compared with htmx, which has much broader applicability and isn't as insane looking. :)
Well, congrats on both projects. _hyperscript especially to me looks like an amazing technical accomplishment, to make something so similar to natural language. What sort of parser is it? LL? LR? Because I would need to use an _LLM_ to handle that. Lol.
The practice of cramming a DSL into an HTML string attribute seems like it would get cumbersome and hard to read after a while. You can really tell in this example on the htmx site [1]. I imagine you can write that long string in your server code somewhere, but that also seems weird especially since you won't have _hyperscript syntax highlighting in your Ruby/Go/Clojure/whatever file. Does anyone have any real world examples of this?
Htmx strikes me as what we would've gotten earlier if we didn't throw XHTML and namespaces out with the bath water. Namespaced attributes, perhaps even tags, that already package and compose behavior seems like the natural outcome of browser spec writers reifying community conventions over time, and that kind of superimposing is precisely what XML facilitates.
So who is using this/hotwire/unpoly and something like capacitor or maybe react native wrapper or turbo-iOS to make “native” mobile apps that are mostly just web apps? Any good war/success stories?
I have to assume that just like most web apps don’t need aggressive SPA front ends, many mobile apps fall in the same boat…
People want and expect pretty and interactive experiences.
I don't think they care how they get there.
I've written some Unity "web" apps by using the port to webgl feature, so I have no deep fondness of html or js. I just need results.
With a little creativity, HTMX can enable some extremely UX-friendly interactive sites. Keep in mind that it makes it trivially easy to entirely swap out small, or large, sections of a web page. So things that used to be standard boring forms can be interactive step-by-step pathways that adapt to the user's selections. Very easy to deliver progress updates and validation cues to users that seem to appear magically without page reloads. It's still early but HTMX continually inspires me (a poor designer) to execute new UI ideas because it makes it very simple to conceptualize how they can be built (and simple to actually build). Tailwind is also essential in this process, for me.
Seems clear to me but I've been watching this project grow for a few years now. If you read the brief introduction, motivation, and quick start on the homepage what do you think the project does?
> why would you want to use something like this
I would agree that part wasn't clear to me either, at least not right away. When compared to something like a SPA the state has to persist on the server while an ephemeral state exists on the client. With HTMX the state only needs to exist on the server. If this sounds like the MPAs of yesteryear, it is. You render the HTML using the frameworks/tools/languages you fancy. HTMX provides custom attributes you can use to update content within a page without having to reload the entire page.
> and quick start on the homepage what do you think the project does?
It adds some special attributes to HTML that magically perform some logic and it is not clear how and why.
Why would I use something like this over React?
What this thing is trying to solve?
> You render the HTML using the frameworks/tools/languages you fancy. HTMX provides custom attributes you can use to update content within a page without having to reload the entire page.
I still can't see what's the point of it. Why would I want to do it?
> I still can't see what's the point of it. Why would I want to do it?
It depends on how you like to build projects. If you like the current state of client-side rendering there is no point to using HTMX. If you like server-side rendering (my personal preference) then HTMX fills the gap of doing partial DOM updates without needing to reload the entire page. Some people will argue about perf metrics until they're blue in the face. I mostly rely on personal preferences.
In the olden days I remember having backend returning an ID of the DOM element to update and a tiny function would look at it and update. There was no need for HTMX.
Before people explore stuff that may not matter, I just don't understand why people don't just graduate writing raw HTML and write something like Pug which is like saving 30% typing that doesn't break or change your workflow.
No frontend developer that cares about the details, the UX and has to deal with the evolution and maintenance of any non trivial UI would use this.
But as I said, this is great for everyone that just wants to make a frontend for their Go/Django/Clojure/etc backend. You’ll notice this pattern in most positive comments you see here.
Also, as someone who also used these kind of tools, I still prefer Unpoly over it. Sadly it didn’t get as much marketing.
I just love that you had the "guts" to start a project that sends HTML via ajax from the server at the height of JSON/JS/Framework Mania (hey it pays my bills).
Project is really cool, I'm itching to use it in the right side project.
Congrats on shipping !
Oh yea the https://htmx.org/essays as the author mentioned is also fantastic. Their twitter is "fun" :D
Not willing to be the party pooper, but isn't htmx's appeal the simplicity of it?
I would expect it to be "done", or maybe could be refined with a couple more little things, but definitely not needing full-time dedication on making a version 2.0 or adding new features.
the 2.0 would drop IE support, remove the older SSE and WebSocket support, and switch a couple of defaults (e.g, using template wrapping for parsing partial content, which handles troublesome elements like table rows better, but isn't available in IE) so it would be a breaking change (not for most folks, but still, breaking for some) which I only like to do w/ major versions.
we may have one major addition: a morph swap based on idiomorph:
I invented this over 10 years ago and called it Pebbles. Got some stars on GitHub. I convinced Memrise to use it in production and it helped them speed up dev a lot.
That's what I was expecting to see, a way of specifying a target. Certainly not returning custom headers for the benefit of such a 'simple' frontend library.
Solution 2 is clearly the best option. htmx authors would be wise to get opinionated and champion that approach. Forget about IE11 compat. Completely rearranging the DOM (Sol. 1) and a two request chain for one update (Sol. 3) are non-starters
This page illustrates why I just don't get HTMX. It seems like a ton of effort to save not a lot of server cycles and html over the wire.
I've done tabbed UIs that worked like HTMX. But instead of trying to do div surgery it replaced the entire tab. It was like 20 lines of JS and a few lines in Rails to render without a layout based on a URL query param.
When we're talking dozens of KBs of HTML for a tab it's not the extra complexity to try and slim that down.
Htmx advantage is not that it sends less bytes, but that it effectively removes frontend. Getting rid of the frontend dependencies, builds systems, and languages can bring a lot of speed to a project.
Of course the downside is everything must go to the server. While not perfect, many spa also do not work nicely without a connection, although they could.
Another thing is that the templates can get a bit crazy quick.
I found a good solution is to use swap-oop (https://htmx.org/attributes/hx-swap-oob/) for everything and have a "component" wrapper server-side to abstract the ids and which template to choose.
Then, some kind of typed data structure tracking all the element ids, since you need to refer to them from the templates to know which element to update. This way you can easily find all the templates that update a specific id or all the ids that are updated by a template.
>Htmx advantage is not that it sends less bytes, but that it effectively removes frontend.
Right, which you can achieve by replacing the main content div. HTMX takes it many steps further and allows you to slice the HTML up into small bits and replace only those. This adds a lot of complexity for little benefit.
It has. The issue jQuery was designed to solve doesn't exist anymore, hence there's no reason to rely on this heavy and convoluted library any longer. There really are better solutions.
My main use case will be basic UI interaction, mostly just posting or fetching data from a backend then updating the innerHTML on some element. Vanilla might be enough, but I'm keeping my options open.
Also, no compilation step, so no need for npm, etc
IMO that's where alpine.js complements HTMX, you can use HTMX mainly for interfacing with a server and then use alpine.js for any special interaction that does not require a round-trip with the server.
That's my thought as well. Anything that needs new data from the server uses HTMX and if you need to manipulate something already on the page use Alpine, Jquery, vanillajs, or whatever other framework you prefer.
JQuery would make sense when we didn’t have querySelector and fetch API. I can’t think of any reason to use it today on a new project, there are not advantages over vanilla.
Have you seriously looked at this and thought "yeah thats better than using a single native function (fetch)"?
As for the rest of the API - what would you even use besides the css and selector functions? Which again, the native `classList` and a simple bind to the selectors are simpler and less verbose.
You just return an HTML fragment that describes the error with a header that says where to put it. The htmx JS API has events for errors too, if you want to do client-side handling.
I like the idea of htmx, it's more familiar with me since when I was involve on web developing, it was mostly jQuery, PHP, vanila JS, django. But I don't think I will change my current app from Vue to htmx, too many changes.
In all those SSR tools, my favorite is inertial.js, I think it combines the best of the both worlds. I am not sure why inertial wasn't getting more popularity though, anyone know why?
Curious if anyone familiar with Drupal’s AJAX implementation (at least how it was in v5-7, I haven’t used Drupal v8 onwards) back in the day and has used this can offer a comparison?
I've skimmed the documentation and searched for the word server but I haven't been able to discover what is required on the server side. Can anyone point me in the right direction?
Any server-side language with your favorite web-framework and HTML templates system. Static files, PHP, Go, Ruby, ASP.NET Core, Spring etc, as long as you can send HTML pages and HTML partials, you are all set
Thanks. So a static site, on neocities.org, for instance can serve files in response to requests such as the examples using hx-swap="outerHtml". Is there a simple example of a static site using Htmx somewhere?
The code is not done yet but I can explain how we're going to use htmx and Hypermedia APIs for the static site of a national chess federation (it's static to avoid hacking/ddos from disgruntled russians). Every week, new chess ratings are calculated from the reports of in-person / over-the-board tournaments. At build-time (Hugo/Netlify), a static HTML fragment is created for each member and included in the site's static files. At run-time, when a member's info is requested, htmx will fetch the member's HTML fragment and insert it into the appropriate <div>. At run-time, there is no server-side code executing nor database so it's fast, highly available, and almost unhackable.
From what I understand, it's just HTML from the server, embellished with properties that get picked up client side by HTMX. So you can use anything on the server: nginx, node.js, go, php, whatever
htmx just got me to do some front-end programming again after many years of false starts with Angular, React, Flutter, etc!
Very refreshing and extremely productive! Goland, browser window and Bard for code snippets and from idea to first working flow in less than an hour!
With other frameworks I would first have to struggle for a day or two setting up the tooling and understand all of the new concepts and constructs. Or worse, learn completely new language (Flutter, Typescript)
How does HTMX work with Tailwind? If I return some HTML from my backend, then the Tailwind scanner won't have found the css selectors, so it won't be in the generated CSS.
document.querySelector(x).[addEventListener|innerHTML|... etc.] is usually enough for most use cases. You can alias it to $() and .on() if it looks verbose.
I don't want to bag on Htmx but if you're looking to just use vanilla HTML (seriously, no extra/custom attributes or weird syntax gotchas), please check out Joystick [1]. UI framework that's part of a full-stack framework that uses vanilla HTML, CSS, and JavaScript for building components.
Your frontend makes a request to your server, the expectation is that will respond with html.
If you have other services you need to bring in to the mix that responds with JSON then make the request to them from your server, have that parse the JSON in to HTML (most likely some kind of templating system like handlebars) and then send that back to your frontend as html for htmx to handle.
Dear god. Have we forgotten about the ACCEPT header? If you get a request with ACCEPT application/json, return json. If you get one with text/html, return html.
I don't think using the accept header is a good idea.
The main reason is that it doesn't necessarily play well with proxies. Most notoriously, Vary: Accept is not supported by Cloudflare (with the exception of images). This means it's not safe to use the accept header if your site will ever be backed by Cloudflare, as you could end up returning cached HTML to a JSON client or vice-versa.
My other problem with it is that it's not very discoverable - it can be surprising to interact with an endpoint that varies based on the accept header. It's not commonly used, so many developers are unfamiliar with it.
And even if you do understand it, it's still hard to tell which endpoints support Vary and which don't.
Finally: I like to debug things by copying and pasting URLs around. The Accept header doesn't support that kind of communication - you need to share not just the URL but also the accept header you were using when you saw a specific response.
I’m not a fan of vendors “not supporting something” as a reason to not use something. Either get a new vendor, put pressure on the vendor, or ignore the feature you want to use.
I personally don’t care about what cloudflare does because I don’t use them.
The rest is RTFM for whatever API you are calling and you usually have to send auth or cookies anyway, so an accept header isn’t that big of a deal.
I dropped Accept header support from https://datasette.io/ because it's open source software that I build for other people to use, and I knew that it was very likely one of my users would choose to run it behind Cloudflare (or run it on a vendor like Vercel who might have a partnership with Cloudflare).
FWIW, WordPress uses the Vary: Accept header for a number of apis and it seems to always work fine behind cloudflare and runs a sufficiently large portion of the internet. But, you're telling me I can hit all these site's public api's that are behind cloudflare and start a DOS by simply sending an uncommon ACCEPT header? Sounds like an easy way to pressure cloudflare to 'do the right thing' if you own a botnet.
Anyway, I guess this is yet another reason to not use cloudflare. Thanks for your comment.
JSON APIs are typically more general. Here, you'll need different endpoints/handling for every flavor of HTML you may show that uses that same dataset. It's not so simple as Accept headers unless you always use exactly the same html, in every context on your site, to represent a "user with ID <foo>"
Not at all. Post a form submission, send back either the same form with errors displayed, or simply return out-of-band updates to error message divs. You can redirect from the response as well using htmx, so if the form submission is successful, you can redirect to a success page ... or simply update a div with a success message.
If you get a request asking for json, you just return a json with the same thing. Not much changes with API design if you were designing the API well in the first place.
Yeah, just exasperation. For the longest time, most APIs would return json if you asked for json, or xml if you requested xml. Many older api's still do content negotiation, many gave up because 'xml bad'.
Yeah, I remember a lot of apis that were something like `resource/instance.json` or `resource/instance.xml` and they'd give you `instance` in whatever the requested format was
That's the whole point. Those "restful API backend services" are not really REST-ful. The essay, "How Did Rest Come To Mean The Opposite of REST"[0], explains this better than I ever could in a HN post. Maybe we should stop growing these Data-APIs (returning JSON) and switch back to Hypermedia-APIs (returning HTML).
it might not be the right REST, the key point though, is that it's json data instead of html, which asks you do client side rendering instead of server side rendering.
htmx might be great for server side rendering, but for client-side-rendering(SPA) which consumes json data from the backend, I doubt htmx is a good fit, and there are lots of json-api-service(instead of html) these days for client to consume.
Yeah that one: full screen sent down from the mainframe on the beginning of a page-interaction, then only the parts of the screen that need to be changed are sent over the wire based on commands and input. With CICS it was all about reducing the number of bits moving over the wire to an absolute minimum which isn't the case here but partial screen replacement without refreshing or reloading the entire page is very reminiscent of the design.
I think Angular looks like Htmx on crack but I do remember that Angular was first.
We used it in a project and it worked perfectly. If you have the need to write a lot of logic and changing of most of the UI parts dynamically on the page then React/Vue/Svelte/Angular is better suited. If you on the other hand has page that could be server rendered and some parts or lists that should load new parts into the page this may be the easiest way to do that.
You can also combine it with any backend language instead of us having one framework for C#, one for Java, one for Go and so on. I think this is one of the biggest USPs for Htmx.
A syntax-based comparison feels a bit... superficial. One is an MVC based SPA framework. The other is best described (in my mind) as syntactic sugar over AJAX calls that replace inner HTMLs of selected targets.
Yeah, honestly (ignoring syntax) it looks A LOT like the original ROR ajax implementation. Having the server render a partial and swaping out the inner html to do a partial page update.
No - from my perspective - it's important and for understanding maintainability. The syntax helps understand the mechanism of using HTML directives that are picked up by clientside javascript at pageload or AJAX HTML partial replacement, which is what GP was getting at with its comparison to Angular 1. Angular 1 picks up directives the same way (and Knockout).
In react you don't use the mechanism of directives, you use JSX or React.createElement in standard Javascript statements or expressions.
I think it's important because it decides your templating and composition, which is what React solves with its Components.
I played with pjax which is similar.
EDIT: For example, you might not want ng-click in your HTML if you think that is wrong for example, as it's like DHTML and onclick="" (I don't have a perspective on this at this time)
It's so odd to live long enough and see the steady pipeline of "look at this much simpler way of doing web apps, just write HTML, not like the previous complex way" projects, which then turn into the previous complex way as the eyes turn towards the next "simple way of doing web apps, just write HTML...".
Angular and React started this way on the frontend, while ASP and PHP started this way on the backend (of course eventually they all grow "full-stack" solutions).
EDIT: And how could I forget, Tailwind, whose tagline reads: "Rapidly build modern websites without ever leaving your HTML"
The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline.
>The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline.
Not my experience for the record. I use Tailwind in my side project, and it is exactly as convenient as it sounds to write my styles directly into HTML rather than think of a class name, add it in HTML, switch to the proper CSS file (or create it if it doesn't exist and make sure it's part of the build step), forget what name I had decided on, check the original HTML to remember the name, then go back to the CSS file and write the class name and then finally within that block add my style.
I’ve messed around with tailwind a bit now, and honestly I could never use it in even a moderately complex site without some sort of “component” framework.
I think you’re talking about just serving a .html file for every page in a site right? Having all of your styles duplicated everywhere would be much more confusing than writing CSS (and having to invent one name per groups of common things.)
IMO it’s only viable if you can create your own components. Which you will also have to give a name.
It's implicitly expected you're already doing so, such as web components or whatever your selected framework uses to abstract components.
> Having all of your styles duplicated everywhere
Locality is a feature. It's much easier to jump into any random bit of HTML and understand what's going on and confidently make changes without having to pull up multiple other files to grok the classes involved.
Compression is going to solve most of the issues with repeating classes everywhere, and while not recommend you can still use something like Sass/SCSS and Tailwind directives like @apply to separate classes into their own files.
"Compression" doesn't solve change management, where you need to consistently change together things that are meant to change together. Intead of letting them fragment, diverge in millions of tiny ways until entropy takes over your project and kills it.
Copy/pasting, which Tailwind is so proud of, is to fork, and never merge. Let's fork all the things. We end up with a bazillion little things and no coherence/alignment between them. Hello, second law of thermodynamics.
Quick detour: our universe is so organized, that inanimate matters forks, and animate matters looks at the forks and is trying to find ways to solve these pieces together into coherent systems by merging putting together, deduplicating, generalizing. Inanimate and animate are two opposing forces, increasing entropy requires no intelligence, decreasing it does. It's no surprise Tailwind promotes lack of intelligence by saying "copy paste bro, it's good, turns out". Because that's who they target. People afraid of thinking. "Oh no you gonna like have to name a class, that's terrible". Woah woah... rocket engineering territory here!
For those starting to get back to their senses... they added @apply. But @apply is by Tailwind's own admission "like using CSS". I'd add it's like using CSS but with 1/1000 the capability, unclear/surprising precedence, and tons of extra steps/indirection, because... you could've been using CSS, simply.
And one more word about "compression". Do you know what you're doing when you name a reusable case and put it behind a class, function, package, module, library? You're compressing. So yes compression does solve issue of repetition, but intelligent compression (YOUR BRAIN) does this in a much better way aligned to your project's needs, compared to, say, GZip. GZip can't think for you. It can shrink things for transmission, but its only job is to shrink transmission. Your project still needs to evolve in time, and when you look at it... you're looking at the repetition, not at the GZip.
Or maybe I'm wrong, do you edit the .gz directly? Heheh. If so, I take all I said back.
But compression, in the context of broader space (your project, your industry, your target audience, coworkers, customers) and broader time (project evolution, change management, new requirements adaptation, changing platforms) is your job. The job of intelligence. The moment a computer compresses better than you, is the moment you become useless. LLM is a form of compression, because compression relies on prediction of what's next, whether it be what we desire is next (needs, desires, goals) or what is next regardless (outcomes, events, probabilities). When I tell an LLM "code me a modern site" and it does better than you (i.e. not using Tailwind, but with proper minimal CSS with well named classes), compression replaced you.
How have you written nearly 500 words and still not make any salient or cogent points? Try making a good faith argument and maybe we can have a discussion.
I think that's not the problem with CSS, but with how you approach design. If you treat your design process as editing a document, and just want to "Ctrl+B" to bold necessary parts, yes, I'm sure Tailwind's better. But, I can see how it could be a problem with maintenance and collaboration as there isn't an agreed upon design language or a document structure.
I understand that managing multiple files and going back and forth can be considered an overhead, but that's a componentization problem, not a problem with CSS per se, and you expect to recuperate your losses with the time you gained when finding and fixing bugs. Otherwise, there's no point in componentization. You'd have the same tradeoff when writing JavaScript code, for example.
You'd encounter the same set of problems the moment you start refactoring your styles into Tailwind components.
Tailwind is meant for a workflow that uses components. I don't need a `.container` class. I need a `Container` component with various tailwind classes on an internal `<div>`.
Is this how Tailwind is supposed to work? I've never used it, but this sounds awful. How do you keep styles consistent across different areas of a website? Do you manually write matching styles into HTML every time you need them?
I used it to build my saas template for my side projects. It's not awful at all - quite the opposite. But I'm an old guy using python+flask+tailwind+htmx. I try to inherit as much from my base template as I can, and then for different sections that are a bit more bespoke, an intermediate layer there to inherit from. It's not perfect, but the things that I tend to want to tweak or play with are as much in a single place as I can make them. I hadn't designed it this way from the beginning or it'd probably be cleaner.
You use UI components. CSS alone can't do everything so trying to come up with class names in a .css file and then integrate them with components is wasted effort (for most things). The component is the atomic unit now.
I disagree that it’s wasted effort. Using stylesheets with components is actually very nice compared to traditional UI systems that mix style with functionality.
1. Most of us are using landscape displays. I can have my functionality on the left and my CSS on the right. If the style information is interspersed with the functionality at component level in the same file, I can’t do that and I can only see half the information at once.
2. It fits my working pattern. Usually when I’m editing styles I’m flying between the styles of many different components. If the style code was interspersed with the functionality this would be a lot slower - with stylesheets I just have to scroll.
ASP had some strange things where you could write what looked like a client side handler on a button and it would call a function in the server.
Circa 2007 or so it seemed a to be a huge mistake because it didn’t play well with the so-called “model-view-controller” paradigm where, most importantly, the request handler could decide which view to render. (e.g. you fill out a form and if you mad a mistake it redraws the form with an error message, otherwise it might render one of several different forms depending on what you filled out on the first form.)
He thing about HTMX is that it really wants support on the server side. For instance, you might have a <select> that gets drawn as part of an HTML page or that gets updated with new <option>(s) via HTMX when you push a button. Similarly you might have a form that can be rendered as the only form on a page or that can be rendered as a modal dialog that is pulled from the server when you open the modal (as opposed to unhiding it.). Either way the code that draws the HTML fragment (both the template and any database fetching/thinking) has to be runnable in more than one context. (Modal dialogs are so fun to implement with HTMX.)
It’s something you can do in a situational way or that you could have a framework to help with, but it is part of the HTMX puzzle.
I wrote ASP then, and it worked fine. We also wrote our own htmx like handlers. The main reason that people forget is that js was just too slow on the client to really do anything. The only way to get performance was render pieces on the server and replace the client html.
I remember having the server render js multi-dimensional arrays consisting of key and html snippet that client js could reference to do html manipulation more quickly.
I'm not sure JS being slow was the reason. It's rather lack of trust that JS can and should be used for such things, and the difficulty of mixing client and server logic together. You kinda want to simplify things and relegate JS simply the role of detecting an event and delegating it to the server for processing and injecting the result back.
But JS, from the moment it was introduced, was quite capable of carrying out a great number of interactions. We tend to project our subjective beliefs on the objective world. We don't see potential in JS and so we didn't use it up to its potential.
I recall working on a webshop back in the day that opened in an embedded IE in the app for a popular music company (so I had also full control over the browser engine and could rely on JS), and there was a complex system of discounts as you add plugins to your cart and so on, and I thought: I'll use JS for this. And despite the discounts were verified on the server side, all my coworkers and my boss were intensely worried about me using JS for this, because I'll make the store insecure, and this is a very noob thing to do and I shouldn't be using JS for this. And... it worked fine. The tech was always capable of this, but none of then would've even TRIED, because they "KNEW" it's not supposed to be done.
Eventually the tide turned, but it turned to another extreme, that is even more BS now. Many websites load more JS code than they load images. Why? Because we subjectively believe the server is not capable of all the richness that JS can deliver. Basically we didn't get smarter about any of this.
We're stupid and led by superstitition about the tech we use, we don't really understand it, we don't grok it. We go by fashion and trends. Most do. And that's the danger of starting a stupid trend. It may take years before the bubble pops.
In that time frame I was building very complex applications (semantic graph editors, decision support software for sales teams with 10,000 salespeople, etc.) in frameworks like GWT (Java compilers to Javascript) this wasn't long after the firstversion of Google Docs came out.
Javascript was fast enough back then to make much more complex applications than most people were making back then but the complexity was mind-numbing, particularly considering that you didn't have tools like async/await to help manage asynchronous communications.
I built frameworks for managing the flow of data in that kind of application and didn't feel it was so catastrophic when Microsoft banned synchronous communications in Silverlight... I knew what to do.
Having had that experiment I tend to laugh at today's Javascript frameworks because they work really hard but aren't suitable for the kind of apps I built back then.
Sometimes it seems there is a lot of "lost" technology in software like the production rules systems of the 1980s, CASE systems and Lotus notes from the 1990s, Google docs in the 2000s that are like Stonehenge or the Egyptian Pyramids seen from the state of programming in 2023.
Entropy creeps into everything, unstoppably, masked under the pretense of a sequence of individually logical choices. To recover from this we will have to take a few steps back before we can make more steps forward. But we keep pushing and pushing, until either the tower we're building collapses, or us and what we do simply gradually become more and more complicated, with smaller and smaller gains that we focus on more and more, until it's all indistinguishable from background cosmic noise. Fermi paradox resolved.
Most C#, .Net devs and even VBScript devs had very little desire to learn JS. Not to mention that prior to IE6 becoming dominant there was a lot of very painful variance between browsers. JQuery helped to normalize this a lot. Part of why the ASP.Net (and others) were modeled with a full server postback. It worked fine when the server was in a server room in the corner of the building you were in, over the internet on dialup, not so much.
The "beauty" of ASP was (is?) that it could be so many wonderful things. For me it was inheriting a codebase that was basically many HTML pages with VBScript AND JScript dynamic parts, in the same file.
Imagine what everyone was saying about spaghetti PHP intermixed with HTML - but with 2 backend languages plus HTML and CSS, at least that was early enough that clientside JS was limited to changing images on hover...
ASP.Net is different than Classic ASP... ASP.Net had a "WebForms" model, where the default behavior was a postback with a rerender on a lot of handler actions. That also included a ViewState input attached to your page/forms that was used for (re)hydration to handle change and other event detection. The use of viewstate with a lot of the component libraries at the time was pretty aweful. Not to mention feature/browser detection was just plain wrong as Firefox started to gain traction, before Chrome.
I can say I migrated away and mostly separated render/js/backend with ASHX handlers until MVC took hold. These days, I tend to prefer the modern SPA models for browser applications. Though will also use static generators, server generation or other techniques if you don't need an interactive application.
HTMX seems pretty interresting as a kind of in-between, closer to the ASP.Net Webforms without the complete excessive overhead in the box.
> Either way the code that draws the HTML fragment (both the template and any database fetching/thinking) has to be runnable in more than one context.
I'm sure it's the matter of time for isomorphic HTMX-based frameworks... but they won't degrade gracefully. but then they will, as a new feature. the circle of life!
Don't forget Polymer, whose main marketing was that it's the tech behind... McD's menu screens. It turned into lit html, I have no idea what the state of that is now, haven't heard from it for a while now.
Polymer powered a few other things at Google too. Look at the DOM for YouTube, that dev team started with Polymer for Web Components and talked about how they built an internal library of custom HTML for the site. Doing that shared library approach seemed like a good way to scale out development across teams. It seems like it's still alive and well over there. (also used at ING, Comcast, Vercel, and others)
I still have hope that frontend will eventually turn back to web components now that HTML templates, Custom Elements, Shadow DOM, and ES Modules are fully adopted. One of the problems is that this stack is foreign even to professional web devs that hail from React land. It's weird because it's native browser tech adopted by the W3C and painstakingly built into the browsers. Maybe it picks up after someone rewrites the react-dom internals to support web components and adds a new tooling layer over it?
It's not bad tech and web components are built into the platform of the web now so they're not really going anywhere...
Coldfusion may have been one of the granddaddies, which java's JSP copied shamelessly.
So many web revolutions touted as "don't use Java and all that big stack, instead use our SUPER SIMPLE stack called:"
Rails: wow did rails eventually encompass a massive stack of dizzying extensions options and frameworks.
React: I laughed when I saw basically a full rewrite of various Java unit testing frameworks in javascript.
But HTMX seems to get love that angular/react/etc never got from a HN front page perspective.
I take a dim view of AI so far, but one thing it could be fantastic for is "take this basic HTML application and write it in framework X" so I can finally see a good comparision.
The web framework landscape has needed a "reference web app" since the year 2000 where frameworks could demonstrate their way of doing rendering, layout, validation, forms, routing, error handling, data binding / data retrieval, tables/grids, media. As in your web framework isn't even close to prime time unless you can show WHY it is novel or useful.
> React: I laughed when I saw basically a full rewrite of various Java unit testing frameworks in javascript.
Why?
Can't run java in a browser. (And don't bring up applets.)
I suppose you could keep most of a testing framework as Java code, and adapt the rest for testing javascript, but that seems fussy enough for a rewrite to makes sense.
Edit: Okay, if people are going to downvote, then I'll elaborate. I understand amusement in people moving from one server language to another, only to recreate the same things they already had, because they could have just stuck with the original. But you can't just stick with a server language when you're writing an interactive web page. Trying to port the tools you like is making the best of the situation, not creating work out of nothing.
Mostly because React was yet another "we're so much simpler/uncomplicated than all that enterprisey Java" sale job (just like Rails was) and lo and behold, React went full enterprisely in like less than 12 months (at least it took Rails something like 3-4 years to get to full complexity, and Rails/Ruby contributed huge amounts of groundbreaking frameworks and idioms along the way).
Almost all of these projects bring something innovative too. My take: we are missing the "refactor" step from the loop. It probably concerns other areas more than web dev by the way, but I would like to see more projects that not only build on top of the past experiences, but also remove the complexity from the solutions, instead of adding the features to deal with it. Achieve the same result with fewer layers, less code, less "stuff". For what it’s worth, HTMX looks exactly like the latter kind.
Yeah, ok. Do tell me what are those ways. Maybe @apply? Then put some effort into realizing this is literally what you could do in CSS the entire time, but better, shorter, simpler, and with clear precedence rules, and complete assistance from the browser dev tools.
It's rampant dysfunction on full display, my friend. It's as clear as daylight. Copy/paste is the rookie approach, and Tailwind targets rookies. So it focuses on "it's not your fault, copy paste is good, they... they don't get you" approach and then throw @apply in there as some half-baked solution for those who are starting to wake up from the Matrix.
"precedence rules, and complete assistance from the browser dev tools"
Huh? I am not sure what you mean here. Tailwind generates css that is completely explorable in any browser dev tooling. Its precedence is the order of the css classes just like any other css class.
You can solve class overload by just making components. Create a Button component one time, have it contain the tailwind classes you want, and then all through your app, just call your Button component and never think about it again.
You can also just define custom tailwind classes in the config you want to do something really specific or crazy.
If that is too much work you can use Daisy UI which is just a tailwind plugin and it creates a ton of classes that essentially compress tailwind classes down to manageable chunks if you are fine with Daisy's style.
> looking for a nice framework for website
> ask dev if their framework is hypermedia or javascript
> doesn't understand, pull out long essay on hypermedia as the engine of application state
> dev laughs and says "its a good framework sir"
> check github
> its javascript
I contacted them. They outright refused to delete any comments, all comments or my entire account. Hacker News by matter of policy WILL NOT delete your comments, even when requested in writing.
in your case there seem likely to be extenuating circumstances; just after posting the above you accused me of 'anti-semitic rhetoric' in https://news.ycombinator.com/item?id=37150457 for example
people who egregiously abuse the site like that may be less likely to get cooperation in concealing their abuses
Interesting how you equate a simple desire to have the ability to delete comments (ostensibly a site-supported function) with "concealing abuses" -- it says more about your own projection than anything else.
All you've done above is make baseless assumptions and imply accusations against kitanata with no basis or merit.
Might want to check your own actions out before you go accusing others of "egregious abuse" - and as you put it, dial back on the rhetoric ;)
judging from the number of your comments that have been killed today you may be on the way to being banned yourself
maybe you should consider more carefully the moral of the hasidic parable i quoted in my previous comment https://news.ycombinator.com/item?id=37145942, that nothing you say can be unsaid
As you've been posting dozens of these comments in the last 24 hours and starting flamewars all over the place, I've banned this account. Please don't create accounts to break HN's rules with.
> “Now Yankel,” the Rabbi began “go back through the town and collect all of the
feathers. Put them back into the pillow and bring the fully stuffed pillow back to
me.”
> “But Rabbi!!!” Yankel burst out. “That will be impossible. Even as I was walking
away from the feathers, I saw that they were being blown from the doorsteps. How
will I be able to find and gather up all of the feathers again?!?!?!”
> “Ah...” the Rabbi began his explanation. “And the same is true for lashon hara, for
once you let it pass from your lips, you can never collect it back again. It floats and
flutters away in whatever direction the wind carries it. That is why you must
always watch your words carefully and avoid all talk of others. You will never be
able to repair the damage you have caused, but I am hoping that you have learned a
lesson...”
> Yankel nodded with deep understanding. From that day forward, not only was he
no longer the town storyteller, but he did everything he could to spread the word
about the pitfalls of lashon hara.
if you regret the damage done by what you have said, you cannot unsay it, but perhaps you can take responsibility, apologize, and make amends by some other means
You disagreeing with something doesn't make it wrong. I'm sorry, but people in other parts of the world have a right to be forgotten, no matter how much you want to pretend they do not.
Where do human rights come from? Did we have them from when we split off from our closest ancestors? Did they magically appear when someone first thought them up, and they just stayed? Why do our closest relatives not have human rights?
You yourself mention that people in Belarus have human rights. Why can the government ignore their human rights then? Why isn't there some magic barrier stopping the government from trampling on the populations human rights?
I didn't ask you to tell you what I think. I asked you to tell me what you think. You are the one taking your position, I can't answer the questions from your position as you would.
Please cite that law, otherwise cease repeatedly being disingenuous and fallacious.
There is a massive difference between curtailing things like freedom of expression, and de-facto stating "Chinese law disagrees with..." when (a) no such law exists, and (b) you're making a ridiculous point in a transparent attempt to distract from your own failing -- namely being too ignorant to admit that the so-called "right to be forgotten" is a thing, whether you choose to believe (or accept) it, or not.
You realize your Googling doesn't make you an expert, right? It's very easy to be an American sitting in BA and judging things from what you've read on Wikipedia, but that doesn't mean you have the slightest actual understanding of the law or its application in China.
When you can read it in Mandarin and you've lived under and seen that particular law being applied in China, come back to me -- until then, keep your armchair-lawyering and racist condescension to yourself.
No accusations, buy a dictionary and you'll see the words literally describe your actions and comments. Don't like being called arrogant and condescending? Don't make arrogant comments and be condescending towards others. Don't like the observation that your remarks are puerile? Try making remarks with a modicum of maturity and less transparent projection, then.
Evidently you're too busy playing the victim to actually have any evidence to deny my point. Going "If YoU GoOgLe It" and making out like you're oppressed somehow is all you've got, then you don't have any kind of logical or sound basis for your "arguments" in the first place - such as they are.
That's a lot of baseless assumption you've got there, buddy - all from the mind that gave us, "have you ever met a person"[1] ...which is the most transparent non-argument trolling attempts appear on HN of late.
Bit hypocritical of you to try and harp on about kindness when all you've done is make baseless assumptions and false accusations to numerous people in recent threads... but then if you don't think you're being disingenuous, then you clearly won't have the forethought or self-awareness to realize that's not being "kind" ... which feeds back to the arrogance and narcissism observations, in a convenient little bundle.
Going "I think x" is a bit ridiculous when you literally stated the "right to be forgotten" didn't exist -- then when you were shown otherwise, you got petulant and resorted to baseless assumptions and ad-hominems. You're not IMAX, so there's no reason to be projecting that much.
Ah, so now you're telling me where I live, pretty arrogant of you, narcissism confirmed.
SEVERAL people have literally linked you repeatedly to multiple sources covering the (frankly old news by now) so-called "right to be forgotten" -- it isn't a literal right to be forgotten, it concerns data protection -- which you well know, but you're evidently choosing to take it literally and make narcissistic trolling rants.
You don't have much in the way of self-awareness if you can't grasp that trying to tell people where they supposedly live and what they supposedly think, while making antisemitic allegories, is completely ridiculous, and frankly a Nazi-esque move.
(Cue you going "but Jewish girlfriend!" as if the "I can't be racist because I have a Black friend" argument has ANY merit, when it doesn't -- you can absolutely still make antisemitic remarks and connotations regardless of whoever you claim to be with)
Five years from now you'll still be telling people what to do and having the audacity to tell them what they THINK, when (a) you haven't got a clue, and (b) you still blindly claim you're not arrogant, condescending, or narcissistic, when making remarks like you just did.
Please, seek psychological help. If the evidence of your assumption-laden, baseless-claim-filled, farcical comments are anything to go by, you have serious issues that go beyond being a troll on HN.
no such right exists; that would be like the right to rob with impunity
of course clever demagogues and rhetoricians can write such things into legislation, just as they can write legislation that claims you have no right to speak freely, but that just makes the legislation incorrect, like the famous legislation declaring pi to be exactly 3
You realize that you're just claiming an imaginary “right for business to keep data forever” and ascribe it a higher moral value than the “right to be forgotten” you judge unnatural?
Of course Google lobbyists are paid to argue that such a right exist and is higher up in the hierarchy than anything else, but there's no reason to listen to this arguments. I have no love for legislative bodies inventing artificial rights (like intellectual property rights), but corporations inventing artificial right is legitimately even worse.
This time fortunately the legislators took the side of the people and created a “right to be forgotten” instead of a “right to hoard private data”.
— We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.
— That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed,
— That whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its foundation on such principles and organizing its powers in such form, as to them shall seem most likely to effect their Safety and Happiness.
Whereas recognition of the inherent dignity and of the equal and inalienable rights of all members of the human family is the foundation of freedom, justice and peace in the world,
Whereas disregard and contempt for human rights have resulted in barbarous acts which have outraged the conscience of mankind, and the advent of a world in which human beings shall enjoy freedom of speech and belief and freedom from fear and want has been proclaimed as the highest aspiration of the common people,
Whereas it is essential, if man is not to be compelled to have recourse, as a last resort, to rebellion against tyranny and oppression, that human rights should be protected by the rule of law, (...)
All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.
Everyone is entitled to all the rights and freedoms set forth in this Declaration, without distinction of any kind, such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status. Furthermore, no distinction shall be made on the basis of the political, jurisdictional or international status of the country or territory to which a person belongs, whether it be independent, trust, non-self-governing or under any other limitation of sovereignty.
Natural law theories base human rights on a "natural" moral, religious or even biological order which is independent of transitory human laws or traditions.
Socrates and his philosophic heirs, Plato and Aristotle, posited the existence of natural justice or natural right (dikaion physikon, δικαιον φυσικον, Latin ius naturale). Of these, Aristotle is often said to be the father of natural law, although evidence for this is due largely to the interpretations of his work by Thomas Aquinas.
The development of this tradition of natural justice into one of natural law is usually attributed to the Stoics.
Some of the early Church fathers sought to incorporate the until then pagan concept of natural law into Christianity. Natural law theories have featured greatly in the philosophies of Thomas Aquinas, Francisco Suárez, Richard Hooker, Thomas Hobbes, Hugo Grotius, Samuel von Pufendorf, and John Locke.
In the Seventeenth Century Thomas Hobbes founded a contractualist theory of legal positivism on what all men could agree upon: what they sought (happiness) was subject to contention, but a broad consensus could form around what they feared (violent death at the hands of another). The natural law was how a rational human being, seeking to survive and prosper, would act. It was discovered by considering humankind's natural rights, whereas previously it could be said that natural rights were discovered by considering the natural law. In Hobbes' opinion, the only way natural law could prevail was for men to submit to the commands of the sovereign. In this lay the foundations of the theory of a social contract between the governed and the governor.
Hugo Grotius based his philosophy of international law on natural law. He wrote that "even the will of an omnipotent being cannot change or abrogate" natural law, which "would maintain its objective validity even if we should assume the impossible, that there is no God or that he does not care for human affairs." (De iure belli ac pacis, Prolegomeni XI). This is the famous argument etiamsi daremus (non-esse Deum), that made natural law no longer dependent on theology.
John Locke incorporated natural law into many of his theories and philosophy, especially in Two Treatises of Government. Locke turned Hobbes' prescription around, saying that if the ruler went against natural law and failed to protect "life, liberty, and property," people could justifiably overthrow the existing state and create a new one.
The Belgian philosopher of law Frank van Dun is one among those who are elaborating a secular conception of natural law in the liberal tradition. There are also emerging and secular forms of natural law theory that define human rights as derivative of the notion of universal human dignity.
The term "human rights" has replaced the term "natural rights" in popularity, because the rights are less and less frequently seen as requiring natural law for their existence.
Natural rights are those that are not dependent on the laws or customs of any particular culture or government, and so are universal, fundamental and inalienable (they cannot be repealed by human laws, though one can forfeit their enjoyment through one's actions, such as by violating someone else's rights). Natural law is the law of natural rights. (...)
Natural law first appeared in ancient Greek philosophy, and was referred to by Roman philosopher Cicero. It was subsequently alluded to in the Bible, and then developed in the Middle Ages by Catholic philosophers such as Albert the Great and his pupil Thomas Aquinas. During the Age of Enlightenment, the concept of natural laws was used to challenge the divine right of kings, and became an alternative justification for the establishment of a social contract, positive law, and government – and thus legal rights – in the form of classical republicanism. Conversely, the concept of natural rights is used by others to challenge the legitimacy of all such establishments.
The idea of human rights derives from theories of natural rights. Those rejecting a distinction between human rights and natural rights view human rights as the successor that is not dependent on natural law, natural theology, or Christian theological doctrine. Natural rights, in particular, are considered beyond the authority of any government or international body to dismiss.
more generally, though, the idea that good and evil can exist independently of law is foundational to most philosophical systems; if you reject that, you necessarily reject that laws can be evil in ways that go beyond mere internal inconsistency
though they are not based on conceptions of individual rights, taoism, confucianism, and almost any kind of theism posit a moral authority that is higher than any human law and can therefore condemn it
I don't think that secular society posits some kind of natural inalienable objective moral law. I'm sure you know this but many, many people do not believe in objective morality
Sure but that doesn’t imply that it’s objective. I mean, I think there are two levels of objective: objective among humans, and objective among the universe. I don’t know any secular person who believes that morals fall into the latter category. As for the former, I don’t think anyone can suggest that the (lack of) a right to privacy falls into in that
I'm not sure quite what you mean by the last sentence.
A "right to be forgotten" seems to mean a conflict with the classic rights of others to remember what they know, and to tell each other what they know.
almost all secular people do in fact believe in objective morality to some degree, though you can occasionally find a pure moral relativist or legalist
remember that the holocaust, the great leap forward, gulag, the imprisonment of galileo, daily human sacrifice to the aztec sun god, and witch-burnings in the spanish inquisition were not just legal but legally required
therefore, anyone who condemns one of them is appealing to a moral standard they consider superior to, at least, the legal systems of the countries in question at the time
"no such right exists" - the law would disagree with you on that one.
"Under Article 17 of the UK GDPR individuals have the right to have personal data erased. This is also known as the 'right to be forgotten'." [1]
"The right to be forgotten appears in Recitals 65 and 66 and in Article 17 of the GDPR. It states, “The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay”" [2]
This obviously varies depending on jurisdictions, but a great number of users (EU citizens, and people resident in the EU - but additionally, the UK) absolutely have a "right to be forgotten," and brazenly claiming "no such right exists" is ignorant and fallacious, and such unfounded arrogance is a distinctly USian trait. For someone who purportedly lives outside the US, you don't seem to grasp that there are laws in other countries than the US.
You'd do well to read https://news.ycombinator.com/newsguidelines.html -- all that baseless assumption and disingenuous false accusation really isn't in any way civil or useful... but then when you're cheap enough to bring the Holocaust into a discussion about data protection legislation, you're really not in a position on ethics - or indeed anything else.
LMAO, you think claiming to have a Jewish girlfriend means you're incapable of making anti-Semitic remarks... What's next, you can't be racist because you have a Black friend?!
You've done nothing but assume, make absolutely ridiculous stretches in your attempts to bring irrelevant points in to try and bolster your assumptions and baseless claims, and -- as for your "ideological battles" claim in another comment -- the only one bringing "ideology" into a discussion about data protection, is YOU.
Perhaps rather than being a toxic, condescending hypocrite, you could take a moment to step back and look at how hard you're projecting -- if you projected any harder, we'd be able to see you on the moon.
I won't be taking lectures on "elevated thinking" from an anti-Semitic narcissist who knows only baseless assumptions and false accusations, but keep raging on the internet.
>no such right exists; that would be like the right to rob with impunity
No, it's the same kind of thing as having your records "sealed", to not let a past deed haunt you.
Not even sure what kind of logic jumps one has to make to equate something like this to "robbing with inpunity". For starters the punishment to robbing isn't remembrance of your robbing, it's jail time or fine etc. And, fun fact, the aforementioned "records being sealed" can even be applied to someone who e.g. did a robbery or other crime as a juvenile.
Now, since a "right to be forgotten" does explicitly exist in EU and other jurisdictions, I'm not sure what denying its existance means.
If you mean "there's no such right" as a thing in itself, outside laws and treaties and jurisdictions, then the same is true for any right.
No right exists by itself, as if handed to us by nature, not even the right to not be murdered. All rights are based on people deciding some kind of assurances are good to have and putting them into laws and treaties and such.
And all rights are only granted and protected based on power relationships and agreement, not based on some (non-existent) natural truths existing independenty of them in the cosmos. We might call some "self-evident" and "natural" but those are just fancy words. In actual history almost all of our so-called "self-evident/natural" rights have been unrecognized (even in quite recent history), and societies considered this just fine. In fact in some cases, actually giving the rights would be considered the violation of the natural law.
>of course clever demagogues and rhetoricians can write such things into legislation
Demagogue is someone who "who seeks support by appealing to the desires and prejudices of ordinary people rather than by using rational argument". Rhetorician is a public speaker who is good in persuading people with words. Neither have much to do with such legislation being passed (nor was it the work of some demagogues).
It's simply about the internet making anything somebody does into a permanent record [1], and this being understood as not always necessarily being for the benefit of society.
E.g. what some edgy/troubled teenager wrote on his social media account in his teens shouldn't necessarily be part of his "permanent record" for employers and others to judge them by decades afterwards. And in the past, it wasn't, unless it made the press (and even then, it was easily lost due to it being in print and ephemeral), or was deemed necessary so by the state (e.g. to register as a sex offender). Just because technology now makes it being a permanent record trivial doesn't mean we should be OK with it. We should be masters of technology, not slaves to it.
[1] Doesn't matter if something like that could be accomplished in the past too - what matters is that it's far more prevalent, has several orders of magnitude more scale of the kind of stuff that can be kept, and is easier to achieve, and trivial to search with the advent of the internet. This changes the impact of this to society a lot.
while i disagree with what you say, i want to say that i really appreciate you saying something substantial and reasonable, rather than just repeating the vacuous moral-relativist nonsense that is the rest of this thread
(i think your comment would be higher-quality if you also deleted your repetition of that vacuous nonsense, though, because it makes it harder to discuss the substantial issues here; there would be no point in discussing ethical issues at all if moral relativism were correct. you wouldn't have bothered to post a comment at all if you were the nihilist you are posing as)
remember that lashon hara is by definition truthful; the point of the story is not that it is commendable to say everything that is truthful
>there would be no point in discussing ethical issues at all if moral relativism were correct (...) you wouldn't have bothered to post a comment at all if you were the nihilist you are posing as
This is wrong on several levels, including practical and philosophical (and those aspects of it have been covered a lot in moral philosophy).
For starters, whether morality is relative or objective has no bearing at all to whether it exists as a practical force in the human world - and thus whether it makes total practical sense to study it, shape it, apply it, benefit from it, use it to make things work smoother or more to your liking, and so on.
(Not to mention how it also makes sense to examine it, document it, and discuss it, from a curiosity or historical interest perspective, even if it doesn't concern one directly as a practical matter. People do study the morality of other historical periods or distant societies, for example, even if it has no impact on their life in their society).
Note that there are several other things for which exactly the same thing applies: religion, laws, taboos, and so on, even art and fashion.
>you wouldn't have bothered to post a comment at all if you were the nihilist you are posing as
Rejecting natural rights and understanding that rights are historical constructions doesn't mean one is disintered in rights.
I am very much interested in my right to my property, for example, and will vote, advocate, protest, demonstrate, etc, to maintain it.
I don't have to believe there's some inherent natural "right to property" for that. Just that I find the legal enforcement of one beneficial to me, and that I'd rather live in a society where it is enforced, as opposed to one where it's not.
it sounds like what you are interested in is negotiating mutually beneficial bargains with people, then, or manipulating public opinion in your favor, by applying the currently fashionable ethical norms (or at least appearing to do so) and attempting to shape them to your liking
in the former case, you don't seem to be offering to make any concessions (and in any case, how could you, in a public forum like this), and in the latter case, it seems like it would be in people's best interests to close their ears to you except when your arguments are factual (as opposed to normative); and possibly even then, if their interests are likely to run counter to yours, because selective reporting of facts can manipulate people to act against their own interests just as effectively as outright lies
that's what i mean by 'there would be no point in discussing ethical issues at all if moral relativism were correct'. there is certainly a point in negotiating agreements, or even evaluating who is likely to fulfill their negotiated commitments, but that isn't the same thing as discussing questions of ethics
attempting to return to the substantive questions, perhaps we would do well to promote pseudonymous and even anonymous online interaction (especially for media likely to be used by edgy and troubled teenagers) and not grant governments the ability to eliminate facts from the historical record piecemeal, like beria editing stalin's opponents out of photos
digital computing machines did not exist when philosophers and thinkers were busy coming up with and refining the concepts of rights between antiquity and relatively recent human history.
If you were familiar with the fallibility of human memory you wouldn't have made such a post
some of us practice sufficiently OK OPSEC to prevent this from becoming an issue but it doesn't mean that we don't have to look out for the greater good of society against unwarranted centralization of technological power.
feel free to breach such legislation if you deem it in your best interests
various people are posting irrelevant things about laws, missing the obvious ethical point
if anyone has the right to be forgotten, then nobody has the right to remember, and prohibiting people from remembering would be an appalling degree of totalitarianism (though not an unprecedented one: https://en.wikipedia.org/wiki/Censorship_of_images_in_the_So...)
that doesn't, of course, imply that it's praiseworthy to repeat everything true that you remember; that is lashon hara
with respect to which, there's an interesting halakhic discussion about whether portraying yourself in an accurate but very unfavorable light, as kitanata and 0ct4via have done in their comments, is also forbidden
ובספר עלי תמר על הירושלמי שם הביא סיפור על בעל החפץ חיים ז"ל שנסע ברכבת ופגש יהודי שלא הכיר שהוא החפץ חיים וסיפר לו שהוא נוסע לבקר אצל החפץ חיים בראדין והפליג בשבחו והחפץ חיים אמר לו למה אתה הולך אליו כי אינו גדול כמו שאתה חושב אלא הוא יהודי פשוט ואותו יהודי התרגז על דבריו וחרפו וגדפו והגיע לידי הכאה ואחר כך כאשר בא לבקר את החפץ חיים בביתו השתומם לגלות שהוא האיש שאיתו רב ברכבת ובקש מחילה ואמר לו החפץ חיים שאדרבה הוא אסיר תודה לו היות וכתב ספר שלם על הלכות לשון הרע ולא עמד על ההלכה שאסור לדבר לשון הרע גם על עצמו עד שהעמידו הוא על הדבר עכ"ל הסיפור וכתב עליו בעלי תמר שיש סמוכין לזה מהירושלמי הנ"ל. ואולם אין פוסקים הלכה מתוך סיפורים וכבר כתבתי שאין ראיה מהירושלמי ומה שלא עמד על הלכה זו בספר חפץ חיים אותו נקבל כי אכן לא נמצא שם אבל מה שמשמע שחזר בו ודן דין חדש לאיסור לא נאמין לזה בלי ראיות מש"ס ופוסקים ובעיקר הסיפור בשלמא אם היה אומר לנוסע אני החפץ חיים ואיני כמו שאתה חושב אלא אני יהודי פשוט שפיר דמי ולא היתה יוצאת מזה שום תקלה אלא הנוסע היה מוסיף לו אהבה בעד ענוותנותו היתירה אבל במה שהסתיר זהותו וכאילו דיבר סרה על אחר יש בו מראית עין של לשון הרע ועוד שהכשיל את הנוסע באיסור דאורייתא של גידוף והכאה אלא בודאי אין הסיפור אמת
In the book Alei Tamar on the Yerushalmi there he brings a story about the Chofetz Chaim, that he was traveling on a train and a Jew who did not recognize that he was the Chofetz Chaim met him and told him that he was traveling to visit the Chofetz Chaim in Radin and he was effusive in his praise. And the Chofetz Chaim said to him, "why are you going to him? He is not as great as you think; he is just a simple Jew." And that Jew got angry over these words and he disgraced him and cursed him and ended up hitting him. Afterwards, when he came to visit the Chofetz Chaim in his house, he was astonished to discover that this was the man he had been with on the train, and he requested forgiveness. And the Chofetz Chaim said that on the contrary he is thankful to him, for he had written an entire book about the laws of lashon hara but had missed the law that one must not speak lashon hara about oneself, until this fellow set him straight on this. This is the end of the story, and the Alei Tamar writes on it that there is support for it from the Yerushalmi mentioned earlier. However, we do not decide halacha from stories, and I have already written that there is no proof from the Yerushalmi. And that which [was mentioned in the story] that the Chofetz Chaim missed this law in the book Chofetz Chaim, we can accept because indeed it is not to be found there. But that which it implies that he retracted and judged the law anew for prohibitiveness we will not believe without proofs from the Gemara and Poskim. And with regard to the actual story it would have been fine had he said to the traveler, "I am the Chofetz Chaim and I am not like what you think; I am just a simple Jew" and no problem would have resulted. In fact the traveler would have increased his love on account of his extra humility. But that which he hid his identity and appeared to speak badly about someone else would be maris ayin of lashon hara, plus he caused the traveler to violate the biblical prohibition of cursing and hitting. Instead, the story is certainly untrue.
In recent years, I have not seen another tool that is so inflated. The attention it can garner for a tool where all it does is do simple things by adding attributes to html elements is really weird. Anyway, we need to act as if adding an attribute to the button and changing the value written in it is a very big need. Great job congratulations.
It can do a lot more than just changing the value written in a button.
I'd say that the hype is more centered around the fact that it helps you to do much more interactive and SPA-like websites without needing a full JS framework and on your favourite server stack, which is honestly really cool.
htmx has seen a surge in popularity, triggered by a video by fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) and a series of videos by ThePrimeagen, a popular twitch streamer on it
hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here:
https://htmx.org/essays
and in a book I authored with a few other writers that we recently released on hypermedia, htmx and a mobile hypermedia called Hyperview:
https://hypermedia.systems
while I am a fan of htmx, obviously, I think the deeper concept that it touches on is hypermedia, which is a worthwhile idea for people to explore even if they don't plan on using it in day-to-day programming.
There are also lots of other great hypermedia-oriented libraries worth checking out such as Hotwire from 37signals, or, my favorite after htmx, https://unpoly.com