Live data from Hacker News

JavaScript in 2015

glenmaddern.com

81–90 of 129 posts

Re: JavaScript in 2015

#81

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…

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

Re: JavaScript in 2015

#84
post #82

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

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.

Re: JavaScript in 2015

#85
post #81

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…

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

This:

    images 
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()`.

Re: JavaScript in 2015

#86
post #84
post #82

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

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.

gotcha, thanks!

Re: JavaScript in 2015

#87
post #76
post #4

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.

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

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.

Re: JavaScript in 2015

#88
post #39

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

While these are WTF moments, when is anyone actually going to run [] + [] in a real project? The map to parseInt is the only one that's even close to something you'd actually write.

Writing literal [] + []? No.

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.

Re: JavaScript in 2015

#89
post #88
post #39

Earlier quoted context omitted.

While these are WTF moments, when is anyone actually going to run [] + [] in a real project? The map to parseInt is the only one that's even close to something you'd actually write.

Writing literal [] + []? No. 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.

I've been writing JS professionally for, what, a decade now - and I've never once had this issue.

Re: JavaScript in 2015

#90
post #4

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.

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