50 ms·

Why I Hate Frameworks (2005)

• oftenwrong 3y ago
  Related: "Using a Framework will harm the maintenance of your software" (2022) https://news.ycombinator.com/item?id=33185010 https://news.ycombinator.com/item?id=33185010
• rco8786 3y ago
  Should be titled “Why I Hate Java” Not sure this post actually has anything to do with frameworks at all.
• pharmakom 3y ago
  Frameworks are bad because they don't compose. What does compose? Simple types and pure functions. If you want to create a community with high levels of code reuse, start there.
  • skydhash 3y ago
    I was listening to a talk (strange loop conf, can’t search the talk itself) where the speaker claims C and languages derived from it feel clunky because they were invented, while Lisp, Haskell were discovered. The latter group is more cohesive and relies on simpler truths instead of the amalgam of idioms you can find in Java. I concur with this because programming with Clojure feels wonderful. Your code is a straight line from input to solution. With imperative languages, you see yourself applying the duct tape.
    • c_crank 3y ago
      Lisp is an imperative language, yet has the same simplicity of code reuse.
• xyst 3y ago
  Sounds like a 3d printer
• jokoon 3y ago
  I remember following up the Angular tutorial. I was about 15min into the tutorial, and I was already editing 8 different files. I never got lost so quickly. I lost a job because I could not use angular, but never felt bad about it. I remember somebody commenting here on HN about a developer conference, where the speakers were bragging about their software being complex. This is an awful trend with software, and is related to John Carmack's "layers of crap", Wirth's Law and developers who want to keep their job by writing code only themselves understand. The quality of any engineering work is highly correlated to how simple and approachable it is. Unfortunately sofware developers have the unfortunate tendency to have a taste for complexity, because they feel complexity is a form of art since they view computers are complex things. It doesn't have to be like that.
  • andix 3y ago
    That's why angular is hated so much. It makes easy things more complicate. In my opinion it's a bad framework. Use a good framework instead! Just because some (or a lot of) frameworks are bad, it doesn't meant that the concept of a framework is bad.
  • hot_gril 3y ago
    Same experience with Angular; idk what they were thinking. Just a button is like 10X harder than vanilla JS. React showed that you can accomplish the same thing with a lot less repetition, which is odd because there's supposedly less going on under the hood than with Angular.
    • deleted 3y ago
      [deleted]
  • a_wild_dandan 3y ago
    This is why React won: No template language to learn. No prescriptions for managing your app. No piles of abstractions to do basic things. It's just a UI lib. Import it, declare what to paint on-screen, done. Oh, you want routing? "Not my business", says React. Go add a routing library. You want a framework for managing global state? Go find one. Want a kitchen sink frontend solution which bundles all of these commonplace features together? Use Create React App, or Next.js, or whatever fits your use case. That's why I love React. The complexity of the solution matches the complexity of the problem. Hello world: const App = () => <div>Hello world!</div> root.render(<App />); Basic reactivity (output click event to console): const App = () => <button onClick={console.log}></button> Composition & enumeration (dynamic bullet list!): const OneTwoThree = () => [1, 2, 3].map(i => <li>{i}</li>) const App = () => ( <ul> <OneTwoThree /> </ul> ) Set UI output data and CSS style based on asynchronous query results: const App = () => { const [isGoogleUp, setIsGoogleUp] = useState(true); const checkGoogleStatus = () => fetch('http://google.com') .then((response) => setIsGoogleUp(response.ok)) .catch((err) => setIsgoogleUp(false)); useEffect(() => { checkGoogleStatus(); }, []); return isGoogleUp ? (<span style={{ color: 'green' }}>Google is up!</span>) : (<span style={{ color: 'red' }}>Can't reach Google.</span>); }; I can't imagine things being much simpler than this. No extra CSS files. No `Controller` classes. No janky, bespoke HTML "attributes" to make array loops or conditionals work. Just pure JavaScript (JSX optional) painting what you declare. That's my jam. I can't endure the agony of learning another damn template language or SomeCompany's (leaky) abstractions.
• jonas21 3y ago
  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.
  • kristopolous 3y ago
    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.
    • balder1991 3y ago
      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.
• inopinatus 3y ago
  Joe Armstrong: “but I wanted a banana”
• Dudester230602 3y ago
  So, no game engines then.
  • justincredible 3y ago
    [dead]
  • billforsternz 3y ago
    I'd forgotten the punchline "So this thing comes with documentation right? ...." My favourite part of the whole piece.
• hayst4ck 3y ago
  I'm not a huge fan of these pieces that don't speak to why frameworks are created in the first place. The counter point to this is that the purpose of frameworks is to turn O(N) problems into O(k) problems by implementing a seam in the code. The problem a framework ultimately solves is that some teams will choose to use screws, some will use a hammer and nails, some will use a nail gun, some will use glue, some will carve connecting joints, some will use metal and weld, some will take a large piece of material and carve it out, etc. etc. and now you have 50 different ways to perform one task, which is to get the end result of joining two objects. That means 50 different on-boarding processes, and 50 different design paradigms to manage, 50 different classes of corner cases, 50 different monitoring/operational paradigms, 50 different hiring processes, etc. etc. Sometime between 50-500 engineers it becomes necessary to properly framework-ize the unit of business logic that product developers work on, like a route, to prevent operational overload.
  • crdrost 3y ago
    Related: "Write libraries, not frameworks," which goes more into depth about how frameworks establish precisely such a "seam" and the responsibilities it entails. https://www.brandons.me/blog/libraries-not-frameworks https://www.brandons.me/blog/libraries-not-frameworks
    • hayst4ck 3y ago
      > Frameworks' key trait is that they impose limitations on the programmer. Rather than providing a set of new things the programmer can do, they establish a boundary on the things the programmer can do. Simply stated and very insightful. This is a way better article than the posted one. Another way of thinking about this is that a framework is a regulating authority on a tragedy of the commons. The commons in the case of software is complexity. Too much complexity becomes impossible to manage and grinds development to a halt.
      • paulryanrogers 3y ago
        Not sure it's always the key trait. In software frameworks are so often accompanied by a rich library of packages or code that folks may consider another important trait is their baseline of functionality. Some frameworks are "batteries included" while others are a "bag of reusable components".
• sn1de 3y ago
  Yes, the state of the industry is a hot mess, but I'm not sure this article rings true. Failing to leverage good frameworks is as big a problem as over using the bad ones. I would point to Rails as an example of an appropriate framework (and Laravel if PHP is your jam). The trouble is so many others are bad, incomplete or defunct, but I don't think the answer is the golang mantra of 'we don't need no stinking frameworks'. Seeing mediocre developers reinvent the wheel, slowly and badly, is super painful and wastes time and money. If you hate the frameworks available to you then perhaps you should consider finding a better ecosystem. Relax your bias and follow the happy developers, wherever that may lead.
  • w7 3y ago
    I'm not sure I'd describe the golang community's attitude as a complete write-off of frameworks. I don't think I personally know a Go developer who doesn't use some sort of web framework (I personally use Echo, for example). Rather I think it'd be better phrased as "frameworks should use simple abstractions and methods as often as possible", which the language naturally pushes people towards imo. I believe this causes most Go frameworks to be referred to as "microframeworks".
    • sn1de 3y ago
      I agree with your more nuanced take on the golang community's position. I still think that a fully realized framework is, in general, a better starting point for the vast majority of projects. Part of the problem is that such frameworks are few and far between. I'll stick to the Ruby community: I know developers I respect who really like Sinatra, which would be more akin to a microframework. It is their go to starting point, but when I go to work on their projects I very quickly find myself straying out of Sinatra's capabilities into things that are fully baked into Rails. I then have to spend time pulling that capability into Sinatra, which is not how I like to spend my time as an application developer. There are many frameworks that are positioned as 'elegant' or 'focused' when they are simply incomplete in the face of real world development and teams end up having to either cobble together disparate micro-framework or rebuild basic capabilities to get to a fully realized app. I would argue that is not time well spent and that everyone thinks they are super good at creating solid, performant, extensible, well documented code, but they are not (statistically speaking) and by then it is too late and others have to live with their junk for years, or worse yet they all bail because now they know hot-framework-x and board the recruiter train to their next salary bump.
• sbr464 3y ago
  This is getting old.
• hardlianotion 3y ago
  I like the little joke at the very end.
• hexage1814 3y ago
  This whole thing reminds me this simpsons joke from S10E03: https://www.youtube.com/watch?v=LuiK7jcC1fY https://www.youtube.com/watch?v=LuiK7jcC1fY
• projektfu 3y ago
  For some reason it called to mind the basic technique of stepwise refinement. https://dl.acm.org/doi/10.1145/362575.362577 https://dl.acm.org/doi/10.1145/362575.362577 (HTML, links to PDF) A good framework would be one in which you start your solution and find that at many locations, your pseudocode gets replaced by an equivalent call into the framework. There are, however, some other requirements that are not obvious from this specification of good framework that make it a great framework. Discoverability, testability, debuggability, deployability, documentation, readability and, of course, performance. But, yeah, you start out with one and you lose interest in the project because of the difficulty of getting started.
• travisgriggs 3y ago
  This was written in 2005. I feel this ship has so sailed at this point. I would love to go back to the world where I had the bandwidth to waste on framework hating. Now days, Framework's mutant offspring ad-order-of-magnitue-larger, Platforms, is what I cope with. Why I Hate Platforms would be the same general rant writ large.
• Mindey 3y ago
  Welcome to 21st century, where everything is almost done, and all you need is to know the language to specify what you want in the universal config.
• Ensorceled 3y ago
  I’m reminded of the YouTube/Facebook videos where the furniture maker first makes their own lumber from timber, planes it down etc. It’s really not necessary for the vast majority of projects you can buy good quality hardwood at the local mill.
• deleted 3y ago
  [deleted]
• post-it 3y ago
  Yeah but React is really good. A lot of these articles[0] delve into an analogy that they twist into a complicated mess and say "hey look at how complicated frameworks are." But React isn't complicated. Most kinds of interaction, even for the smallest apps, are easier with React than with vanilla JS. I've never felt like I'm managing a factory factory factory when using React. And if I do, it's easy to peel back the veil and write vanilla JS alongside React. [0] I realize this was probably one of the first of such articles and thus has fallen victim to [1], but someone did post it today. [1] https://tvtropes.org/pmwiki/pmwiki.php/Main/SeinfeldIsUnfunny https://tvtropes.org/pmwiki/pmwiki.php/Main/SeinfeldIsUnfunn...
  • paulryanrogers 3y ago
    Some inline on(event) attributes can be simpler to enhance basic MPA functionality, compared to pulling in React. I suppose it depends on the requirements and what one is most comfortable with.
  • quickthrower2 3y ago
    React is arguably just a library though. NextJS is React as a framework
    • hot_gril 3y ago
      React: - completely changes how you write your frontend - changes the language itself (JS -> JSX with embedded HTML) - has lots of react-* libs built around it - comes with a script initializing an app skeleton I would call that a framework. And it's a very good one.
      • mostlylurks 3y ago
        > completely changes how you write your frontend You can use it for only a part of your UI, and you can implement any parts of your UI that are embedded within react components without react as well. It doesn't lock you into doing things its way in any manner whatsoever, it is literally just a library with functionality that you can utilize wherever relevant in your app. > completely changes how you write your frontend JSX is not an integral part of react. It's quite feasible to use react without using JSX, and I have done so in the past in some of my side projects when I wanted to avoid setting up a build system for a while. JSX just compiles down to plain old function calls, and you can use those directly without JSX without any issues. > (JS -> JSX with embedded HTML) JSX doesn't really have embedded HTML, it's just syntactic sugar for plain function calls that only somewhat approximates HTML. > has lots of react-* libs built around it Which are usually either libs that implement a react component with react or just wrap some non-react library in a way that's slightly easier to use than using the library directly in an app using react, but it's not like that latter is impossible or even difficult. > comes with a script initializing an app skeleton Such scripts exist, but they are not integral parts of react and are by no means required to use react. React is just a library, and if you want to, you can use it without doing anything else except including a single .js file with a <script> in your html file, even if the more usual way of including react in your project is a lot more convoluted.
• rhdunn 3y ago
  Frameworks are good if what you are trying to do aligns with the model/architecture of that framework. Trying to do something outside that gets exponentially more painful the further away you are from that framework. The same also applies to external libraries and the architecture of your library/application.
• daniel-s 3y ago
  Two sides to this. Author uses everyday life to describe the multiple layers of abstraction in software engineering. That's precisely the advantage of software: that abstraction is easier to construct—by simply writing down rules in text files—than mechanical engineering or other fields. That said, author is not wrong. Reminds me of talks from Bob Martin about frameworks and software architecture. Summarised and linked (shameless self-plug) here: https://www.compilatrix.com/docs/framework-there-to-screw-you https://www.compilatrix.com/docs/framework-there-to-screw-yo...
• evilotto 3y ago
  When all you have is a HammerFactoryImpl, every problem looks like an INailIterator
• quantum_state 3y ago
  A fool with a tool is still a fool … hating the tool does not change this … let’s save our breath …
• vjust 3y ago
  Framework-itis is a widespread disease. Developers and technologists weaponize frameworks to win arguments and feel vindicated that they are setting professional standards
• bergwerf 3y ago
  LOL the new factory factory factory is ChatGPT
• js2 3y ago
  > "Really? I thought you just said that the Universal Hammer was the wave of the future." This really demands that I link to the "Chef of the Future" Honeymooners episode, which I expect most readers of this site will not be familiar with and that I only know because my dad was a huge Honeymooners fan. It's apt to the blog post, as it turns out: https://youtu.be/em1DEwOtm3I https://youtu.be/em1DEwOtm3I To provide some context for the scene, Ralph ("chef of the future") is a bus driver and he's always looking for the next get-rich-quick scheme. Ed ("chef of the past") is his neighbor who Ralph thinks he's smarter than and always enlists in his schemes. Ralph's schemes never work out for him. The scheme in this episode is to sell a kitchen multi-tool ("handy housewife helper"). Here the two of them are supposed to be presenting it to a live TV audience. Unfortunately, Ralph's stage freight and the fact that the multi-tool is worthless get the better of him. Sometimes when I read about a new framework or other software contraption that's supposed to make my life easier, I wonder to myself: "but can it core a apple?" > Everyone is using a general-purpose tool-building factory factory factory So that would be like a 3D printer that can print 3D printers? Personally, I think I own about 4 or 5 different kinds of hammers. And I'm just a homeowner who fixes things on weekends.
• jfoutz 3y ago
  I get the joke. I would absolutely buy a tool factory factory. Tempering the steel alone would be worth it. I’d even be interested in one more layer up, for access to car, rocket and chip factories.
• bouncycastle 3y ago
  It's the 2020's, you no longer need to build a spice rack. You use Spice Rack as a Service.
• _madmax_ 3y ago
  I really like their sense of comedy, they suffered so much it gets funny.
• grishka 3y ago
  My answer to this is — I don't care what "everyone" uses this season, just give me the damn hammer please, I need to get my job done.
• rburhum 3y ago
  I will give a counter point. I love well-designed opinionated frameworks. Whenever I want to do something simple, I agree that a framework may be overkill. A micro-framework is nice for those scenarios though. However, whenever I build a project that will be maintained or extended by many people, opinionated frameworks give me the advantage that they force you to do things in a particular way. Django is a perfect example. If all I am doing is two or four pages that just return static HTML, then why would I pick that at all? A new django project creates a specific file structure: urls.py, models.py, settings.py, views.py, middleware.py, etc. If I get a new Django developer that is not familiar with the project, I can pretty much drop him in and he will not what is going on quickly. I don't need to explain what a viewset is because chances are that the dev has used Djano Rest Framework before. Whatever changes are made, will follow the same patterns, so maintainability overhead is reduced. When you add a project that is built from scratch without using a framework that has strong stances on how files should be organized, all bets are off. You have to spend a lot of time trying to wrap your head around the custom abstractions that have been built - and it is hard to argue that some of that will translate to a different job. Yes, of course when you want to do something else that forces the opinionated framework to do things that it was not designed to do, it is a true pain - but you have to ask yourself if for that particular case it makes sense to use that framework at all (most likely not). Frameworks also evolve. I use to curse constantly when I had to touch a Backbone JS project in the past, but now, I can jump and look at a React project that uses Redux and get to make changes right away without paying high cognitive cost. It may not be perfect, but it gives me structure and pre-defined patterns to worry about solving the actual problem I want to attack - and not waste time trying to create yet another leaky abstraction. My two cents.
  • klabb3 3y ago
    I think it really depends on the use case, no? You can design a framework to be more or less restrictive, and the best tend to be less so, (which allows you to do stupid things but has good guidance on how to NOT to do that). For instance, you could have an http framework that handles things like compression, buffering, timeouts etc, which are likely to work everywhere. But you could also design it such that each mime type comes with a separate class, like a HTMLTreeBuilder, or something like that, which would be horrible and way too constrained. Elaborate type systems can, in some cases, seduce this kind of overengineering. If it really looks like something can be modeled as a type, chances are that the author cannot resist it.
• cout 3y ago
  After reading this I understand why angularjs is a different kind of framework. Instead of a factory factory factory you get a provider provider provider, which is 1000x better.
• hot_gril 3y ago
  Bad frameworks suck, good frameworks are good, that's about it. Factories in Java, like the URL hints at, are just bad. Maybe they made sense in older versions for reasons that I forget. Haven't felt the need to make factories in modern Java or in any other language.
• spacemanspiff01 3y ago
  So coming from c++ these factories are sounding a lot like compilers, how does a framework differ from a new language and standard library? Or for that matter, an os and POSIX? A language is just a standardized framework, and languages are created to solve general cases of specialized problems. Sure, I don't need the python framework to do something, but if I don't care overly much about performance, why would I want to deal with manual memory management of c. And just because c exists means we should not use c++ or rust? Choose the right tool for the job, but starting at a high level of abstraction and working down as needed often makes a lot more sense than starting low and working up. Maybe don't use unproven frameworks and all frameworks has a different level of provenness. yes there are some people out there that don't need anything, and can program a http server and website in assembly. But it's either a toy or fun side project if they do.
• vonwoodson 3y ago
  Can I get a factory that’ll make factory factory factory containers to run on The Cloud?
• dreday 3y ago
  You know why this is so dumb? Because there's an analogy that's very similar that explains why we have frameworks. A: I wanna buy a tree. B: Ok. We have trees. What do you need a tree for? A: i want trees so i can make lumber out of them. So i can cut them in two by eights. So i can build a deck deck for my patio B: Hmm we sell two de eights. You wanna buy that instead? A: Oh yes why! I would like that! I'll buy two by eights instead of trees so i can finish my job faster!
  • von_lohengramm 3y ago
    It appears that you are entirely missing the point and the author's criticism of frameworks. Your analogy is the false promise repeatedly fallen for that created the situation described in the story.
    • dreday 3y ago
      No, i get it. But the author analogy is dumb (even if funny). There's literally no one stopping you from just downloading a "hammer" from the internet and just using that. The "stores" haven't stopped selling "hammers". Even if they're also selling "factory factory factory". Go ahead and build your apps out of whatever you want, no one is forcing you to build it using frameworks. But I promise you, if frameworks did not exist half the apps I use today wouldn't either. There's a right tool for every job and the article pretends there isn't.
• throwaway1777 3y ago
  Hating frameworks is mid
• margaretdouglas 3y ago
  A misconfigured or naively implemented spice rack never provided an entry point to leverage your infrastructure to engage in illegal activity and resources at your expense.
• nullcipher 3y ago
  Easily one of the best tech writings ever. This was a thread on the joelonsoftware forum. Good ol' days.
• Sujeto 3y ago
  The browser is already a framework
• stuxnet7 3y ago
  IKEA is also kind of Framework right?
• deleted 3y ago
  [deleted]
• cabalamat 3y ago
  > So this week, we're introducing a general-purpose tool-building factory factory factory, so that all of your different tool factory factories can be produced by a single, unified factory. The factory factory factory will produce only the tool factory factories that you actually need, and each of those factory factories will produce a single factory based on your custom tool specifications. Looks like someone's been doing too much enterprise Java progamming!
• eternityforest 3y ago
  The difference is, that the universal hammer is in fact mostly good enough, or at least can be, if it's well designed, for everyone except people who are interested in simplicity for its own sake. We had layers of complexity and frameworks and embedded scripting on literal 8 bit game consoles and it was still fast enough. I think the problem he's describing comes from the fact that programmers like to build tools to make other tools. Give people a framework and they'll say "I can totally use this to make something someone else might do something cool with". Perhaps it's some kind of desire to leave a legacy or make your mark it have something awesome on your resume, or just because nobody has any ideas for apps anymore that actually seem worth it to build.
• esjeon 3y ago
  Just FYI, when this was written, "framework" was a buzzword. Everyone tried to write a framework for something, and tried to sell it over well-working libraries. The hype died down because it became obvious that frameworks are overly complicated and don't compose well. p.s. The hype predates even HN. I remember reading these stuffs on magazines. Holy crap, I'm old.
  • archerx 3y ago
    That literally feels like the JavaScript ecosystem we have today and the past few years. New frameworks almost every week...
• ookblah 3y ago
  Nice to the the cycle is alive and well. 1. Start out loving frameworks for how easy it is 2. Convince yourself frameworks are the devil and you can do without, spend a lot of time rolling your own and learning a shit ton about the nitty gritty. 3. Eventually realize it's a fruitless waste and you'd rather spend your time working on more important things. 4. Either you go on to create the next big thing or you go back to using frameworks but smarter this time around (in my experience piecemeal or better able to extend).
• MR4D 3y ago
  This is a great article, and I pretty much agree with everything in it. However, I want to comment on a bit of the discussion about hammers and carpenters in the comments on HN. Let me put this briefly - carpenters learn about wood way more than they learn about tools. Knowing how to cut wood, bend wood, fasten wood, use wood to hold things up, make wood look nice, etc. Those are things carpenters do and learn about. The tools are secondary. Also, one final note - carpenters don’t really use ball peen hammers - those are for metalworking. Carpenters use claw hammers because the claw removes nails.
• raydiatian 3y ago
  Any non-toy web service development, I disagree. HTTP is great except for the fact that as a protocol it carries no built-in mechanism for introspection on the services/types offered by an API. Openapi addressed this. But building an openapi spec by hand is moronic. Frameworks like fastapi or nestjs (forgive me if im forgetting your favorite) will generate an openapi spec. That spec can be used to autogenerate type safe clients, which solve the problem of HTTP not having discoverability or type safety.
• deleted 3y ago
  [deleted]
• pprotas 3y ago
  My enlightened centrist take on this is that some frameworks are good, meanwhile some frameworks are bad :)
• 7071856621 3y ago
  7071856621
• atoav 3y ago
  For me there are two cases: 1. My problem fits the way a framework is shaped perfectly and the things it does for me are done in the way I want them done 2. My problem doesn't fit any framework and I rather take a micro-framwwork and build the rest myself The latter is more common
• strictfp 3y ago
  I disagree with the problem statement; that the framework is trying to solve a meta-problem. The problem with frameworks is instead that they assume that they're in control. They're the program, you're just writing a plugin. This makes it unnecessarily hard to use them in all but the most straight-forward use cases. And they're usually also trying to do too much; config for starting, special way of testing, incompatible with other frameworks and libs etc. Contrary to that, a library does one thing and one thing well. Like a Unix tool. Much easier to use, better coverage, and usually easy to combine. And you can plug them in anywhere. Frameworks are overreaching, but not in the way that the article paints it.
  • grumpyprole 3y ago
    Yes this is possibly why the author renamed the post. There certainly has been a problem of over-abstraction in the industry, with some of the most guilty parties being the frameworks (e.g. the infamous AbstractSingletonProxyFactoryBean from the Spring framework).
    • strictfp 3y ago
      Maybe. But that specific overabstraction is in the implementation of the framework. It's trying to proxy all the method calls to objects to perform logic around them. It is true that Spring wants the developer to configure auxiliary logic that gets applied around the written code, instead of actually calling that logic. So perhaps that's what the author was getting at.
      • grumpyprole 3y ago
        I think of frameworks as essentially higher order functions, e.g. map/reduce, where one provides the function parameters. That many frameworks seem much more complicated than this is certainly not a good thing.
  • hot_gril 3y ago
    There are still good frameworks that don't take unnecessary control. I think the most common bad ones have some ulterior lock-in motive, usually some company trying to extend its influence, and you have to look out for that.
• gauddasa 3y ago
  Anyone who has worked in Python or Go would tell you that it's not the right analogy. Opinionated rigid solutions kill innovation and this analogy is rather quite innovative!
• afiodorov 3y ago
  I've always been hesitant about adopting frameworks, and I still favor Flask over Django. Yet, I spent a couple of years in a Go-centric department where the senior members were so against using frameworks that we ended up building everything ourselves from scratch. This included creating our own load-balancer, event store, and aggregation engine. When I attempted to point out that we were investing substantial time solving problems that have already been resolved, I was invariably met with references to "frameworks" and "complexity". However, in my perspective, our reluctance to utilize frameworks led to an inflated team size, slower development cycles, and a lengthy onboarding process for new members. I believe that if we had chosen to use industry-standard tools for our backend & infra (e.g. Kafka, Kubernetes, Apache Beam/Spark streams), we might have had to deal with a higher degree of complexity, but it would have been manageable. I would much prefer to diagnose issues with a Kubernetes deployment than to debug obscure panic-inducing code written by a colleague, which is questionably designed and lacks readily available support. One of the main advantages of using a framework is standardization: thanks to tools like git, we don't need to familiarize ourselves with every company's unique version control tool. Similarly, if everyone agrees on using Kubernetes and Docker, we can eliminate the need to learn each company's specific deployment process. This would allow us to dedicate more time to providing actual business value, rather than contemplating how our code should be transitioned into production. As for the department - it just got shutdown due to not making enough money and costing too much.
  • whstl 3y ago
    There is no silver bullet that solves this problem. The thing I've seen the most in this industry is the opposite of that: teams that would mostly use third-party tools and frameworks, but the result was effectively the same, with complexity exploding and becoming so unbearable that the teams inflated to compensate, with productivity grinding to a halt. It happens with third-party tools as often as it does with NIH. Like you say, Kafka, Kubernetes and Spark would add a higher-degree of complexity. They aren't really that simple to manage in real world production environments. That's the problem here: the complexity. It doesn't matter where it comes from, it will bite you in the ass. One extreme of that is off-the-shelf enterprise software, that often requires a team of consultants to integrate. I've seen a few disaster, one software specifically started with a 500.000 price, but things became so complex the project ended up costing 4x that. There is no panacea against complexity. It costs money and takes time. The main problem here seems to be the "questionably designed and lacks readily available support" part, which is something universally bad, even when using third-party software. You can design your infrastructure badly. You can make questionable design using third-party tools just as much as you can with your own code. And support is also very often not readily available. "Similarly, if everyone agrees on using Kubernetes and Docker" I'm totally sympathetic to things becoming standards, and I don't have an axe to grind with those two tools, but the reason for the pushback against tools like Kubernetes and Docker is grounded on reality. Not only they introduce complexity by themselves, they are often just band-aids for accidental complexity introduced by teams and by third-party things like programming languages and frameworks.
• fredgrott 3y ago
  Even worse, training beginning app designers that the implementation holes in the framework is the crayons in their new design approach to the app. At first, some see it but many do not. My bias, I app design with the flutter framework one of 3 front ends Google decided to devote engineering time towards.
• rochak 3y ago
  Skill issue
• cubefox 3y ago
  For me the most important issue with frameworks is debugging problems. A framework forces you to commit to it fully when you use it for a project. This is unlike a library, which is optional and can be locally replaced with ordinary code if something doesn't work as expected. A framework is like magic when everything works, but when you see some undecipherable framework error message you have to look behind the curtains and try to understand the code of the framework. Which can be very difficult depending on your skill. In the past I have spent hours or days debugging problems with the framework with features which would have taken ten minutes to solve in non-framework code.
• zaalps 3y ago
  [flagged]
• tough 3y ago
  If you pick enough frameworks you can learn how the underlying system works. All web frameworks are the same to me, doesn't really matter if they're python, javascript, php, or whatever tbh. req/res body cookies that's it
  • hazz99 3y ago
    I disagree, “req/res body cookies that’s it” is not the underlying system. It’s an abstraction over the TCP/IP and HTTP stack. What happens when you need to disable nagles, avoid copies of the request body, use websockets, gRPC, etc? You’d need to pray that the framework gives you an escape hatch.
    • tough 3y ago
      I might be doing it wrong, but I just approach those as new pipes to be put onto the system? they're after all basically different ways of transmitting data from point a > point b. Why would you choose a framework that didn't provide a escape hatch for your use case is the real question tho. TIL: Nagles/TCP
• noobermin 3y ago
  The (2005) part of it is the worst part. Almost 20 years later we have the same issue and haven't figured it out.
• bossstein 3y ago
  If we step back and look at this as a problem of abstraction. An advantage of abstraction is that the people working at the higher levels of the abstraction don't need to know what is happening at the lower levels. Therefore people can specialise and we can achieve better efficiency as an industry. If everyone needed to understand everything we'd be screwed. In reality there are abstraction that work very well. You don't need to understand the internals of python to use it for example, though you may be able to use it better if you do. C however I would argue that you do need to have a mental image of what is happening to use it. Also the operating system. People use that all the time without knowing how it works. Maybe we are just at that early in web dev and we are waiting for the Unix of web frameworks to arise. Or perhaps there is an inherent tension between the developer needing to fiddle with the details while the framework tries to abstract those details away.
• dgroshev 3y ago
  The fallacy here is the assumption that we get "hammers" as libraries, and not some splinters of wood in one crate and a whole bunch of hammer heads in another. A "hammer" is useable on its own, it's a self-sufficient object of value. The "libraries over frameworks" mindset as practiced leads to splitting libraries by underlying technical concerns, not practical utility. There is no practical utility in a "routing library" or an "ORM library"; there is a lot of utility in a "login system", but realistically a login system has a lot of cross-cutting concerns, from database access to sessions to forms to templating. Instead what we get is a wide selection of hammer heads and handles, all requiring assembly and not quite fitting to each other.
• sandreas 3y ago
  Great writeup, thanks for sharing :-) Some time ago, I wrote a small article, what you could learn instead of frameworks. Pretty rough, but still worth a read I think. https://pilabor.com/blog/2021/05/learn-concepts-not-frameworks/ https://pilabor.com/blog/2021/05/learn-concepts-not-framewor...
• adBurner 3y ago
  I used to hate ORMs and never used one until i discovered Prisma. Thanks to it i have been focusing more on the core idea
• evantbyrne 3y ago
  Essays like this are not constructive imo. Reading it I'm not even sure what a "framework" is to the author. It would make more sense to talk about the specific technologies that inspired the rant, and then evaluate the tradeoffs and suggest alternatives.
• klysm 3y ago
  It’s easy to hate on frameworks due to their secondary problems once you’ve lost sight of the original problems. If you stop using a framework, you are bound to recreate one probably shittier framework. Although I do agree premature abstraction is a bad idea you still need some
• egberts1 3y ago
  Customary "We didn't start the fire" for frameworks. (Apology to Billy Joel.) https://m.youtube.com/watch?v=Wm2h0cbvsw8 https://m.youtube.com/watch?v=Wm2h0cbvsw8
• paxys 3y ago
  Show, don't tell. You know what would be more effective than these dozen "frameworks are bad, React is bad, programming sucks these days..." posts a day? Just show me your work. Link to your websites and repos that you built by flipping bits with a magnet or whatever other level of abstraction you prefer and let me judge its worth. Let me see how clean the code is, how easy it was to build, how mature the final product is. In practice, what I have seen is there are people who endlessly talk about the right and wrong ways of working and others who realize that tools are secondary to actually getting your work out there in the world.
• yetanotherloser 3y ago
  I do take the point but I feel like the era of the factory factory was a while ago and I'm almost nostalgic for it compared to the dubious soup that we seem to have to deal with now.
  • killthebuddha 3y ago
    dubioussoup.ai Edit: I donno why, but the concept of dubious soup has me CRACKING UP right now.
    • yetanotherloser 3y ago
      I couldn't think of a better phrase, ok? glad if it amused!
    • tempest_ 3y ago
      We take your soup and pipe it into chat-gpt 4 and what you get is what you get. The ever growing field of prompt engineering continues to grow.
      • mmerlin 3y ago
        Beautiful Soup scrapes data for Dubious Soup model training
• kabdib 3y ago
  I once waded into a piece of software that had factories five or six levels deep. One memorable code path involved the clipboard. That was the company where I first heard the term "Train Wreck". ("Documentation? You're lucky it builds!")
• epiccoleman 3y ago
  The worst part of this kind of thing is that young carpenters honestly, really, truly, just need to learn to use a hammer. They can't even conceive of the problems that are being solved by the hammer factory, let alone the factory factory. But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan complexity of the factory factory factory. When one of the sub factories breaks down, or when a saw came out where a hammer should have, the carpenter might find themselves awfully tempted to take a ball peen hammer to someone's face. But sadly, they don't know where to get one or how to use it.
  • sam_bristow 3y ago
    I'm going to start calling construction apprenticeships "builder builders".
  • adrianmsmith 3y ago
    > But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan complexity of the factory factory factory. Sometimes I wonder if that's the point of all this complexity. (EDIT: I mean really excessive complexity as alluded to in the article with factory factory factories, or 100 microservices all in different programming languages just for a website (true story)) I mean who actually gets to decide what sort of approach to use, and what are their incentives? The senior in the team is in charge of deciding what approach to use. The senior's (personal) objective is not to get fired, maintain their position as the most senior so they can get the payrises and promotions, etc. So they sort of have an incentive to choose something that is going to be easier to understand for them than for others e.g. juniors, a kind of "moat" to protect their position of power and high salary getting attacked by lower paid juniors who don't yet have the experience to understand complex abstractions over manual tasks they haven't yet done themselves. I mean obviously that's not a kind thing for a senior to do, nor something that's in their employer's interest, but on the other hand it is rational given their incentives...
    • josephg 3y ago
• erulabs 3y ago
  Simplicity is easy to mandate: "just use simple tools!". It's not always obvious when the finished product looks wonky and slanted and has to be retrofitted several times that the complexity was always there, in the world. The complexity in our tools is hopefully there to help with some complexity in the world. In my experience, it's always the junior who shouts "This could all be so much simpler!".
  • bob1029 3y ago
    > the complexity was always there, in the world Essential complexity is exactly that. The entire game is to separate it from the accidental complexity. My career/life was revolutionized by a paper that is 100% focused on this very topic: https://curtclifton.net/papers/MoseleyMarks06a.pdf https://curtclifton.net/papers/MoseleyMarks06a.pdf The solution to eliminating accidental complexity is ultimately presented as a flavor of relational model, which I simply read as "please just use SQL for most things". This perspective has served me exceptionally well over the last ~4 years now. A quote I like from Chapter 8: > The relational model [Cod70] has — despite its origins — nothing intrinsically to do with databases. Rather it is an elegant approach to structuring data, a means for manipulating such data, and a mechanism for maintaining integrity and consistency of state. These features are applicable to state and data in any context. Chapter 9 offers an actual proposed solution - Functional Relational Programming. At the end of the day, suffering in a cesspit of complexity is a choice. The relational model is the answer for untangling highly-complex (aka high-dimensional) problem domains, especially ones that require arbitrary downstream views of the data. The central piece of magic with the relational model (as applied to the real world) is the query planner. You should start thinking of this as an actual code-writing super AI that can answer optimization questions 1000x faster than your best developers. All you have to do is give it a tiny pile of hints to work with, and almost any arbitrary request will be satisfied in a nearly-ideal amount of time.
    • john-tells-all 3y ago
      For others: this is the classic Out of the Tar Pit paper, which I also adore so so much. It promotes very explicit state management and functional programming to reduce accidental complexity. our friend ChatGPT summarizes the paper thus: "In summary, "Out of the Tar Pit" argues for a shift in software design principles, advocating for the reduction of accidental complexity through functional programming and dataflow concepts, proper state management, and the use of formal methods. By focusing on these principles, the authors believe that software systems can be made simpler, more robust, and easier to understand and maintain."
• Adamantcheese 3y ago
  Should've just used a rock instead. Free and you can argue about whether expensive European mountain rocks work better.
• Escapado 3y ago
  This reminds me of FizzBuzz Enterprise Edition and I have come across software that was pretty much written like this more than once. To be fair: finding the right level of abstraction in a sea of uncertainty can be a tricky problem - but sometimes this also just happens for very different reasons than out of necessity (ivory tower architecture commitees, external companies selling the most expensive solution, ego fueled idiocy or just plain old ignorance).
• mdorazio 3y ago
  I want a version of this satire where they only sell hammer subscriptions, but to get the hammer the guy actually wants he needs to buy an Extended Hand Tools subscription that auto renews and costs as much in three months as buying the original hammer would have.
  • Etheryte 3y ago
    Don't forget getting billed for a full year while still losing access if you cancel your subscription.
  • nerdponx 3y ago
    It's not a hammer subscription, it's hammering-as-a-service. You ship them the nails and wood, they ship you back the nails hammered into the wood. You don't have to worry about the complexity of storing or using a hammer anymore, let alone the difficulty of selecting the right hammer, it all just works. They charge extra to sell you the nails and wood, to avoid the complexity of packing and shipping your nails and wood.
    • samuellevy 3y ago
      They have strict specifications about the types of nails and wood that they can hammer, but they're not documented anywhere. If you send them the wrong type of nails or wood, they'll put them both into an industrial shredder and send you back the dust, because technically the nails have now been integrated with the wood. Their free plan will let you hammer in 5 nails per month into a single piece of wood, but you can't use a different piece of wood each month. For $30/month you get 50 nails, and up to 5 pieces of wood, or for $60/month you can get 120 nails and unlimited pieces of wood, and two-factor (they'll call you before they hammer in the nails, and ask where you actually want the nails hammered). If you want to have unlimited nails, you have to contact them for enterprise pricing. They will also sell the measurements of your wood and the nail positions to other carpenters.
    • avidphantasm 3y ago
      Maybe you don’t want to be a carpenter after all…
• idlewords 3y ago
  This should have ended with the guy giving up in frustration and using a 60 year old loaded gun to drive in his nails.
  • function_seven 3y ago
    Funny coincidence. Just yesterday The Far Side featured this comic: https://www.thefarside.com/2023/07/06/1 https://www.thefarside.com/2023/07/06/1
• doitLP 3y ago
  With only very slight modification, this essay could be rewritten with “dependency” instead of “factory”
• deleted 3y ago
  [deleted]
• revscat 3y ago
  Look, if you don’t like React just say so.
  • samuellevy 3y ago
    Ok. I don't like React.
  • hfkwer 3y ago
    This piece was written before React even existed. (React is from 2013, this is from 2005.) Besides, I can't think of a single "factory" oriented concept in React, could you elaborate?
    • revscat 3y ago
      Yes, of course. It was a joke. Jokes don’t have to make sense. They just have to be funny. I understand that you did not find it funny, and that’s ok. It certainly wasn’t even all that funny. There are wide variances in what people find funny. Even the most uproarious joke a comedian tells will have those who genuinely didn’t enjoy it. But at the same time it is generally considered dickish to try to convince the people who did enjoy the joke that they shouldn’t. People tend to enjoy laughing and smiling. Having some buzzkill come in and vomit “well akshually” all over the place is a sure fire recipe for annoyance. As an example, the movie “Monty Python and the Holy Grail” opens with King Arthur being trailed by a servant banging two halves of an empty coconut together. King Arthur’s time is estimated to have been around the late 5th century. Coconuts were not introduced to Europe until centuries later. If someone were to object to the scene with these bits of history they likely will be viewed unfavorably. The reason for this is because most people do not expect satire to be historically accurate. Personally, if I see the words “frameworks” and “hate” in a sentence then immediately my brain goes “REACT!” The joke, such as it was, was an expression of that. Should you require further elaboration on the subject of humor please do go jump off the nearest bridge.
      • hfkwer 3y ago
        Sir, this is a Wendy's.
• JohnMakin 3y ago
  This is taking a shot at Java, and a pretty old "joke" but I've heard of this actually being a thing out in the wild: https://stevenheidel.medium.com/a-factoryfactoryfactory-in-production-822478b5afbd https://stevenheidel.medium.com/a-factoryfactoryfactory-in-p...
  • cataphract 3y ago
    It's rich from someone coming from scala. I frequently see lambdas returning lambdas returning lambdas that return a new object.
    • adasdasdas 3y ago
      It's called currying and it's awesome
  • nathell 3y ago
    Reminds me of an issue I submitted against Apache WS-XMLRPC 15 years ago, related to a class named RequestProcessorFactoryFactory.RequestSpecificProcessorFactoryFactory: https://issues.apache.org/jira/browse/XMLRPC-147 https://issues.apache.org/jira/browse/XMLRPC-147
  • deepsun 3y ago
    Thanks for the source! Although, frankly speaking, Java libraries are still the most convenient to include/extend than most other compiled languages I've seen so far. Probably because of that culture of over-engineering for abstraction/extensibility.
  • gottorf 3y ago
    Another fun shot: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
    • jameslk 3y ago
      Looks like the FactoryFactoryFactory was proposed but a PR wasn't ever created sadly: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition/issues/605#issuecomment-1222560743 https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
• gigel82 3y ago
  This must be a Java joke I'm too C++ to understand. But I was actually hoping for a factory automation online game because I feel like I need to sink the next 2 - 14 days of my life into a shapez.io or mindustry or something like that...
  • TOGoS 3y ago
    It is Java's particular set of features and lack of features that give programs written in it a tendency towards design patterns like the one described. - Everything's an object -> Let's define lots of nouns! - Classes cannot be declared to implement interfaces after the fact -> Let's write some adapter classes! - People get tired of writing adapter classes and notice that JVM has reflection capabilities -> Let's make a framework that generates adapter classes as needed! - Everything's heap-allocated -> Let's avoid excess allocations by re-using objects! Which means you've got a big web of interlinked mutable thingamabobs floating around, made possible by Java's pretty-good GC. - 'const'ness ('final'ness in Java-ese) is defined on the type, not on where it's used -> Most classes are written assuming mutability, and if you want immutability, you need to create an entirely separate type hierarchy. I could go on. When I want to write a Java program but keep it simple, I usually end up writing something that looks more like a C++ program. Minimal, domain-specific classes with as much setup in the constructor and as much `final` as I can get away with. But it's not as ergonomic a language for writing programs in that style as C++ is. And once a coworker brings in some library written in the conventional combinatoric-explosion-of-classes-and-pointers-to-mutable-objects-everywhere style, you're pretty much stuck with it.
  • nemetroid 3y ago
    Well, there's not much preventing a C++ programmer from limiting themselves to a feature set similar to Java's (replacing garbage collection with generous shared_ptr usage).
• dang 3y ago
  Related: Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=28920095 https://news.ycombinator.com/item?id=28920095 - Oct 2021 (296 comments) Why I hate frameworks (2005) - https://news.ycombinator.com/item?id=12635142 https://news.ycombinator.com/item?id=12635142 - Oct 2016 (66 comments) Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=9203959 https://news.ycombinator.com/item?id=9203959 - March 2015 (63 comments) Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=6542817 https://news.ycombinator.com/item?id=6542817 - Oct 2013 (37 comments) Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=6283601 https://news.ycombinator.com/item?id=6283601 - Aug 2013 (118 comments) Why I Hate Frameworks - https://news.ycombinator.com/item?id=2787525 https://news.ycombinator.com/item?id=2787525 - July 2011 (100 comments) Why I hate frameworks (2005) - https://news.ycombinator.com/item?id=1533274 https://news.ycombinator.com/item?id=1533274 - July 2010 (55 comments) Why I Hate Frameworks - https://news.ycombinator.com/item?id=431786 https://news.ycombinator.com/item?id=431786 - Jan 2009 (125 comments) Why I Hate Frameworks - https://news.ycombinator.com/item?id=95722 https://news.ycombinator.com/item?id=95722 - Jan 2008 (18 comments) ---- Edit: related ongoing thread: A FactoryFactoryFactory in Production (2017) - https://news.ycombinator.com/item?id=36638525 https://news.ycombinator.com/item?id=36638525 - July 2023 (62 comments) Normally we downweight follow-up posts but that thread is quite good!
  • briantakita 3y ago
    If only there was a framework to locate Why I hate framework posts...
    • ufmace 3y ago
      Clearly we need a framework to generate frameworks to locate threads on your favorite posts
    • raincole 3y ago
      There is. It's called "post this link on HN".
  • sixstringtheory 3y ago
    There must be some metric of the resonance of a particular piece by looking at the number of reposts and distribution of comments amongst them (plus an analysis of the sentiment of the comments and characteristics of the thread trees in each separate posting). Just looking at this listing, without looking at the comments in each one, this seems to have a sustained resonance. Maybe I’m biased–it certainly resonates with me!