
State of the Art JavaScript in 2016 - achairapart
https://medium.com/javascript-and-opinions/state-of-the-art-javascript-in-2016-ab67fc68eb0b#.37u0xx9xi
======
fleshweasel
I strongly disagree about TypeScript-- I think it's a huge boon to
productivity. TypeScript has has union types i.e. "number | string" which are
similar to algebraic data types. TypeScript also has optional interface
members and function parameters by putting ? at the end of the name, i.e.
"foo?: number".

Static types allow for much, much better tooling, particularly autocomplete
and the ability to check whether your code is valid on some basic levels. I
consider avoiding it to be a big waste of time. I've had a good experience
getting the definitions files going for the libraries I use.

I also disagree with the statement that TypeScript is making JavaScript "like
C# or Java". TypeScript lets you opt out of type checking all you want with
minimal difficulty. It also will by default always emit JavaScript even if it
detects type errors.

~~~
lomnakkus
> TypeScript has has union types i.e. "number | string" which are similar to
> algebraic data types.

I understand that you said "similar", but there's actually a _big_ difference
that should be mentioned explicitly, namely that algebraic data type (ADT)
sums always have "constructors" which you can use to disambiguate with. That
means that you can meaningfully do the equivalent of "int | int" whereas for
union types that would just be "int". (I'm sure you already know this, I'm
just pointing this out for those who may not know or appreciate the
subtleties.) Example:

    
    
        data Maybe a = Nothing | Just a
    

In this example the "constructors" are Nothing and Just.

Of course, you _can_ emulate first-order ADT sums using union types by just
introducing artifical container classes and doing a union on those. While this
works for simple cases, I believe (but cannot prove) that it's impossible to
emulate GADTs using union types -- my intuition is that the presence of
constructors to match on is an essential part of being able to "narrow" the
types sufficiently to actually act upon what they "contain" (for each case).

 _However_ , and notwithstanding all of that... the use of union types in
TypeScript is absolutely _the_ best way to align with JavaScript since there's
so much JS that just takes/returns values of type "whatever" (string | number
| ...).

Btw, also agreed on the productivity boost. In the short term, it may not
appear that you're getting faster, but once your application starts to grow
beyond "trivial" you really start to notice the fact that you can refactor
without fear.

~~~
spicyj
Flow has pretty good support for tagged unions like this which act like ADTs:

[http://flowtype.org/blog/2015/07/03/Disjoint-
Unions.html](http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html)

~~~
fleshweasel
This is great. Seems less cumbersome than TypeScript's user defined type
guards for distinguishing cases of a union. The sentinel value concept is
something you could at least steal when creating user defined type guards to
make them simpler, at least.

~~~
wereHamster
TypeScript union types and Flow tagged unions are nice to have, but to make
them really useful you also have to provide a good way to pattern match on
them. And there they both are still way behind Haskell.

------
andybak
Disappointing that after months of moaning about the paralysis of choice, few
of the comments are positive about a genuine and fairly defensible attempt to
cut through that.

He proposes a fairly simple stack (and for the sake of argument he assumes
you're needs are beyond the 'static html and a touch of jQuery' stage). He
spends time explaining them and makes a fairly good attempt to avoid the
overly-new or overly-complex.

We've had all the obvious reactions:

1\. This isn't my stack of choice

2\. React is flawed

3\. Don't use frameworks at all

4\. I hate dynamic typing

5\. Javascript is broken beyond repair

6\. It will have changed by next week

All of these are valid discussions to have but they get wheeled out every time
and - maybe with the exception of point 1 - they are only indirectly related
to the topic of this post.

So every js discussion becomes a meta-discussion. Same thing with Google posts
('oh they'll close that down next week'), ORMs ('they suck'), Python ('Python
3 was a mistake') etc.

HN comments needs an on-topic vs off-topic filter. Or a "yes we already know
that" filter...

(The irony of the above statements when this is also a meta-post is duly
noted)

My own feeling is that everyone should avoid jumping on complex frameworks
until they are really needed. jQuery, Pjax or intercooler.js can take you a
long way and save a lot of headaches. But when you do need a proper MVC-like
framework then this article is a valuable guide of the sort that people have
been asking for for months.

~~~
oneeyedpigeon
"HN comments needs an on-topic vs off-topic filter. Or a "yes we already know
that" filter..."

They already do; if something doesn't positively contribute to the discussion,
downvote it.

~~~
andybak
I wasn't entirely serious about the filters but that's a fair point.

I suppose what I'm actually saying is "Can we all downvote the more worn-out
type of comments a bit more actively?".

Which now I'm come out and said it sounds overly optimistic. ;-)

~~~
gotchange
Yes we can and I started by yours. Sorry not adding to the discussion.

~~~
andybak
I actually edited my top level comment immediately after writing it to try and
engage more directly with the topic at hand and tone down the 'meta-ness' of
my post.

Even so I'm slightly embarrassed that it's the top voted comment. I'd prefer
it if a more strictly on-topic comment was above me.

------
pkrumins
Ok, I've had enough. I'm making a prediction that the entire JavaScript
ecosystem will collapse.

This just doesn't make any sense. None of this is nice. It's all ugly and
complicated. There's no beauty to these tools. There are no fundamental tools
either. Everything is evolving too quickly. You've a choice of 25 frameworks,
libraries, tools that change every day and break between versions. The
complexity is growing and the ecosystem is getting extremely fragmented.

Instead of just writing your application, you're in despair trying to choose
the right tools, panicking about not being able to understand them, and then
then you spend weeks learning them. You end up writing application that is
glitching and you've no idea how to fix it because you depend on a dozen
different tools. Worst part is that you don't even need them. You've been
tricked by peer pressure into using them.

When you've a complex, fragmented ecosystem, and developers are in stress
because they can't understand and learn tools quickly enough, then the only
logical conclusion that it will collapse, and only a few technologies will
survive that will get mass adoption, and everything else will be forgotten.

~~~
anantzoid
> You've a choice of 25 frameworks, libraries, tools that change every day and
> break between versions.

And this is what the author has said too, and then presented a list of tools
for different purposes to one doesn't fall into analysis-paralysis.

Since past few months, JS community and settling down and tools are getting
stable and long lasting. Surely, new ones are being developed everyday, but a
standard is being set with React-Redux-Webpack family.

Maybe a new generation of JS tools will come up when Web Assembly becomes
mainstream, but until then, I think React is here to stay.

~~~
xirdstl
It is extremely hard to believe that anything in the JavaScript ecosystem will
be a standard or 'here to stay' for any timeframe greater than a year or so.

~~~
jbergens
Both React and Angular has existed for more than a year. Angular is a couple
of years old and still works although they have new version.

------
Lazare
I agree with 90% of this. React, Redux, ESLint with airbnb config, npm,
webpack, lodash, ramda, fetch, css modules...absolutely.

I disagree with the breezy assertion that types don't matter, and the offhand
dismisal of TypeScript. And saying that "TypeScript tries too hard to make
JavaScript like C# or Java" reveals, in my view, a fundamental failure to
understand what TypeScript does.

I also think the author is a bit too strongly in favour of `mocha`; I don't
think `ava` should have been some easily dismissed, and I've recently run
across a pretty nice framework called `painless`. And even if you do use
`mocha`, I find `expect` to be a better assertion library than `chai`. I think
a better answer here might be "use whatever works for you, so long as its not
Jest". (The shoutout to `enzyme` was on point though; great library if you
need to test React components.)

~~~
bottled_poe
mocha, ava, expect, chai, painless... honestly what the fuck is this. I'm not
a javascript developer - is the ecosystem really so fragmented? What a
nightmare.

~~~
untog
JavaScript is hardly the only language to have multiple test runners.

~~~
spriggan3
chai and expect aren't test runners, just libraries with assert helpers. I
personnally stick to jasmine. Chai is what happens when Rubyists try to write
some JS like they write some ruby.

------
treenyc
Why not mithril?
[https://lhorie.github.io/mithril/](https://lhorie.github.io/mithril/)

Seems to be way faster, and easier to learn than any of those other
framework/libs.

For example: How is Mithril Different from Other React: Source:
[https://lhorie.github.io/mithril/comparison.html](https://lhorie.github.io/mithril/comparison.html)

"The most visible difference between React and Mithril is that React's JSX
syntax does not run natively in the browser, whereas Mithril's uncompiled
templates do. Both can be compiled, but React's compiled code still has
function calls for each virtual DOM element; Mithril templates compile into
static Javascript data structures.

Another difference is that Mithril, being an MVC framework, rather than a
templating engine, provides an auto-redrawing system that is aware of network
asynchrony and that can render views efficiently without cluttering
application code with redraw calls, and without letting the developer
unintentionally bleed out of the MVC pattern.

Note also that, despite having a bigger scope, Mithril has a smaller file size
than React."

~~~
cetra3
I'm really interested in mithril from a technology stand point. The thing that
holds me back from using it is the ecosphere around it. You look at
powerhouses like react and angular and you can find a whole gamut of reusable
components that you can just plug and play from the community.

For instance: the twitter bootstrap framework we have options for both react
([https://react-bootstrap.github.io/](https://react-bootstrap.github.io/)) and
angular ([https://angular-ui.github.io/bootstrap/](https://angular-
ui.github.io/bootstrap/)).

But with mithril, the only bootstrap library I have found has not been updated
in 2 years ([https://github.com/eddyystop/mithril-components-
bootstrap](https://github.com/eddyystop/mithril-components-bootstrap)).

I really wish mithril had a bigger community around it, as when I used it for
a few prototypes it was a pleasure to work with and fast as hell.

~~~
hjek
I've been using Mithril a bit, and I like how it's just a library, not a big
framework pushing you to use a particular set of components. It's very light
and very well documented.

There are these "Mithril" libraries for Bootstrap and Material with 1
contributor and not updated for years, not appearing official at all. In my
experience they don't really work.

I'd say it's more in line with Mithril's design to use UI components that are
also loosely coupled, like these: [http://topcoat.io/](http://topcoat.io/)
[http://purecss.io/](http://purecss.io/)

------
interlocutor
The problem with React is its patent rider. React.js comes with a BSD license,
but has a patent rider that gives you a license to React's patents. This
sounds like a good thing, right? But this rider has a "strong retaliation
clause" which says that if you make any sort of patent claim against Facebook
this patent license automatically terminates. Which means Facebook can now sue
you for patent infringement for using React. You may think this is no worse
than not having a patent rider at all. But that's not the case. If there is no
patent rider then there is an implicit grant which cannot be revoked.

If you work for a software company and your company has patents then keep in
mind that by using React you are giving Facebook a free license to your entire
patent portfolio.

More info on weak vs strong retaliation clauses:
[http://www.rosenlaw.com/lj9.htm](http://www.rosenlaw.com/lj9.htm)

~~~
SiVal
_if you make any sort of patent claim against Facebook_

My understanding (and I'm asking for correction, if I'm wrong) is that last
year FB changed this provision to only cover patents on technologies within
React itself, not "any sort of patent claim against Facebook", which WAS the
situation before they changed it.

So, the current state is a grant of "you are licensed to use our React patents
at no cost as long as you don't try to make a legal claim that any of our
React patents are not legally ours."

~~~
Lazare
Not exactly. The diff is here:
[https://github.com/facebook/react/commit/b8ba8c83f318b84e429...](https://github.com/facebook/react/commit/b8ba8c83f318b84e42933f6928f231dc0918f864)

The old grant terminated if, among other things, you argued that any Facebook
patent was invalid or unenforcable. This meant that if Facebook sued you over
an unrelated patent, you couldn't defend yourself without the React patent
grant terminating.

The new grant specifically exempts any counterclaims; you can't lose your
patent grant just because you defend yourself. You _can_ still lose it if you
sue Facebook over unrelated patents.

------
lsdafjklsd
At work we've turned an ember-cli ember app into a react redux app in place
using immutable.js and ramda for everything. It's been a huge boon.

PS Ramda it eats lo-dash and its imperative API for lunch. It's for power
users, everything curried, higher levels of abstractions. Pick it up and learn
it, it'll make you a better programmer.

Next stop Clojurescript. Om next is a library where you can get a feel for a
Falcor + Relay stack in like 70 lines of code all without the specific tech
bloat. David Nolen is a UI profit, just follow him.

~~~
jdd
Lodash v4 has its FP module included with it: require('lodash/fp') for
immutable, auto-curried, iteratee-first, data-last method modules.

------
sklivvz1971
Every post that lists a set of tools is eventually going to be completely
wrong.

1) This is the author's favorite setup in 2016. With all due respect, what is
the lasting value of this information?

2) There is no "best" architecture. _It depends on what problem one is
solving_. The author does not specify that, making their conclusions likely
completely wrong in most cases. Yet, the language they use is in absolute
terms.

3) 99% of JavaScript simply enhances static HTML pages. Yes, even in 2016. You
probably don't even need jQuery, although it's likely to be available already.

4) It curiously evangelizes the "latest and greatest" frameworks, thus
incurring in novelty bias -- new frameworks have less apparent problems
because many side effects become apparent years later, once the codebase is
mature.

~~~
shados
Redux is the only "new" thing in that list, and I could code it from scratch
during a hackathon. It's also essentially a javascript port of what other
framework and languages have been doing since before a lot of people reading
this were born.

Ironically, a lot of the comments in the article are complaining why some
newer thing that just came out didn't make the list. Most of these tools are
2-3+ years old.

------
Mc_Big_G
Ember barely gets mentioned and includes each "piece of modern web
applications" OUT OF THE BOX with a great support community. I love not making
all of those decisions and doing all the integration BS work. Ember feels like
the worst kept secret.

~~~
tobltobs
Come on, Ember is so 2015 ...

~~~
jjawssd
Not sure if sarcasm or serious, but this sums up everything that is wrong with
the Javascript community succinctly

~~~
BillyParadise
I'd place a small bet on the former, but I wouldn't go all in. I agree with
you - those javascript folks are more ADHD than me. And that's saying a lot.

~~~
jjawssd
Good point

------
Kequc
A huge amount of this stuff is bloat, to me. It seems like this is a
collection of libraries that largely were picked out of the problem that is
javascript bloat today.

Use typescript and just write it to do whatever you want it to do. You don't
need React, or any of this stuff. Chai is good for testing. But as far as
deploying a production application, there should be literally no dependencies.
You don't need them.

There is nothing today that typescript or even just raw javascript can't do
perfectly fine on its own.

~~~
terda12
I disagree. I think React is a no brainer for any SPA. Try doing a full
fledged SPA admin panel in pure javascript. It's madness. But with React you
can separate everything else into components and it becomes clean and
beautiful.

~~~
jschrf
That's just considered good practice. React brings nothing new to separation
of concerns. In fact, it works against it.

------
tobltobs
Measuring time intervals in years for everything JS related is to imprecise.
"State of the Art in 3/2016" or at least quarterly would make more sense.

~~~
seanp2k2
Sadly, I had the same thought. By the time you + your team get on that latest
greatest, it's now been usurped. I really hope that the JS communities can
come together for some common needs and have just a couple of "paved road"
solutions. I can only imagine how confusing the current state of affairs is
for someone who "[just] wants to get started building modern JavaScript apps"

~~~
davidjnelson
I think a good mindset for building modern javascript apps is that they are
full featured desktop / mobile apps, just like a windows / mac / ios / android
native app. By definition these types of apps are complex, and always have
been, but they are highly valuable!

Looking at it from the lens of "web apps are just some html and css with a
little jquery" is a mindset that can make building very ambitious web
applications seem disproportionately difficult.

------
georgefrick
I'm not a fan of these discussions at all. We're all supposed to have been
using X framework at X time period. In the enterprise we can't just keep
rewriting all the god damn applications.

For us contractors, we have to answer to clients we had 2 years ago about why
their app is in Backbone.

I mean, damn; we have to build software here and we aren't all Facebook. You
might get warm and fuzzies from constantly starting over and feeling like
you've chosen the right framework, but it's immature.

Oh, we got it right this time! React is a paradigm shift! We've quickly
forgotten we were saying this with Angular bindings. Oh your model based stuff
is crap, this has TWO WAY BINDING, it's a paradigm shift!

Now, I'm using Angular. I could recite the Backbone source code, we had a few
small libraries and we built huge apps and they worked (and they were built
with Grunt and it worked fine, but hey, move it all to Gulp! now! Paradigm
shift!). In this case I was expecting it. I waited six months and Web Pack
came along.

We're going to go ahead and build our app in Angular 1.x with TypeScript and
Web Pack and test it with Jasmine.

This article is NOT correct. This hasn't been 'decided', there is no clear
winner. You can't simply list the features of something as "amazing" and
"where it's at". You are arguing finality here and you main data point is
"coolness factor". It's not correct, it's not objective, and it isn't high
quality, long term; well thought out software development practice.

~~~
ericflo
The good news is that Angular 1.x will work fine. It'll get the job done,
there's a huge pool of talent to pull from, and it's proven to work at scale.
However there are newer, better technologies now, and in 2 years time, there
will be better ones still. It's a tradeoff like any other.

And while certain fads do come and go, there are also larger shifts and it's
pretty clear by now that React's declarative-reactive style is the direction
the industry as a whole is going.

The aggregate community is always searching for better solutions, it just so
happens that this aggregate community is now huge and that means lots of
people thinking about the same problems, meaning we make faster progress.

Old things don't stop working, but new things can be made better! What's the
harm? Why so angry?

~~~
jmduke
I think there are frustrations borne from two main places:

\- Code is fashion; for some (especially on HN) there is inherent value in
using technologies that are bleeding-edge and in vogue. Additionally, the
_necessity_ to use things that are bleeding-edge and/or in vogue is amplified
when you're on HN or similar communities, much in the same way that the
quality of your raw denim is amplified when you're on a fashion forum or with
a bunch of stylish people.

\- Fashion fades; building something when it's in vogue in 2015 for the sole
reason that its in vogue in 2015 feels a lot worse when its in 2016 and
suddenly the underlying technologies are not so shiny.

I think it can be easy to muddle 'progress' in the sense of "how do we move
web technologies forward?" and 'progress' in the sense of "how do we deliver
value to clients and customers?" As someone who is fairly shy of the current
fashion (namely the React + Redux stack, which I've had the pleasure of
working with the past couple weeks and whoa is it cool!) -- I'm not entirely
convinced that the value delivered by using these technologies always
outweighs the risk that they'll be obviated in less than a years' time. And
so, there _is_ a risk inherent in rapid progress, if rapid progress
necessitates (as it seems to) the abandonment of anything that isn't pushing
forward.

Choosing your technologies is a value proposition: every choice has positives
and negatives. It can be frustrating to realize in retrospect that the
positives weren't that positive and that there were negatives you didn't even
imagine.

------
marknadal
We all have our opinions and I would say take this article with a huge grain
of salt (as well as my comment). State of the art javascript should still be
considered a browser + editor + files. There is no need to overcomplicate
things, and unfortunately Webpack and Babel do. It is terrifying to see
javascript turn into the new Java - build steps and compile steps and
configuration and everything you don't need except for distraction from
getting real work done.

Build your app first. Then when you are unhappy, see if these tools make your
life easier. But play with them first, don't make upfront commitments.

~~~
ams6110
You're downvoted but I for one agree. KISS. If you really NEED all that stuff,
fine, but it's quite clear why modern web pages are so bloated and slow on
anything but current-gen hardware and fast networks.

~~~
baddox
I doubt this article offers any explanation of the bloat observed in many
modern web pages. I suspect most web pages built using stacks like this will
actually tend to be fairly economical on the client.

------
STRML
This article echoes my experience this year and last, moving from a Backbone
app into React + Fluxxor, and eventually into ES6 with Babel + Flow + Webpack.

It's a huge pain to configure and understand all this tooling, but man is it
nice once it's all working. It definitely gives me hope for the web as an
application platform.

Re: Flow, it's good but nowhere near as developed as TypeScript, but it's
getting better. 0.22 of Flow (released just a week ago) brought massive speed
improvements that bring it decently on par with any other linter. I found I
could finally re-enable it in Sublime Text after this release. It catches all
kinds of things linters won't, and the upstart cost is relatively low. On the
other hand, TS has the benefit of years of type files available for almost any
library; don't underestimate how great that is.

Using React has been great as well. It's what I wish Backbone views had been
from the beginning.

We certainly aren't wanting for choice. Between the dozens of Flux
implementations, React alternatives like Mithril, interesting languages like
ClojureScript (with Om if you want to keep using React) or Elm, multiple
typing systems, and even WASM on the horizon - web development is an exciting
field. It's also overwhelming, and I say that as someone who keeps his head in
it over 12 hours a day.

\---

Re: CSS, the story still feels incomplete. I want a way to write a library
that will effortlessly import its own styles, so consumers can simply import
the component and go to town. Most solutions are severely limited, slow, or
both, mostly because they rely on inline styles. Nothing's wrong with inline
styles, until you want to do :hover, :active, pseudo elements or the like.

See the React material-ui project for a very real example of how this can go
wrong - note how every component has a dozen or more extension points for
styles. I built a project with this recently and it was intensely frustrating
that I couldn't simply add some CSS to the app to fix styles across the board
- I needed to keep a giant file of extensions and be sure to apply them every
time I used a component. And, of course, component authors can't possibly
anticipate every possible use, so some of my selectors were ugly "div > div >
ul > li:first-child" monstrosities.

CSJS ([https://github.com/rtsao/csjs](https://github.com/rtsao/csjs)) is one
of the few solutions I like. I would be very happy to see it, or something
like it, go mainstream.

~~~
nzonbi
Polymer ([https://www.polymer-project.org](https://www.polymer-project.org))
is a solution for the styles problem. You can pack each component with its own
styles, complete with all its functionality. This allows for a very clean
separation of concerns among components. Better than all other libraries that
I have tried. I hope that web components take off, because it is a great way
to build apps. Currently they are only supported in Chrome.

Moving data between components in Polymer, can be done with data binding. The
bad thing is that it could get messy for complex applications. Is not terribly
bad, but it could be better. What Polymer needs is a better way to move data
between components. If that problem is solved, Polymer would be an excellent
alternative to create any kind of apps.

~~~
spankalee
Note that style scoping comes with Shadow DOM, so once browsers support that
(it's happening now), you can get scoping with no libraries.

Polymer also adds a CSS custom properties polyfill and a CSS mixins (@apply)
polyfill. Custom properties are implemented in FF and Chrome already, @apply
is being worked on in Chrome.

Polymer always tries to be forward compatible with actual web standards, one
of it's main benefits :) Eventually Polymer will mostly be just templating and
convenience helpers on top of native standards.

------
tonyle
Mainly used angular and node. Someone was telling me about ember.js, I
wondered why I would use broccoli over browserify. 6 months later. Was
comparing browserify vs webpack. 1 month later.

Go to terminal

ember new app

ember server

start writing code.

------
alextgordon
> Unless you’re working on a legacy application or have 3rd party libraries
> that depend on it, there’s no reason to include it. That means you need to
> replace $.ajax.

> I like to keep it simple and just use fetch. It’s promise based, it’s built
> in Firefox and Chrome, and it Just Works (tm). For other browsers, you’ll
> need to include a polyfill.

I laughed. Is this satire? There's no reason to have X, therefore you need Y
_and_ Z to replace X. It just works.

~~~
hughes
Have you ever started a js app thinking you don't need jQuery? It usually goes
great until you need to make a request. One look at `XMLHttpRequest` and
suddenly including a 92kb (unminified) library starts to sound appealing.

I'd happily include a 9kb (unminified) polyfill and work off the assumption
that I can remove it a few years down the road.

~~~
BinaryIdiot
It's not so bad honestly. Just a little awkward. For my little JavaScript
library I wrote a small utility that lets me do Ajax calls that work in node
and the browser. It's limited but it's all I need and it's pretty well tested
(msngr if you're board).

$.Ajax is awesome and while XMLHttpRequest is awkward it's pretty straight
forward.

~~~
seanp2k2
If that's all you're after, I'd suggest something like Zepto win only the Ajax
module: [http://zeptojs.com](http://zeptojs.com)

------
kenOfYugen
> Avoid CoffeeScript. Most of its better features are now in ES6, a standard.

This argument against CoffeeScript isn't very objective. One of CoffeeScript's
best features is the minimalistic and expressive syntax.

"CoffeeScript (#6) appears dramatically more expressive than JavaScript (#51),
in fact among the best of all languages."[1]

"CoffeeScript is #1 for consistency, with an IQR spread of only 23 LOC/commit
compared to even #4 Clojure at 51 LOC/commit. By the time we’ve gotten to #8
Groovy, we’ve dropped to an IQR of 68 LOC/commit. In other words, CoffeeScript
is incredibly consistent across domains and developers in its
expressiveness."[1]

Using the author's train of thought I could state: "Avoid Bluebird[2]. Most of
its better features are now in ES6 promises, a standard."

Yes promises are in the ES6 standard, but that's not the best feature of
bluebird. There were and are many promise based libraries, but bluebird was
built for unmatched performance. One will use it if performance matters.

Even today it's faster than the native implementations of promises [3].

> Tooling (such as CoffeeLint) is very weak.

Maybe because, as it turns out, in CoffeeScript you don't need a lot of
tooling. Why would that be a bad thing?

> Electron is the foundation of the great Atom editor and can be used to make
> your own applications.

Atom is written in CoffeeScript [4].

[1] [http://redmonk.com/dberkholz/2013/03/25/programming-
language...](http://redmonk.com/dberkholz/2013/03/25/programming-languages-
ranked-by-expressiveness/)

[2]
[https://github.com/petkaantonov/bluebird](https://github.com/petkaantonov/bluebird)

[3] [http://programmers.stackexchange.com/questions/278778/why-
ar...](http://programmers.stackexchange.com/questions/278778/why-are-native-
es6-promises-slower-and-more-memory-intensive-than-bluebird)

[4] [https://github.com/atom/atom](https://github.com/atom/atom)

~~~
k__
I'm using LiveScript for private stuff and ES6/JSX in production. LS is a
pleasure to write. But the tooling on ES6 is nicer I must admit :/

~~~
kenOfYugen
Out of curiosity, what tools are you referring to that are nicer on ES6 and
not applicable to LS? Could you give examples?

~~~
k__
all the auto-complete stuff in atom.

------
hokkos
I use all those tools daily, but this article feel patronising to me, I would
feel inconfortable to say that whatever I use is the state of the art. Also
the author is totally ignorant and bigoted about typescript.

------
achairapart
Can we all agree that State of the Art JavaScript in 2016 is a mess?

~~~
BinaryIdiot
It's always been a mess and the trend will likely continue :)

Every few months there is a new, up and coming framework everyone is saying
that's better than the last popular one. And it's written in a dialect of
JavaScript that isn't supported in most places so it has to be transpired
first.

Good times /s

Honestly when I'm going into a new project I use a handful of utility type
libraries and that's it. You can still develop very quickly this way. The DOM
is awkward but very easy to use. I'm not convinced you need a framework.

------
increment_i
Whenever these kinds of JS commentaries pop up on HN nowadays, I notice two
distinct camps of commenters emerge: Those who are obviously steeped in the JS
scene and are delighted to argue the finer, more sophisticated points of it,
and those who take their best look, step back, and criticize this convoluted
house of cards - and of course proceed to be downvoted into the Stone Age as
the latest casualty of HN censorship.

My only observation of note I guess is the sheer marvel that all of this is
nearly entirely supported by the Open Source community, and the amount of
engineering effort being poured into the JS ecosystem at this point in time is
nothing short of astounding. I can't wait to see where it goes in the next few
years.

~~~
shados
We had a discussion about this in my last team. It really comes down to the JS
community being divided in 2.

You have the first group, of which most of us were part of at least at some
point: developing in our language of choice and being "forced" to use
JavaScript for some frontend stuff, in the same way we kind of have to use SQL
in some form when hitting a database.

That group generally wants to touch JS has little as possible then forget
about it. Ideally making it as close to their language of choice as possible
(similar to ORMs for database).

Then there's the other side, people who are running away with it and pushing
it as far as possible. That also comes with some problems (JS fatigue,
millions of frameworks, etc).

But generally, most comments will fall in one of the 2 categories.

~~~
clouddrover
> _That group generally wants to touch JS has little as possible then forget
> about it._

WebAssembly will be the thing which grants that wish. Once there's a compiler
for your language of choice that can compile to WebAssembly the need to use
JavaScript will be kept to a minimum.

~~~
qaq
Y but you will have to support JS for 10+ years regardless

~~~
clouddrover
Maybe not. There's a WebAssembly polyfill for browsers which don't yet (or
never will) support WebAssembly: [https://github.com/WebAssembly/polyfill-
prototype-1](https://github.com/WebAssembly/polyfill-prototype-1)

And the load times are still good:
[https://github.com/WebAssembly/design/blob/master/FAQ.md#can...](https://github.com/WebAssembly/design/blob/master/FAQ.md#can-
the-polyfill-really-be-efficient)

------
calebgilbert
In a development world that is already rife with planned obsolescence, the
Javascript world is the shining jewel. Reminds me of trying to construct the
killer Yu Gi Oh deck. By the time you get all the cool cards, paying a small
fortune for them of course, a new ban list comes out, new decks come out, and
you have to start all over again. Is the game improved through all of this?
Maybe it is, maybe it isn't, but I would say that this question becomes beside
the point for many players...

------
Niksko
I'm in the process of learning a JS stack at the moment, and I've come to
almost an identical conclusion to this article about the packages and tools to
use.

One difference though is that I've read Relay and GraphQL will eventually win
out over Redux. Thoughts?

~~~
t1amat
That Relay/GraphQL will "win" is very uncertain at this point. The solution is
very interesting but only time and real world usage of it will tell in the
long run. But you might be interested in this thread where the creator of
Redux muses on a future convergence of Relay and Redux[1].

[1]:
[https://mobile.twitter.com/dan_abramov/status/69755646131300...](https://mobile.twitter.com/dan_abramov/status/697556461313007616)

------
drumttocs8
Meteor isn't even being mentioned anymore in most of these posts, but it
really does reduce the need for so much tooling. Plus, it can use React as the
view layer.

~~~
elchief
Meteor is so February 2016

------
keithwhor
I'm a little bit bummed that the author seems to think there's "No API
solution." Nodal [1] was released in early January to a great response, and
I'd hope that more people are paying attention. Our most recent announcement
was that we're focusing on being API-first [2]. We also have out-of-the-box
GraphQL support [3].

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

[2] [https://medium.com/@keithwhor/realtime-doesn-t-belong-
everyw...](https://medium.com/@keithwhor/realtime-doesn-t-belong-everywhere-
build-scalable-api-services-in-node-js-with-nodal-10d0adfb66d)

[3] [http://graphql.nodaljs.com/](http://graphql.nodaljs.com/)

~~~
shados
Don't be bummed :) The point was that there's no "obvious" solution. Something
released in January needs a bit more time to become an obvious go-to. Doesn't
mean it's not great or that it won't.

~~~
dinkumthinkum
I think something released as long ago as January at this point is probably
obsolete. :)

------
reedlaw
I agree that React, Webpack, et al. are great improvements compared to their
predecessors. But do I really want to start an app in 2016 knowing that there
may be even better tools in 2017? Most likely I would use these but what ails
me is the thought that I might have to learn yet another tool and migrate. Why
does the JavaScript ecosystem move so quickly? I get that browser technology
is exciting and constantly improving. But why can't we settle on some well
designed concepts and keep them well maintained? I hope React is it because I
like it but it really depends on Facebook's commitment.

------
jastanton
Wow, this is nearly our teams exact stack. One addition would be superagent
instead of fetch. I really like Fetch, especially for react-native but
superagent is just so simple and easy to use

~~~
amackera
Superagent has flaws. It doesn't support promises out of the box unfortunately
:(

~~~
Can_Not
I don't think this is a problem, I expect to wrap my HTTP calls inside of
promise factories anyways. Promises solve the issue of callback piramids,
there's no issue with a single rogue, well contained callback.

------
ashwin_kumar
>> "You’ll be able to package your application and distribute it like any
other desktop application, complete with an installer and auto-updates."

Yep, Electron is excellent. However, Electron is built on top of V8 and V8
does not provide a way to protect the JS source. More than the technical
problem this becomes legal issue for businesses that want to develop
applications/tools rapidly with electron.

refer:
[https://github.com/atom/electron/issues/2570](https://github.com/atom/electron/issues/2570)

Cons of other options that I know: 1\. Obfuscation is not ideal to hide the
source from competitors.

2\. Writing nodejs modules in C++ is not so easy way. Once could prefer to
develop entire app with C++ than the learning curve associated with node
modules in C++.

3\. V8 snapshots maybe a way to go with nw.js. But doesn't work great and it
is hard to isolate issues while packaging.

4\. EncloseJS looks promising. There is no company behind it and no guarantee
it will be supported. (I personally have been following up with issues in
packaging an open source app with encloseJS. No luck so far with support.

5\. nexe is interesting. But not easy and no clear way to work with it.

What are your opinions? Any alternatives?

P.S: I'm framing a base with Java (most likely C++ too) to develop an app that
runs on client machine but on browsers. Performance and source protection are
my goals. Might open source its architecture eventually.

------
kayoone
Because of all this chaos i heavily lean towards Angular 2 and TypeScript.
It's a good common ground for larger apps imo and has good best practices.

~~~
t1amat
Angular 2 is as good of a bet as any except for maybe React. Angular has
enough name recognition in the enterprise space that it almost certainly won't
be going anywhere anytime soon.

That said, Angular 2 has no answer today for React Native, and to my view,
React Native style solutions may well be a requirement for any serious front
end solution in the coming years. React also has the benefit of a huge
corporation with massive scale dogfooding it, so you can be reasonably
confident that the core library is high quality.

~~~
kayoone
ng2 will work with native script:
[http://angularjs.blogspot.de/2015/12/building-mobile-apps-
wi...](http://angularjs.blogspot.de/2015/12/building-mobile-apps-with-
angular-2-and.html)

~~~
t1amat
Thank you, I will check this out! I hadn't considered a NativeScript route.

------
dkarapetyan
Sigh. Types are very important for the front-end. Have you ever tried to
validate the data going to the backend? Well then you're using types except
you've implemented your own bug-ridden and gimped version of typechecking that
already exists in flow and typescript. So just annotate your code. Both
typescript and flow work with mixed code bases where some parts are annotated
and some parts are not and there is clear benefit to even a half annotated
code base. Typescript even has support for JSX.

Not to mention that any front-end code will invariably have a domain model and
interactions that are much better expressed with typescript than vanilla
modern javascript. The refactoring and basic validations you get by even a few
annotation is just too good to pass up. I no longer write any javascript that
doesn't pass through the typescript compiler/typechecker.

------
eranation
> The learning curve is very flat

So if the graph's x axis is time and y axis is the amount of stuff you learn,
then a flat learning curve means that you gain very little added knowledge as
time goes by. And a steep learning curve means that you learn a lot in a small
amount of time.

It always confused me why is it backwards.

------
acron0
Not even a mention of ClojureScript? :(

~~~
shados
ClojureScript is pretty fantastic, and Om had a lot of the ideas behind Redux
before Redux (a bit like Elm). It's still a bit early to build a team
revolving around FP though (it can be done, but you need a big company
commitment in term of hiring practices, training people, etc). Consider
React/Redux a gateway drug. Sprinkle in some Ramda, maybe even some
Folktale...and then you're in a better spot to go. But starting with
ClojureScript if you have a team not too familiar with the JS world is really
rough.

I do really wish JS had native immutables with structural sharing, though.

~~~
t1amat
I don't feel like the barrier to entry in ClojureScript is that deep. I think
you will find it is awfully easy to pick up if you fall into one of the
following categories:

\- You have experience with Lisp dialects (even better, Clojure specifically).

In this case, you know the language semantics but not the application of in
this domain. The core concepts are so simple, and there is so much material
out there covering it, that picking this up should be easy.

\- You have experience with modern reactive architectures in any language and
an understanding to structure application state atoms.

In this case the concepts you learned will largely prevail and you will be
left learning the language semantics. While Clojure has an enormous core
library, you can do a lot with only a very rudimentary knowledge of the
language.

Also, what you aim for will probably make a difference. Reagent and the hiccup
style is incredibly easy to pick up, and re-frame supplies a very nice state
manager. Om and Om/Next are probably more difficult to pick up, and at least
in the case of Om, probably not worth it now. Om/Next seems to be an attempt
at replicating an entire React/Relay or Falcor/GraphQL stack in
Clojure/ClojureScript, and at this point it is dubious what size of an
application you need to develop to break even on the architecture and
complexity costs.

------
z3t4
I'm making web apps/clients in the browser, servers using node.js and desktop
"native" apps using nw.js. All in vanilla JavaScript, and I love it. If you
need additional functionality, there's always a module for it (npmjs.com)

The interesting part is maybe that most apps look like this:

    
    
      <html><body><canvas id="canvas"></body></html>
    

And the rest is JavaScript!

It does seem a bit stupid to load the browser just for the canvas element
though, so if someone know a better solution, please post!

~~~
err4nt
How does it look on retina/hiDPI displays?

~~~
z3t4
I've never had the chance to use a hiDPI display. But it will probably be
upscaled and look the same as on a normal screen. It would be an easy fix to
increase the canvas context scale though.

------
oever
To me the best compromise between using regular javascript and having type
safety is to use closure compiler. With closure compiler, you can write a
'header file' which defines the functions of the libraries that you use. Then
you can write all you own code with type annotations and even check that you
have 100% type coverage (--jscomp_error reportUnknownTypes).

Anywhere in your code where you are using identifiers, there should be a
method to check for typos. That holds for css classes and qnames too.

------
vmware505
Ember.js is already proved, the best framework out there nowadays. Corporate
ready, production ready, future proof. I'm really looking forward, that Type
Script support will be landing soon in the framework, so it will be a concrete
solid environment. The whole addon ecosystem, with Ember Data and Ember CLI is
just top-notch.

You can check here with this tutorial, how easy to write a complex application
with Ember.js: [http://yoember.com](http://yoember.com)

~~~
davidjnelson
From my experience, the most important aspect of a single page app framework
is the component api.

Here's the doc for ember's:
[http://emberjs.com/api/classes/Ember.Component.html](http://emberjs.com/api/classes/Ember.Component.html)

Versus react's: [https://facebook.github.io/react/docs/multiple-
components.ht...](https://facebook.github.io/react/docs/multiple-
components.html)

Versus angular's:
[https://docs.angularjs.org/guide/component](https://docs.angularjs.org/guide/component)

If you compare them, you can see that react and angular focus heavily on
component oriented architecture, while with ember, not so much.

Edit: wrong link.

~~~
vmware505
Ember implemented React and Redux concept a year ago, the component layer is
based on Virtual DOM. You can see here all the hooks what you can find in
React, maybe with a little bit different function names... a modern Ember app
is full of components. ;)
[http://emberjs.com/api/classes/Ember.Component.html](http://emberjs.com/api/classes/Ember.Component.html)
(Tick the check-boxes, Ember.js is nicely object oriented, so you can get a
lot from parent classes.)

------
doczoidberg
Do I bet on the wrong horse if I use Angular 2 instead of React+other tools?

I don't get the whole React love? I always learnt not to mix view and business
logic? React does this?

------
ellius
Can anyone tell me where to start on all of this as a self-taught beginner? I
feel like I follow tutorials well and get basic apps up and running via
tutorials. I've even built some basic tools in use by a handful of people at
my job with Node and Meteor. But the minute I try to dive into React and some
of these more professional tools in the ecosystem, I find myself totally lost.

~~~
shados
The article mentions [https://github.com/petehunt/react-
howto](https://github.com/petehunt/react-howto). Its a damn good place to
start.

~~~
ChrisDutrow
I just took a look, really good article.

------
neovive
Just wanted to mention VueJS as an option on the front-end for those looking
for a simple JS library with components.

~~~
t1amat
I was enjoying lurking, reading some of the freak out around what amounts to
spending a day or a week learning a new framework. Whether you believe that
this JS theatre is good or bad, learning new concepts and solutions is never a
waste of time, even if only to internally validate some other method. But if
you thought that being a competent software engineer only required a one-time,
upfront educational cost you probably got into the wrong field.

But throughout all this I was wondering who would come out and mention Vue.js.
While my own current preference is CLJS and reagent/re-frame, I feel like this
largely unknown framework should get some representation.

(Disclaimer: I am not claiming this is the best framework out there, but it is
very nice and I believe a great alternative for many of the commenters here
who are coming from Angular, trying to figure out where to turn next, but not
wanting to toss years of experience.)

If you come from Angular and like it's declarative markup but don't care for
the outdated architecture, Vue.js[1] is worth looking at. It's beautifully
clean and blazingly fast (v-dom under the hood). If you are willing to use a
Webpack or Browserify loader you get a very straightforward single file
component style[2], similar to a web component, where you can easily mix and
match style (scoped or not), script, and markup language of choice. The script
side of the component looks remarkably similar to React if the render function
was replaced with an external HTML template in the style of Angular.

For the Angular developers out there who "like things the way they are"
(mostly), do yourself a favor and check it out.

[1]: [http://vuejs.org/](http://vuejs.org/) [2]:
[http://blog.evanyou.me/2015/10/25/vuejs-re-
introduction/](http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/)

------
pdog
A summary, for convenience, of the state-of-the-art libraries for front end
development in Q1 2016:

\- Core: React

\- State container: Redux

\- Language: ES6 with Babel

\- Linting: ESLint

\- Style guide (ES6): Airbnb JavaScript Style Guide() {

\- Dependency management: NPM, CommonJS, and ES6 modules

\- Build tool: Webpack

\- Testing: Mocha and Chai

\- Utilities: Lodash

\- Fetching: Use what-wg or isomorphic fetch rather than jQuery

\- Styling: Sass, PostCSS, Autoprefixer, CSS Modules

------
kmfrk
Why is eslint considered better than jshint+jscs? jscs also supports auto-
fixing, which is pretty dope.

~~~
sotojuan
ESLint is extremely configurable and thus has a vibrant plugin ecosystem so I
think that's why it has picked up a lot of hype.

------
n0us
I would like to add that I've had an excellent experience with the Radium
library for styles. Sass was a little better than CSS because you sort of get
variables but being able to define styles in JS has fixed pretty much all of
the remaining problems.

------
choward
No mention of SystemJS/JSPM?

~~~
finishingmove
I found a mention in the comment section (I believe by the author of the
article), which said it didn't work all that well for them.

------
hoodoof
I find lots of modules that won't build with Webpack and a very solid chunk of
my available development time is spent trying to diagnose and fix problems
caused by modules that won't build under Webpack. I recommend against it.

~~~
Lazare
I've _never_ run across this, or indeed, heard of anyone have experienced this
before. More details? I'm honestly curious.

~~~
shados
It happens all the time because most UMD implementations are broken and make
incorrect assumptions, so you often have to follow the "Fix broken modules"
steps on [https://webpack.github.io/docs/shimming-
modules.html](https://webpack.github.io/docs/shimming-modules.html)

And if your package depends on a broken module, you're essentially SoL unless
you make assumptions about the path NPM will install stuff and configure
webpack to fix -that- one.

That's more a problem with the state of broken UMD modules than Webpack itself
though, but I've considered configuring webpack to ignore all AMD syntax quite
a few times...

~~~
hoodoof
Yeah the line of thinking seems to be that everything else is broken, not
webpack. And the module maintainers say "well it works with everything else
except Webpack so webpack is broken, they should fix it." Seriously crap
situation.

~~~
spriggan3
But people should code for Webpack or JSPM or require JS or whatever. A good
solution should just work no matter how the lib was coded, if it doesn't then
the solution isn't worth the investment.

------
mhd
JavaScript for medium-size SPAs, that is. For just enhanced content, this
still seems overkill and for true desktop replacement apps, there's a lot of
missing gaps (unless you ditch everything and settle with ExtJS).

------
feiss
I feel dumb for not using React. Damn, I even feel I'm living in sin.

------
jgalt212
What's the current thinking on React? Is it primarily indicated for SPAs? Or
should one us it throughout a web app (even for pages that don't qualify as
their own SPA)?

------
melvinmt
Is there a boilerplate repo somewhere with all these frameworks and tools
combined? Would love to dig more into this but configuring them all together
would take me days.

~~~
house9-2
My co-workers put together [https://github.com/CodingZeal/react-
boilerplate](https://github.com/CodingZeal/react-boilerplate) but the
documentation is a bit lacking at the moment, you really need to know a lot
about redux to use it.

Recommend: [https://egghead.io/series/getting-started-with-
redux](https://egghead.io/series/getting-started-with-redux)

------
k__
I would use something linke cyclejs with LiveScript, if I start something new.

the whole function composition has a clean feeling and LS removes a lot of
cruft

------
cel1ne
Regarding CSS I recommend tachyons [0] over css-modules.

[0] [http://tachyons.io/](http://tachyons.io/)

------
ausjke
I tried to like typescript however so far failed, don't feel like it though
everyone else seems are applauding it.

------
sandra_saltlake
It's not so bad. You just pick the most popular thing or use the
recommendations in articles like this one.

------
raspasov
Here's a short story.

I used to do a little bit of JavaScript. Initially it was easy. Functions!
Easy enough. Vars! Cool. I get all of that. I wrote some code, worked. Wrote
some more and it started not working as expected. I was curious why. I started
reading into it and discovered interesting concepts like "hoisting".

Then a friend of mine told me about Clojure/ClojureScript. I never understood
hoisting.

------
b34r
I wrote an app generator (actively maintained) that actually follows many of
these recommendations if anyone is interested:
[https://www.npmjs.com/package/generator-
enigma](https://www.npmjs.com/package/generator-enigma)

------
arxpoetica
No mention of WebSockets...

~~~
andybak
What percentage of projects need them? Surely it's not a core requirement
outside of actual real-time apps (and not 'lets play with realtime on my shiny
blog').

~~~
davidjnelson
I think any app requiring multiple user seeing the same screens could benefit
from them. Compare an open websocket versus polling every 30 seconds for the
use case of changes made by other users of your system. Instant notifications
and changes of your ui in real time versus a delay that could lead to users
trying to perform operations on outdated state.

------
bbcbasic
I have found using Elm a real joy, albeit for hobby projects. I do hope pure
functional languages become state of the art by 2026.

~~~
t1amat
Elm has a lot of beauty to it. I would definitely promote anyone interested in
learning FRP in web development to look here first. They really nailed the
essence of the architecture, and getting some experience with ML-family
languages is bonus, as they are likely more approachable than Lisp-family
languages for many. I'm really hoping Evan and the community can make this a
more viable solution in the coming years.

That said, Elm can be difficult to use today. The foreign function interface
is not all that great of an experience. There is a lot of friction in just
defining, serializing and deserializing JSON objects. You wind up writing a
lot of code you wish you didn't have too. Their great time traveling, hot
reloading debugger doesn't actually hot reload anymore. And there is no real
back end language synergy to speak of at the moment. Many are looking toward
Elixir and Phoenix for support instead of more language-similar Haskell
options like Yesod and Snap.

The competing PureScript, GHCJS, Websharper and FunScript alternatives also
complicate the landscape that Elm plays in greatly.

~~~
bbcbasic
I agree I am learning Elm mainly to learn FRP and do some 'haskell with my
hands tied behind my back' because I believe you can get a lot done without
resorting to the advanced language features of Haskell.

So for me it's a kata for learning how to be a better functional programmer.
Once I feel I 'get' the FRP model used I may just go and do the same stuff in
another language, see how it plays out in Haskell or Purescript.

I feel FP will remain a hobby though and the best I can hope for is to
convince .NET colleagues to make immutable classes, use code contracts to
avoid null problems, and generally try to minimize state and maybe use Rx.
Even F# would be too much of a push for most .NET shops. I have a mortgage and
fixing bugs caused by ridiculous state and null references in .NET code pays
it and then some :-)

~~~
t1amat
If I may make a recommendation: check out ClojureScript with reagent and re-
frame when you feel you've achieved what you set out to in Elm. While Elm
nailed the essence of FRP, ClojureScript really nails the experience I was
looking for in ways Elm can not.

While it doesn't have the gradual typing and _fantastic_ compiler messages, it
is also functional and immutable. But to my view it has all around better
tooling, very simple FFI (either reference JS already on the page
transparently or pull in JS formally via extern definition files similar to
TypeScript typings), optional typing via core.typed, sourcemaps with a native
debugger, and a node-like full stack synergy through Clojure but with all the
power of the JVM.

You definitely lose some confidence at run time due to the dynamic typing, but
on the whole I think the gains far exceed that. At least for me it's a package
that is very hard to beat.

------
ilostmykeys
Relay beats Redux any day

[https://gist.github.com/idibidiart/49a095b6bc528638f34f](https://gist.github.com/idibidiart/49a095b6bc528638f34f)

~~~
shados
Until there's no 1:1 relationship between the client and the server APIs, or
you don't control all parts of the server... Relay is amazing, but it makes
assumptions about the server (its kind of the point).

------
tomc1985
Who are all these people that need all these tools to write stuff in js? Go
back to coder school!

Is this what it means to look for a job in the startup scene in 2016? It seems
overwhelmingly likely that you'll be dropped into some unholy, frankenstein-
esque work of "art"

While JS has a few pain points that should be addressed by tooling, I'd draw
the line at React and jQuery and a bespoke, well-kept utility library

~~~
shados
Redux is 100~ lines of code without all the sanity check. Thunk is -4-.

You kind of need to settle on some kind of design pattern on how your data
exists, flows, etc. You'll want to be reasonably DRY doing it. Whatever you
code will probably be around the same scope. May as well use something that's
already documented and done. Same some time.

Then if you want to roll up your own bundler, minifier, manage your script
tags on your own, spend more time testing, etc...well, that's up to you :)

~~~
davidjnelson
Couldn't agree more. Having a central data model is so important to scaling an
application to many engineers versus the alternative of state being all over
the place or even worse stored in the dom, and also opens up some really
simple ways to implement quite advanced functionality.

