Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx Is the Future

quii.dev

Post reply on HN
Print view View original

521–530 of 875 posts

Re: Htmx Is the Future

#521

Post by mdmglr »

ResearchCode wrote: post #514
PaulHoule wrote: post #277

Earlier quoted context omitted.

Ouch! I’ve worked in two kinds of organizations. In one of them when there is a ‘small’ ticket from the viewpoint of management, one programmer is responsible for implementation but might get some help from a specialist (DBA, CSS god, …) In the other a small ticket gets partitioned to two, three or more sub teams and productivity is usually reduced by a factor more than the concurrency you might get because of overhe…

Sounds like the problem is having "sprints". As far as I know, most teams at Google and Meta don't.

What do teams at google and meta practice?

Re: Htmx Is the Future

#522

Post by fogzen »

renerick wrote: post #509
fogzen wrote: post #506

Earlier quoted context omitted.

You touch on something that bugs me about these discussions: Lack of proof. Show me the web app with killer UX developed with htmx. Show me the product of the tools and processes being advocated.

I'm not a developer of either of these, but here are two examples: - https://htmx.org/essays/a-real-world-react-to-htmx-port/ by https://github.com/David-Guillot - a SaaS product migrated to htmx from React. - https://zorro.management/ by https://twitter.com/Telroshan - a kanban project management tool. This one is particularly interesting IMO, it implements quite advanced UI with htmx and some custom JS.

Thanks! I feel like these discussions would be so much more fruitful if they were centered around dissecting real products.

Re: Htmx Is the Future

#523

Post by MattyRad »

> ... requires a full page refresh to use ... isn't good enough for many types of web-app we need to make.

> without the annoying full-page load refresh.

This fixation on the page refresh needs to stop. Nearly every single website which has purportedly "saved" page refreshes has brutalized every other aspect of the UX.

This is a good article, and I agree that Htmx brings sanity back to the frontend, but somewhere along the line frontend folks got it in their head that page refreshes were bad, which is incorrect for essentially all CRUD / REST APIs. Unless you're specifically making a complex application that happens to be served through the web, like Kibana or Metabase, then stop harping on page refreshes.

Even this article calls it the annoying refresh. Not the impediment refresh, or the derisive refresh, or the begrieved refresh. Moreover, what exactly is annoying about page refreshes? That there's a brief flash? That it takes ~0.3 seconds to completely resolve?

Users don't care about page refreshes, and in fact they are an indication of normalcy. Upending the entire stack and simultaneously breaking expected functionally to prevent them is madness.

The killer feature of Htmx is that it doesn't upend the entire stack, and you can optimize page refreshes relatively easily. That's great! But even then I'm still not convinced the tradeoff is worth it.

Re: Htmx Is the Future

#524

Post by renerick »

doodlesdev wrote: post #328
tsuujin wrote: post #326

Earlier quoted context omitted.

> Please just use the damn fullstack JS frameworks, they make life simpler Strongest possible disagree. I’ve been doing web dev for a long time, and the last 10 years has seen a massive, ridiculous increase in complexity across the board. I personally took my company back to good old server rendered apps with a turbolinks overlay because I was sick of dealing with the full stack frameworks, and we saw a huge increase…

Hotwire is appropriate (I imagine you're not using actual Turbolinks which has been deprecated) with RoR or whatever stack you want, I agree it's great developer experience (despite Ruby and Rails being painfully slow haha). I wonder which full-stack JS framework you used that you thought made life harder? One of the things that gets me mad is the idea of putting it all in one single box, as React is indeed very (nee…

> if you ever need more than just the web-client (i.e. a mobile app, native or otherwise) since you will now have to implement an API anyway, which you could've done in the first place

Unless your new client is a hybrid/webview/electron application, it's a trap. APIs for web, for native and public API have different sets of constraints in terms of authentication, versioning, even features are probably gonna be different.

And it's not like building an API after you built web would be complicated. Unless you put your business logic right into controllers/handlers, making an API would be just making a new endpoint that calls to existing application services. It's not free, it may not be trivial, but like other comment said, if you can afford a new client, you probably can afford an API for it

Re: Htmx Is the Future

#526

Post by nologic01 »

BeefySwain wrote: post #215

I recently put together https://github.com/PyHAT-stack/awesome-python-htmx at PyCon. If anyone is looking to discuss making Hypermedia Driven Applications with HTMX in Python, head over to the discussions there!

Good initiative. HTMX + python hits a sweet spot for various interesting things.

Re: Htmx Is the Future

#527

Post by tommica »

chenster wrote: post #525

Please make up our mind. Why can't we just make a decision and stick to it? It's like something comes alone everything 12 month and claims it is 'better'.

Well, there is as many opinions as there is people, so consensus is a bit hard to reach...

Re: Htmx Is the Future

#529

Post by tommica »

Htmx seems really nice,but as far as I can see, it is messy to implement some kind of a state, f.x a button that can only be pressed if the other forms on the page have been saved.

Re: Htmx Is the Future

#530

Post by redonkulus »

pier25 wrote: post #442
redonkulus wrote: post #286

We've been using similar architecture at Yahoo for many years now. We tried to go all in on a React framework that worked on the server and client, but the client was extremely slow to bootstrap due to downloading/parsing lots of React components, then React needing to rehydrate all the data and re-render the client. Not to mention rendering an entire React app on the server is a huge bottleneck for performance (can'…

> simple client-side library based on HTML decorations has worked really well for us What library are you using?

We developed an internal library, but there are similar libraries in open source (although I can't remember their names).
Post reply on HN