Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 79 reacties
Submitter: Rafe

De General Assembly van Ecma International heeft zijn goedkeuring gegeven aan ECMAScript 2015, beter bekend als javascript 6. Ecma International geeft daarnaast aan dat het voortaan jaarlijks kleinere updates wil geven aan javascript.

Javascript 6 is een aanzienlijke update ten opzichte van ECMAScript 5.1, dat vier jaar geleden uitkwam. Zo is de specificatiebeschrijving van de programmeertaal gegroeid van 245 naar bijna 600 pagina's. ECMAScript 2015 introduceert onder andere modules en classes, evenals maps, generators en sets. Volgens de makers moeten deze features het programmeren van javascript gemakkelijker en efficiënter maken.

De nieuwe javascript-versie is ondanks het grote aantal vernieuwingen backward compatible met voorgaande versies. Verder belooft Ecma International, dat de ontwikkeling van de taal in goede banen moet leiden, voortaan jaarlijks met updates te komen. Veel browsers moeten echter hun javascript-engine nog aanpassen om met de nieuwe editie van de programmeertaal uit de voeten te kunnen, al zijn er wel tools beschikbaar om ECMAScript 2015-code te converteren naar javascript 5.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (79)

Voor iedereen die hier nu mee aan de slag wilt: Er bestaan transpilers die code uit één taal nemen, en er een andere taal van maken. Meestal gaat dat verre van perfect, maar in dit geval is het alleen tussen verschillende versies en kan het dus wel degelijk perfect (genoeg). Om van ES6 naar ES4/5 te transpileren heb je twee opties:
  • Traceur van Google: Dit is de transpiler die ik zelf gebruik. Totaal niks te klagen over en werkt geweldig.
  • Babel.js: Lijkt net iets actiever te zijn als ik het aantal commits enzo bekijk en heeft hier en daar wat extra features zoals JSX support. Babel lijkt er voor te hebben gekozen niet met een runtime te werken, maar dat lijkt wel gewoon aan te zetten te zijn, dus op zich ook geen probleem. Al met al vermoed ik dat dit project ondertussen Traceur voorbij is gestreven, maar zoals ik al aangaf geen persoonlijke ervaring mee.
Daarnaast ook leuk om door heen te kijken: Het babel project heeft een heerlijke lijst van alles wat nieuw is in ES6: Learn ES2015 en op de Mozilla Hacks blog (van Mozilla dus) hebben ze een serie gehad waar ze verschillende features uit ES6 hebben gehighlight o.a. geschreven door de auteurs die sommige van die features zelf hebben geimplementeerd.

[Reactie gewijzigd door David Mulder op 18 juni 2015 17:06]

Om van ES6 naar ES4/5 te transpileren heb je twee opties
Twee opties? :S

https://github.com/addyosmani/es6-tools

Nu ken ik ze (gelukkig) niet allemaal, maar van TypeScript wordt ik wel vrolijk in ieder geval.

Meer info (leerzaam vond ik):
EcmaScript 6 support
Build: https://channel9.msdn.com/Events/Build/2015/3-644
Ignite: https://channel9.msdn.com/Events/Ignite/2015/BRK3703

[Reactie gewijzigd door geertdo op 18 juni 2015 17:50]

Babel is de meest gebruikte en ondersteunt ook de meeste functionaliteiten.

TypeScript is wel wat meer dan een ES6 transpiler en voegt ook niet-ES6 functionaliteiten toe. Je code is dan dus niet ES5/6 compatible.
Huh?!

TypeScript is een superset van Javascript en beter! om in te ontwikkelen.
TypeScript compileerd naar Javascript en kan verschillende Javascript versies targeten inclusief Javascript 5 en Javascript 6.

Daarom word bijvoorbeeld Angular-js in Typescript ontwikkeld. O-)
En als je de transpiler weghaalt zal je TypeScript in geen enkele ECMAScript compatibele omgeving werken, zelfs niet ES 6 of 7.

Het blijft een eigen variatie op de taal en niet volledig compatible met ES 6 of zelfs 7. Je zal altijd moeten blijven transpilen.
Daarom word bijvoorbeeld Angular-js in Typescript ontwikkeld. O-)
Angular wordt vziw in TypeScript ontwikkeld vanwege de ondersteuning voor attribute markeringen...

[Reactie gewijzigd door R4gnax op 19 juni 2015 01:04]

Babel is de meest gebruikte en ondersteunt ook de meeste functionaliteiten
Ik heb geen vergelijk hiervoor, heb je een 'source to back that up'?
Je code is dan dus niet ES5/6 compatible.
De uit TypeScript verkregen code is 100% Javascript.
TS 2.0 heeft volledige ES6 feature support (dus ik neem aan dat dat hetzelfde is als 'compatible').
TypeScript probeert zoveel mogelijk in lijn met ECMAScript6 te blijven. Dat wil niet zeggen dat iedere feature die ze implementeren in TypeScript (buiten de toegevoegde types dan) ook daadwerkelijk in ES6 zit. Zo is het mogelijk om in TS een method als lambda property te implementeren, terwijl dit een ES7 stage 0 feature is, en *NIET* een ES6 feature. Babel ondersteund bijv. ook een hele rits ES7 features.
Had ook met TS lopen spelen en dat ziet er wel goed uit. Eindelijk fatzoenlijke ondersteuning door je IDE
TypeScript is een volledig losstaande taal (inclusief inderdaad bepaalde ES6 features die getranspileerd worden), bedoeld als een soort van superset van ECMAScript. Alleen Babel en Traceur zijn transpilers die de gehele featureset van ES6 naar ES4/5 transpileren. De rest van de opties daar zijn allemaal of beperkt tot specifieke features of verschillende vormen van Traceur en Babel gewrapped.

[Reactie gewijzigd door David Mulder op 18 juni 2015 21:22]

Wat houden modules in? Is dat een andere benaming voor namespaces/classes?
Soort van. Het gaat om het importeren van functies, klassen en variabelen uit een ander bestand in een soort namespace:

// lib/math.js
export function sum(x, y) {
return x + y;
}
export var pi = 3.141593;

// app.js
import * as math from "lib/math";
alert("2π = " + math.sum(math.pi, math.pi));
dat is interessant, geen js files van 10k+ lijnen meer. kan men hoofdpijn wel wat verzachten op het einde van de werkdag :D
Dat is sowieso slechte manier van werken. AMD loaders zoals RequireJS zijn veel nettere aanpak voor grotere projecten.
Modulen exporteren was allang al mogelijk met Node.js.
aha, dus een soort van #include support voor javascript
Simpel gezegd: ja.
Iets uitgebreider: het is inderdaad een manier om code van het ene bestand in het andere bestand te gebruiken, maar met veel meer controle over wat er geïmporteerd kan worden (de "export" keywords in je library) en wat je importeert en hoe ("import X as Y from Z"). Dit lijkt me eerder afgeleid van de Python, waar je al "import X as Y from Z" kan doen. Nu met toegevoegde "export" functionaliteit :).

Het voordeel hieraan is dat je:
1. Niet meer in je html de verschillende JS-libraries hoeft te includen, nu doen ze het zelf — zonder document.write('<script src="/path/to/lib.js"></script>').
2. De globale namespace niet meer kan worden vervuild, je hebt alles gewoon in een object waar je zelf een naam aan geeft — en wat alleen bevat wat je nodig hebt.
3. Je hoeft al je code niet meer in een functie (closure) te stoppen en die gelijk uit te voeren om je variabelen te bevatten, alles wat je declareert in je bestand blijft in je bestand — tenzij je het expliciet aan de wereld beschikbaar maakt.
4. Dit alles kan nu zonder libraries als RequireJS, etc…

[Reactie gewijzigd door dwilmer op 18 juni 2015 20:48]

4. Dit alles kan nu zonder libraries als RequireJS, etc…
Alleen biedt RequireJS met loader plugins wel een flink stuk meer functionaliteit dan alleen maar 'dom' JS modules laden.

[Reactie gewijzigd door R4gnax op 19 juni 2015 01:07]

Niet helemaal. Een module is een losse file waarin normaal gesproken de code en variabelen alleen een scope hebben binnen die file. Echter, je kunt delen van zo'n module exporteren, en ook weer importeren.

Eigenlijk is dit iets wat bijna iedere programmeertaal al zeer lang kan, het is een basis om uberhaupt georganiseerd te kunnen werken, maar helaas native afwezig in JS.

Eenvoudige uitleg en voorbeelden:
http://www.sitepoint.com/understanding-es6-modules/
Maar op zich kon je javascript al aardig organiseren middels onderstaande

var test = {
doSum: function(x, y)
{
return x +y;
}
}

test.doSum(10,20);

en test weer in een los bestand te plaatsen. Het voordeel zie ik zelf dat je ook dus meerdere instanties van de module kan hebben onder een eigen naam (al zou dat ook weer kunnen door simpel weg de var te klonen). Sterker nog in de link die jij plaatst gaat de schrijver uiteindelijk ook over op bovenstaande voorbeeld..

[Reactie gewijzigd door ultimasnake op 18 juni 2015 16:52]

Een voordeel van echte modules wat ontbreekt in jouw voorbeeld is encapsulatie, de mogelijkheid om slechts delen van een object te exposen.
en test weer in een los bestand te plaatsen.
Maar je moest al die losse bestanden dan wel allemaal vanuit één en hetzelfde hoofdbestand includen. En als je foo.js include, en die heeft weer dingen uit bar.js nodig, dan moet je dat maar net weten, en dan met de hand ook bar.js includen. Of als je foo.js later niet meer nodig hebt, zit je nog met een deprecated dependency voor bar.js.. of niet, als er misschien ook nog een andere include file was die bar.js ook nodig had? Superonhandig dus.

Absurd eigenlijk dat dat nog steeds niet kon in javascript. Al boden package managers zoals nodejs die functionaliteit al wel.
Daar heb je dus AMD loaders zoals RequireJS voor. Daar kan je per module/file de dependencies opgeven en eventueel automatisch packages maken.
Met modules kun je functies, objecten met methods, JSON etc. uit bestanden laden zonder hier een zooi <script src=""> tags voor te gebruiken.

Je kunt met ES6 dus native bijv. 'var jquery = require('jquery.js');' gebruiken, zoals dat al langer in NodeJS of met een hulpmiddel als RequireJS kon. Als het bestand een geëxporteerde functie bevat, kun je deze vervolgens gebruiken met de variabelen waarmee je 'm geïmporteerd hebt.

[Reactie gewijzigd door ThePendulum op 18 juni 2015 16:43]

Alleen dan niet via require (dat is NodeJS), maar via import/from syntax.

import $ from 'jquery';

[Reactie gewijzigd door Bosmonster op 18 juni 2015 17:49]

Oh serieus? Heb de specs nog niet goed bekeken, maar zou toch require() verwacht hebben. import $ from 'jquery' voelt totaal niet JS aan eigenlijk.
Erg mooi. Wij gebruiken ES6 al volop in een project, in combinatie met Babelify en React. Een paar slim geschreven Gulp tasks voor nodejs doen de rest. Het was in het begin een beetje wennen, maar al vrij vlug had iedereen wel door hoe en wat.
Het nadeel is dat het niet zoveel doet. Je bent aan het transpilen naar ES5, dus er is eigenlijk geen toegevoegde waarde, behalve dat je een gedeelte van de ES6 syntax kan gebruiken (scheelt je soms wat typen).

Daarnaast worden veel constructies getranspiled naar simpelere ES5 varianten (een let of const wordt gewoon een var, om maar iets simpels te noemen)

Derhalve zou ik dit voor productie niet zo snel toepassen, het voegt alleen maar een foutgevoelige en lastig te debuggen abstractielaag toe en geeft je geen extra functionaliteiten die je niet in ES5 al hebt.

Het wordt pas interessant als je selectief kunt gaan transpilen op basis van browser support en de missende functionaliteiten kunt po(l|n)yfillen. Maar dat ga je nooit vanuit je build tools doen natuurlijk.

[Reactie gewijzigd door Bosmonster op 18 juni 2015 17:34]

const wordt weliswaar omgezet naar var, maar niet zomaar. Doe je bijvoorbeeld het volgende:
const a = 1;
a = 2;
Dan zegt babelify dat je constants niet kan veranderen en weigert hij de bestanden te bouwen.

Daarbij heeft het in mijn ogen wel degelijk voordelen: je begint een taal al te leren die je binnenkort ook moet weten, dus bouw je een voorsprong op. We gebruiken nu volop classes etc die niet bestonden zonder extra libraries in te laden (voorheen Mootools).

Foutgevoeligheid heb ik nog niks van gemerkt. We werken nu een paar maanden op deze manier en ik ben nog geen bug tegengekomen die door Babelify is veroorzaakt
Er is praktisch geen verschil tussen het inladen van een externe library voor iets als classes en transpilen natuurlijk. Transpilen zorgt uiteindelijk ook voor een flinke bak extra code om classes in ES5 te implementeren.

Het voordeel is dat je ES6 syntax (gedeeltelijk) kunt gebruiken en een klein voordeel hebt naar iets dat je over 2 a 3 jaar misschien wel in het echt kunt toepassen zonder transpilen.

Die syntax is nu niet zo ingewikkeld dat je daar een paar jaar voorsprong op nodig hebt.

Een ander voordeel is dat je code die je nu schrijft makkelijk kunt omzetten naar native ES6 en de transpiler eruit kunt knikkeren. Maar aangezien ES6 toch al backwards compatible is, kun je je ook daarvan afvragen hoe nuttig dat is.

[Reactie gewijzigd door Bosmonster op 18 juni 2015 17:44]

Nettere overerf structuur en echte constants en lets zijn op zich wel een voordeel natuurlijk. Beetje zelfde reden waarom mensen TypeScript gebruiken. Dat het ooit native wordt is alleen maar extra pluspunt.
"echte constants en lets" worden het natuurlijk nooit als je het transpilet naar ES5. Uiteindelijk levert het gewoon var's op met wat trucerij of transpiler warnings.
Maar juist die transpiler warning zijn zeer nuttig voor debugging.
Waarom zou je dat niet vanuit je build tools doen? Lijkt mij juist ideale omgeving. Dan kan je gewoon configureren hoe je browser support moet zijn en eventueel verschillende versies van een file genereren.

Zo doe ik dat bijvoorbeeld ook met CSS prefixes.
Omdat je build tools geen client-specifieke feature detection kunnen doen. Met een paar prefixed css properties boeit dat niet zo, maar met iets ingrijpends als je gehele codebase van een complexe applicatie transpilen is de impact wel een stuk groter.

Ik zeg niet per definitie dat je het niet moet doen of dat het geen voordelen heeft, maar het is wel iets waar je serieus over moet nadenken, zeker voor productiecode. Spring niet zomaar op de hipheid trein.
CSS prefixer werkt met een database met browser support. Zoiets kan je voor ES6 ook doen natuurlijk. Volgende stap zou dan wel zijn om juiste package in te laden. Eventueel zou je dat met useragent detectie serverside kunnen doen. Of clientside feature detection maar dat vertraagd wel weer enorm natuurlijk. Jammer dat ze er niet gelijk een syntax bij hebben gedaan om ES6 support te detecteren in <script>-tag. Wellicht dat dit nog komt als browsers het volledig hebben geïmplementeerd. Beetje ala codec support in <video>-tag zou ook kunnen.
Versioning is juist wat ze wilden voorkomen met ES6 (en de toekomst van ES). Daarom hebben ze het denk ik ook op de valreep hernoemd naar ES2015.

Meer informatie hierover (iets ouder artikel wel):
http://www.2ality.com/2014/12/one-javascript.html
Ja dat begrijp ik, maar dat betekent wel dat we voorlopig nog aan het transpilen zijn. En zolang nieuwere browsers gewoon ES5 ondersteunen is dat natuurlijk een prima techniek.

Sowieso wordt die nieuwe aanpak van losse bestanden pas echt interessant als HTTP 2.0 breed ondersteund en geïmplementeerd is. Dan hoef je niet meer te packagen want dan gaan er gewoon meerdere requests over 1 connectie.
Ben benieuwd wanneer de volledige support is ingebakken in de eerste browser en wanneer er een significant deel op de nieuwe versie draait zodat het echt (zonder tussenkomst) gebruikt kan worden. Ik denk dat een heleboel frameworks nog te vroeg zijn met implementatie, maar kijk uit naar wanneer dit breder gebruikt kan worden. Ik vraag me echter af of de browserfabrikanten dit jaar nog de volledige support kunnen leveren. Iets zegt me dat dit nog wel even gaat duren.

En dat dit natuurlijk niet op oude devices kan worden uitgerold is natuurlijk een grote beperking. Iets zegt me dat je nog lang legacy-support mag gaan leveren :/
Of er een browser zal zijn die kan zeggen dat ze ECMAScript volledig ondersteunen dit jaar betwijfel ik ten zeerste. Maar Microsoft (met 82% ondersteuning) en Firefox (met 66%) zijn al goed opweg om dit aanzienlijk te ondersteunen. Chrome zit nog op 45%. Alleen Safari hang achter met 16%.
Safari brengt ook maar 1x per jaar een nieuwe versie uit, dus is moeilijk mee te nemen in zo'n vergelijking.

Als je het zo gaat bekijken zit Microsoft namelijk nog lang niet op 82% (maar op 14%), want Edge is nog niet uit. Of je moet Safari 9 ook mee gaan nemen.

De huidige WebKit release zit op 50%, dus Safari 9 zal ruim dat gaan ondersteunen.

https://kangax.github.io/compat-table/es6/

[Reactie gewijzigd door Bosmonster op 18 juni 2015 17:37]

Dat is dan ook een groot probleem bij Safari, met diens marktaandeel is het gewoon enorm lastig om al met dit soort technieken te gaan beginnen.

En het zal Apple niet zijn of ze doen weer hun eigen ding. Al is het maar in de laatste plaats om te zorgen dat ze de macht behouden met hun appstore. Want laten we wel wezen, zonder die appstore raken ze enorm veel inkomsten kwijt.

[Reactie gewijzigd door Martinspire op 18 juni 2015 22:03]

Je opmerking raakt kant noch wal. De adoptiegraad van nieuwe iOS en OS X versies, en daarmee nieuwe Safari versies is heel hoog. Juist bij Safari is dat nauwelijks een probleem in verhouding tot bijvoorbeeld Windows met Internet Explorer of Android met oude stock browsers.

Je opmerking over de App Store lijkt me nogal irrelevant, dus zal ik niet verder op ingaan.
Dat snap ik, maar omdat het telkens tot een nieuwe OSX/iOS versie duurt, eer Safari wordt bijgewerkt, heb je telkens een lang gat waarbij er geen verbetering is. Dat was bij iOS 8 en 7 ook voor dingen met de webview waardoor je allerlei hacks nodig blijft hebben om dingen te laten werken. Dat is gewoon erg irritant en heb je met bv Chrome op Android geen last van.

Overigens heeft de mobiele versie van Internet Explorer daar ook last van (gehad?)
Elke default browser heeft daar last van helaas en dat is de reden dat we als web developers ons uberhaupt nog druk maken over features en verschillende (oude) browsers :(

Safari is wel een van de browsers waar ik me in dat op zicht niet zo druk over maak, want die loopt mijlen voor op andere browsers met hetzelfde probleem (zoals IE9/10 of Android 4 of zelfs 2 stock browser).
Safari brengt ook maar 1x per jaar een nieuwe versie uit, dus is moeilijk mee te nemen in zo'n vergelijking.

Als je het zo gaat bekijken zit Microsoft namelijk nog lang niet op 82% (maar op 14%), want Edge is nog niet uit. Of je moet Safari 9 ook mee gaan nemen.

De huidige WebKit release zit op 50%, dus Safari 9 zal ruim dat gaan ondersteunen.

https://kangax.github.io/compat-table/es6/
Wel, had ik geweten dat WK stond voor Safari 9, had ik het erbij gezet. ;)
Nu Javascript 6 classes ondersteunt, heeft schrijven in Typescript nog veel meerwaarde?

[Reactie gewijzigd door Slashdotter op 18 juni 2015 17:19]

Als je strong of static typing wil hebben wel, want dat zit niet in ES6.
Je hebt geen private/public classes. Dat zal komen in ES7 (?).

En nog meer: https://kangax.github.io/compat-table/es7/
Zie ook de ES6 tabel: https://kangax.github.io/compat-table/es6/
Wouw, wat een verbeteringen! Classes, includes, generators, maps en sets, functioneel programmeren achtige methoden, syntaxtoevoegingen en nog wel meer. Veel hiervan is vergelijkbaar met aspecten uit andere talen. Ik wordt hier nu al blij van :D . Nu hopen dat het ook redelijk snel standaard wordt in de meeste browsers.
Tevens worden de javascript interpreters van zowel die van Microsoft en die van Google ook steeds sneller.
doordat ie niet automatisch update, zal het wel een tijd duren voordat je dit zonder hacks kunt gaan gebruiken
Toch is het altijd beter om native ondersteuning te hebben dan het om te moeten zetten naar een oude versie. Dat werkt toch altijd langzamer en levert je geheid bugs op.
Het is een taalstandaard. Wat dat uberhaupt met updaten te maken heeft ontgaat me. Het is geen concrete implementatie of iets dergelijks. Het is aan de ontwikkelaars van de javascript engines in browsers om de standaard te gaan implementeren.
maar als de browser niet geupdate wordt, blijft de javascript engine ook achter lopen
Voor mijn gevoel zijn ze, de browser makers, tegenwoordig een stuk meer bezig met naar de standaarden toe te gaan.

Er zullen altijd nog wel verschillen zijn, want anders zou het geen andere browser zijn.
Maar ik heb tegenwoordig het vertrouwen, dat iedereen gewoon netjes de standaard implementeert i.p.v. eigen regels te gaan verzinnen.
Die tijd is nu een tijdje al voorbij, volgens mij.
bij de nieuwste versies wel ja, maar je blijft altijd nog met oudere versies zitten, dit is voornamelijk het geval bij IE
Je bedoelt, 'bij oudere versies van IE'. En ik denk ook browsers op Android telefoons welke geen updates krijgen.
Daar hebben ze 'Edge' voor :)
Dat klopt op zich wel, maar het tijdig implementeren van complete feature sets zit daar nog niet in helaas. Het gaat zeker weten nog een geruime tijd duren voordat alle reguliere browsers de javascript 6 standaard "grotendeels" implementeren, en waarschijnlijk nooit in zijn geheel.
Ja okay, maar er zit ook een gezonde wenningstijd in.
Het is altijd wel handig om het eerst onder de loep te nemen, voordat de beslissing echt genomen wordt.

Nu heb ik de laatste tijd niet echt actief met Javascript gewerkt.. maar voor mijn gevoel was er eigenlijk alleen een groot verschil met hoe asynchroon bepaalde zaken worden getriggert. (de ene browser kwam eerst bij punt A, de andere bij punt B ofzo)
Heb even geen voorbeeld daarvan, maar volgens mij was er ook nog een verschilletje in bubbling events (dus welk element je terug krijgt bij het afvuren van een element).

Ik kom uit de tijd van de IE PNG fix en alles, dus wat er nu staat.. lijkt allemaal een stuk beter.
Het is geen ding wat kan updaten, het ligt puur aan de browsers of die hun javascript engines hebben bijgewerkt.
en hoe worden de engines bij gewerkt, met updates.
doordat ie niet automatisch update
Daarmee leek je te zeggen dat het om een 'ding' ging, terwijl iedere browser zijn eigen engine heeft (ok, sommige hebben dezelfde)
Mooi dat het "Backwards" compatible is. Hoef je je bestaande scripts niet binnenkort aan te passen.
Echter zal 6.0 waarschijnlijk niet snel worden opgepakt. Immers wil je zoveel mogelijk browsers kunnen bedienen, dus zolang in ieder geval de grote browsers, IE, Safari, Firefox, Chrome niet allemaal 6.0 onder steunen zal het nog wel even duren voordat we echt de nieuwe functionaliteit kunnen gaan gebruiken.
Edge ondersteund het al voor 82%. Je zal er dus niet veel problemen mee hebben. Andere browsers hobbelen achter, maar ze komen er wel (Firefox zit op 66%).
Is een software pakket ooit klaar? Ik kan me herinneren dat Microsoft ooit hetzelfde heeft gezegd over Internet Explorer.... En kijk maar eens hoe dat nu gaat.
Netscape is er klaar mee ;)
Behalve dan dat de code daarvan aan de basis van firefox heeft gestaan.
Ja.. het was geen ideaal goed doordacht grapje.. hehe

Volgens mij hebben ze allemaal nog dingen van Netscape erin zitten.
Het is een standaard, geen software. Dus ja, die is klaar.

Nu gaan ze verder met ECMAScript 7.
What the heck moeten classes in ECMAScript?! Het hele mooie van ECMAScript was dat het een van de weinige talen is waar je objecten maakt i.p.v. classes; het is een echte object georiënteerde taal, waar de meeste talen die dat claimen eigenlijk klasse georiënteerd zijn.
EDIT: ik zie dat classes syntactic sugar voor objecten is, toch jammer dat het een beetje aavoelt als "erop geplakt omdat iedereen het wil hebben". Het voegt niets nieuws of beters toe aan de taal, het maakt het alleen minder uniform.

[Reactie gewijzigd door RoadRunner84 op 18 juni 2015 17:15]

What the heck moeten classes in ECMAScript
OOP vergemakkelijken.
Het hele mooie van ECMAScript was dat het een van de weinige talen is waar je objecten maakt i.p.v. classes
En dat is nonsens. In de meeste talen maak je objects, ook in talen als Java en C#. Het verschil komt vooral uit het typesysteem. Waar Java en C# class-based talen zijn waarbij elk object van een bepaalde class is, is Javascript een prototype-based taal waarbij elk object een prototype heeft waar hij eigenschappen van 'leent'.

Waar jij vooral op doelt is dat Javascript loose typed is, en je dus willekeurig properties aan objecten kunt toevoegen. Dat kan in bijvoorbeeld PHP ook. Het heeft weinig met classes of prototypes te maken, en meer met de strictheid van het typesysteem.

Het probleem is dat veel mensen toch geneigd zijn classes te definieren, en daarbij tooling gerbuiken die dmv prototypes toch een wat meer traditionele inheritance structuur opzetten. En dan loop je toch een beetje tegen de limitaties van het prototype-systeem aan. Classes faciliteren dit paradigma, terwijl ze niet indruisen tegen de prototype-aard van Javascript. Het is meer een vorm van syntactische suiker - hetzelfde effect kon je feitelijk al bereiken, maar dat kan nu een stuk makkelijker met wat taalconstructies. Het maakt je sourcecode leesbaarder en onderhoudbaarder. Onder water heeft een object van een bepaalde class nog steeds een prototype zoals je gewend bent. De hele klasse syntax zet dat simpelweg voor je op.

[Reactie gewijzigd door .oisyn op 18 juni 2015 17:25]

Mja, dat bedoel ik min of meer; de meeste talen gebruiken classes, en instantiëren die als objecten. JavaScript/ECMAScript kent (kende) dit gedachtengoed niet. Hte feit dat veel mensen ingesleten zijn en het in classes denken betekent niet dat dat de enige manier is om met objecten om te gaan.
Ik kom in mijn praktrijk bijna geen classes tegen waar ik veel instanties van heb (ofwel ze zitten in een array), het overgrote deel van mijn classes hebben maar één instantie, soms twee, en dan is dat ook nog vaak een globale instantie. In deze praktijk is het veel natuurlijker om objecten te bouwen, zonder de tussenstap van een on-geïnstantieerde variant in de vorm van een class.
Ook als ik graag "classes" heb, dan zijn die nooit ongeïnitialiseerd, dus waarom zou ik dan geen "default" or "empty" object hebben en die .clone()-en? Dat is feitelijk net zo ingewikkeld als een class new-en.
Het enige waar je wellicht tegenaan loopt is multiple inheritance, maar dat is sowieso een omstreden onderwerp.
JavaScript/ECMAScript kent (kende) dit gedachtengoed niet.
Zeker wel. Alleen zijn het prototypes, geen classes. En dat is nog steeds zo, een class in javascript is niets meer dan wat syntactische suiker om het opzetten van prototypes. Maar voorheen schreef men net zo goed prototypes en constructors.
Hte feit dat veel mensen ingesleten zijn en het in classes denken betekent niet dat dat de enige manier is om met objecten om te gaan.
Het feit dat het niet de énige manier wil niet zeggen dat een andere manier beter is. Het is echt niet zo dat classes uit de lucht zijn komen vallen. Er is vraag naar, véél vraag. Dat jij het niet gebruikt, prima, maar dat zegt nog niets over de rest van de wereld, noch dat het dus een slechte beslissing is om ze toe te voegen.

[Reactie gewijzigd door .oisyn op 19 juni 2015 14:31]

Een Class in JS is eigenlijk ook een Object, aangezien alles in JS eigenlijk een object is. Net als Function en Number ook objecten zijn, is een class dat ook. Het enige verschil tussen een Class en een normaal Object ({}) is dat je een instance kan aanroepen van een Class, die de constructor uitvoert. Dit is niet veel anders dan de workaround die voorheen gebruikt werd met behulp van de Prototype.

Zie hier als voorbeeld: http://www.es6fiddle.net/ib2cbfon/

[Reactie gewijzigd door anargeek op 18 juni 2015 17:28]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True