[HN Gopher] "Why I Hate Frameworks", or Nobody Buys Hammers Anym...
___________________________________________________________________
"Why I Hate Frameworks", or Nobody Buys Hammers Anymore (2005)
Author : zkldi
Score : 293 points
Date : 2021-10-19 16:34 UTC (6 hours ago)
(HTM) web link (www.fredrikholmqvist.com)
(TXT) w3m dump (www.fredrikholmqvist.com)
| agent327 wrote:
| 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.
| unixhero wrote:
| So... Why did it have to be Java?
| dexwiz wrote:
| 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.
| continuational wrote:
| I couldn't agree more. Highly configurable frameworks are
| essentially just home grown programming languages, in which
| your code just happens to live in a configuration file.
| ozim wrote:
| 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.
| a-dub wrote:
| 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?
| zorr wrote:
| 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.
| a-dub wrote:
| > 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.
|
| you forgot perl, where perl plus a handful of database and
| session management cpan modules were kind of the ruby on
| rails of the era. (with mod_perl on apache as the application
| server, of course) perl was huge in infrastructure, but also
| powered quite a few massive web properties. the tradeoff
| arguments were interesting... while static analysis was weak,
| developer productivity seemed to massively overshoot what
| you'd see in java teams. although long term scaling and
| maintainability probably did suffer.
|
| > It was also around the same time that Extreme Programming,
| Pair Programming, Test Driven Development, Agile and Scrum
| were massively adopted in software projects.
|
| i remember being doing a training and the instructor preached
| all these gospels. i asked them why they weren't used in open
| source so much and they replied that open source software was
| okay, but that all the best software was constructed with
| these fancy philosophies and was hidden inside of companies.
| that was when i stopped paying attention to this person.
| robotresearcher wrote:
| Article is from 2005. Java has lost mindshare since then.
| kerblang wrote:
| 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.
| z3t4 wrote:
| 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 wrote:
| 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.
| tunesmith wrote:
| 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.
| colhom wrote:
| cough glibc cough
| lmilcin wrote:
| 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 wrote:
| 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 wrote:
| This is a useful perspective. I have often seen the first
| case called framework, and the second library.
| denton-scratch wrote:
| > useful
|
| I don't agree that it's useful (not sure if you were
| being ironic). All of the "frameworks" I've used were
| determined to make my cog their subject. I haven't come
| across a framework that was content to be a cog in my
| machine.
|
| [Edit] Subject, as in royal or imperial subject.
| [deleted]
| [deleted]
| dnautics wrote:
| I think you want a framework that is heavy but swappable for
| stuff that is critical and easy to get wrong (e.g.
| authentication, http header parsing, input validation,
| routing, preventing sql injections etc) most of these things
| are "finalizing" concerns anyways, so you don't really need
| them to compose. And light for everything else (e.g.
| authorization, operations, templates, etc).
| lmilcin wrote:
| Being able to swap things out is one way to make a
| framework lighter.
|
| Light ones: if I have a problem with the framework, I am
| guaranteed to have a local solution without getting rid of
| entire framework. For example, if Spring Framework does not
| let me create an object in a particular way, I can write my
| own function to create the object. If the way configuration
| is being located does not suit me, I can replace the
| mechanism without getting rid of Spring Framework or even
| configuration -- just by implementing couple of interfaces.
|
| Heavy ones: if I want to do something that has not been
| planned for by framework creators I can potentially run
| into problems that I have no way out of without getting rid
| of it all.
|
| An example would by systemd: it is built in an
| unnecessarily heavy way by insisting on you using it all.
| For example, if you don't like journald or can't use it for
| some reason -- tough luck. The only way to get rid of
| journald is to get rid of entire systemd.
| selfhoster11 wrote:
| Composing light frameworks can make for a frustrating
| developer experience. Individually lighter, when combined,
| the end result may end up more "uneven" compared to the
| cohesion of a single heavy framework. VS Code is one example
| of the composition of lights approach.
| treeman79 wrote:
| Rails community sees this a lot. Rails is fairly heavy and
| there are some great lightweight solutions like Sinatra.
|
| But what I've seen many times is that by the time you
| finish adding all the missing bits you end up with
| something as heavy as Rails, but non-standard. So now
| maintaining it is a huge burden.
| echelon wrote:
| Another perspective is whether the framework is declarative
| or imperative.
|
| If your code describes what is to be done without making the
| motions itself, you're using a very heavy framework or,
| honestly, DSL. These types of frameworks have lots of magic
| built into them and favor convention over configuration.
|
| If your code performs actions imperatively, and moreover if
| it's explicit rather than implicit, then it can be easy to
| wrap or replace the framework. It's like a library.
| thrashh wrote:
| From my experience, the libraries and frameworks that have well
| designed primitives (and ideally primitive interop within the
| community) are the ones that generally "win."
|
| And also my experience, very few libraries and frameworks are
| built on reusable internal primitives. I just tide time until
| those frameworks die so I don't have to learn them.
| dkarl wrote:
| The best frameworks are the ones that cater to users working at
| a range of abstraction levels. Akka is a good example of a
| project that aspires to this and largely succeeds at it. If you
| are working at a particular abstraction level and need to drop
| down, it's a consistently polished experience. I have never had
| a shocking moment where I opened a door that users weren't
| supposed to open and saw something that users weren't supposed
| to see. Everything is created to be seen, understood, and used.
| And even in the rare cases where it's not supposed to be used,
| it's still designed to be seen and understood!
| binwiederhier wrote:
| It's funny to hear someone say so many nice things about
| Akka.
|
| I work with Akka streams, actors and http every day and and
| while I agree that Akka is really well documented, incredibly
| powerful and as you say polished, it is also the bane of my
| existence. It has made what could have been a simple
| application a rather painful experience for newcomers and
| even very senior engineers. The complexity of a framework
| like Akka is a huge barrier of entry for engineers and
| hinders development more often than it helps.
|
| This is all obviously very subjective.
| debacle wrote:
| 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.
| intellix wrote:
| Frameworks make the hard things easy and the easy things hard
| SavantIdiot wrote:
| 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.
| abhisuri97 wrote:
| "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.
| beebeepka wrote:
| certain company has spent considerable resources continuously
| promoting that framework. At times I seriously think it has a
| real chance of evolving into a full blown religion.
|
| I am only semi joking
| ok123456 wrote:
| 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 wrote:
| Ahhhh, good point. Every time I hear framework I immediately
| think "node/web". My prejudice / conditioning.
| TeMPOraL wrote:
| 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.
| anm89 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| If you apply that analogy backwards, I think it makes an
| interesting point.
| fennecfoxen wrote:
| > why not hold some other stuff? maybe add something to hold
| fruits later?
|
| What?? No. I have a fruit bowl and a fridge drawer to hold
| fruit. Why would I want to glue them together? So I can use
| precious refrigerator space to hold my cayenne powder? Maybe
| I can add a cell phone to my vacuum cleaner next, attach a
| paintbrush to my broom, or combine a lawn mower with a
| trowel.
|
| These things do not belong together. I appreciate the vendor
| would like more of our kitchen storage spending, but that's
| his problem, not his customers'.
| Lamad123 wrote:
| Excellent case of analogy abuse
| mellosouls wrote:
| (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-2...
| eckmLJE wrote:
| What's funny is that now, 5 years later, all the crazy things
| the writer is parodying sound completely normal to me.
| tehjoker wrote:
| 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?
| count wrote:
| No.
| mhink wrote:
| 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 wrote:
| While fetch rules the browser, it's still anybody's game
| for succeeding request.js for node.
|
| Recently I've been going with got.
| IggleSniggle wrote:
| I haven't really been following, but I just sort of would
| have assumed that node-fetch or equivalent would be
| mainlined into nodejs. I get that nodejs is not in the
| habit of replicating browser APIs, but it seems like that
| one, at least, would be on-point for nodejs.
| SomeCallMeTim wrote:
| Agree on all points...except Prettier, which is manna
| from the gods. Better to get used to it than to fight it.
| Mogzol wrote:
| I actually really like Prettier. It ensures that
| everyone's code ends up formatted the same, and when
| you're working on a project that a bunch of different
| people touch, that makes reading the code so much easier.
| It may not always be beautiful, but at least it's
| consistent and readable.
|
| It also means I have to spend zero time worrying about
| formatting. Now I often just type stuff out on one ugly
| line, then hit ctrl+s and everything magically formats
| itself, it's honestly great. Whenever I work on code
| without Prettier it makes me realize how much time I
| spend just formatting things.
| tehjoker wrote:
| Thanks, that does!
| mnahkies wrote:
| After working with it for a while you get used to the
| ugliness from prettier, but still I really wish JetBrains
| would release their formatter as a prettier alternative /
| competitor.
| [deleted]
| dredmorbius wrote:
| Not sure which planet you're on, but it's been 16 Earth
| years.
| heavyset_go wrote:
| The Hacker Noon article was released in 2016.
| dredmorbius wrote:
| Ah, thought you were referring to TFA, my error.
| dreyfan wrote:
| tldr: OOP sucks.
| zz865 wrote:
| I'm sure Joel Spolsky wrote about absurdities of having factories
| for everything, I can't find it though.
| dstroot wrote:
| 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 wrote:
| aha thanks, maybe I remember it from there.
| vjust wrote:
| 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.
| aazaa wrote:
| 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.
| paxys wrote:
| 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.
| scop wrote:
| 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 wrote:
| The closest analogy I can think of are just basic data
| structures. Dictionaries, lists, tuples, sets etc.
| agentultra wrote:
| 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?
| potta_coffee wrote:
| I'm intellectually interested in writing my own simplest-
| possible versions of game engines, but I have no idea where to
| get started. Do you have any tips or a book recommendation? How
| did you learn?
| ainiriand wrote:
| Game Programming Patterns from Robert Nystrom covered a lot
| of ground for me.
| potta_coffee wrote:
| Thank you!
| agentultra wrote:
| It's hard for me to recall how I learned because my first
| "game" I wrote was in '89 and I wasn't very old at the time.
|
| Maybe check out https://www.youtube.com/watch?v=Ee3EtYb8d1o
| -- I've watched a fair bit of it and many folks agree it's
| thorough and interesting. If you don't know C already he has
| a decent introduction as well.
|
| Maybe not the best place to learn C but it suits well enough
| for game development projects.
|
| The nice thing I find with C is that bringing life back to
| older machines is definitely possible -- the homebrew scene
| for various old consoles is very much alive and well and
| there's probably a C compiler that targets it.
| potta_coffee wrote:
| Thanks!
| 0xFACEFEED wrote:
| > 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 :)
| SomeCallMeTim wrote:
| As someone who started out in the game industry in 1990, I can
| say that being able to choose between competently-built game
| engines is a HUGE bonus.
|
| At last count I'd written six (!!) game engines. Nothing huge;
| mostly "casual" games as the target. One of those engines ended
| up having over a hundred published games written for it,
| though, so at least in that case I got some decent traction.
|
| And honestly? If at any of the times I was starting a game
| engine, I could have just sat down and focused on _writing the
| game_? I would have taken that option and not looked back.
|
| You have to make a decision, when it comes down to it: Do you
| want to write a game? Or do you want to build a game engine?
|
| Because writing a complete game engine can take 2-3 years all
| on its own. And yes, that's counting gluing together existing
| libraries. I never wrote, e.g., a PNG or JPG loader from
| scratch. The engine with 100+ games? I started work at
| PlayFirst and immediately started working on the game engine.
| Nearly six years later when I quit to work on my own games, I
| was _still_ adding features to the engine.
|
| Games were certainly released before that; the first game I
| released was probably only six months in. But the game engine
| (Playground) wasn't very mature yet, and it wasn't until at
| least 2-3 years in that using the engine really had a robust
| set of features (including cross-platform support).
|
| And if you're looking at creating a 3d game, and don't want to
| start with an engine? Well, it can be done, but again, if your
| time budget is three years, at least half that time will be
| working on parts and fixing bugs that a solid engine would have
| handled for you. If your time horizon is shorter, then expect
| even more of your time to be spent reinventing the wheel.
|
| Source: I spent 20 years in the game industry.
| munchbunny wrote:
| > Buuuuuut.... the early stages of starting game development
| these days are, "What engine do you use?"
|
| As someone who started from raw OpenGL and cobbling together
| various libraries (OpenAL, OpenIL, etc.), I think it's bad for
| pedagogy, but I love it for productivity. Just like React.js.
|
| I think there's a huge advantage to not having to spend time
| writing code to glue together asset management to physics to
| animation to graphics to audio to AI and UI, etc., and also
| because scene graphs and entity/component systems are like game
| programming's equivalent to REST and MVC.
|
| So once you know how to work with that stuff, jumping into an
| engine is a great way to get right to prototyping and skip all
| of the setup. But for building up the conceptual
| understanding... it's rough. It's just a totally alien way to
| think about programming if your background is classic
| frontend/backend.
|
| > 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...
|
| That's absolutely a problem, and I totally agree that it's
| exacerbated by starting from Unity as opposed to learning the
| component concepts individually. But that said, Unity genuinely
| saves me a ton of time, even if the result isn't as optimized.
| That goes double for VR, where the sheer conceptual load of
| designing/coding the interaction models makes doing it without
| an engine not really worth it.
|
| > 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.
|
| I think this is a difference of what you're trying to
| accomplish. An engine gets you off the ground much faster if
| you have trained on it because enough of the abstractions are
| common to most games that, for example, reusing a not 100%
| ideal graphics/physics/skeletal animation rigging/key
| framing/audio/collision detection system still saves you a lot
| of programming.
| zubspace wrote:
| I believe, if you really want to understand how a game engine
| works, you need to try to build a game from scratch in your
| favorite programming language. It's a fun exercise and you
| really grow as a programmer. If you use an existing engine, you
| will never really need to know how to initialize a window for
| rendering, you never need to touch opengl/directx/vulkan/etc,
| you never create a rendering loop, a scene tree, implement a
| matrix library, create a basic physic engine or integrate a
| scripting language.
|
| All those things are fun! I know it, because I spent about 8
| years on and off tinkering on my own engine in my spare time
| when I was younger. And what can I show you after all those
| years? A fun tech demo maybe, but other than that, not a single
| finished game.
|
| Game development is different nowadays. To stand out, you need
| to know about game design, concept art, color theory,
| texturing, tile-mapping, lighting, shaders, interface design,
| sound design, sprite animations or skeletal animations,
| networking... The list goes on and on. And then your game also
| needs to be fun!
|
| If you go the route of implementing or integrating everything
| yourself, you will never reach the level of someone who knows
| an existing engine in-and-out. Today, if you want to create
| games, it's far more important to create as many games in a
| short time as possible. Just look at competitions like Ludum
| Dare to realize and appreciate how far even small game engines
| can help you to create a fully fledged game within 48 or 72
| hours. It's crazy. This will improve your skills as a game
| designer far more than building your own engine.
| 1f60c wrote:
| I'm not sure if it matters much in this case--the analogy sadly
| holds up well, if not better--but
|
| > (2005)
| dotandimet wrote:
| Bit of Deja Vu. 2005.
| blunte wrote:
| 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]
| commandlinefan wrote:
| I don't know if I would say that I _hate_ frameworks, but in
| general, I find most of them to be pointless. I use them
| because my teammates insist on them, but I spend far more time
| working around them than I spend taking advantage of their
| strengths - if there even are any.
|
| I've been working with Java for 20 years now, and Spring is the
| ultimate "framework" - it's so framework-y that it doesn't
| actually do anything or offer anything, it's just a thing that
| gets in your way. When people defend Spring, they invariably
| say "but why would you want to do all of that by yourself" and
| I say "do all of _what_ by myself? " The Spring framework saves
| you the trouble of... calling the "new" operator (by making
| everything a global variable)? At least with an ORM framework I
| can see what it actually _does_ , even if I don't really want
| it to do that, but Spring just doesn't do anything except add
| libraries you don't need and make your stack traces useless.
|
| Ok, I take it back, I don't hate frameworks, I hate Spring.
| ryandrake wrote:
| Yea, whenever a new abstraction makes the "you won't have to
| do all these things yourself" promise, I guarantee that the
| abstraction just replaces those things with another,
| potentially bigger set of things you're going to now have to
| do.
| parksy wrote:
| I hated React when I had to jimmy it into a Drupal website, I
| loved it when I was doing React + Redux on a data-driven
| project.
|
| Pre-shopify, I loved Magento when we were just building basic
| eCommerce websites. I hated it when we had to provide bespoke
| functionality to suite various niche business purposes
| because rarely did any of the community plugins work well
| together, and life became a routine of building custom
| intermediary plugins that resolved the conflicts - but at
| least Magento had a way to resolve conflicts between plugins.
|
| I loved Doctrine when I could define my object model with
| simple block comments. I hated it when the client's business
| model enforced an object model incompatible with Doctrine's,
| and we had to extend Doctrine to allow for it.
|
| I tried making a game from scratch many times over the years.
| From writing my own assembly pixel routines (draw a line
| without gaps... that's a fun challenge), to decoupling logic
| from rendering, custom double-buffering, etc. At the end of
| the day, fuck it, Unity does everything I need much more
| efficiently than I have the time to figure out.
|
| Unless you're doing really low-level embedded (and even these
| day's there's off the shelf hardware with frameworks rather
| than bit-bashing IO ports), having no framework at all is
| usually worse than having "a" framework. Want to build an
| entire game engine from scratch or why not just use Unity? If
| you have a good reason and can justify the cost of doing the
| stuff Unity does yourself, just to achieve the stuff Unity
| can't do, then go for it!
|
| Like I guess, I don't hate frameworks, but I don't LOVE them
| either. Pick the tool for the job. I hate jingoism, where
| someone will tell you Redux is the only way we're going from
| now on because functional reactive programming is Jesus, or
| we've decided from now on the project will use webpack, even
| though it's been working fine for a decade using a different
| build strategy. Oh and we need to convert the APIs to GraphQL
| instead of OpenAPI on no budget, it's your fault for not
| understanding best practices duh...
| Zababa wrote:
| 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 wrote:
| 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 wrote:
| > Isn't your custom framework exactly what I said?
|
| No, it's not.
|
| > Use an existing one , or write one that only you (and
| your team) know.
|
| Not only my team, pretty much any people working with it in
| the company. The difference with something like Django is
| that people don't know it before coming in the company,
| which doesn't make a big difference.
|
| To go back to the message I replied to, you said
|
| > "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."
|
| I disagree. There's no reason to replace our custom
| framework, as it's working well and since the codebase is
| getting a bit old, this would be just too much. We also
| have good training material around it, better than what you
| can usually find about open source framework online,
| without even mentionning mentoring. Then there's
|
| > "At the least, they give new devs a common understanding
| to begin from when they join or take over an existing
| project."
|
| The flip side of that is that you need to recruit
| developers that know a framework, which will by definition
| limit your talent pool.
| Pensacola wrote:
| 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 wrote:
| and the joke is that for every tool in that toolbox, there's an
| equivalent tool in the form of 'don't use java'
| awkward wrote:
| 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.
| dmux wrote:
| >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.
|
| Isn't this the same as API's as a service?
| munificent wrote:
| _> 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._
|
| We call them microservices now.
| awkward wrote:
| You just keep putting stuff in smaller and smaller Matryoshka
| dolls and then poof! No more stuff.
| selfhoster11 wrote:
| From "Mortal Engines" by Stanislaw Lem:
|
| > Pyron invented the wire telegraph, and then he pulled the
| wire out so fine, it wasn't' there, and in this fashion he
| obtained the wireless...
|
| (https://english.lem.pl/works/novels/mortal-
| engines/136-intro...)
|
| I always loved that passage and it would always crack me up
| from the sheer absurdity of it.
| selfhoster11 wrote:
| To be fair, they are a little better than the OG technology.
| vaughan wrote:
| Everyone should try to build their own pluggable framework at
| least once, to realize how difficult it is, and to realize how
| small design decisions can cause massive headaches. I think a
| lot of frameworks are the result of someone shipping something,
| it gets popular, and then its stuck like that and they can't
| rethink it.
|
| Having done this helps you to see things in new frameworks that
| will inevitably lead to pain.
|
| As often as people deride it, the Node.js many-small-package
| philosophy (inspired by Unix) is what I keep coming back to. If
| one package doesn't provide the right abstraction to do
| something, if it's built on top of two smaller packages, I can
| assemble a new package with these smaller packages to achieve
| what I want. The smaller the package the better.
|
| From the day the first line of code in a project is written, a
| desire to rewrite from scratch starts to grow - to return to
| the productivity of having an empty slate. If you compose your
| app from small single-purpose packages, rewriting becomes
| trivial.
| mirekrusin wrote:
| What is "Big Objects"?
| awkward wrote:
| A colloquialism that I explain in the second paragraph.
| mirekrusin wrote:
| Oh I thought it's a real thing, started googling it and
| landed on Salesforce's Big Object! Thanks.
| bendbro wrote:
| I suspect the OOP industrial complex like "Big Pharma".
| brabel wrote:
| Big Objects is explained in detail in the Java Beans Spec:
| https://www.oracle.com/java/technologies/javase/javabeans-sp...
|
| The idea may have died, but there's still lots of vestiges of
| it in the Java world.
|
| - getters and setters with standardized names
|
| - Swing mechanics like EventListeners and
| PropertyChangeListener
|
| - Java Serialization
|
| They hoped that a Java bean could be plugged into any UI and be
| visualized, modified and generally integrated into any app, so
| you could "buy" beans made by other developers, for example.
|
| It was definitely an interesting idea, but things went in a
| completely different direction, as we know.
| the_af wrote:
| Even though the Swing thing was java bean based, the idea of
| an "event listener" is a still current and sound idea in
| software development beyond Java.
|
| The funny thing about "standardized" getters & setters is
| that they completely broke OOP and went against this idea
| that Java was "object oriented". One of the most known
| articles of the time was the infamous "getters and setters
| considered evil".
| _greim_ wrote:
| I think sometimes the abstraction moat around an otherwise
| good idea definitely repels would-be adopters, which an idea
| needs to ascend to mainstream success, beyond just technical
| merit.
| _448 wrote:
| > the future was kludging together fungible objects in Java or
| .NET.
|
| And, DCOM and CORBA :)
| parksy wrote:
| 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.
| electroly wrote:
| FWIW, you seem to be talking about regular local COM and
| not DCOM. DCOM is COM-over-the-network, where you can
| create an object on another machine remotely and interact
| with it as if it were a local object. You are describing
| just using a local COM object on that Windows server.
| Unlike DCOM, COM is _extremely_ popular and widely used.
| _448 wrote:
| > DCOM is COM-over-the-network
|
| The hint is in the name: "Distributed COM" i.e. DCOM :)
|
| > Unlike DCOM, COM is extremely popular and widely used.
|
| My understanding was that DCOM is nothing but data
| marshaling and registring GUIDs with Windows registry so
| that the COM object can be created locally/remotely. If
| COM is widely in use, then DCOM should be as well. The
| whole gaming(DirectX) and finance(OLE) industry is built
| on the DCOM/COM infrastructure :)
| selfhoster11 wrote:
| Thank you for sharing this story. I consider war stories of
| this caliber to be unironically heroic exercises of
| thought.
| mauritzio wrote:
| 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.
| Zababa wrote:
| 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.
| cesarb wrote:
| Original:
| https://web.archive.org/web/20180927070411/http://discuss.jo...
| (also has the second part which is missing on the link above).
| throwaway889900 wrote:
| 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.
| mcqueenjordan wrote:
| 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.
| zzbzq wrote:
| It invokes some of the particular absurdity of Spring or
| AspNet, though.
| agumonkey wrote:
| The thing is that computer guys got too much in love with the
| word and started to think framework === full blown 15-tier
| industrial facility.
|
| A good framework removes a chunk of work, guides you for the
| remaining part so you get there quickly but it should stay
| narrow if possible.
|
| here's a small framework: https://imgur.com/a/rBBdRSO
|
| here's j2ee 4 understanding of the term:
| https://imgur.com/a/EH3vpXD
| jaredklewis wrote:
| > The main distinguishing factor between a framework and a
| library is the classic "you call a library, but a framework
| calls you."
|
| This definition does seem to match how I generally hear the
| terms used, but I think whether you call something or if
| something calls you depends more on the function of the
| library/framework than anything to do with the code itself.
|
| I think we generally have "web frameworks" and not "web
| libraries" because if you are making an HTTP sever, then yea
| stuff is going to be calling you. ie.e the incoming HTTP
| requests are going to trigger your code. Now if I have a piece
| of code that extracts URLs from a string, that is obviously
| going to be called by me. That I can see, who is calling who
| has nothing to do with the design of the framework or library,
| and everything to do with the sort of task the framework or
| library performs.
|
| Anyway, engineers obsesses over the distinction between library
| and framework, but it seems fairly mundane from my perspective.
| austincheney wrote:
| When you instead call it a _factory_ analogy, exactly as the
| story reads, it suddenly fits well.
|
| Confusing a _framework_ for arbitrary _reuse_ is perhaps the
| best way to identify developers who aren 't the mythical _10x_
| developer. It is no different than confusing decoration for
| something useful when you are fending off destitution.
| lliamander wrote:
| Yes, a house frame is closer conceptually to a software
| framework than a hammer, but I don't think that's relevant and
| would only undermine the rhetorical effectiveness of the
| analogy.
|
| The purpose of an analogy is fundamentally to describe some
| unknown thing (the subject) by comparing it with a different,
| known thing (the analog) that shares a common attribute with
| the unknown thing. The value in the analog is not in how many
| attributes it shares with the subject, but in how salient it
| makes the particular attribute you wish to highlight.
|
| Consider when a boxer is described as having a "glass jaw".
| Here, the subject is the boxer's jaw, and the analog is the
| material glass. It would be pointless to complain the analogy
| is a bad analogy on account of the fact that glass is
| translucent whereas the human jaw is not. The point of analogy
| is to highlight that the boxer is vulnerable to impacts to his
| jaw. The value of using glass as the analog is the readiness
| with which we can conjure the mental image of glass breaking;
| the translucency is irrelevant.
|
| Likewise, the point of this analogy about hammers and
| frameworks is that the author wanted something simple that
| would just work, and what he got was an over-engineered mess
| that requires considerable yak-shaving to get it to work. The
| fact that a hammer is more like a library than a framework is
| irrelevant, the point is that a hammer is something _simple_
| and _familiar_.
| Cederfjard wrote:
| Thank you, I appreciate this. It drives me crazy when someone
| dismisses an analogy because some other attribute than what's
| actually being compared doesn't match. Yes, you're right,
| they're not the same! If what you compared were exactly the
| same in every way, they would be the same thing!
|
| I think it's part dishonesty, part emotional attachment to
| the things being compared (you should probably rarely bring
| Hitler into the mix, even if technically it works), and
| partly that some people just don't understand analogies.
| selfhoster11 wrote:
| 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.
| sumnole wrote:
| TIL: https://en.m.wikipedia.org/wiki/COMEFROM
| ItsMonkk wrote:
| 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 wrote:
| 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
| kazinator wrote:
| It's trivially easy to reframe the hammer as a framework; just
| take the point of view that what you're bringing to the table
| is the nail and the two pieces of wood (or other kinds of parts
| on which some type of hammer might be used).
|
| These pieces of yours are "called on" by the "hammering
| framework".
|
| This would all be easier if we had a metaphor-factory-
| generating factory.
| avgcorrection wrote:
| HN: Use the right tool for the job.
|
| Also HN: Always and every time do use a carpenter analogy... or
| something involving woodwork.
| smackeyacky wrote:
| What happened to good old car analogies? This carpenter stuff
| is a little too waxed moustache hipster for me.
| tgb wrote:
| So what do carpenters use for analogies?
| [deleted]
| bhelkey wrote:
| Software Engineering.
|
| "Just imagine the facade is the frontend."
| [deleted]
| Uehreka wrote:
| > "you call a library, but a framework calls you."
|
| This is why I don't like when people say "React isn't a
| framework, it's just a library". Almost all of my React code is
| "called by React" with the one exception being
| `ReactDOM.Render()` (I don't count that since every other
| framework has some analogous "bootstrap" instruction).
|
| Now if folks want to argue that React only handles the "view
| layer" without providing a built in state management solution,
| that's absolutely true (and considered a separation-of-concerns
| positive by a lot of people including me). But I feel like so
| many folks just boil this down to "React isn't a framework,
| it's just a library" and then use that as a segue to negatively
| comparing it with their chosen tool.
| Drew_ wrote:
| > Almost all of my React code is "called by React" with the
| one exception being `ReactDOM.Render()`
|
| It only feels this way because your calls to React are hidden
| away behind JSX. I believe this is also why you can't write
| any JSX without importing the React module first.
|
| If you've ever had the "pleasure" of writing React with plain
| React.createElement() calls (what your JSX ultimately gets
| transpiled to) then I think you would more likely agree with
| the notion that React is "just a library".
|
| Create-react-app is much more akin to a framework in that it
| bootstraps an environment for you where you don't have to do
| any of the things that make React feel like simply a fancy
| library for rendering HTML.
| kkirsche wrote:
| Great resource for anyone interested in this. It's really
| enlightening: https://pomb.us/build-your-own-react/
| imbnwa wrote:
| > If you've ever had the "pleasure" of writing React with
| plain React.createElement() calls (what your JSX ultimately
| gets transpiled to) then I think you would more likely
| agree with the notion that React is "just a library".
|
| I'm not sure why someone would unless you're strictly
| writing static JSX with no components whatsoever as some
| sort of weird replacement for just writing the equivalent
| static HTML. The minute you write a `render` or lifecycle
| method, React is now calling _you_. Not to mention stuff
| like Suspense asking you to throw a Promise to render from
| latest render cache.
|
| I think something like Crank.js[0] is more a view library
| since it puts all the nuts and bolts into userland.
|
| [0]https://crank.js.org/
| Drew_ wrote:
| You use React APIs to do everything you would normally do
| with React. You use the API directly if you don't have a
| build step for your web app and you cant or don't want to
| add one. Since React is indeed simply a library with an
| API, you can progressively integrate React into an
| existing web app in this way (a big selling point in the
| early days that people have sensibly forgotten by now).
| You couldn't progressively integrate a traditional
| framework like Django for example.
|
| Lifecycle methods like render, componentWillMount, etc
| are just callbacks that get fired when you render you a
| component. I don't think any library is immediately
| graduated to the class of "framework" the moment a
| callback is added.
| imbnwa wrote:
| > You couldn't progressively integrate a traditional
| framework like Django for example.
|
| I dunno here, is Rails a server application library
| because I can progressively integrate the different
| components of its total API, e.g. first use ActiveRecord,
| then adopt rails-api for the frontend, then adopt
| ActiveView and Turbolinks for the end-user frontend? Or
| is there different idea of framework at work here?
|
| > Lifecycle methods like render, componentWillMount, etc
| are just callbacks that get fired when you render you a
| component. I don't think any library is immediately
| graduated to the class of "framework" the moment a
| callback is added.
|
| But I don't write the code that says when they're called.
| Backbone is more of a library, for example, since it lets
| me do all that and it can be progressively integrated
| into an app too (I can just use models, I can just the
| views, etc). I mean thats part of why people ran to Ember
| and Angular when they appeared, they didn't feel like
| doing all that.
|
| Also see Crank.js: you can emulate React's Component API
| in Crank, but the reverse is not true. If I'm not writing
| the code that "turns the gears" per se, then to me I'm
| using a framework. That framework might have a small API
| surface, it might have a large API surface. That's how I
| see it at least. A framework to me is defined by a
| certain threshold of abstraction.
|
| This is an async task library because I can opt-in and
| out of, as well as control, or simply replace, the
| scheduler[0]
|
| [0]https://github.com/mitranim/posterus
| bryanrasmussen wrote:
| yes, well if I didn't use most of the built in
| functionality of a framework I suppose it would be a lot
| more like using a library.
| Drew_ wrote:
| Support for JSX is not built into React. React is simply
| a JS library and JSX is not valid JS. So if you add React
| to a web page, and attempt to write logic with JSX, you
| will get syntax errors.
| dexwiz wrote:
| I think React's original goal was to be a library, but the
| community made it a framework, because they could not
| conceive of any other way to operate.
| crate_barre wrote:
| Less that they couldn't conceive of any other way, but more
| so we are slaves to the vdom diffs. That's what we signed
| up for, and boy did we get trapped. Go ahead, put a little
| jquery into your React app, or that animation library that
| looks cool, you'll blow up the whole point of React.
|
| Sorry, you will have to do things React's way until the end
| of time if you want your rendering to be optimal. That
| means whatever it means, hooks, suspense, fibers, context,
| so on.
|
| A library means I get to plug in other stuff without
| totally crippling another library, as React claims it is.
|
| Nothing wrong with React, just become the framework you are
| and provide the built in solutions.
|
| Think of it this way, imagine the React team made curl. Now
| they say you can curl anything. So now you say, 'ok, I want
| to curl this' and they respond:
|
| 'Oooo, I don't know about that, that's gonna mess up all
| the curl internal optimizations, hmmm, no no, you SHOULDNT
| be curling that'
|
| And then we all walk away going 'oh', silently. Checkmate,
| hoodwinked.
| szastamasta wrote:
| Hmm, I don't really agree on this one. Just a day ago
| I've added a totally not vdom, stateful component that
| was mutating DOM and adding nodes on it's own to fix
| performance problems with critical part of the app that
| required instant feedback to user typing.
|
| React was not bothered at all. From the start there were
| ways to escape React model in components and integrate
| components into other frameworks. Been there, done that,
| it was never a huge deal.
| crate_barre wrote:
| Can you describe what you did? Breaking out of React for
| rendering means you are in deep shit. In fact, I'd love
| to see the hoops you jumped through, which I'm certain
| you will brush away as 'not a big deal'.
|
| But I am an American, so I won't put up with any
| inconvenience and don't consider it virtuous to do so (we
| fought a war over a tea tax after all).
|
| But I'll take a wild guess:
|
| A bunch of useRefs? I'm excited to hear all of this.
| notshift wrote:
| React only re-renders a component if the state changes,
| the props change, or a parent component re-renders. In my
| app, I only have one component where I needed to break
| out of the vdom, and none of the parent tree ever re-
| rendered (except when navigating to a new page, which
| correctly tears down the component), so it was as simple
| as just one useRef to grab a reference and one useEffect
| to pass it to my other code after the component rendered.
| rictic wrote:
| And with hooks that's become even more true, there's now a
| distinction between React functions and regular JavaScript
| functions, and you can only call a React function from
| another React function.
| tshaddox wrote:
| > > "you call a library, but a framework calls you."
|
| > This is why I don't like when people say "React isn't a
| framework, it's just a library"
|
| Eh, this is just a breakdown in the "framework calls you"
| heuristic. It's still a reasonable heuristic, but it doesn't
| completely describe all distinctions people make between
| frameworks and libraries.
|
| The distinction missing from the heuristic is the _overall
| scope_ of the software project _relative_ to other popular
| software projects in the same area. When people say "React
| isn't a framework, it's just a library" they're not saying
| much about the coding style one uses while using React.
| They're just comparing the overall scope of React to some of
| its close competitors (like Ember and Angular).
| serverholic wrote:
| It stops being a library when you structure your entire
| codebase around it.
| betenoire wrote:
| Or any part of your codebase for that matter
| skytreader wrote:
| > "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
| flylikeabanana wrote:
| You can use a butter knife as a tire lever in a pinch, or the
| handle side of other flatware. Chain tools are a necessity,
| since manufacturers would have to either offer chains for every
| different number of links someone would feasibly have to
| install on a bike, or weaken the chain or make it wider to be
| accessible with "standard" hand tools. A thinner chain is a
| necessity to have more gears without obnoxious wheel spacing
| and derailer travel.
|
| The tool you pointed at at is a chain whip. You used to not
| need a chain whip to replace sprocket clusters, but the old way
| of removing a freewheel still needed the proper shim to lock
| the freewheel mechanism, which was built into the sprocket. Now
| the freewheeling mechanism is built into the hub, which means
| the sprocket cluster has to remain put so you can unlock the
| lockring (instead of spinning the wheel). You /could/ do it by
| just holding the cassette with your hand, but I don't recommend
| it :)
|
| Although bike tech is in many ways suffering from the same
| march of "more tech, sleeker package" that makes parts smaller,
| weaker, and with shorter service lifetimes in other industries,
| most the specialized tools needed to work on bikes haven't
| changed in some decades.
| TeMPOraL wrote:
| Those specialized tools can be seen as the bad side effect of
| mass manufacturing and market streamlining. They're extremely
| wasteful when you have 2000 people buying one to service a
| piece of their bike. They don't look so wasteful when you have
| one shop buying one to service 2000 bikes a month with it, or
| one factory getting a bunch to assemble 2000 bikes a day. It's
| the latter two use cases that shape how products look and work.
| hospadar wrote:
| Chain whip!
| kbuchanan wrote:
| Learn Clojure. Then you can spend the rest of your life building
| with hand tools, lol: https://www.youtube.com/watch?v=ShEez0JkOFw
|
| (Seriously, though, Clojure is awesome--but occasionally I miss
| the guardrails of a framework.)
| PeterCorless wrote:
| 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."
| bovermyer wrote:
| This almost sounds like an argument against AWS, not just
| frameworks.
| jimbob45 wrote:
| 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
| sdenton4 wrote:
| (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.)
| kingludite wrote:
| I used the spice rack hammer for the dog house because I
| don't really know how to make other hammer factories and
| the one from the tutorial (that I cant seem to find how)
| only makes spice rack hammers.
| Digit-Al wrote:
| I sincerely hope you're not putting your son in a doghouse
| lol
| bitwize wrote:
| Unless your son is a dog. Some of us, due to life
| constraints, can only have fur babies.
| recursive wrote:
| Some of us, due to personal preferences, wouldn't
| actually consider that a son.
| nomdep wrote:
| Usually the moment you have an actual son and realize is
| several orders of magnitude more love, commitment, work,
| sacrifice, and money.
| denton-scratch wrote:
| The factory-factory-factory thing is quite an old joke. There was
| one version about creating a double in Java: AbstractFactoryFacto
| ry->createAbstractFactory()->createFactory(Double)->createDouble(
| 1.0)->getValue().
|
| Or something like that.
| rexstjohn wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| [deleted]
| codr7 wrote:
| 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.
| quickthrower2 wrote:
| 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]
| Yhippa wrote:
| 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.
| ant6n wrote:
| 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?)
___________________________________________________________________
(page generated 2021-10-19 23:00 UTC)