> 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.
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.