recursivedoubts 4 days ago | next |

This is a follow up to a presentation David gave at the 2022 European DjangoCon:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

His talk was a major milestone in the arc of htmx, showing that a real world, commercial project could move from react to htmx and see significant benefits. I can't stress how important his talk was in the overall success of htmx, and I'm glad he followed up on it.

itronitron 4 days ago | prev | next |

My only counter is that for a real-time collaborative app the server should be the single source of truth about application state, which would make htmx a good choice for that type of application.

eterps 4 days ago | root | parent |

Look, I'm a fan of HTMX, but if you want to build a collaborative app like Google Docs or Google Sheets, it wouldn't be a good choice.

out_of_protocol 3 days ago | root | parent |

You gotta start learning CRDT and other weird words if you want to build stuff like this. Just having react or whatever is not enough

peutetre 4 days ago | prev |

> Javascript is the only programming language available on the client side of the web platform

Not any more. WebAssembly enables all languages on the client side.

Why am I using JavaScript when I can use anything else?

fuzzy2 4 days ago | root | parent | prev |

WebAssembly cannot access the DOM. So, not a full replacement.

peutetre 4 days ago | root | parent |

Sure it can. It's true you have to use JavaScript glue code, but it's also true that won't be true forever.

lelanthran 4 days ago | root | parent |

> It's true you have to use JavaScript glue code, but it's also true that won't be true forever.

I won't live forever and I'd like to deliver my product before I die.

peutetre 4 days ago | root | parent |

It isn't onerous. Here's an example using Scheme in the browser:

https://www.spritely.institute/news/building-interactive-web...

lelanthran 3 days ago | root | parent | next |

> It isn't onerous. Here's an example using Scheme in the browser:

> https://www.spritely.institute/news/building-interactive-web...

That looks pretty damn onerous to me:

1. (Guile) Declare all the JS symbols you wish to use.

2. (JS) Write wrappers for the symbols from #1 above.

In short, you're still writing custom glue code for manipulating the DOM from the wasm language, and you'll need more custom glue code if you ever want to call your wasm functions from JS (for example, from the `onclick` attribute in an element tag, from `setInterval()`, from resolution of a promise, etc).

This is not what I meant by my response in the following exchange:

>>> It's true you have to use JavaScript glue code, but it's also true that won't be true forever.

>> I won't live forever and I'd like to deliver my product before I die.

Right now, it is true that wasm DOM access is non-existent, needs glue code to be existent, and the DOM <--> wasm interface, even with glue code, is limited as hell.

I don't know if there are plans to address this. It is irresponsible of me to use wasm for a client today under the assumption that, by the time I need a DOM <--> wasm interface, it will be there.

Before the limitations of the DOM <--> wasm interface is ever addressed, the product might even have reached end of life.

hu3 4 days ago | root | parent | prev |

At this point one should think if TypeScript isn't a better solution for most frontend code.