
Yet Another Framework Syndrome (YAFS) - ch0wn
http://blog.tastejs.com/yet-another-framework-syndrome-yafs
======
hrabago
I believe it sometimes happens organically.

Code can be a very intimate affair. When taking on a new requirement that can
be fulfilled by an existing framework, there's a lot more to consider than
just "did someone already implement this"?

In the corporate world, we often remind younger developers that most of the
cost of the code is in the maintenance, not in the development, of software.
Having to tackle feature changes dependent on 3rd party software can be really
expensive.

If I'm working on a hobby project, I don't have enough time to do a full
evaluation of all options out there, nor do I have time to understand the
intricacies of a given framework to meet my unique requirements.

So, often, it takes just as much time to come up with my own mini-framework
and build it up as my requirements increase. If I reach a certain level of
functionality, then I may have something that I can share with other
developers. Everyone always touts the benefits of open source, and I may want
to get in on that, too. Besides, there's more glory in starting a project than
being the 51st person to contribute.

Disclaimer: I don't have my own framework, and has in the past been the Nth
contributor to what was then a de facto standard framework.

------
Jormundir
I don't think this article is giving enough consideration to what's going on
with web application development.

JavaScript is the de facto language of the web, so everyone is using it
whether it's the right tool for the job or not. The web is also rapidly
evolving its capabilities, so web applications are constantly changing in
nature.

YAFS is not really the problem, it's a symptom of a massively developed for,
single language, massively used platform. I'm sure it's exacerbated a bit by
javascript being such a poorly designed language, but this is more minor.

The solution isn't "research and mold what's already out there to your
problem", because this is only addressing the symptom. There's an explosion of
frameworks because there's an explosion of different use cases and application
goals on the web.

Rather than having to choose between 20 different programming languages, you
have to choose between 20 frameworks.

~~~
gtirloni
I'm skeptical about all these new frameworks solving uniquely new things. This
is not a syndrome of the Javascript community alone but of all IT: we never
look to previous solutions and research, and think we are discovering the
wheel every day.

Be it IT vendors rediscovering "cloud" concepts that were published in the
70's or a JS developer releasing a new framework that he rewrote using more
functional idioms because object orientation is so-yesterday.

Besides it getting boring for us old farts, it feels exactly how the author
describes it: more noise than value.

~~~
kawera
_" cloud" concepts that were published in the 70's_

Not only published, I did use _cloud computing_ in the 70's - we called it
_time sharing_. And our keyval, schemaless databases obviously couldn't be
called noSQL before the advent of SQL!

~~~
danellis
Cloud computing and time sharing are not the same thing, though. Time sharing
was just a way for multiple people to access the same computer at the same
time. In cloud computing, people aren't accessing a particular computer as far
as they're concerned; they're accessing a service that's out there _somewhere_
, and they might even have two consecutive requests handled by computers in
different data centers.

~~~
kawera
_...they 're accessing a service that's out there somewhere..._

Exactly what IBM offered in the late 70's.

~~~
ninkendo
If you want to distill all of what "the cloud" means into just "accessing a
service", then sure. Nothing's changed in 40 years because it's all still just
"clients" accessing "services".

Also, transportation hasn't changed in millenia because we're still just
humans moving places, and information retrieval hasn't changed since the
invention of the written word, because we're still just absorbing information
from glyphs on something that has distinct colors.

~~~
mikeash
He's not saying "hasn't changed". He's just saying that he was using something
that could easily be described as "cloud computing" four decades ago.

~~~
kawera
You are right. The technology has evolved but the concept is the same; we had
terminal servers connected to the nearest point of their private network over
a dedicated line and they run our software in one or more of their servers.

------
dgreensp
I would say there is a proliferation of immature libraries and a dearth of
_mature_ JavaScript frameworks and libraries that meet the needs and desires
of today's app developers. Mature frameworks are typically the work of many
developers over several years, and they require time, money, and good product
management, among other things. Five years ago it seemed a little off the wall
to start a company whose customers were JavaScript programmers (I did it), but
that's no longer the case, so I expect times will change.

I hope people invent lots of new ways to do things, and I hope the go-to
software of five years from now is not the go-to software of today. I hope we
aren't using jQuery and Mongo in ten years.

------
camus2
IMHO the problem is more about front-end javascript than nodejs since
Javascript doesnt have a module system,there is no rule as to how to write a
library and include it in one's code. CommonJS and AMD are not JS specs. Ajax
and the DOM are not javascript.

So front-end devs , instead of writing libraries that depend on other
solid(and maintained) projects, either include dependencies or rewrite stuffs
they will not maintain. That's the nature of javascript.

As for the question is there too many frameworks, I disagree. devs will mostly
use frameworks that are well documented and maintained. If the last commit in
your project was 2 years ago, if you dont have an issue tracker set up or you
dont fix bugs, if there is no test other devs aint gona use your library
that's a fact.

But again , open source projects are basically free work,so let's not
complain. Let's also not forget that Javascript is usually easy to read and to
fix. We are not talking about fixing some C++ here...

As a dev it is also your responsability to vet libraries.

------
joesmo
A framework without documentation, is not a framework at all. The article
spends a bit of time on this, but I believe it's worth reiterating. The reason
for using a framework is to not have to rewrite common functionality. Without
good, complete documentation (both in code and external to the framework) one
cannot even evaluate a framework in a timely manner.

While doc-blocks and comments are crucial to all code, and especially crucial
to framework code, a framework that relies solely on auto-generated
documentation is one without complete documentation. There is more to
documentation and the coherency of a framework and its use cases than
describing its microscopic parts.

~~~
collyw
Angular documentation is awful, and its one of the most popular out there.

------
maaaats
After spending some time in the JS and NodeJS world, I feel there are waaay
too many immature libraries out there.

It's very easy to publish a library in the JS world. Just add some boilerplate
and everyone can grab it through npm or bower. In the Java world getting it in
a repo through maven is a bit harder. But that leads to fewer projects to
maintain and focus on, in the JS world it's a bit too "forked" for my taste.

------
dools
After years of dealing with the same issue in PHP, I have come to the
conclusion that frameworks should be evaluated based on two criteria:

1) How quickly can a developer who is competent in the language (ie. a non
ninja-rock-star) but has never heard of the framework understand what's going
on?

2) How hard is it to take the value that I create (ie. the code I write) and
move it to a different solution?

Of course the result of these is that the best framework is no framework at
all... In the case of PHP, at least.... in JS it may be the case that some
minimal framework is required, but as much as possible I think that libraries,
more than frameworks, are the key to this issue.

~~~
krapp
Actually I think in PHP's case the best framework is at best minimal, but
something more than none at all. Anything beyond Composer and a PSR autoloader
to manage libraries, a router to abstract requests from the filesystem and
(arguably) a templating engine is nice but not absolutely necessary. But I
think PHP is a nightmare without at least that.

------
runT1ME
If you constantly find yourself looking at new frameworks to save time, reduce
boilerplate, make development and debugging easier, you may want to
acknowledge that it's not the _framework_ at fault, but the language itself...

~~~
taeric
The reflection may not stop at the language. Many of these "terrible"
framework/languages have plenty of folks accomplishing a lot of stuff with
them.

Not trying to claim that everyone that complains is bad/wrong. Rather, the
field often acknowledges that learning a new language can help "learn a new
way to think." Seems that sometimes we neglect that one needs to learn the way
of thinking for the language/framework they have, and less worrying about the
language/framework they wish they had.

~~~
Mandatum
The amount of 'bad/wrong' frameworks that are present in PHP (as an example,
don't mean to hate-monger) is astounding. These are usually the 'discontinued'
ones that people have gotten used to and find a hard time moving on from, so
in some cases I think it is reasonable to look for a new framework rather than
continuously hacking their way to the finishing line.

~~~
taeric
That may be, but when the rubber hits the floor, you are often better learning
to "think in the framework" that you have, than you are trying to reinvent yet
again. This can be just as true when considering new frameworks. They may be
better, but that doesn't mean you have time for them.

And I fully acknowledge that this is an art. Knowing when to consider making a
change is a tough piece of knowledge to try and hammer down.

------
morganherlocker
And yet, if I were to meet someone who was a few months into a new js web app,
I could probably guess which framework they were using with 5 guesses or less
95% of the time. Also, I would bet that all 5 of the top frameworks will be
reasonably supported for the next 5 years. As for the many frameworks that
make up the last 5% of usage and have shakier futures, I doubt many new devs
are actually using them.

It is always a red flag for me when someone starts arguing for less choice,
more monolithic frameworks, and the inevitable lock in that comes along with
having only one or two options.

------
thatthatis
This sounds an awful lot like what they were saying about python 10 years ago.

Perhaps the problem is that we have a large opportunity before us and it isn't
obvious which frameworks are going to win.

------
jph
I'll donate $100 to anyone who wants to build a wiki-style community-owned
comparison of the various frameworks, tools, libraries, books, etc.

~~~
ch0wn
We added a sidebar with learning resources to the demo pages in the last
release of [http://todomvc.com](http://todomvc.com) which we constantly
update. Obviously, that's only an entry point for further research, but I
think for most libraries or frameworks it's easier to maintain those kinds of
information in one place.

~~~
jph
Nice! I'm donating $50 to you for project now. (And $50 to Wikipedia)

------
CmonDev
The biggest issue is the glorification of web-development. It's just a GUI
layer in a weak script language in the end of day. Just pick any framework you
like at the moment, there will ten new ones by the time your next project
starts.

------
transfire
Corollary of YADSL, Yet Another Domain Specific Language.

