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

21–30 of 111 posts

Re: The Problem with Frameworks

#21

Post by munchbunny »

cube00 wrote: post #6
bjarneh wrote: post #5

Most frameworks (web-frameworks at least) get you from 0 to 80% in very little time. Nice layout/css etc, but they require you to learn how they want to do everything; which can be both cumbersome and time consuming. Frameworks also gives management false expectations of how long it takes to make something. "It looks like you're 80% done with the web-page already, and we've just started - great!" — Management

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

Re: The Problem with Frameworks

#22

Post by gwbas1c »

I generally agree with this article. (Great explanation of the tradeoffs, BTW.)

One edge case: Situations where the language itself has a major, breaking change between versions. IE, .Net Framework 4 -> .Net 5 (based on .Net Core,) or Python 2 -> Python 3.

A simple codebase might easily move from Python 2 to 3; or .Net Framework 4 to 5; but once there's a lot of libraries, there's a good chance that you'll need a newer library in order to move to the newer language... And that newer library might have breaking changes.

Re: The Problem with Frameworks

#23

Post by thomascgalvin »

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

Re: The Problem with Frameworks

#24

Post by Foobar8568 »

bjarneh wrote: post #5

Most frameworks (web-frameworks at least) get you from 0 to 80% in very little time. Nice layout/css etc, but they require you to learn how they want to do everything; which can be both cumbersome and time consuming. Frameworks also gives management false expectations of how long it takes to make something. "It looks like you're 80% done with the web-page already, and we've just started - great!" — Management

Hi2u Telerik and Infragistics if that crap still exists.

Re: The Problem with Frameworks

#25

Post by toddmorey »

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 unique challenges)
  - It's harder to onboard other developers 
  - There's often more bespoke glue code
  - Smaller libraries often have a smaller community and a shorter lifespan
All of that said, I'd likely choose the library approach for certain unique applications and the framework approach for "common / solved problems" like publishing content.

Re: The Problem with Frameworks

#26

Post by mtberatwork »

mattgreenrocks wrote: post #14

The paradox of frameworks: if you couldn’t write it yourself, then using it is a big risk if you hit a bug. But if you could write it yourself, you may not want to, as you have a better idea of what you want. Personally, I only like frameworks that don’t fight me tooth and nail to encapsulate them into adapter layers (hexagonal architecture) when the time comes. There aren’t many of them. Some of them feel almost nar…

If you hit a bug with a popular, open-source framework, the odds are great that others have as well and it will get escalated and solved quickly. The same can't be said for closed-source, proprietary frameworks. Also, writing it entirely yourself always leads to re-inventing the wheel over and over again. Furthermore, I have yet to see any proprietary framework that wasn't in some shape or form a poor knockoff of something already existing in the open-source world.

Re: The Problem with Frameworks

#28

Post by imbnwa »

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.

React is a framework if you let it be a framework.

Re: The Problem with Frameworks

#29

Post by switch007 »

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.

And HR asking for a quick chat should set off greater alarm bells, especially with regards to documenting the discussion
Post reply on HN