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

31–40 of 111 posts

Re: The Problem with Frameworks

#31

Post by hu3 »

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

> (frameworks) require you to learn how they want to do everything; which can be both cumbersome and time consuming.

New teammates will have to learn how to do things anyway. But with frameworks there's a chance they already know.

Re: The Problem with Frameworks

#32

Post by threatofrain »

imbnwa wrote: post #28
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.

React marketing insisted on being a library for too long and Vue is distinguishing itself by saying they aren't a library, they're a framework.

https://www.youtube.com/watch?v=2KBHvaAWJOA

Re: The Problem with Frameworks

#33

Post by beaconstudios »

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 think it's reasonable to say that React is a UI framework because you have to build your UI within it if you choose it. The author's argument that because it doesn't provide the kitchen sink it isn't a framework, misses the issue that you can have frameworks for subsets of a project. You get UI frameworks (React, Angular), CSS frameworks (Tailwind), backend/API frameworks (GraphQL), etc that only lock in one area.

Re: The Problem with Frameworks

#34

Post by commandlinefan »

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 lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers

... that don't usually add any real value.

Re: The Problem with Frameworks

#35

Post by commandlinefan »

random_kris wrote: post #15
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…

Well with spring boot you can use spring wrappers but there are always (atleast in my expirience) ways to override their way of doing things or just completely skip their wrapper and just use whatever is under the hood

> completely skip their wrapper

Why use Spring Boot at all then?

Re: The Problem with Frameworks

#36

Post by giraffe_lady »

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…

Yes exactly. This list is pretty much verbatim my problems with working in javascript right now. Everyone has assembled their own framework within this complex web of influences and dependences so it all seems like the same thing but isn't quite.

It's kinda cool in a way too but it has those specific downsides you mentioned.

Re: The Problem with Frameworks

#37

Post by jordiburgos »

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.

Re: The Problem with Frameworks

#38

Post by commandlinefan »

switch007 wrote: post #29
munchbunny wrote: post #21

Earlier quoted context omitted.

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

Well, there's no "preparing" for that... except making sure your LinkedIn profile is up to date.

Re: The Problem with Frameworks

#39

Post by dnautics »

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…

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 ranges and do Accept matching? How about CORS? Cookie signing?) on your behalf, calling into your code only for the business logic.

Re: The Problem with Frameworks

#40

Post by amoe_ »

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.

As someone wrote further down the thread, the official position of React is that it's not a framework, so it's not just this article making this point.

I agree with you that there's something slightly wrong about that framing on the part of the devs.

But this is just the old descriptivism/prescriptivism divide again.

Post reply on HN