This article is about software frameworks, by the way. The capitalization made me think it was about the Framework laptop.
Now I'm curious what sort of argument could be made about not using the Framework laptop.
Using a framework will harm the maintenance of your software
41–50 of 550 posts
Re: Using a framework will harm the maintenance of your software
#42I'm glad I started my professional career working on a large Django app, I think learning about its abstractions and organization gave me a really good starting point in building my mental model of all the problems sufficiently complex web applications end up having to solve. Now I often find I prefer, or am in a situation where the companies architecture dictates writing projects and services with much simpler dependency graphs, I've also found the prospect of deploying web applications with python a lot less appealing, but there are many reasons the opinionated all-in frameworks like Django and Rails were and are awesome.
Re: Using a framework will harm the maintenance of your software
#431. 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…
> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. This is simply false. On the other hand, every sufficiently complex framework-dependant application is way too complex for what it does, and would be a lot simpler if it was not using said framework. > My last and--to me the most significant--observation is this: Yo…
Avoiding the use of a framework does not preclude someone else from duplicating your work in two months by using a framework. It just means that you wasted a whole lot of time hand-rolling things that didn't need hand-rolling.
Most businesses are not successful by virtue of the technologies they choose. Facebook is probably the foremost example here; they started with PHP and moved over time to leverage additional technologies (some homegrown like hack and react, others just additional languages like C++).
There are plenty of facebook clones in plenty of languages. The technology isn't the reason Facebook hasn't been supplanted by a competitor with the exact same product.
Re: Using a framework will harm the maintenance of your software
#441. 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…
> Using libraries and frameworks is like a business outsourcing things that aren't its core competency and also aren't competitive differentiators.
Adopting frameworks is a variation on the the Build vs Buy question, even when there's no money involved. Does the framework provide some features that are necessary for the technology but not core to what your business does? It's probably OK to use. A company that adopts a framework for its core business is essentially giving up any competitive edge, because any company that uses that same framework with the at least the same skill as your team will end up being a viable competitor.
Re: Using a framework will harm the maintenance of your software
#45Have to agree.
Just the framework itself usually requires maintenance, unless the developer prioritizes backwards compatibility, which is rarely the case.
Re: Using a framework will harm the maintenance of your software
#46Before you comment with "So you want us to write everything ourselves?", make sure you read the paragraph that starts with "Many people will argue that not using a framework means write everything yourself. This is a false dichotomy."
I feel like this response is common enough that it's almost a trope. "Oh you don't like leaky abstraction X, so what we should all code in binary!?" I think it comes from a kind of "Just World" spin off whereby all abstractions are considered pretty much equal, and it's cavalier to not code to the "highest" of these, no matter how many rickety chairs you've piled on top of each other to get that high. Not all abstrac…
> Not all abstractions are created equal.
I'd go so far as to extend the statistics aphorism about models to software abstractions: all abstractions are wrong (/leaky?), but some are useful for now.
The problem with software abstractions is that they, unlike the fundamental laws of physics, model code organization and business logic that frequently changes. These changes often make no sense beyond "VP lifer thought it was a good idea" so our house of cards is built on ever shifting sands. No abstraction short of a pointer can survive that.
Re: Using a framework will harm the maintenance of your software
#47Earlier quoted context omitted.
Agree completely. I’d like to add a couple of things. 6. Frameworks often handle the last 20% of a project that no one wants to do, such as handling compatibility or accessibility issues. 7. There’s a good chance that the framework has already had to deal with edge cases that you would otherwise learn the hard way
My experience is the exact opposite. Frameworks have a very narrow compatibility and accessibility range, and to get the other (often more than) 20% requires extra hackery which has to be bolted onto the framework in ways that were not foreseen by the framework writers.
One example I can think of was the Play framework.
If you wanted to work with Scala 3 and Play 2.7, you couldn't. You needed to stick with Scala 2.13 to be able to use Play 2.7.
This was more than a year ago. Now we have Play 2.8. Is it compatible with Scala 3 now?
Edit:
I am not entirely sure whether it was possible to make Scala 3 and Play 2.7 work. So my statement above might be partially wrong.
However, I had other dependencies too, which required me to use Scala 2.13.
Consider to downvote this, if you think I made a false statement. I should have looked up the documentation beforehand and not rely on my (past) personal experience/impression at all.
Bad mistake!
Re: Using a framework will harm the maintenance of your software
#48Re: Using a framework will harm the maintenance of your software
#49Sure. But not using a framework will harm the maintenance of your software more.
Re: Using a framework will harm the maintenance of your software
#50Earlier quoted context omitted.
> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. This is simply false. On the other hand, every sufficiently complex framework-dependant application is way too complex for what it does, and would be a lot simpler if it was not using said framework. > My last and--to me the most significant--observation is this: Yo…
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 web space, framework often refers to things like "Django" or "Redux". These beats always cost way more than they provide.
For a web server, a library like the standard "net/http" in Go is way more useful than a "framework".