yawaramin

If you’re using htmx, I highly recommend an HTML generation technique in your backend that lets you easily componentize in the same way as you can with React. Eg, extracting common pieces of HTML markup into functions much like React components.

The reason is that htmx requires a certain amount of flexibility in the HTML generated by the backend. Eg, you need to be able to generate a certain piece of HTML markup and put a <title> tag immediately adjacent to it in some situations, and not in others. (Htmx updates the page title when it finds a <title> tag at the top level.)

This kind of flexibility is difficult with traditional string-based templating engines, but trivial with language-embedded HTML libraries.

Eg, if your backend is in JS then a tagged template literal function like https://github.com/WebReflection/uhtml-ssr

If it’s a Go backend then a library like https://www.gomponents.com/

If it’s Scala then ScalaTags. And so on, you get the picture. The point is that a language-embedded system allows you to use the full power of your language to build abstractions and components, which htmx really benefits from.

I typically just write them as plain old HTML files while I develop them. Then once I like the look and feel of a component or page I just convert it into a template. And Visual Studio Code’s HTML Preview extension has a hot reload feature, it works perfectly.

Ok, what’s an example of the complexity growing at 2:1 rate with htmx but not with Mantine?

What's an example of a UI that you built with Mantine that you couldn't with htmx?

Then don't trust it. Don't read it. Don't use it. But I don't get this obsession with trying to police and control everyone's use of AI. Hint: you can't control everyone. They're going to do what they want whether you like it or not. The only thing you can do is move on.

Quis custodiet ipsos custodes?

1a & b. Sure, but you wouldn't know that ahead of time. You'd have to wait until they finished the app.

2. It was enforced, just at a higher level (expensive fines triggered by customer complaints). A good engineer broke down and actually applied the constraints in a preventative way.

Also possible to just ignore interaction patterns that don't work well with HTML and replace them with ones that do.

I actually like the built-in stuff and the Constraint Validation API. I wrote about using it with htmx: https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg

How good are you at hammering nails with a screwdriver? Tools are important. We have a more apropos saying in our industry: use the right tool for the job. Don't let your brain get fried by the 'poor workman' adage, it's talking about the difference between an expensive tool and a cheap tool of the same kind, not two tools of different kinds entirely.

From The Article

FTA: 'To apply for their services, customers could either use an old ASP form on the website, or follow a manual process.'

No, it's actually people. FTA: 'My client was a utility company, and they had a big problem. To apply for their services, customers could either use an old ASP form on the website...'

Ie customers of the utility company were completing the form, not random users from the internet.

Doubling conversions, in digital marketing-speak. Marketing firms probably give out fat bonuses for this kind of result.

Also allows user scripts to interact with the forms, eg I can run a bookmarklet to fill out certain forms. With React controlled components all these changes are wiped out and reset with the state that React has in its app memory.

None of the increased traffic was from AI agents. FTA: 'The results? When we launched, the number of people completing the form doubled.'

All completions were real people. It's a government website.

1. Presumably the team that made the previous app also thought they knew what they were doing. Presumably they were not hired on the assumption that they couldn't make a good app.

2. The design constraints had always existed, the previous app just failed to meet them.

I'd rather not have to maintain lists of source files to compile by hand; dune eliminates this drudge work.

The OCaml ecosystem tried the Make route, it was complex, turns out no one likes maintaining makefiles by hand, and they like opaque make rules even less. Like it or not, dune exists for a very good reason.

Yeah, unfortunately, looks like they're `<div hx-get>`. This is exactly what I tell everyone to avoid in htmx: https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...

Hello, nice work. I recommend running Chrome's built-in Lighthouse analysis tool specifically for accessibility. It will make some very helpful suggestions, like img alt text and colour contrast issues. One example that I eyeballed is the search bar–the background colour is pink and the text colour is yellow. Kinda hard to read :-)

Passkeys don’t lock you into anything.

> With CSS names are global.

Not necessarily. Nested selectors make it pretty easy to apply styles in a modularized way. See https://rstacruz.github.io/rscss/

What does 'marker of affinity toward precision' mean?

But they're not entitled to their own facts.

No, it really doesn't scale that well. 'Thousands' of packages is laughable compared to the scale of npm. And even at the 'thousands' scale distros are often laughably out of date because they're so slow to update their packages.

You are of course right that a signed package ecosystem would be great, it's just that you're asking people to do this labour for you for free. If you pay some third party to verify and sign packages for you? That's totally fine. Asking maintainers already under tremendous pressure to do yet another labour-intensive security task so you can benefit for free? That's out of balance.

Are they incapable of doing it? Probably not. Does it take real labour and effort to do it? Absolutely.

I don't know about others but personally I'd like my electricity source to not be constantly degrading over time and requiring maintenance crews to go out and replace the panels as they randomly start falling below the required efficiency levels. I'd prefer if the entire production unit was a single all-inclusive compound maintained by the team on site, with a relatively compact ecological footprint.

If the solution is 'maintainers just need to do xyz', then it's not a solution, sorry. It's not scalable and which projects become 'successful' and which maintainers accidentally become critical parts of worldwide codebases, is almost pure chance. You will never be able to get all the maintainers you need to 'just' do xyz. Just like you will never be able to get humans to 'just' stop making mistakes. So you had better start looking for a solution that doesn't rely on humans not making mistakes.

> expected lifespan of >30 years

More like <25 years.

> I think being reliant on the fossil fuel supply chain for so long

France isn't. And they are net exporting their (nuclear fission) electricity to their neighbours who shut down nuclear power plants.

> the devs and other users keep telling me I shouldn't want that as a feature and that it "doesn't make sense"

I mean if the devs and the users are all telling you it doesn't make sense, maybe it really doesn't make sense. Not everything is supposed to be able to do everything. Some things are targeted and focused on specific use cases.