Discussion :

[hotcryx]

il y a qu'en même de grosses lacunes comme le typage.
cela ne peut entrainer que des erreurs d'exécution ou lors de conversion de type. Comme ce fut le cas en VB6 avec les Variant.

un langage ne doit pas permettre de faire tout et n'importe quoi n'importe comment. Il faut un minimum de structure sinon ça devient de la bouillie, du code spagetti...

cela dit, je n'ai rien contre toi et javascript, c'est juste mon point de vue.

je suis du même avis, un mauvais codeur, restera mauvais mais malheureusement on doit parfois reprendre le code d'un autre et c'est là que ça peut coincer si le langage ne met pas des gardes fous

[marts]

il y a qu'en même de grosses lacunes comme le typage.
cela ne peut entrainer que des erreurs d'exécution ou lors de conversion de type.

Non, seul le faux développeur qui ne sait pas ce qu'il fait avec ses variables peut entrainer des erreurs d'exécution.

un langage ne doit pas permettre de faire tout et n'importe quoi n'importe comment. Il faut un minimum de structure sinon ça devient de la bouillie, du code spagetti...

Si, un langage doit permettre à un développeur de faire tout ce qu'il veut. Quitte à permettre aussi aux faux développeurs de faire des applis buggées et instables.

on doit parfois reprendre le code d'un autre et c'est là que ça peut coincer si le langage ne met pas des gardes fous

Donc on est bien d'accord, le problème n'est pas JS mais les faux développeurs.
Choisis avec qui tu travailles, ça ira mieux.

[wanou]

il y a qu'en même de grosses lacunes comme le typage.
cela ne peut entrainer que des erreurs d'exécution ou lors de conversion de type. Comme ce fut le cas en VB6 avec les Variant.

un langage ne doit pas permettre de faire tout et n'importe quoi n'importe comment. Il faut un minimum de structure sinon ça devient de la bouillie, du code spagetti...

cela dit, je n'ai rien contre toi et javascript, c'est juste mon point de vue.

je suis du même avis, un mauvais codeur, restera mauvais mais malheureusement on doit parfois reprendre le code d'un autre et c'est là que ça peut coincer si le langage ne met pas des gardes fous

On va diverger si on commence maintenant à rentrer dans le débat langage à typage fort / faible, mais oui, pour des raisons de maintenance (entre autre) il faut les outils pour valider ton code. Ces outils existent en JavaScript: jslint, jshint, l'analyse statique du code via les IDE (Netbeans ou autre), documentation via jsdoc, ...

Je fait un fort distingo entre langage et environnement de dev te permettant de travailler sur le langage. En effet, combien de dev serait actuellement perdu sans leur Eclipse ou autre Visual Studio chérie.

Ici on un langage conçu au dessus de JavaScript... super, mais pour l'utiliser dans un cadre adéquat, il faut passer par Visual Studio. Microsoft n'aurait pas mieux fait d'améliorer leur IDE pour la reconnaissance de JavaScript ? Mais je crains que leur démarche soit la suivante:

1 - Microsoft créé un langage au dessus de JavaScript (donc compatible ECMAScript 5)
2 - Microsoft teste si la communauté est réceptif
3 - Si oui, alors Microsoft l'intègre à Visual
4 - Microsoft l'intègre à IE
5 - Microsoft force de facto la communauté responsable des spec ECMAScript 6 à s'inspirer fortement de ce qu'ils ont implémenté

On se retrouve alors avec Microsoft qui fait une OPA sur JavaScript.

[Niark13]

JavaScript n'est pas Java ou C++, donc oui, si vous voulez coder en JavaScript il vous faut d'abord apprendre à comment coder proprement.

Tu devrais plutôt comparer JS à d'autres langages de script comme Python ou Ruby...

[_skip]

Issu du blog de Scott Hanselman :

What I like about TypeScript - so far - is that TypeScript’s static typing could enable better tooling with warning squiggles, easy statement completion, plus smart refactoring. You also get easy navigation around code, as well as find references, rename, and more.

Ce type a cerné le problème :

Voilà les avantages du typage statique, la détection d'erreur et le fait de rendre possible un support IDE poussé (refactoring, auto-complétion etc...).

Ces choses permettent justement de travailler efficacement en équipe, de s'y retrouver lorsque les bases de code deviennent importantes, d'être productif et d'économiser beaucoup de temps.

On peut le faire en JavaScript actuellement, tout ce qui manque c'est une intégration digne de ce nom de JavaScript dans un IDE.

Dans l'état actuel de javascript, ceci n'est qu'à moitié possible justement. Ce n'est pas le seul langage dans cette situation, regarde PHP, tu verras que malgré la popularité et les années de bouteilles, aucun IDE ne peux t'offrir un support aussi avancé que C# ou java niveau refactoring et complétion.
L'IDE serait quasiment obligé d'exécuter le code from scratch pour savoir s'il est valide ou non.

Puis s'il vous plaît pour ceux que cela concerne, cessez de dire que c'est au développeur de faire attention. Vous n'utiliseriez pas les mêmes variables pour stocker des doubles, des chaînes et des pointeurs de fonction alors pourquoi tenez-vous tant à ce que ce soit possible niveau langage? En sachant que ça amène que des problèmes, tant pour les interpréteurs qui sont incapables d'optimiser, pour les IDE incapables de vous corriger, et pour vous qui risquez de vous faire avoir.
Pour ceux qui se croient tellement malins, vous êtes pas des machines mais des humains, en ce sens vous êtes faillibles et les autres membres de votre équipe aussi. Une fois sur 1000, 10000 ou 100000 lignes de code vous utiliserez une variable de façon inappropriée, ça marchera par bol dans vos tests (c'est là le plus traître) et ça posera problème en production.

Pour en revenir au sujet plus directement, je trouve qu'on a vraiment besoin de projets comme Dart ou TypeScript pour rendre le code JS plus sûr, plus maintenable et plus testable. Le seul point négatif c'est le danger de multiplication de ces JS-killers qui conduise à ce qu'aucun ne soit suffisamment répandu et viable.

[PyNub]

JavaScript n'est pas Java ou C++, donc oui, si vous voulez coder en JavaScript il vous faut d'abord apprendre à comment coder proprement.

Oui c'est bien connu en C++ et en Java on peut se permettre de coder n'importe comment...

[transgohan]

Oui c'est bien connu en C++ et en Java on peut se permettre de coder n'importe comment...

Ce n'est pas ce qu'il sous-entendait.
En C++ et en Java le compilateur/interpréteur est moins permissif et te jetera quand il y a un doute (ou au moins un warning).
En Javascript il te souhaite même pas bonne chance.

[hotcryx]

j'ai du mal à comprendre "interface" (faux-ami?)
Je ne vois pas d'implémentation.

Sinon ça à l'air plus clair.

Dans l'exemple, ils auraient pû employer des Stringbuilder pour les concaténations. Autant donner un exemple correct.

[h_fabrice]

Microsoft a fait sortir beaucoup de framework, de tools et aujourd'hui un surlangage de javascript. D'autres géants aussi du logiciel le font : Preuve de la puissance de ce langage.

[Invité]

Microsoft a fait sortir beaucoup de framework, de tools et aujourd'hui un surlangage de javascript. D'autres géants aussi du logiciel le font : Preuve de la puissance de ce langage.

L'auteur de la citation suivante a bien compris :

C'est dingue le nombre projets pour améliorer Javascript !
Au moins ça confirme qu'en l'état le Javascript n'est plus adapté aux besoins.

[amezghal]

Ecrire du code TypeScript et debugger du javascript.
Dans ce cas pour corriger un bug, il faut deja bien maitriser le javascript..faire un mapping pour savoir ou modifier...

Edit:
Il y a ca: http://www.html5rocks.com/en/tutoria...ls/sourcemaps/

[pierre-y]

Citation:

au final le code généré c'est du javascript parfaitement lisible , donc même si demain MS abandonne typescript , les librairies générées seront toujours totalement utilisables. Maintenant faut il apprendre typescript , coffeescript ou javascript ? débugger son application se fait toujours en javascript donc javascript est obligatoire , cela ne veut pas dire qu'on doit écrire du code js, c'est tout l'intérêt de ces langages.

Oui mais justement, si le résultat est le même ; MS, Google, Apple auraient pas plutôt intérêt a travailler sur un système commun? Ils y gagneraient en temps de développement, en correction des bugs, en clarté aussi... etc.

Ils y a une raison particulière qui peut justifier ces choix de développement a part autre que la concurrence?

[tomlev]

tomlev >> pour éviter les allocations mémoires inutiles (pareil en java et C#).

Je sais ce que c'est qu'un StringBuilder, mais à ma connaissance ça n'existe pas en JS... (cela dit ma connaisance de JS est assez limitée, je l'admets)