JavaScript in 2015
glenmaddern.com
glenmaddern.com
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.
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...
NPM is in fact fine for frontend package management, it's not just about being able to use "Node land tools". All my frontend deps are on NPM, I published some NPM packages myself, and I don't even use Node.
Yes there are small issues (like wanting to be able to specify non-dupe requirement for some libraries) but overall NPM works fine for frontend. Much better than Bower if your app is moderately complex.
(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.)
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.
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>;
I'd argue that with ES6, JSX could just reserve the "jsx" prefix for interpolated strings and go with
jsx`<foo>blah</foo>`
http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts...
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.
In a language like JS you cannot have it all, but at least appreciate the improvements! ;)
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.
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()`.
I can make my code arbitrarily short if it doesn't have to be correct.
However, my comment above had nothing to do with how you handle errors, it was about the unsoundness of comparing code that handles errors to code that doesn't.
For clarification, the error is handled implicitly (but you'd know what kind of error it was due to the type signature), but you can always handle it in manner you choose to at any point.
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.
Not that there's any point complaining about it either though...
- 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.
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.
Here's another project using GIFs and beat matching:
Some other cool projects:
p.s. For prototyping like in the vid, you can use tools like beefy or wzrd to avoid setting up any browserify build step. :)
My understanding is that this tool removes that entire class of annoyances, and gives a no-hassle live-reload ES6-enabled environment on top.
https://gist.github.com/substack/68f8d502be42d5cd4942
Importantly, overloading require like this:
var collections = require('npm:lodash-node/modern/collections');
var $ = require('github:components/jquery');
So you end up with the same workflow as shown in this video; but most likely faster for many modules (browser requests 1 JS file rather than potentially hundreds) and also more realistic for production (aside from minification, the dev environment is the exact same as the production environment).
It's nice to see JS get some positive press.
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.
It's sort of like require.js on steroids.
https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_b...
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!");
parseInt takes two arguments: $thing_to_change and $radix; map iterates over an array and feeds it $value and $index. You're getting parseInt("10", 0); parseInt("10", 1) and parseInt("10", 2);
The fix would be to partially apply parseInt with your defined radix;
var foo = ["10", "10", "10"];
var base10 = function(val){
return parseInt(val, 10);
};
x = foo.map(base10)
[10, 10, 10]These aren't my examples. I haven't done anything. I credited the person who provided them: Gary Bernhardt.
https://www.destroyallsoftware.com/talks/wat
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Next time before you make an accusation, reread the post before pressing the reply button.
Writing x + y where x and y are both arguments to a function, and some call site was passed an (empty?) array of integers instead of an integer? Believable.
Or, put another way: why would a programmer want to have this "feature" instead of being notified: "hey, you're adding '[]' and '{}', that doesn't make any sense, fix that!"
Sure you can work with a language like that. But it sure doesn't feel like somebody thought all of this this through.
Or you know, stop acting like JavaScript is unique in that improper function calling breaks your code.
I can't believe in 2015 there are still people who follow the "JavaScript equalities are WTF" mentality. If you are running into equality operator problems in JS, you are probably going to run into a myriad of problems in any language.
I can't believe in 2015 there are still people who follow the "invalid input should produce invalid output" mentality.
I assume the expected output is "wa" but why should a string less an integer produce that?
It's no more a WTF than this, which follows the same principle: https://gist.github.com/insin/1183916
And I'm pretty sure your example returns the decimal 15. Comma operator returns the last element in the list, and parseInt will truncate strings with non-number-like text to the number-like part. Here, the number-like part is a hexadecimal code, triggering another feature of parseInt that it can figure out the radix on the fly.
It's not just the odd behavior, but the inconsistency.
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.
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.
Why web can't get such a nice lang like C#, Swift?
In the mean time I will stick with Dart