
Frameworks Don't Make Much Sense - th0ma5
http://www.catonmat.net/blog/frameworks-dont-make-sense/
======
onion2k
Frameworks do what the name implies - they provide a consistent base around
which to build the rest of your code. That consistency is very useful in a
large team. You really don't want people rolling their own solutions to
problems, and then finding those solutions don't work together. A framework is
an aid to maintaining a consistent interface between disparate parts of the
code base. That "limit to creativity" is actually a good thing.

Besides, any large project written without a framework will end up
implementing its own "framework-like" interfaces and abstractions anyway. At
which point you're essentially using a framework but without any of the
advantages of using a well tested and well documented solution that new team
members could already have experience of.

~~~
kganser
The author's point is that a framework does not do anything that a library
could not do better. A library respects the principles of abstraction that the
programming language provides, which is not true of a framework. Both can be
consistent, well documented, well understood, etc., but one is definitely
better when it comes to leveraging programming language abstractions.
Ultimately, this means libraries are easier to learn than frameworks.

~~~
aikah
> which is not true of a framework

What framework are you talking about ? Symfony or Silex do exactly that :
"respects the principles of abstraction that the programming language
provides". Spring does that too. Any framework powered by dependency injection
does that. Only frameworks that try to be to smart for their own good like
Rails violate basic separation of concerns. Furthermore, just have a look at
most Go or Node web apps out there : globals everywhere, tightly coupled code,
no separation of concerns, no dependency injection,direct db calls in
controllers... All because "you don't need a framework with Go" or "Dependency
injection makes no sense in Javascript", good to luck to the people
maintaining these messes 5 years down the road. Not using a framework doesn't
make a automatically a codebase better. A framework however can mandate some
discipline,especially when based on IoC : on one side : the framework's code ,
on the other side : the user code and the only glue is the manifest declaring
dependencies between the two.

~~~
mchahn
> globals everywhere, tightly coupled code, no separation of concerns

Speak for yourself. I am not guilty of any of these in my large node
applications. And I use no frameworks, just npm libraries.

------
marcus_holmes
Unfortunately I think Rails has poisoned the well here. Too many web devs seem
to expect that any environment they code in should have all the bells and
whistles that Rails has.

My particular bugbear is working with people who refuse to learn SQL as if
it's some arcane bit of weirdness on a par with machine code. They've only
ever used ORMs and have no idea how to actually talk to their data. /rant

I recently looked at Phoenix, and ran into a few dependency issues straight
out of the box. Thankfully, because it reminded my why I stopped using
frameworks ;) I started getting to grips with Plug instead... much better :)

~~~
melloclello
> My particular bugbear is working with people who refuse to learn SQL as if
> it's some arcane bit of weirdness on a par with machine code. They've only
> ever used ORMs and have no idea how to actually talk to their data. /rant

Lol this is me. People who write their SQL from scratch confuse me, I'm like,
just use the ORM and then everything's consistent! :P

~~~
spotman
The real trick is to have a deep understanding of SQL before you use an ORM so
that you know exactly what you are asking the ORM to ask the database to do.

Otherwise you will never be able to really understand what is going on and
will not be able to optimize a complex app that needs to be performant at
scale.

Learning both has its advantages and I think an ORM can indeed speed up
development, most especially for the prototyping phase.

------
elliotec
I think there are solid cases where frameworks make a lot of sense. They
provide very helpful layers of abstraction on often used patterns, like Rails
CRUD apps, in which you can just use the command line to generate
fantastically useful patterns that would take forever to implement.

On the other hand, learning the basics of a language, or more importantly
learning how programming works and how software is written, is going to be far
more powerful than learning a framework first, even though that is often the
step most newcomers take.

Learning the ins and outs of JavaScript for example is going to help you
immensely in navigating the mess of JS churn and you'll be able to learn the
framework du jour much faster than approaching it framework-first.

~~~
matt4077
True – but: I think I never learnt so much so much in such a short time as
when I started with rails. MVC, project layout, API design – a good framework
can be an incredible role model for these higher-level concepts.

~~~
mercer
I can highly recommend you go even 'lower' than that and use something like
Express, or go framework-less. I did that once, and I learned to appreciate so
much more why Rails/Django/whatever is built the way it is. I really think I
became a better Rails developer, and a better developer in general, by
dropping down to a lower level.

~~~
elliotec
Sinatra would be the Express equivalent for Ruby, and is very powerful and
useful and illustrates these points. There is a lot more configuration with
these types of things, but the tradeoff is the overhead that isn't bloating
your stuff.

~~~
mercer
That, and I really think in hindsight the value of understanding things better
and building 'from scratch' is immense.

Once I built my own 'CMS' using express and RethinkDB, I had to also set up on
a templating system (so I chose React server-side). I ended up using a bunch
of other tools or technologies as well. All of these were on my list, but I
never really found a good excuse to look into them. But now I had to pick
something (as opposed to settling for HAML in Rails, or any of the other
'popular' approaches, and actually figure out what the advantages and
drawbacks were, as well as how to tie all these things together.

Not only was it _fun_ in a way that building Rails sites often isn't anymore,
it was incredibly educational.

------
amasad
Posts like this should start by clearly defining what they mean by framework.
It's really hard to draw the line between a framework, platform or a library.
One of the best differentiation I've heard between frameworks and libraries is
that the former calls you but you call the latter. But even that is still not
clear, a lot of libraries allow you to define callbacks and implements the
adapter pattern to pass them classes and objects which in turn gets called by
the library.

Let's take Browserify for example which I think the author and co most likely
use. It allows you to define modules and then it calls those modules which are
expected to prepare some objects that are passed to it. There is a contract,
and it calls you. It sounds like a framework. What makes it any different than
Rails or anything else?

You may say Browserify is based on the CommonJS standard. CommonJS being a
real standard is debatable, but even if we accept that it's still an arbitrary
line to draw. Any sufficiently popular framework can make itself a standard
(e.g. The json API that was inspired by many of the existing frameworks).

------
mbrock
People disagree strongly with this article because it's written in a strongly
opinionated way yet is also quite abstract in that it fails to specify the
context and meaning of certain key things in the argument.

But whatever. This is how discussions work nowadays: someone makes a strong
vague claim, and then other people react strongly against it, and we all have
a fun time arguing.

"NIH syndrome" is a thought-terminating cliché.

Frameworks are sometimes useful in the same way that a "methodology" like
Scrum is useful, or in the way a "theory" in social science is useful: they
are patterns that people can learn and adapt to and they let people work
continuously without always stopping to make fundamental decisions.

I think the anti-framework train of thought is very useful as an antidote to
the framework mania that some programmers go through, or let's say the "anti-
NIH syndrome."

You could kind of compare it to Paul Graham's thing about tiny teams of expert
hackers using the power of Lisp to create their own kind of bottom up dialect
perfectly tailored to the nature of their project. It's hard to do that if
you're always jumping to put in complex external scaffolding that's designed
for big teams.

------
windlep
This ignores the problem of not using a framework, that is, for a sufficiently
complex project you will eventually end up with your own ad-hoc framework if
you don't use an existing one. Maybe it's better, maybe worse, but one will
appear regardless.

That's how Django and Rails started (and I'm sure many more). Ad-hoc
frameworks that then get yanked out of the project so the company can re-use
the useful parts.

I've seen quite a few ad-hoc frameworks companies have inadvertently created
in their effort to "not use a framework", rarely were they nearly as good as
what was already out there in the OSS world.

~~~
wwweston
> you will eventually end up with your own ad-hoc framework

Or some people call it, "code that solves the problems we actually had."

~~~
ng12
That is virtually unmaintainable. What happens when Joe Hacker moves on to
greener pastures? The new guy gets stuck with a framework that he can't
Google. This is where the author lost me:

> You've to ask for expert help, wait until someone helps you or pay an expert
> framework consultant.

The ability to ask an expert for help is a boon, not a curse.

------
hoodoof
I don't buy it at all.

Of course frameworks take alot of effort to learn.

But the point is that you'll pay an up front cost in time and learning and get
a much bigger payoff further down the track in productivity and possibility.

You have to be really careful not to get a programmer like this on your team -
I have encountered a few. They are scornful of all code that they didn't write
so they rewrite everything. Pure waste of time.

One of the smartest programmers I know said that if you work within a well
organised codebase then over time your programming should get _faster_ ,
whereas without a well organised code base you will get mired in a sticky
swamp and things will become multiples of slower.

A good framework should give you that well organised framework within which to
perform at your best productivity. Of course a crap framework won't do
anything for you but why use a crap framework?

~~~
dietrichepp
The time taken to learn the framework was a relatively minor point of the
article. I have serious doubts about the payoff—in my experience, by the time
you know a framework well, you are fighting against mismatched abstractions,
edge cases, performance issues, etc. You spend more time fighting the
framework than developing your application. Then if you change to another
framework, you have to learn everything over again. But if you use a bunch of
libraries instead, you can swap one of them out without touching the others.
For example, I can keep the same router but use a different ORM.

The same problems with bad abstractions happen with many applications in the
long run, but it seems that using a framework will get you there more quickly.
I'd say that the advantage of frameworks is developing many smaller prototypes
more quickly.

~~~
hoodoof
Sounds like you're using the wrong framework.

May I ask what framework you have in mind with those comments?

I have to say I am very careful about how I budget and spend my learning time.
I do not have much time so I make a big decision when I invest in learning a
framework and I plan for it to pay off over a number of years. It would be
deeply inefficient to be working at a shallow level of understanding across
more than two or at most three frameworks.

I've chosen one web server to understand deeply and one front end browser
based framework to understand deeply and I'm reluctant to take on anything
more than that.

~~~
dietrichepp
Sounds like you're solving different problems than I am. May I ask what kind
of problems you're solving, that the same framework works for all of them?
Never mind, my question is really just bait, don't answer it.

My point is that there's a certain arrogance to watch out for, when we claim
that our solutions will work for other people's problems, but we don't really
understand what their problems are. I've shared my negative experiences with
frameworks, but I can't speak universally. I can only suggest that people not
use frameworks, based on the experiences I had. I'm not about to—for
example—state outright that someone is doing things wrong just because they
don't make the same choices I would make. This is the kind of attitude that I
watch out for when mentoring junior developers who think code is "messy" and
needs to be "fixed" just because it doesn't match the way they write code.

I'm very reluctant to learn any more frameworks because tomorrow's problems
seem not to match the frameworks we chose yesterday. Again, this is just my
personal experience, and you use different frameworks and solve different
problems.

------
leohutson
Frameworks are just a set of libraries that play nice.

If you use a bunch of separate libraries from different developers, then you
have to write a lot glue code to get data between those libraries.

That code is usually slower, as it will involve copying and transforming data,
i.e. you'll be copying data in and out of different classes, copying data to
memory allocated by the library, copying data to differently aligned memory,
transposing data, copying data between different sized scalar types etc.

Frameworks make cross platform development a lot faster, and learning a
framework is no more of a waste of time than learning another language or
native OS api.

I absolutely agree, that bundling together a bunch of dependencies, and having
those dependencies maintained by the same vendor has a risk/cost.

Don't choose a shitty or faddish framework; put as much research into choosing
your framework as you would into researching it's individual libraries, use
the framework as it was designed, and only use what you need.

~~~
learc83
>Frameworks are just a set of libraries that play nice.

Many times when people talk about the difference between frameworks and
libraries, they are talking about which code is driving the program. I think
this is the case here.

An overly simplified example of the difference is that, with a library, your
code calls the library. With a framework, the framework calls your code.

~~~
Animats
Yes. Thus, in one program, you can use multiple libraries, but not multiple
frameworks.

~~~
AstralStorm
Sometimes you can and it is not even too hard to make them interoperate. This
begs the question why would you want to though.

------
cryptos
I disagree. The question whether to use frameworks or not is a bit more
complex. As everything in software engineering, like choosing a framework, is
a trade-off. Frameworks come with a price and it depends on the context,
whether it pays off or not. I've seen some really terrible in-house
"frameworks", because someone decided not to use a framework. And over time
the few "helper" and "util" classes evolved into a poorly structured and
poorly documented framework with poor test coverage.

Common frameworks are (in general) not only better structured, better
documented and tested, but it is far more likely that new developers have some
knowledge of them, whereas your in-house code-dump is not known by anyone
else.

------
cenal
Frameworks make perfect sense if you don't know what you are doing. I've seen
way too many inexperienced developers that try their hand with coding
something from scratch only to have the product development fail spectacularly
and never launch.

If you are as accomplished as the author then a framework is probably going to
only slow him down. In full disclosure I've worked with the author. Peteris
Krumins is an extremely talented developer who has a very cool startup called
Browserling ([http://www.browserling.com](http://www.browserling.com)) for
those of you who need browser based testing.

~~~
greggman
frameworks make sense even if you do know what you're doing. Google, Facebook,
all the top companies use frameworks. Why would I want to waste time
reinventing the wheel. I just want to drive the car to get to my destination.
I don't want to build the engine.

A better analog might be movie making and some guy claiming "buying cameras
makes no sense. You should develope your own cameras and your own film. it's
more creative".

No, it's not. It's wasted time doing busywork someone else has already done.
Similar to game engines. You could write your own and spend 1 to 10 man years
reproducing what's already been done. Or you could spend that 1 to 10 man
years on design, prototypes, and iteration in the actual meat of your project.

~~~
esailija
They use frameworks that they themselves invented specifically for their use
cases, they didn't take someone else's framework because they know it doesn't
make sense just as the author claims.

------
raverbashing
The NIH syndrome is strong with this one

No, they make a lot of sense. Regardless if you use Flask, Django, Rails I
don't want to reinvent the wheel of receiving and dispatching requests,
dealing with Sessions, etc.

------
ChrisDutrow
I hate frameworks. God I hate them. Until I saw this post, I thought I was a
simple minded freak in the extreme minority.

They are probably great for many people and projects. But someone like me, who
wants things just so... I'm always fighting them and the're always getting in
my way with their obfuscation.

I wrote this in Python/JavaScript, adding helpful libraries as I needed them
(backbone.js for Javascrpt organization, jinja2 for templating to name a few)
[https://demo.enterprisejazz.com](https://demo.enterprisejazz.com)

Almost all the front end controls are custom and the back end database is a
custom hybrid or Cassandra/Redis. I don't think software like that usually
comes from a framework. Though I could be wrong cause like I said... I hate
them.

~~~
matt4077
I think that article is indeed written by a simple=minded freak who's in the
extreme minority.

------
RangerScience
Bullllllssshhhhiiiiiiit.

I work in industrial augmented reality (Daqri). Here is an actual task I, or
someone else, actually has to do someday: I have a steel mill with 24000+
sensors distributed over ~20 machines and/or stations. I need to put the
sensor readings into AR space as callouts over the relevant machine and/or
station, as well as the results of any secondary processing of those sensors
(aka, historical trend analysis, error predictions, etc), as well as ways to
view and browse existing documentation of those machines, stations, sensors.

In order for the AR-based HMI to be effective, you're going to have to tweak
and polish each machine/station's AR HMI.

Then I have to do that to the facility that uses the steel this facility
produces. And then the facility that uses the steel products THAT facility
produces.

As each of these facilities was independently constructed, sensorized, and
upgraded over the last few decades, each one has it's own differences and
quirks, and although there are some solid and reliable standards, there's more
than one and many of them are deliberately hard to integrate in order to
create lock-in.

The only way I can imagine possibly being successful at this is with a
framework that makes it easy.

So... Either the author has never had to do same-same-but-different over and
over and over again, or we have different ideas as to what a framework is.

PS - This reminds me of the defaults/no-defaults debate, which I think ends up
actually just being "stop working with code that has 'defaults' that are hard
to change" \- which I'd say mean they're not actually defaults.

------
gosukiwi
You can learn a lot of things from frameworks. If you try to come up with your
own solution without beeing experienced enough you'll end up with a mess.

------
tomelders
Hmmmmm..... I think the sentiment in this article is ( or at least should be )
limited to web frameworks where the pace of change is too fast even for the
most nimble of framework developers to keep up with. Things move so fast that
web devs need "some" help.

I think the problem is that the first step in too many web projects is "what
framework shall we use".

I like to quip that "Frameworks are great!... until they're not". And while I
favour libraries over frameworks, that's not a panacea, it's more like a
preference. For as long as the web continues to grow in complexity at
irregular intervals and with zero real consensus, we will need to offload
lot's of our work onto frameworks and/or libraries.

------
MrPatan
\- Frameworks make it easier to choose the right decision (or at least what
the framework creators believe is the right decision)

\- Frameworks make choices for you, yes, which reduces decision fatigue and
lets you use creativity for the valuable stuff instead of for how to call that
variable.

\- Frameworks improve communication between developers. Implicit or explicit,
they usually have a language (human language) that makes the most challenging
part of software development (putting data in other people's brains) a bit
easier.

Note how this applies to larger teams and projects. it's totally possible that
a single developer working on a small thing is not the right user and use case
for a framework!

------
austerity
I too like to come up with rationalizations of my NIH syndrome.

------
franciscop
I followed this advice, I used document.querySelectorAll() with a .slice()
hack instead of jquery and similar methods. As I needed more and more
functions I kept adding them, and now I have a beautiful jquery alternative
[1].

It has helped me a lot to learn core Javascript concepts, testing my code and
hating Internet Explorer even more. I wouldn't change everything that I have
learned for anything. So try it, create your own small library, you'll learn a
lot.

[1] [http://umbrellajs.com/](http://umbrellajs.com/)

~~~
maxwin
So as time goes by, you ended up creating a jquery alternative. Now imagine
you work on a large team and everybody ends up creating their own
frameworks...

~~~
saiprashanth93
I think the above comment should be taken in the context of doing it for the
sake of learning, not for putting it to use in actual projects.

------
ludamad
The author doesn't mention using frameworks for prototyping, isn't that useful
for deploying earlier?

------
jameshart
All code runs inside some kind of a framework. It might be just the OS process
framework, which requires you to implement an entry point that handles command
line args, and provides you with access to threads and I/o streams. It might
be an http server framework, which hands you requests and waits for your
responses. Or it could be the web browser framework, with its Page lifecycle
and ui events. You're always in a box of some kind; frameworks typically do
things like create a different shaped box within an existing one (eg react
creates a reactive box inside the browser's event based one). They can create
the same shaped box inside different outer boxes (eg a jvm in a web browser
and a web server and a console app). Or they can just make a simpler, more
task-specific box.

Some frameworks are sandboxes - they don't let you even see the outer box (eg
a page running in a web browser can't use the 'OS process' box that the web
browser is in). Others give you a way to escape.

Sometimes it makes sense to intentionally box yourself in. It makes code
easier to reason about. If there's no possible way for code inside this box to
directly access files on this server then a whole bunch of security risks
become easier to evaluate. If there is simply no way for code in this box to
be multithreaded, a whole lot of synchronization risks just go away.

------
JDDunn9
I think this depends on the language. In languages where there is a de-facto
standard framework, like Python & Django or Ruby & Rails, frameworks are very
useful. Then slightly less useful in languages where there are many competing
frameworks, like PHP. Then there's front-end Javascript with its flavor-of-
the-month frameworks, where they probably do more harm than good.

------
hodgesrm
The author's argument stands or falls based on the meaning of the word
framework and the problem you are trying to solve.

Assuming Jersey and Spring qualify as frameworks and the problem is building
web services it's hard to see the argument against using them. It takes about
15 minutes from a standing start with Maven and Eclipse to build a simple web
service using Spring. Frankly unless you are writing the framework itself I
don't know why most people would want to deal with issues like marshaling and
demarshaling HTTP requests, let alone ensuring consistent adherence to REST
conventions. Life's too short to spend very much of it dealing with wire
protocols or worrying about low-level libraries that handle these problems.

The argument for frameworks gets even stronger when you start to consider
cross-cutting issues like security where there's a substantial penalty if you
get things wrong.

~~~
ChrisDutrow
I agree, as I look over these posts, it seems the people on opposite sides are
visualizing what "not using a framework" means very differently. I assume the
"not framework" people are selecting tried and true libraries, not writing
code to marshal http requests.

------
redblacktree
I think what some folks may be missing is that highly-opinionated frameworks
are extremely useful for less-capable programmers. I think most resistance to
large frameworks comes from experienced developers who don't agree with all of
the choices made by that framework. This is fine, and they shouldn't use it.

However, for someone who doesn't understand why they shouldn't pipe user input
into a SQL statement, a framework can keep them out of a lot of trouble. Even
though a more experienced developer may view it as "non-optimal."

------
stevesun21
Framework useful, no doubt, but , I saw so many programmer cannot even design
things without thinking about which framework they are going to use –
frameworks kidnap these people ability to become a real programmer. I can show
you an example right away, Ruby on Rails. I know someone they even cannot
design REST APIs without thinking about ActiveRecord, what a shame! Don't get
me wrong, frameworks is still good way to build things, but as a legit
programmer, you need to own the ability to solve the same problems even
without them.

------
al2o3cr
Two fun alternative reads of this article:

s/framework/high-level language/ \+ s/core language/assembler/

s/framework/operating system/ \+ s/core language/hardware/

~~~
ludamad
I certainly hope no one prefers hardware solutions to small abstractions :)

------
dools
I'm a huge fan of libraries, rather than frameworks. I wrote an article on
this topic some time ago, focused specifically on PHP[0]

I don't think that frameworks regularly achieve ANY of the results they set
out to achieve, and they age terribly.

[0][http://www.workingsoftware.com.au/page/Kill_your_index.php.h...](http://www.workingsoftware.com.au/page/Kill_your_index.php.html)

~~~
jon-wood
In any reasonably large organisation that is going to take you down one of two
routes.

The first is that you end up with a defacto framework made up of the libraries
that are useful in every project, with configuration copy and pasted from
project to project. At some point you'll end up abstracting all that out into
a higher level library, and boom, you're maintaining an internal framework.

The second, even less desirable, outcome is that every project in the company
uses whatever mess of libraries the person who kicked off that project liked
at the time. In that situation every time someone needs to work on a new
project they lose hours to working out which libraries were being used, and
learning how they fit together in this particular case.

~~~
dools
In python you can use flask, in php you can use php. In both cases there are
lots of common libs everyone will know how to use that can be included in the
project, but not tied to a single framework. Once you remove templating,
routing, orm and package management/directory structure from most frameworks
you're not left with anything useful. So solve those problems at a library
level. No framework required.

~~~
jon-wood
You've still created a defacto framework there by stating that your
applications are built by integrating libraries a, b, and c in a particular
way. You're also left actually maintaining that integration, and managing the
entire stack for all applications using it.

Maybe that's a win for you and the extra flexibility is worth the effort, but
that's probably not the case for most organisations.

------
Johnie
I'm curious about how large of a team/organization and size of the codebase
the framework vs anti-framework camps fall on.

------
AstralStorm
This after one or two lines of text feels like an evolved rant by someone who
had a specific issue with a specific framework and tries to justify their
drastic steps or NIH.

All abstractions have warts and frameworks are no exception. An annoyance that
is well known and cannot be easily fixed is no reason to throw out the baby
with bathwater.

~~~
esailija
Frameworks _are_ all or nothing, that is how they are different. Or does it
make sense to have a codebase that has a mix of angular, react, backbone and
ember for instance? Of course not. They are nothing like libraries in this
regard.

~~~
AstralStorm
Correct, which is why the choice of the framework should be done intelligently
and not haphazardly. A good framework is flexible enough to handle weird
corner cases with grace. Sadly, this is often lacking in the frameworks for
web development.

The author suggests not using any frameworks at all, while instead they
probably should write what they or most everyone should look for in one.

------
tarsinge
As always, it depends of the context. When I'm writing apps with complex
BUSINESS rules, and I spent the day with my client understanding a business
process, I can implement it in a few lines in Rails, from database to UI.
Frameworks are just another layer of abstraction, and sure you don't always
need it

------
stop1234
Most people are commenting about to use a framework or not.

The hard part is choosing which framework to use when you have so many to
choose from.

How do you do that? The simple answer of using the most popular one is moot
since we would all be using wordpress if it was about CMSs...

"Frameworks limit your scope of creativity" \- I get that.

~~~
mrweasel
>"Frameworks limit your scope of creativity" \- I get that.

I sort of agree, but I don't think it really matter that much. The majority of
the work people do are basically just database front-ends. You put stuff in,
you pull stuff out, your creativity is already severally restricted by the job
at hand. It makes a ton of sense to pick a framework for your CRUD
application, it speeds up development time by a lot, and the creativity
limiting effect is negligible.

Frameworks like Django provides a ton of features that there's absolutely no
reason to reimplement, because you're just going to do it wrong anyway. You're
not going to get CSRF tokens right and you're user management system is going
to have some weird flaw. It's not that people shouldn't try to write these
things, they absolutely should, but not if they're just trying to do a quick
application.

------
Walkman
This guy did not used Django yet. It does so much for you it's incredible.
Huge productivity boost.

------
Confusion
Most of these arguments seem to apply to any 3rd library, but I don't suspect
the author wants to argue against using those. I guess the question is: when
does a library become a framework and until when do the benefits of code reuse
overcome the cost of these downsides?

------
TurboHaskal
I guess he makes good points from a nerd's perspective, but I've found that
frameworks make hiring really easy, allow new hires to be productive early on,
provide a set of nice conventions and help reducing risks such as bus factor.

~~~
bobwaycott
And yet, these "easy" new hires still get subjected to interview questions
about algorithms and other useless things that don't actually matter to the
work at hand. Sadly, I've seen too many clients wind up with great CS
candidates who can allegedly solve all the things, but can't actually join the
team and solve all the _real_ things.[1]

[1]: Unless, of course, by "solve" you mean rewrite everything from scratch in
New Hire A's language and framework and toolset of choice because ... reasons.

------
rawfan
The author seems to be a big fan of re-inventing the wheel all the time.

~~~
esailija
Duplication is preferable to using the wrong abstraction.

~~~
AstralStorm
So don't choose a bad framework?

------
dschiptsov
Higly specialized do, general purpose bloatware don't.

------
rk06
Man, it sounds as if the author has suffered from js framework hell and thinks
all frameworks for all languages are bad.

------
finalight
if your codebase is already very large to the point that refactoring/rewriting
can take ages, then I agree with not using framework from 3rd party

however, for starter pack, it's best to use a existing good framework. There's
always a learning curve in whatever you do, but at least framework help you
speed up your development.

------
aikah
> Frameworks are one of the hugest anti-patterns in software development.

Says who ? this article isn't serious. If you're going to use an argument of
authority you'd better quote that authority directly instead of making stuff
up... seriously.

But I guess it was the outrage-bait of the day. Clearly some people know what
sells.

> Upgrading versions for no reason is another huge anti-pattern.

Says who again ?

Seriously, who is this guy ? what has he ever accomplished?

------
frik
Frameworks are all or nothing.

It's better to use libraries. That's also the right kind of abstraction.

------
hashkb
I completely agree, but this attitude gets you in trouble unless you're the
boss.

------
zby
Frameworks are framing libraries are liberating :)

------
poosanth
Very anecdotal and personal.

