Live data from Hacker News

Htmx 4.0

four.htmx.org

101–110 of 217 posts

Re: Htmx 4.0

#101
post #38

Earlier quoted context omitted.

Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise. Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.

Thinking about whether a web architecture will hold up for 100 years is bikeshedding, is bikeshedding as well

Only if you don’t know what bikeshedding is and want to broaden the definition so much that it’s meaningless.

This is Hacker News. This is exactly the place to tell people they’re overanalyzing and should just build something.

Re: Htmx 4.0

#102
post #73

Earlier quoted context omitted.

There is something here, but I am not sure if it's the whole story: https://htmx.org/essays/lore/

One of the things that is great about htmx (besides being the best library) is the lack of modern silicon valley corpo communication. It has the slightly unhinged feel of a nerd that spent too much time on Newgrounds or 4chan or something awful. Which is how the internet aught to be.

> unhinged

Please take a look at the official documentation for htmx, which specifically clarifies that the author owns many hinges.

Re: Htmx 4.0

#103
post #38

Earlier quoted context omitted.

Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise. Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.

> RoR and so poorly planned that it’s still biting Microsoft on a regular basis. Disagree. The RoR front end was way more stable and usable than the mess they have made now.

The issues are with the Ruby backend.

RoR is the only framework I’ve ever heard of being so bad that it killed startups. I personally know of two that were doing well, but RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is compounded by Ruby devs being pretty rare.

Re: Htmx 4.0

#104
post #38

Earlier quoted context omitted.

Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise. Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.

100 years, sure, but 10 years? Definitely not bike shedding, I'd hope your website can stay up for 10 years at least.

You don’t need to agonize over a library choice to know that your site will be up for 10 years. If it outputs web standards, the browser engines will make sure it is.

Re: Htmx 4.0

#105

Earlier quoted context omitted.

I call it the GOSH stack (Go Sqlite Htmx) but HUGS is good too.

Or HAGS (HTMX, AlpineJS, Go, SQLite).

Someone asked about using htmx with php on reddit, and was recommended a HAYW (Hypermedia on Anything You Want) stack.

Re: Htmx 4.0

#107
post #7

Congrats and thanks! htmx brings me joy. Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive. I put a few more thoughts about this here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...

I call it the GOSH stack (Go Sqlite Htmx) but HUGS is good too.

Or RASX (Rust Axum Sqlite Htmx)

Skill.md here: https://github.com/dunctk/rasx-app-framework

Re: Htmx 4.0

#109
Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX).

This is not a criticism but I suspect that the people enjoying HTMX are either people preferring old-school server-side rendering or react users.

Just sharing my experience, because HTMX is the absolute darling of hacker news.

Since i mainly develop real SPA, i found that is more complex than just using typscrpit if you build something non-trivial as managing state on the server is not fun at all.

In my opinion if you are happy using angular, you'll find that HTMX is a step backward in terms for dev experience. Can't speak about react, but since it is not a battery included stack unlike Angular, i can understand why many people find they'd be better off moving things server-side instead of messing around with 15 third-party libraries. My 2 cents

Re: Htmx 4.0

#110
A thoughtful, clean, and useful library that wasn't built to climb the corporate ladder. It grew organically. I think it became a cry of relief for those annoyed by unnecessary complexity, which also boosted its recognition. It served as a starting point for things like Datastar, too. I believe it brought a refreshing breath of air to the frontend landscape.
Post reply on HN