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

61–70 of 111 posts

Re: The Problem with Frameworks

#61

Post by hogrider »

munchbunny wrote: post #21
cube00 wrote: post #6

Earlier quoted context omitted.

"But we'd like a quick chat to understand why the last 20% took so long" — Also Management

I love the phrase “quick chat” because it’s rarely ever actually quick. If it was actually quick, they’d just ask it. Over time I’ve learned that the correct response is, approximately, “Sorry, I’m in the middle of [important work], please book 30 minutes for us and [stakeholders] to discuss it.” Gives me time to prepare so that I’m not caught off guard. And to bring backup if I think I need it.

I find this officespeak hilarious.

Re: The Problem with Frameworks

#63

Post by scelerat »

toddmorey wrote: post #25

Ok, I'll take the counterpoint and offer a few challenges I've seen with libraries. In a sense, you are often assembling your own framework. No judgement there--just good to know what you are getting into. - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered un…

> In a sense, you are often assembling your own framework.

Exactly. I always phrase it this way: if you don't choose a framework, you will be writing one.

(for a certain class of problems, obviously)

So, just know that going in. If you're not prepared for that reality, maybe your best choice is in fact to choose a framework that's already written, tested, and well supported.

Re: The Problem with Frameworks

#64

Post by smitty1e »

A framework presents a scope.

If your project falls within the scope, great. You may be sporting a bunch of YAGNI functionality, but could grow into it.

Now, should requirements venture outside the scope...

- You may eat some Level Of Effort to meet those requirements, assuming s decent plugin system, or

- As The Famius Article notes, you could eat the framework equivalent of DLL Hell trying to appease the Version Gods.

Re: The Problem with Frameworks

#65

Post by smoe »

toddmorey wrote: post #25

Ok, I'll take the counterpoint and offer a few challenges I've seen with libraries. In a sense, you are often assembling your own framework. No judgement there--just good to know what you are getting into. - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered un…

As I see it, very generalised, libraries are great, if I already know pretty well what I'm building, the problem I'm solving, so I can pick the right tools for the job. On the other hand, if I'm in a much more exploratory phase, changing the product a lot, then frameworks are great because of the amount of decisions I don't need to make at this stage and the defaults often being good enough.

So ideally, I would have a framework which allows me to swap out components as the application evolves and what is being solved becomes more well defined.

Re: The Problem with Frameworks

#66

Post by dnautics »

lostcolony wrote: post #59
dnautics wrote: post #57

Earlier quoted context omitted.

Sinatra is a framework, it's very light in that it doesn't dictate where you put your files in directories (but neither does, say Phoenix, which is definitely a framework). In sinatra, the system calls into the functions you write and you have no choice but to organize your endpoints the way that sinatra wants you to , even if some things are light relative to rails.

Did...did you miss my callout to the author's definition? Per that, Sinatra is a library. The structure of endpoints is no different than function calls; where they go is not proscribed. I'm not saying that's a good definition.

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

Re: The Problem with Frameworks

#67

Post by throwaway889900 »

erwincoumans wrote: post #27

In game development, Unity 3D and Unreal Engine (and Godot) frameworks seem to have mostly taken over from custom game engines frameworks that use some libraries (for audio, physics, networking etc).

Because those abstract away the complicated build processes for the target, notably game consoles.

Re: The Problem with Frameworks

#68

Post by meesterdude »

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…

I think it's language dependent - no team i've been on has been strangled by dependencies, they've largely amplified development; and the tradeoff to address breaking changes when they come is worth it.

But if you add dependencies, and don't make time to keep them up to date... you're going to have a bad time.

Re: The Problem with Frameworks

#69

Post by breckenedge »

We’ve been arguing about this for years. Frameworks have their place. Bespoke hand-crafted apps have their place. It all depends on expected performance, human factors, and maintainability. I think that’s a benefit you get from hiring folks that have both worked inside and outside of frameworks and in a variety of tech stacks.

Re: The Problem with Frameworks

#70

Post by lostcolony »

dnautics wrote: post #66
lostcolony wrote: post #59

Earlier quoted context omitted.

Did...did you miss my callout to the author's definition? Per that, Sinatra is a library. The structure of endpoints is no different than function calls; where they go is not proscribed. I'm not saying that's a good definition.

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 potentially make it framework.

Post reply on HN