rauschma

For someone who already knows how to program or for a complete beginner?

My book may work for you (free to read online): “JavaScript for impatient programmers”. http://exploringjs.com/impatient-js/toc.html

Cool, thanks for the help!

(Full disclosure: I’m the author.)

I don’t think there’ll ever be typed dictionaries (which are a fairly high-level data structure). There is, however, a proposal for typed objects: https://github.com/dslomov/typed-objects-es7

Yes, that is left unspecified in the spec:

* http://www.ecma-international.org/ecma-262/6.0/#sec-allocate... (relevant: step 4, CreateByteDataBlock())

Typed Arrays are not the most exciting part of ECMAScript 6, but it is still good that they are part of the language now (vs. only a browser API). What surprised me while researching the post was how many browser APIs support Typed Arrays for binary data: File API, XMLHttpRequest, Fetch API, Canvas, WebSockets, WebGL, Web Audio API, and others.

(Disclaimer: I’m the author of the blog post.)

Yes, that’s how it works. `yield` is only reserved in ES5 strict mode. But due to it only being a keyword inside generators, there are no problems in non-strict mode.

AFAICT, `async function` is OK, because you combine a keyword with something that is contextually turned into a keyword. With a single non-keyword that isn’t possble. For example, the following code (a hypothetical ES6 anonymous generator expression) could be an ES5 function call followed by a code block.

    generator (a, b, c) {
        ···
    }

JavaScript is constrained by backwards compatibility. That’s why the ideal solution, the keyword `generator`, wasn’t possible.

His work is great! Linked to from the blog post...

[Disclaimer: I’m the author of the blog post.]

Knowing the algorithm helps with understanding the difference between the following two function declarations.

    function move({x=0, y=0} = {})         { /*...*/ }
    function move({x, y} = { x: 0, y: 0 }) { /*...*/ }

You are absolutely right when it comes to using ECMAScript 6 natively. It will officially become a standard in mid 2015. By then modern browsers should have implemented most of it, but it will be years until legacy browsers go away. It feels to me that (for most projects) we can just now rely on ECMAScript 5 being there everywhere.

On the other hand, there are already a few decent solutions for transpiling ECMAScript 6 to ES5 [1]:

* Traceur (there are Traceur-based plugins for Grunt, Gulp, browserify, webpack, etc.): https://github.com/google/traceur-compiler

* 6to5: https://6to5.org/

* es6-transpiler.js: https://github.com/termi/es6-transpiler

Using those tools results in a workflow that is much like using CoffeeScript.

[1] http://www.2ality.com/2014/08/es6-today.html

Not completely: with getters, you have to decide on a specific set of properties, the proxy GET trap intercepts all get operations. But I agree that you don’t always need proxies.

Even though it is about Scheme, the insights in SICP are invaluable for JavaScript programmers (the way I explain and visualize closures and environments are inspired by it). It’s one of the best programming books I’ve ever read.

Give my book a chance, it is complementary to both SICP and Eloquent JavaScript.

It’s an experiment of mine (but I am aware of at least one more O’Reilly book that has been published this way). I’m hoping that it’s win-win: The public version lets people share and link to what they have read (click on a title to create a link to it). And it allows them to figure out whether the book is for them. But I believe that it will also help sell books.

Don’t judge a book by its TOC! I’d love to get your opinion once you have read or at least skimmed, say, chapter 1: http://speakingjs.com/es5/ch01.html

It’s a matter of deliberate focus! If you are interested in browser stuff, you can either combine Speaking JS with the content on MDN [1] or buy a different book. I like the books by Nicholas Zakas and “JavaScript: The Definitive Guide”.

[1] https://developer.mozilla.org/en-US/

Note that the basics only seem simple. Speaking JS covers them, but also (as optional reading) exposes many of the mechanisms behind them. For example: [1].

The book explains the complete language. I consider functional programming more of a (fascinating and important!) meta-topic; worthy even of dedicated books [2] and beyond the scope of Speaking JS.

[1] http://speakingjs.com/es5/ch18.html#_array_indices_in_detail

[2] “Functional JavaScript” by Michael Fogus. http://shop.oreilly.com/product/0636920028857.do

It’s certainly a good book. Can you explain why you think it’s better geared towards experienced programmers?

Excellent background information, thanks!

Thanks for writing about your motivations for going to JSConf! If I may, I’ll describe my own motivations for going to a conference. I do so not to contradict your opinion, but simply to offer another perspective. For me, a conference has to do the core things well. Everything else I can organize myself – without the risk of someone else choosing badly for me.

- Destination: I considered both San Francisco and the venue to be perfect. For me, a destination mainly has to be easy to reach. Tourism is a plus, but ranks a distant second to the ease of getting to the venue. Additionally, San Francisco has the advantage that many important JavaScript people live close by which increases the chances of them speaking.

- Parties: Agreed. At least one evening event for everyone would have been nice.

- Food: I’m a bit difficult with food, so I often buy my own and don’t care about conference food much.

- Significant others track: I’m single. As long as my money isn’t spent to support other people’s partners, I don’t have an opinion either way.

- Spectacles: Again, I bring my own, so I don’t need a video game lounge etc. All of these things cost money.

- “Free beer / drinks throughout the day”: I am a beer drinker, but would only want a conference to serve alcohol in the evening.

- Schwag: please no. I always have an incredibly bad conscience when I throw away (most of) the stuff I get at conferences. After a certain point, one has enough toys, bags, pens and paper. That being said, a B2G phone certainly would have been cool.

- Community / Speakers: I like JSConf’s egalitarian approach. Not sure how well it scales up, though.

The biggest problem with JSConf is that it’s nearly impossible to get tickets (I tried twice). So where JSConf wins with regard to its egalitarian speaker/audience approach, it loses with regard to tickets, where it can feel a bit elitist: Some people will easily get a ticket, others won’t.

You might completely disagree with my taste as outlined above, but then the conclusion is easy: The JavaScript community can only profit from the increased conference diversity that is currently developing. In my opinion, Fluent should mostly stay as it is, as probably should JSConf (which I haven’t been to, yet).

“Right now, if I want an application that ‘feels native,’ Javascript is a no-go, and I have to use one of these (closed, proprietary) technologies.”

Not true – look at what Microsoft does with Windows 8.

This is purely a matter of taste. You only need the parens to tell JavaScript that it is a function expression and not a function declaration (a statement). The outer parens make an IIFE look even more block-like to me, which is why I use it. Any other prefix that tells JS that the IIFE is an expression is OK, too. For example:

    +function() { console.log("bla") }();

But: this one converts the result to a number, which you don’t want if you need the result of the IIFE. On the other hand, in places where you need that, there is usually no ambiguity with statements, anyway, and you don’t need any kind of prefix.

    var abc = function() { return "abc" }();