ECMAScript 6 kiedy będzie można go używać w przeglądarkach

Cześć,

kiedy będzie można używać standardów ECMAScript 6 bez obaw o utratę użytkowników z powodu braku supportu ich przeglądarek ?

już można, wystarczy transkompilować za pomocą Babela https://babeljs.io

To ciekawe narzędzie, tylko to dodatkowy narzut pracy... Czyli za jakieś 10 lat ECMAScript 6 będzie standardem w środowisku przeglądarek ?. Wiem że nowe przeglądarki implementują nową składnię, ale zanim użytkownicy się dostosują to musi minąć trochę czasu, więc pytanie czy warto teraz sobie zawracać głowę ECMA6 jeżeli działam tylko w środowisku przeglądarek i używam popularnych frameworków

Dlaczego dodatkowy narzut pracy?

Wystarczy np. babel dołączony do gulpa, albo webpacka, więc jak masz watch na plikach, to wszystko dzieje się w locie, podczas tworzenia i nie odczuwasz żadnego dodatkowego "narzutu pracy" : )

Od dwóch lat pracujemy z ES6 i ES7 przy pomocy Babela i nie ma problemów

Jest tego ES5, 6, 7, TypeScript, CoffeScript, Dart, Scala.js + setki frameworków jQuery, Angular, React....

Za 10lat to przypuszczam że nawet ES8 będzie już standardem :D

Teraz weszlismy w erę gdzie babel bedzie potrzebny zawsze :P jak przegladarki zaczna wspierac es6 to bedziesz chcial pisac w es20, wiec..

czyli nowi programiści JS nie będą wiedzieli jak działa JS, chociażby najistotniejsza rzecz jaką są prototypy w JS, teraz to się robi extends construct i załatwione, fajnie a gdzie klimat języka JavaScript ? tygodnie poświęcone na zrozumieniu "dziedziczenia" w JavaScript. Z tego co wiem przeglądarki obsługujące ECMA 7 będą miały TypeScript w środowisku i będzie można ładować normalnie pliki z TypeScriptem, nie ma ucieczki przed nakładkami na JS patrząc na standardy ?

Dlaczego kompilatory JS i PHP 7 są takie szybkie mimo że to są języki skryptowe, a Python i Ruby już sporo wolniejszy od nich? Ruby przecież ma kompilator pisany w czystym C, a JS w C++?

Pijany Mistrzu napisał(a):

Dlaczego kompilatory JS i PHP 7 są takie szybkie mimo że to są języki skryptowe, a Python i Ruby już sporo wolniejszy od nich? Ruby przecież ma kompilator pisany w czystym C, a JS w C++?

JS w C++, chyba chodzi Ci o Node.js ?

Zapewne dlatego że mają odchudzony core połączony z dodatkami przyśpieszającymi jego pracę ;). Poza tym każdy język daje tą samą wydajność, kwestia przystosowania środowiska w jednym mamy w default szybką pracę a w innym trzeba się bardziej namęczyć by osiągnąć lepszą wydajność

Nieposkromiony Kura napisał(a):

czyli nowi programiści JS nie będą wiedzieli jak działa JS, chociażby najistotniejsza rzecz jaką są prototypy w JS

A czemu mieliby nie wiedzieć, skoro to nadal część języka?

Myślę, że nowi programiści mogą się faktycznie zachwycić klasami, ci bardziej zaawansowani będą jechać na prototypach, ale jak ktoś głębiej wejdzie w język to i tak zrozumie, że samo dziedziczenie jako mechanizm przydaje się... dość rzadko.

Tzn. dziedziczenie dalsze niż 1 stopień: bo jak jest obiekt, który dziedziczy coś z prototypu to ma sens jeszcze (chociaż wg nazewnictwa klasowego tutaj nawet nie ma żadnego dziedziczenia, bo wg nazewnictwa klasowego byłaby to po prostu instancja danej klasy).

Może czasem wspólna klasa nadrzędna jest okej (tak jak np. jak się robi komponenty na klasach w React to dziedziczą one ze wspólnej klasy React.Component).

Generalnie im dłużej programuję, tym bardziej mam wrażenie, że mechanizm dziedziczenia przydaje się głównie jako metoda edukacyjna - w ten sposób można ludzi nauczyć obiektowego programowania pokazując na przykładzie, że jest sobie zwierzę, potem ssak, potem kot, potem tygrys - ale odnoszę wrażenie, że w realnych sytuacjach rzadko trzeba projektować dziedziczenie większe niż jeden stopień.

Jest tego ES5, 6, 7, TypeScript, CoffeScript, Dart, Scala.js + setki frameworków jQuery, Angular, React....

CoffeeScript jest już niemodny. Dart i Scala.js to jakieś nisze niewarte uwagi. Co do frameworków to nie jest tego dużo, bo liczy się i tak kilka najbardziej popularnych.

@LukeJL: dziedziczenie to mechanizm wykorzystywania ponownie kodu, który istnieje. W jsie masz bardzo fajny mechanizm na prototypach, ktory jest dostępny dla developerów. Co do użycia dziedziczenia powyżej 1 stopnia spójrz np. na django, tam ten mechanizm z wielodziedziczeniem jest namiętnie wykorzystywany.

@MuadibAtrides: a o kompozycji słyszał?

Przecież CoffeScript jest o wiele łatwiejszy od tego pokręconego ECMAscript 6, który miał uprościć JS a tylko bardziej go zamotał.

Transpilacja przy użyciu Babela to praktycznie żaden narzut i tylko mały task w konfiguracji Grunta / Gulpa / WebPacka i nie widzę żadnych powodów by tego nie używać. W ES6 na pewno pisze się przyjemniej, a kwestia samego programowania obiektowego i zastanawianie się czy i kiedy stosować dziedziczenie to dyskusja na inny temat. Te problemy są w każdym, nawet typowo obiektowym, języku i często lepszym rozwiązaniem będzie stosowanie kompozycji zamiast naciąganego dziedziczenia.

Pijany Mistrzu napisał(a):

Dlaczego kompilatory JS i PHP 7 są takie szybkie mimo że to są języki skryptowe, a Python i Ruby już sporo wolniejszy od nich? Ruby przecież ma kompilator pisany w czystym C, a JS w C++?

Polecam poczytać jak działa silnik v8 od google'a. Google bardzo dużo inwestuje w podkręcanie kompilatorów do jsa. Używane są dwa, jeden do szybkiej kompilacji jsa do asm i drugi optymalizacyjny w trakcie działania aplikacji, zbierający dane i poprawiający kod. Mają bardzo dużo zaimplementowanych optymalizacji + bardzo silne typowanie na poziomie kodu skompilowanego.

Gdzie np. Python po kompilacji działa dalej na vmce pythonowej z dużym narzutem.

Przecież CoffeScript jest o wiele łatwiejszy od tego pokręconego ECMAscript 6, który miał uprościć JS a tylko bardziej go zamotał.

Jest to subiektywne, ja się gubiłem w CoffeeScript z powodu jego nieintuicyjnej składni.

Tak długo było nie aktualizowane JavaScript 5, a tu nagle standard ES6, ES7... będzie się tak szybko pojawiał?

Tak, ale nie ma powodu do niepokoju, bo w ES7 weszły raptem dwie rzeczy...

• Array.prototype.includes
• Exponentiation Operator (2 ** 8 = 256)

Czy da radę stworzyć backend w Node? Prostą stronę z logowaniem, jakieś pomocne tutki może posiadacie?

node js + passport. Wygoogluj.

@Krwawy Pomidor
No po to Node jest.

A czego konkretnie uzyć to zalezy od konkretnego przypadku.