> 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.
Often 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.
If 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.
Hiring 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.
> 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.
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.
100% - 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.
That'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.
There 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.
You 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.
In 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.
Impersonating 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.
I 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.
I'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.
most 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...
Because 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.
In 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.
Django 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.
> 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
Yes, for me batteries included is starting with your problem and not before the problem. I expect in 2024 to have a Visual Basic 6 for the Web (drag and drop UI/UX and objects behavior) and all I have is MFC [1].
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.
And that is why Laravel is maybe the most complete web framework currently. Breeze and Jetstream which are both first party starter kits, adds all of this for you in less that 10 seconds.
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.
That'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.
As 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.
Django 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.
Can’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.
There 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.
Unpoly 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.
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.
The 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.
> 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/. 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.
Do you wanna upvotes here? Better think about how to convince people that having a server serving every request is good. It's impossible to do that without some strong Steve Jobs reality distortion field. Well I can empathize with them, think about how tedious it is to work for big techs without refactoring useless products with the useless new framework
HTMX doesn't require Django - you can use it with any web framework you like. And server side rendering should be fundamental knowledge that anybody working in the web-space should understand.
> HTMX doesn't require Django - you can use it with any web framework you like
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.
I'm really not sure why you keep comparing React to Django? My original point was that HTMX is easier to learn than React.
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.
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.