← Back to context

Comment by blister

1 day ago

I've been using htmx for three years now, and it's completely unlocked new ways of building software for the web, especially if you use a server-side templating language.

But more importantly (as this "Game Boy" option reveals), the head honcho is really responsive with the items in the store. I had purchased a coffee mug a few years back and complained on Twitter that they need to sell larger mugs instead of only offering little tiny baby mugs that only hold ~8 ounces of liquid. The next day, he added giant 48-ounce monsters to the store and I've been drinking out of that mug every day since.

52 comments

blister

Reply
Grimblewald  1 day ago

It's been massive for me as well. I would say my web developmemt is best described as dabbling in web development, and I mostly do so for websites that cater to academic interests and conference / society managment and organising. So, relativly niche.

However, I think HTMX is a beauty. Fast, simple, and doesnt come with all the bloat and BS a JS heavy / JS first deployment comes with. I can quikckly build fast and responsive sites that cost visitors very little to use/interact with.

websites have less compatability issues now, load extremely fast (google web speed score from 60-80 to flat 100), and have fewer points of failure. Debugging is a breeze. Websites are no less pretty or useful for it. In fact, they look better now because time otherwise wasted on Js BS is now free to use to tinker with / improve aesthetic, or add new features.

I'm in love with HTMX. It feels like what the web should have always been. There's absolutly zero reason a random website, without my knowledge or consent, should be running extremely heavy compute and analytics on my own device. That should never have been possible/permissible in the first place.

stevoski  1 day ago

> I've been using htmx for three years now, and it's completely unlocked new ways of building software for the web, especially if you use a server-side templating language.

Likewise. 3 or 4 years ago, I ripped out two-thirds of all the JS in my B2B SaaS by using htmx with server-side templating. So much simpler.

The ethos of allowing a return to a simpler way of building a web app resonates with me.

addaon  20 hours ago

> The next day, he added giant 48-ounce monsters to the store and I've been drinking out of that mug every day since.

This was my trick for cutting back to two cups of coffee a day.

hi_hi  20 hours ago

> it's completely unlocked new ways of building software for the web, especially if you use a server-side templating language.

Could you please expand on this point. As a “greybeard” web dev from the 2000’s era, I’d like to understand if your “unlocking” is my “that’s how it originally worked, get of my lawn”?

  • masfoobar  13 hours ago

    Yes - how you likely built websites in 2000's era (possibly with Classic ASP or PHP4 .. maybe Perl?) is the sort of websites we are addressing with HTMX.

    It's bringing us back to that sort of web development but with modern tools and technology.

    For the server side, we can use modern languages with better templating for html.

    For the client, with htmx, you can do a lot of javascript such as ajax calls (load, trigger, etc) without writing javascript. With htmx you specify what you want to do inside html attributes.

    So my actual javascript code ends up minimal.

    I have been doing website dev since 2008. I've worked with PHP, C# (WebForms, MVC), a bit of python... not to mention maintaining an old website in Classic ASP.

    2008-2010 I used C# WebForms. I didn't like it, but we still kept it simple, returning data from server side to html.

    2010 I started to enjoy jQuery and saw potential returning data. Opened the door to provide more options for webdev.

    Around 2014, I've started disagreeing with "modern website development" learning knockoutjs, requirejs, to eventually angularjs, npm's, etc. Sure, I learned and pushed forward but websites seemed to become more a chore and bloat overtime. Personally, I've not really invested in React.

    I was starting to go round full circle to the 'old ways' just with modern tech. To me, htmx just makes webdev even more smoother.

  • aktau  17 hours ago

    I have the same question. It seems like a decent amount of posters here don't require (non-standard) interactivity. Plain HTML+CSS (perhaps via static site generators) would work.

    It made me think about the Javascript present on my blog. The site works fine without JS (syntax high-lighting is pre-baked server-side).

    There is some optional JS enhancement:

      - MathJax is used for turning LaTeX expressions into nice graphics on the client-side. A search reveals this could be done on the server-side, but I'd need to deal with the node.js ecosystem.
  - PJAX is enabled [1]. This is completely optional, but it noticeably made page navigation faster (feel instant), especially when navigating between pages already visited (forwards/backwards).

    UPDATE: Reading https://triptychproject.org/, it seems like what PJAX does is item #3: "Partial page replacement"

    [1]: The library is at https://www.aktau.be/js/pjax-standalone.js. It is invoked at the end of <body>:

      pjax.connect({
    "container": "content",
    "complete": function() { MathJax.typesetPromise(); }, // Reload mathjax after a pjax load.
    "autoAnalytics": false
  });

sgt  1 day ago

Exactly, I just released another project made with htmx and it's almost like you can't beat that velocity.

germandiago  9 hours ago

Please I am all ears.

I have right now a landing page and a NiceGUI dashboard with websockets (but only need SSE, though I need charts).

I am all the time looking at htmx and used to "desktop-like" workflows for UI authoring.

So I went with NiceGUI. But I wonder if or what tasks I could sinolify. My sites are low/middle-traffic.

I do not need any API backend at all, just final user presentation.

mlhpdx  1 day ago

Likewise, I started using HTMX with AWS Step Functions as the backend and it’s been difficult but also a joy. Sfn these days makes for a weird and wild text templating engine. I’ve been thinking about working on DSL overlay to smooth the bumps a bit.

  • _jackdk_  1 day ago

    That is not a use cases I would've expected Step Functions to handle; I'm intrigued. You're using express ones, I assume, but how are you wiring them up and why?

    • mlhpdx  1 day ago

      API Gateway direct integration to Step Functions. Unlike Lambda, there is not automatic transform for requests so I just wrote one and copy/paste it to each method integration (via a preprocess script; one of the ugly bits). Yes, EXPRESS state machines. I’ve found they have better tail latency behavior, and of course they involve zero patching/dependency updates which is nice.

      The state machines use JSONata for the sweet, sweet power vs JSONPath. Generally I have a Parallel state that splits the different parts of the page and Map states for data driven repetition (usually some data pulled from DDB). I have a simple JSONata method for replacing placeholder values (aka data binding). Zero Lambda at the cost of come copy paste.

      I’m not unhappy with it despite the warts.

      1 reply →

orphereus  1 day ago

Sorry, but at that size (1.25 liters) for my European brain, it's not a mug anymore, it's a barrel.

  • TeMPOraL  1 day ago

    Right. People look at me funny for drinking my tea from a 500 ml thermal mug, courtesy of USS Defiant replicators, and it's not because of the Starfleet delta on it (people don't even recognize it, philistines).

    1.25 liters is way beyond even my own addiction to lightweight liquid stimulants.

  • walthamstow  1 day ago

    It's more than double the size of a Sports Direct mug, which is about the largest cup of tea a Briton would consider

scumdude  1 day ago

Tell me about it. I made a joke about the store selling 'Complexity Bad' onesies, and he started selling them later that day.

https://x.com/scumitchell/status/1886825775560528069?s=20

sublinear  1 day ago

So you drink weak coffee and insist on server-side rendering in 2026?

  • evenhash  1 day ago

    In 2026, everything is server side. Serve your DOM updates encoded in JSON if you want. Personally, I find serving them in HTML to be less of a hassle.

  • SpaceNoodled  1 day ago

    The server SHOULD do the rendering. It's a SERVER, not a give-me-a-bunch-of-bloated-junk-and-make-me-do-it-myself-er.

    • KronisLV  6 hours ago

      I mean a radically different view is that the SERVER should just give you the data and process your requests, without necessarily caring much about what you are - a browser or some other automated system, or a desktop client, where each has vastly different preferences on how the content might get displayed or used.

      With that approach, a clear API in the middle and a SPA on the client side makes a bunch of sense (as long as you don't make some chimera of hydration and pre-rendering and server-side components while pretending that it's still a SPA and it "just works" while your server is coupled to the client).

      Of course, what you actually need depends on your circumstances and sometimes even preferences. For a bunch of internal or personal stuff, SSR can be really nice and simple!