24 ms·

Why I Hate Frameworks (2005)

• quickthrower2 5y ago
  I like the frameworks you can have around for a lifetime and never change. I really appreciate JQuery (ok it’s a library) and ASP.NET MVC which is about 13 years old I think (vintage these days!). To me the problem is a framework is like 200 hours to even get efficient in and if you already know X a there are not much returns in Y in general.
  • deleted 5y ago
    [deleted]
• yandrypozo 5y ago
  this post never gets old!
• mellosouls 5y ago
  (2005) Also reminds me of this framework parody (and the container one it was based on, linked within) https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
  • eckmLJE 5y ago
    What's funny is that now, 5 years later, all the crazy things the writer is parodying sound completely normal to me.
    • tehjoker 5y ago
      I last coded JS seriously in 2016 and I felt like I was losing my mind (though once things got working it was fun). Did things settle down since then?
      • deleted 5y ago
        [deleted]
      • count 5y ago
        No.
      • mhink 5y ago
        Since 2016... yes, more or less. Webpack became the de-facto standard for bundling for a few years there, but everybody hated configuring it, so it dramatically increased the "out-of-the-box" configuration. That said, the ES module standard has started to make its way into the world, so there are more than a few bundlers these days that aim to do Webpack's job better. They've also learned from years past, and most try very hard to remain "zero-config". TypeScript has become extremely widespread, and has finally reached a reasonable level of maturity, in the sense that 1. most libraries now come with type definitions, and 2. its type system is sophisticated enough to express (and infer types for) common Javascript patterns. For non-Typescript code, Babel is still quite common, although like I mentioned, most bundlers are trying to avoid making you explicitly configure your compiler, so it's much less of a PITA to get working. In runtime-land, I can only really speak to React. It's come quite a long way in the past couple years- the main difference is the introduction of "function components" rather than the previous "class MyComponent extends React.Component". These function components use a new effect/state management architecture (called 'hooks') that's sort of like a DSL. Personally I really like it, but it's kinda divisive. Next.JS has emerged as sort of the standard "React front-end framework", and it's quite nice- again, people took "Javascript fatigue" pretty seriously, so there's much less fussy configuration. In semi-related tech, GraphQL has become quite popular for APIs, and there are a few libraries out there to help handle it. Oh, and the Prettier formatter became popular, for whatever reason, which makes me want to bang my head against a wall because in spite of the name, it makes everything it touches uglier. Anyways, I know that was kind of a wall of text, but the takeaway here is that although a bunch of new stuff happened, FE tooling is definitely trying to be more mature and avoid a Cambrian explosion of new stuff like there was back then. Hope that helps!
        • 3np 5y ago
          While fetch rules the browser, it’s still anybody’s game for succeeding request.js for node. Recently I’ve been going with got.
    • dredmorbius 5y ago
      Not sure which planet you're on, but it's been 16 Earth years.
      • heavyset_go 5y ago
        The Hacker Noon article was released in 2016.
        • dredmorbius 5y ago
          Ah, thought you were referring to TFA, my error.
• dreyfan 5y ago
  tldr: OOP sucks.
• cesarb 5y ago
  Original: https://web.archive.org/web/20180927070411/http://discuss.joelonsoftware.com/default.asp?joel.3.219431 https://web.archive.org/web/20180927070411/http://discuss.jo... (also has the second part which is missing on the link above).
• fithisux 5y ago
  When you talk frameworks, in reality you talk DSLs.
• moeris 5y ago
  As someone who built a forge and a good deal of blacksmithing equipment in order to make tools for woodworking... This analogy is supposed to make the situation sound ridiculous, but it really isn't. If customizable physical tools were able to be created and destroyed as cheaply as objects on the heap, every carpenterwould want a tool factory factory factory. There's so many jobs where a custom tool is really useful.
• Justsignedup 5y ago
  The best frameworks work well for the tasks they solve and don't make the other tasks harder. The bad frameworks work well for the tasks they solve and can potentially make other tasks harder.
• bovermyer 5y ago
  This almost sounds like an argument against AWS, not just frameworks.
  • jimbob45 5y ago
    AWS is closer to a day-laborer you hire to help you build a doghouse for your son. However, when your doghouse business explodes, your day-laborer is no longer able to keep up with your business needs and you run into absurd, yet very real problems. Edit: with your son lol - good catch
    • Digit-Al 5y ago
      I sincerely hope you're not putting your son in a doghouse lol
      • bitwize 5y ago
        Unless your son is a dog. Some of us, due to life constraints, can only have fur babies.
        • recursive 5y ago
          Some of us, due to personal preferences, wouldn't actually consider that a son.
          • nomdep 5y ago
            Usually the moment you have an actual son and realize is several orders of magnitude more love, commitment, work, sacrifice, and money.
    • sdenton4 5y ago
      (Sadly, we were forced into building a dog house as a pre-requisite for the spice rack project detailed in the original article. We needed something to guard the factory factory factory.)
• mcqueenjordan 5y ago
  The hammer analogy breaks down from the get-go for me. The main distinguishing factor between a framework and a library is the classic "you call a library, but a framework calls you." A better (but still imperfect) analogy might be buying a timber frame (with plan) versus home-rolling a stick frame from the ground up. With the planned timber frame house, the rough layout of the rooms and plumbing and such is somewhat predetermined, and as such it "calls you" in the sense that you're building out the amenities, but with the ground-up stick frame, you're explicitly making all the framing decisions too. Like all things, there are bad frameworks, but scoped appropriately (simply) they can be incredibly useful. Just like houses, it turns out there are many ways in which web services are similar to each other and can benefit from a common framing.
  • selfhoster11 5y ago
    I liken this instead to GOTO vs COMEFROM. A library is a GOTO statement, while a framework is a COMEFROM statement. Deity help you with the latter if you have problems and not enough knowledge about the framework.
    • ItsMonkk 5y ago
      I always saw it as a tight-coupling with whatever framework you are working with but a loose-coupling with whatever library you are working with, but I like this more. It's much more emotional, almost psychological horror to a programmer.
      • IggleSniggle 5y ago
        It is...and then you can't help thinking about the "no-code" solutions. Anyway, also: 1. any application with sufficiently complex use cases requires configuration 2. any configuration can be made programmable 3. frameworks are application configuration with an open-end configuration programmability 4. ... 5. profit
    • sumnole 5y ago
      TIL: https://en.m.wikipedia.org/wiki/COMEFROM https://en.m.wikipedia.org/wiki/COMEFROM
• dexwiz 5y ago
  I don't see this as an argument against framework, I see it as an argument against continued abstraction. Developers seem to be obsessed with solving the N+1 order of abstraction than requested of them. "Why solve the specific case, when I can solve the general?" If you continually ask yourself this question, that is how you end up with an Abstract Abstract Tool Factory Factory. Solving multiple specific cases is hard, so sometimes it's easier to solve the general, and push the specific problems to the consumer. Except of you do this continuously then you have pushed the entire problem to the consumer. Plus you push the additional configuration problem since these solutions rightful attempt to expose declarative configuration.
  • ozim 5y ago
    I have a funny anecdote from my experience. We sit in a meeting and discuss some feature, there are two new devs in the room, I am dev as well but I worked with those business people for quite some time. Business people start talking about "generic solution" and I already hear devs asking questions/talking like they are preparing to build "reusable and flexible framework for all your needs". Where "generic solution" for business was maybe 2 or 3 types of texts with possibility to add maybe 1 at some point. But that was nowhere near what devs were imagining especially when "generic types" has specific meaning for programming languages.
    • unilynx 5y ago
      Translating from business terminology to developer terminology is always fun, especially when they use the exact same words. One of the first times I encountered it at the early web, when a customer wants you to 'connect' two systems, before you start analysing the data models, first check if maybe all he wanted was a hyperlink.
      • dexwiz 5y ago
        Yeah, developers tend to take the most of a meaning.
  • continuational 5y ago
• zz865 5y ago
  I'm sure Joel Spolsky wrote about absurdities of having factories for everything, I can't find it though.
  • dstroot 5y ago
    This is a post from 2005 by Benji Smith in the old (and now closed) Joel on Software Discussion Group. It's titled "Why I Hate Frameworks". But I know it as "the hammer factory" post.
    • zz865 5y ago
      aha thanks, maybe I remember it from there.
• aazaa 5y ago
  The problem with the long analogy is that it's serial, not random access. You have to read the entire thing to understand the writer's message. But I think it can be summarized as follows: > “And this is the way everyone is doing it now? Everyone is using a general-purpose tool-building factory factory factory now, whenever they need a hammer?” There's something very strange about writing web applications. You can start off just writing without much regard to architecture. But by the time you've implemented a dozen or so endpoints, you realize that tight coupling and code duplication are going to ruin you. What can you do about it?. Frameworks promise a solution. But you can still end up with lots of duplication and coupling. "Controllers" can be code duplication repositories, especially in "restful" applications. Then there's the fact that you're chained to the framework from the moment you start using it until you quit or the application dies. That hard dependency can make adding certain kinds of features very challenging. And maintenance becomes yet another problem, especially if the framework falls out of favor, which it probably will.
• 1f60c 5y ago
  I'm not sure if it matters much in this case—the analogy sadly holds up well, if not better—but > (2005)
• dotandimet 5y ago
  Bit of Deja Vu. 2005.
• blunte 5y ago
  Most people do not hate frameworks. They either use an existing framework, or they eventually end up creating a custom framework which only they understand and which gets thrown out and replaced with a common framework when they leave the company. Unless one's need is trivial or very specific to a narrow scenario, frameworks are helpful. At the least, they give new devs a common understanding to begin from when they join or take over an existing project.
  • deleted 5y ago
    [deleted]
  • Zababa 5y ago
    We have a custom framework at work, with a really large codebase, and I find it was easier to understand than any open-source framework I've worked before, because everything is well-encapsulated and changes have very local consequences. That wasn't my experience with most open-source web frameworks, that often seem optimized for conciseness and people that already know them. I also reject the idea of "They either use an existing framework, or they eventually end up creating a custom framework which only they understand and which gets thrown out and replaced with a common framework when they leave the company". The popular open-source frameworks were created by people like you and me. Those people were good, for sure, but not perfect, just like us. They also often try to make something very generic that may not fit your specific use case. Trying to bend a framework to do something it's not meant to isn't better than writing your own code. I think that these days we have too much worship of open source code. Sure, not having to write code is sometimes very nice, but sometimes a few lines of code can help you avoid a dependency.
    • blunte 5y ago
      Isn’t your custom framework exactly what I said? Use an existing one , or write one that only you (and your team) know. Of course, the bigger your codebase and the more unique your needs, the more reasonable it becomes to create your own.
      • Zababa 5y ago
• awkward 5y ago
  This article from 2005 definitely captures some sillyness around dev work at the time, but in retrospect a lot of that was caused more by Big Objects than by frameworks themselves, although Big Objects was definitely enabled by frameworks. Big Objects was the idea that in the future, basic doing stuff level code would be fully replaced by bought or open source objects that would plug in in standard ways to industry wide interfaces. It was nuts, and was largely driven out by ruby and python gaining traction, libraries that were marketed as having more pleasant interfaces than their competition, and 'enterprisey' becoming a bad word. Still, you could take a couple swings through the conference circuit around 2004-2006 by saying that the future was kludging together fungible objects in Java or .NET.
  • _448 5y ago
    > the future was kludging together fungible objects in Java or .NET. And, DCOM and CORBA :)
    • parksy 5y ago
      As a web developer in the open source, PHP (YUCK) environment, the single time DCOM has been useful for me was an insurance company who had a government-mandated PDF document they had to send to customers. Could we just generate a document in plaintext? No. It had to be pixel perfect dummy. And PDF! Could we just recreate a pixel-perfect HTML to PDF template? No. That would take weeks and the client only budgeted a few hours. So I asked, how do they do it currently. And they sent over a mail-merge MS Word template. We said, hey, so, we use PHP, open source, Linux. TOO MANY WORDS WE'RE PAYING YOU TO MAKE IT WORK. Could we use the template in an open source framework compatible with the PHP solution we'd built? Yeahhhhhhhh... but no. The open source framework mangled the fonts, layout, and the PDF rendering was bodgy to say the least. And yes, we went back and asked really, trully, honestly, does the government really give a shit if this document is not formatted exactly the same as whatever law they apparently passed said it had to look like. No dice. So we could have used any language I guess, but we were familiar with PHP. PHP has a DCOM extension that only works on Windows. So I spooled up a Windows Server instance (firewalled within the DC of course) and installed XAMPP and did a bunch of config to ensure it stayed updated automatically and rebooted every night at 1am. A small PHP script on the Windows server provided an API the website could call at any time. The Windows PHP endpoint had an unzipped DOCX, the script would copy the folder, search-and-replace based on API inputs, zip it up as a new DOCX file, opened in Word with DCOM to save as a PDF which was then streamed back into the website's logic all in the same POST request that a client submitted. It was a kludge, I could think of other ways to do it today, but at the arse-end of a project with an apparent doomsday requirement suddenly dropped in the mix, in the end it took about three days to implement when at the time we were facing a crisis. So yeah, give DCOM some flak I guess because it failed to launch but it saved one small project for one small insurance company. Edit to add: That solution ran for years without issue until the company merged with a larger healthcare provider.
• Zababa 5y ago
  I wonder if it's also a rant against "old frameworks". When a framework is young, everything is easy and optimized for newcommers. When it starts getting old, everything becomes optimized for framework users that already know that framework. At first everyone used $framework because they needed a hammer. Then their requirements changed, so the framework changed, in response to the initial users. And then it changed again, and again, and again.
• denton-scratch 5y ago
  The factory-factory-factory thing is quite an old joke. There was one version about creating a double in Java: AbstractFactoryFactory->createAbstractFactory()->createFactory(Double)->createDouble(1.0)->getValue(). Or something like that.
• rexstjohn 5y ago
  Frameworks are a whole discussion about the topic of complexity, switching cost, sunk cost, incentives, personal preference, market position and job security. I built enterprise B2B applications for several years, saw a lot of frameworks come and go. Worked on technical evangelism for many developer products, hardware + software. Job Security: - The internal framework architect / maintainer is unfireable - Building a framework is high prestige, worth potentially millions (contracts, books, consulting) if it catches on (see: Ruby on Rails) - Successful frameworks spawn massive industries (React training, anyone?) There are tremendous market incentives to try to build and market a framework. Even if you fail, you learn a lot by trying. For the most part; the act of Building a framework is nearly always a good idea for career purposes. This is part of why there are so many of them. And it’s fun. Programmer Preference: - I have rarely seen two programmers agree, or be happy about the most basic decisions in same code base: capitalization etc. - Programmers are highly particular, the odds two programmers will love each others code is close to zero Thus: A framework represents one programmers attempt to fully encapsulate their entire vision of “how it ought to be done.” This vision is often non-transferable. Complexity: A program of any size involves thousands of decisions that form an interlinking network. Largest application I have written was 100,000 lines of C. Relied on many external libraries, user experience and design decisions. Altering a framework by swapping out a single component can have cascading effects throughout entire system and to the user of the framework. Who is going to train everyone to go from Objective-C to Swift, for example? This makes frameworks highly brittle. Which leads to topic of sunk cost / switching cost. Switching cost: Once a framework changes or a new framework arrives, programmers must make an economic decision. Switch to new framework (lose time and money) or keep going switching is painful. Meanwhile, new crop of learners focusing on new framework get ahead learning that. Too bad for you: Your experience in Spring doesn’t translate to new framework XXX. Anyways: I can talk about the sources of the problems, but it is unlikely to ever get solved by humans writing code. Programming is just a complex field.
  • commandlinefan 5y ago
    > This makes frameworks highly brittle Inevitably, popular frameworks address this by making themselves so configurable that you can use them however you want... defeating the purpose of using a framework in the first place.
• mikewarot 5y ago
  Every time I look at modern source code, with hundreds of lines of classes, constructors, setters and getters that could be done with a record type or two, and far, far less code, I have this same feeling.
  • the-pigeon 5y ago
    Context is everything. Writing an app that going to do like 3 things? Keep it barebones. Writing an app that will eventually be 100k lines of code that runs a business. Spend a lot of time organizing and abstracting! Mistakes in your architecture will be expensive to correct but balance avoiding those with premature optimization. And beyond just the purpose of the app, remember who is going to build and maintain it. A project with 100 engineers and a project with 1 engineer should use very different architectures and project management regardless of the problem they are solving.
    • ratww 5y ago
      Nah, all this is just rationalisation. I've already heard this a hundred times and seen it go awry every time afterwards. Complex architectures and unnecessary abstraction are the main reason lots of apps "eventually" get to have the 100k lines of code you mention and require those 100 engineers to maintain in the first place. It's a self-fulfilling prophecy: When you follow the complex architectures where you need "hundreds of lines of classes, constructors, setters and getters that could be done with a record type or two" that GP mentioned, it's no wonder that the software reaches 100k LOC. Could have been 10k or 20k if the grandparent did it. When there are too many levels of abstraction to navigate, it's no wonder you need 100 engineers to maintain. Could have been 5 or 10. There is nothing preventing those complex apps from using something that's more expressive and simpler like the records pointed by GP. And there is absolutely nothing in the popular complex architectures we see everyday that is proven to be inherently scalable. As long as the original goals are maintained, you'll still reap the benefits: testability, composability, predictability, maintainability. And you don't need complexity to reach those goals. In fact, complexity is what people should be running away from to get to them. If you want to burn both money and time for no future benefit other than having a behemoth of a project, however, that's your prerogative. The only major issue with "simpler code" as advocated by GP is that it's not sexy. You can't put "wrote simple code" in your resumé.
• deleted 5y ago
  [deleted]
• a-dub 5y ago
  i saw the title and thought "java", then loaded the story and in the first paragraph found a java apology. my suspicions immediately confirmed. lots of really sharp people work in java, what is it about java that encourages this? is it the aggressive object orientedness of the language? or is it maybe the really strong ides/tooling that people use that encourage creation of lots of classes so that nice little tree view on the left gets populated with things that look like they should go there? or is it the design of the core libraries and j2ee that nudge people in that direction? why does the java universe have more frameworks than programs and why do they all seem to want to pack your brain with so many useless abstractions that your skull wants to split open?
  • kerblang 5y ago
    Obviously the more people using a language, the more 3rd party libraries/frameworks proliferate, of course, and Java is very popular. But: Technologies are separate from their cultures. You might think the tech enforces its own culture, but that's a half-truth at best. Most language designers are pragmatists at heart, and inasmuch as they remain leaders, that sense of pragmatism is cultivated within the community around their language. For example, Python's creator - Guido VR - remains a very emphatic leadership figure within the culture, so that it's a culture big on pragmatism, not just because of Python the technology, but because of Guido's leadership. Also ref. Rob Pike, or in a different technical sphere, Linus. With Java, James Gosling started receding into the background when "Enterprise Java Beans" came out, because he knew that was garbage tech and he was being shushed by the corporate honchos, so a leadership vacuum appeared in his absence. Any and all asshats proclaimed themselves the experts on what programmers really need and started pushing a lot of junk frameworks that the community happily adopted, being readily impressed by the self-confident asshats, and really, just about anything compared well to EJB. So nowadays many folks would find it hard to believe that the creator of Java was a pragmatist at heart, but yeah, he was; he just didn't stick around as a leader.
  • zorr 5y ago
    In a time before Rails and Django and way before Nodejs there were not that many programming languages available to do big backend or web projects. Java and C++ were the obvious choices as those languages were available, being thought in schools and used in the industry. Both languages lean heavily on Object Oriented principles. It was around then that books like Refactoring, Clean Code and Gang of Four design patterns were popular. Maybe the Domain Driven Design book as well. Dependency Injection. JSON wasn't big yet, XML everywhere, SOAP and Corba for RPC. Applications weren't run standalone like they are now, instead they were served by application servers like Glassfish and Tomcat. Java jumped on that enterprise bandwagon. J2EE standardized a lot of things like those application servers and introduced concepts like Enterprise Java Beans. Frameworks like Spring and Apache Struts became popular as they handled all the common stuff. It was also around the same time that Extreme Programming, Pair Programming, Test Driven Development, Agile and Scrum were massively adopted in software projects. The whole Java enterprise framework thing was a child of its time. Then later frameworks like Ruby on Rails and Django entered the scene. Leaving a lot of the "legacy" stuff behind and improving on the annoyances of J2EE. The Java frameworks adapted and started modernizing. Configuration and DI moved from XML to annotations, SOAP was replaced by REST and JSON, instead of hosting applications on application servers, the application servers moved in-process as libraries. Of course Java being Java with its focus on backwards compatibility, all those new features and improvements were added alongside the old stuff. Adding to the bloat of the frameworks with abstractions on top of both old and new methods under a common interface. Meanwhile new frameworks and languages popped up. From scratch frameworks that learned from the old ways and left all the legacy behind, only supporting modern features. Java and Spring might not be the most popular choice in 2021 but I am convinced most of it was all necessary evolution to get where we are now. All that being said. I have since moved on from Java to Kotlin but modern Spring (Boot) is still my go-to solution when I need to write a backend application, and I suspect it will stay that way for a long time.
• anm89 5y ago
  This is a really bad analogy though. A spice rack has to do two things 1) hold spices 2) Not fall apart 3) optional : try not to look terrible If I went through and tried to document every different concern my rails app handles, I 'd probably just give up after a few days of research and a list of thousands upon thousands of concerns. Spice racks don't need to change and evolve over time, a third party can't remotely ruin your life if your spice rack has a design flaw, your spice rack can't make you millions of dollars. So I get that this guy wants to go write tcp/ip stacks from scratch to build his neopets page or whatever but it's the wrong design decision for a vast, overwhelming porportion of projects.
  • gregoriol 5y ago
    I shall disagree on a few points of yours: "Spice racks don't need to change and evolve over time" => why not hold some other stuff? maybe add something to hold fruits later? "a third party can't remotely ruin your life if your spice rack has a design flaw" => have you protected your spice rack against children playing with it? "your spice rack can't make you millions of dollars" => depends on you, not on the rack itself "but it's the wrong design decision for a vast, overwhelming proportion of projects" => really depends on the person doing the code and who will do the future maintenance; updating a framework that evolves fast can sometimes be as hard or harder than maintaining your own code, it's mostly a choice of the developer/development team to make on how they see things going from now
    • anm89 5y ago
      These are all devils advocate answers. None of these are things I would spend a lot of time pondering if I was building a spice rack with the exception of #2 if I had kids which is solved with a single extra screw or a single piece of 3m style adhesive strip How many people spend their free time modifying their spice racks. I'm sure you can find some webpage of someone who has this as a hobby but let's go with less than .01%
      • philwelch 5y ago
        If you apply that analogy backwards, I think it makes an interesting point.
• skytreader 5y ago
  > “Well, the problem with hammers is that there are so many different kinds. Sledge hammers, claw hammers, ball-peen hammers. What if you bought one kind of hammer and then realized that you needed a different kind of hammer later? You’d have to buy a separate hammer for your next task. As it turns out, most people really want a single hammer that can handle all of the different kinds of hammering tasks you might encounter in your life.” This reminded of a recent episode where I had to replace my rear bike tire. I already have a toolset for basic maintenance: a full set of hex keys, flat and philips screwdrivers, track pump, 14/15" wrench, as well as lubricants and cleaning sprays. Served me well so far so I thought all I had to do was buy inner tubes and the tire. Wrong. To begin with, the wrench I had was too short to remove the wheel nut; I had to buy a longer one for better leverage. Then, when removing the old tire, I needed tire levers to get them off. Maybe a better mechanic than me could've McGyvered the operation without tire levers but it blows my mind that I needed such a specialized tool. You will notice all the tools I've had so far were multipurpose, exactly why I bought them. Even the pump can inflate footballs. The name "tire levers" captures their singular purpose perfectly. Anyway, after I accomplished the task, I was quite pleased with myself. I even finally bought a proper toolbox. In my mind I was considering DIYing further upgrades to my bike. What about a new chain? Or why not a new gearset? Nope, turns out I still don't have enough tools to even accomplish this. If you want to unlink your chain, there is a special tool for that too. To remove your cassette you need to keep the gears from spinning with a "sprocket lock tool"[1]. In fairness other tools like the torque wrench and the lockring, aren't so single-purpose but I'm unlikely to use them for something else other than my bike. Lesson of the story: In real life, there are a lot of specialized tools. You can buy a Swiss Army knife but there's a reason why it's not yet the DIY-er's best friend. I agree with the sentiment of the article but I'm even more glad that I'm a software engineer, not a mechanical engineer. [1] I don't know the exact name for the tool but you can see it 23s in https://www.youtube.com/watch?v=9KAaP7pbFV0 https://www.youtube.com/watch?v=9KAaP7pbFV0
  • CRConrad 5y ago
    > To begin with, the wrench I had was too short to remove the wheel nut; I had to buy a longer one for better leverage. When I was young, we used to slip a piece of pipe over the handle.
• TeMPOraL 5y ago
  Couple thoughts: - This wouldn't be a problem if we could have matter replicators like in Star Trek, so I'd have just a single box in my shed that could spit out the exact hammer I want, the exact tape measure I want, and whatever else I need, from nails to three-course dinner. The problem with factories and factory factories is the ridiculous amount of yak shaving that stands between your wish or design and its realization. - The above is also true of frameworks: the issue is that they come front-loaded with accidental complexity. - Where the reality deviates from the hammer story is that, past hammer factory factories, we didn't build universal tool factory factory factories - we've just made Hammer Factories as a Service.
• agentultra 5y ago
  Timely. I am kind of old-school when it comes to game development and recently got into teaching my daughter maths and programming and art through it. It's been a lot of fun. Buuuuuut.... the early stages of starting game development these days are, "What engine do you use?" And honestly it can be a daunting choice. They're all quite large and have their own jargon and way of doing things. I can get through a "Hello, world!" tutorial in an afternoon but it'll take months before I get something useful to work and load my brain with all of the jargon to navigate the documentation and forums... versus writing everything from scratch. It's a slower start but I have already learned a good programming language and can go from there. I don't end up with a black box of performance problems. Nor do I end up trying to shoe-horn my round game into a square peg. It's quite common going down this route to write your own data formats and tools as well: level editors, compilers, debuggers. And the productivity starts going up fast as you build momentum. So I typically go a "libraries not frameworks" kind of approach. Which seems to be entirely alien in the enterprise world. The common wisdom here is to never write your own tools. Always use what's on the shelf and get going as fast as possible. Yet I often end up in those tar pits where cloud costs overrun operating budgets and failures happen constantly without any built-in observability... I wonder why more teams don't build tools for themselves? Is it not as uncommon as I think?
  • 0xFACEFEED 5y ago
    > Which seems to be entirely alien in the enterprise world. There are a few reasons for this. 1) Enterprise is mostly staffed with mediocre programmers. That's not meant to disparage anyone. Even great engineers will produce mediocre work if the incentives are aligned that way. 2) Enterprise problems have more to do with people management than writing the fastest and most cutting edge software. Frameworks can get hundreds or thousands of engineers speaking the same language for writing the boring code (which is the majority of code). 3) Enterprise companies often already have an established business model that works. They often have market dominance in some area and it's okay if their software is a little slower/buggier/etc. Game industry is no different. 4) Enterprise companies often have enormous scope that smaller handmade tools can't always cover. For example your average homegrown UI framework probably won't have accessibility in mind from day one. 5) There is no way to judge the quality of homegrown tools until it's too late. Our industry (like any other) has very loud yet very dumb people who convince others that their way is best. They build up layers of awful tooling/architecture that needs to be rewritten down the road. Frameworks have at least some form of validation. I used to believe the above was fixable. Now I know better and just stay away from big companies. Work is more fun and fulfilling that way :)
• mauritzio 5y ago
  Well at least one can talk together about stuff and then see if the other suffered and dislikes certain parts or maybe finds it great and exactly why. Then you know quite fast how many experience he/she has in the field.
• codr7 5y ago
  I spent the last year "writing" web backends in Java using Spring Boot. Wasted days trying to figure out the latest magic spell to do the most trivial things. This is the kind of code that will be automatically generated any day now.
  • zorr 5y ago
    Any examples of trivial things you've struggled with? My Spring Boot experience is the opposite and it is usually my go-to framework when I need to get a backend up and running fast. It takes 30-50 lines of Kotlin to serve some JSON endpoints backed by a SQL database. And those lines are mostly defining the shape of the JSON response, database model, and hooking up the request route to the controller and repository. All the rest is generated, inferred or in libraries.
    • destring 5y ago
      Same. I've tried other frameworks like Django and even Express, but I still go back to Kotlin + Spring when I need a quick backend for a personal project.
    • codr7 5y ago
      Everything? It's all very opaque and specific to Spring; and it keeps changing every few months, which means that a lot of information online is not applicable. I strongly prefer writing my own scaffolding and pulling in specialized libraries for specific tasks.
• debacle 5y ago
  I was just thinking on this same analogy this morning. What many people don't realize is that there are, off the top of my head, at least a dozen different distinct types of hammers, and then if you're talking working with metals at least a dozen or two more. There are way more types of nails, and then of course you have nail guns, of which there are multiple types, and of course screws. In philips heads alone, you have at least eight different sizes, and then of course flat head, torx (many types), allen (many sizes), square, hex, etc. For drivers you have a basic driver, a driver with swappable bits, a drill (cordless, corded (12v, 14v, etc)), a ratcheting driver (and hex bolts), an air driver, a butter knife, etc. In many cases, there is clearly a "best" choice. If you're putting a treated deck on with nails, you're going to have a bad time. If you're framing with finishing nails, everyone is going to have a bad time. But if you're building a shed, what do you go with? First and foremost, you make sure the fastener you're going to be working with is going to work, and then you choose the one you've worked with in the past, the one you have experience with, and the one you have on hand. Software developers tend to be young. They tend not to have respect for what has come before them. They tend to be really, really fucking bored, nearly all the time. They don't create new fasteners every two months, and switch hammers twice as often because it's prudent, more efficient, or necessary. More often than anything else, it's because they're way smarter than their job demands and they have nothing better to do. There are ways to solve this. There are other professions that solve this. Prescribing statins all day and telling people to lose weight doesn't take a 135 IQ, and yet somehow doctors manage. Programmers need to interact in a more masterful way with their tools.
• z3t4 5y ago
  I like to use training wheels as an analogy. They are great if you want to get started right away and be productive. The alternative is to fall a few times and learn the hard way. The only problem is that when you learn how to ride you can't just take off the training wheels, they will slow you down.
• ralmidani 5y ago
  It’s true that frameworks e.g. Django, Ember, and Phoenix may limit flexibility and scalability in the long-term, but forgoing a framework up-front is, like microservices, a premature optimization; you might become successful enough to need to break things apart, but if you do that too early, it might limit your ability to become successful in the first place. Put 10 React developers in a room, and you will hear ~10 opinions on how to handle routing, state management, tooling, testing, file structure, etc. Startups don’t always have time for that nonsense. True, you may need to work harder to find decent Ember devs vs. decent React devs (and pay the Ember devs higher salaries when you do find them). But they are more likely to skip the bike-shedding, hit the ground running, be productive much earlier, and sustain higher output than their React counterparts.
• paxys 5y ago
  I was waiting for the inevitable "we now sell monthly subscriptions to spice racks, hammers, factories, factory factories..." but I guess 2005 was a bit before the time for that complaint.
• vjust 5y ago
  The hammer analogy seems overdone. The framework , lets say , caters to 60% of your needs (being cautious here). OTOH, If your needs are pretty specific, and you go minimalistic, then you build 60% of your functionality by hand. Yes, code bloat can cause issues, with unused features. I'd rather not spend time building mundane features, and especially in Java. Now if the language you code in, suffers from a lack of good frameworks, but that's a different issue. I wouldn't comment too much on Java, due to an intrinsic dislike for the J2EE environment (and all its baggages - maybe baggage that I have mentally). But in Python I've not found a distasteful framework. There's no single framework that can be like a Swiss army knife, though framework fanatics, by definition will sell that vision.
• throwaway889900 5y ago
  To put another analogy down, it's a coupling issue. Nobody wants to hammer in a nail and then buy a new hammer for a slightly different nail.
• tunesmith 5y ago
  I've always felt like there were two types of frameworks. Both types make the first x% of work relatively easy, but then the two types differentiate based off of how easily it is to drop down and go custom. A framework with strong primitives makes it easy to create custom functionality that is still consistent with the framework's conventions. But a framework that relies too much on magic makes this much harder. It's like all of a sudden you're surrounded with old Mainers saying "you can't get there from here" while you desperately try to cobble some kind of solution using ancient lore documented once long ago in a forgotten scroll.
  • lmilcin 5y ago
    I personally categorize frameworks into heavy and light frameworks. I don't have very good explanation what I mean by heavy/light framework, this is the best I can do at the moment: Heavy frameworks in my understanding are the ones that force constraints on your development process, application design, choice of other technologies and frameworks, on the types of products you can make with it, etc. On the other hand light frameworks are like extensions of your fingers. They don't pretend to know better than you what you are trying to achieve. They just make a particular task easier for you. The issue here is that heavy frameworks do not compose together very well. You can safely have one heavy framework in your application. When you start putting multiple heavy frameworks, they start colliding with each other and you start spending more and more time on resolving various problems that are not inherent to the domain problem that you are trying to solve but rather are completely accidental due to the technology choices you have made.
    • foxbarrington 5y ago
      I think of it as whether or not your app is a cog in the framework machine or the framework is a cog in your app machine.
      • mejutoco 5y ago
        This is a useful perspective. I have often seen the first case called framework, and the second library.
• scop 5y ago
  Tangental, but one of the most useful tools I have my garage is a rubber mallet of all things. I would have never thought a rubber mallet would have so many random, odd-job, uses (e.g. when you need to apply pressure but without breaking force). Makes me wonder what are some software equivalents of "rubber mallet", tools you wouldn't think of but end up using quite frequently and, when you do, its perfect for the job in an incredibly specific way.
  • sgillen 5y ago
    The closest analogy I can think of are just basic data structures. Dictionaries, lists, tuples, sets etc.
• Pensacola 5y ago
  Use the Spring Framework. Within the context of your analogy, I'd not call it a "Universal Hammer," but rather a tool box that contains multiple hammers. For any construction job I've encountered, there's a tool in that toolbox that will handle it.
  • smegcicle 5y ago
    and the joke is that for every tool in that toolbox, there's an equivalent tool in the form of 'don't use java'
• agent327 5y ago
  Can someone explain this for someone who is not a web developer (which I'm guessing this is aimed at)? So there are frameworks out there that... generate frameworks that generate frameworks that generate websites? That seems excessive, even by web standards.
• SavantIdiot 5y ago
  This article is bullshit. And 16 years old. No one is taking away your hammers. You are free to code native JS. If you want to reinvent the wheel every time you start a project, go nuts. I want to buy pre-made wheels. They don't have to be a certain color with a special font, just round, rubber and reliable. The problem is today there are wheels and wheel factoriess and types of machines that use wheels, and their support levels vary wildly. Some wheels only go on square axles, some factories made great wheels and then closed up without warning, others only go on boats. E.g., VueJS is awesome and heavily supported today. But lots of the tooling around VueJS doesn't keep up with the changes (cough webpack/fusebox cough), so huge ecosystems built without forward support (or a deeper evaluation of their tool) decay rapidly. When I see a package.json boilerplate on GitHub from a year ago with 15 different tools, I know 50-70% of them are going to have problems. You should do a lot of research before bringing in a framework, and understanding the tooling required to make it usable. No one is taking away your hammers, but don't expect the latest stupid multi-gadget you bought on QVC at 3am and built an entire ecosystem on to exist forever.
  • ok123456 5y ago
    This article was written at the peak of Enterprise Java, and it did have a negative effect on the industry. Tons of boilerplate and fragile XML. "Framework" meant something else then. It more was like a kitchen sink of design patterns and maybe some persistence.
    • SavantIdiot 5y ago
      Ahhhh, good point. Every time I hear framework I immediately think "node/web". My prejudice / conditioning.
  • abhisuri97 5y ago
    "You are free to code native JS". this really does seem like a simple/obvious statement, but I've been in the position where I've taught JS to beginners and holy crap...the amount of people that think they need to know React to do something as simple as a counter is absolutely insane. I think that the space of intro to web dev has been polluted by people pushing frameworks/libraries onto people when really just simple dom manipulation would do the trick. I think the issue the article was getting at is that the idea of the hammer is considered "obsolete"/useless by the experts in the field, leading those experts to push tool making factories onto beginners who really don't need it for their purpose (but don't know the wiser since they're new to woodworking after all). ...or maybe i'm reading too much into it.
• kbuchanan 5y ago
  Learn Clojure. Then you can spend the rest of your life building with hand tools, lol: https://www.youtube.com/watch?v=ShEez0JkOFw https://www.youtube.com/watch?v=ShEez0JkOFw (Seriously, though, Clojure is awesome—but occasionally I miss the guardrails of a framework.)
• unixhero 5y ago
  So... Why did it have to be Java?
• Yhippa 5y ago
  Around 2015 I worked on a Liferay Portal project and worked with a designer to make portlets that consumed and displayed data from various API's. It was actually not bad and I didn't have to spend a ton of time onboarding. I was able to become productive quickly. It's decidedly unsexy to have to put "JSR-168" on your resume but it felt fun at the time because of the velocity I was able to achieve.
• intellix 5y ago
  Frameworks make the hard things easy and the easy things hard
  • kristopolous 5y ago
    Or easy things hard, hard things impossible, and optional things mandatory. They solve one problem by giving you two new ones. Then they scold you for not following arbitrarily decided conventions. They corner you into using inferior janky solutions that do less with more and prohibit consolidation, abstraction or aggregation because ahem, that's their job to do, not yours. Instead You are supposed to be stupid and do things naively regardless of the fact that's how piles of garbage get made It's like relying on the worst engineers you've ever worked with and you aren't allowed to change their code. Awesome I use them all the time professionally because I feel like it's what I'm supposed to do but good lord almighty are they ever totally broken bullshit
• PeterCorless 5y ago
  Frameworks that work — or at least seem to (imo): • Tokio, Glommio (Rust) • Seastar (C++) • React, Node, Angular, etc. (all JS) • Django, AIOHTTP (Python) Each of which seems to be its own "hammer" for various problems. Yet each is also a kind of "factory" to make specialized "hammers," if you will. ex: Seastar is a shared-nothing, highly distributed, highly async framework upon which folks have built a database (Scylla — disclosure, my employer), but also a streaming data platform (Redpanda), and a storage platform (Ceph's replacement, Crimson). So maybe the one option the author left out is "a factory-building hammer."
• ant6n 5y ago
  I feel like coding in general has broken down. I used to do a lot of coding until about 5 years ago. Back then Google still worked, stack overflow still worked - at least in my memory. Now I'm coming back to coding and I'm having trouble reading a MP4 video and showing one frame as an image using python. I've never done it, but it's a simple task. Except Google keeps sending me to the wrong libraries (the ones that don't work or are badly documented), and I end up hitting bugs and error messages that seem impossible to google either. Without a working search engine, and with the proliferation of a huge number of weakly documented or poorly working libraries, coding new things by yourself is really not fun anymore. (Or maybe I'm getting old and just don't have the patience to spend any amount of time on seemingly trivial tasks and boilerplate?)
  • wheybags 5y ago
    Video is just complicated. The libraries have to be native, because of performance (even if you don't need the performance, the kind of person who writes a video decoder from scratch will), so they have to be built as a c extension. Which means you need a c build environment, and all the complexities of setting that up. And then the api will be "bent" around high performance patterns, which might not be obvious if you're new to that field. I remember when I first did some graphics programming I couldn't understand why people were using char* all over the place instead of a 2d array class which contained instances of a Color class with all sorts of fancy getters and setters. After a few years working with graphics code that question just doesn't seem reasonable anymore, my frame of reference has changed. If I were to write docs about a new library I made, it would be hard for me to write for a new person, even if I was a good writer, and genuinely tried. Many makers of open source libraries are not, and do not try (and noone's paying them to, so why should they, if they don't want to). So yeah, basically, I think it is just a hard problem in easy problem's clothing.
• ashishb 5y ago
  https://docs.spring.io/spring-framework/docs/2.5.x/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html https://docs.spring.io/spring-framework/docs/2.5.x/javadoc-a... - Convenient proxy factory bean superclass for proxy factory beans that create only singletons. Somehow, only Java seems to suffer from this.
  • deleted 5y ago
    [deleted]
• wheresmycraisin 5y ago
  Article author is not a wood worker -- generally you would not use hammers and nails for small projects like that. Glue would be a much better choice. You would use nails for homes (framing) though.
  • CRConrad 5y ago
    > Article author is not a wood worker -- generally you would not use hammers and nails for small projects like that. Glue would be a much better choice. In my day, we usually used both. In retrospect, the nails were probably mostly for holding it together tightly while the glue dried, but we left them in.
• clem 5y ago
  You can tell it was written in 2005 because there's no mention of General Purpose Tool Building Factory As A Service.
• dang 5y ago
  Past threads: Why I hate frameworks (2005) - https://news.ycombinator.com/item?id=12635142 https://news.ycombinator.com/item?id=12635142 - Oct 2016 (65 comments) Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=9203959 https://news.ycombinator.com/item?id=9203959 - March 2015 (62 comments) Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=6542817 https://news.ycombinator.com/item?id=6542817 - Oct 2013 (36 comments) Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=6283601 https://news.ycombinator.com/item?id=6283601 - Aug 2013 (117 comments) Why I Hate Frameworks - https://news.ycombinator.com/item?id=2787525 https://news.ycombinator.com/item?id=2787525 - July 2011 (99 comments) Why I hate frameworks (2005) - https://news.ycombinator.com/item?id=1533274 https://news.ycombinator.com/item?id=1533274 - July 2010 (54 comments) Why I Hate Frameworks - https://news.ycombinator.com/item?id=431786 https://news.ycombinator.com/item?id=431786 - Jan 2009 (124 comments) Why I Hate Frameworks - https://news.ycombinator.com/item?id=95722 https://news.ycombinator.com/item?id=95722 - Jan 2008 (17 comments)
• RandyRanderson 5y ago
  This guy's argument (in a nutshell, heh): I want to build a spice rack, do you have any oak tree seeds? I do have to say, though, a lot of things I wrote ~17years ago probably haven't aged well either so...
• benjismith 5y ago
  As the original author of this post, I'm always amused to see it coming back again and again on Hacker News. A lot has changed since 2005, but a lot of things have stayed the same. What a weird craft we practice... Anyhow, thanks for all the laughs, everybody!
  • throw_m239339 5y ago
    You should write a follow up and link that to the original post.
• ehnto 5y ago
  If I am working in a team, I prefer frameworks because it provides a set of idioms and documentation out of the box. That's great for making sure we are doing things consistently across the team and making sure it's harder for new devs to get stuck spinning their wheels. It can make hiring easier too, but I would still hire a good dev without specific framework experience. Solo projects it really depends on the size I expect it to get.
• fdschoeneman 5y ago
  Architecture Astronauts. https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
• DeathArrow 5y ago
  I read it as more of a critique of design patterns.
• bryanrasmussen 5y ago
  >When we really looked at the situation, we determined that that’s just too complex for someone who really just wants to build a spice rack.” hmm, I think the secret of this text is actually the hardware salesman has ESP and is messing with Fredrik Holmqvist.
• OneTimePetes 5y ago
  Frameworks are the "No-Code"-solutions of programmers. Like these they work well for the intended purpose and become a horrible pain, if you try to venture of the beaten path. To expand them, to cover the whole solution space, destroys the framework, due to bloat and the huge code necessary to solve "all problems and have all the answers."
• blodkorv 5y ago
  Are there any big projects done without being developed into a framework?
• bob229 5y ago
  Boring tripe
• Graffur 5y ago
  While there is a good underlying point I don't enjoy the analogy and I am glad other people have pointed out its flaws.
• deleted 5y ago
  [deleted]