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

581–590 of 875 posts

Re: Htmx Is the Future

#581

Post by doodlesdev »

lakomen wrote: post #553
doodlesdev wrote: post #317

No it's not. Honestly, the fact that this website displays like shit without JavaScript enabled is ironic considering it uses HTMX. Please just use the damn full-stack JS frameworks, they make life simpler, just wait for WebAssembly to allow us to have full-stack Rust/Go/whatever frameworks, and then you can abandon JavaScript, otherwise you get the mess of websites like this one where the developer has not written J…

[flagged]

I'm sorry for saying something you disagree with. Next time I'll ask for permission to comment my opinion. Really, what's the point of your comment? At least state why you think I have no idea what I'm talking about, the way you wrote it adds literally nothing to the conversation.

Re: Htmx Is the Future

#582

Post by infogulch »

mtlynch wrote: post #304
infogulch wrote: post #231

Earlier quoted context omitted.

I don't understand the concern. If your backend is sufficiently compromised to inject arbitrary js into sever responses then you've already lost, and I don't see how that's worse than serving a compromised App.js from the same server.

The attacker doesn't have to compromise the backend to achieve XSS. Suppose your website displays user-generated content (like HN posts). If the attacker finds a way to bypass encoding and instead injects JS, then without CSP, the attacker gets XSS at that point. With CSP, even if the attacker can get user-generated content to render as JS, the browser will refuse to execute it. My understanding of htmx is that the b…

If you exclude the features mentioned above by the creator, most htmx attributes seem pretty harmless from a CSP pov. Really, this is an argument for why htmx features should be built into the browser -- presumably details like this would be rooted out and resolved by browser developers before they would permit it to be included in their browser.

Re: Htmx Is the Future

#583

Post by RHSeeger »

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…

There's been a fair amount of discussion on this thread, which left me wanting to clarify my comments...

It is entirely possible to have a MPA application that makes calls to the back end to retrieve more data. Especially for things like a static page (cached) with some dynamic content on it. My problem is when people convert an entire site to a Single Page (SPA). When I click to go from the "home page" to a "subsection page", it makes sense to load the entire page. When I click to "see more results" for the list of items on a page, it seems reasonable to load them onto the page.

Side note: If I scroll down the page a few times and suddenly there's 8 items in the back queue, you're doing it wrong. That drives me bonkers.

Re: Htmx Is the Future

#584

Post by wibblewobble124 »

robertoandred wrote: post #381
wibblewobble124 wrote: post #352

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.

this is a shallow and dismissive comment lacking any basic charity or nuance: dijkstra was just bad at “goto.”

this doesn’t worry me, though. those in the react crowd that insist on this arbitrary and newfangled “frontend/backend” stratification and are dogmatic about it are by definition going to stick with what they know and won’t come and bother us who choose tools based on real experience and their practical merits. better off they make themselves easy to spot from a distance.

Re: Htmx Is the Future

#585

Post by robertoandred »

ihateolives wrote: post #538
robertoandred wrote: post #381

Earlier quoted context omitted.

Sounds like your backend devs are just bad at frontend.

And? Your average React dev is bad at proper backend too.

So then doesn't it make sense that frontend devs focus on frontend and backend devs focus on backend?

Re: Htmx Is the Future

#586

Post by robertoandred »

wibblewobble124 wrote: post #584
robertoandred wrote: post #381

Earlier quoted context omitted.

Sounds like your backend devs are just bad at frontend.

this is a shallow and dismissive comment lacking any basic charity or nuance: dijkstra was just bad at “goto.” this doesn’t worry me, though. those in the react crowd that insist on this arbitrary and newfangled “frontend/backend” stratification and are dogmatic about it are by definition going to stick with what they know and won’t come and bother us who choose tools based on real experience and their practical meri…

"Frontend/backend" is neither new nor pointless. The people who pretend they are are usually backenders who are under the false impression that frontend is simple.

Re: Htmx Is the Future

#588

Post by _heimdall »

dfabulich wrote: post #217
jgoodhcg wrote: post #186

Earlier quoted context omitted.

I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for what happens when one component in a tree needs to update another component in the tree HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page…

> Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection. > It's basically the speed of the network. Does your stuff work on mobile web? Mobile web requests can easily take seconds, and on a dodgy conne…

What happens in your optimistically updated UI when a request eventually fails 10+ seconds after the users thought it succeeded and moved on?

In my experience optimistic UI updated don't actually make much sense if you expect users to regularly see large delays. Optimistic updates are great though to avoid the jank of a loading state that pops in/out of view for a fraction of a second.

Re: Htmx Is the Future

#589

Post by shearos »

austinthetaco wrote: post #343
PaulHoule wrote: post #51

Earlier quoted context omitted.

As I see it though, node.js on the backend is not mainstream, most sites are still using JVM or other back ends. Using the same code for the front end and the back end is a dream that has been pursued in various forms but it isn’t mainstream.

according to the latest stackoverflow developer survey, NodeJS is extremely common and used quite a bit more than things like ASP.net ( https://survey.stackoverflow.co/2022/#most-popular-technolog... )

is node included when choosing front ends like react or vue?
Post reply on HN