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

Please just try HTMX

pleasejusttryhtmx.com

Post reply on HN
Print view View original

411–420 of 530 posts

Re: Please just try HTMX

#411

Post by culi »

avisser wrote: post #22
0x3f wrote: post #16

The thing is React is usually fine, and even if you don't have to build _this_ thing in React due to simplicity, why bother learning two paradigms when you can just use the heavier one for everything and most likely never encounter any real practical showstopping issue?

> why bother learning two paradigms Objection. Your React is ultimately turning into HTML so you DO have to learn HTML + CSS. You just have an abstraction over it.

This featured article is about HTMX not HTML. Ofc everyone working in the FE should know HTML/CSS

Re: Please just try HTMX

#412

Post by codedokode »

H1Supreme wrote: post #280
CooCooCaCha wrote: post #238

Earlier quoted context omitted.

Plain react is arguably just as simple if not simpler than jquery. And I’m not saying every site needs to be an SPA. I’m saying if I can write everything from a simple site to an SPA in a single framework then why not use that for everything?

How do you handle routing with plain React?

React is an implementation of View component of MVC, View is responsible for displaying Model contents, not for handling routes. You are trying to use the wrong tool.

Re: Please just try HTMX

#414

Post by culi »

philipwhiuk wrote: post #4

The proselyting over frameworks is the worst bit of the web ecosystem. If your solution is actually good, it will get adopted eventually... Forget React, there's still stuff written in jQuery and JSP. Why the rush to convert everything - you're not a missionary on a mission, just build your stuff in stuff you like? The attack on npm is ridiculous, when (apart from introducing a permanent vulnerability in the form of…

> If your solution is actually good, it will get adopted eventually...

I used to believe this when I first started in tech. The truth is even something as seemingly innocent as javascript runtimes now have an incredible amount of money behind them. And sometimes even marketing budgets. Deno released a high-production trailer for their 2.0 release last year

https://www.youtube.com/watch?v=swXWUfufu2w

I've also seen some really cool and well-thought out technologies simply not gain any traction.

The truth is you ultimately do need some big company behind you or major personality writing blog posts to ultimately make it.

Techies don't like to admit it but we're just as reliant on influencers as anyone else.

Re: Please just try HTMX

#415

Post by adamzwasserman »

lbreakjai wrote: post #403
adamzwasserman wrote: post #200

Earlier quoted context omitted.

The state encapsulation concern is exactly what DATAOS addresses: dataos.software The premise is that React's "UI=f(state)" creates a synchronization problem that doesn't need to exist. If the DOM is the authority on state (not a projection of state held elsewhere), there's nothing to sync. You read state from where it already lives. I built multicardz on this: 1M+ cards, sub-500ms searches, 100/100 Lighthouse scores…

> If the DOM is the authority on state (not a projection of state held elsewhere), there's nothing to sync. You read state from where it already lives. But it's not, is it? The state lives in the server. If I open a page, and let it open for 2 hours, then there's no guarantee it actually represents the current state.

You are conflating all state into a big undifferentiated soup.

I reason about state differently, Here are my axioms:

1. There is no such thing as "state".` There is user/ui state, there is cache state, there is db cursor state, etc. trying to manage all of that as big undifferentiated ball is not proper separation of concerns.

2. what I call User State is the user's exceptions that they will find things "as they left them". If as a user, I do a pager refresh, I expect that my user preferences for colors and fonts will still be there. that the sorting on the table I was looking at will still still be there, that the filters I had applied to the table are still there. That is I was editing a record but had not saved, I will still be editing that record without data loss on screen but still not saved to the db (unless the app is explicitly autosave). In a word: the user state is what the user can see.

3. Ideally my User State has a single source of truth, the user can always confirm it by looking at it, and is therefore IN the front end.

4. Most, if not all, other state is stored on the server. things like the user's auth state is a -backend- concern, and should NOT be stored in the frontend.

5. class-oriented programming is extremely difficult to manage: as I like to say, every class is a petri dish for state corruption. I prefer pure functions on the backend for the reason I outline ion the dataos.software blog articles.

Pure functions are mostly deterministic (especially if you avoid floats). So you can not only count on getting the same results for the same query, you can cache them too. And you can test them trivially. Integration test? What's that?

When you capture the User State from the DOM (using a manifest so that you do not need to capture the whole DOM) and send it to the pure function on the back end, you have a perfect event source pattern. Not only can I tell you exactly who and what triggered a particular piece of html being sent o the screen, I can rewind and reply like a tape recorder.

BTW, I have no hate for React. There are some things I think it does better than any other option. I was a core member of the React Studio team (expired cert on the site but safe to visit for archeological purposes).

Re: Please just try HTMX

#416

Post by listenallyall »

lbreakjai wrote: post #386
listenallyall wrote: post #373

Earlier quoted context omitted.

> let the frontend handle it via 3 different rendering logic, (such as JSX templates) same as the server > if you hide the complexity under the bed! which is what you just did by dismissing the reality that client-side requires the same 3 renderers that server-side requires! (plus serialization and deserialization logic - not a big deal with your simple example but can be a major bottleneck with complex, nested, nati…

This isn't about the number of rendering logics. You'll have as many as you have variants, that's tautological. This is about where they happen. In a classic app, there's one entity that keeps the state (the server), and one entity that keeps how it is rendered. This is very easy to reason about, and the contract is very clear. If I want to understand what happens, then I can open my frontend app and see "Hello {{nam…

> If I want to understand what happens, then I can open my frontend app and see "Hello {{name}}".

> In HTMX, the logic is spread

I disagree... with React, by definition, the logic is spread. Persistent data, and usually, business logic, is in some data store accessible via the app backend. And then a totally different entity, the front-end, renders that data (often implementing additional business logic) and manages state (which is often not yet recorded in the data store until various updates can be performed).

HTMX helps keep everything aligned. All the rendering logic is right there along with the data and the business logic. If I'm looking for a renderer, not only is it easy to find the template that produced "Hello {{name}}" but it is also easy to find the source of {{name}}. Which also makes it easy to alter {{name}}, say, from Smith, John to Mr. John Smith - because the data store and business logic are right there, it is low effort to switch the order and to begin including the salutation.

Your "front-end" is still all in one place, except it's on the server, and typically rendered via templates instead of React components. But the templates can often access native objects (including their properties and functions) instead of solely relying on JSON objects.

This comment is already long but regarding data tables... yea, highly dynamic pure data-based UI's such as charts and tables aren't HTMX's forte. But even then there are ways... the data- attribute is very useful, and since you are already using JS to handle sorting, filtering, re-ordering, showing tooltips, etc, it's very possible to render valid HTML fragments that can be properly rendered via that same JS (or contain data which can be).

Re: Please just try HTMX

#417

Post by csomar »

If you don't need React, you probably don't need a framework anyway. The reason I use React is to create components that can exist on their own (and can be constructed/visualized on a StoryBook) and these components will then play nice with other React components. And then use JSX to make reasoning about the code simple. That's not what htmx is.

> htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript.

From React website:

> React lets you build user interfaces out of individual pieces called components. Create your own React components like Thumbnail, LikeButton, and Video. Then combine them into entire screens, pages, and apps.

Apples and Oranges.

Re: Please just try HTMX

#418

Post by tommica »

> If you hate it, you've lost a weekend. But you won't hate it. You'll wonder why you ever thought web development had to be so fucking complicated.

This part is said really well, and applies to anything. "It's just a single weekend" is a cure to the whole "wasting time" argument/excuse that I guess a decent amount of people have - at least I know I do.

Really well written article, having both when to use and when not to use, is a nicely balanced view.

Re: Please just try HTMX

#420

Post by turtlebits »

lbreakjai wrote: post #397
array_key_first wrote: post #384

Earlier quoted context omitted.

> This isn't about state, is it? In a classic react app, if I need to display the name of a user, then I fetch it (from the server) once, and display it as many times as I need, in as many forms as I need. There's only server state. No, there's two states here: the frontend state, and the backend state. The name example is trivial, but in real applications, your state is complex and diverges. You need to constantly s…

> These are hard problems. I fail to see how HTMX helps. I fail to see how SSR necessarily helps too. You could be serving a page for an order that's been cancelled by the time the user sees it. > I put in some search criteria, maybe a check a few boxes. Refresh? All gone You could see that 20 years ago too, unless you manually stored the state of the form somewhere. Again, what does it have to do with HTMX, or Rect,…

HTMX helps enhance UX by not having to reload/render the entire page. IME it should be used sparingly.

For your name example, you could use hx-swap-oob to update multiple elements. However if you're submitting a form element, I would just re-render the page.

Post reply on HN