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

Using a framework will harm the maintenance of your software

berk.es

Post reply on HN
Print view View original

121–130 of 550 posts

Re: Using a framework will harm the maintenance of your software

#121

Post by dalyons »

hsn915 wrote: post #50
matthewmacleod wrote: post #40

Earlier quoted context omitted.

No, it's not "simply false". It's something that many of us have repeatedly observed happening and probably done ourselves at some point. There are of course exceptions, but it's not really fair to bluntly dismiss it. One of your greatest desires should be to have strong propietry technology that you control Yes – and you should be investing your time in making that "strong proprietary technology" more effective, and…

This notion that frameworks save you time is just ridicluous. Unless the framework is doing something really complicated and difficult (like, say, a 3D game engine such as the Unreal Engine), chances are it's costing you time and effort. What often ends up happening is you have to do a lot of useless work to get around the limitation of the framework you decided to use at the start. Since most people on HN are in the…

That is a pretty extreme take - that frameworks “always” cost more than they provide? On what do you base this categorical assertion? I’ve been in this industry a long time, and based on my experience that’s not true at all. “Sometimes” they cost more, if your problem is esoteric or a poor fit to a general framework. Most problems aren’t.

Re: Using a framework will harm the maintenance of your software

#122

Post by smeagull »

Joel_Mckay wrote: post #89

"Frameworks are designed to take your project hostage" Wow, that is some enterprise level FUD, and with zero citations to back up that assertion. While one could possibly see 3rd party external dependencies pose a variable cost, service risk, or security issue... a standalone/maintainable site should not have 25 domains for every lame js widget a designer thought looked cool. Those who do not use a good framework, ar…

You don't need a framework. You can control execution and use libraries. Once you use a framework changing back is hard. Removing a library on the other hand is easy. Because for libraries you control execution, and for frameworks you have to fuck your code so it will obey the requirements of that framework.

Re: Using a framework will harm the maintenance of your software

#124

Post by DrewADesign »

sbf501 wrote: post #109
a4isms wrote: post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

I think this argument is about free vs. not-free frameworks. Frameworks that are supported by a company and actively developed are far superior to the state of NPM open source right now (thinking of Qt vs Electron and my 7 year battle with both). It is no fun when an open-source framework pushes a new major version, then deprecates the version you were on, or dependencies fail to find matching version, and you beg gi…

I think some of your experiences can be explained by your citing NPM as representative of FOSS. Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem, but stability isn't its strongest comparative suit. OTOH, Django, which was cited by the author, just doesn't have that kind of volatility in its base features.

Re: Using a framework will harm the maintenance of your software

#128

Post by john61 »

sbf501 wrote: post #109
a4isms wrote: post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

I think this argument is about free vs. not-free frameworks. Frameworks that are supported by a company and actively developed are far superior to the state of NPM open source right now (thinking of Qt vs Electron and my 7 year battle with both). It is no fun when an open-source framework pushes a new major version, then deprecates the version you were on, or dependencies fail to find matching version, and you beg gi…

And it is no fun when the manager of the company developing your proprietary framework decides to tank it because of a change in strategy or the competitor buys the company and stops development. Since you have no source code you are forced to do what the commercial interest of foreigners dictate.

Re: Using a framework will harm the maintenance of your software

#129

Post by Qwertious »

ar_lan wrote: post #72
flobosg wrote: post #4

This article is about software frameworks, by the way. The capitalization made me think it was about the Framework laptop.

I thought the same exact thing, and had entered the article with a significant bias against the author based on the headline.

I didn't enter with a bias, I was just thinking "LOL, how are they going to justify this, this is gonna be good."

And then they had to be something completely different and yet completely justified. Darn.

Re: Using a framework will harm the maintenance of your software

#130

Post by Test0129 »

a4isms wrote: post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

I've been burned by so many frameworks I am hesitant to use one unless the advantage is abundantly clear. Even something as mundane as an ORM can cause massive problems down the line if you're not careful, or you forgot to anticipate the case you need something more complicated than braindead CRUD.

Frameworks force you into a paradigm. Yes, to spin up quicker, get new engineers onboarded quicker, etc a framework will do the job. But it's not a free lunch. In exchange for this you are hopelessly intertwined in the author's idea of what makes something good. You're bound to their bugs, you're bound to the nuance, and most importantly you're developing knowledge of a framework, and not what the framework does. Some major frameworks, for example React, might pass the smell test as "just use it". This is the exception and not the rule mostly guided by the fact that Javascript is the absolute hottest garbage to ever grace our unfortunate field.

For some people this exchange is worth it. I'd generally recommend a company use pieces of a framework where they can. But to use a whole framework? Let's put it this way, early in my career I was involved in more old rails projects than I care to admit that were FILLED with kludges because no one could justify actually doing it right and in-housing most of it. I've been involved in projects that were hopeless dependent on the ORM-du-jour that were completely hamstrung because the ORM didn't take full advantage of the query planner, or lacked the necessary constructs for complicated queries, etc. ORMs are the worst, in my opinion, because the only other option is to then _force_ the ORM to do what you would've done originally (defeating it's purpose). General purpose web frameworks are close runners up (and related).

Your 5 points are nice sounding, and you probably get a lot of CTOs and engineering directors to agree with you. However, as a man in the trenches I can't say anything but you're fortunate to never have been on something complicated enough that a framework hamstrings you. Rescuing a project from a decision made by some framework-first shortsighted genius is the reason we get paid as much as we do.

Post reply on HN