Druga część była raczej skierowana w stronę socjalistów twierdzących, że skoro syntactic sugar przyczynia się do nieznajomości języka, to powinno go w tym języku nie być.

> „Klasy” w ES6 to cukier składniowy na prototypy
To właśnie napisałem, więc o co chodzi? Nawet jest w opisie testu! Chyba zdajesz sobie sprawę, że znajomość działania dziedziczenia poprzez prototypy nie równa się preferowaniu go nad dziedziczenie za pomocą klas.

„Klasy” w ES6 to cukier składniowy na prototypy, który pozwala tworzyć krótszy i bardziej czytelny kod – nic więcej. Jeśli programista nie zna narzędzia, którego używa, to jego problem. Nie widzę powodów do narzekania.

>Myślę, że nie jest tak źle.
Masz szczęście w takim razie ;) ja widziałem już wystarczająco dużo.

>Pierwszy parametr i tak nie jest ownProperty, pisałem „enumerowalne i własne”
Ok, ale dziedziczy się prototypy. ownProperty to już broszka konstruktora, nie dziedziczenia.
Ale fakt – warto znać różne.

> No bo niestety nikt nie kapuje prototypów.
Douglas Crockford dobrze to tłumaczy – dużo osób go słucha i czyta. Myślę, że nie jest tak źle.

> Object.create (nie pierwszy parametr).
Object.create jest wygodny dla pewnych przypadków, a nie zawsze.

var obj = Object.create({foo: 1}, {bar: {value: 2}, baz: {value: 3, enumerable: true}});
var obj2 = new (function () { this.foo = 1; this.bar = 2, this.baz = 3 });
Object.keys(obj) // [„baz”]
Object.keys(obj.__proto__) // [„foo”]
Object.keys(obj2) // [„foo”, „bar”, „baz”] – pożądany wynik

Pierwszy parametr i tak nie jest ownProperty, pisałem „enumerowalne i własne”. Żeby z obj2 otrzymać taki sam wynik musiałbym jawnie napisać enumerable: true. Jestem daleki od tego, że jedna metoda jest lepsza od drugiej. Lepiej znać dwie i wybrać odpowiednią w danym momencie.

>gdybym był w tym odosobniony to CS nie zagościłby domyślnie w Railsach
No bo niestety nikt nie kapuje prototypów. To tutaj leży problem, nie w ich niedorobioności

>Jak mam obiekt i chce mu nadać 10 właściwości, które będą enumerowalne i własne to nie użyję Object.create, bo przy każdej muszę napisać jeszcze deskryptor
Ale przecież dodatkowe własności można nadać poza Object.create. to Object.defineProperty wymaga oznaczania enumerable w sposób dosłowny, nie Object.create (nie pierwszy parametr).

>Napisz własny i nie przetłumacz :P
Ok ;)

>Widzę, że nawet taki JSowy maniak jak Ty się dał na to złapać. OBIEKT arguments jest „array like”, nie jest tablicą.
Fajnie, ale ja poprawiałem „jako tablica” :D Poprawna forma to „jako tablicę”. No i ja tam wolę używać Array.from z polyfillem ;)

>Chętnie zaakceptuję jakieś pull requesty :D
A zobaczę. Na razie zajmuję się własnym artkiem o ES7 ;)

> Czyli mieli w wersji 6 przepisać fundamenty języka tylko dlatego, żeby wprowadzić klasy?
Im dłużej piszę w JS to patrząc na niego przez pryzmat np. Ruby to widzę, że przydałyby się mu solidne usprawnienia. Absurdy jak typeof NaN == „number” pomijam. Żeby to zrozumieć trzeba wiedzieć, że NaN jest liczbą przechowywaną w pamięci jako same jedynki – czy taka wiedza powinna być konieczna do zrozumienia sprawdzania typu? Moim zdaniem nie powinna być. Klasy mogłyby być dodane, (a nie zamiast) mimo, że prototypy mają więcej możliwości to widząc class w CoffeeScript cieszyłem się jak małe dziecko i gdybym był w tym odosobniony to CS nie zagościł by domyślnie w Railsach.

> Akurat to jest najgorszy przykład dziedziczenia w JS.
Jest wiele sposobów, nie ma „jednego poprawnego”. Jak mam obiekt i chce mu nadać 10 właściwości, które będą enumerowalne i własne to nie użyję Object.create, bo przy każdej muszę napisać jeszcze deskryptor.

> W życiu bym tak tego nie przetłumaczył.
Tłumacząc swój artykuł z angielskiego zdecydowałem, że przetłumaczę. Napisz własny i nie przetłumacz :P

> Co do iteratorów i generatorów: warto zwrócić uwagę na to, że generator de facto zwraca iterator.
Myślę, że dość jasno wynika to z pierwszego przykładu.

> >Możemy przyjąć w funkcji wiele parametrów jako tablica i pożegnać obiekt arguments.
> tablicę*
Widzę, że nawet taki JSowy maniak jak Ty się dał na to złapać. OBIEKT arguments jest „array like”, nie jest tablicą. Nie posiada np. metody pop by go nie modyfikować. Żeby uzyskać tablice potrzebujesz tego:
var args = Array.prototype.slice.call(arguments);
https://developer.mozilla.org/pl/docs/Web/JavaScript/Referencje/Funkcje/arguments

> Bardzo mi brakuje opisu Reflect API.
Tak jak pisałem, to jest przegląd. Nowe API obiektu niedługo będzie w repozytorium, na Reflect API też przyjdzie czas.

Przy stałych i let pominięto najważniejsze rzeczy, czyli 'temporal dead zone’ oraz brak hoistingu. Dzięki temu mamy de facto całkowicie dwa odmienne obiegi zmiennych, które zachowują się całkowicie inaczej.

>Stałe jak zapewne się domyślasz nie mogą zostać nadpisane, ale mogą być modyfikowane – można edytować właściwości obiektu przypisanego do stałej.
Wypadałoby przy tym zaznaczyć, że po prostu wynika to z tego, że w JS wartości prymitywne są niemutowalne (zatem porównywane przez wartość), a obiekty posiadają tzw. tożsamość. Nie modyfikujemy samej tożsamości obiektu, jedynie modyfikujemy jego własności.

Przy arrow functions wypada zwrócić uwagę, że nie dziedziczą po Function.prototype (a przynajmniej nie w pełni)

>trochę podstępnego parameter = parameter || default
Czemu podstępnego? Jak ktoś nie zna zasad koercji typów w JS, to nie powinien w tym języku pisać ;)

>Czy Ci się to podoba czy nie (jak to jest w moim przyp adku), klasy wprowadzone przez ES6, są tylko składniowym cukrem, którym możemy posypać prototypy.
Czyli mieli w wersji 6 przepisać fundamenty języka tylko dlatego, żeby wprowadzić klasy? IMO wgl ta składnia nie powinna zostać wprowadzona. Większość devów JS nie ogarnia prototypów, a jak się to przysłoni takim lukrem, to znajomość JS spadnie diametralnie. Wystarczy popatrzeć na ludzi, którzy znają jedynie CS…

>Jednak przyznaję, że extends wygląda przyjaźniej niż Child.prototype = new Parent()
Akurat to jest najgorszy przykład dziedziczenia w JS. Od dawna lepiej to machnąć przy pomocy Object.create. Z tym, że obydwa sposoby nam pokażą, że Child i tak nie jest potomkiem Parent.

W sumie jedyna sensowna przewaga extends (oprócz pokazywania poprawnych związków między „klasami”) to możliwość subklasowania natywnych „klas”. I to jest jedyny powód, dla którego sięgnąłbym po klasy.

>Możemy przyjąć w funkcji wiele parametrów jako tablica i pożegnać obiekt arguments.
tablicę*

>Mogą być wykożystane jako identyfikatory właściwości obiektów, w tym w WeakMap.
wykorzystane*

>Może się wydawać (mi tak się wydawało), że symbole są świetnym sposobem na symulowanie prywatnych właściwości (przez unikalne identyfikatory, niedostępne poza funkcją konstruktora). I wiecie co? Nie są.
One mają być po prostu unikalne. IMO Symbol to zbędny bajer i niepotrzebnie wprowadza aż tyle zmian do języka.

Co do iteratorów i generatorów: warto zwrócić uwagę na to, że generator de facto zwraca iterator.

Generatory jednak służą przede wszystkim do zarządzania asynchronicznym kodem i w połączeniu z Promises dają niesamowite możliwości, pozostawiając kod czysty i praktycznie „synchroniczny” (zresztą pisałem o tym na tym portalu z 2 lata temu).

>Jeżeli chcesz wiedzieć więcej o generatorach to sprawdź serię wpisów o generatorach w ES6autorstwa Davida Walsha.
One nie są autorstwa Davida Walsha, tylko Kyle’a Simpsona. Ja od siebie natomiast polecę blog 2ality.com – jego autor jest prawdziwym mistrzem jeśli chodzi o JS.

Co do literałów: śmieszne jest to zwłaszcza wówczas, gdy uświadomimy sobie, że literały takie zdeprecjonowano w ES5…

>Literały Szablonów
W życiu bym tak tego nie przetłumaczył. W ogóle to jest bolączka naszego community, że próbujemy tłumaczyć wszystko, nie podając równocześnie angielskich terminów. Jak ktoś przeczyta ten artykuł i zechce poszukać czegoś więcej na temat tego ficzera z ES6, to w życiu nie znajdzie tego, czego szuka. Template strings – tyle.

>Co więcej literał taki może otrzymać tag, który jest funkcją, a ta może go zmodyfikować.
Bez tego ten dodatek nie miałby najmniejszego sensu. Dzięki temu można było przepisać JSX na JS, pozbywając się całkowicie bzdurnej składni a’la E4X.

Przy Promises brakuje linku do specyfikacji: https://promisesaplus.com/

Co do modułów – TC-39 strzeliło sobie w stopę nie opierając składni modułów na tym zaproponowanym przez CJS. Co więcej – obecna implementacja loaderów IMO robi więcej szkody niż pożytku. Nie wspominając o nowym tagu module. Dlatego przez jeszcze bardzo długi czas standardem pozostanie UMD.

Bardzo mi brakuje opisu Reflection API.