I don't get it. I assume the author is trying to make it sound absurd that you would need all these layers of factories to build a simple spice rack and, by analogy, that frameworks are also absurd.
But if you were building spice racks at scale, of course you would build them in a factory! And you'd use machinery made in other factories. And those factories would have tools and machines made in yet other factories.
That's why you can go to Amazon or Wayfair or the Container Store and find 100 different spice racks for less than $30, and why nobody builds a spice rack by hand, except for fun.
That's a mistake. Imagine you're instead a carpenter.
You're being called up because the problem is specialized.
Now as a carpenter, you go to the container store and then go back to your shop to dismantle prebuilt products and glue a bunch of different pieces from different containers together and present the Frankenstein cabinet as the product back to the customer. Also, you're on the hook for maintaining it.
Is it faster then just doing it yourself? Higher quality? Cheaper? Maybe...
Competency is the key skill here - someone could claim they're competent in both the NIH and framework way and they choose frameworks because of their vast power of assessments but statistically speaking, they're probably just choosing the frameworks because they lack the competency to DIY and are Dunning Krugering themselves.
A lot of this depends on the types of jobs you decide to take on. The boring ones are pretty easy to do with frameworks but the interesting ones are wildly unclear whether you're saving or wasting time by choosing one path over another especially if you're interested in the product's reliability and longevity.
The amalgamation of frameworks approach makes long term upgrading somewhere between very expensive and impossible. Dependencies, schemas, templating, test syntax can all change in totally incompatible ways as your version gets abandoned and you get locked in to whatever was hot 10 years ago. So much for security patches.
Eventually you'll end up forking the dependencies you once used to save you time and then patch them yourself - code ages way quicker with (most) frameworks.
Unfortunately this is true, as I grew more experienced I’m very careful with the dependencies I add to a project. I don’t work with React Native but I hear horror stories of how the hundreds of dependencies force you to either stick to the old versions of stuff or keep fixing or rewriting things that used to work. Seems totally unsuitable for a side project you want minimal maintenance over time.
If “hello world” is the whole requirement behind an app, and you won't develop it further, you don't heed to use react. In fact, here's your whole app: “hello, world!”. Copy it, save it in .txt file, serve in static anywhere you want.
I wish more people would actually follow this advice. When they don't need anything "reactive" they would not use React. When they don't actually need an SPA, they would not use React. When they don't actually need dynamic behavior on a website, they would not use React or JS.
But unfortunately people use what they don't need all the time, rather following hype than reason.
Or, may be, they use the tool they're familiar with, because what they need is to be productive immediately instead of wasting their time to learn different tooling. Even if this different tooling is simpler that what your already know.
Right but the earlier you catch your mistake the more time you'll save in total.
Generally people use 10x on cost at every subsequent step. Andy Grove famously talked about how this made the FDIV pentium bug cost Intel untold millions instead of pennies.
He said when the mistakes and decisions seemed free early on, that's actually when they were the most expensive.
As more commitments were made towards the design, it became costlier to back out. Then they discovered it after production and shipping, and by then it became so costly and famous people still remember it 30 years later.
To be more direct, if someone doesn't know how to do it right they Shouldn't Be Doing It. If someone can't fly a plane, they shouldn't be flying planes. If someone can't operate a construction crane, they shouldn't be operating one.
Same thing here. If they're doing it wrong because that's all they know, they are unqualified. They should not be given the responsibilities.
So that method of doing what you're familiar with is the cost of incompetency. Planes and cars crash under incompetent hands and software doesn't fare much better.
I'm a little bit confused. At first, we were talking about people using React for Hello World or similarly small and simple project, but here you're talking about making architecture decisions for huge projects?...
In context of a simple project: yes, React is not the best tool for the job if you look at project requirements. But also consider the fact that the bundle size and optimization might not be that important from business perspective, and project scope is very limited from time perspective. That's why using React might be the best choice: you're optimising for developer productivity on the short run.
However, the situation you are describing now is different. Not only project's business priorities are different, but also the scope is much larger. Which means that spending time on choosing tools and learning a new tool would tale a much smaller % of project's timeline, and thus it makes sense to spend a lot of time on that to potentially save a lot of time and improve other characteristics later on.
In other words, you don't do pre-production on hello world, but you do on something huge.
Who is going to maintain the React app in 3 years? Who is going to work with the various "repairments" made to get normal browser behavior back into a SPA? History, back button, forward button, bookmarkability, context menu (if modified). The original developer will have moved on to the next gig. Are you going to rebuild, or pay even more for the next developer with more experience, to subject themselves to work with this?
This is the hidden cost associated with such decisions. If you decide to make it an SPA, you are automatically opting in for paying wages of frontend devs for the next years and not only that, you are probably opting in for them to need longer time to get browser staples back working. Things like a navigation, that could be a rather simple <ul><li> construct, maybe 1 or 2 days of work for rendering simple HTML templates on the server, with some nice CSS styling, can suddenly take weeks to implement and adjust. Can the most likely little need for SPA justify this extra cost?
Usually you are also not only having one frontend developer, but multiple ones to pay, since you don't want all the knowledge in one hand only.
Take a good developer salary and this can easily get into the millions over the years.
> Who is going to maintain the React app in 3 years?
Uhm, developers? Using projects documentation?
> Who is going to work with the various "repairments" made to get normal browser behavior back into a SPA? History, back button, forward button, bookmarkability, context menu (if modified).
I never had to manually “repair” any of that. Most often you just don't need them. Why would you use a back button in an image editor or an IDE?
> The original developer will have moved on to the next gig.
Developer, singular? Are we taking about small projects here again?
> Are you going to rebuild, or pay even more for the next developer with more experience, to subject themselves to work with this?
In my personal experience, React projects were one of the nicest codebases to work with. I came to projects 2-4 years old, found great documentation, good architectural decisions, and was able to compete a ticket on the first day.
Overall, I think it’s a difference in experience. I build complex web applications. IDEs. User interfaces with complex, customisable data widgets updated in real time. People I talk with about web development are building 3d visualization platforms with C++ compiled to WebAssembly. Games. Image editors.
What your are talking about seem to be simple CRUD apps. I have built those with server-rendered templates, yes (here's a takehome for some company from a couple of years back: https://github.com/golergka/url-shortener).
However, a lot of apps _seem_ to be simple CRUD apps in the beginning, until you anticipate future features and other requirements that will force you to adopt a frontend framework all too late. Do you need a form with search over content from the server? You need a system to query data and cache the results. Update data in real time with websocket connection, while also allowing your user to edit it? You need a system to consolidate state. Save user's data in local storage? Also local state, but also schemas and migrations for when your app updates. Table of 100s of thousands units of data, which user should be able to filter, sort and edit, with updates from the server too? Don't even get me started. There's a lot of other examples I'm too lazy to type. Overall — you either adopt a proper frontend framework or try and implement it in “simple JS” and then spend much more time fighting a lot of subtle bugs that simply would not happen if you used proper abstractions and tools.
You mean the documentation that was never written, because the developer thought: "Ah but this is just the usual usage of the framework I am using. I don't need to write anything about that."
> I never had to manually “repair” any of that. Most often you just don't need them. Why would you use a back button in an image editor or an IDE?
Well, on most SPAs you would need them, because people build SPAs all the time without caring, whether they are actually building an app or are actually building a website. So what you get are things that would be a normal website, but implemented using SPA frameworks and then have broken browser functionality. An IDE or an image editor would probably be OK examples for SPA, but the reality unfortunately is very different.
> What your are talking about seem to be simple CRUD apps. I have built those with server-rendered templates, yes (here's a takehome for some company from a couple of years back: https://github.com/golergka/url-shortener).
Exactly! I am talking about the cases, when people take out the sledgehammer, where a screwdriver would have been appropriate.
Yea it’s nonsense. Factories are fantastic. If you want to do something as a hobby, sure don’t use the most advanced tools and do it by hand, but for everyone else especially professionals who are charging other people for their time and effort using the best possible tooling is essential.
In fact, if somebody didn’t use a common library or framework and instead “rolled their own” it’s downright irresponsible, obnoxiously egotistical and just creates a huge maintenance burden for whoever has to maintain it when you move on.
Take for example a crud app in ruby. If instead of using rails or another framework you instead “rolled your own” for one it would take you way longer for two it would never be as battle tested as the framework and lastly you are guaranteeing that whoever has to maintain it will need to learn the idiosyncrasies of your amazing implementation with zero outside help. It’s a recipe for disaster.
I use the same argument for IDEs versus fancy text editors like EMACS. Sure, you might prefer the specific keyboard shortcuts, but IDEs objectively make developers more productive through features like source code integration, debuggers, and refactoring capabilities.
Use whatever you like on your home projects, but at work you should be using whatever is most efficient.
And interestingly, your argument also falls apart in the same way as the framework argument. It might make the average developer more productive on an average project. But most projects are not average, and neither are most developers. Everyone has some unique combination of strengths, just like every project has special cases that don’t fit within the box of a framework.
A framework is great if you don’t know much about the domain and just want to get something together quickly. But if you’re working on anything novel, then eventually you’ll bump against the walls of the framework. Hopefully you designed the project in such a way that you can break out of the framework for these inevitable special cases.
And I like frameworks! I’ve used a few in various languages and think they do a good job organizing the code for the basic cases. But every professional project I’ve worked on has eventually been trapped by piling workarounds on top of the framework to make it work for some unsupported or complex case, or an inevitable architecture fail which the framework has not considered an escape hatch for.
Just like developers and their tools. I have an IDE and nvim at work. The IDE has a lot of power for major refactoring and hinting features, and it’s reasonable enough for an untrained dev.
But it is very slow for the other 99.8% of my job where I’m not doing a big “find and rename all instances”. I am usually wading through a large project and jumping between files to try to understand a complex system. Once I understand it, I’m jumping between those files again to make my changes. All of that is much faster in a lightweight editor than an IDE. But I still open up the IDE every now and then to double-check some change that I made, or do those big fancy refactors.
You could argue that it's specifically true for projects, but the definition of average absolutely doesn't require that.
If for example you had 100 projects were 50 of them were built by expert teams who poured love into their work, and 50 were made by 12 year olds who spent one day on their projects before giving up, the "average" quality of the 100 would be a long way from either the great or the shit products.
Likewise if a group of ten people has five CEOs earning a million a year, and five waiters earning minimum wage including tips, none of the ten are "by definition" earning half a million a year.
Of course in my data sets there is a kind of "normal distribution" such that most objects are near the mean, but that needs to be found out not assumed.
I have no idea how many tech products are near the mean as opposed to near one extreme or the other, and doubt anyone could guess without bias and without actually researching the question.
> Most projects are average by definition. Otherwise that wouldn’t be the average.
You're assuming outliers in both directions don't dominate the process.
As an example, let's say we have 10 projects, that have some property that can be rated on a scale from 1-10. Difficulty to accomplish is the first thing coming to mind. If we have 5 projects that are a 1 on this scale, and 5 projects that are a 10, the average is going to be 5.5 despite none of the projects being anywhere close to that.
There’s way too much variance in projects for the average to be meaningful, in my opinion. They will have some or many average parts, but they will also have some number of parts that are special.
It might be normally distributed, but across tens/hundreds/thousands of dimensions. For example, some axes might be
Like, if you want a terminal-based UI and don’t need SQL access, then you definitely shouldn’t use Ruby on Rails.
Some of those dimensions are obvious at the start of a project but some aren’t. You might not find out until later that you need something that your framework doesn’t support. And when that happens, you can end up in a situation of hacking together the feature working around the framework, especially if there’s a deadline.
Like I said, frameworks are great if you are very careful with their limitations.
It's a really weird sentence. I think most people would consider IDEs are the "fancy" ones, compared to emacs. I have to read your comment 3 times to ensure I didn't read it wrong.
Plus the comparison doesn't work at all. When you use your home-made framework to solve a common problem, you make it harder to maintain for others. When you use emacs you use emacs.
Emacs and IDEs are tools, but frameworks and libraries (and programming languages) are not merely tools. They're tools AND raw materials.
"I actually wrote a vim versus IDE comparison. Do you know how much faster vim was? 4.3 seconds! 4.3 seconds I saved every day! All those months learning were totally worth it."
My experience with having to use Spring Boot everywhere is that the amount of effort involved in debugging Spring Boot problems is hardly worth the benefit of avoiding the minimal glue code to call some database or pass around some object. But hey, some dentist said this toothpaste is the toothpaste to end all toothpastes...
What with Google and now GPT, it's critical that your framework is well talked about on the internet. Otherwise searching "show me some code to do XYZ using the frankenframework" will come up empty and then it's game over for your framework.
That makes building your own framework even less of a good idea than it used to be.
OTOH, if you build a framework/library, you might be able to use AI to generate thousands of examples of using your framework/library, then publish those examples. If it's too difficult for the AI to generate correct examples, then that may be a sign of what parts would also be difficult for humans.
We may in fact see an explosion of new frameworks and libraries that use this strategy.
Like factories, frameworks are methods of reducing production costs, but come at the expense of certain aspects of product quality.
Sometimes, that quality/cost tradeoff is desirable, sometimes it's not. The trouble comes if using a factory or framework is the only, or even main, tool in your toolbox, and it ends up getting used for everything.
I'm not sure the expense of reduced quality is even an issue. Just like an (decent quality) spice rack I buy from a store is probably better quality than spice rakes built by most people, an app built on a (decent quality) framework is probably better quality than apps hand built by most people.
> the main tool in your toolbox, and it ends up getting used for everything.
I you get the work done efficiently this may be a good strategy. It may be a worse strategy, to spend a lot of time to find the "perfect" framework and a lot of time to master it, just because it's a better fit for the problem. "Good enough" very often does the trick.
Absolutely. From an engineering standpoint, "good enough" is often the right thing. An essential thing engineers do, after all, is to select appropriate compromises.
Exactly. This post falls apart because it's predicated on the company not selling hammers anymore. That's not true about software: you have plenty of choices if you don't want to use a framework. People are happily string together libraries to make web servers in almost every language I know of, including the heavyweights like Java and C#.
I think you might actually be surprised at the level of non-sophistication of most of these factories. Especially for the "made in China" items, but even in the US. My friend works at Masterbrand, a HUGE houseware manufacturer and it is essentially a massive workshop of people using the most basic tools within reason for the job. This is specifically by design because they found that the more advanced tools required more advanced workers and upkeep that ultimately made them more vulnerable to labor and tooling disruptions. Now 99% of the jobs are setup where anyone can step in with very minimal training.
Indeed, but they don't just do basic items. They make huge industrial products the same way. See this video for example where they melt down steel scrap in arc furnaces covering their faces with just cloth and pour those huge steel gears.... https://youtu.be/2lrGQbMEHaQ
By that very analogy, using frameworks for building a service is absurd.
A framework you would use in order to pump out a ton of services quickly, just like a factory in this case. They'd be similar, with similar functionality and such, but you can produce them quickly and upgrade things across all of them fast. They wouldn't by optimal, but time from development to launch would be quicker.
But most startups and companies start with one web service, where at that point you don't really need a framework. What you need instead is careful deliberation and implementation, together with development speed and also enough proper architecture to continue to facilitate development speed in the future, but not too much as to over-engineer things. A balance if you will.
But unless your business/startup is about pumping out 100s of websites, a framework will hardly help you achieve your goal faster.
Is the author trying to build themselves a spice rack or many spice racks for all the world? In one of those cases, yes, you would want a factory, but that isn't this case.
The same is true for code. Are you writing one application or are you writing the same application for many different customers? In one of those cases you would benefit from some sort of template but in the other case it all the extra stuff to scale just gets in the way.
If you want your one self-serving spice rack to scale then just plan ahead and make it bigger than your current needs so that you can add more spice later. Again, that also applies to code. If you want your one application to scale then just plan ahead. Jumping immediately into a framework only indicates you lack the confidence to make appropriate planning decisions.
And the spice rack itself is just a container for preprepared ingredients from spice factories, to enable a cook to easily access them.
The end product here is the food, after all.
When you go to cook a meal you’re oblivious to the framework of abstractions that go to make it possible for you to obtain and store and conveniently dispense your spices - as well you should be.
The pieces are mass produced, the assembly is done by humans. Because unlike software they are not insane.
There is no at scale for 99% of companies.
The break even point for a factory building spice racks buying machines instead of humans is an immense volume of spice racks - like 100+ spice racks an hour type thing. Maybe more.
Just like software, the number of companies that need to produce spice racks at this volume is miniscule.
Unlike software, the ones dumb enough to buy machines they don't need go bankrupt very quickly.
The point that flew over your head is every one wants one spice rack. There is no scale, no one wants a 1km long spice rack or 10,000 small ones either. That you can just buy a ready made one is even more to the authors point. Most software shouldnt exist! Why even build a spice rack, indeed!
But if you were building spice racks at scale, of course you would build them in a factory! And you'd use machinery made in other factories. And those factories would have tools and machines made in yet other factories.
That's why you can go to Amazon or Wayfair or the Container Store and find 100 different spice racks for less than $30, and why nobody builds a spice rack by hand, except for fun.