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

491–500 of 875 posts

Re: Htmx Is the Future

#491

Post by _heimdall »

MisterSandman wrote: post #183
brushfoot wrote: post #10

I use tech like HTMX because, as a team of one, I have no other choice. I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted. After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with J…

Angular is nototiously bad for single developers. React is much better, and things like Remix and Gatsby are even better.

I really can't recommend Gatsby to anyone at this point. The sale to Netlify was the final nail in the coffin of Gatsby, the entire business was sold off only for the perceived value of Valhalla

Re: Htmx Is the Future

#492

Post by _heimdall »

ukuina wrote: post #465
recursivedoubts wrote: post #190

Earlier quoted context omitted.

https://htmx.org/essays/hateoas/

Doesn't this make serverless read-only apps (that only require a fileserver) effectively impossible? In a serverless read-only app, all business logic and state is maintained on the browser.

Serverless and static are different. Static sites will likely be limited to maintaining state in the browser. Serverless is terribly named but still have a short lived server with access to request query parameters, cookies, headers, and a database depending on your setup

Re: Htmx Is the Future

#493

Post by _heimdall »

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

> There is a reason why HATEOAS is almost never observed in REST setups.

I saw the HTMX creator floating around the thread so hopefully he can confirm, but my understanding is HATEOS is a specific implementation of a REpresentstional State Transfer API. JSON is often used for the API, HTMX uses HTML instead but it is indeed still a REST API transferring state across the wire.

My shift key really doesn't appreciate all these abbreviations

Re: Htmx Is the Future

#494

Post by philderbeast »

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"

unfortunately this also needs to be done server side, unless your trusting the client to send you information that is what your expecting?

client side validation makes for a good user experience, but it does not replace the requirement to validate things server side, and many times you will end up doing the same validations for different reasons.

Re: Htmx Is the Future

#495

Post by iainmerrick »

emodendroket wrote: post #244
sidlls wrote: post #240

Earlier quoted context omitted.

Being not hyped up doesn’t mean it’s mainstream. Most backends are in Java, Go, or PHP. Python and Ruby take up most of those that aren’t. It’s rare to find node on the backend in comparison.

I don’t agree that Go is more common than node (or other options you did not mention like .NET).

I wonder if part of the confusion here is that “backend” is pretty overloaded. There are backends like API servers, and web server backends (which at Google they call “frontends”!)

I’d guess that Go is relatively more popular than Node for API servers, and Node is more popular for web servers.

And as you note, both are probably less popular than languages like Java and PHP.

Re: Htmx Is the Future

#496

Post by doodlesdev »

klabb3 wrote: post #489
doodlesdev wrote: post #339

Earlier quoted context omitted.

> Finally, we cut to the chase. This is 100% true, and we should be talking about this, because it’s still not settled: do we want web pages or web apps? If both, where is the line? Can you expect something like Slack to work without JavaScript? What about a blog with interactive graphs? Should everything degrade or should some things require JS/WASM? BINGO. At times, it seems everyone is talking through each other b…

> BINGO. At times, it seems everyone is talking through each other because we are thinking of different things Glad to hear. Yes, it seems like the post and the comments are largely missing the functional issue at play. > the blog post we are talking about which displays awful without running JavaScript Yeah, case in point, perhaps.. I mean if you have two paths (incremental and full) to reach the same state, you bet…

   > I have an app based on Tauri which is web based, and the msi is 10Mb. It’s never had any perf issues.
And that's on the heavy side! Tauri is awesome, it's unfortunate most developers opt for Electron to reduce the amount of testing needed between browser engines.

I agree with you that a well-made web app is snappy and works well. I don't think we'll go back to native apps (for now), what I hope for is simply that it could become an _option_ as right now it's just basically trying to swim upstream.

Web apps do a lot of things really well that native applications always had difficulty with, such as accessibility and distribution. Still, I feel that even when doing web apps that are snappy they miss out on some cool features of native applications such as consistent theming, reduced memory usage, reduced CPU usage (regardless of how well the web app is written), and just the simplicity of it.

Perhaps the ship has already sailed, and native applications will never make a comeback, in which case I hope lighter weight engines purpose-made for web applications get adopted as an alternative to shipping the entirety of Chromium with each program I download. Projects like Servo [0] show me that's possible, it's just that there is currently no interest from the big players to keep funding these developments and provide them as an alternative to Chromium.

[0]: https://servo.org/

Re: Htmx Is the Future

#497

Post by _heimdall »

tomhallett wrote: post #212
recursivedoubts wrote: post #124

Earlier quoted context omitted.

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

HTMX makes heavy use of replacing branches of the DOM with HTML partials fetch wit get/post requests

There a ton of additional features builtin to HTMX, but I'd love to see just this basic primitive built into browsers. It's related to the element transitions API that has been working it's way into browsers, but approaches it from the angle of HTML partials instead of diffing two full pages durn SPA navigation.

Re: Htmx Is the Future

#498

Post by philderbeast »

emodendroket wrote: post #174
pphysch wrote: post #95

Earlier quoted context omitted.

Username length does not "need" to be validated on the client. However, it is nice for UX to enforce it there.

I think a charitable reader could infer that this is often made a requirement out of UX concerns and therefore it “needs” to be done. Do you have a substantive objection to what I said?

a requirement that is solved by setting the length on your input field?

or have we forgotten that plain hold HTML can validate much of this for us with no JS of any type required?

Re: Htmx Is the Future

#499

Post by yawaramin »

emodendroket wrote: post #273
yawaramin wrote: post #256

Earlier quoted context omitted.

Why be on the internet at all? Why not distribute a desktop app that doesn't need any connectivity at all?

Presumably there are some features of the app that won’t work that way. Surely you’re not saying you prefer a Web app just for the sake of making calls.

No, I'm just taking your argument to its logical conclusion. If you manufacture enough criteria, you can steer any discussion so that your choice is the only possible choice left. That's not how things work in reality, there are many competing factors that go into technological choices.

Re: Htmx Is the Future

#500

Post by iainmerrick »

emodendroket wrote: post #406
ZephyrBlu wrote: post #353

Earlier quoted context omitted.

Frontend and backend validation are usually not the same though. You won't be writing the same thing twice, you'll be writing different validations for each.

I think the frontend validations will, most of the time, be a subset of the backend ones, with many shared validation points.

Yes, exactly!

I’ve several times been in the position of writing a new UI for an existing API. You find yourself wanting to validate stuff before the user hits “submit”, because hiding errors until after submitting is terrible UX; and to do that, you find yourself digging into the server code to figure out the validation logic, and duplicating it.

And then years or months later the code gets out of sync, and the client is enforcing all sorts of constraints that aren’t needed on the server any more! Not good.

Post reply on HN