8 ms·
Building a SaaS product with Htmx – Are you sure you need all the complexity?
- chasd00 2y agoI thought you used htmx when complexity was already too high and you wanted to simplify…
- LikeAnElephant 2y ago> Axiom 2: You’re optimizing over a business, not over a codebase. Well said. Ultimately I think this is where much of the communication breakdown occurs when discussing Framework A vs Framework B online. If you’re optimizing for _code_, sure. Stress about the ms it takes to load this or that thing. Client vs server. All of it is valid discussion from an engineering standpoint. Go nuts! If you’re optimizing for _business_, then choose something that gets the job done. Fewer moving parts - and fewer resources needed to maintain it - the better.
- dewey 2y agoIf you are optimizing for business optimize for something that you can easily hire people for that want to work on it. That internal Angular based tool might work fine and doesn’t need much maintenance, but hiring someone for it that’s not an expensive consultant might be hard. Same for htmx, it might get the job done but in 5 years maybe it’s hard to find people to work on your niche framework code base.
- tanner49 2y agoHiring is one part of a business, but I don't know if I agree with this, mainly because learning HTMX is so darn easy. You are essentially offloading much of the business logic to other parts of the stack. So, in my case, if I'm lucky enough to be hiring employees to work on this project, I'd likely be looking for backend django experts or true "front-end" devs with expertise in styling and limited client-side JS.
- yodon 2y ago100% - React has won the FrontEnd wars. Anything else is great to love and to use in a hobby project, but if it's for a business, React is the one FrontEnd tech you can be confident people will still be using heavily in ten years. Just compare the npm trends of react and $coolthing, then look at the number or active committers and the maintainer succession planning.
- camdenreslink 2y agoThere are still a lot of companies using Angular and Vue. Especially some big institutions that started using AngularJS (pre-"Angular") years before React was really popular.
- wordofx 2y agoReact won worst front end framework that somehow got popular and brainwashed people into creating a mess to double down on.
- _heimdall 2y agoYou know that won't last forever though, right? React will be replaced by another technology eventually, and in the web development world 5 years from now is 2-3 tech generations down the road.
- bigtunacan 2y agoThat's what they said about the original Angular framework and Backbone before it. In another 10 years React will just be another legacy front-end framework that some poor asshole will get stuck maintaining.
- threecheese 2y agoOften this goes in the “other direction”; many corporate software projects start with a large team and, based on success or shifting business priorities, can go between Modernize —> Invest —> Maintain —> Goodbye in unexpected time frames. It is very difficult to optimize for those future states, especially with go-live time pressure across many teams - abstraction is a strong tool for managing Conway, and those big frameworks do it well. Nobody wants to think their team won’t grow, we’re all building The Next Big Thing in our minds.
- mildred593 2y agoI'm not surprised at the powers of htmx. I have been doing single page apps (or close to) using Rails + Hotwire (Stimulus/Turbo) and it works really well.
- safwen 2y agomost things work (better) on the server. makes sense to shift back there. React served a purpose, making the web feel more interactive in the early 2010s, but it's not an all in one solution. moreover, the web is just a frankenstein...
- deleted 2y ago[deleted]
- rcaught 2y agoComplexity breeds complexity
- andrewstuart 2y agoI am willing to be convinced about HTMx mainly because the whole internet is blathering about how great it is. I have just started looking into it. BUT - the suggestion seems to be that it makes easy things easy and after that we'll you need to reach for more powerful tools. So why would I not just use the power tools for everything and reduce the number of technologies in use therefore making the whole thing less complex.
- tanner49 2y agoI think the argument in addition to "makes easy things easy" is "and most things are much easier than you think." HTMX and the hypermedia philosophy asks you to reconsider whether you need the complexity ever, even at scale.
- deleted 2y ago[deleted]
- slyall 2y agoBecause you don't need to deploy those more complex technologies until you scale and have the money to hire an expert. It's Like building your SaaS to run with a single server and database at the start. When you get a million users and the old infra won't scale you can move it to kubernetes and DB clusters. But no point doing that till you need it.
- andrewstuart 2y agoDjango isn't batteries included despite everyone saying it is. Batteries included would mean inclusion of the most basic requirement of almost every web application - some sort of user signup/signin/forgot password auth and cookie/token flow. Django does not include anything for this and leaves it to the user to work out - and this tends to be one of the most complex parts of a new system.
- tanner49 2y agoThat's a fair critique. I would say that the Django ecosystem is fairly batteries included though. I used the django-allauth package for this project and it filled in those gaps. Additionally, in the Python ecosystem your other options are basically flask and fastapi, which are definitely not any form of batteries included.
- sroerick 2y agoAs a guy who has had a 8 year career largely in Django, I generally agree with this sentiment. Even though I prefer and am probably much more functional with Django + htmx, my sense is that for general web applications both Rails and Laravel are generally more functional ecosystems. Most of my Django work has been pretty data heavy or geospatial heavy, in which case I think python and/or geodjango are a great solution. In general, however, if I had a trajectory for more traditional web apps, I’d probably use Rails.
- scrapcode 2y agoRails was fun but combined with the uniqueness of Ruby, RoR always felt a little "too magic" for me.
- andrewstuart 2y agoDjango people always say this "All you need to do is install this user management lib you're done". There's at least 10 sophisticated steps to install and configure a user management system for Django and for beginners seeking genuine batteries included they'll have no idea if they are doing it right or wrong, ending up at best with problems and at worst a misconfigured auth system. Django really should not be recommended to beginners, it's for sophisticated Python devs.
- skywhopper 2y agoCan’t read the article right now, getting a server error. But the SaaS company I work for is working on htmx for our next release. It’s actually made things incredibly simple. Not to mention speedy on the client side. No need for a heavy JS layer. Keep your rendering on the server where it can actually be fast.
- tanner49 2y agoYeah.... got the website up an running a week ago on Heroku and made this post. And what do you know, hacker news crashed it!!
- tanner49 2y agoGuess I should upgrade from the hobby postgress tier....
- chrisco255 2y agoIsn't this an unintentional argument for static, client-side rendering?
- tanner49 2y agoHa no. No htmx here. Just me being dumb with Heroku.
- meiraleal 2y agoAnd people still arguing that having a server process every request is a good idea
- BalinKing 2y agoIn case dang sees this: The title here on HN doesn't match the original title of the article, and (to me at least) it now gives the opposite impression as what the article is saying.
- tanner49 2y agoHa you're right. My bad (poster). I didn't realize until right now that it kid of implies the opposite. Sorry about that!
- airtonix 2y ago[dead]
- _heimdall 2y agoIn my experience, the most frequently missed benefit of HTMX, and server rendering in general, is that you actually control the hardware your frontend is rendered on. If and when you find performance issues in production you can much more easily reproduce and fix it when conversion from data to HTML is done on a server and infrastructure that you own. Trying to track down render performance issues with client side rendering is a huge pain that more often then not leads to a bug being chalked up to "can't reproduce" or blaming the user's device/browser/network. Tracking down rendering performance issues with server rendering almost always leads to optimizing database queries or reworking your internal infrastructure.
- winrid 2y agoHmm. But if you can impersonate users and see what they see, doesn't that let you see the problem? Also you're describing database queries and architecture as being a potential issue. Won't APIs be just as slow for the same reasons?
- wordofx 2y agoNo because you’re not using their computer to reproduce the issue.
- winrid 2y agoI found keeping an old machine or two around is enough. Old laptops are pretty much free. Generally frontend performance problems are easy to diagnose, easy enough that that's not a consideration when architecting an app in most cases. If your React UI is taking 30% of your dev PC CPU then that's pretty obvious that it's gonna be slow on an average laptop from Walmart with a 5k passmark score.
- _heimdall 2y agoImpersonating users only gives you their data, with client rendering you may need their device and network conditions to reproduce a bug. If the bug is in an API you're really just tracking down an issue in your server rendering. When an issue is in client rendering it's after the API response. It could be anything from a network delay that times out some client logic to a corner case that causes a re-render loop or a specific JS performance difference on a specific device with a specific browser version. My point is just that you don't own the actual hardware or network when rendering UI on the client. That's not to say you should never use client rendering, it is a good fit for some use cases, but I've always found debugging rendering or performance bugs a huge pain compared to server rendering.
- est 2y agooff topic, is there any UI framework like htmx where you don't need a huge pile of npm to work with? Is bootstrap still the go-to option?
- tanner49 2y agoThere are a ton. Go on the HTMX subreddit and there is a question basically every week talking about some new styling framework. I'm not an expert but you will find something there for sure.
- LaundroMat 2y agoUnpoly needs no npm and I'm trying it out with Django for a rewrite of a Django+Vue app. I'm very happy with the results as it forces me to keep the business logic in the back-end, which speeds up development dramatically.
- deleted 2y ago[deleted]
- mmarian 2y ago> <div hx-get="/poll_content_chunks?last_chunk_id={{chunk_id}}&session_id={{session_id}}&type={{chunk_type}}" hx-trigger="every 5s once" hx-swap="outerHTML settle:1s"> I'll probably be downvoted but this code shows why I'm put off by htmx. The belief that just because you write the least amount of code, it always means that it's the simplest solution. To me, that's a lot harder to understand than if I used React. Having tried both, I found the learning curve pretty much the same.
- amanzi 2y agoThe difference, is that with HTMX, the above line and the HTMX JavaScript file is all you need. There is no separate build systems, or mess of dependencies, or anything like that. You just link to the HTMX JS file, and you're away. I think it's fair to say the HTMX learning curve is significantly different to React.
- mmarian 2y ago> no separate build systems, or mess of dependencies Why is that necessarily a bad thing? Django's build system is atrocious too; eg there's no consensus around what web server you should use https://docs.djangoproject.com/en/5.0/howto/deployment/ https://docs.djangoproject.com/en/5.0/howto/deployment/. Yet that doesn't prevent you from using the framework. > I think it's fair to say the HTMX learning curve is significantly Agree to disagree I'm afraid. It's not just the fact that you have to learn HTMX, but also how to work with SSR. And of course, I got downvoted :). Which is a shame because it discourages me from spending time explaining an alternative view in the hopes that I could help.
- Fire-Dragon-DoL 2y agoI agree on the idea but... What if i want offline app support? Some apps are used in areas where network might be available