

The Battle of Modern Javascript Frameworks - LVB
http://www.softfinity.com/blog/the-battle-of-modern-javascript-frameworks-part-i/

======
substack
I hope that nothing will "win" because "front-end" programming is such a
nebulous concept that it's much better for each project to find a niche and
cater to an increasingly narrower set of trade-offs and use-cases. The idea
that we need such a thing as a "framework" is I think mistaken but
understandably so: we've only had viable module systems and package management
for a short amount of time and they are still evolving.

But module systems and package managers change _everything_ about how open
source ecosystems work! When you've got a package manager that is trivially
easy to publish to, you remove pressure on libraries upstream to include extra
functionality into their cores because users have too hard of a time fetching
the functionality for themselves otherwise. With pervasive package management
and a culture modularity, modules can be smaller because they can depend on
other modules instead of inlining functionality or otherwise being overly
cautious about dependencies. Convergence under this kind of fitness landscape
tends toward narrowly-focused single-purpose libraries that do just one thing
and do it well.

Popular frameworks have already severely dwindled in size from something
extjs, mootools, or yui scale towards something backbone-sized. I sincerely
hope that frameworks dwindle away into nothingness so that focused, reusable
libraries that take simple inputs and produce simple outputs can fill the gap
because the severe orthogonality and opportunities for novel recombination are
so much greater!

~~~
Joeri
I disagree that they've gotten smaller.

Ember is 47 kb, they say, but you need jquery + handlebars + ember + ember
data in practice, for a total of 370 kb minified but not gzipped, which is
huge. Or look at backbone, which requires underscore, zepto and json2 (if you
care about ie7) for a total of 60 kb, and to really use it at scale you need
marionette which bumps the total to 80 kb. Angular clocks in at 80 kb (with
json2). None of these frameworks support splitting te payload, so you pay this
loading cost at the worst time possible: on the first pageload.

Now. Let's look at the legacy frameworks you mention. Mootools is 100 kb
total, which puts it on equal ground with backbone+marionette and angular. Yui
core bootstraps in 30 kb and loads in the rest on-demand so you don't feel it
as a user. Even the biggest most bloated framework of all, extjs, can
bootstrap a first page in 500 kb ungzipped, which is not that much more than
ember.

Your page load performance will not be better with the new frameworks than the
old. In fact, if you're not careful and load too many 'focused' libraries your
initial page load will be worse. What is the value of orthogonality and focus
if it does not improve the developer experience or user experience? Bah
humbug, get off my lawn ;)

~~~
gingerlime
I honestly don't understand the obsession with js package sizes. Of course,
the initial page load is important, you want to minify, gzip and make this as
fast as possible. But once it is loaded (and cached), that's all there is to
it. It's a one-off cost, which I think is perfectly acceptable for most users
using a single-page app.

I personally think ease of development, flexibility, documentation and project
long-term viability are far greater concerns when choosing a framework, than
whether it weights 100kb less (or more).

~~~
alipang
Agreed, this seems like some kind of strange competition/point of pride
between javascript libraries. The smallest slightest advantage in the quality
of your application instantly offsets whatever extra time you spent on loading
100k extra javascript.

The only advantage I see is in moving away the ember style. It's ridiculous
how frameworks get a free pass from violating single-resposibility by claiming
to be "opinionated".

------
tracker1
I think there will be some natural gravity wells that form around JS
frameworks/toolkits. We have the incumbents jQueryUI, extjs, etc... along with
the upstarts: AngularJS, Knockout, Backbone, even Bootstrap, etc. Each offer
specific advantages over others.

Another consideration, which imho is even bigger than toolkits and frameworks
will be packaging and distribution... Bower, and even npm are pretty
popular... you have CommonJS vs. AMD vs ES6 Modules ... It's an interesting
time, with a lot of options, and no clear leaders (other than those with large
corporations behind them).

I'm starting to see the likes of Bootstrap and jQueryUI as pretty
heavy/bulky.. and re-thinking how/what I really need and want. I have a pretty
big addiction to jQuery's features, and not sure if I want to start doing
custom builds with fewer features for newer/mobile browsers, and 1.9.x for
ieold.

The uptake of mobile browsers (my last job saw mobile expand from 0 to 20% of
its' users in the past two years, which is huge), the amount of data used is a
big deal, and monolithic toolsets are a burden there.

\-----

And for the love of god to anyone reading this... stop specifying "Helvetica"
or "Arial" in your stylesheets and just use the "sans-serif" fallback, which
is the most similar/appropriate font for the platform 99.999% of the time.

------
gbog
Looks like very biaised towards knockout to me.

~~~
tracker1
Yeah.. the couple projects I've done with Knockout seemed to be very easy to
get your JS and html muddled, and even harder to make modular. It was probably
the easiest to get started with, but more complex tasks were really
complicated. It really seems to be patterned after XAML in a lot of ways. I do
like it's observable models though... not sure if the 2-way binding is worth
the level of overhead it introduces though.

Backbone is interesting, and I have yet to use it all in a project, I've used
bits and pieces in a couple things so can't comment. It does seem to be the
most flexible from those I've talked to about it.

AngularJS just seems like a big undertaking, and not sure I'm willing to do it
unless I have to.

I think a more interesting compare/contrast would be with regards to project
packaging, how to handle modules and even building processes. I know
RequireJS/AMD has a big lead here, but is it really worth it over say
Browserify, or other patterns. Also as build tools go, is Grunt the best and
what other options are there?

I'd love to see how others structure their projects... I tend to have a
/client/(less|images|scripts|fonts) set of directories as a source then
optimize/merge/push into /pub/(img|js|css|font) directories. I know that Ruby
and Python have mature frameworks, but it looks like NodeJS is growing and
taking over a lot of these roles, separately from even other server-side
frameworks.

My last 3 .Net projects have used Grunt for building client-side tools. I
haven't settled on a popular module framework (yet) though... I generally just
include the tools I want, and namespace my own code out, which comes out
lighter, but less reusable/modular than newer approaches.

~~~
pico303
Let me recommend Yeoman plus Angular. Yeoman is that extra step above and
beyond basic Grunt. Integrates Bower so your common components stay separate,
then builds out your stylesheets and JS like they should be for deployment.
It's a nice way to develop client-side apps.

Then give Angular a shot. I'm not a JavaScript superstar, but it was pretty
easy to pick up Angular and run with it. I love how they've organized
directives and services. Really lends itself to building reusable components
for your apps. Just wish the docs, particularly around testing, were a bit
better.

------
kmasters
Javascript, is a legacy technology, with browser folks pushing the envelope
into backend and front end solutions.

It should be clear to anybody working with whatever.js that this is not
technology that is here to stay.

This is still a browser patch. And everything underneath anything.js is a
patch or a port or a hook, or a kludge.

There is no memory management, no threading, no accurate concept of
parallelism and no support for anything but what the browser makers want to
support.

Javascript is not a real language. It encompasses no real technology. And it
will be replaced.

Javascript is the new applet.

~~~
Kiro
Replaced with what? I think you're wrong.

~~~
gingerlime
I think zed shaw's talk/rant pretty much says the same thing, perhaps with
some more details and insights (as well as more F words)

<http://vimeo.com/43380467>

I think the gist of it is some kind of an ecosystem with browsers running a
form of a Virtual Machine runtime, so people can write different languages
that compile to the VM bytecode.

