16 ms·

Htmx and Web Components: A Perfect Match

257 points by alexzeitler 3y ago

Kiro 3y ago
Is anyone using htmx in a large project? Seems like it could be great for small things, but unmaintainable at scale, and that all the praise is based on the former. Something tells me that the backlash will be enormous.
- karmarepellent 3y ago
  There is the occasional tech talk on YouTube where some kind of migration from React to HTMX in a large project is discussed. You will have to search though as I do not have any links at the ready. However I have not seen anything really substantial either that confirms that HTMX works in large projects just as well as in smaller ones. I plan to use HTMX in another larger, upcoming project though as I want to gain some insights on the side too. That being said I am aware that it might turn out to be a mess. But I would be content with the fact that HTMX is generally very useful for smaller projects and just put it in my respective imaginary toolbox to keep in mind for those kinds of projects.
  - rob 3y ago
    Link, from 2022: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ Every time this is brought up (use in larger projects), people usually only mention this article/video and nothing else, so I'm not sure if that's a good or bad thing.
    - karmarepellent 3y ago
      Yes, that is exactly my point! I think the lack of real world examples of large HTMX projects is a little telling. But it might just be large projects usually happen in large companies where you aren't necessarily allowed to disclose project details to the community. Again, I think at this stage the best way to determine if HTMX is a viable option for large projects is to try and ideally share your insights. To be honest I am looking forward to the day when we can put all the HTMX/React whatever debates to rest and it will just be another great tool amongst other tools.
      - Woshiwuja 3y ago
        to be fair unless you are doing a complete rewrite it doenst make much sense to swap frontend. I bet we will see later this year htmx getting used because of people getting confortable with it
        cqqxo4zV46cp 3y ago
        htmx’s growth trajectory isn’t as steep as you’re making out with that expectation. I remember seeing conference talks about it ages ago. It’s ostensibly getting more interest now sure, if not legitimate adoption, but it does feel like more of the early starters would have something to share by now. For the record, I hope that it succeeds.
        recursivedoubts 3y ago
        finished a close second behind react and ahead of svelte, vue, vue2, vue + vue2, angular, solidjs, quick: https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date https://star-history.com/#bigskysoftware/htmx&bigskysoftware... idk what a steep growth trajectory is to you, but this has felt pretty steep to me: https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date https://star-history.com/#bigskysoftware/htmx&bigskysoftware...
        Woshiwuja 3y ago
        also: https://star-history.com/#bigskysoftware/htmx&facebook/react&Date https://star-history.com/#bigskysoftware/htmx&facebook/react...
        recursivedoubts 3y ago
        sure, but click "align timelines" and then consider I'm a one man shop in montana, and facebook is, well, facebook: https://star-history.com/#bigskysoftware/htmx&facebook/react&Timeline https://star-history.com/#bigskysoftware/htmx&facebook/react... not saying htmx is gonna replace react any time soon, but c'mon, it finished #2 right behind react in rising stars, that's pretty good
    - boringuser2 3y ago
      >The effort took about 2 months (with a 21K LOC code base, mostly JavaScript) That isn't a very large codebase for frontend, I'd expect one person to be able to do that in less than one month if they're actually trying.
  - zer00eyz 3y ago
    >> that confirms that HTMX works in large projects Define large? By size of project or volume of users. HTMX is more targeted for the latter, not the former. THere is a continuum. Static pages, SSG's on one side, and SPAs/react all the way at the opposite end. They both do VERY different things. HTMX is some where in the middle, think content heavy PAGES that need lightweight public facing interaction (email/contact, validation loops, a form or two, maybe some dynamic conversions, a carrousel) Static home page for cache performance, html for sales contact cycle, react for the app you sell ... all three can and should be coexisting!
- sli 3y ago
  In theory it seems like it should scale like a variation on a pretty standard full stack application that does the HTML work on the backend -- as opposed to a SPA -- but instead sends fragments instead of entire pages. I'm also be curious to see how it plays out in practice, since it's been pretty neat for my small projects and I'm intrigued by it, generally.
- davedx 3y ago
  I doubt it. I think it's like svelte, but a bit earlier in the hype cycle. The "State of JavaScript" survey is illuminating for these kinds of technologies. They often follow a trajectory towards "more liked", while remaining consistently and firmly in the "not used" quadrant. Everyone thinks they look amazing and refreshing, and maybe some people have even actually written some small apps in them, but (almost) nobody is using them at scale. It's not a bad thing really, but the hype can be annoying
  - caseyf 3y ago
    Everyone using modern Rails/Hotwire (including 37 signals) is using basically the same architecture, does that count?
    - polycaster 3y ago
      I wouldn't categorize Hotwire as a well-established technology simply because it's included with Rails. Its prominence isn't solidified even with support from notable figures – as all tech trends have their advocates. In my perspective, it's somewhat analogous to htmx: The cool kids are using it for smaller, manageable use cases, but it's far apart, like magnitudes, from the adoption React has.
    - davedx 3y ago
      I've used Rails for small-medium sized projects and overall have a good impression of it (I'd even argue it did a lot to drive web development forwards) and I know there are still orgs out there using it regularly, but is Rails honestly still being used to build large scale apps (excepting the ones that have already been around forever like Github)? Every org I've worked at since the last Rails project I worked on around 2014 has built JavaScript heavy thick clients on top of API's. That's not really where Rails shines, and I've not seen it around at all for newer projects since roughly that time. It's anecdotal, but it's my experience that the industry has largely settled on the SPA + API's architecture, and the technologies every org I've worked at use to build those SPA's are either React, Angular, Vue, or very occasionally for niche cases their own JavaScript framework. I understand that some people on Hacker News still dislike the complexity of modern front ends, and I get it, I really do. But I haven't seen any real alternatives that have been seriously used in anger to build an actual commercial application since React, Angular (and Vue) took over.
- HackerThemAll 3y ago
  Majority of apps are small, yet they load tens of megabytes of javascript and it's becoming the unwanted norm. You can't browse many blogs without enabled javascript for no other reason than personal data harvesting needs.
  - zdragnar 3y ago
    Those are very different issues. React, Angular, Ember and co don't help you with your data harvesting one bit.
    - spinningslate 3y ago
      Agree they're different, but it's important not to miss the first point: > Majority of apps are small I'd like to see some data on it, but intuitively that resonates. The lighthouses of UI frameworks - notably React & Angular - emerged from the needs of big apps, with 100s of people, and structures that delineate front-end and back-end teams. The organisations behind the frameworks - Google, Meta - are very influential in setting industry direction. So those frameworks become "the way to do UI". That doctrine spreads through the community, and the context of origin and use is occluded. If htmx or similar drives a re-think then that's healthy to me. My own experience is with lots of comparatively small apps. Plain old server-side rendering hits the 80/20 for most, and something like htmx might move that indicatively to ~90/10. Which is attractive because it means 1 tech stack and comparatively less requirement for hard delineation of skills in dev teams. It's not saying "throw away React/Angular/..., you never need them". There are clearly situations where they're a good fit. Where fit means both organisational and technical. But they're not a good fit in every case.
      - zdragnar 3y ago
        React actually wasn't built for SPAs; Facebook built it for widgets on a server-rendered page. That is why it has no built in SPA features, like routing, data management, data fetching or other batteries a SPA or PWA might want. Conveniently, it provided a very nice set of primitive and composable APIs so that all of those features can be added on in a way that fits naturally, such as react-router and the rest of the ecosystem. That's all driven by the community, not the "lighthouse", so to speak. AngularJS likewise didn't require using the router, and in fact can just as easily run multiple instances on a single page. I haven't used Angular in years, so I don't know the story there. Same goes for Vue, but that's hardly backed by a "lighthouse". I don't disagree that there's no use for HTMX or server rendering of html. Not everything needs to be a SPA. The problem is the argument is a whole lot less convincing when presented with a lot of incorrect facts
- naasking 3y ago
  > Seems like it could be great for small things, but unmaintainable at scale, and that all the praise is based on the former Why does it seem that way? There are plenty of talks on youtube of commercial projects that switched from React to htmx and found considerable benefits.
  - beanjuiceII 3y ago
    where? I would love to see a big project in htmx, maybe our definition of big is different though.
    - naasking 3y ago
      For example: https://www.youtube.com/watch?v=3GObi93tjZI&pp=ygUJaHRteCB0YWxr https://www.youtube.com/watch?v=3GObi93tjZI&pp=ygUJaHRteCB0Y...
      - elvennn 3y ago
        21k LOC ...
        beanjuiceII 3y ago
        yea 21k lines of code is like a tinymicro project :|
      - DrammBA 3y ago
        Do you have any other project besides 2022 example from the htmx website that everyone shares every time?
    - deleted 3y ago
      [deleted]
- recursivedoubts 3y ago
  https://htmx.org/essays/does-hypermedia-scale/ https://htmx.org/essays/does-hypermedia-scale/
- jbergens 3y ago
  I don't see any reason why it shouldn't scale. It also allows you to use any backend language. If you write messy code in php and think it is the language 's fault then you can use something else. Rust, Go, Java, C#, Elixir. Everything should work. Just don't write messy code.
ThePhysicist 3y ago
I don't get why people would use something like this, for most use cases this seems like a massive step back. I guess it's for applications where you want a little bit of interactivity but not build a complete single-page app. Which seems like a pretty small niche. The amount of boilerplate code and mental modeling needed for such a simple example seems absurd though. Personally I would just embed a small single-page app/snippet instead where I need more interactivity, stitching together server-rendered HTML like this seems quite bad. React for example is such a small and easy to use library, you don't even need a compiler toolchain to use it (makes code nicer to read of course), just drop the JS bundle in your HTML and write your component in a script tag, it will still be much easier to understand, use and modify than this.
- mariusor 3y ago
  Different developers have different skill sets. The mental model of different URLs giving you different distinct resources might make more sense for some. :P
- deleted 3y ago
  [deleted]
andrewstuart 3y ago
Am I right in my understanding that HTMx is kinda "adding data requests to document elements". I can see how that might be useful for simple things but for anything with any level of sophistication aren't you going to have to jump right into JavaScript? I just don't really get the big picture of HTMx. Is it making easy things easy and leaving hard things to React or Vue or whatever? Can someone please sell me on it - why should I be excited given that to get anything hard done I have to jump straight into JavaScript.
- masfoobar 3y ago
  I am writing a complicated website - the typical single page application and, so far, htmx is working wonders (and removing a lot of frontend work which I find duplicating data models already done on the server) One problem I did face is trying to put together a large json to a POST request. I did experiment if I could do this all in the 'htmx way' of using input=hidden but was not working. With this, it was best to store this as a JS variable, or call a JS function to return json, which was all specified in htmx (in html) Point is there are some exceptions that I have to do some javascript but the amount is much less when using other popular frameworks. Overall, I am doing most work using htmx and odd exceptions with simple javascript functions to returns text or json.. or javascript to compliment my css.
  - smallerfish 3y ago
    What was in your json? I've taken forms pretty far with htmx. Getting to accept "the state lives in the html" takes a bit of mental wrangling, but I've found it to hold up well so far. (One nice htmx trick is the ability to include hidden inputs/forms/whatever from outside the current form if necessary.)
    - mst 3y ago
      from outside? (I swear I've read the htmx docs but either I missed this part or I've forgotten it since)
      - 3y ago
BlackFly 3y ago
> Framework updates often render components not usable anymore (anyone has changed, or tried to, major versions of Vue or React recently?) I migrated my personal site from pure Vue 2 to Vue 4 + Nuxt recently. The migration guide was a garden path, but when I started a new project and just moved my components over into the conventional nuxt locations, everything went quite smoothly. My use case is quite narrow. It's basically a blog but with some embedded applications (mostly simulations), heavy use of a particular custom component. I like the hot swapping from the vue framework and I appreciate the static compilation of the result from Nuxt. I thought about doing something like HTMX + web components, but I would still need to figure out how to bundle what javascript into each page. Plus, web components have absolutely no server side rendering without another layer of complexity. Setting all that up seemed to me to be effort better spent on the occasional migration. Plus, when the going gets rough, Vue always had my back. My next step will be embedding wasm though... so that might change things, I'll see.
- jddj 3y ago
  > Vue 4 Is this a thing?
  - rk06 3y ago
    Nope, Vue is still in v3
    - worthless-trash 3y ago
      Time travellers go home.
    - BlackFly 3y ago
      What did I upgrade to 4 then? Vue router? I guess I got confused.
codie3611 3y ago
HTMX looks pretty much like something I would use for fast prototyping with very limited complexity/the scope is known ahead to stay simple. I've been working in full-stack for a decade together with extremely skilled engineers on large monorepos. Our wisdom is to stay as vanilla as reasonable and understand what your technology does underneath. As soon as there are layers over layers (tools calling tools with domain specific languages) you wish you could simply change X directly instead of having to go through e.g. create-react-app or htmx. But if any framework can provide me that level of comfort then I'm fine with it although I learned the more comfort frameworks provide the darker the other side.
- Woshiwuja 3y ago
  i disagree. making the backend format a div and send it back is much faster than creating a json, sending it to client and having the client hydrate stuff inside the page
  - replwoacause 3y ago
    I have found this to be true in my experience too, but I’m not a professional dev, rather a hobbyist, so HTMX suits me just fine. That isn’t to say it doesn’t have a place in the toolchain of professional devs though!
    - Woshiwuja 3y ago
      both things can be true at the same time! For an hobbyist you get to write less js. For a company you get faster apps. Its a win win situation
- infecto 3y ago
  I see these kind of comments pop up and as a long time backend/full-stack dev I don't follow the logic all too well. HTMX is just another tool to be deployed. If your app requires a SPA experience or large amounts of javascript for the UI, its not the right tool for the job. Where I have had great experience with it is for applications that have discrete javascript implementations or none. Lot's of applications that are quite valuable to the end user, are really just a bunch of CRUD like operations and don't really need a full blown FE framework.
wscourge 3y ago
The monospace font in the article is unpleasant to read
- cebert 3y ago
  HN guidelines suggest to not comment on the site itself, but I agree that the font immediately made me less excited to read this article even though I am interested about the topic.
randomdev3 3y ago
Good thing about htmx style solutions is that it's easy to implement the features you need without extra bs. Often it's so much simpler and cleaner to code something than using a generalized library or framework. You can still use react , vue, solid or whatever for the dynamic parts that make sense to do clientside
BurningPenguin 3y ago
I think it's also possible in Stimulus, if i'm not mistaken. Because i kinda prefer that one.
reportgunner 3y ago
Nice try but I'm not adding more javascript
andix 3y ago
Web Components can't be (pre-) rendered server side, right? I wouldn't chose a technology that comes with this limitation.
- DrScientist 3y ago
  Wrong. ( https://www.google.com/search?q=SSR+of+webcomponents https://www.google.com/search?q=SSR+of+webcomponents ) Though I'd admit it doesn't have the beautiful simplicity as concating some strings.
- demurgos 3y ago
  There's the declarative shadow DOM proposal for this but I don't think it's ready yet.
- _heimdall 3y ago
  That really depends on how you want to use web components. I have used custom elements quite a few times with Astro, mostly leveraging custom elements for life cycle events. I end up with a `.astro` file that server renders the HTML and adds a script to define the custom element. In the browser its more pike cheap hydration - the custom element doesn't re-render anything up front, it will just grab references to the server rendered DOM nodes and setup event handlers. I know Lit has an SSR helper, though I haven't used it myself I think its supposed to make server rendering you lit web components much easier.
brianzelip 3y ago
Here's HTMX author very recently talking about Web Components and HTMX on JS Party, https://changelog.com/jsparty/307#t=5260 https://changelog.com/jsparty/307#t=5260
deleted 3y ago
[deleted]
mediumsmart 3y ago
html and css say hello/wave goodbye
mortallywounded 3y ago
What are the impacts HTMX has on SEO/crawlability? I can't imagine doing XHR requests that return partial HTML snippets to be "good" for a crawler that expects one page to link to another (assuming they are running JS to begin with).
aljarry 3y ago
Is Htmx a good case for UI for a local application? I want to build a server app which I could host openly behind some auth, but at the same time I'd want to be able to run it in local mode, as a simple UI for local tests. I understand there are some security challenges, as in "local" mode it can only communicate over HTTP with local app, or probably without CORS, etc. XSS might be a real issue here.
- mortallywounded 3y ago
  Strange question... if something works over the public internet why would it not work locally? There's no magic sauce with HTMX. It's just a JavaScript library that does what a million others do. You can run it on a local toaster if you felt like it.
listless 3y ago
Web components are great! HTMX is great! But there is no answer for WHAT ABOUT THE JAVASCRIPT. You can't build a web app without it, so...what about bundling? What about binding? What about state? Yes, I understand that I'm doing it wrong and I need to do this on the server or something, but these are not specific enough answers which would make me abandon React or Vue which have great answers to all of these questions.
- recursivedoubts 3y ago
  https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/
xialvjun 3y ago
php + htmx should work good. But it's still website, not webapp. Complex front end operations are hard to implemente in htmx. api server + react/vue/angular work good. They are just js(templates compiled to js). They are for building webapps. Anyway, html is not turing complete.
shaunxcode 3y ago
I like both technologies as well! It feels like the sort of phase shift that happened when jquery got long in the tooth.
megaman821 3y ago
The real power of HTMX and Web Components is that Web Components self-initialize when they get attached to the DOM, so they are easy to AJAX in. This was always a PITA in the jQuery world since you would have to hunt down the new interactive elements and run a library's init function on them.
- boringuser2 3y ago
  I haven't seen the term "AJAX" used in years. Very bad sign both for the project and people mentioning it.
  - worthless-trash 3y ago
    Using a term is not a bad sign.
    - boringuser2 3y ago
      It means your knowledge is likely quite dated.
      - linkdd 3y ago
        AJAX literally is "async request from the client to the server". https://en.wikipedia.org/wiki/Ajax_(programming)#Technologies https://en.wikipedia.org/wiki/Ajax_(programming)#Technologie... XML (the X in AJAX) is not even necessary as JSON came in. Any React/Vue/Angular/... client application using `fetch` to make a request, is making an AJAX request. Just because you haven't seen the term in a long time does not mean it is outdated.
- hellcow 3y ago
  This is the exact use-case I found for them, and it’s terrific. I define any tag, e.g. <my-modal>, put normal HTML within it as if it were just a div, and then I can define the callbacks (like adding/cleaning up listeners) and custom attributes in a tiny bit of JS.
- 3y ago
rgbjoy 3y ago
So am I the only person seeing htmx and tailwind together and feeling absolutely disgusted? Like a wall of run on sentences and no paragraphs. I can’t believe tailwind is a thing…
- _lvbh 3y ago
  I used to love tailwind. Used it a ton. Not so much anymore. Plain CSS is enough for me.
- wg0 3y ago
  I have opposed Tailwind to no end. But I gave it a try and the portability it brings to markup is beyond description. You just move HTML from anywhere and it would just look exactly the same (subject to your overrides/customisations of course) so I don't think Tailwind is going away anywhere. Rather, it now can be thought of as a mini language or notation built on top of CSS.
- tuzemec 3y ago
  I personally don't like Tailwind. But I do see a lot of benefits of using utility classes for basic layout stuff. So far UnoCSS works very well for me. It's like light-weight and customizable Tailwind. Also for more complicated "components" I use css modules and refer to my theme values via directives (I think this is doable in Tailwind too?).
- naasking 3y ago
  The pain or disgust is a strong hint that you're thinking about it wrong. If you have a bunch of repetitive CSS, how do you typically eliminate that? You create a class that bundles it all together and then just use the class name on the HTML. But notice how you're then left with a bunch of repetitive HTML on which you apply those classes. If you bundle up the repetitive HTML into a reusable abstraction (like a component), then you're no longer repeating the CSS and so you don't need to bundle the CSS into classes anymore, thus reducing work. A type of inline styles, without the limitations, then gives you more direct control over styling on the bundled HTML itself. That's how you should use Atomic CSS/Tailwind.
- sergiotapia 3y ago
deleted 3y ago
[deleted]
b33j0r 3y ago
I am using htmx. I still have a nagging feeling that this has mostly dragged the overton window back towards hypermedia (big fan of the book, recommended). It still feels wrong. I don’t know if I mean wrong as in “incorrect” or wrong as in “cheating/too easy.” It gracefully makes sites work like it’s 2025 or 1999, but I have to design my markup like it’s 1999. I can never decide if this is good or bad. My projects all depend on an API for automation. So by buying into this doctrine, and rejecting even content negotiation, I am at least doubling my endpoints. It’s like being 12 years old, and falling in love with a “bad girl” who doesn’t go to church—and never shows up to class—but makes you remember a lot of basic truths. Being less poetic. Installing python-multipart to do anything interactive with forms seems like a codesmell, but I don’t know what it is ;) EDIT: my final comment was not a diss on htmx obviously. But the idea of using browser-consumable response data after the success of computer-readable encodings for web apps (I guess I just mean hashmaps/dicts/json/object)
- foul 3y ago
  >My projects all depend on an API for automation. So by buying into this doctrine, and rejecting even content negotiation, I am at least doubling my endpoints. If you can query that client-side, you don't need an hypermedia client, you need an RPC client.
- arethuza 3y ago
  I have seen people arguing that you shouldn't be using the same API endpoints for front-ends and for integration. I can see arguments both ways though... https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui
  - k__ 3y ago
    Didn't GraphQL solve this issue already anyway?
    - fl0ki 3y ago
      How? GraphQL is just another way to make query API with structured output, almost always JSON in practice. If you wanted server-side rendering, you still need another endpoint even if it happens to use GraphQL internally, just like you could made a rendered endpoint using another form of API internally.
throwaway167 3y ago
> content:class="bg-amber-300 border-solid border-4 border-black rounded-md m-auto mt-32 px-8 pt-8 pb-32 w-3/5" Is this inline CSS reimagined?
- mplewis 3y ago
  This is how Tailwind works. This sort of comment comes up every time Tailwind is mentioned. Here's a recent piece on the popularity of the framework: https://matt-rickard.com/why-tailwind-css-won https://matt-rickard.com/why-tailwind-css-won
  - lenkite 3y ago
    Considering that low-level atomic CSS lib like https://open-props.style https://open-props.style are now up-ticking in popularity, it is too early to say that Tailwind CSS "won".
- mvkel 3y ago
  If you use tailwind, you're rarely, if ever, coding CSS. you live in HTML world exclusively.
  - bonzini 3y ago
    It is the same as inline css though.
    - throwaway77384 3y ago
      Not from a CSP (content security policy) perspective. Which can sometimes make all the difference.
      - deleted 3y ago
        [deleted]
    - rvense 3y ago
      A) There are some important differences. For instances: sizes, spacings and colors are picked from a scale, not set in pixel values (although you can do that now if you need it.) B) There are many ways to "reinvent inline styles", this one is good, actually. I used to work with a fairly mature codebase. We enforced BEM-style names, but otherwise the CSS was extremely ad hoc (which, it is my impression, is quite normal). I ran some queries on our existing code, and found that most of our CSS classes were only used once, and most elements had only one style. They quite often had generic names, though, and when working with them you were always afraid to change a class because you didn't know if it'd been recruited elsewhere. And you certainly didn't delete anything. The growth in the size of the CSS was also quite extreme - it doubled over a year as far as I can remember. Probably because nobody ever deleted a class, even when they stopped using it, because then you would've had to check for sure that it was now unused and.. meh. I starting referring to all this as "might as well be inline"-styles, because really, all we did was move the inline information to a different file, which... has no benefits when you think about it[0]. A thoughtful application of atomic CSS would have been a massive ergonomic improvement IMO, and I've since used Tailwind on a big project and found it much, much easier to work with over time than the other system. [0] Yes, I know about the CSS Zen Garden. I don't think the principles apply to web applications - and, if anything, the approach to colors and font sizes in Tailwind makes theming much easier than in a messy codebase like what I used to work with.
ionrock 3y ago
I don't know if I fully grok the web components described by the author. I did find that using templ with Go makes it reasonable to have components you can inject some logic and state into for sending back HTML to htmx where it makes sense. The thing that makes sense is we focus on generating HTML once and there is no need to redefine models in the frontend. This is important because it means we don't take HTML, convert it to a data structure, validate the data, then send the data to a server, that has to validate things again, and return some resulting data, that once again gets rendered as HTML. Each data transition is expensive from a complexity perspective and requires caching state where caching is hard. I'll admit that I'm not a frontend guru so my bias for writing apps like I did 20 years ago likely shows here. Still, when I consider all the different abstractions and details around using something like Next.js + Typescript, and where the division between server and client becomes mixed, reducing complexity feels advantageous. Tailwind is another good example where the explicit nature of attaching styles makes sense if you are writing React components. You've encapsulated all that noise behind a simple JSX tag. Using Tailwind with something that returns HTML then requires a similar way to encapsulate the noise. Again, I found using Templ with Go made that feasible, but I still have avoided Tailwind just b/c I don't want to introduce the noise too soon if possible. It all makes me wonder if we lost the idea of a fullstack engineer, not because the problems became so challenging that we needed the extra complexity, but rather because we organized our applications into frontend and backend organizationally when we should have been more diligent in maintaining teams that could do everything. The real tl;dr is that Templ for Go is pretty handy for writing components :)

257 points by alexzeitler 3y ago

Kiro 3y ago

Is anyone using htmx in a large project? Seems like it could be great for small things, but unmaintainable at scale, and that all the praise is based on the former. Something tells me that the backlash will be enormous.

karmarepellent 3y ago
There is the occasional tech talk on YouTube where some kind of migration from React to HTMX in a large project is discussed. You will have to search though as I do not have any links at the ready. However I have not seen anything really substantial either that confirms that HTMX works in large projects just as well as in smaller ones. I plan to use HTMX in another larger, upcoming project though as I want to gain some insights on the side too. That being said I am aware that it might turn out to be a mess. But I would be content with the fact that HTMX is generally very useful for smaller projects and just put it in my respective imaginary toolbox to keep in mind for those kinds of projects.
- rob 3y ago
  Link, from 2022: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ Every time this is brought up (use in larger projects), people usually only mention this article/video and nothing else, so I'm not sure if that's a good or bad thing.
  - karmarepellent 3y ago
    Yes, that is exactly my point! I think the lack of real world examples of large HTMX projects is a little telling. But it might just be large projects usually happen in large companies where you aren't necessarily allowed to disclose project details to the community. Again, I think at this stage the best way to determine if HTMX is a viable option for large projects is to try and ideally share your insights. To be honest I am looking forward to the day when we can put all the HTMX/React whatever debates to rest and it will just be another great tool amongst other tools.
    - Woshiwuja 3y ago
      to be fair unless you are doing a complete rewrite it doenst make much sense to swap frontend. I bet we will see later this year htmx getting used because of people getting confortable with it
      - cqqxo4zV46cp 3y ago
        htmx’s growth trajectory isn’t as steep as you’re making out with that expectation. I remember seeing conference talks about it ages ago. It’s ostensibly getting more interest now sure, if not legitimate adoption, but it does feel like more of the early starters would have something to share by now. For the record, I hope that it succeeds.
        recursivedoubts 3y ago
        finished a close second behind react and ahead of svelte, vue, vue2, vue + vue2, angular, solidjs, quick: https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date https://star-history.com/#bigskysoftware/htmx&bigskysoftware... idk what a steep growth trajectory is to you, but this has felt pretty steep to me: https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date https://star-history.com/#bigskysoftware/htmx&bigskysoftware...
        Woshiwuja 3y ago
        also: https://star-history.com/#bigskysoftware/htmx&facebook/react&Date https://star-history.com/#bigskysoftware/htmx&facebook/react...
        recursivedoubts 3y ago
        sure, but click "align timelines" and then consider I'm a one man shop in montana, and facebook is, well, facebook: https://star-history.com/#bigskysoftware/htmx&facebook/react&Timeline https://star-history.com/#bigskysoftware/htmx&facebook/react... not saying htmx is gonna replace react any time soon, but c'mon, it finished #2 right behind react in rising stars, that's pretty good
  - boringuser2 3y ago
    >The effort took about 2 months (with a 21K LOC code base, mostly JavaScript) That isn't a very large codebase for frontend, I'd expect one person to be able to do that in less than one month if they're actually trying.
- zer00eyz 3y ago
  >> that confirms that HTMX works in large projects Define large? By size of project or volume of users. HTMX is more targeted for the latter, not the former. THere is a continuum. Static pages, SSG's on one side, and SPAs/react all the way at the opposite end. They both do VERY different things. HTMX is some where in the middle, think content heavy PAGES that need lightweight public facing interaction (email/contact, validation loops, a form or two, maybe some dynamic conversions, a carrousel) Static home page for cache performance, html for sales contact cycle, react for the app you sell ... all three can and should be coexisting!
sli 3y ago
In theory it seems like it should scale like a variation on a pretty standard full stack application that does the HTML work on the backend -- as opposed to a SPA -- but instead sends fragments instead of entire pages. I'm also be curious to see how it plays out in practice, since it's been pretty neat for my small projects and I'm intrigued by it, generally.
davedx 3y ago
I doubt it. I think it's like svelte, but a bit earlier in the hype cycle. The "State of JavaScript" survey is illuminating for these kinds of technologies. They often follow a trajectory towards "more liked", while remaining consistently and firmly in the "not used" quadrant. Everyone thinks they look amazing and refreshing, and maybe some people have even actually written some small apps in them, but (almost) nobody is using them at scale. It's not a bad thing really, but the hype can be annoying
- caseyf 3y ago
  Everyone using modern Rails/Hotwire (including 37 signals) is using basically the same architecture, does that count?
  - polycaster 3y ago
    I wouldn't categorize Hotwire as a well-established technology simply because it's included with Rails. Its prominence isn't solidified even with support from notable figures – as all tech trends have their advocates. In my perspective, it's somewhat analogous to htmx: The cool kids are using it for smaller, manageable use cases, but it's far apart, like magnitudes, from the adoption React has.
  - davedx 3y ago
    I've used Rails for small-medium sized projects and overall have a good impression of it (I'd even argue it did a lot to drive web development forwards) and I know there are still orgs out there using it regularly, but is Rails honestly still being used to build large scale apps (excepting the ones that have already been around forever like Github)? Every org I've worked at since the last Rails project I worked on around 2014 has built JavaScript heavy thick clients on top of API's. That's not really where Rails shines, and I've not seen it around at all for newer projects since roughly that time. It's anecdotal, but it's my experience that the industry has largely settled on the SPA + API's architecture, and the technologies every org I've worked at use to build those SPA's are either React, Angular, Vue, or very occasionally for niche cases their own JavaScript framework. I understand that some people on Hacker News still dislike the complexity of modern front ends, and I get it, I really do. But I haven't seen any real alternatives that have been seriously used in anger to build an actual commercial application since React, Angular (and Vue) took over.
HackerThemAll 3y ago
Majority of apps are small, yet they load tens of megabytes of javascript and it's becoming the unwanted norm. You can't browse many blogs without enabled javascript for no other reason than personal data harvesting needs.
- zdragnar 3y ago
  Those are very different issues. React, Angular, Ember and co don't help you with your data harvesting one bit.
  - spinningslate 3y ago
    Agree they're different, but it's important not to miss the first point: > Majority of apps are small I'd like to see some data on it, but intuitively that resonates. The lighthouses of UI frameworks - notably React & Angular - emerged from the needs of big apps, with 100s of people, and structures that delineate front-end and back-end teams. The organisations behind the frameworks - Google, Meta - are very influential in setting industry direction. So those frameworks become "the way to do UI". That doctrine spreads through the community, and the context of origin and use is occluded. If htmx or similar drives a re-think then that's healthy to me. My own experience is with lots of comparatively small apps. Plain old server-side rendering hits the 80/20 for most, and something like htmx might move that indicatively to ~90/10. Which is attractive because it means 1 tech stack and comparatively less requirement for hard delineation of skills in dev teams. It's not saying "throw away React/Angular/..., you never need them". There are clearly situations where they're a good fit. Where fit means both organisational and technical. But they're not a good fit in every case.
    - zdragnar 3y ago
      React actually wasn't built for SPAs; Facebook built it for widgets on a server-rendered page. That is why it has no built in SPA features, like routing, data management, data fetching or other batteries a SPA or PWA might want. Conveniently, it provided a very nice set of primitive and composable APIs so that all of those features can be added on in a way that fits naturally, such as react-router and the rest of the ecosystem. That's all driven by the community, not the "lighthouse", so to speak. AngularJS likewise didn't require using the router, and in fact can just as easily run multiple instances on a single page. I haven't used Angular in years, so I don't know the story there. Same goes for Vue, but that's hardly backed by a "lighthouse". I don't disagree that there's no use for HTMX or server rendering of html. Not everything needs to be a SPA. The problem is the argument is a whole lot less convincing when presented with a lot of incorrect facts
naasking 3y ago
> Seems like it could be great for small things, but unmaintainable at scale, and that all the praise is based on the former Why does it seem that way? There are plenty of talks on youtube of commercial projects that switched from React to htmx and found considerable benefits.
- beanjuiceII 3y ago
  where? I would love to see a big project in htmx, maybe our definition of big is different though.
  - naasking 3y ago
    For example: https://www.youtube.com/watch?v=3GObi93tjZI&pp=ygUJaHRteCB0YWxr https://www.youtube.com/watch?v=3GObi93tjZI&pp=ygUJaHRteCB0Y...
    - elvennn 3y ago
      21k LOC ...
      - beanjuiceII 3y ago
        yea 21k lines of code is like a tinymicro project :|
    - DrammBA 3y ago
      Do you have any other project besides 2022 example from the htmx website that everyone shares every time?
  - deleted 3y ago
    [deleted]
recursivedoubts 3y ago
https://htmx.org/essays/does-hypermedia-scale/ https://htmx.org/essays/does-hypermedia-scale/
jbergens 3y ago
I don't see any reason why it shouldn't scale. It also allows you to use any backend language. If you write messy code in php and think it is the language 's fault then you can use something else. Rust, Go, Java, C#, Elixir. Everything should work. Just don't write messy code.

ThePhysicist 3y ago

I don't get why people would use something like this, for most use cases this seems like a massive step back. I guess it's for applications where you want a little bit of interactivity but not build a complete single-page app. Which seems like a pretty small niche. The amount of boilerplate code and mental modeling needed for such a simple example seems absurd though. Personally I would just embed a small single-page app/snippet instead where I need more interactivity, stitching together server-rendered HTML like this seems quite bad. React for example is such a small and easy to use library, you don't even need a compiler toolchain to use it (makes code nicer to read of course), just drop the JS bundle in your HTML and write your component in a script tag, it will still be much easier to understand, use and modify than this.

mariusor 3y ago
Different developers have different skill sets. The mental model of different URLs giving you different distinct resources might make more sense for some. :P
deleted 3y ago
[deleted]

andrewstuart 3y ago

Am I right in my understanding that HTMx is kinda "adding data requests to document elements". I can see how that might be useful for simple things but for anything with any level of sophistication aren't you going to have to jump right into JavaScript? I just don't really get the big picture of HTMx. Is it making easy things easy and leaving hard things to React or Vue or whatever? Can someone please sell me on it - why should I be excited given that to get anything hard done I have to jump straight into JavaScript.

masfoobar 3y ago
I am writing a complicated website - the typical single page application and, so far, htmx is working wonders (and removing a lot of frontend work which I find duplicating data models already done on the server) One problem I did face is trying to put together a large json to a POST request. I did experiment if I could do this all in the 'htmx way' of using input=hidden but was not working. With this, it was best to store this as a JS variable, or call a JS function to return json, which was all specified in htmx (in html) Point is there are some exceptions that I have to do some javascript but the amount is much less when using other popular frameworks. Overall, I am doing most work using htmx and odd exceptions with simple javascript functions to returns text or json.. or javascript to compliment my css.
- smallerfish 3y ago
  What was in your json? I've taken forms pretty far with htmx. Getting to accept "the state lives in the html" takes a bit of mental wrangling, but I've found it to hold up well so far. (One nice htmx trick is the ability to include hidden inputs/forms/whatever from outside the current form if necessary.)
  - mst 3y ago
    from outside? (I swear I've read the htmx docs but either I missed this part or I've forgotten it since)
    - 3y ago

BlackFly 3y ago

> Framework updates often render components not usable anymore (anyone has changed, or tried to, major versions of Vue or React recently?) I migrated my personal site from pure Vue 2 to Vue 4 + Nuxt recently. The migration guide was a garden path, but when I started a new project and just moved my components over into the conventional nuxt locations, everything went quite smoothly. My use case is quite narrow. It's basically a blog but with some embedded applications (mostly simulations), heavy use of a particular custom component. I like the hot swapping from the vue framework and I appreciate the static compilation of the result from Nuxt. I thought about doing something like HTMX + web components, but I would still need to figure out how to bundle what javascript into each page. Plus, web components have absolutely no server side rendering without another layer of complexity. Setting all that up seemed to me to be effort better spent on the occasional migration. Plus, when the going gets rough, Vue always had my back. My next step will be embedding wasm though... so that might change things, I'll see.

jddj 3y ago
> Vue 4 Is this a thing?
- rk06 3y ago
  Nope, Vue is still in v3
  - worthless-trash 3y ago
    Time travellers go home.
  - BlackFly 3y ago
    What did I upgrade to 4 then? Vue router? I guess I got confused.

codie3611 3y ago

HTMX looks pretty much like something I would use for fast prototyping with very limited complexity/the scope is known ahead to stay simple. I've been working in full-stack for a decade together with extremely skilled engineers on large monorepos. Our wisdom is to stay as vanilla as reasonable and understand what your technology does underneath. As soon as there are layers over layers (tools calling tools with domain specific languages) you wish you could simply change X directly instead of having to go through e.g. create-react-app or htmx. But if any framework can provide me that level of comfort then I'm fine with it although I learned the more comfort frameworks provide the darker the other side.

Woshiwuja 3y ago
i disagree. making the backend format a div and send it back is much faster than creating a json, sending it to client and having the client hydrate stuff inside the page
- replwoacause 3y ago
  I have found this to be true in my experience too, but I’m not a professional dev, rather a hobbyist, so HTMX suits me just fine. That isn’t to say it doesn’t have a place in the toolchain of professional devs though!
  - Woshiwuja 3y ago
    both things can be true at the same time! For an hobbyist you get to write less js. For a company you get faster apps. Its a win win situation
infecto 3y ago
I see these kind of comments pop up and as a long time backend/full-stack dev I don't follow the logic all too well. HTMX is just another tool to be deployed. If your app requires a SPA experience or large amounts of javascript for the UI, its not the right tool for the job. Where I have had great experience with it is for applications that have discrete javascript implementations or none. Lot's of applications that are quite valuable to the end user, are really just a bunch of CRUD like operations and don't really need a full blown FE framework.

wscourge 3y ago

The monospace font in the article is unpleasant to read

cebert 3y ago
HN guidelines suggest to not comment on the site itself, but I agree that the font immediately made me less excited to read this article even though I am interested about the topic.

randomdev3 3y ago

Good thing about htmx style solutions is that it's easy to implement the features you need without extra bs. Often it's so much simpler and cleaner to code something than using a generalized library or framework. You can still use react , vue, solid or whatever for the dynamic parts that make sense to do clientside

BurningPenguin 3y ago

I think it's also possible in Stimulus, if i'm not mistaken. Because i kinda prefer that one.

reportgunner 3y ago

Nice try but I'm not adding more javascript

andix 3y ago

Web Components can't be (pre-) rendered server side, right? I wouldn't chose a technology that comes with this limitation.

DrScientist 3y ago
Wrong. ( https://www.google.com/search?q=SSR+of+webcomponents https://www.google.com/search?q=SSR+of+webcomponents ) Though I'd admit it doesn't have the beautiful simplicity as concating some strings.
demurgos 3y ago
There's the declarative shadow DOM proposal for this but I don't think it's ready yet.
_heimdall 3y ago
That really depends on how you want to use web components. I have used custom elements quite a few times with Astro, mostly leveraging custom elements for life cycle events. I end up with a `.astro` file that server renders the HTML and adds a script to define the custom element. In the browser its more pike cheap hydration - the custom element doesn't re-render anything up front, it will just grab references to the server rendered DOM nodes and setup event handlers. I know Lit has an SSR helper, though I haven't used it myself I think its supposed to make server rendering you lit web components much easier.

brianzelip 3y ago

Here's HTMX author very recently talking about Web Components and HTMX on JS Party, https://changelog.com/jsparty/307#t=5260 https://changelog.com/jsparty/307#t=5260

deleted 3y ago

[deleted]

mediumsmart 3y ago

html and css say hello/wave goodbye

mortallywounded 3y ago

What are the impacts HTMX has on SEO/crawlability? I can't imagine doing XHR requests that return partial HTML snippets to be "good" for a crawler that expects one page to link to another (assuming they are running JS to begin with).

aljarry 3y ago

Is Htmx a good case for UI for a local application? I want to build a server app which I could host openly behind some auth, but at the same time I'd want to be able to run it in local mode, as a simple UI for local tests. I understand there are some security challenges, as in "local" mode it can only communicate over HTTP with local app, or probably without CORS, etc. XSS might be a real issue here.

mortallywounded 3y ago
Strange question... if something works over the public internet why would it not work locally? There's no magic sauce with HTMX. It's just a JavaScript library that does what a million others do. You can run it on a local toaster if you felt like it.

listless 3y ago

Web components are great! HTMX is great! But there is no answer for WHAT ABOUT THE JAVASCRIPT. You can't build a web app without it, so...what about bundling? What about binding? What about state? Yes, I understand that I'm doing it wrong and I need to do this on the server or something, but these are not specific enough answers which would make me abandon React or Vue which have great answers to all of these questions.

recursivedoubts 3y ago
https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/

xialvjun 3y ago

php + htmx should work good. But it's still website, not webapp. Complex front end operations are hard to implemente in htmx. api server + react/vue/angular work good. They are just js(templates compiled to js). They are for building webapps. Anyway, html is not turing complete.

shaunxcode 3y ago

I like both technologies as well! It feels like the sort of phase shift that happened when jquery got long in the tooth.

megaman821 3y ago

The real power of HTMX and Web Components is that Web Components self-initialize when they get attached to the DOM, so they are easy to AJAX in. This was always a PITA in the jQuery world since you would have to hunt down the new interactive elements and run a library's init function on them.

boringuser2 3y ago
I haven't seen the term "AJAX" used in years. Very bad sign both for the project and people mentioning it.
- worthless-trash 3y ago
  Using a term is not a bad sign.
  - boringuser2 3y ago
    It means your knowledge is likely quite dated.
    - linkdd 3y ago
      AJAX literally is "async request from the client to the server". https://en.wikipedia.org/wiki/Ajax_(programming)#Technologies https://en.wikipedia.org/wiki/Ajax_(programming)#Technologie... XML (the X in AJAX) is not even necessary as JSON came in. Any React/Vue/Angular/... client application using `fetch` to make a request, is making an AJAX request. Just because you haven't seen the term in a long time does not mean it is outdated.
hellcow 3y ago
This is the exact use-case I found for them, and it’s terrific. I define any tag, e.g. <my-modal>, put normal HTML within it as if it were just a div, and then I can define the callbacks (like adding/cleaning up listeners) and custom attributes in a tiny bit of JS.
3y ago

rgbjoy 3y ago

So am I the only person seeing htmx and tailwind together and feeling absolutely disgusted? Like a wall of run on sentences and no paragraphs. I can’t believe tailwind is a thing…

_lvbh 3y ago
I used to love tailwind. Used it a ton. Not so much anymore. Plain CSS is enough for me.
wg0 3y ago
I have opposed Tailwind to no end. But I gave it a try and the portability it brings to markup is beyond description. You just move HTML from anywhere and it would just look exactly the same (subject to your overrides/customisations of course) so I don't think Tailwind is going away anywhere. Rather, it now can be thought of as a mini language or notation built on top of CSS.
tuzemec 3y ago
I personally don't like Tailwind. But I do see a lot of benefits of using utility classes for basic layout stuff. So far UnoCSS works very well for me. It's like light-weight and customizable Tailwind. Also for more complicated "components" I use css modules and refer to my theme values via directives (I think this is doable in Tailwind too?).
naasking 3y ago
The pain or disgust is a strong hint that you're thinking about it wrong. If you have a bunch of repetitive CSS, how do you typically eliminate that? You create a class that bundles it all together and then just use the class name on the HTML. But notice how you're then left with a bunch of repetitive HTML on which you apply those classes. If you bundle up the repetitive HTML into a reusable abstraction (like a component), then you're no longer repeating the CSS and so you don't need to bundle the CSS into classes anymore, thus reducing work. A type of inline styles, without the limitations, then gives you more direct control over styling on the bundled HTML itself. That's how you should use Atomic CSS/Tailwind.
sergiotapia 3y ago

deleted 3y ago

[deleted]

b33j0r 3y ago

I am using htmx. I still have a nagging feeling that this has mostly dragged the overton window back towards hypermedia (big fan of the book, recommended). It still feels wrong. I don’t know if I mean wrong as in “incorrect” or wrong as in “cheating/too easy.” It gracefully makes sites work like it’s 2025 or 1999, but I have to design my markup like it’s 1999. I can never decide if this is good or bad. My projects all depend on an API for automation. So by buying into this doctrine, and rejecting even content negotiation, I am at least doubling my endpoints. It’s like being 12 years old, and falling in love with a “bad girl” who doesn’t go to church—and never shows up to class—but makes you remember a lot of basic truths. Being less poetic. Installing python-multipart to do anything interactive with forms seems like a codesmell, but I don’t know what it is ;) EDIT: my final comment was not a diss on htmx obviously. But the idea of using browser-consumable response data after the success of computer-readable encodings for web apps (I guess I just mean hashmaps/dicts/json/object)

foul 3y ago
>My projects all depend on an API for automation. So by buying into this doctrine, and rejecting even content negotiation, I am at least doubling my endpoints. If you can query that client-side, you don't need an hypermedia client, you need an RPC client.
arethuza 3y ago
I have seen people arguing that you shouldn't be using the same API endpoints for front-ends and for integration. I can see arguments both ways though... https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui
- k__ 3y ago
  Didn't GraphQL solve this issue already anyway?
  - fl0ki 3y ago
    How? GraphQL is just another way to make query API with structured output, almost always JSON in practice. If you wanted server-side rendering, you still need another endpoint even if it happens to use GraphQL internally, just like you could made a rendered endpoint using another form of API internally.

throwaway167 3y ago

> content:class="bg-amber-300 border-solid border-4 border-black rounded-md m-auto mt-32 px-8 pt-8 pb-32 w-3/5" Is this inline CSS reimagined?

mplewis 3y ago
This is how Tailwind works. This sort of comment comes up every time Tailwind is mentioned. Here's a recent piece on the popularity of the framework: https://matt-rickard.com/why-tailwind-css-won https://matt-rickard.com/why-tailwind-css-won
- lenkite 3y ago
  Considering that low-level atomic CSS lib like https://open-props.style https://open-props.style are now up-ticking in popularity, it is too early to say that Tailwind CSS "won".
mvkel 3y ago
If you use tailwind, you're rarely, if ever, coding CSS. you live in HTML world exclusively.
- bonzini 3y ago
  It is the same as inline css though.
  - throwaway77384 3y ago
    Not from a CSP (content security policy) perspective. Which can sometimes make all the difference.
    - deleted 3y ago
      [deleted]
  - rvense 3y ago
    A) There are some important differences. For instances: sizes, spacings and colors are picked from a scale, not set in pixel values (although you can do that now if you need it.) B) There are many ways to "reinvent inline styles", this one is good, actually. I used to work with a fairly mature codebase. We enforced BEM-style names, but otherwise the CSS was extremely ad hoc (which, it is my impression, is quite normal). I ran some queries on our existing code, and found that most of our CSS classes were only used once, and most elements had only one style. They quite often had generic names, though, and when working with them you were always afraid to change a class because you didn't know if it'd been recruited elsewhere. And you certainly didn't delete anything. The growth in the size of the CSS was also quite extreme - it doubled over a year as far as I can remember. Probably because nobody ever deleted a class, even when they stopped using it, because then you would've had to check for sure that it was now unused and.. meh. I starting referring to all this as "might as well be inline"-styles, because really, all we did was move the inline information to a different file, which... has no benefits when you think about it[0]. A thoughtful application of atomic CSS would have been a massive ergonomic improvement IMO, and I've since used Tailwind on a big project and found it much, much easier to work with over time than the other system. [0] Yes, I know about the CSS Zen Garden. I don't think the principles apply to web applications - and, if anything, the approach to colors and font sizes in Tailwind makes theming much easier than in a messy codebase like what I used to work with.

ionrock 3y ago

I don't know if I fully grok the web components described by the author. I did find that using templ with Go makes it reasonable to have components you can inject some logic and state into for sending back HTML to htmx where it makes sense. The thing that makes sense is we focus on generating HTML once and there is no need to redefine models in the frontend. This is important because it means we don't take HTML, convert it to a data structure, validate the data, then send the data to a server, that has to validate things again, and return some resulting data, that once again gets rendered as HTML. Each data transition is expensive from a complexity perspective and requires caching state where caching is hard. I'll admit that I'm not a frontend guru so my bias for writing apps like I did 20 years ago likely shows here. Still, when I consider all the different abstractions and details around using something like Next.js + Typescript, and where the division between server and client becomes mixed, reducing complexity feels advantageous. Tailwind is another good example where the explicit nature of attaching styles makes sense if you are writing React components. You've encapsulated all that noise behind a simple JSX tag. Using Tailwind with something that returns HTML then requires a similar way to encapsulate the noise. Again, I found using Templ with Go made that feasible, but I still have avoided Tailwind just b/c I don't want to introduce the noise too soon if possible. It all makes me wonder if we lost the idea of a fullstack engineer, not because the problems became so challenging that we needed the extra complexity, but rather because we organized our applications into frontend and backend organizationally when we should have been more diligent in maintaining teams that could do everything. The real tl;dr is that Templ for Go is pretty handy for writing components :)