Live data from Hacker News

Htmx Is the Future

quii.dev

381–390 of 875 posts

Re: Htmx Is the Future

#381

we’re using htmx at work, migrating away from react. the technique we’re using is just rendering the whole page, e.g. we have a page where one side of the screen is a big form and the other side is a view on the same data but with a different UI, updating one updates the other. we’re using the morphdom swapping mode so only the things that changed are updated in-place. as a colleague commented after implementing this…

Sounds like your backend devs are just bad at frontend.

Re: Htmx Is the Future

#382
post #11

Earlier quoted context omitted.

I often work on an old ColdFusion application. It's amusing that for a long time the response was "oh man that sounds terrible". Now it is "oh hey that's server side rendered ... is it a new framework?". The cycle continues. I end up writing all sorts of things and there are times when I'm working on one and think "this would be better as Y" and then on Y "oh man this should be Z". There are days where I just opt for…

ActionScript is basically ES6 too isn't it?

AS3 was typed though, so maybe closer to Typescript.

Re: Htmx Is the Future

#383

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…

I don't really see how progressive enhancement works if every element is a hypermedia control. Without JS/HTMX you just have a page that does nothing:

    Get Some HTML
This will never do anything without HTMX because the semantic of that markup is wrong. You'd really have to write everything in a vanilla HTML approach to begin with, and never make use of the idea of adding hypermedia to other elements.

Re: Htmx Is the Future

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

> have to do a network request for each and every validation of user input.

HTML5 solved that to a first approximation client-side. Often later you'll need to reconcile with the database and security, so that will necessarily happen there. I don't see that being a big trade-off today.

Re: Htmx Is the Future

#386

Earlier quoted context omitted.

> Please just use the damn fullstack JS frameworks, they make life simpler Strongest possible disagree. I’ve been doing web dev for a long time, and the last 10 years has seen a massive, ridiculous increase in complexity across the board. I personally took my company back to good old server rendered apps with a turbolinks overlay because I was sick of dealing with the full stack frameworks, and we saw a huge increase…

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 for the producer and one for the consumer. That’s totally never caused any headaches or slowed anyone down at all.

Re: Htmx Is the Future

#387

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…

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

When a company gets to the stage where they actually need a mobile app, it is pretty easy to add API endpoints in many/most/all? major web frameworks. Starting out with the FE/BE split slows you down immensely.

Re: Htmx Is the Future

#388
post #125
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 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.

Re: Htmx Is the Future

#389

Earlier quoted context omitted.

it absolutely is hypermedia we generalize HTML's hypermedia controls in the following way: - any HTML element can become a hypermedia control - any event can drive a hypermedia interaction - any element can be the target of a hypermedia interaction (transclusion, a concept in hypermedia not implemented by HTML) all server interactions are done in terms of hypermedia, just like w/links and forms it also makes PUT, PAT…

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.

SvelteKit forms work fine with Javascript disabled -- Rich Harris is a big proponent of progressive enhancement.

Re: Htmx Is the Future

#390
post #221

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…

The article under discussion here appears to be saying that HTMX can work without Javascript enabled. But HTMX itself is a Javascript library, correct? So how can it work without Javascript enabled?

Adding the form element allows it to post to the server without javascript, just like olden times. Since the htmx header is not included, the backend was instructed to return a full page instead of a fragment.
Post reply on HN