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

241–250 of 875 posts

Re: Htmx Is the Future

#241

Post by koromak »

jgoodhcg wrote: post #186
dfabulich wrote: post #56

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for what happens when one component in a tree needs to update another component in the tree HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page…

My app would crash and burn without optimistic UI. For simple CRUD applications sure, but most products these days aren't CRUD apps anymore.

Re: Htmx Is the Future

#242

Post by tacone »

I used to have my hand-written mini version of htmlx ten years ago. It took a few jquery lines of code to have small parts of the UX to update without refresh.

I don't see the point by the way, I think htmlx is here to stay and a good choice for many, but it's clearly not a silver bullet. You make decently fast UIs, not blazing fasts, there are no (proper) offline first apps with htmlx, caching is likely more difficult or impossible sometimes and the load for your server is inevitably greater (of course it could be more than acceptable in some cases, so why not?), that also means more bandwidth for your cloud provider as opposed for you cdn. You will still have to write javascript sooner or later.

It depends on what you're doing. Nothing is aprioristic ly "the future", the future is "the future", and it has yet to come.

Re: Htmx Is the Future

#243

Post by emodendroket »

kokanee wrote: post #210
emodendroket wrote: post #82

Earlier quoted context omitted.

I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).

There are two things that engineers tend to neglect about validation experiences: 1) When you run the validation has a huge impact on UX. A field should not be marked as invalid until a blur event, and after that it should be revalidated on every keystroke. It drives people crazy when we show them a red input with an error message simply because they haven't finished typing their email address yet, or when we continu…

Even if you’re not A/B testing you’re going to have some validations that only happen server-side because they require access to resources the client doesn’t have, but I don’t see either of these points as arguments against sharing the validators that can be.

Re: Htmx Is the Future

#244

Post by emodendroket »

sidlls wrote: post #240
emodendroket wrote: post #78

Earlier quoted context omitted.

Man... if you don't think node.js on the backend is mainstream at this point I don't know what to tell you. It's not even the hyped-up new thing anymore.

Being not hyped up doesn’t mean it’s mainstream. Most backends are in Java, Go, or PHP. Python and Ruby take up most of those that aren’t. It’s rare to find node on the backend in comparison.

I don’t agree that Go is more common than node (or other options you did not mention like .NET).

Re: Htmx Is the Future

#245

Post by neurostimulant »

0xbadcafebee wrote: post #115

I just want Visual Basic for the web man. Screw writing lines of code. I want to point and click, drop complex automated objects onto a design, put in the inputs and outputs, and publish it. I don't care how you do it, I don't want to know any of the details. I just want to be able to make things quickly and easily. I don't care about programming, I just want to get work done and move on with my life. At this rate, w…

So, do you want to run a winform app in a browser? Behold! https://github.com/roozbehid/WasmWinforms

https://news.ycombinator.com/item?id=18981806

Re: Htmx Is the Future

#246

Post by adamckay »

fogzen wrote: post #134

Server-side apps cannot provide optimistic UI. No matter how you feel about it, they are limited in this capability compared to client-side apps. The user doesn’t care about the technology. For example, imagine a todo app that shows a new todo immediately. Or form validations that happen as soon as data is entered. That’s a superior experience to waiting on the server to continue interaction. Whether that’s harder to…

You don't have to be restricted to just using htmx, you can use it with client side Javascript to give you that interactivity you need in the places you need it.

Indeed, the creator of htmx has created another library called hyperscript which he's described as a companion to htmx.

https://hyperscript.org/

Re: Htmx Is the Future

#247

Post by antoniuschan99 »

qgin wrote: post #195
dfabulich wrote: post #56

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

It's interesting that this paradigm is especially popular on Hacker News. I see it pop up here pretty regularly and not many other places.

lol HN itself seems like it should be the poster child of htmx :P. It's literally just text.

Re: Htmx Is the Future

#248

Post by pwpw »

What is the simplest way to host a website closer to barebones HTML, CSS, and a bit of JS with reusable components like nav bars? My experiences handling those manually leads to too much overhead as I add more pages. SvelteKit makes things fairly easy to organize, but I dislike how the user isn’t served simple HTML, CSS, and JS files. Ideally, I don’t want to use any framework.

Re: Htmx Is the Future

#249

Post by pkelly »

Thank you for writing this article! I've had similar thoughts for the past 5 years or so.

A lot of the comments here seem to have the approach that there is a single best stack for building web applications. I believe this comes from the fact that as web engineers we have to choose which tech to invest our careers in which is inherently risky. Spend a couples years on something that becomes defunct and it feels like a waste. Also, startup recruiters are always looking for the tech experience that matches the choice of their companies. VCs want to strike while the iron is hot.

Something that doesn't get talked about enough (which the author does mention near the end of article) is that different web apps have different needs. There is 100% a need for SPAs for certain use cases. Messaging, video players, etc. But there are many cases where it is overkill, like the many many CRUD resource apps I've built over the years. Say you have a couple hundred users that need to manage the state of a dozen interconnected resources. The benefits of an MPA are great here. Routing is free, no duplication of FE / BE code. Small teams of devs can ship code and fix bugs very fast which keeps the user feedback loop tight.

Re: Htmx Is the Future

#250

Post by antoniuschan99 »

dfabulich wrote: post #56

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

But isn't React going this route as well? There was some talk a week or so back with the React team talking about this direction.

Also, it seems so cyclic, isn't HTMX/Hotwire similar to Java JSP's which was how things were before SPA's got popular?

Post reply on HN