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.
(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.)
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...
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) { ... })
==
===
Object.is() (would have been a good laugh if introduced as ==== 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.
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.
Whether this algorithm should have been exposed to users is debatable, but it exists for a good reason.
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.
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) { ... })
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.
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.
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.
Years later
var foo = <foo>{item}</foo>;
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.
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.
- 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.
I'm a senior frontend developer and I find this side of JavaScript truly bewildering.
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.
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.
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!");
https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_b...
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.
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?
images <- get "http://example.com/images.json"
var images;
get("http://example.com/images.json", (err, resp) =>
if err throw err;
images = resp;
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()`.
p.s. For prototyping like in the vid, you can use tools like beefy or wzrd to avoid setting up any browserify build step. :)
Does anyone know why he wouldn't have used the midi clock from Ableton (or other DJ software) to a "midi->websocket" server?
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.
It's nice to see JS get some positive press.
It's sort of like require.js on steroids.
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.
Here's another project using GIFs and beat matching:
Some other cool projects:
Why web can't get such a nice lang like C#, Swift?
In the mean time I will stick with Dart