Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem with Frameworks

plbrault.com

Post reply on HN
Print view View original

71–80 of 111 posts

Re: The Problem with Frameworks

#71

Post by EdwardDiego »

I think it really depends on your framework. Good ones have upgrade paths that work.

"Move fast and break things" frameworks are not good ones.

My first job, I was working on a Tapestry 5 web-app. Very nice framework, very opinionated though.

And the creator, Howard L Ship, was very opinionated about breaking things. So we could never upgrade past 5.x (where I think x was 4 or 6), because it just broke everything for us, and we put weeks of dev time into trying to overcome that.

In the end, we just ported the app to Wicket, it was faster to do so.

Re: The Problem with Frameworks

#72

Post by jamesfinlayson »

nicoburns wrote: post #12
kerblang wrote: post #2

I keep saying it again and again: Dependencies strangle dev teams to death. A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws. And I'll add that a lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers around technologies that work…

> A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws. I definitely agree that the attitude of never upgrading dependencies doesn't work! But I've seen plenty of teams using dependencies successfully that took the opposite approach of updating them regularly (say, spending an hour updati…

Agreed - I drive-by minor version updates at every opportunity that I can because I know if I don't, things will get pretty painful sooner or later.

Re: The Problem with Frameworks

#73

Post by croes »

thomascgalvin wrote: post #23

> According to that definition, React is not a framework, but Gatsby is. I dislike articles like this. The vast majority of people would consider React a framework, and if you need to redefine such a basic word in order to make your point valid, there's probably an issue with your argument, not the definition.

According to https://www.reactjs.org react is "A JavaScript library for building user interfaces"

Re: The Problem with Frameworks

#74

Post by Zababa »

thomascgalvin wrote: post #23

> According to that definition, React is not a framework, but Gatsby is. I dislike articles like this. The vast majority of people would consider React a framework, and if you need to redefine such a basic word in order to make your point valid, there's probably an issue with your argument, not the definition.

I like calling React a component framework and Gatsby/Next an application framework.

Re: The Problem with Frameworks

#77

Post by jjtheblunt »

jordiburgos wrote: post #37
kerblang wrote: post #2

I keep saying it again and again: Dependencies strangle dev teams to death. A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws. And I'll add that a lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers around technologies that work…

But Spring also saves you the time of putting those wrapped technologies together.

I wonder if Spring has caused more wasted time, configuring its grandiosity, than it has saved people, and I say that because I don't know the answer.

Re: The Problem with Frameworks

#78

Post by throwaway984393 »

Most software developers have the same problem. They ignore what they already know is going to happen: one day, their code will die, just like we all will one day die. This thought is so disturbing to us that we avoid dealing with it until it's too late. No one's code runs forever; yet we all pretend every line of our code will outlive us. And just like the health-nut marathon runner who drops dead of a heart attack, there are no guarantees in life or in code, framework or not.

Plan for your code's death. Keep an eye on the next versions, and keep a CI job pinned to them. Read the changelogs. Keep the import EOL dates on your calendar. EOL your own code. We don't get to choose whether our code will die, but we can choose how it goes out.

Re: The Problem with Frameworks

#79

Post by chaostheory »

lostcolony wrote: post #53
dnautics wrote: post #39

Earlier quoted context omitted.

I'd like to add this: - There's the possibility you will do something very wrong if you roll your own from libraries For example, HTTP serving frameworks are popular because the HTTP protocol is complicated , not to mention best practices around security that have evolved over decades and are still evolving, and the (ideal framework) will handle a lot of high-level protocol logic (do you really want to parse mimetype…

Using the author's definition (necessary when comparing the two) of "I consider a piece of software development technology to be a framework if it dictates the way all or most aspects of an application built using it will be programmed and how the code will be organized, while a library covers only a specific aspect of the system and is usually less opinionated about architecture.", I'm not sure your criticism really…

Imo the autHor’s definition of a framework isn’t very good. React is clearly a framework and not a library.

Re: The Problem with Frameworks

#80

Post by dnautics »

lostcolony wrote: post #70
dnautics wrote: post #66

Earlier quoted context omitted.

look, "all" is meaningless. What constitutes "most" is a matter of judgement. Sinatra does guide you in your code organization a hell of a lot more than something like, "a json parser library".

Sounds like you might be defining library vs framework as "library's are collections of functions with minimal if any state that needs carrying between calls to exposed functions" then. Which is a possible way to distinguish them! Just...not how the author did. Of course, that makes things like Go's inbuilt HTTP a bit weird; it's part of the standard library, but it also necessitates setting up handlers, which would…

I'm conforming to the authors definition, as you present it. Under these criteria, Sinatra is categorically closer to rails than a Jason library. What might an http server library look like? It would have a function that blocks on accepting a socket, a function that parses the socket contents into a data structure, and a function that lets you send a response. That's not what Sinatra looks like, at all. If you make a claim otherwise, you are on shaky ground. Let go.
Post reply on HN