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

211–220 of 875 posts

Re: Htmx Is the Future

#211

Post by PaulHoule »

yellowapple wrote: post #110
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…

> There is a time and place for SPA (mail is a great example). But using them in places where the page reload would load in completely new content for most of the page anyways? That's paying a large cost for no practical benefit; and your users are paying some of that cost. Yep. It's bonkers to me that a page consisting mostly of text (say, a Twitter feed or a news article) takes even so much as a second (let alone m…

I remember writing high complexity rich internet applications (knowledge graph editors, tools to align sales territories for companies with 1000+ salespeople, etc.) circa 2005. It was challenging to do because I had to figure out how to update the whole UI when data came in from asynchronous requests, I had to write frameworks a bit like MobX or redux to handle the situation.

Even before that I was making Java applets to do things you couldn't do with HTML, like draw a finite element model and send it to a FORTRAN back end to see what it does under stress, or replace Apple's Quicktime VR plugin, or simulate the Ising model with the Monte Carlo methods.)

What happened around 2015 is that people gave up writing HTML forms and felt that they had to use React to make very simple things like newsletter signups so now you see many SPAs that don't need to be SPAs.

Today we have things like Figma that approach the complex UI you'd expect from a high-end desktop app, but in many ways our horizons have shrunk thanks to "phoneishness" and the idea that everything should be done with a very "simple" (in terms of what the user sees) mobile app that is actually very hard to develop -- who cares about how fast your build cycle is if the app store can hang up your releases as long they like?

Re: Htmx Is the Future

#212

Post by tomhallett »

recursivedoubts wrote: post #124
tomhallett wrote: post #118

Earlier quoted context omitted.

have you seen any interest by the browsers to build htmx features as experimental browser features, with the goal of htmx features becoming browser standards? When looking at the various options, I always enjoyed your architectural choice of htmx being an extension of html, for that very reason. Similar to "phonegap" hoping that the phonegap code base would get smaller and smaller as mobile browsers built more of tho…

i haven't heard of any browsers implementing these features, but that's the right thing: they would be far more effectively implemented by the hypermedia client and it wouldn't be too much work technically my sense is that HTML is constrained by social/organizational issues rather than technical ones at this point hopefully someone on the chrome team notices htmx at some point and HTML starts making progress again

question - which parts of htmx would be better from an end-user-perspective if they were built into the browser? i assume "all features" might be a bit faster, but is there anything which would be night and day better if it wasn't a js library?

the browser vendors have been more than happy to use experimental features to chart their own course, which I think can be a good thing to spawn innovation and healthy competition. (given the standards bodies will be slower and more prudent - similar to how python doesn't want "pedantic" to be part of python core, because that would hurt pedantic's innovation, not improve it)

Maybe the way someone from the chrome team could tap into "business value" of "let's build these htmx features in chrome" would be that it allows developers to write "internal/developer/crud apps" where a "only supported in chrome" is acceptable.....

Re: Htmx Is the Future

#213

Post by zamadatix »

yawaramin wrote: post #131
obpe wrote: post #81

Earlier quoted context omitted.

I see, I have never implemented those types of validations. We do religiously deploy the same validation on client and server to explicitly avoid the mismatch of client/server validation. Having the client submit "valid" input only to have server reject it is something we have run into. Having only client side validation is something I have never run into. Also, in my opinion things like you suggest you shouldn't do.…

> A password strength metre is only going to give attackers hints at the passwords you have in your system No, it's not. A password strength meter just shows you the randomness of an input password, it doesn't have anything to do with passwords already in the system.

I'd agree with both takes on that it depends on the meter. Ones which truly approximate password entropy work like you say, however, for some reason, the most common use of such meters is to show how many dartboard requirements you've met while ignoring the actual complexity. When this common approach is used you combine "password must be 8 characters or more" with things like "password must have a number, symbol of ${group}, and capital letter" and the average password complexity is actually made worse for a given length due to pigeonholing.

In the full picture though, in terms of UI/UX, the meter seems like only a downside. In the dartboard use case it's great because it displays what's still needed in terms users work and think with signalling e.g. "you still need a number, otherwise you're all set". People don't really think in bits of entropy though so ll that really is being signaled by either a meter or a normal failed validation hint is "more complexity and/or length needed".

There may be good cases for using a meter while simultaneously implementing good password requirement policy I'm not thinking of though.

Re: Htmx Is the Future

#214

Post by pier25 »

lenkite wrote: post #176
pier25 wrote: post #109

Earlier quoted context omitted.

I agree but one important point to consider is the dev effort of making a proper SPA which is not a very common occurrence. "The best SPA is better than the best MPA. The average SPA is worse than the average MPA." https://nolanlawson.com/2022/06/27/spas-theory-versus-practi...

Extend that statement with "Only True Web Gods can create the Best SPA".

You joke but even Google with all its resources struggles to create proper SPAs.

I dread using the Google Cloud console for example.

Re: Htmx Is the Future

#216

Post by PaulHoule »

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…

It is totally possible to make MPAs where reloads are never a problem.

As for phone apps these are undeniably a step backwards from desktop apps, web apps and every other kind of app. On the web you can deploy 100 times a day, waiting for the app store to approve changes to your app is like building a nuclear reactor in comparison.

All the time you get harassed in a physical store or a web site to "download our mobile app" and you know there ought to be a steaming pile of poop emoji because the mobile app almost always sucks.

One of the great answers to the app store problem is to move functionality away from the front end into the back, for instance people were looking to do this with chat bots and super apps back in 2017 and now that chatbots are the rage again people will see them as a way to get mobile apps back on internet time.

Re: Htmx Is the Future

#217

Post by dfabulich »

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…

> Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection.

> It's basically the speed of the network.

Does your stuff work on mobile web? Mobile web requests can easily take seconds, and on a dodgy connection, a single small request can often take 10+ seconds.

The difference between optimistic UI and non-optimistic UI on mobile web is the difference between an app that takes seconds to respond, on every click, and one that responds instantly to user gestures.

Re: Htmx Is the Future

#218

Post by recursivedoubts »

lucasyvas wrote: post #209
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…

You're on the money with this assessment. It's all bandwagon hopping without any consideration for reality. Also, all these things the author complains about are realities of native apps, which still exist in massive numbers especially on mobile! I appreciate that some folks only need to care about the web, but declaring an architectural pattern as superior - in what appears to be a total vacuum - is how we all colle…

agreed:

https://htmx.org/essays/when-to-use-hypermedia/

Re: Htmx Is the Future

#219

Post by BeefySwain »

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…

The people using HTMX have never heard of stateofjs.com (though they are painfully aware of the state of js!)

Re: Htmx Is the Future

#220

Post by withinboredom »

gpapilion wrote: post #208
pphysch wrote: post #18

Earlier quoted context omitted.

Client side validation is for UX. Server side validation is for security, correctness, etc. They are different features that require different code. Blending the two is asking for bugs and vulnerabilities and unnecessary toil. The real reason that SPAs arose is user analytics.

I actually tend to think of it to add feature degradation and handle micro service issues. It always seemed better to have the client manage that, and more graceful.

The number of SPAs that implement their own timeouts when I'm stuck on 2G networks is non-zero and incredibly annoying. The network socket has a timeout function, just because you 'time out' doesn't mean the network timed out, that data is still being transferred and retrying just makes it worse.
Post reply on HN