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.
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…
JavaScript in 2015
71–80 of 129 posts
Re: JavaScript in 2015
#72Slightly 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?
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.
Re: JavaScript in 2015
#73Earlier quoted context omitted.
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…
yep, the point though is that having a build step during dev adds some overhead (which can easily go into the several seconds range in my experience) into the type-save-reload cycle, which is exacerbated by hit-reload-before-build-finished-so-need-to-reload-again pattern. My understanding is that this tool removes that entire class of annoyances, and gives a no-hassle live-reload ES6-enabled environment on top.
The build step is mitigated by incremental reloading, and the incremental reloading can be tied to a live-reload event.
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).
Re: JavaScript in 2015
#74Slightly 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?
The editor was webstorm with a very minimal UI
Re: JavaScript in 2015
#75For anyone building projects utilizing GIFs, check out the GIPHY api.
Here's another project using GIFs and beat matching:
Some other cool projects:
Re: JavaScript in 2015
#76God, 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.
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/.
Re: JavaScript in 2015
#77Earlier quoted context omitted.
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.
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.
This is a trite response. If it does something significantly better than it does do something to invalidate knowledge in a defacto sense, at least for the caring craftsman.
Not that there's any point complaining about it either though...
Re: JavaScript in 2015
#78God, 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.
Do you have time to hear about our lord and saviour browserify ?
Re: JavaScript in 2015
#79Earlier quoted context omitted.
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 know what the batman example gives but I don't get how it's a WTF? I assume the expected output is "wa" but why should a string less an integer produce that?
There is no expected output. It doesn't make sense to subtract the value 1 from the string "wat". But Javascript will cast both of them to numbers, then try to subtract 1 from NaN. However, if you do "wat" + 1, Javascript will cast both of them to strings, and append "1" to "wat".
It's not just the odd behavior, but the inconsistency.
Re: JavaScript in 2015
#80Earlier quoted context omitted.
No, it produces NaN (Not-a-Number), and then repeats it in a string 16 times. The WTF is that NaN can be concatenated to strings as "NaN".
NaN is passed to Array.prototype.join() as the separator to join strings with, so it gets coerced to String ("NaN"). It's deliberately working backward from the behaviour of Array.prototype.join() to create a contrived example for giggles, not a WTF. It's no more a WTF than this, which follows the same principle: https://gist.github.com/insin/1183916
Oh, I understand that. I was more trying to explain why someone might think it was a WTF.
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.