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.
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.
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.
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
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.
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.
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'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.
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.
> 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!
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...
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.
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.
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...
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.
>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.
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.
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>`.
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).
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.
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.
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)
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.
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
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 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.
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.
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.
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.
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 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?
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)
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.
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.
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.
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.
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.
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 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..
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 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.
:) 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'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?
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
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.
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.
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
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.
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.
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.
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
> “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
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
— 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 t...
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
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
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.
"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.
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
>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
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”.
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.
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, un...
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.
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'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
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.
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.
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.
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.
519 comments
[ 2.8 ms ] story [ 296 ms ] threadDoes anyone know what they have on the roadmap for 2.0? I'm curious what they are working towards.
1. https://htmx.org/discord
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.
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
Could I have made it work? Yes
Could I have just made the map it's own self-sufficient component and left the rest of the app as is? Also yes
Did I do these things? No. As one tends to do, I just nuked it and started over
Solution 3 gave me a good laugh though.
Also, no compilation step, so no need for npm, etc
https://api.jquery.com/category/ajax/
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.
This is a complete non-issue in unpoly as you can have multiple targets:
https://unpoly.com/targeting-fragmentsHTMX gets a lot of attention, but I think it's not the best option in its field.
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.
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.
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.
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.
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'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!
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...
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.
Good times.
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.
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.
Sorry, poetic diversion.
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.
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...
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 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.
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.
^_O
We can agree to disagree about readability though, I have a lot of trouble groking long class=“…” strings.
This is still what you're doing with any components, only the CSS is localized to the component vs. its usage.
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.
> forget what name I had decided on
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.
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.
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.
There are a ton of ways to solve this issue but most people just look at tailwind on the surface and go shitpost about it on social media.
Its the equivalent of saying "I wrote this 2k line program in one file, its so bad and disorganized <insert language here> is bad!"
Look at this here and the ridiculous extent they insist on "NO, YOU MUST COPY AND PASTE ZEH STYLES!": https://tailwindcss.com/docs/reusing-styles
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.
You are in an abusive relationship. Seek counsel.
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.
Could you elaborate?
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)
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.
This is a regression on graceful degradation.
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.
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
https://htmx.org/essays/a-real-world-react-to-htmx-port/
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 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.
I mention C# in that ASP.Net MVC + Razor seems like a very clean match to the HTMX paradigm.
I've gone to the home page it poorly explains what it is and doesn't say why would you want to use something like this.
Seems like another distraction.
There's a stable implementation for PHP too.
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.
Is this HATEOAS?
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?
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.
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.
I hear that you and your band have sold your guitars and bought turntables.
I hear you rewrote your http endpoints to return JSON because that was REST.
I hear that you and your band have sold your turntables and bought guitars.
I hear you rewrote your http endpoints to return templated html fragments because that was HATEOAS.
I'm losing (regaining/losing/regaining) my edge
I'm pitching a mobile app built in Unity and a custom ruby backend on digital ocean.
They questioned my tech choices on a working app! Apparently if you want VC money you must use their approved tech stacks.
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.
But I do appreciate that you tried to parse it.
It's some lyrics from an LCD Soundsystem track with some topical snark mixed in
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)
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.
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.
Like angular, react got the huge initial boost in popularity because of the brand behind it.
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.
Time to go snow skiing in hell, I guess. It's deeply frozen over.
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.
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.
Ironic considering what the OP attributes to HTMX's current popularity.
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.
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 went to a series of JavaScript conferences and React is extremely diverse.
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.
I certainly do.
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.
Htmx is JS in string.
Goodluck stringify :))
Exactly. It can serve HTML partials, or utilize `hx-select` attribute to extract required elements from a full page
> Is there a simple example of a static site using Htmx somewhere?
Not that I'm aware of unfortunately
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.
Or am I missing something?
How likely is it every API will adhere to that though?
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.
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.
https://developers.cloudflare.com/cache/concepts/cache-contr...
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 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.
https://github.com/simonw/datasette/issues/1534
Anyway, I guess this is yet another reason to not use cloudflare. Thanks for your comment.
[0] https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
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.
Not that the comments are “wrong” but it feels slightly contradictory, in a way.
It's not a startup accelerator - it's a part of GitHub's efforts to support open source projects with funding and mentorship.
people who egregiously abuse the site like that may be less likely to get cooperation in concealing their abuses
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 ;)
> All you've done above is make baseless assumptions and imply accusations against kitanata with no basis or merit.
though you see nothing wrong with their behavior, kitanata has been banned from the site for abuse two hours ago as explained in https://news.ycombinator.com/item?id=37150880
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
nothing you say can be unsaid; therefore speak judiciously
https://uuliveoak.org/Story%20ideas%20-%20service%20or%20cla...
> “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
> The right to erasure is also known as ‘the right to be forgotten’.
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-re...
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
— 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.
(https://www.archives.gov/founding-docs/declaration-transcrip... the US Declaration of Independence, expressing the motivation for independence from Europe)
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.
https://www.un.org/en/about-us/universal-declaration-of-huma...
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 t...
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
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.
"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]
[1] https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-re...
[2] https://gdpr.eu/right-to-be-forgotten/
https://support.google.com/legal/answer/10769224
https://en.wikipedia.org/wiki/Right_to_be_forgotten
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'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.
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
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.
(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
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.
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
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”.
Feel free to Geoblock the entire market if you disagree. Many small news sites in the states do this.
If I’m an EU citizen accessing a site from outside the EU, don’t I still have the right to be forgotten?
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?
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.
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.
[1] https://news.ycombinator.com/item?id=37149287
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.
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
https://judaism.stackexchange.com/questions/30372/lashon-har...
ובספר עלי תמר על הירושלמי שם הביא סיפור על בעל החפץ חיים ז"ל שנסע ברכבת ופגש יהודי שלא הכיר שהוא החפץ חיים וסיפר לו שהוא נוסע לבקר אצל החפץ חיים בראדין והפליג בשבחו והחפץ חיים אמר לו למה אתה הולך אליו כי אינו גדול כמו שאתה חושב אלא הוא יהודי פשוט ואותו יהודי התרגז על דבריו וחרפו וגדפו והגיע לידי הכאה ואחר כך כאשר בא לבקר את החפץ חיים בביתו השתומם לגלות שהוא האיש שאיתו רב ברכבת ובקש מחילה ואמר לו החפץ חיים שאדרבה הוא אסיר תודה לו היות וכתב ספר שלם על הלכות לשון הרע ולא עמד על ההלכה שאסור לדבר לשון הרע גם על עצמו עד שהעמידו הוא על הדבר עכ"ל הסיפור וכתב עליו בעלי תמר שיש סמוכין לזה מהירושלמי הנ"ל. ואולם אין פוסקים הלכה מתוך סיפורים וכבר כתבתי שאין ראיה מהירושלמי ומה שלא עמד על הלכה זו בספר חפץ חיים אותו נקבל כי אכן לא נמצא שם אבל מה שמשמע שחזר בו ודן דין חדש לאיסור לא נאמין לזה בלי ראיות מש"ס ופוסקים ובעיקר הסיפור בשלמא אם היה אומר לנוסע אני החפץ חיים ואיני כמו שאתה חושב אלא אני יהודי פשוט שפיר דמי ולא היתה יוצאת מזה שום תקלה אלא הנוסע היה מוסיף לו אהבה בעד ענוותנותו היתירה אבל במה שהסתיר זהותו וכאילו דיבר סרה על אחר יש בו מראית עין של לשון הרע ועוד שהכשיל את הנוסע באיסור דאורייתא של גידוף והכאה אלא בודאי אין הסיפור אמת
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, un...
https://news.ycombinator.com/newsguidelines.html
* 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
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.
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.
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.
something like this is complex enough to require some front end scripting, which I am not opposed to:
https://htmx.org/essays/hypermedia-friendly-scripting/
For the second part you probably go with your own javascript or get away with hyperscript
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.