Microsoft komt met JavaScript-variant TypeScript
Microsoft geeft zijn uitgebreide JavaScript-variant TypeScript vrij onder een opensourcelicentie. TypeScript voegt ondersteuning voor optionele datatypen, klassen en modules toe aan de scripttaal, en werkt in bestaande JS-omgevingen.
Microsoft heeft een uitgebreide variant van JavaScript uitgebracht, genaamd TypeScript. Volgens de softwaregigant lost TypeScript een aantal problemen met JavaScript op, waardoor de scripttaal beter gebruikt kan worden voor applicatieontwikkeling. Zo voegt TypeScript ondersteuning toe voor optionele datatypen, klassen en modules.
TypeScript is geen nieuwe taal, maar zogeheten syntactische suiker, die het programmeren voor een ontwikkelaar makkelijker maakt. Hiermee lijkt het op CoffeeScript en Google Dart, die ook de mogelijkheden van JavaScript uitbreiden. De compiler maakt van TypeScript gewone JavaScript-code, die binnen browsers, Node.js en andere JavaScript-omgevingen zal werken. Verder zijn bestaande JavaScript-libraries aan te roepen vanuit TypeScript-code.
De specificaties van TypeScript zijn vrijgegeven onder de Open Web Foundation, terwijl Microsoft de broncode van de compiler beschikbaar heeft gesteld onder de Apache 2.0-licentie. Voor Visual Studio 2012 is er een plug-in, zodat features als refactoring en IntelliSense voor TypeScript-code beschikbaar zijn.
TypeScript en de resulterende JavaScript-code
Reacties (136)
Ben benieuwd of dit hetzelfde lot als google dart zal ondergaan. We hebben natuurlijk nog niet genoeg verschillende talen.
Dit is toch gewoon een extentie voor javascript net als JQuery?
jQuery is een library, geschreven in Javascript. Geen Javascript extensie. TypeScript is niet uit te voeren als Javascript, maar wel te compileren naar Javascript.
Het is natuurlijk niet de uiteindelijke taal, maar een taal die geinterpreteerd wordt, en JavaScript komt daar uit.
*gecompileerd, om de correcte technische term te gebruiken.
Compileren is het vertalen van taal X naar taal Y; TypeScript naar Javascript, bijvoorbeeld, maar ook C naar assembly.
Interpreteren is wat er met Javascript gebeurt in de browser, in de meeste gevallen, maar daar doen ze ook aan compileren naar een lagere taal in de geoptimaliseerde interpreters.
Compileren is het vertalen van taal X naar taal Y; TypeScript naar Javascript, bijvoorbeeld, maar ook C naar assembly.
Interpreteren is wat er met Javascript gebeurt in de browser, in de meeste gevallen, maar daar doen ze ook aan compileren naar een lagere taal in de geoptimaliseerde interpreters.
Als Visual Studio dat inderdaad doet is het natuurlijk een TypeScript compiler, maar dat kan ik niet helemaal opmaken uit het artikel. Taal naar taal is dacht ik niet perse een eigenschap die alleen voor compilers geldt.. het is een conversie (code naar compiled, bytecode of machinecode) die niet resulteert in gecompileerde code, maar in een andere niet-gecompileerde taal.
Heb je het artikel ook gelezen? Het resultaat is gewoon javascript code.
Verschil met Google Dart is dat er niet zo radicaal afstand genomen is van JavaScript, maar er juist verdergebouwd is op de nieuwe Ecma-definities.
Zoals Scott Hanselman het zegt: "In fact, it's a little like getting some of tomorrow's ECMAScript 6 early in a way that's compatible with today's JavaScript. ES6 won't be out for at least a year but we can play with some of those features today."
http://www.hanselman.com/blog/WhyDoesTypeScriptHaveBeTheAnswerToAnything.aspx
Zoals Scott Hanselman het zegt: "In fact, it's a little like getting some of tomorrow's ECMAScript 6 early in a way that's compatible with today's JavaScript. ES6 won't be out for at least a year but we can play with some of those features today."
http://www.hanselman.com/blog/WhyDoesTypeScriptHaveBeTheAnswerToAnything.aspx
[Reactie gewijzigd door vstrien op dinsdag 2 oktober 2012 14:55]
CoffeeScript is anders zeer populair.
Ik zie hier het praktisch nut ook niet van in.
Weer een nieuwe Microsoft-implementatie die meer regels vergt dan het origineel, en functionaliteit overneemt van reeds bestaande initiatieven zoals CoffeeScript, welke in tegenstelling tot TypeScript wel degelijk syntactic sugar bevordert.
Weer een nieuwe Microsoft-implementatie die meer regels vergt dan het origineel, en functionaliteit overneemt van reeds bestaande initiatieven zoals CoffeeScript, welke in tegenstelling tot TypeScript wel degelijk syntactic sugar bevordert.
Zoals ik dit zie is TypeScript toch wel een heel stuk fijner dan standaard javascript, komt de leesbaarheid aan de development kant alleen maar ten goede. Want tegenwoordig wordt er zoveel javascript gebruikt dat het hele browsers op hun knieen krijgt, en zeker op wat oudere computers..
Ik ben geen programmeur, maar is het niet inefficient dat Typescript 20 regels code nodig heeft terwijl Javascript er 'maar' 16 nodig heeft?? (Ok, Typescript heeft 3 lege regels erin zitten.. maar toch)
Aantal regels code heeft niet zoveel te betekenen. Duidelijkheid is belangrijker, evenals als wat het systeem ermee uitvoert als deze uitgevoerd word.
Hangt af van:Ik ben geen programmeur, maar is het niet inefficient dat Typescript 20 regels code nodig heeft terwijl Javascript er 'maar' 16 nodig heeft?? (Ok, Typescript heeft 3 lege regels erin zitten.. maar toch)
1) Of dit voor grotere stukken code ook geldt
2) Of de code leesbaarder en dus beter onderhoudbaar wordt
3) De nieuwe mogelijkheden die ontstaan
4) Hoeveel het meer is
5) ...
Meer is niet altijd slechter, maar inderdaad wel een klein minpuntje.
Hoezo is dat in dit geval een minpuntje? Een CR neemt net zo veel opslag of verwerkingstijd in beslag als een spatie.
In dit geval zal de code dus niet groter zijn, maar als het goed is wel leesbaarder.
In dit geval zal de code dus niet groter zijn, maar als het goed is wel leesbaarder.
Daarnaast wordt de code toch omgezet naar JavaScript, welke vervolgens weer geminimized kan worden.
Fout, in Windows neemt een lege regel twee keer zoveel opslag in als een spatie.Een CR neemt net zo veel opslag of verwerkingstijd in beslag als een spatie.
Dit is immers een Microsoft initiatief. In Linux en Unix(OSX) neemt het evenveel ruimte in als een spatie.
Windows: CR+LF (2 bytes)
Linux: LF (1 byte)
Unix: LF (1 byte)
OS<X: CR (1 byte)
Bron: https://en.wikipedia.org/wiki/Newline#Representations
[Reactie gewijzigd door Redsandro op dinsdag 2 oktober 2012 19:25]
Als de taal duidelijker / typesafe wordt en via compilatie fouten eruit kan halen dan weegt dat natuurlijk meer op dan dat een taal toevallig in die situatie 3 regeltjes minder nodig heeft.
Sowiezo is het eindresultaat altijd meer ge-optimaliseerd door de compileer slag dus het is niet zo dat een taal die meer verbose is er trager door wordt of dat er meer instructies nodig zijn om hetzelfde te bereiken (na compilatie)
Sowiezo is het eindresultaat altijd meer ge-optimaliseerd door de compileer slag dus het is niet zo dat een taal die meer verbose is er trager door wordt of dat er meer instructies nodig zijn om hetzelfde te bereiken (na compilatie)
4 lege regels dus het komt op hetzelfde neer.
Kan iemand me dan ook even uitleggen waarom er met een lege regel begonnen wordt? De eerste regel leeg laten maakt het niet overzichtelijker volgens mij. Dat er tussen door regels leeg staan kan ik wel zien dat het inderdaad dan overzichtelijker wordt...
Als ik mag gokken is dat gewoon een foutje van de persoon die het codevoorbeeld getypt heeft 
Het heeft verder geen enkele toegevoegde waarde. Sowieso hebben enters of spaties geen enkele waarde voor een compiler, die is net zo tevreden met alles op 1 regel aan elkaar geplakt
Het heeft verder geen enkele toegevoegde waarde. Sowieso hebben enters of spaties geen enkele waarde voor een compiler, die is net zo tevreden met alles op 1 regel aan elkaar geplakt python programmeurs zullen hier anders over denken, zie ook: http://en.wikipedia.org/wiki/Off-side_rule (met een lijst van andere talen waar dit ook (deels) voor opgaat)Sowieso hebben enters of spaties geen enkele waarde voor een compiler, die is net zo tevreden met alles op 1 regel aan elkaar geplakt
Het aangehaalde CoffeeScript hecht dus heel veel waarde aan whitespace. Hoever je inspringt bepaald de blokken die bij elkaar horen , zo besparen ze weer { } in CoffeeScript.
Ik moet zeggen dat ik dit TypeScript er een stuk leesbaarder uit ziet dan CoffeeScript. Dat lijkt er voornamelijk op gericht te zijn om zo weinig mogelijk te typen.
Ik moet zeggen dat ik dit TypeScript er een stuk leesbaarder uit ziet dan CoffeeScript. Dat lijkt er voornamelijk op gericht te zijn om zo weinig mogelijk te typen.
Beide hebben effectief 11 regels code, alleen andere syntax
Waar er bij TT 4 witte regels tussen zitten. -- Maar dat heb je inmiddels zelf ook gezien
[Reactie gewijzigd door xiD op dinsdag 2 oktober 2012 14:42]
Het eerste wat mij opvalt is dat in het TypeScript voorbeeld er op regels 1, 11, 13 en 19 alleen maar whitespace is. Verder zeggen LoC helemaal niets. Ook is het zo dat een compiler optimalisaties kan toevoegen in de compilatie naar JavaScript.
Dat is maar net hoe je het opstelt. Bovenstaande code kan ook in 6 regels. Maar voor de leesbaarheid van de code wordt dit uitgesmeerd over meerdere regels. Ook indenting is niet nodig maar verhoogd ook de leesbaarheid (mits goed toegepast natuurlijk).
Het schrijven van code gaat bijna altijd sneller en makkelijker dan het teruglezen, dus langer is niet per definitie slechter. Volgens mij wordt de TypeScript code ook "gecompiled" naar JavaScript; het lijkt mij dat er daar de nodige optimalisaties inzitten om de uiteindelijke bestandsgrootte wél te minimaliseren.
Edit: spuit 11
Edit: spuit 11
[Reactie gewijzigd door dvz89 op dinsdag 2 oktober 2012 14:45]
http://www.joelonsoftware.com/articles/fog0000000069.htmlIt’s harder to read code than to write it.
al weer meer dan 12 jaar oud
Weet niet of ik de rest van het artikel onderschrijf(weet niet meer precies wat er instaat en ik ben het nog al eens met hem oneens), maar dat is iig een belangrijke observatie.
Nee, je ziet links typescript wat wordt omgezet naar (rechts) javascript. Verder zegt de lengte van een stuk code niks over de efficiëntie.
TypeScript heeft 4 lege regels; ook regel 1 is leeg. Ze hebben allebei dus 16 regels code nodig voor hetzelfde. De laatste 7 hiervan zijn zelfs identiek. Sterker nog, als instance variabelen in TypeScript niet gedeclareerd zouden moeten worden zou regel 3 daar weg kunnen en heb je zelfs een regel minder.
En als je dan de eerste 9 regels met elkaar vergelijkt, dan vind ik TypeScript toch beter leesbaar. Vooral die })(); op regel 9 van het JavaScript blok vind ik maar niks. Ik weet wat het doet, maar toch.
En als je dan de eerste 9 regels met elkaar vergelijkt, dan vind ik TypeScript toch beter leesbaar. Vooral die })(); op regel 9 van het JavaScript blok vind ik maar niks. Ik weet wat het doet, maar toch.
Het heeft evenveel regels nodig ... regel 1 is bij Typescript ook leeg.
Het gebruik van klasses is toch wel wat properder en maakt het ontwikkelen toch ook wat gemakkelijker.
Ik als developer vind de code links (Typescript) ook iets logischer en leesbaarder.
Dat alleen al maakt ontwikkelen in Typescript mogelijk efficiënter - want vaak ben je als ontwikkelaar toch het meeste tijd kwijt met het interpreteren van code.
Het gebruik van klasses is toch wel wat properder en maakt het ontwikkelen toch ook wat gemakkelijker.
Ik als developer vind de code links (Typescript) ook iets logischer en leesbaarder.
Dat alleen al maakt ontwikkelen in Typescript mogelijk efficiënter - want vaak ben je als ontwikkelaar toch het meeste tijd kwijt met het interpreteren van code.
Soms is het handig als je overzicht hebt in plaats van weinig regels. Het is dus niet per definitie inefficient dat een taal meer regels code nodig heeft, als het met meer regels code dan ook maar overzichtelijker is.
Hoeveel karakters bepaalde code is maakt op zich niet veel uit. Het belangrijkste is dat code begrijpbaar is voor zoveel mogelijk mensen.
Er is een algemene tendens naar langere programmacode. In assembler (zeer oude taal) zijn de meeste programma's nog redelijk klein, en daarmee ook zeer performant. Maar deze programma's zijn dermate ingewikkeld dat bijvoorbeeld een moderne webbrowser volledig in assembler schrijven nagenoeg onmogelijk is.
Iets nieuwere programmeertalen zoals C zijn al wat leesbaarder, maar de programmacode is ook langer. Als we dan naar de nog nieuwere talen gaan, bijvoorbeeld het objectgeörienteerde Java, zien we dat de code weer langer wordt, maar weeral eenvoudiger te begrijpen (of dit zou toch moeten).
Met de steeds beter wordende ontwikkelomgevingen betekent het trouwens niet dat de programmeur meer moet typen, want de ontwikkelomgeving kan bepaalde structuren (bijvoorbeeld een lege klasse) zelf aanmaken. Samen met de meer begrijpbare code zorgt dit ervoor dat programma's steeds sneller en met minder fouten gemaakt kunnen worden.
Deze laatste 2 factoren worden dan weer tegengewerkt doordat programma's steeds meer moeten kunnen. Hierdoor wordt de ontwikkeltijd langer en het aantal fouten groter, maar als er enkel met verouderde programmeertalen werd gewerkt zou het aantal bugs waarschijnlijk nog veel hoger liggen, en de projecten nog een veelvoud langer duren.
Er is een algemene tendens naar langere programmacode. In assembler (zeer oude taal) zijn de meeste programma's nog redelijk klein, en daarmee ook zeer performant. Maar deze programma's zijn dermate ingewikkeld dat bijvoorbeeld een moderne webbrowser volledig in assembler schrijven nagenoeg onmogelijk is.
Iets nieuwere programmeertalen zoals C zijn al wat leesbaarder, maar de programmacode is ook langer. Als we dan naar de nog nieuwere talen gaan, bijvoorbeeld het objectgeörienteerde Java, zien we dat de code weer langer wordt, maar weeral eenvoudiger te begrijpen (of dit zou toch moeten).
Met de steeds beter wordende ontwikkelomgevingen betekent het trouwens niet dat de programmeur meer moet typen, want de ontwikkelomgeving kan bepaalde structuren (bijvoorbeeld een lege klasse) zelf aanmaken. Samen met de meer begrijpbare code zorgt dit ervoor dat programma's steeds sneller en met minder fouten gemaakt kunnen worden.
Deze laatste 2 factoren worden dan weer tegengewerkt doordat programma's steeds meer moeten kunnen. Hierdoor wordt de ontwikkeltijd langer en het aantal fouten groter, maar als er enkel met verouderde programmeertalen werd gewerkt zou het aantal bugs waarschijnlijk nog veel hoger liggen, en de projecten nog een veelvoud langer duren.
Is het niet net omgekeerd ? Hoe hoger de abstractie van een programmeerteel hoe minder lijnen code je nodig hebt om hetzelfde te doen ... Het is inderdaad wel zo dat oudere software vaak minder moest doen en daardoor ook minder lijnen code had.
Je kan wel abstract dingen programmeren, maar er komt een punt dat je concreet moet worden. Als je dan alles bijelkaar optelt kom je (effectief) op meer code uit. Het doel van abstract programeren is dat het begrijpelijk is maar dat het ook mogelijk maakt om Design Patterns toe te passen zodat de structuur efficient en modulair word opgebouwd.
Helaas zit JavaScript niet lekker in mijn maag aangezien het geen volwaardig object georienteerde taal is. Het is namelijk een prototype language. TypeScript maakt een goede stap in de richting, maar ik twijfel of het echt gaat aanslaan. Het grote gros eindgebruikers hebben JavaScript ik weet niet of TypeScript backwards compatible is met JavaScript. Daarnaast hoop ik niet dat ze (aangezien het van Mircosoft komt) JScript gebruikt hebben, dit is namelijk niet 1 op 1 gelijk aan JavaScript.
Helaas zit JavaScript niet lekker in mijn maag aangezien het geen volwaardig object georienteerde taal is. Het is namelijk een prototype language. TypeScript maakt een goede stap in de richting, maar ik twijfel of het echt gaat aanslaan. Het grote gros eindgebruikers hebben JavaScript ik weet niet of TypeScript backwards compatible is met JavaScript. Daarnaast hoop ik niet dat ze (aangezien het van Mircosoft komt) JScript gebruikt hebben, dit is namelijk niet 1 op 1 gelijk aan JavaScript.
TypeScript compileert naar JavaScript, dus het eindresultaat is 100% compatible (of zou dat tenminste moeten zijn).... ik weet niet of TypeScript backwards compatible is met JavaScript
De opbouw en syntax die TypeScript (en alternatieven) hanteert is voor een doorsnee developer makkelijker te begrijpen omdat het een Object Oriented syntax aanbied die veel overeenkomsten heeft met de andere gangbare WEB talen (PHP, Java, C#, etc) en wat ontbreekt in JavaScript. In native JavaScript moet dat via een lastiger variabele definitie ( var MyClass = (function() { .... } )(); ) wat syntactisch totaal niet lijkt op wat je gewend bent in andere talen, en daarmee het ontwikkelen in JavaScript voor veel mensen lastig maakt (om maar over scope lastigheden te zwijgen).
Vaak kunnen in teams niet alle mensen goed uit de voeten met JavaScript. Typescript (en alternatieven) verlagen dus de drempel van de vaak lastige JavaScript instap (zie ik ook regelmatig in mijn omgeving), het verbetert daarnaast ook de leesbaarheid en daarmee de onderhoudbaarheid.
Er is dus zeker wat voor te zeggen, het is alleen jammer dat het altijd moet worden gecompileerd naar JavaScript wat dus ook lastigheden met zich mee kan brengen voor automatische builds en/of deployments.
[Reactie gewijzigd door 4np op zaterdag 6 oktober 2012 23:19]
Dat er echte classes geschreven kunnen worden is een huge improvement. Ik neem die paar extra regels op de koop toe.
Dat er 'echte classes' geschreven kunnen worden getuigt puur van het willen faciliteren van luie programeurs. Mannetjes die op school Java hebben geleerd en willen dat alle talen zo als Java gaan werken, in plaats van dat ze leren dat dingen in andere talen nou eenmaal anders werken. In JavaScript moet je leren werken met lexical scoping en prototypal inheritance en anonymous functions, zodra je dat in de vingers hebt dan mis je 'echte classes' echt niet meer. Het zelfde geld bijvoorbeeld voor C++, daar lopen die zelfde luie gasten vaak te zeuren dat C++ geen garbage collection heeft zonder dat ze bijvoorbeeld de moeite hebben willen nemen om RAII te leren, of dat C++ echt niet zo veel sneller is dan Java zonder dat ze ook maar een blik hebben willen werpen op TMP.
JavaScript draagt een hele berg hystorische slechte keuzes met zich mee, maar zoals Douglas Crockford in z'n briljante kleine boekje laat zien zit er een elegant klein taaltje onder een grote stapel puin. Static typing voor JavaScript zou hardstikke mooi zijn, tuurlijk, maar met 'echte classes' maak je de stapel puin alleen maar groter. JavaScript moet vooral ontdaan worden van z'n 'bad parts' zoals Douglas ze noemt. Voeg daar een klein beetje static typing bij voor de smaak en je bent een heel end op weg. Mischien kunnen we daarna dan eens kijken naar het 'echte' probleem met JavaScript: het hersendode DOM, daar moet absoluut met niet al te veel moeite een veel betere vervangende API voor te maken zijn.
JavaScript draagt een hele berg hystorische slechte keuzes met zich mee, maar zoals Douglas Crockford in z'n briljante kleine boekje laat zien zit er een elegant klein taaltje onder een grote stapel puin. Static typing voor JavaScript zou hardstikke mooi zijn, tuurlijk, maar met 'echte classes' maak je de stapel puin alleen maar groter. JavaScript moet vooral ontdaan worden van z'n 'bad parts' zoals Douglas ze noemt. Voeg daar een klein beetje static typing bij voor de smaak en je bent een heel end op weg. Mischien kunnen we daarna dan eens kijken naar het 'echte' probleem met JavaScript: het hersendode DOM, daar moet absoluut met niet al te veel moeite een veel betere vervangende API voor te maken zijn.
Sorry hoor maar het afkraken van object georienteerde talen vind ik totaal niet op zijn plaats. Ik ben er mee eens dat er luie programmeurs onder ons zijn, maar ik vind dit echt poggen van "kijk mij eens goed zijn in JavaScript". Ik vind OOP prettig programmeren puur om het feit dat het overzichterlijker is(dus ook makkelijker uit te leggen is aan anderen denk aan FO's en TO's) en eenvoudiger is om design patterns op toe te passen. Naast dit feit is OOP universeler, zodat ik ook bijvoorbeeld eenvoudig op andere OOP talen kan overschakkelen zonder allerlei ingewikkelde workarrounds. Want dit kost tijd, en tijd is kostbaar binnen een bedrijf en dat is != aan een luie werknemer.
By Typescript zijn er witregels gebruikt, bij Javascript niet.
achja joh, het feit dat er al een interpreted language gebruikt wordt en bijna alles via XML gaat, dan maakt die extra lege regeltjes ook niet meer uit hoor..
Choices choices... Javascript, Coffeescript, Dart, Typescript... 
Gebruikte tot nu toe coffeescript maar ik miste support voor interfaces en modules.
Doordat typescript optionele type-checking heeft kunnen de tools ook betere autocomplete en refactorings leveren.
De syntax ligt ook sterker bij de C familie van talen dan bij het whitespace gevoelige coffeescript. (deze laatste komt uit de ruby of python wereld dacht ik)
Een groot voordeel van modules is ook dat de google closure compiler veel beter kan optimaliseren zodat je javascript code compacter wordt.
Doordat typescript optionele type-checking heeft kunnen de tools ook betere autocomplete en refactorings leveren.
De syntax ligt ook sterker bij de C familie van talen dan bij het whitespace gevoelige coffeescript. (deze laatste komt uit de ruby of python wereld dacht ik)
Een groot voordeel van modules is ook dat de google closure compiler veel beter kan optimaliseren zodat je javascript code compacter wordt.
Als je naar modules in js wilt dan is requirejs waarschijnlijk interresant voor je. Requirejs modules in combinatie met coffeescript gebruiken we om heel complexe js structuren te bouwen.
Je kunt een switch meegeven aan de TypeScript compiler waardoor deze de module syntax niet emit als CommonJS modules à la NodeJS, maar als Asynchronous Module Definitions (AMD), waar o.a. RequireJS mee werkt.
TypeScript en RequireJS complementeert elkaar dus perfect. (Het wordt in de project forums zelfs aangeraden om TypeScript te gebruiken i.c.m. met RequireJS als AMD loader.)
TypeScript en RequireJS complementeert elkaar dus perfect. (Het wordt in de project forums zelfs aangeraden om TypeScript te gebruiken i.c.m. met RequireJS als AMD loader.)
Valt mee hoor, gewoon bij javascript blijven. We gebruiken het al jaren voor complexe webapplicaties en is - zeker in combinatie met jQuery - superkrachtig en goed leesbaar mits je je code en conventies helder opzet.
Ik begrijp die extra layers als Coffeescript en Typescript niet goed. Ook daar kan je onleesbare code mee schrijven, en het heeft weer een extra slag nodig (compilen naar javascript).
Ik begrijp die extra layers als Coffeescript en Typescript niet goed. Ook daar kan je onleesbare code mee schrijven, en het heeft weer een extra slag nodig (compilen naar javascript).
Dan begrijp je niet wat typesafety überhaupt voor voordeel heeft. Het stelt je in staat bepaalde fouten veel sneller op te sporen omdat ze bij het compileren al naar boven komen en niet pas als de code daadwerkelijk wordt uitgevoerd. Daarnaast heeft het ook een documenterende werking - iedereen die de code leest weet direct wat voor type een variabele is of wat een functie verwacht of teruggeeft. Tevens kunnen statische analyse tools de code veel beter snappen (inclusief de IDE die je kan helpen met autocompletion en dat soort zaken).Ik begrijp die extra layers als Coffeescript en Typescript niet goed
En alle libraries ten spijt, de traditionele vorm van OO met classes en interfaces is gewoon veel makkelijker te doen met een taal die dat ondersteunt. Natuurlijk is het te simuleren in pure javascript met behulp van prototypes (die op zichzelf dan ook best krachtig zijn), maar iedereen doet het op een andere manier en heel vrolijk wordt je er niet van.
[Reactie gewijzigd door .oisyn op dinsdag 2 oktober 2012 15:58]
Nu nog een debugger waarmee je door TypeScript heen kan stappen. Die gaat er niet komen, zeker niet in firefox en chrome... zit je uiteindelijk toc tegen javascript aan te kijken. Nee bedankt.
Die bijna 1 op 1 overeenkomt met je huidige code. Je overdrijft enorm als je stelt dat dit een serieuze hindernis is.zit je uiteindelijk toc tegen javascript aan te kijken
Ik zit vaak zat naar assembly te kijken als de optimizer weinig debug informatie heeft overgelaten van mijn C++ code. Een wereld van verschil. Maar is dat een reden om dan maar geen C++ code te gebruiken en meteen maar assembly in te typen? Absoluut niet, omdat je in C++ 100.000 keer zo productief bent.
Nou zijn de contrasten tussen JS en TS een stuk kleiner, maar tegelijkertijd maakt het het debuggen ook een stuk makkelijker. Ik vind derhalve dat je bazelt.
[Reactie gewijzigd door .oisyn op dinsdag 2 oktober 2012 17:21]
Mijn verwachting van MS en VS2012 is dat dit debuggen van TypeScript met de VS2012 debugger attached aan IE10 zal zijn. Ik debug al mijn js met IE 9 en VS2010 en dat werkt in de praktijk heel erg fijn, zeker als je serverside met Asp.Net werkt.
Ik weet wel zeker dat ie gaat komen, in ieder geval voor Visual Studio icm IE. Reken maar dat Microsoft er eentje gaat schrijven. Anders Helsbjerg (lead dev C#) gaf aan laatst aan dergelijke tools te werken. Nu TypeScript er is, is het wel duidelijk hoe dit vorm gaat krijgen.Die gaat er niet komen, zeker niet in firefox en chrome...
Daarnaast zorgen sourcemaps ervoor dat ook talen waarvan JS is gecompiled kunnen worden gemapped naar hun originele code. Hiermee kan er multilanguage support komen in browsers. De mogelijkheid dat Firefox uiteindelijk Dart, TypeScript, CoffeeScript, EcmaScript6 (JS.Next) en hun eigen Opa gaat supporten lijkt me ook niet onrealistisch. Wellicht eerst met een eigen transpiler, later misschien met een native VM implementatie.
Maarja, dat laatste is dus in the eye of the beholder, want wat JIJ misschien helder van opzet vindt wil nog zeker niet zeggen dat dat ook voor een ander geldt, en als ik zo rondkijk in de praktijk hebben veel mensen hele andere ideeen over wat helder is..superkrachtig en goed leesbaar mits je je code en conventies helder opzet.
Ik gebruik persoonlijk Coffeescript. Ik snap dat sommige mensen liever javascript gebruiken maar ik zie wel duidelijk voordelen met Coffeescript en kan nu ook veel sneller programmeren met javascript.
Voorbeeldje(spaties zijn eruit gefilterd dus het ziet er een beetje raar uit):
CoffeeScript:
Ook vind ik typescript er ook wat beter uit zien dan javascript en zie er de voordelen wel in.
Voorbeeldje(spaties zijn eruit gefilterd dus het ziet er een beetje raar uit):
CoffeeScript:
javascript:class Person
constructor: (name)->
@name = name
hello: ->
if @name?
console.log("#{@name} says hello!")
Ik persoonlijk vind Coffeescript een stuk makkelijker, maar ik snap wel dat er ook een aantal haters zijn, maar dat is ook gewoon persoonlijke smaak.var Person;
Person = (function() {
function Person(name) {
this.name = name;
}
Person.prototype.hello = function() {
if (this.name != null) {
return console.log(this.name + " says hello!");
}
};
return Person;
})();
Ook vind ik typescript er ook wat beter uit zien dan javascript en zie er de voordelen wel in.
[Reactie gewijzigd door mokkol op dinsdag 2 oktober 2012 15:45]
tja, en als ik zo bekijk wat je aan coffeescript hebt staan denk ik 'wtf, das verre van duidelijk'.. maar zoals ik al hierboven ergens anders heb aangegeven, 'helder' is in the eye of the beholder, ofwel wat jij duidelijk vindt hoeft een ander zeker niet zo te vinden..
Maar de javascript ziet er ook allerminst duidelijk uit.. TypeScript zou meer mijn voorkeur hebben dan..
Maar de javascript ziet er ook allerminst duidelijk uit.. TypeScript zou meer mijn voorkeur hebben dan..
Ja je moet de spaties er even bijdenken... Jammer dat je geen code blokken kan toevoegen (of misschien ook wel maar weet niet hoe)
Ziet er niet slecht uit behalve dat we zoals het artikel zegt al CoffeeScript en Google Dart hebben. Op welk vlak verschilt TypeScript hier dan mee ?
compatibiliteit met JS
maarja, je kunt dan ook stellen dat zowel CoffeeScript als Google Dart ook overbodig zijn...
Ziet er netjes uit.
Je hebt overzicht en daardoor maakt het je makkelijker.
Je hebt overzicht en daardoor maakt het je makkelijker.
Is dit nu een compiler voor JavaScript (of ECMAScript) of gaan we hier per se IE10 voor moeten gebruiken?
De compiler compileert typescript naar javascript. De output is dus gewoon javascript. Geen IE10 nodig gewoon een browser met javascript support.
Artikel gelezen? Daar staat in de de compiler open source is, en dus geport kan worden naar andere browsers.
Net scripts eens doorgekeken. Heel overzichtelijk en makkelijk de compile. Zit er daarom toch eens over te denken om het te gaan gebruiken.
Als ik het voorbeeld bekijk zie ik niet echt het voordeel hiervan, behalve dat het meer op andere talen lijkt (syntax). Als programmeur moet de oude variant toch geen probleem zijn.
Ik zag Coffeescript populair worden, blijkbaar is er nog een "concurrent" op de markt 
Ziet er aardig uit, maar waarom staat (in tegenstelling tot de meeste talen) het type rechts van de variabelnaam?
Ik denk dat dit is omdat ze TypeScript zoveel mogelijk willen laten lijken op JavaScript (eigenlijk ECMAScript, voor de kenners), waarin het enige type 'var' is. Door deze manier van schrijven lijkt het onderscheid duidelijker tussen directe variabele en de intelligente datatype-laag eroverheen.Ziet er aardig uit, maar waarom staat (in tegenstelling tot de meeste talen) het type rechts van de variabelnaam?
Overigens ben ik het wel met je eens: het ziet er gek uit in verhouding met de norm.
[Reactie gewijzigd door The Zep Man op dinsdag 2 oktober 2012 17:11]
Uhmm.. Nee?[...]
Ik denk dat dit is omdat ze TypeScript zoveel mogelijk willen laten lijken op JavaScript (eigenlijk ECMAScript, voor de kenners), waarin het enige type 'var' is.
'var' is een keyword wat een variable declaratie aangeeft. Evenals het nieuwere 'let' en 'const' keywords zijn om variables en constantes te declararen.
De identifier-colon-type (bijv 'var x:Number') notatie stamt al uit de drafts van de oude ECMAScript v4 specificatie. De 'powers that be' werden het echter intern nooit eens over belangrijke delen van de specificatie en dus is deze een vroegtijdigde dood gestorven. (Vandaar dat JavaScript nu van het stokoude ECMAScript v3 met veel moeite naar v5 aan het transitioneren is terwijl v6 al in de schaduw klaar staat.)
De enige partij die een breed gedragen ECMAScript v4 implementatie heeft geproduceerd is Adobe. We hebben het dan over ActionScript v2 en ActionScript v3, welke de type system syntax, class & interface syntax (incl. scope modifiers) van ECMAScript v4 allemaal aan boord hebben.
Bijna exact dezelfde syntax die nu ten dele door Microsoft in TypeScript gehanteerd wordt en ten dele in de officiële ECMAScript v6 'Harmony' / JS.Next specificaties terug te vinden is.
Alleen al hierom heeft TypeScript een veel grotere kans van slagen dan Google's initiatieven Dart en Go: het is niet alleen backwards compatible met bestaande JavaScript code, maar ook forward compatible met de officiële JS.Next standaard in wording.
[Reactie gewijzigd door R4gnax op dinsdag 2 oktober 2012 22:10]
Dat vroeg ik me ook al af. In volgens mij praktisch elke andere (veelgebruikte) static typed programmeertaal staat de type aanduiding links. Hier moet het weer anders. Vind het ook niet bevorderlijk voor de leesbaarheid eerlijk gezegd.
Het is een trend: zo ook bij andere nieuwe talen: Go, F#, Scala.. etc
maar wat oudere gebeurde het ook al: Ada, Pascal, .. etc
zelf ben ik geen fan
maar wat oudere gebeurde het ook al: Ada, Pascal, .. etc
zelf ben ik geen fan
Nu weet ik niet de exacte beweegredenen, maar functionele talen als ML, Haskell en F# hebben het type rechts van de definitie en expressie staan. De volgende regel...
...wordt gelezen als:(a + b) : Int
Ook in de wiskunde wordt deze notatie gebruikt. Neem bijv. deze functie:De expressie (a+b) heeft het type Int
Om het domein en codomein van deze functie aan te duiden gebruiken wiskundigen een notatie als:f(x, y) = 3x^2 + y
Nu heb ik me nog niet verdiept in TypeScript, dus ik weet niet of het volgende ook voor TypeScript geldt, maar in talen als ML/Haskell worden ingewikkeldere functietypes duidelijker. Neem de volgende methode uit de .NET library geschreven in semi-C# syntax:f : R x R -> R
En vergelijk dit met een Haskell-like syntax waarin types aan de rechterkant staan:List<B> SelectMany<A,B>(this List<A> list, Func<A,List<B>> func);
selectMany :: List a -> (a -> List b) -> List b
Het is maar wat je zelf duidelijker vindt, persoonlijk vindt ik dit dus duidelijker (eerst variabele naam en daarachter pas wat voor type het is).. Enuh, meeste talen? denk eerder dat het 50/50 is.. Zelf ben ik het gewend van cobol,turbo/visual/whatever basic, pascal/delphi, unrealscript.. Het is maar gewoon wat je gewend bent, ben je c gewend dan wil je het links ben je..
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
