There is already! However it is not yet filtered in the current homepage but this will be ASAP.

as a proof: https://glsl.io/transition/a830822b23e846e25d2d

see that there is already some warnings ;-)

99 lines of code . . . and a few libraries. ;-)

Anyway, nice bunch of new ES6 features out there

Thanks! The aim for the chapter is indeed to show how ES6 and AngularJS simplify a typical web application like this.

The version at https://github.com/audreyt/500lines/tree/master/spreadsheet/... has exactly the same line count, but with more idiomatic workarounds that's less clear to students new to web development (the audience of this book).

It is possible to replace AngularJS (the only external library) with regular blur/focus/change handler as @xem shows — without affecting the line counts — but the separation of concerns between view, logic and worker would be less clear.

Comparing the ES5-DOM-only version: https://github.com/audreyt/500lines/tree/master/spreadsheet/... with with the AngularJS-with-ES5 version: https://github.com/audreyt/500lines/tree/master/spreadsheet/... would illustrate the issue of separation of concerns.

The DOM-only version had to construct its own view in JS, and use an additional #_A1 encoding to fill in calculated values into display, while the AngularJS version is declarative in that regard.

I'm a bit skeptical about this new property.

In this basic example,

    .element:hover {
	will-change: transform;
    }
    .element:active {
	transform: rotateY(180deg);
    }

it seems very predictable. I don't get why the browser couldn't guess (with some heuristics) what to prepare.

Also I feel we will misuse this feature and tend to make the performance worth than if the browser would detect what are the "will-change"s.

Which works fine in a CSS-only environment. But a lot of the time these properties are being set in JS, which is going to be very difficult to predict.

Is there a way to make this a JS-only interface or property, then? Heck, the article made it sound like using it directly in stylesheets would often be a bad idea anyway.

I generally try to not manipulate properties directly through javascript, rather declaring a class for the purpose. Doesn't seem like an unreasonable requirement for proper performance? (I mean, compared to having stuff like `will-change`)

But you still use Javascript to apply the class to the element, right? So how can the browser know that your Javascript might do that?

It seems to me to know that a rule along the lines of "might-add-class: foo;" would get us back most of that separation of presentation and content.

It is an unreasonable requirement in places, though. Before now I've made things like swipable elements that track the user's touch - i.e., you touch down, pull your finger left and the box follows you. That's not possible to do in pure CSS.

is there any goal?

exactly! definitely planned https://github.com/glslio/glsl.io/issues/23 :-)

https://github.com/glslio/glsl.io : the platform itself is open-source.

https://www.youtube.com/watch?v=BYdCNTJaGss : a first presentation video.

An other common mistake when you begin with promise:

    var result = promise.then(identity, function (error) { console.log(error); })

Oops, you just recovered your promise with undefined. result will always be successful. Yes if you don't throw again (or return a new failure promise) in your error callback it will make the resulting promise successful.

I haven't checked if this behaviour is the same on the DOM Promise API but it is on Q (which is the most popular JS lib for Promises).

dead link

Me too :-)