Building a SaaS product with Htmx – Are you sure you need all the complexity?
chatterpulseai.com
chatterpulseai.com
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.
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.
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.
Just compare the npm trends of react and $coolthing, then look at the number or active committers and the maintainer succession planning.
At least based on the article's description of the app, I don't think 5 years down the road is really the concern. They're building an LLM tool that leans heavily on real-time natural language processing. The last concern they'd likely have over the next 5 years is whether they can hire frontend or fullstack devs for the current codebase.
Between the odds that frontend development changes in the next 5 years and the odds that this service fundamentally changes either at the product or architecture level, hiring devs in 5 years really should be the last of their concerns.
Awhile back on another HN discussion about htmx someone commented it seems easier to learn a framework than to learn htmx.
Having already built a prototype in htmx I tried Angular and found it much quicker to learn and be productive.
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.
Also you're describing database queries and architecture as being a potential issue. Won't APIs be just as slow for the same reasons?
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.
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.
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.
HTMX and the hypermedia philosophy asks you to reconsider whether you need the complexity ever, even at scale.
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.
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.
Additionally, in the Python ecosystem your other options are basically flask and fastapi, which are definitely not any form of batteries included.
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.
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.
My experience as a casual developer in several programming languages and operating systems (macOS, Windows, Linux...) is that nowadays software development is for teams and not for individuals but it is not a software engineering problem but a community one because the technology we have available is really incredible but you can waste your time with relatively simple problems.
[1] https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Lib...
But it does: https://docs.djangoproject.com/en/5.0/topics/auth/default/#m...
Basically if you seriously want to run an online saas business, not using Laravel is like choosing Java over Python back when pg wrote the famous essay.
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.
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/. 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.
I agree, but that wasn't the point I was making. My point was to question why a simpler build system should be the deciding factor for your tech stack. You could've used Go for your backend if that was the case. But you chose Django because it offers an ecosystem of tools. So does React.
> server side rendering should be fundamental knowledge that anybody working in the web-space should understand.
I'd invite you to question why that's the case. This "X should know Y even if few actually use it" type of thinking is very prevalent in the developer community.
As for your second point, I think I must be missing something or misunderstanding where you're coming from. It seems fairly fundamental that developers should understand that web servers can render web pages. Even the JSON files that flow into React applications are rendered on a server and served with a web server.