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)

[w3news]

Als ik het goed begrijp, is het een uitbreiding op visual studio, en via node.js kun je het ook gebruiken.
In visual studio zet de visual studio het weer om in javascript, wat je weer in de website gebruikt.
Als je in de browser debugger gaat kijken zie je gewoon javascript, wat volgens mij juist weer enorm irritant is, omdat je dan toch de gewone javascript methode moet kennen.
Laat Microsoft eens tijd besteden in een goede javascript console en foutafhandeling in de browser, en dit soort dingen moet via de ecma geregeld worden.

[masterpoi]

Zit er sinds IE 8.0 toch gewoon in? Al eens F12 gedrukt?

[w3news]

Ik weet het, maar dat werkt lang zo fijn niet als in bijvoorbeeld Chrome.
Verder zijn foutmeldingen in IE nog erg vaag.

[A27]

Hahahahaha, heb je hem al eens gebruikt?

[masterpoi]

Ben je gek? Firebug FTW!

Maar goed uiteindelijk kan je er wel hetzelfde mee, tenminste als je de eigenaardigheden weet te "omzeilen".

[w3news]

Ik kwam laatst een foutmelding tegen in IE, en de foutmelding kwam niet voor in andere browsers. Ik moest dus wel IE gebruiken om te achterhalen wat er fout ging. Het was overigens een vreemde melding, en er stond geen regelnummer die verwees naar een functie in een javascript bestand waar het verkeerd zou gaan. Op dat moment wil je het liefst IE omzeilen

[Verwijderd]

Ik vind juist firebug crap, en gebruik juist chrome of ie.
Chrome vind ik wat fijner voor html. omdat je makkelijker css kunt aanpassen.
En ie is soms fijner voor javascript

[robertpNL]

TypeScript is een superset op Javascript lees ik op de weblog van Hanselman. Het verbergt Javascript niet (wat CoffeeScript wel doet) of werkt alleen wanneer de browser dit ondersteund (Dart). Ontwikkelaar Ward Bell heeft hierover gezegd: "TypeScript is not a crutch any more than JSLint is a crutch. It doesn’t hide JavaScript (as CoffeeScript tends to do). - Ward Bell"

Andere ontwikkelaar vergelijkt TypeScript en CoffeeScript als volgt: "CoffeeScript is to Ruby as TypeScript is to Java/C#/C++." - Luke Hoban.

Ander voordeel van TypeScript is de combinatie met Visual Studio. Je kan makkelijk in code refactoren, references in één keer veranderen, rode waarschuwing-golfjes etc. Voor CoffeeScript moet je eigenlijk in een aparte tool ontwikkelen (of heb ik wat gemist?)

[masterpoi]

Ik zit nog altijd te duimen dat er CoffeeScript support komt voor resharper:

Go vote zou ik zeggen !

http://youtrack.jetbrains.com/issue/RSRP-272988

[DigitalExorcist]

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)

[Giesber]

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.

[Beretta1979]

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.

[Brawler1986]

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.

[Verwijderd]

... ik weet niet of TypeScript backwards compatible is met JavaScript

TypeScript compileert naar JavaScript, dus het eindresultaat is 100% compatible (of zou dat tenminste moeten zijn).

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 Verwijderd op 24 juli 2024 01:38]

[ritsjoena]

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)

Hangt af van:
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.

[Verwijderd]

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.

[Brian]

Daarnaast wordt de code toch omgezet naar JavaScript, welke vervolgens weer geminimized kan worden.

[Sando]

Een CR neemt net zo veel opslag of verwerkingstijd in beslag als een spatie.

Fout, in Windows neemt een lege regel twee keer zoveel opslag in 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 Sando op 24 juli 2024 01:38]

[Reboot]

4 lege regels dus het komt op hetzelfde neer.

[DaDolce]

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...

[Haan]

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

[Mr_Light]

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)

[PuzzleSolver]

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.

[dvz89]

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

[Reactie gewijzigd door dvz89 op 24 juli 2024 01:38]

[Mr_Light]

It’s harder to read code than to write it.

http://www.joelonsoftware.com/articles/fog0000000069.html

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.

[ro8in]

Dat er echte classes geschreven kunnen worden is een huge improvement. Ik neem die paar extra regels op de koop toe.

[pibara]

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.

[Brawler1986]

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.

[Cambion Daystar]

Aantal regels code heeft niet zoveel te betekenen. Duidelijkheid is belangrijker, evenals als wat het systeem ermee uitvoert als deze uitgevoerd word.

[ronaldmathies]

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)

[Perryv]

Beide hebben effectief 11 regels code, alleen andere syntax

[xiD]

Waar er bij TT 4 witte regels tussen zitten. -- Maar dat heb je inmiddels zelf ook gezien

[Reactie gewijzigd door xiD op 24 juli 2024 01:38]

[the_shadow]

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.

[swemmela]

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).

[L-VIS]

Nee, je ziet links typescript wat wordt omgezet naar (rechts) javascript. Verder zegt de lengte van een stuk code niks over de efficiëntie.

[Robtimus]

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.

[chime]

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.

[Br4mmie]

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.

[Loller1]

By Typescript zijn er witregels gebruikt, bij Javascript niet.

[SuperDre]

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..

[chao5]

Ziet er aardig uit, maar waarom staat (in tegenstelling tot de meeste talen) het type rechts van de variabelnaam?

[RayNbow]

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...

(a + b) : Int

...wordt gelezen als:

De expressie (a+b) heeft het type Int

Ook in de wiskunde wordt deze notatie gebruikt. Neem bijv. deze functie:

f(x, y) = 3x^2 + y

Om het domein en codomein van deze functie aan te duiden gebruiken wiskundigen een notatie als:

f : R x R -> R

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:

List<B> SelectMany<A,B>(this List<A> list, Func<A,List<B>> func);

En vergelijk dit met een Haskell-like syntax waarin types aan de rechterkant staan:

selectMany :: List a -> (a -> List b) -> List b

[The Zep Man]

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.

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 24 juli 2024 01:38]

[R4gnax]

[...]
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.

Uhmm.. Nee?

'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 22 juli 2024 22:52]

[Flowmo]

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.

[Mr_Light]

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

[SuperDre]

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..

[Flowmo]

Choices choices... Javascript, Coffeescript, Dart, Typescript...

[masterpoi]

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.

[bartsidee]

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.

[R4gnax]

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.)

[Verwijderd]

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).

[.oisyn]

Ik begrijp die extra layers als Coffeescript en Typescript niet goed

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).

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 24 juli 2024 01:38]

[A27]

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.

[.oisyn]

zit je uiteindelijk toc tegen javascript aan te kijken

Die bijna 1 op 1 overeenkomt met je huidige code. Je overdrijft enorm als je stelt dat dit een serieuze hindernis is.

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 24 juli 2024 01:38]

[PeaceNlove]

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.

[Ruudjah]

Die gaat er niet komen, zeker niet in firefox en chrome...

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.

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.

[SuperDre]

superkrachtig en goed leesbaar mits je je code en conventies helder opzet.

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..

[mokkol]

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:

class Person

constructor: (name)->
@name = name

hello: ->
if @name?
console.log("#{@name} says hello!")

javascript:

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;

})();

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.

Ook vind ik typescript er ook wat beter uit zien dan javascript en zie er de voordelen wel in.

[Reactie gewijzigd door mokkol op 24 juli 2024 01:38]

[SuperDre]

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..

[mokkol]

Ja je moet de spaties er even bijdenken... Jammer dat je geen code blokken kan toevoegen (of misschien ook wel maar weet niet hoe)

[Verwijderd]

Ik denk dat de belangrijkste vraag hier noch gesteld noch beantwoord is: Krijgt IE10/11 native ondersteuning voor TypeScript of blijft het iets dat zich enkel in de IDE manifesteerd.
Indien die native support er komt, dan beschouw ik dit wederom als een gevalletje Embrace, extend and extinguish.
Indien dit niet het geval is dan is het alleen relevant voor Visual Studio devs, neem aan dat MS geen Eclipse of Netbean plugins gaat ontwikkelen.

[masterpoi]

So how does TypeScript work? All you have to understand for this article (and I'll do another that looks into the mechanics) is that TypeScript is a superset of JavaScript that lets developers add strong-typing and OO. It's designed to be very sympathetic to JavaScript - there's no attempt to replace, or subsume the language. It's not an "extend, embrace, and extinguish" strategy. It's solely designed to move the story on.

At its most basic, it's just "syntactic sugar". Sprinkle it onto common or garden JavaScript and you'll get code that's easier to read and easier to work with on larger projects.

http://www.zdnet.com/micr...of-javascript-7000005054/

[Verwijderd]

Fijn, maar dat beantwoord mijn vraag niet. Komt er native support in IE? De 'daad' vertelt mij meer dan het 'woord'.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 01:38]

[masterpoi]

Zelfs als dat er zou komen (wat compleet geen steek houdt gezien EcmaScript 6.0 er ooit wel eens aankomt, en waar dus TypeScript op gebaseerd is), wat maakt dat uit?
IE heeft toch al lang geen 90% "marktaandeel" meer?

Eigenlijk kan je het dan nog het best vergelijken met de vender specifieke prefixes die we nu al een tijdje kennen in CSS bvb.

-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
-ms-box-sizing: border-box;
-o-box-sizing: border-box;
box-sizing: border-box;

[Reactie gewijzigd door masterpoi op 24 juli 2024 01:38]

[masterpoi]

En hier (basic) support voor emacs, vim en sublime text:

http://blogs.msdn.com/b/i...s-typescript-enabled.aspx

Maar volgens Miguel de Icaza is er nog werk aan de winkel:

http://tirania.org/blog/archive/2012/Oct-01.html

[hackerhater]

Persoonlijk hoe het zo uitziet heb ik iets van : voorleggen aan de standaardrisatie commissies!

klassen is een enorm gemis in javascript. Ja ik weet dat je sort of klassen kan maken, maar als dingen als private ed beschikbaar worden zal ik heel happy zijn.

[TimmiX]

Ik zie het nut er niet zo van in. Jammer dat er zoveel tijd wordt gestoken in een 'product' dat al bestaat. Hadden ze beter de tijd kunnen gebruiken om javascript door te ontwikkelen of zoals jQuery een library te maken.

Denk niet dat dit heel veel gebruikt gaat worden. Iedereen is nu al gewend om JS te gebruiken, waarom zou je overstappen?

[Reactie gewijzigd door TimmiX op 24 juli 2024 01:38]

[Haan]

Als iedereen zo'n instelling had gehad, hadden we nu nog allemaal in MS-DOS zitten werken. .
Aan de reacties hier te zien, snappen de meeste lezers niet wat TypeScript precies is. Het is GEEN opvolger/vervanger/uitbreiding van Javascript, het is syntactic sugar bovenop Javascript, wat het makkelijker zou moeten maken om complexe Javascript code te schrijven (ik heb het zelf nog niet uitgeprobeerd). Blijkbaar is de term syntactic sugar niet zo bekend, dus: http://en.wikipedia.org/wiki/Syntactic_sugar . De output van wat je in TypeScript schrijft, is gewoon Javascript.
Het voorbeeld dat onder het artikel staat is maar een simpel "Hello World" voorbeeld, de echte kracht van TypeScript zal je pas merken als je complexe code gaat schrijven.

[Reactie gewijzigd door Haan op 24 juli 2024 01:38]

[masterpoi]

Tja als als MS JavaScript doorontwikkelt en dan tegen de rest van de wereld zegt "kijk, dit is het nu!", wat denk je dat dan de reacties gaan zijn?

Er zijn gewoon features die door vele programmeurs in JavaScript gemist worden. Die zullen er ooit wel eens officieel in de standaard komen en als dan ook de huidige browsers uitgefaseerd zijn zullen we die misschien ook nog binnen 10 jaar kunnen gebruiken.

Ondertussen is er vandaag TypeScript, Dart, CoffeeScript ea. die het leven aangenamer maken voor vele professionele developers.

[mokkol]

en CoffeeScript is echt heel populair geworden. Dus het 'wennen' kan snel gaan.

[Gamebuster]

Het nadeel van dit soort dingen si dat het altijd extra moeite meebrengt met debuggen. Probeer maar eens gecompileerde code te debuggen als je stacktraces van de browser doorloopt.

Zolang browsers niet native zo'n taal ondersteunen zie ik geen rede om het te gebruiken. Doe mij maar vanilla javascript. Ik denk er zelfs aan om het eens zonder jQuery te proberen: De verschillen tussen browsers wordt kleiner en veel jQuery features die browser-incompatibiliteit dekte zijn inmiddels gedekt.

[.oisyn]

Probeer maar eens gecompileerde code te debuggen als je stacktraces van de browser doorloopt.

Dat lijkt me in het geval van TypeScript nauwelijks een probleem, daar de code vrijwel 1:1 overeenkomt met de gegenereerde Javascript code. Alle expressies zijn zo goed als identiek, en wat class en interface-definities betreft wordt het in een prototype-vorm gegoten waarbij de methodenamen en parameters alsnog gelijk blijven.

[codebeat]

Ah, class versus function. Meer standaard OOP maar wat voegt het toe? Het toevoegen van 'types' is sommige gevallen heel vervelend, zeker in een 'interpreter' taal zoals javascript. Kan onduidelijk zijn maar is ook ontzettend flexibel. Controleren op het type volstaat. Als je het goed doet maakt het je ook wat alerter omdat je de code moet controleren of er een juiste waarde terugkomt. Hoop doen dat niet maar ik doe dat altijd, ook al is er zeker wat er terug verwacht kan worden, met javascript weet je het nooit. En wat gebeurd er als een verkeerd type wordt gereturned, klapt dan de code? Moeten we dan overal try and catch statements omheen zetten met alle gevolgen vandien? Overal try and catch omheen zetten om de code stabiel te krijgen maakt de code helemaal niet kleiner. Niet wenselijk omwille een type check.

Het voorbeeld laat helemaal niet zien wat het voordeel is. Weer een class-wrapper om een string te returnen. MS maakt van alles te pas en te onpas gebruik van classes, want blijkbaar is dat heel erg stoer of staat dat stoer. Waarom iets moeilijker maken dan het is. Daar hebben ze bij MS wel een handje van. Ik zou het zelf nooit zo geprogrammeerd hebben, laat staan het gebruik van 'prototype' in deze context.

Ik weet, het is een voorbeeld maar toch, laat dan ECHT zien wat het voordeel is. constructor, okay, maar niet noodzakelijk. Zou meer iets willen zien in het overerven van classes.

Kortom, zet erge vraagtekens bij het nut. Maar als het nut heeft, voeg het toe aan javascript en maak er geen nieuwe 'taal' van, anders krijg je weer zo'n tweesplitsing. Maar buiten dat kan MS zich beter bezig houden met javascript engine van IE, die is nog steeds ondermaats. MS komt altijd weer te pas en te onpas met 'nieuwe' dingen op de proppen zonder eerst de basis eens goed te maken. MS, wij willen geen nieuwe taal maar wel stabiliteit en continuïteit!

[Reactie gewijzigd door codebeat op 24 juli 2024 01:38]

[SentientNr6]

MS kan niet zomaar zaken toevoegen aan de taal. Daar is een committee voor waar zij ook in zetelen.
Ze gebruiken hier trouwens zoveel mogelijk de syntax van ECMAScript 6 die waarschijnlijk over een (paar?) jaar zal uitkomen. Daar zitten ook klasses in.
Het grote verschil is dat je dit NU kan gebruiken als je acht dat het je helpt.

Voor mij persoonlijk was die keuze snel gemaakt, maar ik heb dan ook een C++ background. Ik kan me inbeelden dat dit niet voor iedereen even nuttig is.

MS komt hiermee dus tegemoet aan programmeurs die voornamelijk statically typed languages zoals C++, C#, java etc gewoon zijn die toch JS moeten gebruiken op de client omdat dat nu eenmaal de standaard is.

[Verwijderd]

Kun je Jquery gebruiken binnen trypescript
Of is het bedoeld functioneele classen, en minder voor ui manupilatie enzo.

[SentientNr6]

Dat lukt perfect en ben ik nu 'toevallig' aan het doen.

Typescript is een superset van javascript. Dus je kan alle javascript libraries gebruiken.
Maar tenzij je een declaratie file hebt krijg je geen type checking voor bevoorbeeld functie paramaters.

Voor jQuery is er zo'n declaratie file en krijg je dus wel type informatie. Voor veel andere libraries is zo'n file er nog niet.

[Verwijderd]

bedankt voor de info