
The State of JavaScript in 2015 - sahara
http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/
======
wycats
I completely agree with this post that there is churn fatigue. Part of that is
in libraries, but an even bigger part of it is in the tooling that people use
to build JavaScript applications.

It's easy to see all of these new things flying by, combined with changes to
JavaScript itself, and feel completely overwhelmed. To be honest, over the
past two years, even as a maintainer of Ember, I have experienced very serious
hype fatigue.

This is a large part of the reason behind Ember's philosophy of finding and
implementing strategies for stability without stagnation. On the one hand,
people (including us) are tired of the constant barrage of new tools and
techniques. On the other hand, it would be terrible to get beaten by a
competitor that discovered a wonderfully productive new solution. The Ember
team has spent the last few years honing a process for dealing with these
conflicting desires.

That process involves:

* six-week release cycles, so every new change is incremental and adds value on its own

* canary, beta, and release channels (just like browsers), so that people will more appetite for churn can help test out features, and get them stable by the time they ship as part of a final release

* SemVer, so upgrading across final releases is relatively painless and the biggest part of our community can take advantage of the improvements as they roll out

* having each member of the core team build apps that we care about and maintain, so that we can feel the competing costs of maintenance and keeping pace with the latest and greatest first hand

The core ideas come from shipping browsers, which have had to deal with
requirements of very strong stability with an increasing desire to "go fast".
The pace of new browser features has been so good, in fact, that they have
been used as an argument in favor of completely breaking things and starting
over.

Ironically, the browser instead shows us that if we want to avoid stagnation,
we are going to have to have strategies for bringing people along. Stability
without stagnation is not a paradox; it's a recipe for success.

(we talked a lot more about the nitty-gritty technical details in the
previously discussed Ember 2.0 RFC:
[https://github.com/emberjs/rfcs/pull/15](https://github.com/emberjs/rfcs/pull/15))

~~~
sant0sk1
FYI: Yehuda and Tom talked to us about "stability without stagnation" and
other philosophies behind Ember 2.0 in episode 131 of The Changelog:
[http://thechangelog.com/131](http://thechangelog.com/131)

~~~
notduncansmith
FYI: You're replying to Yehuda.

~~~
girvo
One of the funnier idiosyncrasies of Hacker News.

------
vjeux
The way we tried to open source our front-end stack at Facebook is to release
a collection of standalone libraries. This strategy worked very well to
integrate with existing codebases but we're missing a very large audience:
people starting new projects. It's not trivial at all to glue all those
projects together. So while it's tempting to reject "framework"-type projects,
that's actually what a lot of people want and our most common request.

\- React: [http://facebook.github.io/react/](http://facebook.github.io/react/)

\- Flux: [http://facebook.github.io/flux/](http://facebook.github.io/flux/)

\- Jest: [http://facebook.github.io/jest/](http://facebook.github.io/jest/)

\- Immutable-js: [http://facebook.github.io/immutable-
js/](http://facebook.github.io/immutable-js/)

\- Flow: [http://flowtype.org/](http://flowtype.org/)

\- JSX: [http://facebook.github.io/jsx/](http://facebook.github.io/jsx/)

~~~
MrBuddyCasino
This looks like a good opportunity to point people at Mercury:
[https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

It is similar to Mithril, but with a strong focus on modularity. To quote the
website: "mercury is a small glue layer that composes a set of modules that
solves a subset of the frontend problem."

You can basically swap out things that you don't like, use it with Backbone or
JSX etc. Its weak point currently is documentation, which is of course a
biggie.

------
ChicagoDave
I've been a developer for over 30 years and there's _always_ churn. You will
_always_ have to learn new things. That's just the way it is. Some things are
truly better (C#) and some things are not (Flash). It often takes time to weed
out the truly bad things, especially if the bad thing is the only thing that
solves a noteworthy problem (how to provide high-end interactive animated
content through a browser aka Flash). We've managed to move most of the basic
concepts of Flash to the browser via HTML5 and that is very clearly a better
solution.

The Angular 2 issue is somewhat curious. My biggest question isn't about the
new teaser specification. It's what happens to the current version. It's open
source, right? I suspect a number of corporate babysitters will provide the
support required to make sure 1.x lasts for a decade or more. If you choose to
adopt 2.0 for _new_ projects, so be it. Although why on earth the A2
architects chose to break XHTML standards baffles me. An attribute in parens?
Seriously?

I personally see the new JS world as a step forward. It's absolutely a molten
spew of new and unproven code, but it's also easier to build things than ever
before. There are a ton of problems solved with a front-end MVC connecting to
a service layer. A TON.

The hard part is that we need better tools all around for JS that we've been
spoiled with in C#, C++, Java, and even Assembler.

But one more thing that's hinted at, but I'm suddenly asking myself. What if
Anders Hejlsberg (C#/TypeScript) were to publish a monolithic front-end
MVC/MVVM framework and its use was built into Visual Studio 2015, which is
going to be free at the Pro level? That would throw even more F bombs into the
JS world.

In any case, if you're a senior developer or architect and making decisions
about technology, you better know what you're doing. You can pick 2% usage
code, but you better own it.

~~~
bshimmin
Addressing just a small point from this: a lot of people working on the web at
the moment have absolutely zero interest in using Visual Studio. Like, say,
all the people using Macs.

~~~
pjmlp
> Like, say, all the people using Macs.

Outside US, it is a very small number.

~~~
timrichard
You could go to just about any tech meetup event in London and see that isn't
true. And these people are largely the hiring pool for web applications.

~~~
pjmlp
People in the UK have a very good salary in comparison with average European
one.

------
doublerebel
This only refers to frontend JavaScript and reflects the opinion of a dev who
hasn't been using JS all that long. Angular was never that great a framework,
it's popularity was by and large because it came out of Google. It's far too
tightly coupled to the DOM and was therefore destined to have problems as HTML
and browsers evolve.

Npm is stable, Backbone is stable, Node is stable, Gulp is great, and devs
like myself who have seen trendy frameworks come and go (Batman.js and jQuery
templating come to mind) are still using the same great composable tools that
were better designed from the start.

Backbone (and my favorite, Spine) are built on more loosely coupled components
and can be used on applications which have no DOM, such as Canvas games or
native mobile apps. Browser fragmentation has been an issue since the dawn of
JS -- and these days the JS ecosystem extends far beyond the browser.

Take a look at the mature tools for front or backend that major companies rely
on and be glad that the open-source nature of JS produces so many options and
rapid evolution.

~~~
pluma
Factors in Angular's success:

* backed by Google * MEAN * plenty of media/blog coverage * seductive examples (that don't reflect best practices)

My personal gripe is with the last point. A lot of the appeal is in the two-
way binding -- which is often the first thing to go out of the window once
scaling becomes a problem.

Also, I have no idea why the author thinks Browserify and Angular go well
together. They don't. At all. Browserify is great on its own, but there's not
really any "blessed" way of using a module system with Angular (and like
jQuery Angular 1.x is tightly coupled with the global scope).

~~~
Illniyar
I haven't seen two-way binding go out the window with scaling.

It's still the number one selling point and greatly reduces development time
in both small and large applications.

The only thing I've seen is that in bigger projects, if there are locations
where huge amounts of binding might take place (such as drawing, tables,
etc...) you don't use two-way-binding in that particular place.

And in any case many of the popular frameworks (Ember, backbone etc... ) also
use two-way binding, they just don't support two-way binding on simple js
objects. And for that many of the bigger frameworks (

~~~
Offler
> The only thing I've seen is that in bigger projects, if there are locations
> where huge amounts of binding might take place (such as drawing, tables,
> etc...) you don't use two-way-binding in that particular place.

Sounds like two-way data binding went out the window then...

------
sosuke
My stance has been to take a more static view of an applications development
life cycle. So you're on an Angular 1.x app, Angular 2 is coming out in a
year, your project will be launched or is already launched and you're
concerned with switching.

Stop, right now, just let it go, take a step back from the bleeding edge and
see that you've got all the JavaScript libraries and tools you need to put
together any application you could imagine. If your imagination is big enough
then you'll be hand writing your own additions in no time. So long as your
applications runs on the major browsers latest-1 without issue there isn't a
reason to upgrade. If you're writing a project there isn't a reason to make a
framework jump, and if Angular 1 to 2 is that different, consider it a
framework jump. Why feel bad about not knowing your way around when you go
from one framework to another, would you feel the same going from Drupal to
Wordpress? They are both CMSs, both PHP, both extended far beyond their
initial goals. Angular 1 will go into maintenance if Angular 2 is that
different, development will slow, and eventually you'll upgrade to Angular 3,
which is incompatible with Angular 2, but after years of having a working
application.

I've gone from Angular, to Kendo, to Ember, to Backbone. If you want to make
an 'investment' in knowledge of front-end development learn the plain
JavaScript, read through the framework you're using. Walk through the
execution, that will allow you as a developer-for-hire to pickup the newest
shiny on a new team with less issues.

Web development has always had this pace, whatever tool or setup you commit
too, the next week someone will call you an idiot for using it. Ignore them,
make something maintainable, nothing in the new framework is ever mission
critical, just nice to have.

~~~
tracker1
Exactly... I worked on a project a couple years ago, and decided to use a beta
version of bootstrap as the baseline for the project... I cloned the repo,
merged the pieces into my project, and kept a copy of the docs at-that-time
for reference.

The site still works great... the codebase is fine. It was before some later
changes to bootstrap 3, so it isn't current with the released version, but it
still works, and did better so than v2. The same goes for most things
involving open-source tools. You can go through migration cycles, or accept
and limit the scope of how you use it.

I always applied the same arguments for using Mono in places as a practical
reasoning. So what if new development stopped/dropped or rolled.. as long as
what I'm doing can keep running.

Your best bet is to keep your codebase modular so much as possible, and it
makes it easier to replace certain pieces.

Today, I really like react + yahoo's flux implementation. There are some weird
corner cases I've had to deal with, it's still nice. It really just depends on
your needs.

------
kangax
This is nothing new.

Back when I was starting, it was all about "JS libraries"; when Prototype.js
gained the most traction at one point, beating in popularity older Dojo.
Still, there were new libs popping up again and again — Mootools, MochiKit,
YUI, jQuery. jQuery "won" by introducing a simple and powerful concept of
operating on collections via an intuitive API.

Then there were modules — AMD, Require.js, Common.js, etc. New "standards" and
libraries competed and everyone claimed to be the best.

Then Backbone and others brought a new perspective on widgets via sort-of-MVC,
and a whole slew of libs emerged — JavascriptMVC, Knockout.js, SproutCore ->
Ember, Angular, etc. All similar concepts rearranged in a different flavor,
shifting abstraction into one layer or another, with different levels of
convention.

In the end, every wave brings something good. Right now we have React &
Ractive bringing concept of virtual DOM. It seems long overdue and sorely
needed.

Staying at the edge must be exhausting. Staying in the middle of a bell curve
is best bang for your buck.

------
cageface
_By using small libraries – components with a dedicated purpose and a small
surface area – it becomes possible to pick and mix, to swap parts of our front
end stack out if and when they are superceded._

This is the problem with front-end dev in a nutshell. Everybody is mixing and
matching their own solutions which makes it impossible for an ecosystem of
higher level, reusable components to emerge. Compare this to iOS, for
instance, where I can go pick and choose from a huge online library of
prebuilt components and be fairly confident I can just "pod install" them and
go. I'm not a fan of Angular but it was a _good_ thing for there to be
something like a de-facto SPA framework standard. I can only imagine how upset
business owners that invested heavily in Angular 1 apps are feeling now.

If web developers are serious about mounting a challenge to the rising tide of
native apps, they need to build some consensus and agree on some durable
foundations. In the end elegance and novelty count for nothing if you don't
have a healthy, stable ecosystem upon which businesses can depend. It's sad to
think that the freedom that makes web dev so appealing may also turn out to be
its fatal weakness.

~~~
sehr
_Compare this to iOS, for instance, where I can go pick and choose from a huge
online library of prebuilt components and be fairly confident I can just "pod
install" them and go_

I believe this is the one of the main motivators behind web components

~~~
cageface
I haven't built anything non-trivial with web components but I do like where
they're going with them in principle. The biggest problem I see with WC is
that they require native browser support to really function properly and I'm
not sure it's really in Apple's or Microsoft's best interest to support them.
AFAIK Apple hasn't made any indication so far that they will support the WC
spec.

~~~
Offler
I think the biggest problem with WCs is they are standardizing best practices
from 2011/Angular early days. Things have moved on and mutable two-way state
that binds to a stateful DOM is no longer state of the art.

------
cromwellian
Not sure why he is including GWT. Google continues to fund GWT. We just hired
another full time engineer on the project. We just released GWT 2.7 which has
a massive number of new changes, including an all new incremental compiler
that reduces development recompiles from minutes to seconds.

We have a lot more external contributor interested that in the past now, have
accepted many more patches, and we just landed Java8 lambda method support,
with even more cool stuff to be shown at GWTcreate.com conference in January.

In other words, Google has not removed support from the project, which has
continuously existed since 2006. Not sure how much more dedication you want in
funding for an open source tool/library.

~~~
brey
so instead of being a tool which Google has already removed support for, it's
in the bucket of tools which - at least to me - should be treated as liable to
be cut at any time and don't rely on it.

sorry, Google lost any credibility in this area over the Reader fiasco -
Google has no interest in maintaining a project for the good of a community,
if it doesn't align with corporate strategy. 8 years history means nothing.

~~~
coriny
"... it's in the bucket of tools which - at least to me - should be treated as
liable to be cut at any time and don't rely on it."

Unless you've paid for a guaranteed period of support, bug fixes and
extensions of functionality, this how you should treat all code libraries
surely? All libs come as is, and statements of future actions are always
expressions of intent, not facts. If your company is utterly dependent on a
single free 3rd party library then you should be prepared to take over
ownership of it - or accept that your company's survival is at the whim of
another. Personally, I would not be swayed by any brand name here - but who
would you trust (enough to bet your company on) to provide long term support
for a free OSS library?

Personally, I would consider the closing down of a very niche, free, consumer
product based on a seemingly dying web technology as a very poor guide towards
how Google will treat GWT, which is actually used by them for website
development.

------
Illniyar
I'm not sure if this churn is unique to the javascript and front-end world.

When I used to work in Java a few years back, there was a new "favorite"
framework every few months:

* build: ant, then maven and just when maven started getting massive traction, gradle.

* web frameworks: JSP, JSF, Spring MVC, Wicket, Tapestry, GWT, struts, dropwizard (and compiled java - Grails, Play etc...).

Even "standards" made by the "governing body" conflicted with each other -
JDO, JPO and ESB (the persistence part, though I'm not sure if there was a JSR
for that) for example.

A new web shop even had a hard time choosing the Language of the month:
Groovy, Scala, Clojure.

If you go broader then the Java world, then the flavour of the week platform
was even harder to pinpoint- ASP.net ,PHP,wordpress,drupal,rails, node etc...

Not to mention databases - from everything must be relational in one Monolith
DBS (oracle mostly) to sharded mysql with memcache layer, to only noSQL
(usually mongodb),then to polyglot persistence (I.E. use what fits) and now
into the brave world of natively distributed sql (I.E. newSql).

I don't think it's the front-end that is high churn, I think web development
as a whole has changed so much in the last few years that the technologies
involved has changed drastically.

At least in front-end development you one language, and the knowledge of some
universal standards (you aren't going to need to relearn HTML and css).

Also there is still jQuery- which regardless of how many things are built
against it, it exists in practically every site.

~~~
gred
> build: ant, then maven and just when maven started getting massive traction,
> gradle

I'm not sure that I would call 3 big build systems over the course of 20 years
"churn" :-)

> web frameworks: JSP, JSF, Spring MVC, Wicket, Tapestry, GWT, struts,
> dropwizard (and compiled java - Grails, Play etc...)

The height of the churn corresponded to people trying to handle MVC on the
server side, and seems to have subsided somewhat as people have simplified the
server side (RESTful APIs) and moved the MVC to the client side.

I wonder if this churn is somehow intrinsic to the type of problem being
solved (user interaction), rather than to the technology / language /
community.

~~~
Illniyar
in regards to build, I was talking more about when these systems became
popular/hyped/adopted rather then when they were released.

Maven didn't became really adopted until 2.0 came out, and, to me at least,
Gradle gained traction extremely fast after Maven was adopted (along with sbt
for scala and others). I think Maven laid out the foundation for the adoption
of gradle.

But yes, it's a lot farther apart then Grunt vs Gulp. I was more trying to
show that build systems change even for very stable languages/ecoSystems
(relatively speaking).

In regards to problem solved - it's an interesting thought, I haven't done a
lot of ui outside of web, I wonder if other people can shed some light on
churn regarding ui frameworks on desktop (or even flash/silverlight/unity
etc...)

~~~
empthought
There is some churn in layout recommendation and widget availability, but the
fundamental application construction model in iOS 8 is the same as it was for
OpenStep 20 years ago.

~~~
gred
Open source; MVC; API stability -- choose two?

------
grumblestumble
The whole "use lots of little modules" idea is great on the surface, but when
you have to build large applications with small teams, I find it fails:

\- There are always multiple choices for each piece of functionality you need
to address, and personality clashes over which is the "best".

\- Security is a whole lot harder to nail down with more moving parts. Go with
Angular, you have this: [https://code.google.com/p/mustache-
security/wiki/AngularJS](https://code.google.com/p/mustache-
security/wiki/AngularJS). Similarly, Ember:
[https://code.google.com/p/mustache-
security/wiki/EmberJS](https://code.google.com/p/mustache-
security/wiki/EmberJS). Even though these frameworks aren't 100% secure
(although Angular comes pretty close), you can be more aware of the pitfalls.
The more independent modules you have to keep track of in your app, the more
difficult it becomes to track security flaws.

\- Some seemingly unrelated components just don't end up playing nice with
each other, and this can be hard to determine ahead of time.

------
dpweb
I think alot of the devs today have grown up with all this frameworks on top
of other frameworks. The problem is you lose power with every layer of
abstraction. It's the price you pay for it. They also abstract at too low a
level, especially since browsers have caught up. They don't need provide a new
custom ajax for instance, XHR as implemented in the browser works quite well
without imposing an arbitrary syntax on top. So I think people have moved
increasingly to vanilla. We've come full circle with the opinionated
frameworks and some people are frustrated and where do we go now?

Web components are the most promising development, because the preferred
approach in sw development has always been isolation/separation of concerns.
This is pretty much the opposite of the JQuery style. In theory you can
separate using JQuery but in practice still in 2014 you cannot look at source
in any moderately complex web app and understand what's going on. Ultimately,
its going to have to be a DOM/JS mix (Those aren't going away for a long time)
but they never got it quite right. The web component frameworks are the best
thing going for the future.

IMO they should be declarative, that is - in the HTML - but programmable, and
that's the way things have been heading. So in 10 years we'll still have the
DOM and JS (although it would be interesting to have more languages easily
usable in the browser). As Polymer evolves it (or some equivalent) will make
it into the browser.

~~~
Offler
> IMO they should be declarative, that is - in the HTML - but programmable,
> and that's the way things have been heading.

Sounds like React. WCs templates aren't programmable that's a DSL that is
specific to Polymer.

~~~
dpweb
The mingling of HTML/JS in React I find unattractive (at best) but I'll have
to look into React some more.

~~~
akrymski
This was my first reaction as well. I've tried using React but the designer in
me hated having views inside my controllers. So I've ended up writing vanilla
js, and a helper MVC framework:
[https://github.com/techlayer/espresso.js](https://github.com/techlayer/espresso.js)
which borrows a bunch of concepts from React but is really just a tiny helper
lib.

------
kartikkumar
As a relative beginner in front-end dev, I have to say, the whole JS world has
me completely flummoxed. I really don't know which way is up and given that my
time is at a premium at the moment, I want to learn something that is going to
give me a firm foundation in the long-term. It seems with all these frameworks
that it's like betting on a horse blindly, at least to someone who only has a
cursory view of the JS landscape. I've played around a bit with Express.js and
with jQuery, but not enough to know which way is up.

I've been wondering if all this change means that the real way for me to start
is diving straight into vanilla JS. I have a firm grasp of Fortran, C++ and
experience with MATLAB, SciPy, and Julia (recent) for scientific computing.
Coming from the engineering world though, I have no sense how the front-end
dev community is shaping up, and that makes me nervous about deciding where to
spend my time learning. There are some fun projects I have in mind to bring
some of the engineering stuff I've done to the web (e.g. an asteroid redirect
mission calculator), but I'm worried about spending time learning a framework
that'll just disappear by the time I even really get going.

Does all of this change mean that, in the long-run, I'm best working my way
through vanilla JS and at a later stage making using of frameworks or
libraries to make the more mundane programming tasks a synch? Or should I
actually be starting off by learning a framework? Input highly appreciated!

~~~
dccoolgai
"I've been wondering if all this change means that the real way for me to
start is diving straight into vanilla JS."

Yes. If you learn JS really well, you can adapt to the framework-du-jour
quickly. Learn the DOM , Learn the Web Standards: Two years from now, these
frameworks may or may not matter but the things that are happening in Web
Standards like ServiceWorker, Components, RTC, etc. definitely will. If you
are searching for the branch to cling to in the storm, it is this: Web
Standards (which includes "Vanilla" JS). Start here and work your way
outwards:
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/)

~~~
kartikkumar
Thanks, I guess that's along my line of thought at the moment.

My interpretation from my limited exposure is that RoR is a big step up from
"vanilla Ruby" and that the community in that case is consolidated enough that
it's pretty much a no-brainer to just start with RoR as a beginner. In the
case of JS it seems like a movement towards consolidation in that sense is
still a long way off, meaning that "vanilla JS" knowledge carries more value
than it might do 5 years from now. I've also wondered if all the energy that's
being pumped into frameworks and libraries wouldn't yield more if it was
targeted towards completely replacing JS with something that's more akin to
modern (front-end) dev from the ground up. Maybe that's a silly thought, given
legacy and the close relationship with browser development, but as an outsider
it seems like a lot of energy is spent on "warring" that could perhaps be
focussed more productively in a different direction altogether.

Any other JS resources you would recommend to start from the bottom
outwards/upwards?

~~~
dccoolgai
Resources:

1\. [https://developer.chrome.com/devtools/docs/console-
api](https://developer.chrome.com/devtools/docs/console-api)

2\. [https://developer.chrome.com/devtools/docs/commandline-
api](https://developer.chrome.com/devtools/docs/commandline-api)

If you are doing webdev, Chrome DevTools is _everything_. The console and CLI
are your window to the truth. It literally spells the difference between
wondering why things work like an idiot and knowing it like a boss. Pay
special attention to getEventListeners(IClickThisAndItBreaks),
debug(WeirdFunction), console.trace().

3\. [http://caniuse.com/](http://caniuse.com/)

The things in that list: You should know a lot of them. You should know OF
almost all of them (what they do on a conceptual level).

4\. Hate to reco a paid thing, but this book was critical to me: Secrets of
the Javascript Ninja by Resig. TL;DR: Everything in JS is a function. There is
1 thing to know about functions: The "Everything/Nothing Rule" (my paraphrase)
- Scope has everything to do with how the function is declared and nothing to
do with how it's called. "this" has everything to do with how a function is
called and nothing to do with how it's declared.

5\. Embrace Function-ness: lodash.com/docs

6\. Embrace Event-ness:
[http://api.jquery.com/callbacks.add/](http://api.jquery.com/callbacks.add/)

7\. Embrace Async-ness. Easiest way for me on this was to dabble with Node -
async.js & promises.

8\. After you lock all that down (don't get scared - it's actually easier than
it sounds), learn how a browser really works and performs. Good place to start
on that: [http://superherojs.com/](http://superherojs.com/) \- "Under the
Hood" section. (Other good links there, too.)

9\. Follow people like Jake Archibald to learn about the Web's "coming soon"
stuff like
[https://jakearchibald.github.io/isserviceworkerready/](https://jakearchibald.github.io/isserviceworkerready/)

~~~
kartikkumar
Wow, awesome list! Thanks for putting the time and effort into putting that
together. Sounds like I have a plan laid out to get started over the winter
break! Thanks!

------
rurabe
I agree that fragmentation is a problem, but don't understand why the solution
to that problem should be smaller, fragmented libraries instead of larger,
complete frameworks. Isn't that the same problem described in combining all
the tools with small market/mind share? In my experience, far more problems
arise from the interaction of separately authored modules versus the
interaction of modules designed to work together. Not to mention that there
will be far more blogs and SO posts about a larger framework.

~~~
bsaul
I came to say the same. If you multiply the number of dependencies, owned by
different people, having different interest, you multiply the chances of
having to catch up with a problematic update.

On a more general pov, the debate between "integrated design" and
"modularized" design has been going on for decades. We know the advantage of
both. The problem right now is that angular made a desition to break
compatibility in a major way while their framework was barely becoming
mainstream. Let's not make it a bigger problem.

People that invested in the .net framework, or in the unity framework, did not
make a blunder. All we need is an equivalent in the front end js world.

------
hrish2006
I wonder if we need any JavaScript framework at all, given how far JS has come
in recent years, yes, I use an MVC framework currently for the apps I'm
building but I'm writing more and more of my apps these days using nothing but
vanilla JavaScript(ES-6 to be exact) and the dom apis, and I'm not depending
upon any framework. (well, I use traceur but only because ES-6 support is not
fully baked in to all browsers). IMO the frameworks that are all out there
today are simply too big and try to do too much for you. The only libraries I
use from time to time are underscore, d3 and moment.js.

~~~
pluma
I'm finding that in many cases the old adage holds true: "You're always using
a framework. Either you're using an existing framework, or you're building
your own." (paraphrased)

Sure, if legacy browser support is not a concern and you don't need to support
bleeding-edge features (i.e. unstable APIs), you can go a long way with
vanilla JS. But at some point any large system needs abstractions in order to
stay maintainable. And if you don't use existing abstractions, you'll have to
come up with your own abstractions.

Of course the other option is to simply not build large enough systems to
require abstractions.

That said, I do prefer smaller libraries, too. This is why I see React not
being a full replacement for all of Angular as a feature rather than a
limitation.

I only ever began considering Express as a framework when it dropped the vast
majority of its features (mostly middleware) in 4.x, too.

~~~
hrish2006
Well, a custom framework might evolve when you write everything using just
JavaScript, but I've found that when such a thing does happen, it suits your
needs perfectly. Even if I screw up, I'll at least know where to look when I'm
debugging :)

~~~
andybak
Time to wheel out another paraphrase of Greenspun's Tenth Rule
([http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule](http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule))

How about:

"Any sufficiently complicated collection of libraries contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of a full
framework"?

;-)

~~~
hrish2006
That sounds about right :) . However, you need a great degree of discipline
(greater compared to other languages IMO), to write good JS. JS enforces
almost nothing, so it's up to the programmer to design an application
architecture that suits her, so it might not be as ad-hoc in real life
applications after all.

------
Mc_Big_G
Ember had a lot of growing pains, but it's starting to come out of it's cocoon
and spread it's wings. When you combine it with the massive productivity boost
of ember-cli, tooling that does all the tedious and hard shit that no one
wants to deal with, it's a big win.

I recently made a simple app and decided to just write it in jquery and
constantly found myself missing doing things "The Ember Way"™ Building an
"ambitious" application in jquery alone would be complete madness and half-
hearted frameworks don't really give you much benefit for all the wrestling
you have to do.

I really like that the Ember team strives to find the right way and deprecates
parts of the api that they find people using in bad ways. I've also seen a lot
a pragmatism around preventing bloat like removing string inflections etc...

The best advice I have if you really want to try Ember is to read the guides,
completely, word for word. Then try to write a simple app, using the
guides/recipes/API for reference and then read the guides again, completely.
Then do all that again. It won't take as long as you think and you'll be far
ahead of where you would be reading some introductory blog posts.

Admittedly, I have been frustrated at points, but that's par for the course
with any js framework at the moment and if I had chosen Angular 1.x for any of
my previous clients, I would be VERY embarrassed right now.

~~~
tragic
I like ember well enough, but sweet jesus it's _huge_. We have a page weight
budget; 350k of ember plus 100k of jquery plus 50k of handlebars leaves about
-150k for all the ad/analytics code the rest of the business needs. It's just
not going to happen.

That's a serious advantage for angular - it's pretty small for what you get
out of the box, and there are no external dependencies.

I saw in the Ember 2 RFC that they hope to slim down a little, which would be
good (especially now that Angular is going mad), but for those of us who don't
want to send a great hulking wodge of stuff to every P.O.S. phone that so much
as glances at our apps, it's going to have to get a lot smaller.

------
akrymski
Small libraries win out every time, as soon as there is a decent package
management system. Just look at what happened with Node and NPM - npm really
rocks, and the whole node ecosystem is choke full of great and small libraries
that fit together nicely.

I write node on backend and frontend, and package the frontend using
browserify into a single index.html file that contains _everything_ the app
needs, so it's one HTTP request to fetch the app. That's the new binary format
of the web, and all the dependency management is done for you. It's bliss. For
the frontend I used vanilla JS to write a small Backbone-style library to meet
my needs:
[https://github.com/techlayer/espresso.js](https://github.com/techlayer/espresso.js)
because even Backbone seemed too monolithic to me (requires jQuery/Zepto).

I've tried React and Angular, but I simply don't understand what they offer
over Vanilla JS. What developers really need is to agree on a package standard
(NPM!) so that small libs can flourish. There are tonnes of great libs on
github but unless they are in npm, it's just a hassle, let's face it. Frontend
devs need to adopt the same approach of publishing everything to npm as Node
devs have been doing for years. You don't see monolithic frameworks in Node
world because the package management system _just works_. I don't care about
standards, but if everyone embraced _something_ the world would be a much
happier place.

~~~
jnem
>I've tried React and Angular, but I simply don't understand what they offer
over Vanilla JS.

Agreed, especially considering many devs choose Angular, Ember, etc. to
perform easy two-way data binding. However, two-way data binding can be
achieved fairly easily in vanilla JS. I recall Javascript Weekly sharing a
great article about how simple it is to do:
[http://www.sellarafaeli.com/blog/native_javascript_data_bind...](http://www.sellarafaeli.com/blog/native_javascript_data_binding)

------
at-fates-hands
As someone who was drinking the AngularJS kool-aid, the merry-go-round joyride
ended abruptly for me and my startup after the Angular team announced a lot of
the updates they were planning, including the obsolescence of previous Angular
versions at the ng conference in October.

My partner and I had about 8 months of dev time into a directory app we were
building on the MEAN stack. It just so happens AngularJS was a big part of
that architecture.

After some long conversations over beers and some teeth gnashing, one thing
became clear. If the Angular team just decided to make these huge changes now,
what keeps them from doing it again in the near future? If they have no plans
now of making newer versions backwards compatible, does this means every new
version will be this way? All it did was create huge questions of trust and
reliability with using a framework which could dead end your project somewhere
in the distant future. This meant continually looking over your shoulder,
which is not good for any business.

Our final decision was to scrap what we were doing with Angular and now are
looking at several options which include:

1 - going with a traditional .Net stack / MVC

2 - going with Django or other Python framework

3 - moving to another JS framework like Ember

Either way, We're moving away from Angular. Call me gun shy, call me spooked
by the latest change in direction, but I have a bad feeling about how this is
going to turn out in the next 18-24 months.

------
ben336
So there seem to be 2 separate issues this post is addressing.

1\. A lot of JavaScript frameworks are being released 2\. JavaScript
frameworks are being updated too fast.

His biggest example, the Angular 2.0 split, is of the second one, but he seems
primarily concerned with the first one.

I can see the first one being a problem primarily for developers keeping their
skills up to date. The fact is that once you've put a decent amount of code
down into an application, you're not going to be constantly switching
frameworks. Maybe do it once, but otherwise the applications that are already
built will stay on a stable foundation. So for developers working on a single
or stable set of applications (not client work), this shouldn't effect their
actual work. There may be an issue of skill decay if employers are constantly
looking for the latest and greatest, but outside the Silicon valley bubble, I
still see a lot more jQuery and Backbone job postings than Ember or React.

As for the issue of frameworks lacking stability, I frankly don't see that.
Yes Angular is making big breaking changes. But otherwise? Let's look at the
other 6 biggest front end libraries/frameworks.

jQuery has been fairly stable for a few years now, with minimal breaking
changes.

Underscore has been very stable, albeit growing with competition/help from Lo-
Dash

Knockout and Backbone have evolved slowly while remaining small and very small
respectively.

Ember has a very clear process for moving their framework while allowing
actively developed applications to stay up to date in a reasonable way.

React is still pre 1.0 and that's something you should know going in.

Basically if you started a project with any of those technologies (or angular
for that matter) at some point in the past 3 years, you've probably had a
pretty easy time in adjusting as the library specific concepts have changed.

I just don't see the idea of "Frameworks are evolving too quickly" as being
particularly compelling. There's a lot of information out there. Yes if you
want to know it all and always be using the newest shiny thing, it will
probably be too much. But none of this is preventing anyone from actually
building useful things today.

~~~
joesmo
I'd say the Angular 2.0 split actually fits your first point (A lot of
JavaScript frameworks are being released) rather than your second as
essentially, it is a new library that shares only the name. The way I see it,
Google is deprecating Angular 1.0 and creating a new library which will also
be called Angular (2.0) but might as well be called something else. This
bungling is rather typical of Google open source projects and I agree with the
author on being aware of corporate sponsorship. I'd add to that, especially of
Google, whose track record in this space (front end) is abysmal and whose
track record in general as far as developer technologies is mediocre at best.

~~~
marknutter
It shares more than just the name. The Angular rewrite was unavoidable if they
had any hope of integrating seamlessly with web components. They also remove a
lot of the concepts that people lambasted Angular 1.0 for and end up with a
much more elegant framework. It seems they were damned whether or not they
wrote Angular 2.0 - people would either bitch about the current framework for
being convoluted in places or bitch about the new one for having breaking
changes.

~~~
joesmo
I don't see anything else that it meaningfully shares with Angular 1,
certainly nothing that warrants keeping the name the same. What people are
bitching about now is that Angular is essentially deprecated and a dead
project: in other words, Google's spectacular failure at maintaining the
project. That applies to both Angular 1 and 2 now, as it's clear to me and
plenty of other devs that Google is simply not serious in this space (not to
mention that Angular 1 wasn't all that great to begin with when used for
anything but simple apps). I think it'd be foolish to choose Angular 1 or 2 at
this point, knowing that there will be literally no support from the creators.
Other frameworks do this as well, just not on such a short timescale.

~~~
marknutter
> What people are bitching about now is that Angular is essentially deprecated
> and a dead project: in other words, Google's spectacular failure at
> maintaining the project

You keep using the term "Google" as though it represents a single, unified
entity aligned on all fronts. Angular was never an official initiative within
Google and its usage within Google is actually pretty limited. It's a Google
framework in name only. It grew organically out of one small team's (who
happened to work at Google) desire to simplify the rewrite of a very large
legacy web app (DoubleClick). It's no more "Google Angular" than Bootstrap is
"Twitter Bootstrap", which was another project that started within large,
recognizable company but wasn't officially initiated or mandated by said
company. I'm sure Google employees are sick of people lumping them into one
big group and making blanket statements such as the ones you made in your
comment.

> I don't see anything else that it meaningfully shares with Angular 1

Then you haven't been paying attention. Angular 2.0 still has dependency
injection, directives, two-way binding, scopes, routing, and more. Directives
are being renamed to match more common terminology and scopes are now just
implied but these are _improvements_ , not removals.

> I think it'd be foolish to choose Angular 1 or 2 at this point, knowing that
> there will be literally no support from the creators.

This is just FUD. The creators have said they will continue supporting Angular
1.0 well after Angular 2.0 is released; they even hired a few people recently
to do just that. And there are core contributors out there who don't work for
Google who will likely keep supporting Angular 1.0 for as long as it makes
sense to. It's open source, after all. And to say that Angular 2.0 will
receive "literally no support from the creators" is simply trolling.

~~~
joesmo
Whether or not the creators are mainly Google based or not, it doesn't change
the fact that their support is unreliable and untrustworthy. It's not trolling
for me to express my opinion as such. If they're so quick to abandon Angular 1
(about 2 years since the stable release), they're likely to do it again. This
isn't a technology issue, it's a trust issue. All this so they can create a
more "elegant framework" that's likely to be more of the same. Also, just
because the 2.0 release uses general concepts and design patterns that 1.0
also happens to use (DI, routing, two-way binding, etc.) doesn't make it an
upgrade. That's akin to saying they're both Javascript, so they must have
something in common. Ridiculous.

------
michaelmcmillan
Great post! I agree with your argument regarding libraries over frameworks,
but I think the real problem is how we couple our software to third-party
libraries. Frameworks tie you down more than a library, like you said. But if
you're not careful a library can do just the same. Which is why I believe
developers have to be more clever when architecting software.

Reading your post reminded me of Robert C. Martin (Uncle Bob) opinions on how
coupling your code with anything that can screw you over obviously is a bad
idea.

"Apparently the notion that it’s a good idea to hide the framework, UI, or
database from the application code is not universally accepted."

"What happened to us? How did we forget these rules? When did the old rules of
coupling and cohesion evaporate from our awareness? Are we really so naive as
to think that the best way to write a complex system is to throw a bunch of
components into a bag and shake it until it works?"

[http://blog.8thlight.com/uncle-bob/2011/11/22/Clean-
Architec...](http://blog.8thlight.com/uncle-bob/2011/11/22/Clean-
Architecture.html)

~~~
je42
Yep !!!

------
jimmytidey
This discussion is exactly why I'm drawn to Meteor. As someone who turns out
prototypes and doesn't do full time web development, the overhead of
researching all these options every time I try to do something is too much.
The cost is that I might not always be using exactly the right thing, and that
I'm stuck with Meteor's quirks. The pay off is that it always just waiting to
go.

As an aside, I think it's notable what a barrier to entry all this is. If you
want to try your hand at web app development the thicket of libraries is not a
welcoming prospect...

~~~
evo_9
I have to agree, I've played with all the 'big' JS frameworks during the past
2 years and only Meteor has 'stuck' for me. Part of it is that it's just so
fast and easy to crank out something usable with minimal effort; I think this
is largely because Meteor is unencumbered by any MVC requirements. It would
take a lot for me to consider changing to something else at this point, Meteor
is just so fast, easy and most importantly fun to develop apps in.

------
d0m
Yeah, I agree. I lost faith in Angular (Even the 1.x). From now on I'll be
using React for the view and a mix of amazing smaller libraries for the rest.

------
ux-app
"Prefer dedicated libraries to monolithic frameworks", this is the money quote
for me.

I got burned a long time ago when I wrote a large personal project using ExtJS
(~1.2 i think). Breaking changes, coupled with a kitchen sink mentality soured
me against large frameworks.

It's vanilla JS with a few small very targeted libraries to fill in the gaps
from now on for me.

------
mimo84
Where I work we decided to avoid using libraries and frameworks, because
decisions taken at that level was do not give us the flexibility to deal with
the problems that we face. The main issues we found were:

1\. Change of behaviour between versions, (e.g. the way a frameworks integrate
with a page)

2\. Reliance on functionality being supported into the future

3\. Customer expectations

4\. Browser support

That said, it is true that a frameworks gives you the ability to put together
an app in a few weeks. However, when you know that what deal with with
something that needs to be maintained for years than knowing what does each
piece of your code is far more important.

~~~
Bahamut
It's possible to do the same with a framework - it is also likely that
frameworks and various libraries will be more performant and account for
cross-browser issues. For example, I am not going to handcode JS logic with
generating SVG for a graph - I'm going to use d3.

~~~
spyder81
Well, sort of. It's possible if you're willing to take on maintenance of that
library if/when they abandon it, and be able to dive into the guts to track
down bugs or weird behaviour.

As a good example, we're on the verge of ditching JQuery.

~~~
Bahamut
Here's the rub though - code will not (likely) live forever. That's just the
reality of software engineering.

I always have to dive into the guts of a library to figure out bugs regardless
- I feel like that's essential for a software engineer to become well versed
in, regardless of whether the work is in frontend or backend.

The cost of not producing at a fast enough rate is something almost no
business can afford, especially in the startup world. The speed at which
companies have to move are always on full thrust because if they don't move
fast enough, then it costs sales, reputation, and gives competitors more of an
opportunity for market entry.

Homerolling your own framework/library can be a dangerous operation, and you
lose the benefits of the lessons that others have learned in maintaining open
source frameworks/libraries.

~~~
davidgerard
> Here's the rub though - code will not (likely) live forever. That's just the
> reality of software engineering.

Yes. Only the code you wish wouldn't!

(seriously. I'm maintaining complex logic in ant. AUGH MY EYES)

------
noname123
Good zeitgeist. I feel compelled to give my $0.02 as I was quoted in the blog
as someone who "frankly feels completely overwhelmed." However, my criticism
will be more from a programmer's perspective not so much a "web application
developer" perspective.

Re: the chaos/churn in Javascript, forgetting for a minute the buzz-words of
Backbone.js, React.js, Ember.js, Gulp, Angular etc. - they seem all to be a
fight about MVC, traditional vs. single-page app vs. isomorphic.

I fail to see how improvements in these tools actually push us to create novel
projects. While one can nit-pick about React.js rendering performance in its
internal "DOM diff" model or Flux's "data flow architecture" in improving code
readability, but they are just buzzwords to me like words-play in a post-
modern novel or art that arrange concepts in their idiosyncratic way in an
arbitrary aesthetic way; although sometimes the rearrangements can be
beautiful, they are ultimately shrines to themselves and their creators and
subculture.

Subculture because everyone wants something of their own and ignore
interoperability. Although the data model are the same whether you're a
single-page or isomorphic, there is no community standard to define standards
to define your data models a la J2EE annotations or code-generated one's a la
Google Protobuf. Same thing with single app controllers, no standard like
RESTful web service spec that's universal and interoperable like between
.net/Java/Python etc. that can be applied to say, Sail/Backbone/Ember/Angular.

Postmodern because they are always self-referential to the
"Ember.js"/"Node.js" way of doing thing - when they all do the same thing
which is rendering HTML elements on the web browser in 2014, much like Visual
Basic rendering forms on Windows 95 desktop in 1997. Never mind all the touts
about performance, architecture, when the users won't care about the
diminishing return of shaving off some microseconds of your AMD JS module
loading or the beauty of your invisible architecture.

IMHO, instead of a race to the bottom to the most "efficient" and "beautiful"
stack to render HTML, I care more about the _ideas_ that push the web as a
medium, e.g.,

WebGL
([http://www.chromeexperiments.com/webgl/](http://www.chromeexperiments.com/webgl/)),

Web Audio API
([https://chromium.googlecode.com/svn/trunk/samples/audio/samp...](https://chromium.googlecode.com/svn/trunk/samples/audio/samples.html)),

Web Real Time Collaboration
([https://togetherjs.com/](https://togetherjs.com/)
[http://www.webrtc.org/](http://www.webrtc.org/))

~~~
carsongross
An alternative direction to head is back to the future: take the web for what
it is and try to simplify AJAX interaction, rather than relearn all the hard
lessons of client/server programming from the 80's, but in a hobbled browser
sandbox.

This is what I'm trying to accomplish with intercooler.js:
[http://intercoolerjs.org/](http://intercoolerjs.org/)

~~~
mike_hearn
_An alternative direction to head is back to the future: take the web for what
it is and try to simplify AJAX interaction, rather than relearn all the hard
lessons of client /server programming from the 80's, but in a hobbled browser
sandbox._

For an even more retro approach, perhaps some things are just better written
as desktop apps. I know they're out of vogue at the moment, but I've been
having good experiences with writing a JavaFX app lately. Particular points to
note:

* I wrote my own online updates engine, that can be used to implement Chrome/Web style silent background updates, but which can also give control to the user over which version of the app they use. Users can downgrade at any time if a new version is buggy or just not as good as the previous version. It's very small, simple and easily integrated. It supports threshold signed updates so it's also suitable for high security apps where a hacked web server could be critical. It's called UpdateFX, check it out.

* JavaFX has a tool that creates native, bundled installers on each platform (dmg, exe/msi and deb). The user does not have to install JVMs or get any Ask Toolbar crap on their system. You remain in total control over JRE upgrades.

* UI is specified with an XML dialect called FXML, it's quite intuitive and anyone who knows HTML can pick it up quickly. But there's also (unlike with the web) a competent visual designer. You can style UI with a dialect of CSS and it's very easy to match the Twitter bootstrap look, native looks can be done too.

* Data binding is easy, the UI is OpenGL/Direct3D hardware accelerated, you can trivially apply effects like drop shadows or blurs and animate them, the API is clean, the entire framework is open source and the developers are responsive.

* Because it's not a web app, support for offline or flaky internet connections is second nature.

If your users can tolerate the initial download then it's a much more pleasant
and robust development experience. If your users are the type who can't wait,
you might want to stick with the web.

~~~
munificent
> For an even more retro approach, perhaps some things are just better written
> as desktop apps.

This is effectively what the mobile marketplace has decided. Native mobile
apps are thriving while mobile web apps struggle to keep up.

~~~
jbergens
I'm not sure that is true, a lot of apps use web technologies on the inside.
The more interesting part is that most seem to choose native not because of
the development story but because they need to reach some special API or
really want to keep the UI very close to examples from the platform
manufacturer. It is actually a problem to go native when you have to develop
multiple versions of each application which might totally lose any advantages
the native coding experience has over html+js.

------
empthought
Can someone more invested in the SPA/rich internet application JavaScript
state-of-the-art explain to me what is unappealing with the Dojo toolkit[1]?
Of all the frameworks I've seen, it's appeared to have the most consistent and
sustained developing, documenting, and extending efforts, over the past six
years or so.

But I'd rather be programming iOS any day, so maybe my tastes in client-side
application programming are very out-of-step.

[1]: [http://dojotoolkit.org](http://dojotoolkit.org)

------
oakaz
If you close your ears to people who try to spread the words of unix
philosophy, this is where you find yourself at.

For past 4 years, there is NPM, and there is people trying to explain why you
should build your software with modules instead of frameworks.

~~~
mhd
That was the vision of OOP, too ("Software ICs") and we all know how well that
turned out. Even Unix is not really the big success story here -- one might
say that even something like 'awk' is already stretching the paradigm, never
mind common fellow travelers like Perl or Emacs. Never mind most graphical
interfaces.

I know, this will probably evoke a "No true Unixman" response, maybe even with
pointers towards the Plan 9 highlands, but the truth is that a) connecting
stuff is hard and b) a good connection is often a prime feature itself.

Especially the latter will result into a plethora of modules of its own, for
nearly all possible combinations of component modules. The end result is even
more "frameworks". Sure, they're going to be _modular_ frameworks, but I don't
really know whether that's going to help the developers who live in the
uncanny valley of _mostly_ knowing what's there and how it connects.

A "fat kernel" with lots of "satellite modules" might be a viable approach,
too. Just like with most programming languages (i.e. not C or JavaScript),
where you've got plenty of useful stuff in your standard library, and some
package manager for the rest.

But hey, if the JavaScript ninjas finally figure out how to properly combine
software components, that would be better for all of us. I just wouldn't bet
on that.

------
ebiester
I posted it elsewhere, but I remember it said from my days watching the
proliferation of java frameworks: If you aren't using a framework, you're
building a framework.

When I spent some time in the node.js world, I felt the same thing: there were
a few attempts at frameworks, but most everybody was writing their own glue
framework between microlibraries. I am convinced that it is only fun the first
few times you have to do it. :) It reminds me a little of the days before
server side frameworks, where people were reinventing the wheel (poorly) every
project.

Further, I don't think it's necessary to run and learn every single framework
that comes out. If something is an order of magnitude better, it will take
over the market. (Ember, Angular, and React are all an order of magnitude
better than backbone.) There will come something that is an order of magnitude
better than these eventually. Until then, just get stuff done.

And frankly, there's no shame in continuing to render on the server until that
next generation leap comes.

------
prottmann
To be fair: many things were developed in the last 4 years since google pushed
V8.

Thats why so many things changed too.

And the other thing is: why are all those things so successfully? People had
enough from old fat frameworks, that where developed 10 years ago with a
language from 15 or 20 years ago.

This old languages and frameworks did not fit to Web-Development, Apps,
whatever... all the things that boomed since 2007.

------
al2o3cr
"Developers will move, I believe, from monolithic frameworks like Angular.js
and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk
of churn"

Well, that _would_ reduce the framework churn rate for an individual developer
to exactly the rate that said developer gets new projects. Too bad about the
NEXT dev on the project, tho...

------
cozuya
Relying on reddit for all of your "temperature gauges" of the JS community
probably isn't for the best.

~~~
state
I would tend to agree, but what would you recommend instead?

~~~
cozuya
Good question. I guess here, and Twitter? ugh. There's nothing "centralized"
for cutting edge javascript development (hopefully not an oxymoron..), so I
consume a few different places daily. I don't feel like I'm missing out on
things that's for sure.

------
yeskia
How is this churn any different to other languages at the height of the
popularity? Every other web programming language seems to have it's defining
framework (whether it be a collection of quality packages or entirely first
party code). From Rails to Django to Symfony to MVC, plus not forgetting that
each language also has a popular "slim" framework also.

I see no reason why that would differ in the JavaScript world - whether it be
front-end or back-end. Angular's changes may have burned a lot of developers
but it could just be teething problems - learnt some critical lessons on the
first round and resolving them before it's too late. I fully expect to see a
solid MVC framework on the backend, whether it's Sails.js or something else
that comes along.

~~~
mattxxx
idk; I've been focusing on all things javascript for the past two years, and I
can relate to the "alienation" the author is describing. I mostly write
vanilla (or +underscore) and AngularJS, and it feels like you have to
constantly compare things, because so many of the workflows don't feel right.

AngularJS scales really well on gigantic applications, and it felt like there
was going to be some stability from the corporate-world, but now it's gone.

Frontend code is so hard to maintain well (compared to backend), and now it's
going to cost companies millions of dollars to migrate: retraining, migration,
unit-testing, QA

sigh...

~~~
Bahamut
The stability will still be there - the first evidence of breaking changes was
at ng-conf back in January, when Vojta presented about di.js. In addition,
Angular 2.0 won't come out for over a year (I'd bet on 1.5 years from now
given the tendency for timelines to slip - 1.3 was originally supposed to come
out a year ago), and Angular 1.x will be supported for 1.5 years after that.
That's at least 3 years of active development in 1.x. Meanwhile, the
development ecosystem will probably have finally adopted Web Components and
ES6 as the norm for development, and so it would give the perfect opportunity
to evaluate options to migrate to then.

Web Components looks hugely promising as the path for independent components -
essentially what Angular directives were meant to be in the absence of such
browser technology.

------
briantakita
People who paid attention to Rails upgrade issues over the years saw issues
with heavy frameworks that abstract a bit far from the input & output.

Simple libraries often mean less maintenance headaches, more flexibility, and
better productivity over the long term. YMMV of course ;-)

Exoskeleton looks like a promising microframework replacement for Backbone.js
- [http://exosjs.com/](http://exosjs.com/)

\---

Edit: re: downvotes. I know, sometimes it hurts to hear there are other ways
that may be more optimal. Been there. Developing software is hard sometimes
but it's a craft :-)

~~~
bbcbasic
Why is maintaining a Rails application a mess? Yes if everything gets stuffed
into controllers/models then maybe. But you don't have to do that.

~~~
briantakita
The upgrades have been historically been quite painful. Especially from v2 to
v3.

Perhaps it's better now that the api has stabilized a bit. I've been using
node.js & some Sinatra lately.

Upgrades tend to be smoother & due to less monolithic libraries. Also, the app
startup time & TDD cycle tends to be faster with slimmer libraries.

It's also nice to be close to http vs the ambiguous controller methods &
complicated route files.

Plus ActiveRecord is slow, especially with collections. The business logic can
often be implemented in simple functions, resulting is less abstraction
overhead.

~~~
bronson
True, v2->v3 was hard due to escaping-by-default, but that was a long time
ago. v3 to v4 was trivial and v4 to v5 looks to be similarly easy.

Also, I find business logic sql libs written by typical devs tend to be
unreadable and much buggier than AR code. They start clean, but once some
other devs make some edits, they end up a jumble of sql concatenation
nightmares (even if you use prepared statements, and especially if you've ever
switched sql dialects). Given the choice, I think I'd rather see them written
as stored procedures. At least that enforces decoupling.

I agree with your other points -- less code is more better.

------
err4nt
Well said Breck! As a front-end dev it feels like a hurricane of new libraries
and frameworks all the time.

Two years ago I decided that the best course of action would be for me to
really dig into HTML and CSS, and ive been learning vanilla JavaScript as
well, and that combination has worked and will continue to work. Im leery of
anything I _couldnt_ write myself, but if I can take an existing library and
expand on it and make it my own that saves me time and I know I wont have to
worry about compatibility changes down the road.

------
funkiee
I think the Front-End community just happens to collaborate a lot more than
other communities and so the ideas get shared at a faster pace. Yes, it leads
to framework churn, but it's mostly because we're learning from each other's
ideas. If the other side of the coin is stagnation where people learn the
dogma of a framework and not the reason behind it, I'm all for framework
churn.

Find something that works for your team and stick with it. No one is making
you use the latest framework or library out there.

------
dustingetz
open source has won, we are innovating at faster and faster speeds than ever
before, and the best innovations eventually bubble up to the top, bad ideas
get peer reviewed out and thrown away before the whole world depends on them,
this is amazing!

I for one am perfectly able to track all this innovation within my specialties
(enterprise web dev) across multiple language ecosystems, and if I miss
something, someone in my monkeysphere will make me aware of it, all of this
fuss sounds like hot air to me.

~~~
Avalaxy
Maybe because you're primarily a front-end developer? If front-end is not your
fulltime job it's really hard to keep up with all the new frameworks and
changes.

~~~
w4tson
Agreed. I'm an enterprise dev who tries to keep a finger on the pulse but it
can be quite difficult. I take my eye off the ball for 6 months and it turns
out grunt is no good?! etc etc.

------
RyanZAG
Not sure why he brings up GWT so much - GWT seems to be very healthy right
now. I'd probably choose to use GWT in a new project before I'd choose Angular
at this point..

------
hardwaresofton
Iteration produces churn (I don't think anyone would argue for not arriving at
the best solution in an iterative manner in this day and age), and almost
everything on the front end is iterating.

I say keep calm and watch it churn.

When it stops churning, whatever comes out is going to be worth it

------
tk42
The state of JavaScript in 2015: it still sucks. I just wish the webbrowser
creators would implement a way of other languages to be executed as a
replacement of JavaScript. Not gonna happen, I know...

~~~
pestaa
In my mind it's in the same spot as PHP: the language can hardly be worse, but
so much quality code is written in both, you're beginning to accept them.

Lucky if you can work with a disciplined team...

~~~
juliangregorian
JavaScript, while it was rushed and had questionable design goals, at least
was somewhat designed. You can't say that about PHP.

Also not sure I can get on board with "lots of quality code in PHP", some
sure, but seems that anyone who knows PHP and another language prefers to
write in another language.

~~~
pestaa
The early PHP releases indeed weren't thought through fully, but recent
versions are taken quite good care of.

The are emergent (PSR) standards nicely backed by all the leaders in the
community (Symfony, Laravel, Silex, Drupal 8.) The Doctrine ORM is also an
extremely pleasant way to interact with a relational DB (on par with Python's
SQLAlchemy.) I very deeply hated PHP but nowadays I find it fun to develop and
ship software written in PHP.

As for JavaScript, 1 week is nowhere near enough what I'd call "designing a
language." It has quite the same evolutionary history as PHP, except for being
rediscovered a year or two ago.

~~~
juliangregorian
No dude. Sorry, your opinion is wrong. If recent versions were indeed "taken
quite good care of", there wouldn't be >5000 functions all existing in the
global scope, with completely inconsistent naming and arity patterns. There
wouldn't be exactly one non-scalar data type, the so-called "associative
array" monstrosity. I could go on. I don't think you'd care.

It's also funny that you listed 4 actors as "all the leaders" when Laravel
uses mostly Symfony code, Silex is made by Symfony, and Drupal is known to be
terrible.

The last time I had to program something real in PHP, I got caught trying to
debug network calls (all PHP debugging is an exercise in futility, you just
never know, am I going to throw an error, return 0, return -1/false/something
else, is it something that gets swallowed by the interpreter?) and tried to
use a try/catch to catch all exceptions. So pretty much "catch (Exception
$e)". Except that, since I was trying to be good and use PSR, I was using
namespaces, and PHP does not search the root namespace unless you are in the
root namespace. Which is ridiculous and the only language I know to do that.
The really infuriating part however was that the interpreter gave no
indication whatsoever that something was wrong, it just silently failed.
Making it ironic that by dint of using an error construct, I was prevented
from seeing compile errors in my code.

Congratulations on knowing that JavaScript was written in a week, however if
you had actually dug deeper, you would have known that the creator was a bit
of a language nerd and was concepting something different but was forced to
shoehorn it into a more Java-esque paradigm at the eleventh hour. When I use
JavaScript, I don't have to RTFM to find out what order str_replace takes its
arguments in for the 3000th time (and don't give me the string functions/array
functions bit because it isn't actually true). Nope, I can just
"string".replace(find, replace) because the language was designed. Whereas PHP
to this day seems to be a slipshod cadre of hackers (and not in the elite FBI
break-in sense, but in the duct tape and baling twine sense) blithely adding
whatever feature scratches their particular itch with no care or concern for
the rest of the ecosystem.

I don't think JavaScript is a great language. But it is an understandable
language, a predictable language. When I have to use PHP it makes me want to
quit my job. When I have to use PHP it makes me want to quit being a software
developer.

------
vkjv
I completely agree with the modular, single purpose library approach, but, for
large teams, it adds a lot of hidden overhead: library curation.

It's so easy to just, `npm install` or `bower install` a new library,
sometimes you don't even think about it. But, this causes a huge bloat and
duplicated functionality that both produce huge build artifacts and increase
the learning curve.

You need to make sure you have at least one person dedicated to saying, "I
know B does X better, but, we are already using A and it does X good enough."

~~~
je42
In my experience you will get into this problem also in any other language. I
had this particular problem with C#/Unity, C++/Windows and Python/Linux.

------
cayblood
I'm surprised there was no mention of Google Polymer in this article (and very
little in the comments). As I understand it, one of the big reasons why
Angular wasn't backwards compatible is that they wanted to remove directives
and opt for a more web-components-compatible approach. Having worked with
Polymer during the past few months, I'm very impressed with its modularity and
the simplicity one can achieve because of how each component's features are
well-encapsulated.

------
thomasfoster96
I still have issues with people loading jQuery just to get an element using an
id. I'm glad I haven't dived into the world of Angular and other frameworks.

~~~
simonrobb
If you misuse jQuery, it doesn't reflect badly on jQuery as a technology, it
reflects upon the developer. jQuery is an outstanding library.

If you stay away from technologies because there are developers out there
misusing it, I doubt you'll be left with much but machine code.

~~~
thomasfoster96
Well, yes, that's correct. jQuery is outstanding, but 95% of the time you
don't need to use it.

------
sauere
I got to agree with the Reddit posts quoted in the blog post.

But it's not just JavaScript, it's Frontend and WebDev in general. The whole
landscape is too big and moving too fast for anyone to move along and most
importantly: it is very, very frustrating. Go to angel.co and just look at
three or four job openings and you will end up with 50 different Frameworks,
Libs and Stacks. Half of them might be dead or deprecated in 12 months. It is
insane.

~~~
davidgerard
I'm a sysadmin supporting this shit for bespoke web applications. A new piece
of semi-supported crap every six months and the business expects it to be
supportable for two or three years. (We're getting better about demanding they
fund a damn sprint for any nontrivial work.)

Our devs are a very smart and capable bunch, but are slowly learning the
Support Hangover of being the knowledgeable one on a project because you made
a foolish and enthusiastic choice when the project was launched ... it's how
you learn the "-ops" bit of devops.

Some year webdev will grow out of the CADT model, but it won't be this year.

------
bwindels
Funny how a lot of the comments here, on an article about framework fatigue,
talk about frameworks that don't have problem x :)

My preferred way of working in a lot of projects is to work with the DOM
directly but keep the code that is DOM-aware as minimal as possible, and call
my domain layer right from the event handler after extracting the needed info
(id, ...) from the event and target. IMHO, data-binding is not that useful in
most projects.

------
mattxxx
Frontend JS is so hard to tame, and it feels like everyone has such varied and
strong opinions on it. I'm with the author on continual shake-ups in frontend
dev, but maybe with better support for DOM stuff, and framework agnostic
dependency stuff, we might have gotten somewhere just as some of the rug got
pulled out.

Sigh... with AngularJS 2, I'm shuddering at all the unit tests that will have
to be rewritten.

------
ryanmk
I'm glad I read this article. I just started experimenting with javascript for
web development, and I've encountered so many Named Swords.

------
louischatriot
The last point about small libraries versus monolithic framworks really
resonnates with me. I always have a hard time understanding why my team should
commit to one specific way of doing almost everything, instead of picking the
best tool for every job. In my experience, framework code is of a very varying
quality, some is good, some is not, some doesn't suit what I want to do.

------
Lamba
I stick to using well established libraries/frameworks, eg jQuery. Unless you
have a large and complicated model, an MV* framework can be overkill and add
unecessary complexity in addition to possibly tying you down to something that
becomes a laughing stock in six months. The new and well received SPA book by
Mike Mikowski and Josh Powell takes a similar stance.

------
btbuildem
Seems relatively accurate to me. I understand the lean towards tiny fragments,
there is less upfront investment / easier learning curve; this reduces risk.
Perhaps with time we will see intermediaries emerge between light libraries
and heavy frameworks - eg combinations of the former into subsets of the
latter, suited for less general development.

------
bahmutov
Are we really now complaining that the fast pace of new tools is a problem?
Not to put everything in black and white, but would the author prefer new
releases every 5 years? Just apply same principles to picking new tools like
you would when buying a car: do you really need it? Can you afford it? Does
the new model have something the old one does not?

------
tempVariable
This and the related reddit post put some more libraries on my radar and the
cycle continues. That is probably the most useful thing for me out of this
debate.

I have not dipped my toes into a production app with ember or angular because
of the same list of concerns put forward by folks here and on the other-webs.

------
ddw
Does it really take that long to learn Angular? Will it really take long to
upgrade to 2.0 and will you have to do it immediately?

The web has always changed quickly because that is the only way it can
survive. If you think you can write an app and let it sit there for years
you're silly.

Technology: there is no end game.

------
gfodor
My team was trying to decide what Javascript libraries to use to build our web
tier for our project. After spending a few days trying to get our heads around
the ecosystem, we just gave up and went running back to Rails. Couldn't be
happier.

~~~
pluma
What does Rails have to do with front-end SPA frameworks?

Or are you talking about node?

~~~
gfodor
Yeah we were looking into node for the server.

------
cturhan
Great article and I agree on most of the parts.

But, don't put tldr; on bottom of the article.

------
BuckRogers
I feel sorry for those stuck in web development. Native apps always were and
still are the way to go. Appstore/Play and soon Windows 10's inevitable
blastoff to mass popularity will bring a popular appstore to all 3 major
platforms.

As the article states, there was a time a few years ago that js-all-the-things
appeared interesting and unstoppable. To me it appears in 1 year when Win10
arrives, people will have better spent their time honing skills for native
apps.

Webapps as people envision them (universal applications) will die- returning
to their original intention. Document sharing and simple data
collection/retrieval.

Blame Eich and Mozilla for that. They insisted on pushing no bytecode for the
web. Wanting us to rely on Eich's JS + rest of the webstack monstrosity
requiring ugly hacks.

~~~
mappu
I don't see (comparatively) a lot of people targeting the Windows 8 app store
that's been available for 2 years already. Most Windows deployment is either
ad-hoc exe's or centrally administered msi's. What's changing with Windows 10?

~~~
BuckRogers
Win10 and it's (likely) XP/7 popularity level is a dark horse for native apps,
and looming blow for the webapp movement. Which I believe has gotten a _very_
long free-pass thanks to the most popular platform not having a cohesive
appstore ready (on a popular OS).

Win8 IMO is almost irrelevant, the marketshare isn't there to add a MS Store
option for me or many others. The corporations haven't and won't hop on.
Everyone is (IMO rightly) focused on iOS/Android/web at the moment. Agreed on
MSIs, but I'd add the customizable corporate frontend stores should be more
powerful and slick than the current method (same appstore for MS desktop and
mobile). It's possible once enterprise moves to the MS Store that MS mobile
devices make major inroads. For consumers, I think they'll rejoice at Win10,
upgrade to it and by default go to the MS Store for security reasons alone.
Not to mention auto-updates, same apps as on MS mobile etc.

I'm not pro-MS, I'm actually anti-all-for-profits and a Mozilla fanboy. I just
disagree with Eich on a bytecode for the web, he blew it as far as the web
being the prime delivery mechanism for apps is concerned. The webstack sucks,
it had to go. Too late now.

I understand my view isn't popular at the moment. Especially among webdevs who
are most likely to be reading this HN post. Those people have invested heavily
in the webapp dream with their time, skills and careers. Anything to the
contrary that it was a great idea is going to get downvoted. Regardless, I
think this is an accurate reading of the foreseeable future.

~~~
modarts
>Regardless, I think this is an accurate reading of the foreseeable future

It's not accurate at all though.

~~~
BuckRogers
Good thing we'll see if my prediction, or your non-contribution turns up
correct in the next 2 years then.

~~~
oldmanjay
Your prediction relies on a windows app store somehow making the web
irrelevant which is amazingly unlikely and counter to every trend of the last
20 years. I suspect you have some emotional investment in the Microsoft
ecosystem that is coloring your perspective.

My prediction is that your prediction is dead wrong. Nothing will stop the
web, certainly not your app store dystopia, and certainly not the way
Microsoft would run it.

~~~
BuckRogers
I never spoke in absolutes, as you are. I said it was a blow to the webapp
movement. Webapp movement defined here as a universal application deployment.

Presuming about my intentions or feelings towards the MS ecosystem is
ridiculous. I had courses on VB6 in the late 90s, that's the closest and most
exposure I've ever had to their ecosystem. I do wish I knew C# now that .Net
is merging with Mono though. I see no shame in that. I don't hate MS anymore
than I do Google, Apple, Oracle or ANY for-profit. For-profit means not-in-my-
best-interests.

"Nothing will stop the web" sounds way too much like the idiotic quote,
"always bet on JS". I'm not betting on JS with Eich, but I'm not against the
web. Certainly my HN post of what I think will happen, won't affect that
outcome.

I'm with (I believe) most everyone in supporting webapps being the universal
delivery mechanism for apps in the future. Where did I say I wasn't? I also
think there was a limited window of opportunity for this to take off. That
window roughly being 2004-2014. Today, native apps are still on top.

Webapps will continue on in some form. But with Apple and Google already
having appstores, will a popular version of Windows with an appstore be the
closing of that door? That door being defined as webapps becoming the
_dominant application delivery platform_. Yes, I think so.

But as of today, I fully believe webapps were/are hobbled during their glory
years by the webstack, the web needed a bytecode.

If someone merely looking at circumstances and speaking on them bothers you so
much, you are likely someone who speaks only to persuade others to your
viewpoint. I'm not trying to persuade you and don't care where you stand.
Frankly, I'm more than likely aligned with your views on webapps. I just
personally find the webstack inconducive with the goal.

Action needed to be taken at a high level (likely at Mozilla, to make the
webstack legacy and introduce a new bytecode standard), in a window of
opportunity while the last major player (MS) was essentially out of the
appstore business. I don't see it happening in time now. We'll see, but I
predict it is _you_ who has an emotional investment in the webstack.

------
wyclif
The State of JavaScript in 2015, Vine edition:

[https://twitter.com/jennschiffer/status/539274049273479170](https://twitter.com/jennschiffer/status/539274049273479170)

------
CmonDev
This is why nobody mainstream wants to work with web front-end. Would you be a
JavaScript MVC expert or a Java server-side expert? Think about the rate of
knowledge aging.

------
jfmercer
An altogether excellent article. You have impressed clearly and eloquently the
exact same sentiments as I have about instability of the Javascript landscape.

------
calebm
I've often found Libraries > Frameworks.

------
WhyYes
Stop doing your coding in a framework. I know coding something big in JS is
not ideal and thats why Google made Dart.

------
strickjb9
I disagree with this post. Churn is the byproduct of evolution. Libraries will
slowly die and fade away but we learn with each misstep. Sure, there is a lot
of redundancy in the work but each different library/framework/plugin/shim is
a mutation. The good ones pass down traits to future libraries.

Survival of the fittest. Churn is just necessary. The front end world is a
huge ecosystem which is constantly evolving.

------
hammadfauz
To me, it is not at all alarming. But it might be due to my inexperience in
dealing with truly huge code bases.

No matter what framework, in the end it's all JavaScript. So even if I develop
a flashy app using a nice fat framework, it is still going to run unless
JavaScript itself is changed.

That said, I can build an app in Angular today, and when something flashier
comes out, I can code new features/modules to my app using that.

~~~
AYBABTME
I think the main problem is about fixes. Invariably, something is going to go
wrong in the future with whatever framework you use. Either security related
or else. Then your version of {{framework}} won't be supported anymore and
you'll have to:

    
    
       - fix it yourself
       - give up: turn off your app
       - ignore: let people deal with the issue/be vulnerable
    

If your version of {{framework}} is supported, likely all you'll have to do is
wait for a patch.

------
montecruiseto
if we're worried about this miniature explosion...just consider the supernova
that's coming when the internet of things hits the scene. Then, we will all
look back on how peaceful things were in 2014.

------
tomcam
Oh yeah, another thing happened this year. The hivemind turned its back on the
creator of JavaScript because he had a private, principled difference of
opinion that was never in the slightest reflected in his public role.

