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

501–510 of 875 posts

Re: Htmx Is the Future

#501

Post by iainmerrick »

pphysch wrote: post #111
blowski wrote: post #44

Earlier quoted context omitted.

> The real reason that SPAs arose is user analytics. Can you go into that a bit? I don't really understand what you mean.

HTML gives very limited tools for tracking what a (potentially JS-less) user is doing. There are various tricks, like "link shorteners" and "magic pixels" that allow some tracking. But if you want advanced tracking, like tracking what a user is focusing on at a particular instant, you need to wrap the whole document in a lot of JS. SPA frameworks came out of AdTech companies like Meta, and I assure you it wasn't beca…

That’s a good and logical story, but it doesn’t match the reality in my experience.

Companies use SPA frameworks for the same reason they use native apps, to make a “richer”, more responsive, more full-featured UI.

Analytics is typically done in a separate layer by a separate team, usually via Google Tag Manager. There might be a GA plugin for your UI framework, but it can work equally well with plain HTML. GA does use a bunch of client-side JS, yes, but it’s not really a framework you use on the client side, it’s just a switch you flip to turn on the data hose.

In my experience, trying to add analytics cleanly to clientside UI code is a complete pain. Trying to keep the analytics schema in sync as the UI evolves is really hard, and UI developers generally find analytics work tedious and/or objectionable and hate doing it.

Google Tag Manager is the big story in adtech, and I think it comes from and inhabits a completely different world from Angular, React etc.

Re: Htmx Is the Future

#502

Post by narag »

berkes wrote: post #376
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…

Even worse: Client-side validation and server-side validation (and database integrity validation) are all their own domains! I call all of these "domain logic" or domain validation just to be sure. Yes, they overlap. Sure, you'll need some repetition and maybe, indeed, some DSL or tooling to share some of the overlapping ones across the boundaries. But no! They are not the same. A "this email is already in use" is se…

A "this doesn't look like an email-address, did you mean...

Stop right there.

I'm tired of receiving mail from people that gave my email address as if it was their own.

Never ever accept an email address unless you can instantly confirm it's valid sending an email and waiting for an answer. If the user can't access their email on the spot, just leave it blank and use another data as key.

I wish they included that in GDPR or something.

Re: Htmx Is the Future

#503

Post by AtlasBarfed »

ok look people.

I think what is needed is to recognize that the SPA architecture isn't actually just a view processor. IMO it is a very shitty designed:

View rendered client process server process

So it seems that SPA apps load an absolute mountain of javascript into the view (the tab/page) and then that starts (crudely IMO) running as client-side daemon tracking messy state and interfacing with local storage, with javascript (opinion: yuck) ferreted away in a half dozen divs.

IMO, what has been needed since you have local storage and local session state and all that is ... a client daemon that the web page talks to that offers data services, and then that client daemon if it needs server data calls to the internet.

That way local state tracking, transformation, and maintenance can be isolated away from the code of the view. Large amounts of javascript (or maybe all with CSS wizardry is dropped). The "client daemon" can be coded in webassembly, so you aren't stuck with javascript (opinion: yuck).

You can even have more efficient many views/tabs interfacing with the single client daemon, and the client daemon can track and sync data between different tabs/views/windows.

Now, of course that is fucking ripe as hell for abuse, tracking. Not sure how to solve it.

But "separation of concerns" in current web frameworks is a pipe dream.

Re: Htmx Is the Future

#504

Post by sublinear »

recursivedoubts wrote: post #29
sublinear wrote: post #25

> SPAs have allowed engineers to create some great web applications, but they come with a cost: ... Managing state on both the client and server Having a separation of concerns between server and client is the whole point, and replacing JSON APIs with data trapped in HTML fragments is a massive step backwards.

https://htmx.org/essays/splitting-your-apis/

What if we need the same backend to be usable by more than one client? What if those clients aren't even a SPA, but a wrapper library, or a native app? What if we need internal scripts that manage the content in the backend using the same API? What if we need to redesign the client without touching the backend?

HTMX doesn't address any of that. YAGNI is often only true for the original developers, not everyone else who has to maintain it long term.

Re: Htmx Is the Future

#505

Post by nsonha »

PaulHoule wrote: post #179
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…

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…

Can you argue a bit more genuinely and not pick on such a minor point as validation? I think parent mentioned other points? How about the logical shift to let client do client things, and server do server things? Server concatting html strings for bilions of users over and over again seems pretty stupid.

Re: Htmx Is the Future

#506

Post by fogzen »

chrsjxn wrote: post #335

I love articles like these, because the narrative of "JS framework peddlers have hoodwinked you!" is fun, in an old-timey snake oil salesman kind of way. But I'll be honest. I'll believe it when I see it. It's not that htmx is bad, but given the complexity of client-side interactions on the modern web, I can't see it ever becoming really popular. Some of the specifics in the comparisons are always weird, too. > Inste…

You touch on something that bugs me about these discussions: Lack of proof. Show me the web app with killer UX developed with htmx. Show me the product of the tools and processes being advocated.

Re: Htmx Is the Future

#507

Post by rwalle »

IshKebab wrote: post #400
jdthedisciple wrote: post #397

This puts all the computational load on the server. Imagine 10s of thousands of clients requesting millions of HTML fragments be put together by a single server maintaining all the states while all the powerful high end computing power at the end user's fingertips goes completely to waste. Not convinced.

Most users these days are probably using phones, not high end computers.

The processor on my phone is better than the one on a 2015 Macbook Pro 13" (i5)

Re: Htmx Is the Future

#508

Post by exabrial »

Schemaless markup has lead us down a path where something is broken nearly all the time.

I’d really rather see strongly typed markup that can easily be checked for correctness and who’s behavior is well defined. Something Modular too with profiles and designed for extensibility.

Re: Htmx Is the Future

#509

Post by renerick »

fogzen wrote: post #506
chrsjxn wrote: post #335

I love articles like these, because the narrative of "JS framework peddlers have hoodwinked you!" is fun, in an old-timey snake oil salesman kind of way. But I'll be honest. I'll believe it when I see it. It's not that htmx is bad, but given the complexity of client-side interactions on the modern web, I can't see it ever becoming really popular. Some of the specifics in the comparisons are always weird, too. > Inste…

You touch on something that bugs me about these discussions: Lack of proof. Show me the web app with killer UX developed with htmx. Show me the product of the tools and processes being advocated.

I'm not a developer of either of these, but here are two examples:

- https://htmx.org/essays/a-real-world-react-to-htmx-port/ by https://github.com/David-Guillot - a SaaS product migrated to htmx from React.

- https://zorro.management/ by https://twitter.com/Telroshan - a kanban project management tool. This one is particularly interesting IMO, it implements quite advanced UI with htmx and some custom JS.

Re: Htmx Is the Future

#510

Post by itronitron »

marcosdumay wrote: post #294
hirako2000 wrote: post #76

Earlier quoted context omitted.

I have no love for unnecessarily bloated dependency graphs, but we can't have the cake and eat the cake too. Next.js for example, comes packed with anything and everything one might need to build an app. Sitting on the promise of hyperproductivity with "simplicity". Plus, is made of single responsability principles set of modules, kind of necessary to build a solve-all needs framework. And it does that. A bit like An…

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.

If someone releases a module that depends on nine other modules then their module will likely be promoted by the authors of the other modules, rinse and repeat.
Post reply on HN