3 ms·

I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write. There's t

by dminik 2y ago

I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write. There's this vague general sense that the "Web used to be simple" and that "Everything is so complex now". There's even an enemy that can be pointed at: React and various other frameworks/libraries and JS tools. Sometimes even JS itself isn't safe from this. Though I can never find myself agreeing with the arguments (if any get presented at all). There's a reason we're writing web APPS instead of web SITES now even if you might dislike it. Just as there's a reason the world itself is now more complex now. Ultimately I don't hate HTMX or the people who want to use it. Though to me the experience of actually using it is awful. I would ask people that they don't pretend that the backend ecosystem is any different from JavaScript. By the time you've chosen the language, debated the backend framework/chosen your templating solution and DB library and build system you could have gotten through the decision paralysis for JS too.

sensanaty 2y ago
As a fullstack dev doing roughly 50/50 of both, massive agree. At least in JS land it's just JS, in the backend you even have to choose between entirely different languages sometimes, all of which have similar complexities to deal with. By comparison, especially these days, making something like a Vue or React app couldn't be simpler. You run a single command and get everything generated for you, then you point it to one of a million free hosting sites out there and boom presto, you're live. I feel like people are just afraid/cocky to admit they're too lazy to think about the frontend for whatever reason. All the arguments I've ever heard have been quite shallow and easily disproven if you spend, like, 5 minutes reading through some docs.
recursivedoubts 2y ago
Glad to hear that ultimately you don't hate htmx or the people that use it. htmx is a good choice for some types of applications: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ it isn't right for everything, as I try to outline here: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ i think i've been open and honest about when the hypermedia approach is appropriate and when it isn't and I've been open about posting bad experiences with the library: https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/#on-the-other-hand populist or not, i think the htmx website holds up pretty well when compared with other libraries/frameworks with respect to honestly outlining its pros and cons
- boredtofears 2y ago
  Just out of curiosity, do you know of any hypermedia/hateoas open source repositories that you'd recommend as good example implementations? The best I've found is the github v3 API but it would be nice to review different approaches.
  - nymanjon 2y ago
    Here's some hypermedia apps that I've made (caveat I use HTMF -- html-form on npm -- that is similar to HTMX but is simpler and stays closer to the native HTML): An offline first MPA: https://github.com/jon49/WeightTracker https://github.com/jon49/WeightTracker https://weight.jnyman.com/web/ https://weight.jnyman.com/web/ A progressively enhanced from no JS needed to JS with HTMF and web components to make it work a little nicer to partial offline support: https://github.com/jon49/cash https://github.com/jon49/cash This uses C# to progressively enhance the website: https://github.com/jon49/MealPlanner https://github.com/jon49/MealPlanner This is like the weight tracker app but is a soccer game tracking app. The game play is much more complex then anything I've made in the other apps, I almost used a micro front end for that page, but it works fine with hypermedia. It also is a SPA as the page is always the same page using hf-select (works the same as hx-select). I'll be removing the SPA part as it is really unnecessary. I just added it originally because I didn't like the code calling the service worker code on every page. I've since made it so the service worker is under 100 bytes and then calls in the other code using importScripts. https://github.com/jon49/Soccer https://github.com/jon49/Soccer I hope you find those examples useful. Hit me up if you have any questions on github.
    - deleted 2y ago
      [deleted]
raincole 2y ago
People acting like web dev was "simple" never fail to baffle me. Remember Flash? Java Applet? ActiveX? Adding interactivity to web pages has always been abominable work.
jrsj 2y ago
I think it's less of a distinctly populist thing and more of a "convert's zeal". I have seen this type of language used with a lot of different technologies over the years when there's a lot of hype and momentum around them. Ultimately there's just a lot of tradeoffs to make in this space and I'm glad that we have more options now. For awhile it seemed like you were either doing SPAs or everyone thought you were doing it "wrong", but things like HTMX, LiveView, Livewire, and Hotwire make it much easier to build good backend driven web apps. Inertia.js 2.0 is a really compelling middle ground as well & IMO is the best thing to come out of Laravel. You can get most of the benefits of a JS "metaframework", but you have adapters for many different backend and frontend frameworks.
- 0xblinq 2y ago
  Inertia is a godsend. We are using it at work and it’s such an amazing combination of the best of both worlds without all the craziness going on with the more popular meta frameworks.
jiriknesl 2y ago
When you are writing web APPs, you don't have to move as much logic to client as possible. I was writing web apps in 1998, with table layouts, almost no CSS and no JS. Of course, it was simple. It was so simple you can't imagine how. And it was the simplest in the golden age of MVC frameworks (like Django, Rails, Symfony) some 10-15 years ago. Since that, everything went downhill. Building sign in form or some simple form with validation and saving in database was 2 hours of work, 4 hours with testing and deployment. Salaries of devs were 1/4. Now, it takes 2 days to make a simple form, backend API, sync two states, run it via myriad of builders and minimisers and deploy it to production. Development now is 4 times less productive, 16 times more expensive for marginally better UX.
- fragmede 2y ago
  I mean webpack is slow, and css can be annoying sure, but c'mon, 2 days? I'm having trouble seeing that take two days unless you're doing a lot more than a form with two text input boxes and a button for signup and one for login in the modern version, which would make it an apples to oranges comparison.
  - jiriknesl 2y ago
    It's not just 2 input boxes, unfortunately. It's also a backend part, adding sessions, requiring the user to be signed in. It is also sign out functionality. In MVC framework, you just annotate a bunch of controllers, import Sign In and Sign Out functionality, and you are all set. Another examples might be building data grids, CRUD functionalities, or more complex validation situations. Back then, you designed database, generated CRUDs, it automatically added Bootstrap CSS compatible classes. You added one beforeSave handlers to add extra logic, and it was done. We web developers had to be competitive, because our competition were people using tools like Delphi, where you could drag'n'drop 30 screens in a day. It was ugly (default Windows 98 WinAPI look), it wasn't responsive, it wasn't prepared for people with disabilities, but it was hyperproductive.
  - dlisboa 2y ago
    2 days is fast. OP left out that most companies nowadays run a separate front end team, so now you need your backend team and front end team to have a meeting about what proper JSON should be returned, then the front end mocks that response and implements the form behavior, all the while the backend implements server functionality, then someone else (usually) tests this integration, then someone else deploys it. If nothing in that multi-team communication pipeline breaks you’re very lucky. If you can all get that done in 2 days you’re running a very fast dev team. Minus the QA and DevOps team my point is that a SPA/JavaScript-heavy web app is not only a technological choice but an organizational one. Things used to be faster because there were fewer divisions in the software, therefore fewer divisions in the organization.
paulddraper 2y ago
Right? Did we forget Spring was a thing? Did someone solve async Rust? And the only thing more numerous than JS frameworks is new databases. Let’s not kid ourselves, this has always been hard.
iuvcaw 2y ago
Right… I think HTMX is cool and would like to try it. But the argument that “we need to go back to when things were simpler” just falls so flat to me. I remember the Web 20 years ago. It was pretty bad and ugly and slow and clunky and unintuitive. We’ve made a lot of progress since then thanks in part to the powerful front-end state management and rendering solutions that are now standard. And if the argument is “we don’t need all that, I prefer simpler web pages…” then I just think you may have a totally different preference set from the average user. Normal non-engineers like sleek modern interfaces, not Web 1.0 forms and links and reloads
- cryptos 2y ago
  As someone else wrote: we have apps and not websites now and if you look at what was named "HTML5" it is basically a software platform where you can run applications on. It really is client application development today, html is just the UI lanuage for historic reasons, but even that is no longer true in all cases (I'm thinking of Flutter or Compose). So, maybe even HTML is not that relevant in many cases.
  - chuckadams 2y ago
    > we have apps and not websites now Is it too out there to say that we have both, and that's not a bad thing?
- masfoobar 2y ago
  20 years ago we were using the likes of PHP4 or Classic ASP or perhaps Perl for server-side languages. Possibly the early days of VB.NET (ASP.NET) being a thing. Some sites created 20 years ago were still not making use of AJAX, either. If they were, in very specific ways. It is more likely to be using IFRAMEs back then to achieve partial refresh. Today, the difference is that we still apply "the old ways" building websites but with modern languages + htmx. This is the difference. When I look at websites I have created or inherited, all I see if bloat crossing between code written on the server-side... and code on the client-side. The further back in time I go the more it was server-side but, as mentioned, begin to lack the AJAX side of it. Personally, I prefer to be back to the vast majority being server-side code. Sure, the amount of Views (and Partial Views) on my backend codebase is much higher than before but it is still organised code and testable without even using a browser. I then let htmx do the magic onto the webpage. I have success stories but I also mock some things I did in the past but with htmx and it is very promising! Sure I am still using Javascript but it is not ready about the data anymore - mostly additional libraries used for better drop down features or other cosmetics/UI things. EDIT - ADDED: It is worth noting that the last 20 years, despite various javascript frameworks from React to Angular to knockout to jQuery to MooTools, etc..... we also had Flash and Silverlight and other things. We also have HTML5, CSS3, etc. I have tried many things in the last 20 years. I also accept that htmx, while my goto choice for todays web development... is not going to be the best choice in my future. Web Assembly (WASM) is going to get better and more popular. It will not be about HTML coding like today or even javascript in many ways. They will still be there, of course. (Javascript will always be there but its use will get smaller and smaller)
vlz 2y ago
> I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write. Funnily I get quite irrationally conservative vibes the other way around. People clinging to their tools. All this complexity I learned must have been for a reason! We are building webapps for a reason (and that reason is valid for absolutely everybody and their use case)! "You youngsters do not remember the bad old days when everything was made of spaghetti, never again!" Fortunately this is not a struggle for democracy but only a quibble in web development. Your abstractions live either in the frontend or in the backend. For most cases, either will be quite fine.
- BackBlast 2y ago
  > All this complexity I learned must have been for a reason! It doesn't have to be so emotional. Htmx can be helpful to keep all your state in one place, it's simpler to reason about and make changes. Lower cognitive load for the system is better for smaller teams and particularly lone developers. You can accomplish the same thing by going full front end and minimize backend code with a similar small library that takes care of most to all of it for you. Living in the front end, with all app state in the front end, has distinct advantages. Lower latency for interaction. Lower server costs. Offline capable. It has some cons like slower initial render. If you don't like JavaScript, JavaScript.
  - nymanjon 2y ago
    > Lower latency for interaction. Unless you are optimistic in your approach, that isn't true, both have to talk to the back end. > Lower server costs. Not necessarily. It depends on what language on the back end you're using and how your front end code is working. If it is making the API calls anyway then the cost should be the same, or close to the same. > Offline capable. Offline support with HATEOS: https://github.com/jon49/WeightTracker https://github.com/jon49/WeightTracker Progressively enhanced (No JS needed all the way to offline support) with partial offline support: https://github.com/jon49/cash https://github.com/jon49/cash

by dminik 2y ago

sensanaty 2y ago

As a fullstack dev doing roughly 50/50 of both, massive agree. At least in JS land it's just JS, in the backend you even have to choose between entirely different languages sometimes, all of which have similar complexities to deal with. By comparison, especially these days, making something like a Vue or React app couldn't be simpler. You run a single command and get everything generated for you, then you point it to one of a million free hosting sites out there and boom presto, you're live. I feel like people are just afraid/cocky to admit they're too lazy to think about the frontend for whatever reason. All the arguments I've ever heard have been quite shallow and easily disproven if you spend, like, 5 minutes reading through some docs.

recursivedoubts 2y ago

Glad to hear that ultimately you don't hate htmx or the people that use it. htmx is a good choice for some types of applications: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ it isn't right for everything, as I try to outline here: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ i think i've been open and honest about when the hypermedia approach is appropriate and when it isn't and I've been open about posting bad experiences with the library: https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/#on-the-other-hand populist or not, i think the htmx website holds up pretty well when compared with other libraries/frameworks with respect to honestly outlining its pros and cons

boredtofears 2y ago
Just out of curiosity, do you know of any hypermedia/hateoas open source repositories that you'd recommend as good example implementations? The best I've found is the github v3 API but it would be nice to review different approaches.
- nymanjon 2y ago
  Here's some hypermedia apps that I've made (caveat I use HTMF -- html-form on npm -- that is similar to HTMX but is simpler and stays closer to the native HTML): An offline first MPA: https://github.com/jon49/WeightTracker https://github.com/jon49/WeightTracker https://weight.jnyman.com/web/ https://weight.jnyman.com/web/ A progressively enhanced from no JS needed to JS with HTMF and web components to make it work a little nicer to partial offline support: https://github.com/jon49/cash https://github.com/jon49/cash This uses C# to progressively enhance the website: https://github.com/jon49/MealPlanner https://github.com/jon49/MealPlanner This is like the weight tracker app but is a soccer game tracking app. The game play is much more complex then anything I've made in the other apps, I almost used a micro front end for that page, but it works fine with hypermedia. It also is a SPA as the page is always the same page using hf-select (works the same as hx-select). I'll be removing the SPA part as it is really unnecessary. I just added it originally because I didn't like the code calling the service worker code on every page. I've since made it so the service worker is under 100 bytes and then calls in the other code using importScripts. https://github.com/jon49/Soccer https://github.com/jon49/Soccer I hope you find those examples useful. Hit me up if you have any questions on github.
  - deleted 2y ago
    [deleted]

raincole 2y ago

People acting like web dev was "simple" never fail to baffle me. Remember Flash? Java Applet? ActiveX? Adding interactivity to web pages has always been abominable work.

jrsj 2y ago

I think it's less of a distinctly populist thing and more of a "convert's zeal". I have seen this type of language used with a lot of different technologies over the years when there's a lot of hype and momentum around them. Ultimately there's just a lot of tradeoffs to make in this space and I'm glad that we have more options now. For awhile it seemed like you were either doing SPAs or everyone thought you were doing it "wrong", but things like HTMX, LiveView, Livewire, and Hotwire make it much easier to build good backend driven web apps. Inertia.js 2.0 is a really compelling middle ground as well & IMO is the best thing to come out of Laravel. You can get most of the benefits of a JS "metaframework", but you have adapters for many different backend and frontend frameworks.

0xblinq 2y ago
Inertia is a godsend. We are using it at work and it’s such an amazing combination of the best of both worlds without all the craziness going on with the more popular meta frameworks.

jiriknesl 2y ago

When you are writing web APPs, you don't have to move as much logic to client as possible. I was writing web apps in 1998, with table layouts, almost no CSS and no JS. Of course, it was simple. It was so simple you can't imagine how. And it was the simplest in the golden age of MVC frameworks (like Django, Rails, Symfony) some 10-15 years ago. Since that, everything went downhill. Building sign in form or some simple form with validation and saving in database was 2 hours of work, 4 hours with testing and deployment. Salaries of devs were 1/4. Now, it takes 2 days to make a simple form, backend API, sync two states, run it via myriad of builders and minimisers and deploy it to production. Development now is 4 times less productive, 16 times more expensive for marginally better UX.

fragmede 2y ago
I mean webpack is slow, and css can be annoying sure, but c'mon, 2 days? I'm having trouble seeing that take two days unless you're doing a lot more than a form with two text input boxes and a button for signup and one for login in the modern version, which would make it an apples to oranges comparison.
- jiriknesl 2y ago
  It's not just 2 input boxes, unfortunately. It's also a backend part, adding sessions, requiring the user to be signed in. It is also sign out functionality. In MVC framework, you just annotate a bunch of controllers, import Sign In and Sign Out functionality, and you are all set. Another examples might be building data grids, CRUD functionalities, or more complex validation situations. Back then, you designed database, generated CRUDs, it automatically added Bootstrap CSS compatible classes. You added one beforeSave handlers to add extra logic, and it was done. We web developers had to be competitive, because our competition were people using tools like Delphi, where you could drag'n'drop 30 screens in a day. It was ugly (default Windows 98 WinAPI look), it wasn't responsive, it wasn't prepared for people with disabilities, but it was hyperproductive.
- dlisboa 2y ago
  2 days is fast. OP left out that most companies nowadays run a separate front end team, so now you need your backend team and front end team to have a meeting about what proper JSON should be returned, then the front end mocks that response and implements the form behavior, all the while the backend implements server functionality, then someone else (usually) tests this integration, then someone else deploys it. If nothing in that multi-team communication pipeline breaks you’re very lucky. If you can all get that done in 2 days you’re running a very fast dev team. Minus the QA and DevOps team my point is that a SPA/JavaScript-heavy web app is not only a technological choice but an organizational one. Things used to be faster because there were fewer divisions in the software, therefore fewer divisions in the organization.

paulddraper 2y ago

Right? Did we forget Spring was a thing? Did someone solve async Rust? And the only thing more numerous than JS frameworks is new databases. Let’s not kid ourselves, this has always been hard.

iuvcaw 2y ago

Right… I think HTMX is cool and would like to try it. But the argument that “we need to go back to when things were simpler” just falls so flat to me. I remember the Web 20 years ago. It was pretty bad and ugly and slow and clunky and unintuitive. We’ve made a lot of progress since then thanks in part to the powerful front-end state management and rendering solutions that are now standard. And if the argument is “we don’t need all that, I prefer simpler web pages…” then I just think you may have a totally different preference set from the average user. Normal non-engineers like sleek modern interfaces, not Web 1.0 forms and links and reloads

cryptos 2y ago
As someone else wrote: we have apps and not websites now and if you look at what was named "HTML5" it is basically a software platform where you can run applications on. It really is client application development today, html is just the UI lanuage for historic reasons, but even that is no longer true in all cases (I'm thinking of Flutter or Compose). So, maybe even HTML is not that relevant in many cases.
- chuckadams 2y ago
  > we have apps and not websites now Is it too out there to say that we have both, and that's not a bad thing?
masfoobar 2y ago
20 years ago we were using the likes of PHP4 or Classic ASP or perhaps Perl for server-side languages. Possibly the early days of VB.NET (ASP.NET) being a thing. Some sites created 20 years ago were still not making use of AJAX, either. If they were, in very specific ways. It is more likely to be using IFRAMEs back then to achieve partial refresh. Today, the difference is that we still apply "the old ways" building websites but with modern languages + htmx. This is the difference. When I look at websites I have created or inherited, all I see if bloat crossing between code written on the server-side... and code on the client-side. The further back in time I go the more it was server-side but, as mentioned, begin to lack the AJAX side of it. Personally, I prefer to be back to the vast majority being server-side code. Sure, the amount of Views (and Partial Views) on my backend codebase is much higher than before but it is still organised code and testable without even using a browser. I then let htmx do the magic onto the webpage. I have success stories but I also mock some things I did in the past but with htmx and it is very promising! Sure I am still using Javascript but it is not ready about the data anymore - mostly additional libraries used for better drop down features or other cosmetics/UI things. EDIT - ADDED: It is worth noting that the last 20 years, despite various javascript frameworks from React to Angular to knockout to jQuery to MooTools, etc..... we also had Flash and Silverlight and other things. We also have HTML5, CSS3, etc. I have tried many things in the last 20 years. I also accept that htmx, while my goto choice for todays web development... is not going to be the best choice in my future. Web Assembly (WASM) is going to get better and more popular. It will not be about HTML coding like today or even javascript in many ways. They will still be there, of course. (Javascript will always be there but its use will get smaller and smaller)

vlz 2y ago

> I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write. Funnily I get quite irrationally conservative vibes the other way around. People clinging to their tools. All this complexity I learned must have been for a reason! We are building webapps for a reason (and that reason is valid for absolutely everybody and their use case)! "You youngsters do not remember the bad old days when everything was made of spaghetti, never again!" Fortunately this is not a struggle for democracy but only a quibble in web development. Your abstractions live either in the frontend or in the backend. For most cases, either will be quite fine.

BackBlast 2y ago
> All this complexity I learned must have been for a reason! It doesn't have to be so emotional. Htmx can be helpful to keep all your state in one place, it's simpler to reason about and make changes. Lower cognitive load for the system is better for smaller teams and particularly lone developers. You can accomplish the same thing by going full front end and minimize backend code with a similar small library that takes care of most to all of it for you. Living in the front end, with all app state in the front end, has distinct advantages. Lower latency for interaction. Lower server costs. Offline capable. It has some cons like slower initial render. If you don't like JavaScript, JavaScript.
- nymanjon 2y ago
  > Lower latency for interaction. Unless you are optimistic in your approach, that isn't true, both have to talk to the back end. > Lower server costs. Not necessarily. It depends on what language on the back end you're using and how your front end code is working. If it is making the API calls anyway then the cost should be the same, or close to the same. > Offline capable. Offline support with HATEOS: https://github.com/jon49/WeightTracker https://github.com/jon49/WeightTracker Progressively enhanced (No JS needed all the way to offline support) with partial offline support: https://github.com/jon49/cash https://github.com/jon49/cash