Live data from Hacker News

Why I Hate Frameworks (2005)

factoryfactoryfactory.net

271–280 of 407 posts

Re: Why I Hate Frameworks (2005)

#271

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…

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.

Re: Why I Hate Frameworks (2005)

#272

Earlier quoted context omitted.

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 common…

> Oh, you want routing? "Not my business", says React. Go add a routing library Great, now I have to sort through hundreds of different routing libraries and dozens of different build systems, and then do it all again when I need a state library. This is why people hate React.

Most often you don't have to go through so many. The community usually has some preferred selection of tools and you have to choose from 2-5 different options. You still need to do some research but it is not as bad as you present it. The advantage of this is that better tools may replace worse tools and totally different approaches can be tested whereas you have to hope in a framework that the initially chosen strategy can be improved enough.

Re: Why I Hate Frameworks (2005)

#273

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 comple…

> 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 differe…

What you wrote matches my experience. Not that I approve of it, of course, but it is often like that.

"The senior in the team is in charge of deciding what approach to use."

The only thing I'd like to add is that the senior is rarely free in their decision. It is often an unspoken choice dictated by culture and upper management. (Ironically it's worse in companies with technically apt management.)

You work in a Java shop, everything else than the couple of standard Java frameworks will be an uphill battle and you bear all the risk to get your problems blamed on your framework choice.

This is not an excuse of course, but unfortunately our choices are rarely by technical merit alone.

Re: Why I Hate Frameworks (2005)

#274

Earlier quoted context omitted.

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

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.

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.

Re: Why I Hate Frameworks (2005)

#275
post #22

Related: Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=28920095 - Oct 2021 (296 comments) Why I hate frameworks (2005) - https://news.ycombinator.com/item?id=12635142 - Oct 2016 (66 comments) Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=9203959 - March 2015 (63 comments) Why I Hate Frameworks (2005) - https://news.ycombinator.com/item?id=6542817 - Oct 2013 (37 comments) Wh…

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 wi…

There are quite a few titles which have appeared on the HN front page more than once. I've got an archive that's current as of a week or so back, and it shows 1,734 repeated titles.

The following 39 titles have appeared on the front page 5+ times, based on an exact text match, excepting a year indicator in parentheses, e.g., "(2023)". Note that the apostrophe glyph differs in the 2nd & 3rd entries for Peter Roberts AMAs:

     1   10 OpenSSL Security Advisory
     2    7 I'm Peter Roberts, immigration attorney who does work for YC and startups. AMA
     3    7 I’m Peter Roberts, immigration attorney who does work for YC and startups. AMA
     4    7 Richard Feynman and The Connection Machine
     5    7 The Architecture of Open Source Applications
     6    7 The TTY demystified
     7    7 Why GNU grep is fast
     8    7 You and Your Research
     9    6 Bit Twiddling Hacks
    10    6 Dictionary of Algorithms and Data Structures
    11    6 How to be a Programmer: A Short, Comprehensive, and Personal Summary
    12    6 The Bipolar Lisp Programmer
    13    6 Why Lisp?
    14    5 A Primer on Bézier Curves
    15    5 A regular expression to check for prime numbers
    16    5 Advanced programming languages
    17    5 Akin's Laws of Spacecraft Design
    18    5 Ask HN: Idea Sunday
    19    5 Ask HN: What are you working on?
    20    5 Beej's Guide to Network Programming
    21    5 DNA seen through the eyes of a coder
    22    5 Data Structure Visualizations
    23    5 How Software Companies Die
    24    5 How to Read Mathematics
    25    5 How to Write a Spelling Corrector
    26    5 Learning Advanced JavaScript
    27    5 Notation as a Tool of Thought
    28    5 Statistical Data Mining Tutorials
    29    5 Structure and Interpretation of Classical Mechanics
    30    5 Teach Yourself Programming in Ten Years
    31    5 Ten Rules for Web Startups
    32    5 Terms of Service; Didn't Read
    33    5 The Book of Shaders
    34    5 The Scientist and Engineer's Guide to Digital Signal Processing
    35    5 The Tao of Programming
    36    5 The case of the 500-mile email
    37    5 Who Can Name the Bigger Number?
    38    5 Why Lisp macros are cool, a Perl perspective
    39    5 You can't tell people anything

A further 67 titles appear 4 times each, 259 appear 3x, and 2,120 appear twice.

("Front page" here means the archived HN front pages under the "past" link at the top of the page here.)

Data through 2023-06-21.

I could run the analysis based on the URL rather than title, but that would require parsing the raw HTML which I've yet to do.

Re: Why I Hate Frameworks (2005)

#276

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 comple…

> 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 differe…

Thing is, I've had non-Seniors-Developers asking for more complex stuff as often as I had seniors doing it.

It's cultural. Complexity is often part of developer culture, period.

I've even had a non-technical CEO asking to use Angular around 2013-2014. Developer culture is leaking.

Also a lot of accidental complexity comes from the business/staffing side. So, you need to have 200 developers because some high-up said so? Better jump on that Kubernetes and Microservices train. Are the business processes more complex than they have to be because of inertia and disorganization? Let's spend a million bucks customizing that off-the-shelf ERP system.

Re: Why I Hate Frameworks (2005)

#277
post #59

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 framewo…

Laravel is prime example of a bad framework trying to reinvent the language, educating young developers to use it and its ecosystem and to never get out of the stranglehold.

I'm not sure what made you think it's an "appropriate" framework, it's literally antipattern on antipattern and it's not even the worst thing, neither is the fact it's 10x slower than anything else out there - what's worst is the blatant lying, bunch of security issues and using it as an advertising platform to push subpar services onto devs stuck with it.

Re: Why I Hate Frameworks (2005)

#278

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…

Ah, but that is exactly where the carpenter analogy truly works - a good carpenter understands the strengths and weaknesses of all those techniques, and when to apply each. Just like a good software dev understands when to apply frameworks and libraries, and knows enough about each to choose the right ones. (And yes, which ones just aren't quite ever the right answer.)

Now, do we do that well? Clearly not. But that is the right place to collectively focus on improvement. We don't need to argue that frameworks or other solutions either should or should not be used, we need to focus on why they exist, what problems they solve, what problems they cause, and drive understanding of when to use each tool.

Re: Why I Hate Frameworks (2005)

#279
post #47

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 re…

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]

Re: Why I Hate Frameworks (2005)

#280
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.
Post reply on HN