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

271–280 of 875 posts

Re: Htmx Is the Future

#271

Post by chubot »

obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

Well at least the shitty MPAs will run on other people's servers, rather than shitty SPAs running on my phone and iPad

FWIW I turned off JavaScript on my iPad a couple years ago ... what a relief!

I have nothing against JS, but the sites just became unusably slow

Re: Htmx Is the Future

#272

Post by kokanee »

emodendroket wrote: post #243
kokanee wrote: post #210

Earlier quoted context omitted.

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.

I agree. These points are arguments against the philosophy of HTMX which asserts that you can get everything you need without client-side logic.

To be fair, I'm also not a fan of bloated libraries like React and Angular. I think we had it right 15-20 years ago: use the server for everything you can, and use the smallest amount of JS necessary to service your client-side needs.

Re: Htmx Is the Future

#273

Post by emodendroket »

yawaramin wrote: post #256
emodendroket wrote: post #187

Earlier quoted context omitted.

Why make a round trip if you don’t have to?

Why be on the internet at all? Why not distribute a desktop app that doesn't need any connectivity at all?

Presumably there are some features of the app that won’t work that way. Surely you’re not saying you prefer a Web app just for the sake of making calls.

Re: Htmx Is the Future

#274

Post by bottlepalm »

I tried HTMX. The static typing just isn't there between the components you send down and the rest of the page. This makes maintenance of a large HTMX app pretty costly. For simple stuff, it's probably fine, but large complicated web apps, I'm not seeing it. Mixing HTML fragments from the server into the client is pretty messy. Keeping all the rendering in one place à la React seems much simpler to maintain. With Next for example you can pre-render on the server, and re-render on the client - the same code is doing the rendering in both places so a bit more easier to understand.

Re: Htmx Is the Future

#275

Post by emodendroket »

kokanee wrote: post #272
emodendroket wrote: post #243

Earlier quoted context omitted.

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.

I agree. These points are arguments against the philosophy of HTMX which asserts that you can get everything you need without client-side logic. To be fair, I'm also not a fan of bloated libraries like React and Angular. I think we had it right 15-20 years ago: use the server for everything you can, and use the smallest amount of JS necessary to service your client-side needs.

It’s been a while since I did much frontend work but I actually found Angular revelatory. It makes it so easy and it’s really batteries-included.

Re: Htmx Is the Future

#276

Post by otreblatercero »

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…

I feel you. I'd love to have a tree that gives money, and I tried to, but somehow I had to implement many things, like invent a seed that can actually produce golden coins, I had to read about alchemy, seed hybridation... I just wanted to get money from a tree. But do not despair, while documenting my process, I found a revolutionary tool called Dreamweaver, I think it's the future, I think it would be terrific for your needs.

Re: Htmx Is the Future

#277

Post by PaulHoule »

v0idzer0 wrote: post #234
PaulHoule wrote: post #179

Earlier quoted context omitted.

I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…

It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…

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 overhead with meetings, documentation, tickets that take 3 sprints to finish because subtasks that were one day late caused the team to lose a whole sprint, etc.

People will defend #2 by saying thar’s how Google does it or that’s how Facebook does it, but those monopolists get monopoly rents that subsidize wasteful practices and if wall street ever asks for “M0R M0NEY!” they can just jack up the ad load. People think they want to work there but you’ll just get a masterclass in “How to kill your startup.”

Re: Htmx Is the Future

#279

Post by croes »

obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

>For instance, a major selling point of Node was running JS on both the client and server so you can write the code once.

You did write it once before too. With NodeJS you have Javascript on both sides, that's the selling point. You still have server and client code and you can write a MPA with NodeJS

Post reply on HN