| ▲ | sgt 3 hours ago |
| Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity. |
|
| ▲ | asdfsa32 3 hours ago | parent | next [-] |
| Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing. |
| |
| ▲ | sgt 3 hours ago | parent [-] | | In principle I agree that putting React or Vue in for a little interactivity is a bad approach, if the same can be achieved with Htmx, which it usually can. However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered. | | |
| ▲ | asdfsa32 3 hours ago | parent [-] | | "Complex mini app" is one hell of a concept. | | |
| ▲ | skydhash 2 hours ago | parent [-] | | It can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state<=>ui relationship is worth it. | | |
| ▲ | asdfsa32 2 hours ago | parent [-] | | A text editor or music player is hardly "mini". Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps. | | |
| ▲ | stymaar an hour ago | parent [-] | | > A text editor or music player is hardly "mini". If it's a sub-function of a bigger ensemble that mostly dies something else then it's fine to call them “mini apps”. For instance a bank app may contain a text editor for the internal messaging feature of the app, that would count as a min-app in that context. |
|
|
|
|
|
|
| ▲ | skeptic_ai 2 hours ago | parent | prev [-] |
| That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago. |
| |
| ▲ | prologic 2 hours ago | parent | next [-] | | I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB). | | |
| ▲ | asdfsa32 2 hours ago | parent [-] | | LoB isn't going to reconcile Chat Messages rendering state and Notifications. Their dependent state by nature. HTMX largely seems to ignore this reality. In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists. | | |
| ▲ | Zanfa an hour ago | parent | next [-] | | > In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists. Which makes it even more ironic that in the 10 years since React was announced in 2013 and when I quit Facebook, they never managed to fix the original state synchronization bug that they demonstrated in the original React announcement for more than a few months at a time at best. I'm sure technically it wasn't a singular bug over the years and the causes were complex, but React did fuck all in relation to the unread message counter being correct. | |
| ▲ | an hour ago | parent | prev | next [-] | | [deleted] | |
| ▲ | greenchair an hour ago | parent | prev [-] | | right, so use the right tool for the job. most apps are boring CRUD apps and dont support chat. |
|
| |
| ▲ | Levitz an hour ago | parent | prev | next [-] | | That "massive hack" is supposed to be one of the core features of React. | |
| ▲ | asdfsa32 2 hours ago | parent | prev [-] | | But it is different this time, we are going back to HTML! /s |
|