Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from React to htmx

htmx.org

Post reply on HN
Print view View original

131–140 of 326 posts

Re: Moving from React to htmx

#131

Post by eyelidlessness »

ksbrooksjr wrote: post #73
yawaramin wrote: post #68

Earlier quoted context omitted.

The article we're commenting on dedicates an entire section to talking about the dev team makeup and how it completely changed and unified the team approach to being fullstack. That's how thoroughly htmx changed the programming model.

You haven't disagreed with anything I said. My original comment says "Htmx is great for developers who need client side interactivity, but would rather not write any js". I'm sure a team of Python developers is enjoying not writing Javascript. My point is that you don't have to switch to a completely different paradigm to reap the performance benefits that the article lists.

I didn’t read the comment as disagreeing either. Sometimes people are commenting not to disagree ;)

Re: Moving from React to htmx

#132

Post by eyelidlessness »

ipaddr wrote: post #90
Void_ wrote: post #59

Earlier quoted context omitted.

I was just picking technology for my new landing page and was looking into Preact first. I wanted basic SSR and things like that. Preact has a library called preact-cli for this. The last commit is from Aug 17. I ended up with SvelteKit. It just felt much more alive. I don't love learning a new technology just for a landing page, but that was kinda fun.

Was the worry Aug 17 less than two months ago a sign the project was abandoned? Daily changes would worry me more.

Especially given the team has been actively working on a major version for several months and released an impressive improvement to their state model in the last month. They’re active and thoughtful about what they ship.

Re: Moving from React to htmx

#133

Post by nine_k »

throwawaymoddle wrote: post #119
stickfigure wrote: post #75

Earlier quoted context omitted.

There's no such thing as a secure "app". Only the API needs to be secure. That's more straightforward when your API looks like REST/RPC calls rather than "renders html templates to a string".

> Only the API needs to be secure. If users type passwords, sensitive data, anything into the frontend then any javascript, plugins etc pulled in by that page is an attack vector.

Unless you do something extremely silly with the login page, like sending it as a GET parameter, or storing it locally, or not having a CSRF token, or not using HTTPS, I don't see what special measures are required!

Re: Moving from React to htmx

#135

Post by camkego »

Deep inside the comments is a wise question. What happened to the user experience over high latency links? Across countries? Over high latency mobile links? Starlink latency anyone??

Not every situation has high latency, but it's worth asking what happens when moving from React to Htmx in those situations.

Re: Moving from React to htmx

#136

Post by ksec »

samwillis wrote: post #7

Love htmx and this talk is a brilliant run down of where it works well. But as always it’s about choosing the right tool for the job. Server rendered pages/fragments solve so many issues around security and time to develop a product, however it only gets you so far. Ultimately I think the decision when choosing a stack comes down to how much state you need to managed in browser. The vast majority of sites needs very…

Somewhere along the line the only accepted voice in the industry was everything has to be Javascript. I still have no idea why HTML5 hasn't evolved to include features purposed by HTMX.

> It’s the 5% where htmx is not one of the right choices at all.

I think even 5% is an over-statement. In my Top 100 site visit per month, the only three site that were SPA are Gmail, Feedly and Youtube. And I dont see how any of these three couldn't be done in HTMX. The Web Apps, if we call it that, that actually requires heavy JS usage are Google Work, Sheets, Google Map and Google Earth, and possibly some other productivity tools like Figma.

Re: Moving from React to htmx

#137

Post by hsbauauvhabzb »

nine_k wrote: post #133
throwawaymoddle wrote: post #119

Earlier quoted context omitted.

> Only the API needs to be secure. If users type passwords, sensitive data, anything into the frontend then any javascript, plugins etc pulled in by that page is an attack vector.

Unless you do something extremely silly with the login page, like sending it as a GET parameter, or storing it locally, or not having a CSRF token, or not using HTTPS, I don't see what special measures are required!

You can import malicious client side plugins irrespective of if it’s an SPA or server rendered. I’d much rather a silly plug-in be limited to client side JavaScript (which is sandboxed) over server side logic, which is not.

Re: Moving from React to htmx

#138

Post by richbell »

camkego wrote: post #135

Deep inside the comments is a wise question. What happened to the user experience over high latency links? Across countries? Over high latency mobile links? Starlink latency anyone?? Not every situation has high latency, but it's worth asking what happens when moving from React to Htmx in those situations.

Conversely, a poorly optimized SPA may not even load in a reasonable time span.

Re: Moving from React to htmx

#139

Post by richbell »

stickfigure wrote: post #125
nkozyra wrote: post #98

Earlier quoted context omitted.

> That's more straightforward when your API looks like REST/RPC calls rather than "renders html templates to a string". How so? You're now dealing with two applications (or two parts of an application) that need to understand and access authentication as defined by "the app" If the same codebase handles auth across the board it's much simpler and more reliable.

From a security perspective, the client is 100% irrelevant. You might prefer to offer a good UX in the face of authorization failure, but that doesn't affect the security of your app one way or another. Good APIs look like simple functions; they take certain very structured inputs (path, query params, headers, body) and produce a simple structured output (usually a json blob). They're usually well defined, limited in…

The operative word being good, which most APIs unfortunately aren't. You could make the exact same argument about APIs that you made about HTML endpoints, and vice versa. The problem, imo, is that writing a fronted is a lot harder for many people than writing a backend and they tend to spend more time on the front-end.

Security is hard, especially when most developers are ignorant or negligent about basic best practices. If I had a nickel for every website I've found that only has client-side validation I'd be rich.

Re: Moving from React to htmx

#140

Post by bigDinosaur »

recursivedoubts wrote: post #87
bigDinosaur wrote: post #83

I'm just so burnt out with new things. How do I combat such burnout? I really don't care about 'Htmx', I think barely any apps need much beyond what was available in ~2006 in terms of web tech. I just feel tired knowing that moving from React to Htmx is an option. Yet another option which will very possibly bring zero commercial value (although it might be a nicer dev experience I guess) to any project I ever work on…

That's understandable, the front end world is extremely churny. If you don't want to deep dive on htmx-as-a-tool due to burn out, I completely understand. But, at some point, it might make sense to read up on the philosophy behind it (hypermedia as an archiecture) because that is an area where it is different than most front end frameworks today. I have a collection of essays here: https://htmx.org/essays

Thanks, I'll definitely take a look given your (and others') replies here.
Post reply on HN