18 ms·

Moving from React to htmx

575 points by mpweiher 4y ago

recursivedoubts 4y ago
TLDR: - Took 2 months (21K LoC, mostly JavaScript) - No reduction in user experience - Reduced LoC by 67% (21,500 LoC to 7200 LoC) - They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS - Reduced JS dependencies by 96% (255 to 9) - Reduced web build time by 88% (40s to 5) - First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds) - Much larger data sets were possible than react could handle - Memory usage was reduced by 46% (75MB to 45MB) These are spectacular numbers that reflect that the application in question is highly amenable to the hypermedia approach. I wouldn't expect everyone to see this level of improvement, but at least some web apps would.
- deleted 4y ago
  [deleted]
- keizo 4y ago
  Speed is the big one for me. 2-6+ seconds is insanity for anything.
  - recursivedoubts 4y ago
    Speed is definitely a big one. I also am glad to see that everyone on the dev team became full stack developers, because I think the back-end/front-end split is often detrimental to development velocity. It's often better when a developer can fully realize an entire feature, with no front-end/back-end friction.
    - keizo 4y ago
      Oh for sure. For me programming is a hobby, so I can only get something made if I do it all.
  - funstuff007 4y ago
    I hear you, but YouTube takes 6+ seconds for me to load and it does not seem to hold them back. For most, not all, optimizing page load time is time probably best spent elsewhere. This is is no way to impugn htmx, because with htmx you seem to kill many birds with one stone.
    - stjohnswarts 4y ago
      Youtube is kind of unique in that nothing (currently) even comes close to replacing it for the average youtube user.
    - josephscott 4y ago
      Details matter, as they learned when making things faster made their metrics slower - https://blog.chriszacharias.com/page-weight-matters https://blog.chriszacharias.com/page-weight-matters
  - jiggawatts 4y ago
    I would argue that 1-2 seconds is not impressive either. It's like seeing people breaking rocks with hand tools being impressed with a bigger mallet. I used to aim for 15 millisecond cold load times, which is apparently unheard of these days even for front pages with entirely static content.
    - keizo 4y ago
      Well yea, but start trimming with the biggest wins first.
    - earthboundkid 4y ago
      15ms to who? I’ve never had that kind of latency on a cold connection. My pages have an LCP of around 600ms, and it’s hard to push it much lower because even static pages on a CDN end up taking 400ms to connect and download.
      - jiggawatts 4y ago
        15 ms to anyone in the same city or on the same local network in an office setting. 50 ms to anyone in the same country, ideally lower. Global reach is a different problem because of physics. However, front pages of web pages tend to be largely static and can be staged in various geo-distributed regions. In other words, distributed via a CDN.. > even static pages on a CDN end up taking 400ms to connect and download. Only if you stuff them full of megabytes of Javascript and pull down megabytes of JSON in order to display that static content. The fact that my comment -- a factual statement about real-world performance I've achieved regularly -- is voted down and your off-by-an-order-of-magnitude reply is voted up speaks volumes about the state of the industry. It's like a bunch of fat people being flabbergasted about the mere concept of mountain climbing. With what... your legs!? Up there!? Madness!
        earthboundkid 4y ago
        My site is a static page hosted on a CDN with less than 80KB of JavaScript. If you’re testing local network times, you’re just fooling yourself. None of your visitors are seeing that time, so it’s irrelevant. What’s your URL? I’d love to throw it into webpagetest.org and take a look.
- MatthiasPortzel 4y ago
  > Much larger data sets were possible than react could handle I find this one difficult to believe. I'm not calling BS necessarily, but I doubt it applies in the general case. I have a Django app that's server-side rendered, the largest page is very large (~200kb of content). Django on a low-tier VPS took about 500ms just to render that page. Django templates aren't faster than React. And Python isn't faster than JS. If they're seeing performance increases I'd guess it's either that they're being more judicious about their queries (pulling only what they need from the database instead of filtering client-side), or the React app had a lot of complexity and they simplified the UI when re-writing.
  - andrewingram 4y ago
    I’d be a little surprised if rendering that same Django page as a server-rendered React app wasn’t even slower. Historically, server-rendered React has been painfully slow compared to Django (I’ve been doing SSR with React since 2014, using Django since 2006, experienced the pain first hand multiple times). Usually at least an order of magnitude slower. That said, I haven’t benchmarked in a while, perhaps the worst of it has since been addressed.
- tannhaeuser 4y ago
  I think the value of markup-based templating approaches such as HTMX and SGML comes from enabling content authors to create dynamic document-oriented sites without having to deal with dangerous tools such as JS and the endless ways too shoot yourself and your visitors into the foot (through eg injections and other security issues). The difference between HTMX and SGML being that HTMX integrates templating as markup vocabulary extension while SGML brings syntactical templating at the markup declaration level. A developer, OTOH, might choose JS-heavy approaches to avoid limitations and learn new syntax/concepts, and to re-use existing knowledge from/to other projects. I don't know that speed of development is of primary concern.
pen2l 4y ago
One reason I prefer doing React is that retrofitting existing React stuff for React Native is better/easier than embarking on React Native from scratch.
- samwillis 4y ago
  I would argue that most “apps” built with React Native don’t need to be apps at all, they are better as websites. The majority of these apps are about placing the existing product into the App Store for discoverability, and encouraging users to be “locked” into the app at the expense of a worse customer experience. A web app, in a browser, automatically has support for opening multiple pages as multiple tabs, bookmarks, sharing pages. You can’t do that with 99.9% of apps. I will also argue strongly that, again, react native is unnecessary even if you do want to package a native app. WebView based apps perform as well as a react native app, and most of the time with significantly less additional code. It also forces you to up your “mobile website” UX. In general the minuet you build a mobile “app” the mobile web experience gets neglected.
  - duxup 4y ago
    How would we even know what most React Native apps are like to… know this?
samwillis 4y ago
Love htmx and this talk is a brilliant run down of where it works well. But as always it’s about choosing the right tool for the job. Server rendered pages/fragments solve so many issues around security and time to develop a product, however it only gets you so far. Ultimately I think the decision when choosing a stack comes down to how much state you need to managed in browser. The vast majority of sites needs very little client side state management, htmx and other tools such as Alpine.js are perfect for this. But eventually as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework. Now that doesn’t always mean going all in on a full SPA covering the whole of your product. It could just be a small fragment that requires that level of interaction. Point is, don’t pick a tool because it’s “in vogue”, pick one because it lets you build the best possible product as efficiently as possible. For 80% of websites that could be htmx, and for the next 15% htmx probably works for 90% of their pages. It’s the 5% where htmx is not one of the right choices at all.
- ChrisDevx 4y ago
  I have 2 problems with htmx (IMHO): 1. SoC: the server API needs to return only the data and meta data requested, and it should not be concerned with the display-layer (html), because many different clients i.e. mobile app, browser, Electron etc. might want to consume this API. 2. Logistics & scaling: Imagine a large application with 100s of html/htmx components and views, now you alter your database, you introduce new business rules etc... If you used React or Alpinejs etc. you could just go to the relevant stores or app code and make the change as opposed to sifting and refactoring tons of html. Personally I'd rather just use Alpinejs from the start, knowing its lightweight, fast and easy to implement, and not end up painting myself into a corner over the application lifecycle.
  - recursivedoubts 4y ago
    1. https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ 2. many large applications use htmx (or related approaches like hotwire, unpoly, etc.) and scale fine. hypermedia is better at handling databaase/logic/API changes than fixed-format data APIs because your API is encoded within hypermedia responses: https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/
quickthrower2 4y ago
It is a cliche but probably true: Second rewrite will be better by those sort of metrics even without a tech change. Lessons learned get applied. Domain is fully known. I definitely believe in fewer LOC with any not-react due to all the hooks, memo, etc. boilerplate though!
- recursivedoubts 4y ago
  This wasn't a complete rewrite, it was a feature-for-feature rewrite of the front-end, moving from react to htmx, mainly as a proof of concept at first. Note that the amount of python actually increased, as logic was moved back to the server. While I'm sure there were a few places where better decisions were made, I think it's reasonable to assume that the majority of the reduction in code is due to the different approach to front end development.
gardenhedge 4y ago
I consider this an alternative development approach neither better or worse than what it is trying to replace. The winner in recent approach, imo, is Remix Run.
- recursivedoubts 4y ago
  Reducing a code base by 2/3rds isn't better than what it replaced? At least in some sense?
- jaredcwhite 4y ago
  For literally every developer on the planet who is not an expert JavaScript developer—or who doesn't wish to be—this is undoubtedly a better development approach. Saying "Remix is the winner" doesn't really move the needle. It's still JavaScript, still React—just with some work pushed to the server instead of the client. The contract of the web is that while the client-side language in use may not be up to the discretion of the developer (recent evolutions in WASM notwithstanding), the server-side language/framework/OS/etc. can be literally anything which speaks the protocol of HTTP/HTML/etc. JS frameworks for years have repeatedly broken that contract with the claim that we must accept it for…well, "reasons". If it turns out most of those reasons are bupkis—more a matter of preferences than requirements—then we must stop breaking the contract. JS as a server-side language should _get in line_ alongside all the other languages out there. Why privilege it if we don't need to?
  - andyfleming 4y ago
    > It's still JavaScript, still React—just with some work pushed to the server instead of the client. This is being too reductive of the design of Remix. It is closer to traditional web applications in handling form submissions. There's no client-side state management needed for those use cases. Whether it's the "winner" or not, really depends on use case, but it is decently different than a traditional SPA.
- flexterra 4y ago
  IMHO this approach is better for most apps. Remix is bending the curve here. They make it extremely easy to progressively enhance a small part of your UI with all the power of React. That said, using React on the server side and forcing you to run JS on the server is not my cup of tea...
endisneigh 4y ago
serve side rendering is ideal, but at the end of the day what matters these days is developer productivity. a better question is how long it takes to make something like gmail with htmx vs. say react. you might say most apps are not gmail, and you'd be correct. so then you say, ok what about something like wikipedia? easy enough. then you start adding all of this javascript and it becomes a mess.
- infamia 4y ago
  Interesting you mention Gmail, that's one of the examples given in the Layers Tutorial for Unpoly, which is a batteries-included take on the basic ideas behind HTMX. https://unpoly.com/tutorial https://unpoly.com/tutorial
- pier25 4y ago
  Use the right tool for the job. Obviously Gmail is a much better fit for React/Vue/etc than HTMX. Gmail is the perfect use case for an SPA but most web apps don't need to be an SPA.
  - adamckay 4y ago
    > Gmail is the perfect use case for an SPA Is it really, though? It's a paginated list of emails, some drag-and-drop functionality, buttons for some ajax functionality. It works reasonably well, but it doesn't need to be so high Javascript compared to Google Docs or maps.
    - hunterb123 4y ago
      Viewing your emails offline is pretty important.
      - pier25 4y ago
        And being able to use Gmail (search emails etc) while writing an email too
dhucerbin 4y ago
Listing template dependencies as event names that can change underlying data seems very brittle (hx-trigger for favorite articles). You would need at least integration tests to get some confidence! Can’t we infer used state in template and setup triggers for developer? LiveView gives better DX in this case.
sergiomattei 4y ago
A note I’ve internalized lately: there is a middle ground. You can write excellent, lightweight React apps by simply writing semantic HTML and taking advantage of the platform (declarative form validations, a simple CSS pipeline, etc). It doesn’t have to be madness in the front-end. NextJS, in particular, keeps the build pipeline quite simple.
- chrisweekly 4y ago
  In the React ecosystem, Remix.run embraces a much simpler approach than Next.js.
deleted 4y ago
[deleted]
ksbrooksjr 4y ago
Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a build step to use it [3]. [1] https://unpkg.com/browse/htmx.org@1.8.2/dist/ https://unpkg.com/browse/htmx.org@1.8.2/dist/ [2] https://unpkg.com/browse/preact@10.11.2/dist/ https://unpkg.com/browse/preact@10.11.2/dist/ [3] https://preactjs.com/guide/v10/getting-started#no-build-tools-route https://preactjs.com/guide/v10/getting-started#no-build-tool...
- flexterra 4y ago
  The programming model is totally different when working with HTMX. The server returns HTML instead of a JSON API which is the usual solution when building apps with React/Preact and similar.
  - ksbrooksjr 4y ago
    Yea htmx definitely has a different programming model than an SPA style framework like React/Preact. I actually like the JSON api programming model where the backend is as simple as possible, and the frontend js/ts code is completely responsible for handling the UI, but I guess it's a matter of personal preference. The linked article is referring to a team switching from React to htmx though, so for them I'd imagine it would've been a much easier transition if they'd just added a Webpack alias[1] that replaced React with preact/compat, rather than switching to a completely different UI paradigm. [1] https://preactjs.com/guide/v10/getting-started#aliasing-in-webpack https://preactjs.com/guide/v10/getting-started#aliasing-in-w...
    - flexterra 4y ago
      The difference in programming model IS THE advantage of HTMX. Changing from react to preact is a perf optimization. If you are doing the SPA thing correctly you must duplicate business logic (data validation). Also when your API just sends "dumb data" (JSON) to the client, you are forced to make changes to the backend and frontend in lockstep.
xwowsersx 4y ago
Link to the talk mentioned if you were looking for it as I was: https://youtu.be/3GObi93tjZI https://youtu.be/3GObi93tjZI
nikodunk 4y ago
This is a really beautiful approach IF you don't need mobile. If you do need mobile, then you may be better served (pointlessly) running React on web and re-using all of the logic/fetchers, etc for React-Native on mobile IMO. Your other option would be to do something like 37 Signals and render web with htmx (or in their case Hotwire) and server-render mobile too, but wrap the web views with a thin native mobile navigation layer to make it feel more native. Very jealous if your project is web-only - this can work wonderfully and be incredibly efficient! I've been thinking about this a lot recently and also just blogged about it (https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-efficiency/ https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-e...).
- paulryanrogers 4y ago
  Efficient for dev time, not so sure about mobile app size, RAM usage, or response time.
  - nikodunk 4y ago
    Definitely! Wasn't considering the other 3 in this discussion. The most efficient for all of these is most likely a native app everywhere, and all the complexity/duplication that brings.
- recursivedoubts 4y ago
  If the hypermedia approach really grabs you, you could pair an htmx-based web application with a HyperView-based mobile application: https://hyperview.org/ https://hyperview.org/
  - haolez 4y ago
    I can't decide if this is awesome or terrifying. Will try it out :)
    - recursivedoubts 4y ago
      :) why not both?
agrippanux 4y ago
I don’t understand why this effort was undertaken vs migrating to NextJS and accomplishing the same thing in half the time without needing to ramp up more Python.
- legutierr 4y ago
  I don't think the point here was to show how quickly they could migrate to another framework, but rather to show that HTMX is powerful enough to use for things like this. The point seems to have been to show how you don't need to use React to build applications like this, so migrating to NextJS wouldn't have made any sense from that perspective.
  - kajaktum 4y ago
    That would make sense if this was a hobby project but it’s not.
- yawaramin 4y ago
  Because migrating to NextJS would have meant doing a rewrite of the entire backend which was already written in Python/Django and running in production. Migrating to htmx was much less risky.
  - danieljacksonno 4y ago
    NextJS can use an external API? It doesn't need to be fully full-stack.
    - yawaramin 4y ago
      So then add Next.js when we're already using another backend service. The idea is to reduce complexity, not the other way round.
- halfcat 4y ago
  Perhaps they are better equipped to write more Python, less JavaScript.
cloudking 4y ago
What is the best framework to build a high performance web application on? Specifically for building a UI to work with large sets of tabular data similar to a spreadsheet, e.g thousands of rows. Is Htmx up for this task?
- recursivedoubts 4y ago
  A spreadsheet is probably not amenable to the hypermedia approach because of the complicated inter-dependencies between arbitrary parts of the screen. You don't want to gate those updates on a hypermedia exchange. I would look at writing either a custom solution or one of the big reactive libraries like vue.js for something like this.
- tonto 4y ago
  this repo keeps track of various benchmarks on a data grid type app https://github.com/krausest/js-framework-benchmark https://github.com/krausest/js-framework-benchmark eventually you may need to create "virtualized scrolling" (e.g. only rendering a subset of the total table to the screen at a time) which can hard to make seemless. possibly the benchmark is "too much info" to make a good choice, but it is an interesting resource.
- firecall 4y ago
  Totally unfashionable answer: I use 'Rails 6.x and datatables.net. The system manages call-logs for a call centre with WFH staff. It's doing thousands of calls a day. The tables are 'endless' pagination reporting tables. It's hosted in Sydney, AU. And used by staff around the world. It has the advantage of being extremely robust on the dodgiest of old PCs with poor internet connections. So not fashionable, but it's super reliable and has a well documented implementation path!
  - germandiago 4y ago
    Your solution looks like the right way to do it to me. At least in your case.
- pier25 4y ago
steve76 4y ago
jokethrowaway 4y ago
That's great, I still remember how productive teams were in the jQuery times. Angular and react slowed down development massively. Nowadays teams are often busy fixing random stuff for days
miiiiiike 4y ago
The hoops people will jump through to avoid learning HTML/CSS/JS. I say this as a Python/Django dev who resisted learning web tech for 20 years: It's time to just learn this stuff. You can slap on a mound of band-aids and watch the wound bleed forever. Or, you can go in, get three stitches, suffer a little pain, and let the healing process begin.
- deleted 4y ago
  [deleted]
- recursivedoubts 4y ago
  I think this take does yourself a disservice: htmx is an extension of HTML and, in general, of the hypermedia model, and it is this model that should be contrasted with JSON data APIs. I think that you should learn JavaScript, and I certainly think you should learn HTML(!!!) and CSS. But I also think you should consider how much more can be achieved in a pure hypermedia model with the (relatively small) extensions to HTML that htmx gives you. I have a collection of essays on this topic here: https://htmx.org/essays/ https://htmx.org/essays/ Including an essay on how I feel scripting should be done in Hypermedia Driven Application: https://htmx.org/essays/hypermedia-driven-applications/ https://htmx.org/essays/hypermedia-driven-applications/ There is more to all this than simply avoiding JavaScript.
  - miiiiiike 4y ago
    I’ve used htmx.
    - recursivedoubts 4y ago
      I'm sure you have. Regardless of that, the idea that you learn htmx because don't want you to learn JavaScript is simply incorrect. Rather, it's how you use JavaScript that should be considered.
      - miiiiiike 4y ago
        JSON APIs are usable beyond the browser and using htmx feels like using Django+jQuery 14 years ago. I'd rather not go back to that.
parhamn 4y ago
There are four main problems in the React SPA world: - State management - hooks are awful for anything complex - Packaging + Bundling - Webpack kitchen sink, JS/TS, browser vs node vs random runtimes, packaging vs bundling, etc - Data/API binding - Adds distributed state to your data and the complexity that goes with that (cross dom reuse, caching, staleness, realtime updates, etc) - SEO/Prehydrating - Mostly applies to landing/CRM/blog type things. These 'old school' solutions help you avoid some of these issues in favor of relocating the complexity a bit (those templates in the talk are absolutely gnarly and I'm sure very bug prone) and reducing the experience. Also the API boundaries are blurred should you ever need one for non UI usage. Ignoring HackerNews taste for simpler websites, some complexity of UIs can and should only be captured with client sided javascript. With that said, after a few years of things shifting around I'm really happy with the Typescript (lang) + Parcel (packaging) + MobX (state management) + Vercel (when server side rendering is needed). They've been really stable, no fuss, always work. Especially MobX for state, absolutely game changing for the dev experience. As for the data binding problem, still sucks and my 4th attempt at solving it internally is still meh. This feels like it comes with the territory. As much as I loved my working with Django/Jinja2/etc, I think theres a light at the end of this tunnel.
- Humphrey 4y ago
  I've solved your data binding problem with: GraphQL (server) + UrQL (JS graph client with the graphcache plugin) + GraphQL Code Generator (creates TS types for your API). The data syncs perfectly, keeps up-to-date. GraphQL subscriptions allow for real time updates. Oh, and React-Hook-Form for forms, which feeds quite nicely into my GraphQL mutations. It's a real neat solution. As for server side, I've started using Python-Strawberry (was using Graphene but it stopped receiving updates) with Django. It's super solid stack, with typings flowing all the way from server API through to my react components.
jdthedisciple 4y ago
Wouldn't it be nice to have an actual link to an example of the same site written in React and Htmx?
danielvaughn 4y ago
Some years ago, a bright guy created something called 7 GUIs. It’s a collection of seven problems that all UI systems must successfully implement, and it was intended to act as a guide for comparisons. Unfortunately I think the author has passed away, but it would be interesting to see it rekindled and used for baseline comparisons like these. https://eugenkiss.github.io/7guis/ https://eugenkiss.github.io/7guis/
- deleted 4y ago
  [deleted]
- edflsafoiewq 4y ago
  I don't think Htmx is a good fit for those. I wouldn't want a server roundtrip for any of them (except maybe part of CRUD).
  - DannyPage 4y ago
    Hyperscript[1] pairs well with HTMX (as it should, it’s by the same group) and would fill those gaps. [1] https://hyperscript.org/ https://hyperscript.org/
    - xutopia 4y ago
      What are the advantages of Hyperscript over plain old Javascript?
      - recursivedoubts 4y ago
        a few: - it is designed to be embedded directly in HTML - it can listen for any event (unlike on* attributes) - it has native support for CSS selectors: https://hyperscript.org/docs/#dom-literals https://hyperscript.org/docs/#dom-literals - it has async-transparency: https://hyperscript.org/docs/#async https://hyperscript.org/docs/#async - subjectively, it is easier to read than JavaScript, particularly for the short, light scripts it is designed for (toggling a class, etc.): `on click toggle .clicked on me` hyperscript is more of a glue language than something I would recommend building an entire application out of (although people are doing that!)
bigDinosaur 4y ago
I'm just so burnt out with new things. How do I combat such burnout? I really don't care about 'Htmx', I think barely any apps need much beyond what was available in ~2006 in terms of web tech. I just feel tired knowing that moving from React to Htmx is an option. Yet another option which will very possibly bring zero commercial value (although it might be a nicer dev experience I guess) to any project I ever work on. Am I wrong?
- __s 4y ago
  You can get by mostly ignoring the churn. I still haven't switched to hooks with React; I'll figure it out when I run into a codebase using them
- recursivedoubts 4y ago
  That's understandable, the front end world is extremely churny. If you don't want to deep dive on htmx-as-a-tool due to burn out, I completely understand. But, at some point, it might make sense to read up on the philosophy behind it (hypermedia as an archiecture) because that is an area where it is different than most front end frameworks today. I have a collection of essays here: https://htmx.org/essays https://htmx.org/essays
  - bigDinosaur 4y ago
    Thanks, I'll definitely take a look given your (and others') replies here.
- 29athrowaway 4y ago
  Unless you need to hire. Then 2006 tech is not viable. 2006 tech in frontend = COBOL level stuff
  - nabaraz 4y ago
    This is not a correct interpretation. I'd argue the basics - HTML, CSS and Javascript hasn't changed as much since 2006. jQuery came out in 2006 and we were manipulating DOM back then. Now, we have frameworks like React, where we are manipulating DOM. The only differences are new browser APIs and a much better code maintainability.
juddlyon 4y ago
htmx is deceptively powerful for how easy it is to use.
fareesh 4y ago
I am fortunate to have gone 10 years without having to use react in production ever. I've used rails+turbolinks and included Vue or Stimulus or even jQuery to get on page interactivity done. The current state of the react / jam world strikes me as an HR led solution where you can get humans who only know JS to be more productive without having to worry about servers, databases or infrastructure.
- have_faith 4y ago
  It’s not the most popular framework in the world for web apps because it pleases front end devs who are scared of the backend.
pier25 4y ago
I was expecting something that would blow me away... but honestly that UI is not super sophisticated. You could solve that with vanilla or jQuery. Obviously React (or any of the modern libs/frameworks) would be overkill for that. IMO this video reinforces the idea that for personally simple stuff I'd rather just use jQuery (or rather CashJS) or even vanilla.
- talideon 4y ago
  That's exactly why HTMX was a good fit for this: it covers exactly the kind of Interaction patterns you'd find yourself writing in vanilla JS where React is overkill, except without having to write all that JS. Though I don't know why you'd bother with jQuery these days unless you had to deal with ancient browsers: venerable as it is, it's obsoleted itself as just about everything it did is now covered by browser APIs.
  - pier25 4y ago
    > is now covered by browser APIs I've never understood that argument. You could always do what jQuery does with vanilla JS. How could it be otherwise? The point of jQuery is productivity. Even today, a jQuery-style API saves you from writing a lot of code.
    - padjo 4y ago
      The biggest boon of JQuery back in the day was that it abstracted over all the browser variances, which were far more numerous at the time. Also many APIs simply didn’t exist(e.g. querySelector). Now that browsers are much mor standards compliant and there are much better APIs it feels like the rationale for jQuery has shrunken to pretty much zero
    - talideon 4y ago
      No it doesn't. Just about everything jQuery does is now a browser API these days, so you no longer save time using jQuery vs vanilla JS. The only argument for continuing to use it is that you're used to it and not used to the modern APIs that have absorbed jQuery's functionality. It's just a slower way of doing the same thing.
Throwaway23459 4y ago
Speeding up the build could be done in other ways, were they using esbuild or something fast previously? Probably not. The memory usage saving is really not a big deal, load up your favourite news web page and look at the memory it chews up in comparison. As for the preference implied for python over js, that's fine, but the choice is not binary, typescript is my preference for a React project, for example. Reduction in LOC is slightly misleading, JSX creates a lot of lines. It would be interesting to see a proper write up on the data React couldn't handle.
- rwalle 4y ago
  Agreed. More details are necessary to understand the potential benefit of such rewrites. And to be honest 21K LOC is not a big project. I can imagine that as project grows even larger, there will be problems that htmx cannot or is difficult to handle, and I'll be curious about how that would work out.
sriram_malhar 4y ago
Loved the presentation, and prodded me to revisit the latest state of htmx and django.
Glyptodon 4y ago
Expected this to be more interesting than a maybe fancier version of turbolinks. Am I missing something?
- David-Guillot 4y ago
  Hi there ; I'm the author of the talk linked in the article. Technically you're not missing anything: htmx is nothing more than another turbolinks, maybe more flexible and easier to learn. What you might be missing is the non-technical implications of these new tools. The idea behind the talk (and behind htmx, and behind turbolinks, or unpoly) is to prove that the usual arguments for Javascript application frameworks are just not valid for 90% of use cases. And *that's* a complete game-changer, even an industry-changer. Because since 2016, every small-and-not-super-rich company that wants to create a rich UX on the web is told to hire at least 2 developers: one "front-end" (i.e. "JS"), and one "backend-end" (i.e. everything else, from API to hosting through domain stuff and user data). Or one superman with both back-end and React skills, which is, IMO, almost impossible. From what I've seen, what businesses need is, indeed, 2 devs: one "back-end" (i.e. workers, databases, user data, domain stuff, and even hosting), and one "front-end" (i.e. "the website", from DB queries to CSS). One person should be enough to address this second scope, even with complex UIs and rich UX. And as this is almost impossible with Javascript application frameworks (because they require a lot of work), it becomes possible again, like in 2008, with htmx/hotwired/unpoly (and without the spaghetti code we had in 2008). One more thing: of course the idea was *never* to do JS-bashing, only people who are too tied to Javascript and not caring about tech cost-effectiveness would see htmx as a thing for JS-haters. In my talk I actually show some Javascript code, because it's useful for handling client-side-only stuff like a custom dropdown, a modal, etc. The whole idea is to put Javascript back at its place: pure client-side advanced interactions.
- beebeepka 4y ago
  The htmx guys self promote here all the time. Their selling point is "no js" for slightly interactive demo apps. 10/10 times is just them openly bashing the rest of us for not using their tech.
  - 4y ago
camkego 4y ago
Deep inside the comments is a wise question. What happened to the user experience over high latency links? Across countries? Over high latency mobile links? Starlink latency anyone?? Not every situation has high latency, but it's worth asking what happens when moving from React to Htmx in those situations.
- richbell 4y ago
  Conversely, a poorly optimized SPA may not even load in a reasonable time span.
silver-arrow 4y ago
We have experienced similar results moving to htmx and a hypermedia approach for building dynamic web apps. It simplifies development greatly and has resulted in better productivity. Like the results cited here, we too are extremely pleased that the majority of our coding now falls into our preferred language - Clojure (using Hiccup). Very pleasant experience!
kgeist 4y ago
Doesn't server rendering increase load on the server? I like to off-load as much processing to the user's browser as possible. We have ~1 million users and I like to think that when we off-load a lot of processing to the browser, we basically have 1 million servers for free.
- newbieuser 4y ago
  It is quite nice to create on the browser, but as the number and variety of clients increase, the application may become slow for some. And the main problems start there.
- kaeshiwaza 4y ago
  Rendering html doesn't consume a lot more than rendering json, specially that with htmx you'll render small fragments... Anyway the bottleneck is most of the time on the database.
- talideon 4y ago
  Consider this: you're doing server side rendering whether it's JSON or HTML fragments you're sending across. They're just different serialisations of the same data. The problem that SPAs were meant to fix was that each update of the page meant a full rerender under the classic model rather than just rerendering those bits that had actually changed. You're still going to be able to take advantage of those client machines to do rendering, but the difference is that with HTMX, you skip serialising JSON, so your clients aren't stuck doing unnecessary rendering. The load on the server is barely different, but the client has less to do. Now, if you're doing an awful lot of data manipulation on the client, that's a different story.
- David-Guillot 4y ago
  Hi! Sorry for the delay. I'm the one who gave this talk. Yes, rendering HTML on server-side increases server load, for the simple reason that the server-side templates contain some display logic. But: - Most SPAs I've seen generate useless server load: either by fetching too much information, or by fetching information too often. And that's not because SPAs are a bad idea per se, it's because many small companies have very small teams, and very small teams just don't have time to build a custom-tailored API ("backend-for-frontend"). We chose jsonapi with Django-Rest-Framework, which was crazy-easy to implement from the back-end perspective (as we had many other challenges), but which made the front-end developer implement twisted stuff on client-side, like prefetch-on-hover, or plugging react-query with crazy refresh settings generating hundreds of API calls when only 2 or 3 would have been enough. At the end of the day our servers load is not higher now. Each request costs a little bit more, but there are a lot less of them. - Another thing is: the idea of delegating template processing to the client may seem good from a wallet perspective. But if you also think of the environmental impact of what we do as developers, you might notice that many people get a new laptop on a regular basis just because some applications are more and more CPU and memory greedy. And when you think that about 80% of environmental impact of the digital industry is generated by building and shipping new terminals, it might make you realize that being part of the solution implied reducing the amount of client load you ask your users. And yes, this implies that your company accepts to reduce gross margin to take a very small action in the battle for a cleaner industry.
kaeshiwaza 4y ago
I can replace all the iframe from my legacy apps without changing any logic !
temp20202020 4y ago
I am in a remote village in India, Assam, Barpeta, Maranadir par. htmx or hotwire or pjax works great here on my 4g mobile network (Jio, Airtel) and surprisingly 3g BSNL (govt. supported isp). I think at least in India internet speed problem is a solved problem.
hnbad 4y ago
This again? From the first page of the documentation: With that in mind, consider the following bit of HTML: <button hx-post="/clicked" hx-trigger="click" hx-target="#parent-div" hx-swap="outerHTML" > Click Me! </button> We've been through this back in the Angular days (and even before that: remember Knockout?). Implementing your template language as DOM attributes does not make it HTML. Not to mention the examples using "hyperscript", aka a "human readable" DSL for DOM manipulation and event handling also stuck in HTML attributes. If you are a Python team, sure, avoiding JS is a good idea and tools like htmx which let you pretend you're not working in multiple languages while having to memorize a massive API implemented in DSLs bolted onto DOM elements are fine. I've worked with these kinds of libraries in the past and once you can get over the knowledge gap, they can be amazing 80% solutions and solve most of your problems. If you are either a "full-stack" JS (i.e. server + client written in JS) team or have more than one person specifically working on the frontend, this can just as likely be a massive footgun because you're trading a widely used, well-understood tool with a massive community for a somewhat niche one with a much smaller (but hopefully more dedicated and helpful) community. Sorry if my assessment of htmx comes across as sarcastic but TINSTAAFL and my criticism would equally apply if the talk was about moving from Angular or Vue. If having to write JS is a drain on your team's resources and you can't change that, yes, try moving away from JS even if it means going down a less travelled path. EDIT: To be clear: one of the early selling points of React was "it's just JavaScript", referring to how most comparable tools would require you to learn their DSLs to do basic things like a loop. React allowing you to actually use a JavaScript `forEach` or build an array in your render function instead of having a `data-react-foreach` attribute or something like that on an element was a breath of fresh air as tools like AngularJS or Knockout required you to use those and were extremely inflexible because of it (e.g. if they wanted to support filtering they'd have to bake it into the DSL whereas in React you could just do an `if` or `.filter`).
- recursivedoubts 4y ago
  Htmx is not simply angular-style directives with client-side templates again. it is, rather, an extension of HTML as hypermedia. That's the big difference between htmx and most other front end libraries. There are a number of essays here on this difference and the ramifications of it here: https://htmx.org/essays https://htmx.org/essays
kitsune_ 4y ago
Is this and Turbo etc. inspired by what ASP.NET MVC did with Partial Views 10+ years ago?
spion 4y ago
I may have missed it in the video, but where exactly do they store all the "client-side" state? Postgres? Redis? Sessions?
- pwdisswordfish0 4y ago
  There is no client-side state, that’s the whole point.
  - spion 4y ago
    There is always client-side state. The dropdowns, for example, have selection that affects the entire app. That selection must be stored in a state which will affect the reloads triggered by changes in the dropdowns.
    - pwdisswordfish0 4y ago
      Well, sure, the value of an input is in its value property, but you build your stuff in such a way that you don’t access it unless you absolutely have to.
      - spion 4y ago
        Did you actually watch the video? The things are built in such a way that there is global state shared among components.
        pwdisswordfish0 4y ago
        I did watch the video, iirc he literally says “is this client-side state I have to worry about? No.” multiple times. When the user changes something that affects the UI in multiple places, all the necessary fragments are fetched from the server and swapped in by htmx.
        spion 4y ago
petespeed 4y ago
Can anyone explain how htmx (or similar) would work for an electron app?
captnswing 4y ago
back in the days, I really liked https://malsup.com/jquery/taconite/ https://malsup.com/jquery/taconite/, which had a similar approach (but using xml snippets sent from server over ajax)
sfusato 4y ago
If your React SPA can be replaced by htmx, I would say you've chosen the wrong technology from the start. Certain type of applications require a SPA architecture, but most simply don't.
jakebasile 4y ago
As an aside, the author of this project is also the author of grugbrain.dev, the most wonderful and accurate software development site I've ever encountered.
- nikodunk 4y ago
  Wow!! This site made me laugh a few times while collecting these great lessons. Very well written!
xutopia 4y ago
People forget that React can be used for just the complex components that require it. Your entire page need not be a React app just because you use it for one component. To me it's bonkers that all web sites seem to be moving towards SPA when they don't benefit from it at all and require so much frontend work when a little bit of simple HTML and Javascript could do most of the work. It feels like the whole industry is Reactifying everything because they're scared that if they don't they won't look professional.
- hunterb123 4y ago
  What's the issue with using Next/React to build static and SSR web pages? React doesn't only work for SPA.
  - ec109685 4y ago
    If that requires full client side re-hydration in order for those SSR pages to become interactive, then the user receives a worse experience.
    - larrymyers 4y ago
      It's also a bit shocking how much javascript and json get loaded client side to facilitate this hydration for Next.js.
- larrymyers 4y ago
  This is an excellent point. It's a philosophy that I think Astro gets right. https://docs.astro.build/en/concepts/islands/ https://docs.astro.build/en/concepts/islands/ Combined with Preact instead React I think it allows for server content first, and sprinkling in interactive components as needed without much extra page size. At the end of the day a good component based js framework makes it a lot easier to implement a lot of things client side.
- smrtinsert 4y ago
  Resourcing for frontend is basically hiring for the superset of frontend tech. Once you have that team in place of course they'll use the tool that has the most options. It's a safe bet even if its not the best performance, and it's important on the resume.
dorongrinstein 4y ago
htmx is a great library. I can see a back-end-for-front-end pattern where a thin 'UI' layer emits the html/js/css based on orchestrating calls to REST/GraphQL APIs - where those already exist, or where having an API makes sense for native apps on mobile for example. To serve html to htmx sites closer to the caller/user, a developer can run the backend on something like https://controlplane.com https://controlplane.com (disclosure - I run Control Plane) where a request from Australia is served from Sydney and a request from New York is served from aws-us-east-2 for example. In short, htmx looks great because of the simplicity. I am sure it will be used by a lot of developers. Nice work!
prasadi 4y ago
0xblinq 4y ago
I've used this approach a lot, although I prefer Unpoly to htmx. On my last project I paired it up with Alpinejs for the 100% client side interactions, leaving Unpoly for the use cases where I would have needed an API call in the SPA world. I'm convinced 90% of the stuff we build out there should be built this way. It's so much easier and there's tht nice feeling about not being standing on tons and tons of overengineered tech. The last 10% on which I'd use react or similar are offline first apps or things such as figma, etc.
pkrumins 4y ago
I recommend doing another pass and reducing it all to plain HTML.
tomhallett 4y ago
As I was reading https://htmx.org/ https://htmx.org/, I kept thinking "Oh crap, yet another framework ripping off intercooler/alpine. Why?". Then I when I got to the bottom, I read that it's a rebrand/rename of intercooler, which gives me a lot more confidence/trust about the project. I would recommend putting the "htmx 1.0 = intercooler 2.0" at the top of the htmx website, similar to the intercooler website. Note: while the htmx homepage is short, I spent about 30 seconds reading/thinking about each "motivation" bullet point, and my monkey brain is very content jumping to conclusions about the project at a much faster pace, :).
- ColonelPhantom 4y ago
  I believe HTMX is also a rewrite (at least to some degree) of Intercooler, as it uses vanilla JS instead of jQuery.

575 points by mpweiher 4y ago

TLDR: - Took 2 months (21K LoC, mostly JavaScript) - No reduction in user experience - Reduced LoC by 67% (21,500 LoC to 7200 LoC) - They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS - Reduced JS dependencies by 96% (255 to 9) - Reduced web build time by 88% (40s to 5) - First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds) - Much larger data sets were possible than react could handle - Memory usage was reduced by 46% (75MB to 45MB) These are spectacular numbers that reflect that the application in question is highly amenable to the hypermedia approach. I wouldn't expect everyone to see this level of improvement, but at least some web apps would.

deleted 4y ago
[deleted]
keizo 4y ago
Speed is the big one for me. 2-6+ seconds is insanity for anything.
- recursivedoubts 4y ago
  Speed is definitely a big one. I also am glad to see that everyone on the dev team became full stack developers, because I think the back-end/front-end split is often detrimental to development velocity. It's often better when a developer can fully realize an entire feature, with no front-end/back-end friction.
  - keizo 4y ago
    Oh for sure. For me programming is a hobby, so I can only get something made if I do it all.
- funstuff007 4y ago
  I hear you, but YouTube takes 6+ seconds for me to load and it does not seem to hold them back. For most, not all, optimizing page load time is time probably best spent elsewhere. This is is no way to impugn htmx, because with htmx you seem to kill many birds with one stone.
  - stjohnswarts 4y ago
    Youtube is kind of unique in that nothing (currently) even comes close to replacing it for the average youtube user.
  - josephscott 4y ago
    Details matter, as they learned when making things faster made their metrics slower - https://blog.chriszacharias.com/page-weight-matters https://blog.chriszacharias.com/page-weight-matters
- jiggawatts 4y ago
  I would argue that 1-2 seconds is not impressive either. It's like seeing people breaking rocks with hand tools being impressed with a bigger mallet. I used to aim for 15 millisecond cold load times, which is apparently unheard of these days even for front pages with entirely static content.
  - keizo 4y ago
    Well yea, but start trimming with the biggest wins first.
  - earthboundkid 4y ago
    15ms to who? I’ve never had that kind of latency on a cold connection. My pages have an LCP of around 600ms, and it’s hard to push it much lower because even static pages on a CDN end up taking 400ms to connect and download.
    - jiggawatts 4y ago
      15 ms to anyone in the same city or on the same local network in an office setting. 50 ms to anyone in the same country, ideally lower. Global reach is a different problem because of physics. However, front pages of web pages tend to be largely static and can be staged in various geo-distributed regions. In other words, distributed via a CDN.. > even static pages on a CDN end up taking 400ms to connect and download. Only if you stuff them full of megabytes of Javascript and pull down megabytes of JSON in order to display that static content. The fact that my comment -- a factual statement about real-world performance I've achieved regularly -- is voted down and your off-by-an-order-of-magnitude reply is voted up speaks volumes about the state of the industry. It's like a bunch of fat people being flabbergasted about the mere concept of mountain climbing. With what... your legs!? Up there!? Madness!
      - earthboundkid 4y ago
        My site is a static page hosted on a CDN with less than 80KB of JavaScript. If you’re testing local network times, you’re just fooling yourself. None of your visitors are seeing that time, so it’s irrelevant. What’s your URL? I’d love to throw it into webpagetest.org and take a look.
MatthiasPortzel 4y ago
> Much larger data sets were possible than react could handle I find this one difficult to believe. I'm not calling BS necessarily, but I doubt it applies in the general case. I have a Django app that's server-side rendered, the largest page is very large (~200kb of content). Django on a low-tier VPS took about 500ms just to render that page. Django templates aren't faster than React. And Python isn't faster than JS. If they're seeing performance increases I'd guess it's either that they're being more judicious about their queries (pulling only what they need from the database instead of filtering client-side), or the React app had a lot of complexity and they simplified the UI when re-writing.
- andrewingram 4y ago
  I’d be a little surprised if rendering that same Django page as a server-rendered React app wasn’t even slower. Historically, server-rendered React has been painfully slow compared to Django (I’ve been doing SSR with React since 2014, using Django since 2006, experienced the pain first hand multiple times). Usually at least an order of magnitude slower. That said, I haven’t benchmarked in a while, perhaps the worst of it has since been addressed.
tannhaeuser 4y ago
I think the value of markup-based templating approaches such as HTMX and SGML comes from enabling content authors to create dynamic document-oriented sites without having to deal with dangerous tools such as JS and the endless ways too shoot yourself and your visitors into the foot (through eg injections and other security issues). The difference between HTMX and SGML being that HTMX integrates templating as markup vocabulary extension while SGML brings syntactical templating at the markup declaration level. A developer, OTOH, might choose JS-heavy approaches to avoid limitations and learn new syntax/concepts, and to re-use existing knowledge from/to other projects. I don't know that speed of development is of primary concern.

pen2l 4y ago

One reason I prefer doing React is that retrofitting existing React stuff for React Native is better/easier than embarking on React Native from scratch.

samwillis 4y ago
I would argue that most “apps” built with React Native don’t need to be apps at all, they are better as websites. The majority of these apps are about placing the existing product into the App Store for discoverability, and encouraging users to be “locked” into the app at the expense of a worse customer experience. A web app, in a browser, automatically has support for opening multiple pages as multiple tabs, bookmarks, sharing pages. You can’t do that with 99.9% of apps. I will also argue strongly that, again, react native is unnecessary even if you do want to package a native app. WebView based apps perform as well as a react native app, and most of the time with significantly less additional code. It also forces you to up your “mobile website” UX. In general the minuet you build a mobile “app” the mobile web experience gets neglected.
- duxup 4y ago
  How would we even know what most React Native apps are like to… know this?

samwillis 4y ago

Love htmx and this talk is a brilliant run down of where it works well. But as always it’s about choosing the right tool for the job. Server rendered pages/fragments solve so many issues around security and time to develop a product, however it only gets you so far. Ultimately I think the decision when choosing a stack comes down to how much state you need to managed in browser. The vast majority of sites needs very little client side state management, htmx and other tools such as Alpine.js are perfect for this. But eventually as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework. Now that doesn’t always mean going all in on a full SPA covering the whole of your product. It could just be a small fragment that requires that level of interaction. Point is, don’t pick a tool because it’s “in vogue”, pick one because it lets you build the best possible product as efficiently as possible. For 80% of websites that could be htmx, and for the next 15% htmx probably works for 90% of their pages. It’s the 5% where htmx is not one of the right choices at all.

ChrisDevx 4y ago
I have 2 problems with htmx (IMHO): 1. SoC: the server API needs to return only the data and meta data requested, and it should not be concerned with the display-layer (html), because many different clients i.e. mobile app, browser, Electron etc. might want to consume this API. 2. Logistics & scaling: Imagine a large application with 100s of html/htmx components and views, now you alter your database, you introduce new business rules etc... If you used React or Alpinejs etc. you could just go to the relevant stores or app code and make the change as opposed to sifting and refactoring tons of html. Personally I'd rather just use Alpinejs from the start, knowing its lightweight, fast and easy to implement, and not end up painting myself into a corner over the application lifecycle.
- recursivedoubts 4y ago
  1. https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ 2. many large applications use htmx (or related approaches like hotwire, unpoly, etc.) and scale fine. hypermedia is better at handling databaase/logic/API changes than fixed-format data APIs because your API is encoded within hypermedia responses: https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/

quickthrower2 4y ago

It is a cliche but probably true: Second rewrite will be better by those sort of metrics even without a tech change. Lessons learned get applied. Domain is fully known. I definitely believe in fewer LOC with any not-react due to all the hooks, memo, etc. boilerplate though!

recursivedoubts 4y ago
This wasn't a complete rewrite, it was a feature-for-feature rewrite of the front-end, moving from react to htmx, mainly as a proof of concept at first. Note that the amount of python actually increased, as logic was moved back to the server. While I'm sure there were a few places where better decisions were made, I think it's reasonable to assume that the majority of the reduction in code is due to the different approach to front end development.

gardenhedge 4y ago

I consider this an alternative development approach neither better or worse than what it is trying to replace. The winner in recent approach, imo, is Remix Run.

recursivedoubts 4y ago
Reducing a code base by 2/3rds isn't better than what it replaced? At least in some sense?
jaredcwhite 4y ago
For literally every developer on the planet who is not an expert JavaScript developer—or who doesn't wish to be—this is undoubtedly a better development approach. Saying "Remix is the winner" doesn't really move the needle. It's still JavaScript, still React—just with some work pushed to the server instead of the client. The contract of the web is that while the client-side language in use may not be up to the discretion of the developer (recent evolutions in WASM notwithstanding), the server-side language/framework/OS/etc. can be literally anything which speaks the protocol of HTTP/HTML/etc. JS frameworks for years have repeatedly broken that contract with the claim that we must accept it for…well, "reasons". If it turns out most of those reasons are bupkis—more a matter of preferences than requirements—then we must stop breaking the contract. JS as a server-side language should _get in line_ alongside all the other languages out there. Why privilege it if we don't need to?
- andyfleming 4y ago
  > It's still JavaScript, still React—just with some work pushed to the server instead of the client. This is being too reductive of the design of Remix. It is closer to traditional web applications in handling form submissions. There's no client-side state management needed for those use cases. Whether it's the "winner" or not, really depends on use case, but it is decently different than a traditional SPA.
flexterra 4y ago
IMHO this approach is better for most apps. Remix is bending the curve here. They make it extremely easy to progressively enhance a small part of your UI with all the power of React. That said, using React on the server side and forcing you to run JS on the server is not my cup of tea...

endisneigh 4y ago

serve side rendering is ideal, but at the end of the day what matters these days is developer productivity. a better question is how long it takes to make something like gmail with htmx vs. say react. you might say most apps are not gmail, and you'd be correct. so then you say, ok what about something like wikipedia? easy enough. then you start adding all of this javascript and it becomes a mess.

infamia 4y ago
Interesting you mention Gmail, that's one of the examples given in the Layers Tutorial for Unpoly, which is a batteries-included take on the basic ideas behind HTMX. https://unpoly.com/tutorial https://unpoly.com/tutorial
pier25 4y ago
Use the right tool for the job. Obviously Gmail is a much better fit for React/Vue/etc than HTMX. Gmail is the perfect use case for an SPA but most web apps don't need to be an SPA.
- adamckay 4y ago
  > Gmail is the perfect use case for an SPA Is it really, though? It's a paginated list of emails, some drag-and-drop functionality, buttons for some ajax functionality. It works reasonably well, but it doesn't need to be so high Javascript compared to Google Docs or maps.
  - hunterb123 4y ago
    Viewing your emails offline is pretty important.
    - pier25 4y ago
      And being able to use Gmail (search emails etc) while writing an email too

dhucerbin 4y ago

Listing template dependencies as event names that can change underlying data seems very brittle (hx-trigger for favorite articles). You would need at least integration tests to get some confidence! Can’t we infer used state in template and setup triggers for developer? LiveView gives better DX in this case.

sergiomattei 4y ago

A note I’ve internalized lately: there is a middle ground. You can write excellent, lightweight React apps by simply writing semantic HTML and taking advantage of the platform (declarative form validations, a simple CSS pipeline, etc). It doesn’t have to be madness in the front-end. NextJS, in particular, keeps the build pipeline quite simple.

chrisweekly 4y ago
In the React ecosystem, Remix.run embraces a much simpler approach than Next.js.

deleted 4y ago

[deleted]

ksbrooksjr 4y ago

Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a build step to use it [3]. [1] https://unpkg.com/browse/htmx.org@1.8.2/dist/ https://unpkg.com/browse/htmx.org@1.8.2/dist/ [2] https://unpkg.com/browse/preact@10.11.2/dist/ https://unpkg.com/browse/preact@10.11.2/dist/ [3] https://preactjs.com/guide/v10/getting-started#no-build-tools-route https://preactjs.com/guide/v10/getting-started#no-build-tool...

flexterra 4y ago
The programming model is totally different when working with HTMX. The server returns HTML instead of a JSON API which is the usual solution when building apps with React/Preact and similar.
- ksbrooksjr 4y ago
  Yea htmx definitely has a different programming model than an SPA style framework like React/Preact. I actually like the JSON api programming model where the backend is as simple as possible, and the frontend js/ts code is completely responsible for handling the UI, but I guess it's a matter of personal preference. The linked article is referring to a team switching from React to htmx though, so for them I'd imagine it would've been a much easier transition if they'd just added a Webpack alias[1] that replaced React with preact/compat, rather than switching to a completely different UI paradigm. [1] https://preactjs.com/guide/v10/getting-started#aliasing-in-webpack https://preactjs.com/guide/v10/getting-started#aliasing-in-w...
  - flexterra 4y ago
    The difference in programming model IS THE advantage of HTMX. Changing from react to preact is a perf optimization. If you are doing the SPA thing correctly you must duplicate business logic (data validation). Also when your API just sends "dumb data" (JSON) to the client, you are forced to make changes to the backend and frontend in lockstep.

xwowsersx 4y ago

Link to the talk mentioned if you were looking for it as I was: https://youtu.be/3GObi93tjZI https://youtu.be/3GObi93tjZI

nikodunk 4y ago

This is a really beautiful approach IF you don't need mobile. If you do need mobile, then you may be better served (pointlessly) running React on web and re-using all of the logic/fetchers, etc for React-Native on mobile IMO. Your other option would be to do something like 37 Signals and render web with htmx (or in their case Hotwire) and server-render mobile too, but wrap the web views with a thin native mobile navigation layer to make it feel more native. Very jealous if your project is web-only - this can work wonderfully and be incredibly efficient! I've been thinking about this a lot recently and also just blogged about it (https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-efficiency/ https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-e...).

paulryanrogers 4y ago
Efficient for dev time, not so sure about mobile app size, RAM usage, or response time.
- nikodunk 4y ago
  Definitely! Wasn't considering the other 3 in this discussion. The most efficient for all of these is most likely a native app everywhere, and all the complexity/duplication that brings.
recursivedoubts 4y ago
If the hypermedia approach really grabs you, you could pair an htmx-based web application with a HyperView-based mobile application: https://hyperview.org/ https://hyperview.org/
- haolez 4y ago
  I can't decide if this is awesome or terrifying. Will try it out :)
  - recursivedoubts 4y ago
    :) why not both?

agrippanux 4y ago

I don’t understand why this effort was undertaken vs migrating to NextJS and accomplishing the same thing in half the time without needing to ramp up more Python.

legutierr 4y ago
I don't think the point here was to show how quickly they could migrate to another framework, but rather to show that HTMX is powerful enough to use for things like this. The point seems to have been to show how you don't need to use React to build applications like this, so migrating to NextJS wouldn't have made any sense from that perspective.
- kajaktum 4y ago
  That would make sense if this was a hobby project but it’s not.
yawaramin 4y ago
Because migrating to NextJS would have meant doing a rewrite of the entire backend which was already written in Python/Django and running in production. Migrating to htmx was much less risky.
- danieljacksonno 4y ago
  NextJS can use an external API? It doesn't need to be fully full-stack.
  - yawaramin 4y ago
    So then add Next.js when we're already using another backend service. The idea is to reduce complexity, not the other way round.
halfcat 4y ago
Perhaps they are better equipped to write more Python, less JavaScript.

cloudking 4y ago

What is the best framework to build a high performance web application on? Specifically for building a UI to work with large sets of tabular data similar to a spreadsheet, e.g thousands of rows. Is Htmx up for this task?

recursivedoubts 4y ago
A spreadsheet is probably not amenable to the hypermedia approach because of the complicated inter-dependencies between arbitrary parts of the screen. You don't want to gate those updates on a hypermedia exchange. I would look at writing either a custom solution or one of the big reactive libraries like vue.js for something like this.
tonto 4y ago
this repo keeps track of various benchmarks on a data grid type app https://github.com/krausest/js-framework-benchmark https://github.com/krausest/js-framework-benchmark eventually you may need to create "virtualized scrolling" (e.g. only rendering a subset of the total table to the screen at a time) which can hard to make seemless. possibly the benchmark is "too much info" to make a good choice, but it is an interesting resource.
firecall 4y ago
Totally unfashionable answer: I use 'Rails 6.x and datatables.net. The system manages call-logs for a call centre with WFH staff. It's doing thousands of calls a day. The tables are 'endless' pagination reporting tables. It's hosted in Sydney, AU. And used by staff around the world. It has the advantage of being extremely robust on the dodgiest of old PCs with poor internet connections. So not fashionable, but it's super reliable and has a well documented implementation path!
- germandiago 4y ago
  Your solution looks like the right way to do it to me. At least in your case.
pier25 4y ago

steve76 4y ago

jokethrowaway 4y ago

That's great, I still remember how productive teams were in the jQuery times. Angular and react slowed down development massively. Nowadays teams are often busy fixing random stuff for days

miiiiiike 4y ago

The hoops people will jump through to avoid learning HTML/CSS/JS. I say this as a Python/Django dev who resisted learning web tech for 20 years: It's time to just learn this stuff. You can slap on a mound of band-aids and watch the wound bleed forever. Or, you can go in, get three stitches, suffer a little pain, and let the healing process begin.

deleted 4y ago
[deleted]
recursivedoubts 4y ago
I think this take does yourself a disservice: htmx is an extension of HTML and, in general, of the hypermedia model, and it is this model that should be contrasted with JSON data APIs. I think that you should learn JavaScript, and I certainly think you should learn HTML(!!!) and CSS. But I also think you should consider how much more can be achieved in a pure hypermedia model with the (relatively small) extensions to HTML that htmx gives you. I have a collection of essays on this topic here: https://htmx.org/essays/ https://htmx.org/essays/ Including an essay on how I feel scripting should be done in Hypermedia Driven Application: https://htmx.org/essays/hypermedia-driven-applications/ https://htmx.org/essays/hypermedia-driven-applications/ There is more to all this than simply avoiding JavaScript.
- miiiiiike 4y ago
  I’ve used htmx.
  - recursivedoubts 4y ago
    I'm sure you have. Regardless of that, the idea that you learn htmx because don't want you to learn JavaScript is simply incorrect. Rather, it's how you use JavaScript that should be considered.
    - miiiiiike 4y ago
      JSON APIs are usable beyond the browser and using htmx feels like using Django+jQuery 14 years ago. I'd rather not go back to that.

parhamn 4y ago

There are four main problems in the React SPA world: - State management - hooks are awful for anything complex - Packaging + Bundling - Webpack kitchen sink, JS/TS, browser vs node vs random runtimes, packaging vs bundling, etc - Data/API binding - Adds distributed state to your data and the complexity that goes with that (cross dom reuse, caching, staleness, realtime updates, etc) - SEO/Prehydrating - Mostly applies to landing/CRM/blog type things. These 'old school' solutions help you avoid some of these issues in favor of relocating the complexity a bit (those templates in the talk are absolutely gnarly and I'm sure very bug prone) and reducing the experience. Also the API boundaries are blurred should you ever need one for non UI usage. Ignoring HackerNews taste for simpler websites, some complexity of UIs can and should only be captured with client sided javascript. With that said, after a few years of things shifting around I'm really happy with the Typescript (lang) + Parcel (packaging) + MobX (state management) + Vercel (when server side rendering is needed). They've been really stable, no fuss, always work. Especially MobX for state, absolutely game changing for the dev experience. As for the data binding problem, still sucks and my 4th attempt at solving it internally is still meh. This feels like it comes with the territory. As much as I loved my working with Django/Jinja2/etc, I think theres a light at the end of this tunnel.

Humphrey 4y ago
I've solved your data binding problem with: GraphQL (server) + UrQL (JS graph client with the graphcache plugin) + GraphQL Code Generator (creates TS types for your API). The data syncs perfectly, keeps up-to-date. GraphQL subscriptions allow for real time updates. Oh, and React-Hook-Form for forms, which feeds quite nicely into my GraphQL mutations. It's a real neat solution. As for server side, I've started using Python-Strawberry (was using Graphene but it stopped receiving updates) with Django. It's super solid stack, with typings flowing all the way from server API through to my react components.

jdthedisciple 4y ago

Wouldn't it be nice to have an actual link to an example of the same site written in React and Htmx?

danielvaughn 4y ago

Some years ago, a bright guy created something called 7 GUIs. It’s a collection of seven problems that all UI systems must successfully implement, and it was intended to act as a guide for comparisons. Unfortunately I think the author has passed away, but it would be interesting to see it rekindled and used for baseline comparisons like these. https://eugenkiss.github.io/7guis/ https://eugenkiss.github.io/7guis/

deleted 4y ago
[deleted]
edflsafoiewq 4y ago
I don't think Htmx is a good fit for those. I wouldn't want a server roundtrip for any of them (except maybe part of CRUD).
- DannyPage 4y ago
  Hyperscript[1] pairs well with HTMX (as it should, it’s by the same group) and would fill those gaps. [1] https://hyperscript.org/ https://hyperscript.org/
  - xutopia 4y ago
    What are the advantages of Hyperscript over plain old Javascript?
    - recursivedoubts 4y ago
      a few: - it is designed to be embedded directly in HTML - it can listen for any event (unlike on* attributes) - it has native support for CSS selectors: https://hyperscript.org/docs/#dom-literals https://hyperscript.org/docs/#dom-literals - it has async-transparency: https://hyperscript.org/docs/#async https://hyperscript.org/docs/#async - subjectively, it is easier to read than JavaScript, particularly for the short, light scripts it is designed for (toggling a class, etc.): `on click toggle .clicked on me` hyperscript is more of a glue language than something I would recommend building an entire application out of (although people are doing that!)

bigDinosaur 4y ago

I'm just so burnt out with new things. How do I combat such burnout? I really don't care about 'Htmx', I think barely any apps need much beyond what was available in ~2006 in terms of web tech. I just feel tired knowing that moving from React to Htmx is an option. Yet another option which will very possibly bring zero commercial value (although it might be a nicer dev experience I guess) to any project I ever work on. Am I wrong?

__s 4y ago
You can get by mostly ignoring the churn. I still haven't switched to hooks with React; I'll figure it out when I run into a codebase using them
recursivedoubts 4y ago
That's understandable, the front end world is extremely churny. If you don't want to deep dive on htmx-as-a-tool due to burn out, I completely understand. But, at some point, it might make sense to read up on the philosophy behind it (hypermedia as an archiecture) because that is an area where it is different than most front end frameworks today. I have a collection of essays here: https://htmx.org/essays https://htmx.org/essays
- bigDinosaur 4y ago
  Thanks, I'll definitely take a look given your (and others') replies here.
29athrowaway 4y ago
Unless you need to hire. Then 2006 tech is not viable. 2006 tech in frontend = COBOL level stuff
- nabaraz 4y ago
  This is not a correct interpretation. I'd argue the basics - HTML, CSS and Javascript hasn't changed as much since 2006. jQuery came out in 2006 and we were manipulating DOM back then. Now, we have frameworks like React, where we are manipulating DOM. The only differences are new browser APIs and a much better code maintainability.

juddlyon 4y ago

htmx is deceptively powerful for how easy it is to use.

fareesh 4y ago

I am fortunate to have gone 10 years without having to use react in production ever. I've used rails+turbolinks and included Vue or Stimulus or even jQuery to get on page interactivity done. The current state of the react / jam world strikes me as an HR led solution where you can get humans who only know JS to be more productive without having to worry about servers, databases or infrastructure.

have_faith 4y ago
It’s not the most popular framework in the world for web apps because it pleases front end devs who are scared of the backend.

pier25 4y ago

I was expecting something that would blow me away... but honestly that UI is not super sophisticated. You could solve that with vanilla or jQuery. Obviously React (or any of the modern libs/frameworks) would be overkill for that. IMO this video reinforces the idea that for personally simple stuff I'd rather just use jQuery (or rather CashJS) or even vanilla.

talideon 4y ago
That's exactly why HTMX was a good fit for this: it covers exactly the kind of Interaction patterns you'd find yourself writing in vanilla JS where React is overkill, except without having to write all that JS. Though I don't know why you'd bother with jQuery these days unless you had to deal with ancient browsers: venerable as it is, it's obsoleted itself as just about everything it did is now covered by browser APIs.
- pier25 4y ago
  > is now covered by browser APIs I've never understood that argument. You could always do what jQuery does with vanilla JS. How could it be otherwise? The point of jQuery is productivity. Even today, a jQuery-style API saves you from writing a lot of code.
  - padjo 4y ago
    The biggest boon of JQuery back in the day was that it abstracted over all the browser variances, which were far more numerous at the time. Also many APIs simply didn’t exist(e.g. querySelector). Now that browsers are much mor standards compliant and there are much better APIs it feels like the rationale for jQuery has shrunken to pretty much zero
  - talideon 4y ago
    No it doesn't. Just about everything jQuery does is now a browser API these days, so you no longer save time using jQuery vs vanilla JS. The only argument for continuing to use it is that you're used to it and not used to the modern APIs that have absorbed jQuery's functionality. It's just a slower way of doing the same thing.

Throwaway23459 4y ago

Speeding up the build could be done in other ways, were they using esbuild or something fast previously? Probably not. The memory usage saving is really not a big deal, load up your favourite news web page and look at the memory it chews up in comparison. As for the preference implied for python over js, that's fine, but the choice is not binary, typescript is my preference for a React project, for example. Reduction in LOC is slightly misleading, JSX creates a lot of lines. It would be interesting to see a proper write up on the data React couldn't handle.

rwalle 4y ago
Agreed. More details are necessary to understand the potential benefit of such rewrites. And to be honest 21K LOC is not a big project. I can imagine that as project grows even larger, there will be problems that htmx cannot or is difficult to handle, and I'll be curious about how that would work out.

sriram_malhar 4y ago

Loved the presentation, and prodded me to revisit the latest state of htmx and django.

Glyptodon 4y ago

Expected this to be more interesting than a maybe fancier version of turbolinks. Am I missing something?

David-Guillot 4y ago
Hi there ; I'm the author of the talk linked in the article. Technically you're not missing anything: htmx is nothing more than another turbolinks, maybe more flexible and easier to learn. What you might be missing is the non-technical implications of these new tools. The idea behind the talk (and behind htmx, and behind turbolinks, or unpoly) is to prove that the usual arguments for Javascript application frameworks are just not valid for 90% of use cases. And *that's* a complete game-changer, even an industry-changer. Because since 2016, every small-and-not-super-rich company that wants to create a rich UX on the web is told to hire at least 2 developers: one "front-end" (i.e. "JS"), and one "backend-end" (i.e. everything else, from API to hosting through domain stuff and user data). Or one superman with both back-end and React skills, which is, IMO, almost impossible. From what I've seen, what businesses need is, indeed, 2 devs: one "back-end" (i.e. workers, databases, user data, domain stuff, and even hosting), and one "front-end" (i.e. "the website", from DB queries to CSS). One person should be enough to address this second scope, even with complex UIs and rich UX. And as this is almost impossible with Javascript application frameworks (because they require a lot of work), it becomes possible again, like in 2008, with htmx/hotwired/unpoly (and without the spaghetti code we had in 2008). One more thing: of course the idea was *never* to do JS-bashing, only people who are too tied to Javascript and not caring about tech cost-effectiveness would see htmx as a thing for JS-haters. In my talk I actually show some Javascript code, because it's useful for handling client-side-only stuff like a custom dropdown, a modal, etc. The whole idea is to put Javascript back at its place: pure client-side advanced interactions.
beebeepka 4y ago
The htmx guys self promote here all the time. Their selling point is "no js" for slightly interactive demo apps. 10/10 times is just them openly bashing the rest of us for not using their tech.
- 4y ago

camkego 4y ago

Deep inside the comments is a wise question. What happened to the user experience over high latency links? Across countries? Over high latency mobile links? Starlink latency anyone?? Not every situation has high latency, but it's worth asking what happens when moving from React to Htmx in those situations.

richbell 4y ago
Conversely, a poorly optimized SPA may not even load in a reasonable time span.

silver-arrow 4y ago

We have experienced similar results moving to htmx and a hypermedia approach for building dynamic web apps. It simplifies development greatly and has resulted in better productivity. Like the results cited here, we too are extremely pleased that the majority of our coding now falls into our preferred language - Clojure (using Hiccup). Very pleasant experience!

kgeist 4y ago

Doesn't server rendering increase load on the server? I like to off-load as much processing to the user's browser as possible. We have ~1 million users and I like to think that when we off-load a lot of processing to the browser, we basically have 1 million servers for free.

newbieuser 4y ago
It is quite nice to create on the browser, but as the number and variety of clients increase, the application may become slow for some. And the main problems start there.
kaeshiwaza 4y ago
Rendering html doesn't consume a lot more than rendering json, specially that with htmx you'll render small fragments... Anyway the bottleneck is most of the time on the database.
talideon 4y ago
Consider this: you're doing server side rendering whether it's JSON or HTML fragments you're sending across. They're just different serialisations of the same data. The problem that SPAs were meant to fix was that each update of the page meant a full rerender under the classic model rather than just rerendering those bits that had actually changed. You're still going to be able to take advantage of those client machines to do rendering, but the difference is that with HTMX, you skip serialising JSON, so your clients aren't stuck doing unnecessary rendering. The load on the server is barely different, but the client has less to do. Now, if you're doing an awful lot of data manipulation on the client, that's a different story.
David-Guillot 4y ago
Hi! Sorry for the delay. I'm the one who gave this talk. Yes, rendering HTML on server-side increases server load, for the simple reason that the server-side templates contain some display logic. But: - Most SPAs I've seen generate useless server load: either by fetching too much information, or by fetching information too often. And that's not because SPAs are a bad idea per se, it's because many small companies have very small teams, and very small teams just don't have time to build a custom-tailored API ("backend-for-frontend"). We chose jsonapi with Django-Rest-Framework, which was crazy-easy to implement from the back-end perspective (as we had many other challenges), but which made the front-end developer implement twisted stuff on client-side, like prefetch-on-hover, or plugging react-query with crazy refresh settings generating hundreds of API calls when only 2 or 3 would have been enough. At the end of the day our servers load is not higher now. Each request costs a little bit more, but there are a lot less of them. - Another thing is: the idea of delegating template processing to the client may seem good from a wallet perspective. But if you also think of the environmental impact of what we do as developers, you might notice that many people get a new laptop on a regular basis just because some applications are more and more CPU and memory greedy. And when you think that about 80% of environmental impact of the digital industry is generated by building and shipping new terminals, it might make you realize that being part of the solution implied reducing the amount of client load you ask your users. And yes, this implies that your company accepts to reduce gross margin to take a very small action in the battle for a cleaner industry.

kaeshiwaza 4y ago

I can replace all the iframe from my legacy apps without changing any logic !

temp20202020 4y ago

I am in a remote village in India, Assam, Barpeta, Maranadir par. htmx or hotwire or pjax works great here on my 4g mobile network (Jio, Airtel) and surprisingly 3g BSNL (govt. supported isp). I think at least in India internet speed problem is a solved problem.

hnbad 4y ago

This again? From the first page of the documentation: With that in mind, consider the following bit of HTML: <button hx-post="/clicked" hx-trigger="click" hx-target="#parent-div" hx-swap="outerHTML" > Click Me! </button> We've been through this back in the Angular days (and even before that: remember Knockout?). Implementing your template language as DOM attributes does not make it HTML. Not to mention the examples using "hyperscript", aka a "human readable" DSL for DOM manipulation and event handling also stuck in HTML attributes. If you are a Python team, sure, avoiding JS is a good idea and tools like htmx which let you pretend you're not working in multiple languages while having to memorize a massive API implemented in DSLs bolted onto DOM elements are fine. I've worked with these kinds of libraries in the past and once you can get over the knowledge gap, they can be amazing 80% solutions and solve most of your problems. If you are either a "full-stack" JS (i.e. server + client written in JS) team or have more than one person specifically working on the frontend, this can just as likely be a massive footgun because you're trading a widely used, well-understood tool with a massive community for a somewhat niche one with a much smaller (but hopefully more dedicated and helpful) community. Sorry if my assessment of htmx comes across as sarcastic but TINSTAAFL and my criticism would equally apply if the talk was about moving from Angular or Vue. If having to write JS is a drain on your team's resources and you can't change that, yes, try moving away from JS even if it means going down a less travelled path. EDIT: To be clear: one of the early selling points of React was "it's just JavaScript", referring to how most comparable tools would require you to learn their DSLs to do basic things like a loop. React allowing you to actually use a JavaScript `forEach` or build an array in your render function instead of having a `data-react-foreach` attribute or something like that on an element was a breath of fresh air as tools like AngularJS or Knockout required you to use those and were extremely inflexible because of it (e.g. if they wanted to support filtering they'd have to bake it into the DSL whereas in React you could just do an `if` or `.filter`).

recursivedoubts 4y ago
Htmx is not simply angular-style directives with client-side templates again. it is, rather, an extension of HTML as hypermedia. That's the big difference between htmx and most other front end libraries. There are a number of essays here on this difference and the ramifications of it here: https://htmx.org/essays https://htmx.org/essays

kitsune_ 4y ago

Is this and Turbo etc. inspired by what ASP.NET MVC did with Partial Views 10+ years ago?

spion 4y ago

I may have missed it in the video, but where exactly do they store all the "client-side" state? Postgres? Redis? Sessions?

pwdisswordfish0 4y ago
There is no client-side state, that’s the whole point.
- spion 4y ago
  There is always client-side state. The dropdowns, for example, have selection that affects the entire app. That selection must be stored in a state which will affect the reloads triggered by changes in the dropdowns.
  - pwdisswordfish0 4y ago
    Well, sure, the value of an input is in its value property, but you build your stuff in such a way that you don’t access it unless you absolutely have to.
    - spion 4y ago
      Did you actually watch the video? The things are built in such a way that there is global state shared among components.
      - pwdisswordfish0 4y ago
        I did watch the video, iirc he literally says “is this client-side state I have to worry about? No.” multiple times. When the user changes something that affects the UI in multiple places, all the necessary fragments are fetched from the server and swapped in by htmx.
        spion 4y ago

petespeed 4y ago

Can anyone explain how htmx (or similar) would work for an electron app?

captnswing 4y ago

back in the days, I really liked https://malsup.com/jquery/taconite/ https://malsup.com/jquery/taconite/, which had a similar approach (but using xml snippets sent from server over ajax)

sfusato 4y ago

If your React SPA can be replaced by htmx, I would say you've chosen the wrong technology from the start. Certain type of applications require a SPA architecture, but most simply don't.

jakebasile 4y ago

As an aside, the author of this project is also the author of grugbrain.dev, the most wonderful and accurate software development site I've ever encountered.

nikodunk 4y ago
Wow!! This site made me laugh a few times while collecting these great lessons. Very well written!

xutopia 4y ago

People forget that React can be used for just the complex components that require it. Your entire page need not be a React app just because you use it for one component. To me it's bonkers that all web sites seem to be moving towards SPA when they don't benefit from it at all and require so much frontend work when a little bit of simple HTML and Javascript could do most of the work. It feels like the whole industry is Reactifying everything because they're scared that if they don't they won't look professional.

hunterb123 4y ago
What's the issue with using Next/React to build static and SSR web pages? React doesn't only work for SPA.
- ec109685 4y ago
  If that requires full client side re-hydration in order for those SSR pages to become interactive, then the user receives a worse experience.
  - larrymyers 4y ago
    It's also a bit shocking how much javascript and json get loaded client side to facilitate this hydration for Next.js.
larrymyers 4y ago
This is an excellent point. It's a philosophy that I think Astro gets right. https://docs.astro.build/en/concepts/islands/ https://docs.astro.build/en/concepts/islands/ Combined with Preact instead React I think it allows for server content first, and sprinkling in interactive components as needed without much extra page size. At the end of the day a good component based js framework makes it a lot easier to implement a lot of things client side.
smrtinsert 4y ago
Resourcing for frontend is basically hiring for the superset of frontend tech. Once you have that team in place of course they'll use the tool that has the most options. It's a safe bet even if its not the best performance, and it's important on the resume.

dorongrinstein 4y ago

htmx is a great library. I can see a back-end-for-front-end pattern where a thin 'UI' layer emits the html/js/css based on orchestrating calls to REST/GraphQL APIs - where those already exist, or where having an API makes sense for native apps on mobile for example. To serve html to htmx sites closer to the caller/user, a developer can run the backend on something like https://controlplane.com https://controlplane.com (disclosure - I run Control Plane) where a request from Australia is served from Sydney and a request from New York is served from aws-us-east-2 for example. In short, htmx looks great because of the simplicity. I am sure it will be used by a lot of developers. Nice work!

prasadi 4y ago

0xblinq 4y ago

I've used this approach a lot, although I prefer Unpoly to htmx. On my last project I paired it up with Alpinejs for the 100% client side interactions, leaving Unpoly for the use cases where I would have needed an API call in the SPA world. I'm convinced 90% of the stuff we build out there should be built this way. It's so much easier and there's tht nice feeling about not being standing on tons and tons of overengineered tech. The last 10% on which I'd use react or similar are offline first apps or things such as figma, etc.

pkrumins 4y ago

I recommend doing another pass and reducing it all to plain HTML.

tomhallett 4y ago

As I was reading https://htmx.org/ https://htmx.org/, I kept thinking "Oh crap, yet another framework ripping off intercooler/alpine. Why?". Then I when I got to the bottom, I read that it's a rebrand/rename of intercooler, which gives me a lot more confidence/trust about the project. I would recommend putting the "htmx 1.0 = intercooler 2.0" at the top of the htmx website, similar to the intercooler website. Note: while the htmx homepage is short, I spent about 30 seconds reading/thinking about each "motivation" bullet point, and my monkey brain is very content jumping to conclusions about the project at a much faster pace, :).

ColonelPhantom 4y ago
I believe HTMX is also a rewrite (at least to some degree) of Intercooler, as it uses vanilla JS instead of jQuery.