
JavaScript in 2015 - geelen
http://glenmaddern.com/articles/javascript-in-2015
======
akanet
God, he makes it look good. The demo does give me a few of the ol' "too much
magic" heebie jeebies, but frontend JS development is so badly lacking in
compelling packaage management stories that I'm going to give jspm a shot.

Here's to 2015, I suppose.

P.S. Glen, if you're reading this, I really would love to see a youtube of a
DJ hooked up to automatically synced GIFs. Don't be a tease.

~~~
LunaSea
For package management why not use Bower ?

~~~
mattdesl
Bower is great if you need to install jQuery or one of its plugins, or another
very popular JS framework.

When you get into smaller modules, persistence, recursive or deep dependency
trees, versioning, automated bundling (i.e. no manual "config" files), etc.
then bower is not a strong choice.

A good writeup here:
[https://github.com/bionode/bionode/issues/9#issuecomment-495...](https://github.com/bionode/bionode/issues/9#issuecomment-49566087)

------
peferron
My biggest issue with the recent additions to the language is that there's now
a thousand different ways to do the same thing.

Iteration:

    
    
      for (var i = 0; i < y.length; i++) { ... }
      for (var x in y) { ... }
      for (var x of y) { ... }
      y.forEach(function(x, i) { ... })
      Object.keys(y).forEach(function(x) { ... })
    

Comparison:

    
    
      ==
      ===
      Object.is() (would have been a good laugh if introduced as ==== instead)
    

Of course, this doesn't matter much if you're a single developer. I've started
writing a bit of ES6/ES7 and it's pretty cool. But it's going to be a PITA for
projects built by many developers of varying experience levels. The nice
things about smaller languages is that there's often only one way to do
something, so when you write code or review other people's code, your mind is
free from the minutiae and you can focus on the big picture instead.

It's a bit funny that it's when JS is, from the general consensus, finally
getting "better" that I'm actually considering more and more switching to a
small but well-built compile-to-JS language. I guess smallness and simplicity
just matter a lot to me.

~~~
serve_yay
Object.is is a very silly addition to the language. It does the same thing as
=== except in the case of NaN and positive/negative zero.

I mean if you read a polyfill for it, it's such a silly bit of
"functionality". And of course the name is terrible. Argh.

~~~
ender7
The new Map and WeakMap classes use Object.is() to determine if two keys are
the same (otherwise it would be impossible to use NaN as a key to a map).

Whether this algorithm should have been exposed to users is debatable, but it
exists for a good reason.

------
chrisdotcode
What's interesting is that all of the 'niceness' seen is the result of a
switch to the functional style.

Excluding the singleton class (which could have been a single function
itself), you've got your map/filters in the gif processing, and encapsulation
of async activities[0] through monads via promises.

Seems like JavaScript got good when it started embracing what functional
programmers have been drowned out saying for years.

Looking good indeed.

[0] Async actions as a language-level construct, as opposed to a syntactic
abstraction have always been A Bad Idea. Promises should have always been the
default, and manually writing callbacks should have never been a thing.

~~~
lucian1900
Except for immutability. It's still nowhere near the norm.

~~~
nwienert
I'm working on a JS stack that leverages React, es6, functional style
programming, and immutable data. Check my profile for more info.

------
fredsted
Great screencast – lots of detail in a short period. No messing around, it
also shows how an optimized workflow should look like. The audio/video quality
of the screencast was extremely good as well.

------
danabramov
What will SystemJS+JSPM give me over Webpack? Just curious.

Webpack also supports ES6 modules (as well as CJS and AMD) when used with 6to5
transpiler, and has a lot of great features like splitting code into bundles,
figuring out the best way to split dependencies based on module size, and
asynchronously loading missing chunks.

~~~
linhmtran168
Haizz, I've just learned to use Webpack. Now comes SystemJS+JSPM. There are
just too many new tools, workflows and different ways of doing things in
Javascript world.

~~~
colinramsay
No, because SystemJS+JSPM does nothing to invalidate your Webpack knowledge.
It's still an active project that works just fine for the needs of many
developers.

~~~
dasil003
This is a trite response. If it does something significantly better than it
_does_ do something to invalidate knowledge in a defacto sense, at least for
the caring craftsman.

Not that there's any point complaining about it either though...

------
lbotos
Aside: "A DJ using Ableton Live, a huge bundle of MaxMSP emitting a UDP stream
of beat information (courtesy of the immensely pro Cade), a UDP ➝ WebSockets
server, and DJGif pulling hundreds of GIFs off various Tumblrs to beatmatch
<x-gif> on two projectors makes for a hell of a good show."

Does anyone know why he wouldn't have used the midi clock from Ableton (or
other DJ software) to a "midi->websocket" server?

~~~
radiowave
One reason might be that MIDI clock is just a repeating, identical message. It
does not contain any position information (like where the next bar starts). To
get positional information relating to beats and bars, you need to use MIDI
Song Position Pointers, however these use a 14 bit counter which will
typically overflow after about 10 minutes. In short, long-running musical
clock sync over MIDI is problematic.

For syncing sound recorders, MIDI Time Code (MTC) is usually used, which works
fine for up to 24 hours, but doesn't contain information about bars and beats,
so unless the system receiving the MTC has a-priori knowledge of what time
locations will correspond to bars and beats (which it typically wouldn't have
in the context of a live performance), MTC can't be used for this purpose.

~~~
lbotos
Sweet! Thanks for the detailed run down. As a DJ myself, at my residency we
have a random splattering of strange movie clips that we just play and they
are never beat matched but mentally something "always" hits a beat when you
are watching it. I guess he's going for stuff actually changing in musical
time.

------
jnhasty
For anyone building projects utilizing GIFs, check out the GIPHY api.

[http://api.giphy.com/](http://api.giphy.com/)

Here's another project using GIFs and beat matching:

[http://www.seehearparty.com/](http://www.seehearparty.com/)

Some other cool projects:

[http://giphy.com/labs](http://giphy.com/labs)

------
williamcotton
What advantages does this offer over the more mature ecosystem that surrounds
browserify?

~~~
lhorie
From what I can tell, it means you no longer need to write/maintain gulp
scripts and you don't have a build step during development

~~~
khalilravanna
That's assuming you want all your scripts to be loaded on the front end
asynchronously which seems to be only for development. For production I think
you'd still want to compile this all down for a faster load time. From the
jspm page: "For production, use the jspm CLI tool to download packages
locally, lock down versions and build into a bundle." So I think you're
correct that there'd be no build step for development but you'd still have
some sort of script being run, whether it be gulp or otherwise, that builds it
for production use.

~~~
lhorie
yep, the point though is that having a build step during dev adds some
overhead (which can easily go into the several seconds range in my experience)
into the type-save-reload cycle, which is exacerbated by hit-reload-before-
build-finished-so-need-to-reload-again pattern.

My understanding is that this tool removes that entire class of annoyances,
and gives a no-hassle live-reload ES6-enabled environment on top.

~~~
williamcotton
Substack's essay applies as much to this tool as it does to webpack:

[https://gist.github.com/substack/68f8d502be42d5cd4942](https://gist.github.com/substack/68f8d502be42d5cd4942)

Importantly, overloading require like this:

    
    
      var collections = require('npm:lodash-node/modern/collections');
      var $ = require('github:components/jquery');
    

... means that you can't publish this module to npm and have the require
statements work as expected.

------
rmrfrmrf
Looks like an interesting workflow, but I think I still prefer using a
compile-to-js language like CoffeeScript over the use of shims. I know it's a
silly thought, but to me, shims sort of violate the separation of
responsibilities between the user and the developer. If I, as the developer,
want to write more concise, scalable, and convenient code, it should be _my_
responsibility to spend my development resources to convert that code to
something the user's browser can understand.

------
tmaly
I would love to hear more about djgif

~~~
obituary_latte
There is a link to the repo in the article which might be helpful.

[https://github.com/geelen/djgif](https://github.com/geelen/djgif)

------
wldlyinaccurate
Really great screencast. If you have the good fortune to be a JS developer in
2015 (and beyond), there are some exciting times ahead!

~~~
lordbusiness
I'm _really_ late to the JS party, having just picked it up a month or so ago.
node.js and Meteor are my current tools of choice; it's a rather super
environment to get stuff done in.

It's nice to see JS get some positive press.

~~~
pestaa
In fact, JavaScript is the one late to the party, having developed some
rudimentary tools only recently. There's nothing exciting about redoing old
mistakes in a new ecosystem.

~~~
_random_
Don't say things like that on HN. Say "Wow, amazing! I did not know this is
possible in JS! JS is the future, other languages are not needed!"

------
mattdesl
I'd be curious to see how a medium to large project (500+ files) works with
this approach? I'm guessing it would take a while to load the page since the
browser has to request each script?

The tool looks pretty good. I think the most important feature is working with
existing modules on npm. :) This means that most browserifiable modules can be
jspm'd and vice versa.

~~~
agilebyte
In production you would bundle all into one file, while in development
most/all of your files will be cached by the browser. But to be honest I've
never worked with 500+ in the browser.

------
vayan
Nothing to do with this, but I remember a conf about javascript in 2040++ or
something can't find the video..

~~~
oblio
[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

------
basicallydan
Wow, this looks great. Nice one Glen. I'm looking forward to trying this out.
I'm going to, ASAP.

------
Bahamut
I found this link that was linked by the article to be very interesting:
[http://blog.npmjs.org/post/101775448305/npm-and-front-end-
pa...](http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging)

------
MrBuddyCasino
Slightly off topic, and sorry if it seems obvious, but his coding workflow
looks really neat. He must be using a Chrome extension to live-reload the
changes? Did anyone recognize the editor?

~~~
tomca32
Editor is Webstorm:
[https://www.jetbrains.com/webstorm/](https://www.jetbrains.com/webstorm/)

------
eskimobloood
I wonder if there is a way to split the build in more then just one big file
but in several smaller files then can be loaded on runtime.

~~~
illicium
Use WebPack and set up code splitting

------
nawazdhandala
Finally we have promises support built into JS.

------
atestu
What is the difference between this and require.js for loading modules? I feel
like I'm missing something

~~~
onion2k
require.js loads modules that are written to the CommonJS and AMD standards.
systemjs loads those too, but it also loads a few other things including
modules that just dump things in to global scope and things written to the ES6
standard.

It's sort of like require.js on steroids.

~~~
atestu
gotcha, thanks!

------
collyw
Still has more WTF moments than any other language I have used so far.

~~~
oneeyedpigeon
Your comment might be useful or interesting if you explained which WTF moments
affected you in particular, or even just which other languages you've used. As
it is, it's not adding much to the conversation which is why you've been
downvoted.

~~~
sarciszewski
Some WTF moments in Javascript, courtesy of Gary Bernhardt:

    
    
        var foo = ["10", "10", "10"];
        foo.map(parseInt);
        // Returns [ 10, NaN, 2 ]
    
        [] + [] // ""
        [] + {} // {}
        {} + [] // 0
        {} + {} // NaN
    
        var a = {};
        a[[]] = 2;
        alert(a[""]); // alerts 2
    
        alert(Array(16).join("wat" - 1) + " Batman!");
    

Press F12 and use the Console to verify these if you're skeptical.

~~~
hfsktr
I know what the batman example gives but I don't get how it's a WTF?

I assume the expected output is "wa" but why should a string less an integer
produce that?

~~~
squeaky-clean
There is no expected output. It doesn't make sense to subtract the value 1
from the string "wat". But Javascript will cast both of them to numbers, then
try to subtract 1 from NaN. However, if you do "wat" \+ 1, Javascript will
cast both of them to strings, and append "1" to "wat".

It's not just the odd behavior, but the inconsistency.

~~~
hfsktr
Ok that makes a bit more sense. I didn't even think about how it would be if
you tried to add them.

I like javascript but I don't do anything so complicated (or maybe not the
right types of things) that I run into many of these situations.

------
BigChiefSmokem
Instead of creating yet-another-library, yet-another-framework or superset
(TypeSscript, etc.) of it we should try to fix JavaScript itself. Why
companies don't push for this even if it's in all their best interests is
beyond me.

~~~
benaiah
They _are_. That's what ES6, a major focus of TFA, _is_.

~~~
_random_
They are not fixing JS, they are extending it. That's a different thing.
Because backwards-compatibility.

------
AndyFang98
Node.js is the only real dev language.

~~~
pestaa
Node.js is not even a language. Talk about factual correctness.

~~~
_random_
Node.js is just a Reactor Pattern implementation with some package management
on top.

------
tkubacki
JavaScript is broken by design (eg. adding obj properties on the fly is
killing perf and toolability) we need replacement.

Why web can't get such a nice lang like C#, Swift?

In the mean time I will stick with Dart

