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

201–210 of 326 posts

Re: Moving from React to htmx

#201

Post by rmbyrro »

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…

I also like htmx and this kind of comparison is fruitless. The executive summary talks about LOC, build time, # of JS dependencies, etc. Nobody started using React because of these things, so it misses the point. It doesn't compare htmx to react on the matters that really matter to people who chose react...

Re: Moving from React to htmx

#203

Post by spion »

Winsaucerer wrote: post #155
hsbauauvhabzb wrote: post #57

Earlier quoted context omitted.

What security issues does server rendering solve? I resent that every website needs to be an SPA, but from a security perspective I’ve concluded that the clearer line in the sand that SPA application architectures creates is better than the security challenges that can result from server side rendering. Navigating the risks around the NPM supply chain is another story, but I suspect it will be solved by large / popul…

Here's one I've experienced. Suppose you have a table of customers, and you want to show an extra column of data on that page showing total orders, if and only if the viewer of that table has the manager role. With an SPA, you'll be building an API (perhaps a 'REST' one, or GraphQL) to expose all the data required, such as customer name, email, etc, as well as the extra 'total orders' field iff they have the manager…

What do the tests look like for this? How do you check that you're not exposing the sensitive data?

Re: Moving from React to htmx

#204

Post by germandiago »

qwertyzxcvmnbvw wrote: post #71
mediumdeviation wrote: post #56

Earlier quoted context omitted.

For a real world example of this, GitHub uses server-side rendered fragments. Working with low latency and fast internet in the office, the experience is excellent. Trying to do the same outside with mobile internet, and even with a 5G connection, the increased latency makes the application frustrating to use. Every click is delayed, even for simple actions like opening menus on comments, filtering files or expanding…

Side note: in Thailand and the Philippines, at least, mobile internet is blazing fast and not more expensive.

In Vietnam it is also fast.

Re: Moving from React to htmx

#205

Post by samwillis »

hnbad wrote: post #187

This again? From the first page of the documentation: With that in mind, consider the following bit of HTML: Click Me! We've been through this back in the Angular days (and even before that: remember Knockout?). Implementing your template language as DOM attributes does not make it HTML. Not to mention the examples using "hyperscript", aka a "human readable" DSL for DOM manipulation and event handling also stuck in H…

The other reply (I think by the creator of HTMX) is right, HTMX is not a DSL for DOM template manipulation, but I want to address your main point about DSLs for DOM templating.

I completely see the appeal of a "it's just JS" approach that JSX and React take. But there is a massive advantage that a DSL has, the compiler can statically analyse the template and compile it in such a way that it has an understanding of what will change, what won't. This allows the compiler to make massive optimisations that JSX templates cannot do (easily). To achieve, in general, the same level of optimisation with JSX you have to code them in yourself.

Whether you go for an Angular/Vue style attribute based DSL or a Handlebars-esq DSL such as with Svelt, I don't really mind, they both have advantages and disadvantages. But what they allow you to do over JSX is enormously misunderstood by the majority of React devs.

There is a good overview of this in the Vue docs here: https://vuejs.org/guide/extras/rendering-mechanism.html#comp...

Re: Moving from React to htmx

#207

Post by germandiago »

nine_k wrote: post #130
jaytaylo wrote: post #28

Earlier quoted context omitted.

How was it worse than the current state of affairs of complexity with React? Bowser, npm, typescript, obfuscation, compressors, build pipelines.. it’s a lot. Life at the front-end today is so discombobulated, creating a bunch of backend APIs which will generally only be used and consumed by a single browser front-end. I’m genuinely curious, because I never used JSF except for a single school exercise

Frankly, with yarn, typescript, and a packaging / compressing tools of your choice, web frontend development is pretty pleasant and efficient these days. (To say nothing of using Elm, if you can afford it.) Typescript is particular is nice compared to, say, Python, and even to Java (though modern Java is quite neat.) The only unpleasant part is dependency management, but you have the same, or worse, with Python or Ru…

Typescript nicer than Python? Bc of speed? Python has typing module + mypy to be warned about typing mistakes.

Re: Moving from React to htmx

#209

Post by KuiN »

germandiago wrote: post #207
nine_k wrote: post #130

Earlier quoted context omitted.

Frankly, with yarn, typescript, and a packaging / compressing tools of your choice, web frontend development is pretty pleasant and efficient these days. (To say nothing of using Elm, if you can afford it.) Typescript is particular is nice compared to, say, Python, and even to Java (though modern Java is quite neat.) The only unpleasant part is dependency management, but you have the same, or worse, with Python or Ru…

Typescript nicer than Python? Bc of speed? Python has typing module + mypy to be warned about typing mistakes.

It may have improved significantly since I last used it (9 months ago?) but mypy was a world away from the ergonomics, quality of tooling and maturity of TypeScript.

Re: Moving from React to htmx

#210

Post by hiyer »

MatthiasPortzel wrote: post #41
andy800 wrote: post #12

Earlier quoted context omitted.

> as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning j…

The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast. There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rende…

Would this not be a concern for React (and other SPAs) as well? I'm no UI expert, but from what I've seen of React/Vue UIs in previous companies, you still have to hit the server to get the data, though not the UI components. The difference in size between just the data in, say, JSON, and the entire HTML component would be very minimal considering both would be compressed by the server before sending.
Post reply on HN