41–50 of 129 posts
Does anyone know why he wouldn't have used the midi clock from Ableton (or other DJ software) to a "midi->websocket" server?
I would love to hear more about djgif
Earlier quoted context omitted.
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.
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.
I assume the expected output is "wa" but why should a string less an integer produce that?
Why web can't get such a nice lang like C#, Swift?
In the mean time I will stick with Dart
Earlier quoted context omitted.
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
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 developmen…
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.
- 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.
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 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?
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.
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, y…
I'm a senior frontend developer and I find this side of JavaScript truly bewildering.
Earlier quoted context omitted.
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
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 developmen…
My understanding is that this tool removes that entire class of annoyances, and gives a no-hassle live-reload ES6-enabled environment on top.
Earlier quoted context omitted.
The first one is easy to understand though. 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, 1…
A lot of the ones he presented are easy to understand. It's still a WTF when you run into it though.