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

451–460 of 875 posts

Re: Htmx Is the Future

#451

Post by tsuujin »

doodlesdev wrote: post #438
tsuujin wrote: post #386

Earlier quoted context omitted.

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

I’ve used turbolinks on a few backend driven projects, but mostly with rails, and hotwire replaced that nicely enough. I really only used it because from the users perspective it’s hard to tell that you’re not using a SPA.

I really like the idea of systems like Phoenix’s LiveView as well, but I ask a lot of questions before I implement something like that. The majority of projects I’ve ever worked on didn’t really need that much interactivity and I strongly prefer the “sprinkle on JS when you actually need it” approach to web apps.

Re: Htmx Is the Future

#452

Post by tabtab »

I keep saying this and will say it again: what's really needed is a state-ful GUI markup language. HTML+DOM+JS+CSS is the wrong tool for the CRUD/GUI job, and force-fitting it has inflamed the area so bad many don't want to even try to scratch it.

Bloated JS frameworks like Angular, React, Vue, and Electron have big learning curves and a jillion gotcha's because they have to reinvent long-known and loved GUI idioms from scratch, but DOM is inherently defective for that need, meant for static documents. There are just too many GUI needs that HTML/DOM lacks or can't do right: https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...

Let's byte the bullet and create a GUI markup standard. Perhaps base it off Tk or Qt kits to avoid starting from scratch.

Re: Htmx Is the Future

#453

Post by taeric »

kbenson wrote: post #433
taeric wrote: post #361

Earlier quoted context omitted.

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.

That is an at rest choice that should be identical in both.

I presume you are thinking of rendering? But, again, that is largely done client side in both cases.

Re: Htmx Is the Future

#454

Post by manx »

knallfrosch wrote: post #449

HTMX Solution to keeping client and server in sync: Remove the client. Okay, now you have half the code base, but need a round trip to the server for every interaction. You could also remove the server and let people download your blog, where they can only post locally. No server-side input validation needed!

You can implement interactivity which doesn't need data from the server entirely client side. Libraries like https://alpinejs.dev help here and pair well with htmx.

Re: Htmx Is the Future

#455

Post by tabtab »

pphysch wrote: post #18
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…

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.

But if you don't blend the two, then you have a DRY violation. Someone should only have a say a field (column) is required in one and only one place, for example. The framework should take care of the details of making sure both the client and the server check.

I myself would like to see a data-dictionary-driven app framework. Code annotations on "class models" are hard to read and too static.

Re: Htmx Is the Future

#456

Post by MrVandemar »

fridgemaster wrote: post #415
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…

I fail to see how HTMX could be the "future". It could have been something useful in the 2000s, back when browsers had trouble processing the many MBs of JS of a SPA. Nowadays SPA's run just fine, the average network bandwidth of a user is full-HD video tier, and even mobile microprocessors can crunch JS decently fast. There is no use case for HTMX. Fragmented state floating around in requests is also a big big probl…

> Nowadays SPA's run just fine, the average network bandwidth of a user is full-HD video tier, and even mobile microprocessors can crunch JS decently fast.

ie. "I don't live in a rural area, but that's fine, nobody who matters lives there."

Re: Htmx Is the Future

#457

Post by pphysch »

tabtab wrote: post #455
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.

But if you don't blend the two, then you have a DRY violation. Someone should only have a say a field (column) is required in one and only one place, for example. The framework should take care of the details of making sure both the client and the server check. I myself would like to see a data-dictionary-driven app framework. Code annotations on "class models" are hard to read and too static.

DRY has its limitations. Client-server boundary is a good candidate for such a limit.

Re: Htmx Is the Future

#458

Post by manx »

It seems that many people are wondering why UI interactions, which don't need new data, should take a network roundtrip. You can avoid those round-trips by using a library like https://alpinejs.dev . It pairs well with htmx.

Re: Htmx Is the Future

#459

Post by replwoacause »

recursivedoubts wrote: post #86
benatkin wrote: post #77

Earlier quoted context omitted.

Links and forms are the bread and butter of many frameworks. Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.

if you read the article, you will see that you can use htmx as progressive enhancement quite easily since it is consonant with the vanilla HTML approach. what makes htmx a hypermedia framework is the exchange of hypermedia with the server, this satisfies the hypermedia constraint (HATEOAS) of REST. there are other libraries that are also hypermedia oriented, such as unpoly. it is a different approach to building web…

You’ve mentioned unpoly in a couple of your comments. I’m a beginner dev and have used HTMX successfully and quite easily, so thank you for making it. What does it offer that Unpoly doesn’t and vice-versa? Or do they basically do the same things?

Re: Htmx Is the Future

#460

Post by charrondev »

PaulHoule wrote: post #277
v0idzer0 wrote: post #234

Earlier quoted context omitted.

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

Ouch! I’ve worked in two kinds of organizations. In one of them when there is a ‘small’ ticket from the viewpoint of management, one programmer is responsible for implementation but might get some help from a specialist (DBA, CSS god, …) In the other a small ticket gets partitioned to two, three or more sub teams and productivity is usually reduced by a factor more than the concurrency you might get because of overhe…

I work at a company that makes a very clear distinction between API and View layer. Our API spans 200+ endpoints. We have 6 backend and 6 frontend developers.

As far as iterations go it’s very rapid. Our work teams are split into 1 backend and 1 frontend developer. They agree on an API spec for the project. This the contract between them and the frontend starts working immediately against a mock or very minimal version of the API. Iterate from there.

Post reply on HN