JavaScript in 2015

http://glenmaddern.com/articles/javascript-in-2015

by geelen • 12 years ago

417 123 12 years ago

fredsted• 12 years ago

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.

collyw2• 12 years ago

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

oneeyedpigeon• 12 years ago

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.

collyw2• 12 years ago

Its well documented:

https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_b...

virmundi• 12 years ago

I'm actually trying to write a book about that myself. It's called "JavaScript es basura caliente: Learning JavaScript in Anger".

The goal of the book is not to rag on JS. That's not new or really interesting in its own right. The goal is to walk people through the oddities of the language such as identity loss when passing a function from an object to something else (the good old this == window rather than self).

There are interesting, and annoying, things about JS that are non-obvious to people from a different language like Java or C#. There are other issues like testing and package management that are either assumed or glossed over. The JS community knows about them. Unfortunately for most of us, the responses to the language's weakness and ecosystem strengths are dispersed through the interblogs.

In fact from personal use of JS and some research on the book, I'm moving to a functional approach with JS. OO in Ecma5 is a pain. Pure (or Clojure like) functional can work with a bit of help from Underscore. That pardigm seems to fit the mentality of JS better too.

https://leanpub.com/javascriptesbasuracaliente

sarciszewski3• 12 years ago

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.

_broody• 12 years ago

Most of these WTF examples basically boil down to JS doing type coercion willy-nilly. This 'feature' makes writing conditionals slightly shorter, in exchange for introducing the possibility of massive bugs everywhere in your code at any moment. Seriously, f* JS type coercion.

The other misfeature I hate is that accessing undefined properties doesn't raise an error (then, but you can be sure it will make your program blow up a bit later).

Typescript helps to solve both.

_random_4• 12 years ago

Here you go: http://wtfjs.com

akanet• 12 years ago

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• 12 years ago

For package management why not use Bower ?

joshkpeterson• 12 years ago

http://jspm.io

mattdesl5• 12 years ago

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

hij1nx• 12 years ago

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

Bahamut3• 12 years ago

I'm a bit torn over using npm this way. On one hand, being able to use tools already built in Node land such as the EventEmitter is nice. On the other hand, having to use Browserify and navigating the mess of node modules is a pita. If the dependency structure with Node modules for npm dependencies were handled better, I would likely be all for it, but it is a major negative for me, especially if a quick project starts off as a mix of a Node server and contains a moderate amount of frontend heavy logic.

1971genocide2• 12 years ago

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

sanderjd• 12 years ago

I thought jspm looked like a direct browserify competitor/replacement. Is that an incorrect interpretation?

tabrischen2• 12 years ago

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

tabrischen2• 12 years ago

( and if not, an invite to your next rooftop party would probably suffice )

lomnakkus4• 12 years ago

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

basicallydan• 12 years ago

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

vayan• 12 years ago

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

hyperpape• 12 years ago

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.

oblio• 12 years ago

https://www.destroyallsoftware.com/talks/the-birth-and-death...

eskimobloood• 12 years ago

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• 12 years ago

Use WebPack and set up code splitting

wldlyinaccurate• 12 years ago

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• 12 years ago

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.

pestaa2• 12 years ago

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.

danabramov2• 12 years ago

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.

Touche• 12 years ago

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.

linhmtran168• 12 years ago

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• 12 years ago

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.

moron4hire3• 12 years ago

You don't have to try to learn everything. I know HR throws the kitchen sink into job listings, but it's okay to specialize in only one copy of a particular tool.

woah• 12 years ago

It's just not that hard. Try it and see if you like it.

arcatek2• 12 years ago

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.

davedx• 12 years ago

This seems so fragmented, even before you consider all the other module loaders, transpilers and toolchains.

I'm a senior frontend developer and I find this side of JavaScript truly bewildering.

williamcotton3• 12 years ago

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

lhorie2• 12 years ago

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

mattdesl5• 12 years ago

You still need to maintain build scripts for production, though.

p.s. For prototyping like in the vid, you can use tools like beefy or wzrd to avoid setting up any browserify build step. :)

khalilravanna• 12 years ago

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.

williamcotton3• 12 years ago

Who says you have to use gulp? Just use make.

https://github.com/williamcotton/makeify

tmaly• 12 years ago

I would love to hear more about djgif

obituary_latte• 12 years ago

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

https://github.com/geelen/djgif

sbuccini• 12 years ago

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

AndyFang98• 12 years ago

Node.js is the only real dev language.

pestaa2• 12 years ago

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

_random_4• 12 years ago

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

Bahamut3• 12 years ago

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

mattdesl5• 12 years ago

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• 12 years ago

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.

lbotos2• 12 years ago

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?

arthurdenture• 12 years ago

The beat information might have been more elaborately derived from the audio, as opposed to just sending the basic tempo.

radiowave• 12 years ago

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.

lbotos2• 12 years ago

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.

tkubacki• 12 years ago

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

chrisdotcode4• 12 years ago

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• 12 years ago

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

nwienert• 12 years ago

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

_greim_• 12 years ago

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?

chrisdotcode4• 12 years ago

This:

    images <- get "http://example.com/images.json"

is objectively easier to reason about than:

    var images;
    get("http://example.com/images.json", (err, resp) =>
        if err throw err;
        images = resp;

even though the former might be internally implemented as the latter.

In addition, the former doesn't give the programmer the 'opportunity' to cause a race-condition, and encapsulates the failure entirely for you (automatically and defaultly); If `images` ends up erroring, and you use it again, then it'll short-circuit without crash, very similar to `then()`.

MrBuddyCasino• 12 years ago

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• 12 years ago

Editor is Webstorm: https://www.jetbrains.com/webstorm/

teamonkey• 12 years ago

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

c17r• 12 years ago

The editor was webstorm with a very minimal UI

rmrfrmrf• 12 years ago

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.

jnhasty• 12 years ago

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

atestu2• 12 years ago

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

onion2k• 12 years ago

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.

atestu2• 12 years ago

gotcha, thanks!

nawazdhandala• 12 years ago

Finally we have promises support built into JS.

peferron2• 12 years ago

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• 12 years ago

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• 12 years ago

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.

nawitus• 12 years ago

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.

frik• 12 years ago

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.

riffraff• 12 years ago

I really wish E4X had gotten traction. I wrote a firefox extension using it and it was awesome to do XUL + JS with it.

Years later

  var foo = <foo>{item}</foo>;

is the new hotness in facebook's JSX.

lomnakkus4• 12 years ago

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.

peferron2• 12 years ago

Yes, "let" is better than "var". I could also have used a fat arrow in the forEach(). But my point was to list iteration variations, so outside of that I wrote traditional ES5.

This illustrates the issue though. "var" is like "let" but without block scoping, so you should almost never use "var", but it's still there to trip newcomers. The fat arrow is like the "function" keyword and most of the time you can use them interchangeably, but if you rely on "this" they're not interchangeable anymore.

This growing laundry list isn't exactly thrilling. I'm glad to have map(), filter(), every() and friends, though.

pcthrowaway• 12 years ago

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.

BigChiefSmokem• 12 years ago

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• 12 years ago

They are. That's what ES6, a major focus of TFA, is.

_random_4• 12 years ago

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

JavaScript in 2015

Related Stories