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

431–440 of 875 posts

Re: Htmx Is the Future

#431

Post by detaro »

ragall wrote: post #388
adrr wrote: post #125

Earlier quoted context omitted.

I don't understand how spa is different than vanilla web app in terms of user analytics? A beacon is a beacon. Whether its img tag with a 1x1 transparent gif or an ajax call. Also validation is usually built on both client and server for the same things. Like if you have a password complexity validation. Its both on UX and the server otherwise it will be a very terrible UX experience.

A SPA can track the mouse cursor, as well as stealing form content that was left unsubmitted.

an MPA can use javascript that does exactly the same.

Re: Htmx Is the Future

#432

Post by kbenson »

alethiophile wrote: post #377
kbenson wrote: post #238

Earlier quoted context omitted.

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…

What exactly is the resource-intensive request here? Loading an E-mail, or list of E-mails? I don't see why that should be any more resource-intensive than any other CRUD app.

A list of emails. That's essentialls a database query that is taking X items and sorting by the date field, most commonly, except that the average user can have thousands, or even tens or hundreds of thousands of items that are unique to them in that dataset that need to be sorted and returned.

Sure, gmail optimizes for this heavily so it's fast, but it's still one of the most intensive things you can do for an app like that, so reducing the amount of times you need to do that is a huge win for any webmail. If you've ever used a webmail client that's essentially just an IMAP client for a regular IMAP account, you'll note that if you open a large inbox or folder it's WAY slower than trying to view an individual message, most times, for what are obvious reasons of you just think of a mailbox as a database of email and the operations that need to happen on that database (which it is).

If clicking on an individual message is a new page, that's fine, but if going back to the main view is another full IMAP inbox query, that's incredibly resource intensive compared to having it cached in the client already (even if the second request is cached in the server, it's still far more wasteful than not having to request it again).

Re: Htmx Is the Future

#433

Post by kbenson »

taeric wrote: post #361
kbenson wrote: post #238

Earlier quoted context omitted.

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.

You're thinking just of the amount of data sent, not the amount of work that's done on the back end. Just because it's only showing you the most recent 40 messages or something doesn't mean it isn't doing a significant amount of work on the back end to determine what those messages are. Not having to scan through all your email and sort by date nearly as often is a significant win.

Re: Htmx Is the Future

#434

Post by detaro »

RHSeeger wrote: post #61
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…

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

my favorite example is dev.to. A (web-)developer-centric site, open-source nowadays. In a similar discussion years ago it was praised as well-done SPA. Everytime the topic comes back up again I spend 5 minutes clicking around, it every time I find some breakage of a page being critically broken during a transition, not being the page the URL-bar says it is, ... because having a blogging site just be pages navigated by the browser was too easy.

Re: Htmx Is the Future

#435

Post by marcosdumay »

hdjjhhvvhga wrote: post #321
marcosdumay wrote: post #294

Earlier quoted context omitted.

Back in the late 90's and early 00's, armed with the experience of C, C++, Bash, and Perl, everybody knew it very clearly that "batteries included" is the correct way to create development tools. I don't know about the current fashion of minimalism comes from. It doesn't bring simplicity.

> C, C++, Bash, and Perl While I agree with your comment, lumping these together somehow doesn't seem fair. As for C and C++, it took decades to develop package managers, and we can't still say we have standard ones (but I feel Conan is a de facto standard PM for C++). Bash, on the other hand, should never have 'batteries included' because in this case the batteries are the rest of the system - coreutils and the rest…

C is completely without batteries, the stdlib for C++ was a great change and a big force towards people adopting it. The same happened with Bash and Perl (and people did migrate a lot of things into the later).

Re: Htmx Is the Future

#436

Post by synergy20 »

htmx is ajax wrapped in html to me.

it does not work for resource restricted (i.e. embedded) devices where you just can't do server-side rendering, CSR SPA is the future there as the device side just need return some json data for browser to render.

Re: Htmx Is the Future

#437

Post by fridgemaster »

recursivedoubts wrote: post #39

i am the creator of htmx, this is a great article that touches on a lot of the advantages of the hypermedia approach (two big ones: simplicity & it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn't the best server side option) hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more rele…

>simplicity

Can be achieved in MPAs and SPAs alike. I'd also argue that having state floating around in HTTP requests is harder to reason about than having it contained in a single piece in the browser or in a server session. Granted this is not a problem of HTMX, but of hypermedia. There is a reason why HATEOAS is almost never observed in REST setups.

> two-codebase problem

This is a non-problem. In every part of a system, you want to use the right tool for the job. Web technologies are better for building UIs, if only by the sheer ammount of libraries and templates that already exist. The same splitting happens in the server side: you would have a DB server, and a web service, maybe a load balancer. You naturally have many parts in a system, each one being specialized in one thing, and you would pick the technologies that make the most sense for every one of them. I'd also argue that backend developers would have a hard time dealing with the never ending CSS re-styling and constant UI change requests of today. This is not 2004 where the backend guys could craft a quick html template in a few hours and went back to work in the DB unmolested. The design and UX bar is way higher now, and specialists are naturally required.

Re: Htmx Is the Future

#438

Post by doodlesdev »

tsuujin wrote: post #386
doodlesdev wrote: post #328

Earlier quoted context omitted.

Hotwire is appropriate (I imagine you're not using actual Turbolinks which has been deprecated) with RoR or whatever stack you want, I agree it's great developer experience (despite Ruby and Rails being painfully slow haha). I wonder which full-stack JS framework you used that you thought made life harder? One of the things that gets me mad is the idea of putting it all in one single box, as React is indeed very (nee…

> I wonder which full-stack JS framework you used that you thought made life harder? I’ve used Angular, Dart, Backbone, Ember, Elm, React, Vue, Svelte, and a few others I can’t remember anymore. All in production systems, not demo projects. Also some of the “build it once” platforms like Meteor. They’re all cool until you have to actually maintain them. My favorite part is having to build my data models twice, one fo…

   > I’ve used Angular, Dart, Backbone, Ember, Elm, React, Vue, Svelte, and a few others I can’t remember anymore. All in production systems, not demo projects. Also some of the “build it once” platforms like Meteor.
That's quite a lot of libraries lol, I guess no one can say you just haven't found the right library

I must admit I've used Hotwire much less than I should've, but I still feel comfortable with full-stack JavaScript (or rather, TypeScript).

You said you migrated back to Turbo, what backend framework do you use? RoR with Hotwire is so nice, but I personally avoid it because of Ruby (not personally a fan), to be fair the same is true for most full-stack frameworks I avoid (such as Django/Python).

Re: Htmx Is the Future

#439

Post by pier25 »

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…

> 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? That'd be insane.

Good luck forcing users to download 50MB before they can use your web app.

The web and mobile/desktop apps are two totally different paradigms with different constraints.

Re: Htmx Is the Future

#440

Post by agrippanux »

fridgemaster wrote: post #421
willio58 wrote: post #364

Earlier quoted context omitted.

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…

Angular 2 works fine out of the box, and already provides a good architecture that noobs struggle to come up with in "freestyle" solutions like React. Angular's bi-directional binding is way superior and simpler to use vs React's mono-directional binding: you can just use bound variables, no need to do complicated setState or use abominations like Redux. Vue also has bi-directional binding. Essentially there are many…

You may of not used React in the past few years, but setState fell out of favor a while ago with the release of the useState hook and Redux (which I agree is an abomination) isn't necessary for 95% (imo) cases, again thanks to hooks.

For bound variables you can use MobX or signals in Preact.

Post reply on HN