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

271–280 of 326 posts

Re: Moving from React to htmx

#271

Post by talideon »

pier25 wrote: post #243
talideon wrote: post #238

Earlier quoted context omitted.

That's exactly why HTMX was a good fit for this: it covers exactly the kind of Interaction patterns you'd find yourself writing in vanilla JS where React is overkill, except without having to write all that JS. Though I don't know why you'd bother with jQuery these days unless you had to deal with ancient browsers: venerable as it is, it's obsoleted itself as just about everything it did is now covered by browser API…

> is now covered by browser APIs I've never understood that argument. You could always do what jQuery does with vanilla JS. How could it be otherwise? The point of jQuery is productivity. Even today, a jQuery-style API saves you from writing a lot of code.

No it doesn't. Just about everything jQuery does is now a browser API these days, so you no longer save time using jQuery vs vanilla JS.

The only argument for continuing to use it is that you're used to it and not used to the modern APIs that have absorbed jQuery's functionality. It's just a slower way of doing the same thing.

Re: Moving from React to htmx

#272

Post by rchaud »

veidelis wrote: post #268
rchaud wrote: post #257

Earlier quoted context omitted.

React has a self perpetuating marketing machine. From boot camp courses to YouTube how-tos and frequency plof appearance in job description requirements, people end up hiring React developers who want to build the sites in React.

What is your point exactly? Please explain why is that bad and how the whole problem can be solved better - which lib or approach etc?

The point is that React has become the IBM of web app frameworks, in the "nobody got fired for using IBM" sense.

Your CTO, PM, frontend dev and DevOps people likely all have React experience under their belt. So it isn't surprising if React ends up becoming the framework of choice, simply because it will likely be faster to start with.

Re: Moving from React to htmx

#273

Post by generichuman »

veidelis wrote: post #268
rchaud wrote: post #257

Earlier quoted context omitted.

React has a self perpetuating marketing machine. From boot camp courses to YouTube how-tos and frequency plof appearance in job description requirements, people end up hiring React developers who want to build the sites in React.

What is your point exactly? Please explain why is that bad and how the whole problem can be solved better - which lib or approach etc?

People think React or similar SPA libraries are the way to do frontend development, so all frontend development seems to be React at this point.

"When all you have is a hammer, everything looks like a nail" is the problem. Another new library / framework will not solve this.

Frontend dev should go for the bare minimum when designing web sites, only introduce libraries as they're needed -- and really think about whether they're really needed or not. They need to ask some questions like:

- Maybe you can roll your own specialized solution that'll be smaller and faster than a general solution? - Does the thing you're working on need to be an SPA or does a good old multi-page web site be enough for your use case? - If you need parts of your website to be interactive, can you only update that part (the "islands" approach) by hand instead of introducing a dependency to do that?

There is a lot of complexity going on in our field right now and not enough people seem to care about that. The complexity is needlessly inflating our application / web page sizes and reducing performance.

Re: Moving from React to htmx

#274

Post by spion »

pwdisswordfish0 wrote: post #263
spion wrote: post #202

I may have missed it in the video, but where exactly do they store all the "client-side" state? Postgres? Redis? Sessions?

There is no client-side state, that’s the whole point.

There is always client-side state. The dropdowns, for example, have selection that affects the entire app. That selection must be stored in a state which will affect the reloads triggered by changes in the dropdowns.

Re: Moving from React to htmx

#275

Post by dagenix »

generichuman wrote: post #273
veidelis wrote: post #268

Earlier quoted context omitted.

What is your point exactly? Please explain why is that bad and how the whole problem can be solved better - which lib or approach etc?

People think React or similar SPA libraries are the way to do frontend development, so all frontend development seems to be React at this point. "When all you have is a hammer, everything looks like a nail" is the problem. Another new library / framework will not solve this. Frontend dev should go for the bare minimum when designing web sites, only introduce libraries as they're needed -- and really think about wheth…

React isn't an SPA library.

Re: Moving from React to htmx

#277

Post by galaxyLogic »

spion wrote: post #184
galaxyLogic wrote: post #161

Earlier quoted context omitted.

> we used to call them "Single Page Web Applications" because avoiding page refreshes was the point I wonder if the problem was really that the whole page was reloaded into the browser which caused a big "flash" because all of the page was-re-rendered. The problem maybe was not reloading the page from the server but re-rendering all of it. Whereas if you can load just parts of the page from the server the situation c…

The problem was there was no concept of reusable components. IMO htmx is not the headline here but django-components ( https://pypi.org/project/django-components/ ) is. Managing html, css and JS in component-reusable chunks on the server used to be extremely awkward, especially when you begin to need lifecycle events (HTML appeared on the page, lets attach all the necessary event listeners, but only to the right elem…

I think your explanation makes it very clear.

The difficulty with web-development is there are 3 different languages (HTML, CSS, JS) which all need to make some assumptions about what is coded in the other languages. The JavaScript refers to a DOM-element by id, it assumes some CSS which the JS can manipulate in a specific way.

The ideal goal much of the time has been: "Keep content separate from presentation, keep behavior separate from the content etc.". While this has been achieved in a superficial level by keeping CSS in a .css -file, content in a .html-file and behaviors in a .js -file, they are not really independent of each other at all. And how they depend on each other is not declared anywhere.

That means that to understand how a web-page works you must find, open and read 3 files.

Therefore rather than having 3 different types of files a better solution might be to have 3 files all of which contain HTML, CSS, and JS. In other words 3 smaller .htm files, each embedding also the CSS and JS needed.

Re: Moving from React to htmx

#278

Post by devoutsalsa »

criddell wrote: post #223
devoutsalsa wrote: post #108

Earlier quoted context omitted.

Vanilla JS definitely needs some discipline. I just made an app in vanilla JS for the first time in a while, and OMG it’s a rat’s nest XD

Have you ever tried writing a native client? I think the native client path is something that a lot of developers don't even consider these days. I think it's an area of great opportunity.

What do you mean? Like writing one's own framework, such as devoutsalsa.js?

Re: Moving from React to htmx

#279

Post by Winsaucerer »

ec109685 wrote: post #233
Winsaucerer wrote: post #155

Earlier quoted context omitted.

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…

If you have non-html native mobile applications, you’ll need to have that complexity regardless of the techniques used to construct web page.

Yep, that's absolutely right. From my own experience (which is really quite small for that kind of thing), I tend to think that the API you want and would build for a mobile app is not going to be the same as the one you would build for your SPA site. But yes, when you build that API, you'll need that complexity.

I've been doing some hobby experimenting with doing this in a more generic way using Postgres RLS and putting a lot of that permissions checks into the database. That way, if I used PostgREST or my own solution for a mobile app API, the security rules should apply just the same to the API as they do to the website.

Re: Moving from React to htmx

#280

Post by lliamander »

criddell wrote: post #195
ksbrooksjr wrote: post #25

Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a buil…

If you want a non-JavaScript client, ditch the browser all together and build a native client.

I think you have it backwards.

If you want to build a client using HTML, then targeting the browser is exactly the right choice.

Javascript-heavy SPAs are much closer to traditional native apps - and lose some of the benefits of running on the web/ in the browser as a result.

There's a lot more reason to consider native app if you are building an SPA than if you are building an MPA/SSR app.

Post reply on HN