22 ms·
An SPA Alternative
- vladstudio 4y agoEvery time I see an essay from Carson, author of HTMX, I upvote instantly! Make sure to check other essays at https://htmx.org/talk/ https://htmx.org/talk/ (scroll down for Essays)
- MrWiffles 4y agoWhat's the actual advantage of HTMX over something like React or Vue? All 3 require some form of JavaScript library coupled with markup to build interfaces. While I'm all about killing JavaScript as much as possible (why should I let $MEGACORP execute code on my device all willy-nilly without any real restrictions?), I just don't see the tangible benefit to the end user here. (And don't start with "it's faster/more efficient", that comparison isn't terribly valid because the inefficiencies seen with React/Vue are largely an artifact of bad code/practices, not the libraries themselves.)
- RobbieGM 4y agoWithout any real restrictions? JavaScript is very restricted in what it can do. Most APIs that you'd expect to be gated behind a permission are gated behind a permission.
- S34RZrXNZoeemHj 4y ago
- traverseda 4y agoYou can generate your HTML using a server-side template, and it is mostly just HTML. > All 3 require some form of JavaScript library coupled with markup to build interfaces. With HTMX you're typically including one static javascript file that you just download, you're not using any kind of javascript build system at all. Where it has very limited scope it's possible to imagine a browser that doesn't have javascript but that has HTMX built in. Calling it a javascript library might be a bit much, I mean you're not typically installing this with node/npm, or minifying it, or importing it. You're just including it in a script tag at the bottom of your site. While they both do technically run on javascript I think they have more differences than things they have in common, and saying "Well they're both just javascript libraries" is a very sophomoric take. I mean you might as well just say that all javascript libraries are the same, and it doesn't matter what you use. So why choose react/vue over jquery? > inefficiencies seen with React/Vue are largely an artifact of bad code/practices, not the libraries themselves. Ehh, I'm sure you can make a fast bug-free website in server-side assembly if you're so inclined but it's probably not the right tool for the job. The question is what kind of design patterns do the libraries/tools encourage, not "can I do X with Y".
- y2bd 4y agoI want to note that Vue provides official instructions on how to use it without build tools [1], and lots of folks who have written posts on how to use React without tooling as well [2]. I agree that they're ultimately designed to be used with tooling, but it's not a blanket requirement. - [1] https://vuejs.org/guide/quick-start.html#without-build-tools https://vuejs.org/guide/quick-start.html#without-build-tools - [2] https://blog.jim-nielsen.com/2020/react-without-build-tools/ https://blog.jim-nielsen.com/2020/react-without-build-tools/
- edmcnulty101 4y agoI think the article kind of explains it pretty well. It kind of returns to the original intention of the web.
- Starlevel001 4y agoWeb devs have zero right to run their javascript disasters on my computer. Htmx outsources 99% of the rendering and logic to the server, where it can use up their valuable time.
- ng12 4y agoWhy stop there? They should get their own end users as well.
- n0us 4y agoIf you hate it so much just turn off JavaScript and enjoy waiting for the page to reload every time you click on anything
- andybak 4y agoWhich is often faster than the response time of a client side app.
- DangitBobby 4y agoGreat! Enjoy it!
- tshaddox 4y agoCan you further explain your principles around the web? I'm curious to hear more. For instance, it sounds like you don't think web sites ought to be able to distribute JavaScript which executes on your computer in order to generate a user interface, but it seems you do think web devs have the right to utilize your internet bandwidth to download markup from a server in order to generate a user interface. Is that the case, and if so, why do you make that distinction?
- zakki 4y agoMaybe GP wants to access the information and not the unnecessary local processing? Edit: wording
- 4y ago
- simonw 4y agoIt's faster. React apps often load hundreds of KBs - if not MBs - of code before they start to work. HTMX loads 10KB (gzipped).
- threatofrain 4y agoThen use Preact, Solid or its ilk. Then your bundle size is going to be a tiny fraction of the kinds of things users tend to like, such as images.
- tomnipotent 4y agoDoesn't really matter unless you're targeting low-bandwidth customers. The Amazon homepage is ~4MB, and an average user session is going to downloading many times that in additional images and markup while browsing. In that context, React or other JS files will be single-digit percentage of what was downloaded.
- deleted 4y ago[deleted]
- recursivedoubts 4y agoOne big advantage is simplicity: you eliminate the need for a lot of client side technology, such as routing, and push everything back to the server. Also, by eliminating application javascript, it allows you to spend more time in your preferred language on the back end. The downside is the same as regular HTML, although less pronounced: since you are driving application state through hypermedia (HATEOAS), the less coarse-grained your state or UI gets the more annoying things are going to be. There are some patterns that help but eventually, if you want to update 12 different places in your UI at once on every keystroke, the hypermedia approach just isn't going to cut it.
- amelius 4y ago> Also, by eliminating application javascript, it allows you to spend more time in your preferred language on the back end. But these days (using transpilers and/or WebAssembly) you can choose just about any language on the front-end ...
- recursivedoubts 4y agoThat's true and, in the case of pyscript in particular, may limit the appeal of something like htmx. On the other hand, the simplicity of the hypermedia approach, and the flexibility of ReST are still there. We'll see.
- noidexe 4y agoThe idea is that the js is used to implement the functionality that the author believes should be built-in. In theory you could have a browser plugin/extension for handling htmx and it would work across every site using htmx. You app-specific "code" is all declarative, just extra properties in your html tags. With most frontend frameworks, even if the browser came with built in support for Vue, React or whatever, you'd still tons of imperative js for each single webapp to define how it uses the framework. Imagine not having html at all. You'd have to create pages from scratch imperatively by doing things like let element = createElement("p"); element.setContent("my paragraph"); parent.addChild(element); It'd be really ugly, a PITA to change stuff and error-prone. htmx is the opposite of that. It tries to make web development declarative again, among other things.
- felipeccastro 4y agoThe main advantage I see of traditional server side rendering (like in Rails/Django) is that you develop a single project, not two (SPA + API). Instead of api models and client models, you just have models. Instead of api routes and client routes, you just have routes. Instead of unit testing api and client, you test one project. Instead of having the client making N requests to load all the data it needs from the server (and being careful not to return more data than you need for performance reasons), you return an html with all the data it needs in a single request, and nothing more. In the case of client stacks using SSR (like Next/Nuxt): Instead of running the SPA on the server so the server returns the html rendered, you just make the server return the html rendered. The benefit to the developer is higher productivity. The benefit to the end user should follow from that.
- jeeep 4y agoThe tight coupling removes a lot of scalability possibilities though. I understand the higher productivity argument, but wouldn't it be time consuming on the long run to lock yourself in an environment where you would have to go back and build an API if you want to extend your web app to mobile for example?
- felipeccastro 4y agoIt depends on the needs of the mobile version. Often, a well designed responsive version of the same web app is enough. Even if it's a mobile native app, you might still be able to reuse some/most of the screens with the same html in a webview. Even if you really needed it to be an API, you can always make the server side return either html or json depending on some request header. There's also a chance that the mobile version will be different enough from the desktop that it warrants new, custom built endpoints anyway.
- drchaim 4y agoI've been trying htmx and the results are great. So much simpler to code than with SPA. My only concern is about those datetime pickers and other type of "components" that is easy to get from a react/vue ecosystem but much harder in a vanilla Javascript way. Not saying it's impossible, but a bit harder to find decent maintain libraries/components for those kind of web interactions.
- Scarbutt 4y agoI haven't use it but my understanding is that htmx is normally paired with something like alpinejs for which there existes date picker components.
- S34RZrXNZoeemHj 4y ago<input type="date"> Why would you need JS at all for a date picker?!
- sergiotapia 4y agoI am totally with you. Unfortunately firefox as usual cocks it up for the rest of us.
- phil-martin 4y agoBecause the built in date pickers (and other editors) don't always fit the requirements? A couple of things I had to handle in the last couple of weeks: - Handling different separators for input - having a clear button to indicate "no date" - display the date in a different format
- dham 4y agoYea, would have been nice if the W3C actually gave us usable components, but hey you can connect your MIDI keyboard to the browser.
- jaredcwhite 4y agoI would focus less on "vanilla JavaScript" as the ecosystem from which good components will arise and focus more on web components (which, generally speaking, are vanilla JavaScript). There is a thriving and growing sector of the frontend space where web components and WC-based design systems are coming to the forefront. Shoelace is a fantastic library in this vein. Libraries like htmx, Alpine, Turbo, etc. benefit greatly from web components.
- daotoad 4y agoI'm pretty sure I've said this on previous mentions of htmx, but I'll say it again: this reminds me of the old SPF framework youtube published. http://youtube.github.io/spfjs/ http://youtube.github.io/spfjs/ SPF was a bit more focused on being easy to merge into an existing server side app. I am glad to see this and hope it has some legs. It could help free us from the need to write every UI in JavaScript(ish).
- geenat 4y agoIt's a similar concept to Google's SPF. htmx is more light weight, and very actively maintained.
- no_wizard 4y agothis of course, is really meant for brochure or light interactivity sites. I don't think Figma should convert to htmx. I also don't think its meant for sites that may need to honestly scale as part of their product line heavy JavaScript interactivity. For instance, I've definitely worked at a place that deployed well over 10K components to production (I think we pushed over a million lines of deployed production code). React & Angular do scale this far, I have yet to encounter any who works with Vue that ships over a million lines of deployed code though I'd love to hear from you!
- sodapopcan 4y agoTo nitpick, Figma is not a good example as it’s essentially all Canvas.
- recursivedoubts 4y agoI don't think that "scale" is the right axis, but rather the amount of interdependence in your UI. htmx would probably work great for something like GMail, but would be a bad choice for something like Google Sheets. Both are big apps, but one is more amenable to coarse grain HTTP requests because the UI isn't as interdependent.
- vindarel 4y ago> Sheets Interestingly, I have seen a new app that provides a sheet with HTMX: https://www.licenseprompt.com/ https://www.licenseprompt.com/ (gif: https://twitter.com/WimpieNortje/status/1520419150245638144 https://twitter.com/WimpieNortje/status/1520419150245638144)
- recursivedoubts 4y agoYep, but the total dependency area there is relatively small and focused. Compare with something like a general spreadsheet, with any number of cells that need updating based on formulas entered in them. That's just not an application that is going to be amenable to a hypermedia approach.
- 4y ago
- jdthedisciple 4y agoNaive question but how would styling be handled actually? If the server just returns plain html tags with content in it ... I mean, I don't quite get it
- listenallyall 4y agoUsually, the server returns plain HTML tags with Tailwind-enabled 'class' attributes.
- jaredcwhite 4y agoI don't understand why you mentioned Tailwind. Nothing about htmx requires a utility class framework AFAIK.
- quickthrower2 4y agoI think it is snark. The implication is that if he just said “use css classes” in 2022 it wouldn’t be understood by “cool kids” so tailwind is mentioned to clarify what a css class is.
- listenallyall 4y agoHuh? Wasn't meant to be 'snarky' at all. Sure you can use plain CSS classes but Tailwind is immensely popular. Htmx + alpine + tailwind is a fast-growing front-end stack, for good reason. Use it or don't use it, whatever. (the last sentence is snark)
- quickthrower2 4y agoSorry! I guessed wrong
- listenallyall 4y agoBecause the guy asked about styling and Tailwind is by far the most popular CSS styling toolkit. Never said it was "required," just common.
- recursivedoubts 4y agoI am the author of this article. Happy to answer questions. I know my alternative approach, htmx-enhanced hypermedia, isn't right for every application, but it can be a much simpler approach for many applications, and, since it is so simple, can be used to conserve complexity in applications that have parts that are not amenable to the hypermedia approach.
- encryptluks2 4y ago
- recursivedoubts 4y agoSPA means "Single Page Application", I don't spend much time defining it but defer to Tom Wright's definition, about which he says: > The SPA pattern (Single-Page Apps), I tried to define, was about the React model, which also covers, to a large extent, the model of Vue, Angular, and other frontend frameworks. I created an alternative to AngularJS, Meteor, Knockout and Ember.js back in 2013 called intercooler.js. It used hypermedia as the communication mechanism with the server, rather than JSON. I wrote the library in JavaScript because that's what was there. In 2020 I rewrote the library to eliminate the jQuery dependency and clean it up and renamed it to htmx, since I had figured out that it was a generalization of HTML as a hypertext. I think that's a pretty good summary of what happened.
- woojoo666 4y agoThis reads like more of an attack than a question. Even though I prefer React over HTMX, I think the difference is pretty clear, as well as the intention of this article. In particular, this quote from the article is most relevant > In HTML-Centric Development, rather than being an afterthought, HTML is embraced as the primary medium of application development. This is in contrast to most SPA frameworks, where a client-side model & the javascript that manipulates it is the central focus. If you read the authors other post about REST [1], they also talk about how most SPAs communicates with the server via JSON, whereas HTMX uses HTML. This is also part of the HTML centric design. You embed the fetching logic into the HTML, and the server returns HTML directly, so there's less work done on the client, in constrast to most SPA frameworks. [1]: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
- kulor 4y agoI’ve found this library a delight. Coupled with a sprinkling of Alpinejs to cover more advanced interactions and Django-livereload, I feel progressive enhancement has a renascence opportunity
- newbieuser 4y ago
- andybak 4y agoPeople post it and other people upvote it? I've seen this before but I enjoyed the other article and it was new to me
- recursivedoubts 4y agoI assure you, at this point, as much as you, I would like a break from the front page
- deleted 4y ago[deleted]
- rlawson 4y agoI have used htmx (and it's predecessor intercooler) on several occasions now. The real sweet spot is it allows you to push server side frameworks like Django even further. You may find you can skip the SPA all together. And nothing beats the speed of development of a Django/Rails/Laravel. Htmx is part of my go to stack for solo/side projects and my preferred stack on the job for crud heavy line of business applications.
- likortera 4y agoSame here, except I use Unpoly for all my side projects.
- quickthrower2 4y agoHas anyone got battle stories from using HTMX it similar? I there a time you regretted it a little and wished you had chosen React? Or is it pretty rosy?
- phil-martin 4y agoI've used it a fair bit in a equipment finance app I have built for a small company. In the system I've used a mix of regular django templates, some Django unicorn, some HTMX, and some HTMX+Alpinejs I pick the tool based on the the amount of interactivity I need on the page. It's.... interesting. If you start out knowing you will do HTMX, then I found everything is much easier. Splitting off small small views to return just the right html after a hx-post is more labor intenstive than i would like, bit overall it's nice. The hardest part I found was being able to have a fine level of control around the user experience, and solving that required adding a lot of javascript, which made me wonder if it was worth the effort and should have instead just used Vue to handle it. I've ended up using a lot of HX-Refresh in responses (causes a page refresh) because it was easier to do that than to ensure all the different parts of the page updated at the right time. The way it cascades htmx values down the tree is really handy, and lends itself to consise attributes on the html. Overall I'd give it a silver-coated bullet rating. Certainly not a solid silver bullet. :)
- infamia 4y ago> It's.... interesting. If you start out knowing you will do HTMX, then I found everything is much easier. Splitting off small small views to return just the right html after a hx-post is more labor intenstive than i would like, bit overall it's nice. This was almost exactly my first impression of HTMX as well. It's a huge step forward! However, for my tastes it demands too many tiny views and micromanaging, which somewhat felt like a drag on my productivity. For an alternative, take a look at Unpoly [1] which has more batteries included (i.e. create layers of interactivity that update lower layers automatically) and is centered around full page requests/diffs and less focused on injecting small page fragments everywhere. For my small apps, I could do everything in one view that took three or more views with HTMX. I can only imagine the views exploding for a modestly complex site. The biggest penalty for Unpoly is that it is quite a bit (~2X) slower than HTMX, which needs to be kept in mind and managed for larger pages with a lot of interactivity. I suspect this is because Unpoly loads the entire page and does a DOM diff to see what it needs to update, as opposed to injecting just a page fragment. In my tests, I was able to manage around this issue using layers. The big upside to Unpoly is that the full page refresh architecture aligns very neatly with Django's request/response cycle, which gives you pretty seamless interactivity and form validation. It also has a lot of batteries included that HTMX lacks. I think HTMX is terrific and revolutionary, but Unpoly fits my brain better while doing Django development. [1] https://unpoly.com/tutorial https://unpoly.com/tutorial
- noidexe 4y agoFor me this feels like finally jumping back to the good timeline. From the user point of view, I think there are two main types of experiences on the Web: a ) Interactive documents. Basically web 1.0 but today we want fancier transitions and interactions. This can be provided by htmx and should always have been developed declaratively. It should ideally be provided by the browser and htmx shouldn't need to exist. Examples of this are Gmail and most social networks and forums including this one. b) Desktop apps-but-I-don't-want-to-have-to-install-them. This would be things like Google Docs, Photopea and most real-time games. To deliver this, right now we have a browser that has become almost an OS inside an OS, to the point only Google can keep up with the complexity. On top of that, we pretend apps are documents and for all the imperative code we need we use a scripting language that was not meant for that, and we need a really complex VM just to keep it more or less performant. For this use case I think at some point we should move all the way into just delivering apps, if not native apps, something like wasm, where the browser tab would just be a vm player.
- toddmorey 4y agoI agree generally with the two types of experiences, but I'd also submit that there's no easy, clear deliniating line and it's much more of a spectrum between the two types. I really think some of the quirky magic of the web comes from this doc / app hybrid thing it supports and bifurcating them fully would be a mistake. Rich Harris speaks towards that here: https://www.youtube.com/watch?v=860d8usGC0o https://www.youtube.com/watch?v=860d8usGC0o
- ordinaryradical 4y agoI think the spectrum is the right mental model, too. E-commerce stores have different interactivity needs than blogs, which have different needs than documentation, which has different needs than dashboards, which have different needs than real-time collaboration tools, and on and on and on. Much of the framework angst is around the assumption of a singular tool for all these varieties of interaction and the annoyance that comes with not acknowledging the trade-offs. Plus the web itself is changing, so the breadth of this spectrum is increasing. Years ago, the ends might not have been very far apart but they are diverging more with each new use-case and app idea.
- hencq 4y agoI really love the idea of htmx and will definitely use it for my next hobby project. Out of curiosity, does htmx only work for always online apps or could you build a PWA with offline capability with it as well?
- mixmastamyk 4y agoSeems focused on a backend service, but you may be able to fake it.
- jasongi 4y agoI have noticed that there is a dogmatic element to a lot proponents of these libraries which leaves a sour taste in my mouth. Occasionally you get a head nod in the direction that “sometimes, React is the best tool” but most of the time it’s Simpsons memes stoking a culture war. If you’ve worked in an org where someone with decision making power has drunk the “progressive enhancement not SPA” koolaid, then it’s just as bad as someone who has drunken the SPA always koolaid - at least you’ll find it easy to hire and find support/libraries with the latter.
- wrnr 4y agoThis happens a lot mathematicians might have their favourite object they study like Category theory and then get hung up on categories of categories but might forget that many simple things aren't categories like the prime numbers under addition because 2 + 2 = 4 and that is not prime. Not just programming or math, in physiology you have entire research groups worked up about a molecule that causes dementia and after decades of research realise that the story was a lot more complicated than that. You can almost recognise a healthy mind by the lack of such dogma, just don't make it a rule that would defeat its purpose.
- silviogutierrez 4y agoI'm the creator of Reactivated[1] and fully agree with a lot of the aversion to SPAs [2] and REST [3][4] But to me, writing my markup in JSX (really, TSX with TypeScript) and using scoped CSS solutions was too good to pass up. I just couldn't bear writing text-based templates. That's why I built Reactivated: combining the best of both worlds. Server-rendered, simple markup — albeit still in TypeScript — but you can add interactivity as needed. Of course, HTMX is far less opinionated and framework-agnostic. So it can be used with any number of libraries / stacks. [1] https://www.reactivated.io https://www.reactivated.io [2] https://www.reactivated.io/documentation/philosophy-goals/#traditional-serverrendered-views-work-well https://www.reactivated.io/documentation/philosophy-goals/#t... [3] https://www.reactivated.io/documentation/philosophy-goals/#rest-is-not-the-way-not-always-practically-never https://www.reactivated.io/documentation/philosophy-goals/#r... [4] https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
- zagrebian 4y agoWhen was this published?
- NorwegianDude 4y agoI have been doing something similar where a js file takes over links and forms and uses fetch to get content and some other data on navigation. Great TTFB as I don't need to send it to node to render js, faster navigation for many users with slow plugins and easy to implement. This seems to do the same thing, and much more. I really need to try htmx, looks cool!
- jmull 4y agoHere's the "motivation" for htmx, from it's main page: Why should only <a> and <form> be able to make HTTP requests? Why should only click & submit events trigger them? Why should only GET & POST methods be available? Why should you only be able to replace the entire screen? By removing these arbitrary constraints, htmx completes HTML as a hypertext I think the first three items are minor issues, at best, which in no way justify yet another DSL. The fourth is a reasonable point -- it's quite common that you only want to update a portion of a page. But it's very unclear that HTTP requests are the way to do it. For one thing, using HTTP requests as the transport for app event handling adds nothing conceptually. It seems nice to use something that people are widely familiar with to build an event model on top of, but HTTP isn't a good fit for everything. So you either need something else (javascript or another language/api/framework) or you awkwardly fit everything into this model anyway. But more importantly, it implies a strongly hierarchical structure to your app UI, which I think is overly rigid and unrealistic. Content tends to be largely hierarchical, but frequently important cross-cutting concerns pop up... maybe not on day one, but maybe on day 100 or 1000. Now you're swimming upstream. Also, it's not like there aren't a very high number of HTML-centric options available. It has an interesting low-level approach, but in the end we're developing apps and UIs. It's very unclear to me whether htmx really offers advantages that other approaches don't meet or exceed.
- mamcx 4y ago> It's very unclear to me whether htmx really offers advantages that other approaches don't meet or exceed. You say what is the advantage before :) : > ... maybe not on day one, but maybe on day 100 or 1000. That is the thing. Is Wonderfull when you actually wait and see if you truly need the extra complexity of things. Go nuts when is time to go nuts. But is nuts to do it now.
- soruly 4y agoI think Turbolinks is a nice balace bewteen traditional webpage and SPA. https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks It provides a smooth UX by fetching next page's HTML in background, then replace the DOM by compareing the diff in HTML. So you won't see a blank page while navigating between pages.
- jasongi 4y agoTurbolinks is one of those things that seems revolutionary to begin with, until you need to start implementing hacks in your server in order to deal with edge cases. Things I remember from the last time I had to deal with these libraries were redirects and hard-to-debug JavaScript issues due to so much JavaScript relying on document ready/onload events.
- barking_biscuit 4y agohttps://hotwired.dev/ https://hotwired.dev/ They turned Turbolinks and extended it into a complete framework. I really want to give it a try.
- danbulant 4y agoKind of reminds me of sveltekit. For example, I hate writing the same HTML repeatedly, so I just used svelte for it's components and made a fully static, JS-less page. That later evolved and left out the JS-less (some fancy effects, dialogs, cross-page transitions etc), but even for building static pages seems far better than writing normal HTML, when those pages become a bit complex.
- calderwoodra 4y agoWhat are the pain points developers have with SPAs? I've been working on a nextjs/react/tailwindcss project for 5 months full-time now and I honestly love it. It's been very intuitive and straightforward to get things done.
- ravenstine 4y agoThere are no pain points with SPAs that can't be had in any other kind of web app architecture. Most of the problems we run into are ones we create for ourselves. Writing jQuery splatter got tiring, so we moved everything to the frontend. Then we got tired of our 300+ line Webpack configs, so now the old days of server rendered HTML is where the grass looks green. Inevitably, we will get tired of all the hacks we have to do to work around the shortcomings of HTMX/LiveView/Hotwire and move on to something else. What tires me is the groupthink around web development. SPAs and server rendered content aren't better than one another. It's annoying and unreasonable that the current trend is that SPAs are bad. They are not. Everything bad with SPAs I've seen is caused by developers not getting their priorities straight and by bandwagoning. Stop making webpages complicated and you'll find that many problems disappear.
- tr1ll10nb1ll 4y agoOne of my apps built on the Django+HTMX stack got traction and no matter how much I loved using HTMX, I found it’s not feasible to keep a clean codebase (facilitating new developers on the team as well) with this stack. [Tetra](https://www.tetraframework.com/ https://www.tetraframework.com/) might be an alternative if you’re hell-bent on not using React. But, if you want to ship quick, have a maintainable codebase in a technology a lot of devs are familiar with and have the power to instantly ship for mobile (and buy yourself some time to build one in React Native; code is going to be similar to React.js), I’d recommend using React. You can use Capacitor.js for instantly shipping a mobile app with your codebase that “just works”. Use Capgo for affordable codepush and you’re set! HTMX all the way if you’re not building an app cause not everything is an “app”. At the same time, if you’re building an app with a framework unlike Phoenix, I don’t see why one would not go ahead and use a decent JS framework. Using frontend framework seems to be facing a lot of aversion and I don’t understand if it’s because of the inability to learn these frameworks or what. Point is, your users just need a snappy app that works. That’s it! And using a robust frontend framework makes it easier.