4 ms·

What the htmx anti js crowd refuses to accept is the existence of applications that do not fit their world view. Serving html is trivial but do we really need

What the htmx anti js crowd refuses to accept is the existence of applications that do not fit their world view. Serving html is trivial but do we really need every back-end juggling this stuff just to make these guys happy? What do they do when they have to support a number of clients. Oops...

asciiresort 4y ago
> back-end juggling this stuff just to make these guys happy? I don't see this design pattern as forcing a particular back-end framework? It's merely shifting the frontend<-->backend contract from JSON to HTML. Some backend engineers arguably would prefer HTML. Especially if their backends weren't Node. Backends were originally C servers that sent a string of HTML back. I think backend engineers are fully capable of "juggling" with this new/old paradigm.
- ducharmdev 4y ago
  The problem with using HTML in this way is that it couples the view with your data. What happens when non-browser clients (e.g. mobile, other servers) need to easily consume the same API? I know some projects plan to only ever use browser clients, so this may seem irrelevant for them. But I'd rather not try to predict how a business will want to use it's data in the future, and would prefer to design a backend that can be adapted to many scenarios without being bound to a particular client.
  - asciiresort 4y ago
    > But I'd rather not try to predict how a business will want to use it's data in the future Sure, then the backend can expose a gRPC / protobuf interface instead. Mobile apps can readily deserialize this and it will be more performant, both in network bandwidth and data parsing, too, especially with first-party to first-party SDKs. It's strongly typed and serves as a better data contract language than both HTML and JSON. JSON is loosey goosey because of JavaScript. Then the frontend server now plays the role of aggregating data from gRPC backends and converting it to HTML. The gravitation to JSON is a case of web developer familiarity.
julienfr112 4y ago
This ain't such thing as a world view, it's only about tradeoffs. When you build something that is highly transactional, say booking train tickets, and you don't have the resources, like dozen of 200k-400k a year devs, you are better of with a really short path between the where the state is stored and what is displayed to the user. What we are seeing currently is something like that : DB(ms sql, ...) <-> [ microservices(java spring ?) ] <-> FrontEnd (react ?) With few integration tests and load testing, legacy authentication with oauth or oidc on top, and a really poor user experience (see https://www.sncf-connect.com/ https://www.sncf-connect.com/). The user experience is in fact poorer that it use to be with php, and even lousier than it use to be with https://en.wikipedia.org/wiki/Minitel https://en.wikipedia.org/wiki/Minitel The "antijs crowd" is saying : When it's relevant, let's make more simple systems, but let's still offer solution for some interactivity in the frontend. That's it, it's not a "world view".
vehemenz 4y ago
I think it kind of goes both ways. People knee-deep in the React ecosystem are dismissive of problems that don't require a full application implemented in a heavy, opinionated framework.
recursivedoubts 4y ago
as I have said many times: the hypermedia approach isn't right for everything, htmx just makes it possible to address a much larger UX space using that model than plain HTML does: https://www.reddit.com/r/htmx/comments/ufsqcj/vue_angular_react_svelte_or_lock_in_and_use_htmx/i6wehos/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/htmx/comments/ufsqcj/vue_angular_re... > So, consider something like google sheets, with a large number of dependent cells that need to be recomputed and synced on every cell entry. Probably not a good idea to jam an HTTP request after every cell edit, and a place where a more elaborate SPA framework is called for. On the other hand, maybe htmx is useful for the settings page for that application. And for something like Gmail, htmx would be perfect.

asciiresort 4y ago

> back-end juggling this stuff just to make these guys happy? I don't see this design pattern as forcing a particular back-end framework? It's merely shifting the frontend<-->backend contract from JSON to HTML. Some backend engineers arguably would prefer HTML. Especially if their backends weren't Node. Backends were originally C servers that sent a string of HTML back. I think backend engineers are fully capable of "juggling" with this new/old paradigm.

ducharmdev 4y ago
The problem with using HTML in this way is that it couples the view with your data. What happens when non-browser clients (e.g. mobile, other servers) need to easily consume the same API? I know some projects plan to only ever use browser clients, so this may seem irrelevant for them. But I'd rather not try to predict how a business will want to use it's data in the future, and would prefer to design a backend that can be adapted to many scenarios without being bound to a particular client.
- asciiresort 4y ago
  > But I'd rather not try to predict how a business will want to use it's data in the future Sure, then the backend can expose a gRPC / protobuf interface instead. Mobile apps can readily deserialize this and it will be more performant, both in network bandwidth and data parsing, too, especially with first-party to first-party SDKs. It's strongly typed and serves as a better data contract language than both HTML and JSON. JSON is loosey goosey because of JavaScript. Then the frontend server now plays the role of aggregating data from gRPC backends and converting it to HTML. The gravitation to JSON is a case of web developer familiarity.

julienfr112 4y ago

This ain't such thing as a world view, it's only about tradeoffs. When you build something that is highly transactional, say booking train tickets, and you don't have the resources, like dozen of 200k-400k a year devs, you are better of with a really short path between the where the state is stored and what is displayed to the user. What we are seeing currently is something like that : DB(ms sql, ...) <-> [ microservices(java spring ?) ] <-> FrontEnd (react ?) With few integration tests and load testing, legacy authentication with oauth or oidc on top, and a really poor user experience (see https://www.sncf-connect.com/ https://www.sncf-connect.com/). The user experience is in fact poorer that it use to be with php, and even lousier than it use to be with https://en.wikipedia.org/wiki/Minitel https://en.wikipedia.org/wiki/Minitel The "antijs crowd" is saying : When it's relevant, let's make more simple systems, but let's still offer solution for some interactivity in the frontend. That's it, it's not a "world view".

vehemenz 4y ago

I think it kind of goes both ways. People knee-deep in the React ecosystem are dismissive of problems that don't require a full application implemented in a heavy, opinionated framework.

recursivedoubts 4y ago

as I have said many times: the hypermedia approach isn't right for everything, htmx just makes it possible to address a much larger UX space using that model than plain HTML does: https://www.reddit.com/r/htmx/comments/ufsqcj/vue_angular_react_svelte_or_lock_in_and_use_htmx/i6wehos/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/htmx/comments/ufsqcj/vue_angular_re... > So, consider something like google sheets, with a large number of dependent cells that need to be recomputed and synced on every cell entry. Probably not a good idea to jam an HTTP request after every cell edit, and a place where a more elaborate SPA framework is called for. On the other hand, maybe htmx is useful for the settings page for that application. And for something like Gmail, htmx would be perfect.