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.

[hij1nx]

npm is not just a server side package manager. It handles package management for the front-end very well and has for a long time, learn more here -- http://browserify.org/.

[1971genocide]

Do you have time to hear about our lord and saviour browserify ?

[tabrischen]

'I really would love to see a youtube of a DJ hooked up to automatically synced GIFs. ' Yes, this please !

[lomnakkus]

If you have new projects you can try this out on with out too much risk, then please do give this a go and report/blog about it!

(I, too, am extremely dissatisfied with the current state of ES5-based JS modularity. Frankly it's incredible that anyone can get anything done at all given the state of tooling for modularity/building/deployment ATM.)

[LunaSea]

For package management why not use Bower ?

[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.

[nawitus]

I would think that most languages suffer from this at least as much as JavaScript. The solution is to have guidelines and enforce them through code reviews. Linters can also catch some of the rules.

I'd say that JavaScript's benefit is that it's so simple that there are not too many solutions to do the same thing, unlike massive enterprise languages like C# and Java.

[lomnakkus]

Just looking at your example:

    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) { ... })

None of the "for" variations are considered good practice in ES6. You should be using "let" (or "const" if it's allowed here) to avoid var-hoisting of "i".

Personally, I'd advocate using "for" if you have a need for early return/break/continue -- otherwise I'd go for the first forEach() variant. Or, even better, use "map" and avoid side effects in the function you're mapping over the collection. Unless of course you're doing something imperative.

The fact that the last forEach() variant is possible is a good thing, though I wouldn't recommend its use in this case because it's needlessly complex -- it shows that the language/stdlib is becoming more compositional.

[frik]

I am unsure about some ES6 additions.

Thanks to Crockford we got a decent ES5. Remember that several syntax changes got postpones to ES6. And don't forget about "E4X", a beast that was supposed to be JavaScript 2? http://www.ecma-international.org/publications/standards/Ecm... It got similar traction as XHTML 2. Both had no backwards compatibility - an insane idea. Some new features in ES6 look like Crockford "good parts" movement lost and Sun/Oracle Java evangelists won.

Hopefully Douglas Crockford updates his "JavaScript: The Good Parts" in time for JavaScript 6.

[pcthrowaway]

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

To be fair though, this has been an issue with Javascript since its creation (and has been getting worse as the language has been expanded while maintaining backwards-compatibility).

Many other languages have similar problems (Ruby is an offender that comes to mind, though it's perhaps not on the level of ES6+)

I'm not much of a polyglot, but one language which seems to have "one obvious way" as part of its design choices that springs to mind is Python. I have a hunch that pure-functional languages would be less choicy as well, though I have no familiarity with any.

[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.

[_greim_]

> Async actions as a language-level construct, as opposed to a syntactic abstraction has always been A Bad Idea.

Are you saying that the upcoming async/await features of JS are a bad idea? Or maybe I'm not following; can you give an example?

[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.

[arcatek]

In their current states, Webpack is for the production applications, JSPM for development / little ES6 apps, and SystemJS is used for Node.js.

- Webpack supports much more than just ES6 (and more people work on it), so you probably want to use it for production apps.

- JSPM allows you to load ES6 library by transpiling them on-the-fly, which is great for simplicity.

- SystemJS works by itself in a Node environment, you don't need JSPM for it.

Guy Bedford has made a great tool with JSPM.

[Touche]

It runs in the browser so less boilerplate to start a project, don't have to run a build daemon for every project or wait for rebuilds to finish, etc.

[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?

[jnhasty]

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

http://api.giphy.com/

Here's another project using GIFs and beat matching:

http://www.seehearparty.com/

Some other cool projects:

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

[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

[sbuccini]

Yes, please. A video, and explanation of how to get beat data from Abelton to the server, anything helps.

[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.

[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...

[hyperpape]

Gary Bernhardt is the speaker, though my sense is that the talk is more of a thought-experiment/parable than anything else. He hasn't quite said that, it's just my impression.

[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...

[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/

[c17r]

The editor was webstorm with a very minimal UI

[teamonkey]

He talks about using live-server[1] about ~2m in. It injects the live reload script into the page it serves so no plugin needed.

[1] https://github.com/tapio/live-server

[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.

[akanet]

The article and cast was specifically about making the development flow for frontend javascript more robust. What are you complaining about? This article has nothing to do with advocating JS for "critical systems, frameworks and back end".

[zakelfassi]

I hope you're not serious.