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

281–290 of 875 posts

Re: Htmx Is the Future

#281

Post by quii »

pkelly wrote: post #249

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…

Thanks for taking the time to read the article :) A lot of the comments here seem to implying that I claim "htmx is the one hammer to solve all website needs", even when I explicitly say SPAs have their place in the article.

A hypermedia approach is the nice happy medium between a very static website and an SPA, not sure why so many people are close-minded about this possibility.

Re: Htmx Is the Future

#282

Post by quii »

yellowapple wrote: post #141

Using an HTTP header to decide between "just return a snippet for this specific list element" v. "return the whole page with the updated content for this list element" is an interesting choice that I hadn't really considered before; normally I would've opted for two entirely separate routes (one for the full page, one for the specific hypermedia snippet), which HTMX also seems to support. I guess it ain't fundamental…

I think both are valid, as i mentioned in the article, for this particular case, the psuedo content-negotiation felt right

Re: Htmx Is the Future

#283

Post by wwweston »

com2kid wrote: post #167
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…

> The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. MPAs break back buttons all the damn time, I'd say more often than SPAs do. Remember the bad old days when websites would have giant text "DO NOT USE YOUR BROWSER BACK BUTTON"? That is because the server had lots of session state on it, and hitting the browser back button would make the browser and server be out of syn…

> "DO NOT USE YOUR BROWSER BACK BUTTON"?

Yeah, state mutation triggered by GET requests is going to make for a bad time, SPA or MPA. Fortunately enough of the web application world picked up enough of the concepts behind REST (which is at the heart of all web interaction, not just APIs) by the mid/late 00s that this already-rare problem became vanishingly rare well before SPAs became cancerous.

> going back to change the order details would completely break the world and you'd have to re-enter all your shipping info. SPAs solve that problem very well.

The problem is entirely orthogonal to SPA vs MPA.

> If you are making a phone app, would you EVER design it so that the app downloads UI screens on demand as the user explores the app?

It's not only EVER done, it's regularly done. Perhaps you should interrogate some of the reasons why.

But more to the point, if it's bad, SPAs seem to frequently manage to bring the worst of both worlds, a giant payload of application shell and THEN also screen-specific application/UI/data payload, all for reasons like developer's unfortunately common inability to understand that both JSON and HTML are perfectly serviceable data exchange formats (let alone that the latter sometimes has advantages).

Re: Htmx Is the Future

#284

Post by hankchinaski »

everytime i see a custom new DSL i just bin the thing altogether, I dont want to learn a new DSL that will disappear in a year, it will be impossible to find documentation and community support for. just a big no for me. Apart from that seems like a good idea

>Here we are getting a bit fancy and only allowing one row at a time to be edited, using hyperscript. https://hyperscript.org

Re: Htmx Is the Future

#285

Post by themodelplumber »

listenallyall wrote: post #178
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…

HTMX is quite easy to code. Your prompt sounds rather generic, I mean, you can just serve 10 days of weather forecasts without any interaction whatsoever. https://www.wunderground.com/forecast/us/ak/north-pole It isn't clear what you were asking ChatGPT to provide, therefore not surprised it didn't come up with the exact answer you expected. I'd suggest learning HTMX by reading the docs, the majority is just a single…

ChatGPT made it very clear it understood exactly what I wanted, short of writing the code. The steps it offered were long, and far from generic. So. Why no code? It offers code for other langs all the time, even unprompted.

It was like...if you've ever been mansplained before, when you know how to code something, but are asking a specific question that interests you, related to the process of having a service do that part for you--and someone comes along like, "well, it's easy to code that yourself!"

Not sure if you've experienced that before but it's very similar.

Re: Htmx Is the Future

#286

Post by redonkulus »

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't wait for Server Components / Suspense which are supposed to make this better ... aside: we had to make this architecture ourselves to split up one giant React render tree into multiple separate ones that we can then rehydrate and attach to on the client)

We've moved back to an MPA structure with decorated markup to add interactivity like scroll views, fetching data, tabs and other common UX use cases. If you view the source on yahoo.com and look for "wafer," you can see some examples of how this works. It helps to avoid bundle size bloat from having to download and compile tons of JS for functionality to work.

For a more complex, data-driven site, I still think the SPA architecture or "islands" approach is ideal instead of MPA. For our largely static site, going full MPA with a simple client-side library based on HTML decorations has worked really well for us.

Re: Htmx Is the Future

#287

Post by mikece »

traverseda wrote: post #20
mikece wrote: post #7

"You can use whatever programming language you like to deliver HTML, just like we used to." Is this suggesting writing any language we want in the browser? I have wondered for a couple decades why Python or some other open source scripting language wasn't added to browsers. I know Microsoft supported VBScript as an alternative to JavaScript in Internet Explorer and had it not been a security nightmare (remember the w…

It is not suggesting running arbitrary languages in the browser. It's basically Ajax.

I hope the execution is better than Ajax! They way that was implemented in WebForms was horrible and a complete PITA to debug.

Re: Htmx Is the Future

#288

Post by rmorey »

CodeCompost wrote: post #280

I'm beginning to realise that AI assistance is now resulting in long and verbose articles like this one. The bullet points are especially off-putting.

then the problem begets its own solution - just use an assistant to summarize for you! \s

(i don't actually think this article is largely AI-generated)

Re: Htmx Is the Future

#289

Post by mattgreenrocks »

SoftTalker wrote: post #188
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 by definition the "average" team is not capable of writing a "great" app. So it doesn't matter so much what the technology stack is -- most of what is produced is pretty shitty regardless.

This is the real problem, and why I'd argue we've made little real progress in tooling despite huge investment in it.

The web still requires too much code and concepts to be an enjoyable dev experience, much less one that you can hold in your head. Web frameworks don't really fix this, they just pile leaky abstractions on that require users to know the abstractions as well as the things they're supposed to abstract.

It seems like it is difficult to truly move webdev forward because you have to sell to people who have already bought into the inessential complexity of the web fully. The second you try to take part of that away from them, they get incensed and it triggers loss aversion.

Re: Htmx Is the Future

#290

Post by themodelplumber »

yawaramin wrote: post #144
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…

You can write an htmx app in bash: https://www.youtube.com/watch?v=Jzcu4JheCtY

So are you saying that ChatGPT will probably offer to write an htmx app in bash?

> I'm sorry, but it's not possible to write a weather forecast app using bash and htmx as htmx is a client-side technology and bash is a command-line shell. htmx is typically used in conjunction with HTML and JavaScript to create dynamic web applications.

Cuz that didn't work. It straight up forged ahead and wrote a bash script to show the weather though.

I really wonder today if ChatGPT is going to cause a bash renaissance

(If you are telling me I can do this myself plz reread posts thx)

Post reply on HN