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

361–370 of 875 posts

Re: Htmx Is the Future

#361

Post by taeric »

kbenson wrote: post #238
jfvinueza wrote: post #225

Earlier quoted context omitted.

Mail is not a good example. Why would you like to read a collection of documents through A Single Page interface? Gmail was a fantastic improvement over Hotmail and Yahoo, and it provided UX innovations we still haven't caught up with, yes, but MPAs are naturally more suited for reading and composing them. Overriding perfectly clear HTML structure with javascript should be reserved for web experiences that are not do…

Mail is good for a SPA because the main central view which shows the different items (emails) to view or take an action on is based on a resource intensive back-end request, so keeping that state present and not having to refresh it on many of the different navigation actions yields a tremendous benefit. You could do some client side caching with local page data, but just keeping it present and requesting updates to…

I'm willing to wager that I get far more data loading Gmail than just an email or list of titles/senders.

That is, it may seem a fine optimization, but has led to a fairly bloated experience.

Re: Htmx Is the Future

#362

Post by tored »

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.…

Generally you don’t want to reuse the same API for different types of clients, you want backends for frontends (BFF) that are specialized for each use and can be moved forward in their own pace. The needs and the requirements differs a lot between a browser, app and server-to-server call.

And just because you serve HTML doesn’t necessary mean that you backend code is tightly coupled with the view code, HTML is just one adapter of many.

A boundary doesn’t get better just because you slip a HTTP barrier in between, this is the same type of misconception that has driven the microservice hysteria.

Re: Htmx Is the Future

#363

Post by themodelplumber »

nirav72 wrote: post #345
themodelplumber wrote: post #79

Thanks for the reminder, I've been meaning to try it out. Just to get started, I asked ChatGPT to write an htmx app to show a 10-day weather forecast. It described the general steps and seemed to be able to describe how htmx works pretty well, including hx-get and hx-target, etc., but then said "As an AI language model, I am not able to write full applications with code". I replied "do the same thing in bash" (which…

Was it with gpt 3.5 or 4?

3.5. I actually just tried the same prompt in playground > text-davinci-003 and it wrote the front end in htmx without any endpoint code, then when prompted it provided endpoint code.

Still looks to be missing something aside from just the api key...

    
      htmx.on('load', () => {
        const apiKey = '';
      });
...maybe 4 is way better. I thought I had a Plus account but it looks like API only.

Edit: Just tried 4 and it is better in the sense that it writes a more complete app for you, but it strangely separates the sections of the front end into discrete textareas w/ code, so if you are new to front end it'll be confusing for sure. "Where do I put all this" "oh actually it all gets run together; specifically these two sections of code are concatenated and placed in the body area of the first code section."

It also writes the endpoint code in Python and Flask by default, but with one more prompt it seems to have fixed all that.

I really wonder why 3.5, the common public interface, did what it did, when "actually writes code for more languages by default" isn't exactly on the Plus features list.

Re: Htmx Is the Future

#364

Post by willio58 »

brushfoot wrote: post #10

I use tech like HTMX because, as a team of one, I have no other choice. I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted. After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with J…

Angular is falling off hard in the frontend frameworks race. And I totally agree about how the boilerplate and other things about Angular feels bad to work with. Other frameworks are far easier to build with, to the point where a 1-person team can easily handle them. React is being challenged but still has the biggest community, it's a much better place to start than Angular when evaluating frameworks like this.

All that being said, I'm glad HTMX worked out for you!

Re: Htmx Is the Future

#366

Post by pphysch »

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.

> HTMX which asserts that you can get everything you need without client-side logic.

That's not true at all. HTMX extends the logical capabilities of HTML, and _hyperscript goes even further.

Re: Htmx Is the Future

#367

Post by tkiolp4 »

Frontend developers don’t want to write HTML nor augmented HTML. They want to write code, and these days that means JS. Frontend developers want to make good money (like those backend developers or even infrastructure developers who are working with data, servers, and cool programming languages), hence they need to work with complex libraries/frameworks (if you just write HTM?, you don’t get to earn much money because anyone can write HTM?).

Hell, the term “frontend developer” exists only because they are writing JS! Tell them it’s better to write HTM?, and you are removing the “developer” from their titles!

Same reason why backend developers use K8s. There’s little money on wiring together bash scripts.

Now, if you’re working on your side project alone, then sure HTMX is nice.

Re: Htmx Is the Future

#368

Post by kubota »

I don't know. The tabs example on the htmx page is perceptibly slow to me. Making a rest call every time I switch a tab, each time sending 90% of the same html skeleton data over the wire feels like a sin to me. Returning html from my api also feels like a sin.

Re: Htmx Is the Future

#369

Post by towawy »

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.…

This development style might be a better DX for the teams. But Facebook on the web is an absolute dumpster fire if you use it in a professional capacity.

You can't trust it to actually save changes you've made, it might just fail without an error message or sometimes it soft-locks until you reload the page. Even on a reliable connection. Error handling in SPAs is just lacking in general, and a big part of that is that they can't automatically fall back to simple browser error pages.

Google seems to be one of the few that do pretty good on that front, but they also seem to be more deliberate for which products they build SPAs.

Re: Htmx Is the Future

#370

Post by robertoandred »

jfvinueza wrote: post #225
RHSeeger wrote: post #61

Earlier quoted context omitted.

> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. or They're changing things because they're already so far from def…

Mail is not a good example. Why would you like to read a collection of documents through A Single Page interface? Gmail was a fantastic improvement over Hotmail and Yahoo, and it provided UX innovations we still haven't caught up with, yes, but MPAs are naturally more suited for reading and composing them. Overriding perfectly clear HTML structure with javascript should be reserved for web experiences that are not do…

JavaScript doesn't override perfectly clear HTML structure, it generates it.
Post reply on HN