La bêta de TypeScript 2.0 disponible et déjà supportée par WebStorm 2016.2

Stop aux valeurs null

Le 12 juillet 2016 à 10h00

4 min

Logiciel

Microsoft vient de publier la première bêta de TypeScript 2.0, un surensemble de JavaScript conçu pour la gestion des gros projets. L’environnement WebStorm passe en version 2016.2, intégrant dans la foulée les nouveautés du langage de script.

TypeScript est un langage de Microsoft qui fonctionne comme un superset de JavaScript, avec lequel il est totalement compatible. Conçu pour gérer de gros projets, il se démarque notamment par un typage fort, un point que l’éditeur a décidé de renforcer avec la version 2.0, actuellement en développement.

La première bêta introduit donc les « non-nullable types ». Comme leur nom l’indique, il s’agit de types de variables qui ne pourront en aucun cas retourner de valeur « null » ou « undefined ». Dans le cas d’une fonction dont le rôle était de récupérer une séquence de caractères (string), il n’existait aucun moyen de savoir si la variable n’allait pas à un moment donné renvoyer une valeur « null ».

Interdire les valeurs null et undefined pour les types

Dans TypeScript 2.0, un développeur peut donc ajouter le flag « --strictNullChecks ». Si une déclaration de variable se fait avec un type string ou number, elle ne pourra donc renvoyer que des séquences de caractères ou des nombres. Dans le cas d’une variable qui doit renvoyer des valeurs null et undefined, des types adaptés sont maintenant disponibles, avec les mêmes noms. L’opérateur « ! » permet également de retirer les deux types de toute expression.

Cet apport est complété par un autre, la CFA (control flow analysis). L’analyse du flux permet à TypeScript de suivre l’évolution des types dans un programme quelconque pour mieux comprendre ce qu’ils sont censés être à un certain point.

TypeScript 2.0 permet également de déclarer des modules de manière simplifiée. Il fallait auparavant renseigner la déclaration avec un minimum d’informations, mais ce n’est plus le cas. Par exemple, « declare module "foo"; » est suffisant, Microsoft indiquant que le développeur peut simplement vouloir indiquer que le module existe, sans se soucier de ce qu’il est.

Async et await devront attendre TypeScript 2.1

La nouvelle version ne sera par contre pas celle d’une fonction attendue : le support des fonctions async d’ES3 et 5. L’éditeur précise que l’implémentation d’async et await réclame une révision de certaines bases et qu’il n’est pas possible d’insérer l’ensemble des tests nécessaires dans le calendrier de la mouture 2.0. Les développeurs peuvent par contre l’espérer pour TypeScript 2.1, la pull request pouvant déjà être examinée dans le dépôt GitHub. Comme on peut le voir dans les commentaires de l’annonce, ils affichent toutefois une certaine déception sur ce report.

TypeScript devrait normalement sortir sous forme de Release Candidate d’ici quelques semaines, le temps que la phase bêta fasse son œuvre. La version finale, quant à elle, arrivera peu de temps après.

Télécharger la bêta de TypeScript 2.0

Attention, l'utilisation de cette bêta réclame la présence de l'Update 3 de Visual Studio 2015.

WebStorm intègre TypeScript 2.0 dans sa version 2016.2

L’environnement de développement intégré WebStorms, édité par JetBrains, rebondit dans la foulée en prenant en charge les nouveautés de TypeScript 2.0. Logique diront certains, cet IDE étant spécialisé dans les langages du web, et tout particulièrement JavaScript. Les utilisateurs pourront donc utiliser par exemple les nouveaux « non-nullable types ».

WebStorms 2016.2 intègre également la CLI (command line interface) d’Angular, permettant aux développeurs de créer de nouveaux projets Angular 2, une galerie de « Live templates » étant d’ailleurs disponible. Le support de React est également amélioré, avec par exemple une complétion du code pour les propriétés de composants définies avec « propTypes » ou des attributs non-DOM qui ne sont plus marqués comme non-résolus.

Notons également le support des imports jspm et des polices avec ligatures, une simplification de la gestion des patchs avec VCS, la possibilité d’ajouter une image en fond, le glissement d’éléments dans un fichier HTML pour générer automatiquement des tags adaptés, l’importation automatique des composants nécessaires en cas d’utilisation de TypeScript ou encore un meilleur support du langage Dart.

Télécharger WebStorms 2016.2

Commentaires (46)

CryoGen

Le 12/07/2016 à 11h47

grunk a écrit :

Visual studio 2015 (community gratuit) ou webstorm (300€) sont à mon sens les plus adaptés

60€ pour Webstorm

anonyme_e186b7865d4971c1a4c38b90521f44b5

Le 12/07/2016 à 11h53

Pochi a écrit :

OK, bon pas de chance VSC me demande 8Go d’espace disque, ça devra attendre que je fasse de la place.

 VCS permet de faire de la grosse maintenance de code (renommage, split de classes, …) ?

Tu peux déjà faire des choses sympa avec vscode.

vloz

Le 12/07/2016 à 11h59

Async et await devront attendre TypeScript 2.1

Je trouve ça tellement nul.

La grande valeur ajoutée des async/await se joue essentiellement coté serveur (cote client ça va surtout donner des mauvaise pratique) or, il est deja possible de faire du vrai l’async/await sur node en activant le flag ES6 de tsc…

Du coup les mecs vont juste perdre énormément de temps à bosser sur un polyfill qui avait certe, énormément de sens lorsque la demande a été lancée, mais plus aujourd’hui.

t0FF

Le 12/07/2016 à 12h00

Il se passe quoi si on essaye d’affecter null à une variable non-nullable ? 

bichon_1er

Le 12/07/2016 à 12h19

Comme éditeur léger, il y a Visual Studio Code (pour Windows, unix…) :https://code.visualstudio.com/

JCDentonMale

Le 12/07/2016 à 12h30

Compatible avec SublimeText ?

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 12/07/2016 à 12h51

Heu j’ai un peu de mal à piger ton point de vue. Async / Await ça a au contraire plus de sens sur le client que sur le serveur, piske ça sert justement à attendre que le serveur réponde sans devoir créer une fonction de callback :

    x = AsyncGetResource1 ();

    y = AsyncMakeQuery2 ();

    MyElement.InnerText = await x + await y;

cmnt

Le 12/07/2016 à 14h12

Je me suis mis a typescript / angular 2 depuis 1 semaine. J’aime beaucoup mais je galère à trouver des tutos intéressant :( Si qq à de bons liens, je suis preneur :)

brazomyna

Le 12/07/2016 à 14h26

il n’existait aucun moyen de savoir si la variable n’allait pas à un moment donné renvoyer une valeur « null ».

Non: il existait des moyens (et plusieurs, du côté de la fonction elle-même comme du côté de l’appelant) ; ce que typescript ajoute ici est un moyen plus ‘coder friendly’ de le faire.

La nuance est de taille à mes yeux.

 

Paraplegix Abonné

Le 12/07/2016 à 14h44

Async Await est valable autant pour le client que le serveur.

 Je pense surtout dans un cas d’utilisation avec Node JS côté serveur ou 90% des fonctions se font avec du callback.

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 12/07/2016 à 14h59

J’suis pas trop convaincu que les callbacks NodeJS soient adaptés à une utilisation avec async/await, justement…

Je n’utilise pas beaucoup Node.JS (hou le doux euphémisme), mais quand je déclare un callback, c’est souvent un pattern :

      “crée un serveur http, et chaque fois qu’un client demande la ressouce /f.html/, appelle la fonction f()”.

 C’est cette notion de “chaque fois que” qui ne me semble pas compatible avec await/async, qui est plutôt “attends une seule fois qu’une action produise son effet, puis continue au statement suivant”.

 

 

CryoGen

Le 12/07/2016 à 15h14

Et si ta fonction f() mets 10 minutes à compléter et donc “retourner” (" />) tu fais comment ?

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 12/07/2016 à 15h25

CryoGen a écrit :

Et si ta fonction f() mets 10 minutes à compléter et donc “retourner” (" />) tu fais comment ?

Ben… On est bien en train de parler d’un serveur, non ? La fonction f() est invoquée dans un thread ; donc le serveur continue à servir les autres clients dans d’autres threads, non ? Et si f() prend 10 minutes, ben, il faut bien que j’attende qu’elle ait fini avant de répondre au client, non ?

vloz

Le 12/07/2016 à 15h33

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

ça sert justement à attendre que le serveur réponde sans devoir créer une fonction de callback 
L'avantage exclusif des l'async/await c'est d'etre utiliser dans des contexte d'execution asynchrone chainée et/ou dynamique &nbsp;, &nbsp;parce que la finalité ça reste quand meme d'eviter que le code se transforme en champs de moustache.     
Or coté client, si lors d’une action de l’utilisateur vous avez besoin de faire appel à plus de 2 fonction asynchrones qui ont besoin d’etre chainé, c’est que le probleme est ailleurs..  

 Pour le reste, votre code doit déjà bien être assez clair avec des promesse et ça evite de tomber dans l’écueil du “tout await” qu’on voit de plus en plus…

EDIT:

D’ailleurs je reprend ton exemple:

   x = AsyncGetResource1 ();    

  y = AsyncMakeQuery2 ();    

 MyElement.InnerText = await x + await y;

 

 Ca coté client, c’est moche… 

CryoGen

Le 12/07/2016 à 15h40

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

Ben… On est bien en train de parler d’un serveur, non ? La fonction f() est invoquée dans un thread ; donc le serveur continue à servir les autres clients dans d’autres threads, non ? Et si f() prend 10 minutes, ben, il faut bien que j’attende qu’elle ait fini avant de répondre au client, non ?

Bah ca dépend du contexte de ta fonction en fait. Tu peux très bien répondre au client “action lancée” pendant que ton serveur mouline et que le client lance de temps à autre une requete f2() pour avoir le status de la tâche…

Bref c’est aussi utile coté client que serveur de pouvoir faire le asynchrone je trouve.

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 12/07/2016 à 16h14

Ha oui, on est bien d’accord que faire de l’aynchrone c’est pratique partout.  Je dis juste que le “syntactic sugar” apporté par la notation async/await ne permet pas de simplifier le code d’un serveur autant qu’il permet de simplifier le code d’un client, c’est tout… 

 

vloz a écrit :

   

 Ca coté client, c’est moche… 

Pourquoi c’est moche ? Si j’ai besoin de demander une offre à deux sites de réservation d’hôtel, puis d’afficher la plus intéressante, je suis bien obligé de faire les deux requêtes et comparer les résultats une fois que je les ai obtenus tous les deux. Le plus efficace c’est de faire les deux en même temps, je vais quand-même pas attendre que le Formule 1 réponde avant de lancer la requête vers le Hilton… Et c’est précisément quand on veut faire ce genre de choses que les notations async/await sont les plus intéressantes.

tanguy_k Abonné

Le 12/07/2016 à 11h04

TypeScript est très chouette, l’essayer c’est l’adopter !

grunk

Le 12/07/2016 à 11h22

C’est vrai que comparé à du JS classique ca change la vie. J’ai juste regretté la galère des typings à se cogner manuellement quand on utilise une librairie un peu exotique qui n’en as pas de dispo.

Pochi

Le 12/07/2016 à 11h33

Je commence à apprendre un peu TypeScript  (pour Angular 2). Des gens connaissent de bons tuto ? Y a quoi comme bon éditeur pour le TypeScript ? C’est aussi puissant qu’un Eclipse pour du Java (renommage des variables, des champs, des classes etc…) ou comme c’est du javascript faiblement typé faut tout se taper à la main ?

grunk

Le 12/07/2016 à 11h38

Visual studio 2015 (community gratuit) ou webstorm (300€) sont à mon sens les plus adaptés

Pochi

Le 12/07/2016 à 11h45

OK, bon pas de chance VSC me demande 8Go d’espace disque, ça devra attendre que je fasse de la place.

 VCS permet de faire de la grosse maintenance de code (renommage, split de classes, …) ?

sr17

Le 12/07/2016 à 16h15

tanguy_k a écrit :

TypeScript est très chouette, l’essayer c’est l’adopter !

Langage avec structures dynamiques, ça ne sera jamais performant.

Avec ce type de langage, un compilateur est devant trop d’inconnues. Il n’a pas assez d’informations pour cadrer le contexte et optimiser efficacement.

Mais bon, comme pour toutes les modes en informatique, on en reviendra.

Paraplegix Abonné

Le 12/07/2016 à 16h16

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

La fonction f() est invoquée dans un thread ; donc le serveur continue à servir les autres clients dans d’autres threads, non ?

Dans NodeJS, pour faire court, la réponse c’est Non. Nodejs est monothread.

 

Pour expliquer rapidement, imaginons pour une raison X ou Y, tu dois lire des infos dans un fichier (ou depuis une base de données), et que la lecture met une 10aine de secondes à se faire. Si tu le fais sans callback  : “fs.readFileSync(“tonfichier”)“, le temps que la fonction se finisse, ton serveur NodeJS est presque complétement bloqué.

Hors si tu utilises les callbacks : “fs.readFile(“tonfichier”, toncallback(x,y){…}) NodeJS lance la lecture du fichier, en attendant que le fichier soit lu, réponds aux autres requêtes, puis reviens sur toncallback une fois que le contenu du fichier a été entièrement lu.

(Après c’est comme ça que l’on m’a expliqué nodejs et toutes les sources que j’ai pu lire sur le net vont dans ce sens, je peux me tromper)

Pour revenir sur la question de async/await côté client ou serveur, je pencherai plus côté serveur. AMHA c’est là  où il sera plus fréquent d’avoir, dans une même fonction, des appels vers plusieurs ressources avec une agrégation des résultats.

Après ça peut être utiliser client comme serveur, rien n’empêche son utilisation. Comme le dis vloz :

“la finalité ça reste quand meme d’eviter que le code se transforme en champs de moustache.”

CryoGen

Le 12/07/2016 à 16h23

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

Ha oui, on est bien d’accord que faire de l’aynchrone c’est pratique partout. Je dis juste que le “syntactic sugar” apporté par la notation async/await ne permet pas de simplifier le code d’un serveur autant qu’il permet de simplifier le code d’un client, c’est tout…

Ah ok, c’est un point de vue qui se défend. De toutes façons je ne fais pas le coté serveur en JS/Node " />

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 12/07/2016 à 16h44

Paraplegix a écrit :

Dans NodeJS, pour faire court, la réponse c’est Non. Nodejs est monothread.

 

Ah ouais, dans ce cas évidemment… Comme dit précédemment, je n’utilise pas Node.JS pour de “vraies” applis. Quand je dois embarquer un serveur, je suis un dinosaure moi, je fais ça à la main en Delphi avec Indy." />

Bon, ben merci à tous de m’avoir remis sur la bonne voie.

vloz

Le 12/07/2016 à 16h53

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

Pourquoi c’est moche ? Si j’ai besoin de demander une offre à deux sites de réservation d’hôtel, puis d’afficher la plus intéressante, je suis bien obligé de faire les deux requêtes et comparer les résultats une fois que je les ai obtenus tous les deux. Le plus efficace c’est de faire les deux en même temps, je vais quand-même pas attendre que le Formule 1 réponde avant de lancer la requête vers le Hilton… Et c’est précisément quand on veut faire ce genre de choses que les notations async/await sont les plus intéressantes.

Bon deja tu peux le faire sans trop de soucis en faisant un simple:

 

Promise.all([query1,query2]).then(()=>{//la suite});

Ce qui est loin d’etre illisible (bon là dans les commentaire forcement c’est moche).

Mais bon ton exemple est encore loin d’etre genial, c’est moche de se servir du navigateur d’un client pour fureter des offres de sites tiers… Normalement ce genre de comparaison tu les fait coté serveur, pour etre sur de ce qui est envoyé au client, le foutre en cache, l’analysé, etc… ca evite d’enfeindre la Same-origin policy et c’est au final surtout une question de bon sens…

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 12/07/2016 à 17h29

vloz a écrit :

Normalement ce genre de comparaison tu les fait coté serveur, pour etre sur de ce qui est envoyé au client, le foutre en cache, l’analysé, etc… ca evite d’enfeindre la Same-origin policy et c’est au final surtout une question de bon sens…

C’est surtout une question d’architecture. Et de contraintes. Et de mode. Tu pars naturellement du principe que l’application est hostée sur un serveur et déployée sur Internet, en grande partie parce que c’est à la mode.

Les applications du monde industriel, et en particulier celles que nous développons dans ma boîte, ne s’appuient pas toutes sur ces principes. Notamment, la solution que j’emploie, destinée à un réseau local, n’a pas besoin de serveur centralisé, tous les traitements se font en local sur le client.

vloz

Le 12/07/2016 à 18h33

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

Les applications du monde industriel, et en particulier celles que nous développons dans ma boîte, ne s’appuient pas toutes sur ces principes. Notamment, la solution que j’emploie, destinée à un réseau local, n’a pas besoin de serveur centralisé, tous les traitements se font en local sur le client.

Mais dans cette situation autant directement faire une app nodejs… ¯\_(ツ)_/¯

zefling Abonné

Le 12/07/2016 à 20h37

Pochi a écrit :

Je commence à apprendre un peu TypeScript (pour Angular 2). Des gens connaissent de bons tuto ? Y a quoi comme bon éditeur pour le TypeScript ? C’est aussi puissant qu’un Eclipse pour du Java (renommage des variables, des champs, des classes etc…) ou comme c’est du javascript faiblement typé faut tout se taper à la main ?

Ça fait 4 mois que je suis sur Angular2 est il a tellement changé que te donner un bon tuto serait compliqué. Le premier que j’ai suivi (payé par ma boîte) ne vaut plus rien aujourd’hui (un truc avec beaucoup trop de poneys). C’est d’ailleurs le problème actuel, il est encore beaucoup trop installable (un module en ait déjà à leur 3e réécriture : ex. le routter), difficile à débugger (des erreurs souvent incompréhensible), et j’en passe. Ça reste possible d’écrire un projet d’envergure, mais ça demande beaucoup d’investissements, accepter de passer souvent sur cette page et de lire les commits, car la doc est blindée d’erreurs. Actuellement, on est bloqué sur les RC3 à cause de dépendances qui rendent le passage en RC4 beaucoup trop compliqué.

Typescript reste un outil très puissant, surtout pour ceux qui sont habitués à Java, sauf que je viens de me rendre compte qu’on perd aussi au passage tous les avantages d’un langage prototypé pour simuler de l’objet. Pour un gros projet, ça reste quand même sympa de pouvoir côté d’avec une partie des avantages permis ES6 et 7 sans se soucier du navigateur, car il est possible de le transpiler pour des navigateurs obsolètes comme IE11.

Bunnyhop

Le 12/07/2016 à 21h15

Pas mieux, ça va faire 3 ans que j’en fais, niveau productivité c’est du bonheur…

Mandrivia

Le 12/07/2016 à 21h44

Le site officielhttp://angular.io est la source la plus fiable (mais pas la plus complète, hélas) puisque la plus à jour (par rapport aux releases). C’est pas trop mal pour commencer, après il faut creuser sur google (toujours en faisant attention à la version utilisée) pour certains points plus précis.

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 13/07/2016 à 05h56

vloz a écrit :

Mais dans cette situation autant directement faire une app nodejs… ¯\_(ツ)_/¯

Bah oui, allons-y, ajoutons une couche intermédiaire tournant sur un noeud qu’il faudra provisionner, qui peut tomber en panne, sur lequel il faudra installer les patchs de sécurité, qu’il faudra maintenir, dont il faudra convaincre la DSI d’ouvrir les bons ports du firewall…

Ca va vachement augmenter la stabilité de l’application, tout ça. " />

vloz

Le 13/07/2016 à 09h40

Je crois que tu m’a pas compris.

Dans l’univers du “tout javascript”, lorsqu’on veut faire une “ application-industriel-pas-à-la-mode-wesh” qui ne passe pas un serveur web centralisé: on n’utilise pas de navigateur, car ça expose inutilement les sources à l’utilisateur, c’est une surcouche supplémentaire inutile sur laquelle on a pas forcement la main pour les mis à jour, et accessoirement ça fait pas pro du tout de balancer de fichier html/js en vrac dans un bete repertoire, en plus de t’empecher d’avoir acces à pas mal de fonctions bien interessante dont dispose la quasi totalité des autres techno de client lourds (l’acces au systeme de fichier pour ne citer que lui).

Le seul avantage de passer par un navigateur c’est juste la taille de l’executable qui prend +40MB supplémentaire dans sa version node (car il embarque un navigateur pour l’UI), mais vu qu’on parle de client lourd dont l’install ne depend pas d’un serveur web distant => osef.

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 13/07/2016 à 10h49

Ah de fait, j’ai rien compris à ce que tu dis, en effet… Une application industrielle en tout JavaScript tournant sur un serveur Node/JS (dont j’ai appris récemment qu’il était monothread) juste pour “passer pour un pro” ? " /> 

Moi je te parle juste d’un tableau de bord qui collecte les indicateurs de performance du système depuis les différents équipements, calcule les corrélations, qu’on peut afficher sur n’importe quel PC, tablette, téléphone ou écran au mur..

Je ne vois vraiment pas l’intérêt concret de faire ça autrement que directement en JS dans une page html unique, servie statiquement par l’intranet du site.

Le coeur de métier est évidemment en C / C++ / Delphi dans des serveurs d’applications dignes de ce nom et sécurisés. En multithread. Avec des attentes de réponse synchrones et sans callbacks… 

brazomyna

Le 13/07/2016 à 11h23

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

Je ne vois vraiment pas l’intérêt concret de faire ça autrement que directement en JS dans une page html unique, servie statiquement par l’intranet du site

Ça dépend beaucoup du contexte et des contraintes qu’il impose en effet. Mais à priori, je rechignerais à avoir des clients qui vont directement picorer des données sur des équipements tiers de la boite pour se faire leur synthèse de leur côté.

Niveau sécurité, j’aurais tendance à privilégier un serveur bien déterminé qui lui seul a les droits d’accéder aux fournisseurs de données, et qui sert différents clients qui eux ont seulement accès à ce que ce serveur veut bien leur fournir. Ça me paraît (toujours à priori, sans autre élément) plus vertueux déjà en terme de politique de sécurité.

Quant au mono/multi-thread, faut arrêter de dire n’importe quoi: on peut parfaitement faire des applications multithreadées avec node, on trouve les explications en moins de 30 secondes dans la doc de node (cf child-process)

Pochi

Le 13/07/2016 à 11h27

zefling a écrit :

Ça fait 4 mois que je suis sur Angular2 est il a tellement changé que te donner un bon tuto serait compliqué. Le premier que j’ai suivi (payé par ma boîte) ne vaut plus rien aujourd’hui (un truc avec beaucoup trop de poneys). C’est d’ailleurs le problème actuel, il est encore beaucoup trop installable (un module en ait déjà à leur 3e réécriture : ex. le routter), difficile à débugger (des erreurs souvent incompréhensible), et j’en passe. Ça reste possible d’écrire un projet d’envergure, mais ça demande beaucoup d’investissements, accepter de passer souvent sur cette page et de lire les commits, car la doc est blindée d’erreurs. Actuellement, on est bloqué sur les RC3 à cause de dépendances qui rendent le passage en RC4 beaucoup trop compliqué.

Oui je viens juste de me rendre compte qu’il était encore en béta. En fait je voulais apprendre Angular parce que ça à l’air pas mal demandé en ce moment chez les banques/assurances. Je suis parti sur le 2 sans trop savoir parce que c’est le plus récent, que typescript à l’air moins pire que du pur javascript (^^’ ) et que chez mon précedent client ils avaient sorit un framework basé sur angular1 et qu’ils disaient qu’ils allaient pas trop tarder à passer sur le 2.

zefling a écrit :

Typescript reste un outil très puissant, surtout pour ceux qui sont habitués à Java, sauf que je viens de me rendre compte qu’on perd aussi au passage tous les avantages d’un langage prototypé pour simuler de l’objet. Pour un gros projet, ça reste quand même sympa de pouvoir côté d’avec une partie des avantages permis ES6 et 7 sans se soucier du navigateur, car il est possible de le transpiler pour des navigateurs obsolètes comme IE11.

Perso je viens d’un projet GWT et je dois dire que c’est le framework que j’ai le plus apprécié. Je jette un oeil sur angular parce que c’est la mode mais j’ai l’impression que c’est mieux pour les petits projets (ou sites web très branchouille/design mais avec peu de contenu) mais que niveau maintenance, surveillance du code c’est en dessous. Après je ne connais pas encore tout l’ecosystème.

zefling Abonné

Le 13/07/2016 à 13h33

Pochi a écrit :

Perso je viens d’un projet GWT et je dois dire que c’est le framework que j’ai le plus apprécié. Je jette un oeil sur angular parce que c’est la mode mais j’ai l’impression que c’est mieux pour les petits projets (ou sites web très branchouille/design mais avec peu de contenu) mais que niveau maintenance, surveillance du code c’est en dessous. Après je ne connais pas encore tout l’ecosystème.

Angular 2 est pensé pour les applications web. Pour une petite applis, c’est prendre un char pour tuer une mouche. On est déjà plus de 56 composants avec des services de tous les côtés et ça reste très réactif.

grunk

Le 13/07/2016 à 13h51

En effet je croyais qu’il l’avait coller au même prix que tout leur autres ide

Cedrix

Le 13/07/2016 à 13h55

Angular 2, c’est orienté composant. Niveau maintenance, c’est assez aisé si tu mets pas tous tes composants dans les mêmes fichiers.

Après le problème c’est pour trouver un bon IDE qui supporte le TS sur toutes les plateformes :-)

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 13/07/2016 à 14h09

brazomyna a écrit :

Ça dépend beaucoup du contexte et des contraintes qu’il impose en effet. 

Quant au mono/multi-thread, faut arrêter de dire n’importe quoi: on peut parfaitement faire des applications multithreadées avec node, on trouve les explications en moins de 30 secondes dans la doc de node (cf child-process)

Le contexte : accumuler des données en provenance d’équipements connectés sur le réseau dont quasiment aucun ne supporte ssl et qui négocient le mot de passe (quand il y en a un, bien sûr) en clair…

Pour le reste, Paraplegix me dit que c’est monothread… mettez-vous d’accord entre spécialistes.

brazomyna

Le 13/07/2016 à 20h48

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

Le contexte : accumuler des données en provenance d’équipements connectés sur le réseau dont quasiment aucun ne supporte ssl et qui négocient le mot de passe (quand il y en a un, bien sûr) en clair…

Donc si je comprends bien, la situation actuelle c’est d’avoir les mots de passe hardcodés dans le javascript refilé au client, qui est mis à dispo dans l’ensemble de l’intranet.

A ce niveau, c’est pas une faille de sécurité, c’est un abîme.

 

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

Pour le reste, Paraplegix me dit que c’est monothread… mettez-vous d’accord entre spécialistes.

Par défaut c’est monothread ; il existe de nombreuses solutions pour faire du multi-thread/multi-process avec communication inter-thread/process.

Un exemple qui reprend la même syntaxe que les web-workers qui existent dans le JS côté navigateurs.

GitHub 

brazomyna

Le 13/07/2016 à 21h06

La version longue:

Par défaut nodeJS est monothread, avec une philosophie forte de "dès qu'un   truc peut potentiellement prendre plus que quelques microsecondes, on   propose une API en asynchrone pour cette action.

L’asynchrone, C’est parfaitement adapté pour des actions qui vont initier un traitement qui ne consomme pas nécessairement beaucoup de CPU pour le traitement en soit, mais qui devra attendre un temps plus ou moins long que les ressources dont il a besoin pour ce traitement soient disponibles.

Cas typique: je fais une requête HTTP ; le traitement de la requête en lui-même est très peu consommateur en ressources (temps CPU), mais entre le moment où je fais la requête et le moment où j’aurai la réponse il peut très bien se passer 10 secondes pendant lesquelles je peux faire autre chose et/ou je dois rester réactif pour traiter d’autres demandes.

Autre exemple typique: les IHM (n’importe quelle appli graphique avec des boutons) dont le fonctionnement repose strictement sur ce même principe de boucle d’événements.

Quand on a d’autres types de besoins, typiquement quand on veut faire des actions qui vont devoir consommer beaucoup de CPU, là on veut autre chose: pouvoir utiliser le maximum de cores de son CPU et/ou répartir la charge. Cas typique: j’ai besoin de calculer 10k décimales de PI pendant que je fais d’autres trucs en parallèle. Là le besoin c’est du multi-thread.

Il existe en nodeJS aussi de nombreuses solutions pour faire du multi-thread/multi-process avec communication inter-thread/process.

Et on peut également avoir encore d’autres besoins pour la montée en charge (ie. on a toujours les mêmes besoins pour chaque client, mais on a de plus en plus de clients qui vont vouloir nous demander le même genre de choses en même temps) ; là aussi la notion de multi-thread/process peut devenir intéressante, et d’autres notions complémentaires (notion de cluster).

 

En bref, tout ça n’a rien d’extraordinairement nouveau, ce sont des concepts généraux qui existent depuis plus de 20 ans (et qu’au passage le moindre dev. du XXIème siècle qui se respecte un tant soit peu devrait maîtriser) ; nodeJS n’a pas plus réinventé la roue dans ce domaine qu’il ne serait composé que d’une seule roue carrée. NodeJS ne se différencie pas là dedans.

Faut arrêter avec les FUDs à deux balles du genre ‘nanmé node est mono-thread caydlamayrde’.

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 14/07/2016 à 07h19

brazomyna a écrit :

Donc si je comprends bien, la situation actuelle c’est d’avoir les mots de passe hardcodés dans le javascript refilé au client, qui est mis à dispo dans l’ensemble de l’intranet.

A ce niveau, c’est pas une faille de sécurité, c’est un abîme.

 

Euh, non, ce n’est pas du tout, du tout, du tout, ce que j’ai dit, lire, pas extrapoler, merci…

Bon, puisqu’on a dévié jusqu’ici, je vous fais la version longue pour essayer de recentrer le débat (qui pour rappel était : async/await est plus utile dans du code qui interroge un serveur que dans du code qui répond à un client)

J’ai juste dit que chacun des modules fonctionnels expose un port (généralement un micro-serveur http) qui permet à n’importe quel client de se connecter, (1) sans SSL (2) ni mot de passe, pour obtenir un heartbeat et les paramètres essentiels de fonctionnement du module (p. ex. si le module est un frigo, sa température).

Ceci permet à tous les noeuds du système de périodiquement vérifier que les autres noeuds qu’il connaît sont en état de fonctionnement optimal, et lancer localement des alertes si nécessaire.  Cette architecture hautement redondante est indispensable pour détecter rapidement les services qui ont cessé de fonctionner, surtout et y compris quand c’est précisément un module centralisé qui s’est vautré. Cette architecture n’utilise pas la technologie “push” pour exactement les mêmes raisons.

Passer exclusivement par un serveur centralisé est une couche supplémentaire inutile et compliquée ; elle est surtout dangereuse car ajoute un single point of failure.  Demander un chiffrement SSL occupe des ressouces processeur qui seraient mieux exploitées par le module à faire autre chose, tout en n’offrant aucune réelle protection. Pareil pour un mot de passe. Le seul risque réel pouvant être une attaque DOS sur le serveur web d’un module, ce serveur est expressément limité quant aux ressources qu’il peut occuper.  D’où, notamment, pas de SSL, aucune vérification de MdP, aucun parsing des arguments, rien : j’ouvre le socket, je ne lis pas ce que le client a envoyé, j’écris mon status précédé d’un header http minimaliste et je ferme le socket ; en gros, comme le démon quotd sauf qu’on n’envoie pas un sonnet de Shakesepeare.

 

Cette architecture permet accessoirement d’écrie une “simple” page html & js qui interroge quelques modules bien choisis et affiche leurs paramètres de fonctionnement. Ce qui était là où je voulais en venir depuis le début.

 

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 14/07/2016 à 10h04

De l’asynchrone, j’en fais depuis 30 ans et le Z-80 des contrôleurs de l’époque (le multithread n’était pas trop répandu sur cette plateforme, mais il y avait des interruptions), donc c’est pas moi qu’il faut essayer de convaincre… Néanmoins, et pour nuancer mon propos, puisque manifestement il fait penser que je n’ai rien compris…

Le fonctionnement asynchrone est - comme tu le fais remarquer - utile quand on attend passivement qu’un processus extérieur fasse un traitement. Ce comportement est typiquement celui d’un client. Il arrive qu’on désire écrire un processus serveur qui agrège les résultats de plusieurs autres serveurs. Ce serveur prend donc, durant cette attente des résultats, lui-même une attitude de client. Un paradigme asynchrone est adapté à cela.

Par contre, là où le bât blesse, c’est que dès que tu as un workflow un peu complexe où tu alternes attentes passives et traitements lourds pouvant en plus être parallélisés, il devient vite compliqué de gérer ça, et tu as besoin de points de rendez-vous qui ne sont pas aisés à exprimer avec de “simples” fonctions de callback et qui, selon mon expérience, sont plus faciles à écrire et donc moins fragiles quand tu exprimes ce que tu attends directement dans un thread (j’ai pas dit que c’était impossible en asynchrone, je dis juste qu’il est beaucoup plus facile de perdre le fil du workflow - et la lisibilité du code dans ce contexte est cruciale).

Notamment un truc comme notre implémentation du protocole ASTM-1381 qui prend 8 pages quand c’est exprimé en asynchrone avec une machine à états (sans même gérer tous les cas), a pu se réécrire via un thread comme (de mémoire) :

   while (retrycount < 6) {

      send block

      switch (read character) {

       case ACK : return true;

       case NAK : retrycount ++; break;

       case EOT : *interrupt = true; return true;

       case TIMEOUT : return false;

       default : flushInput(); retrcount++; break;

     }

  } 

Ce morceau-là se prêterait encore assez bien à un await AsynchSendBlock() et await AsynchReadChar() mais si c’est juste pour faire immédiatement un await d’un asych, autant faire directement un thread…

 

Pochi

Le 14/07/2016 à 11h13

zefling a écrit :

Angular 2 est pensé pour les applications web. Pour une petite applis, c’est prendre un char pour tuer une mouche. On est déjà plus de 56 composants avec des services de tous les côtés et ça reste très réactif.

Y a quoi comme eco-système pour :

analyser le code (genre SonarQube)

avoir une idée de la couverture du code par les tests

J’ai testé Visual Code Studio, c’est pas trop mal, c’es très réactif mais ça manque encore beaucoup d’aide à la complétion de code (les import sont pas détecté comme le fait eclipse pour java, j’ai pas trop vu de modification de signature de méthode…) et y a toujours ce truc horrible du script dans le html qui n’est pas dynamique (je change le nom d’un champ d’une classe, je dois me tapper la modif à la main dans le html, relou). Après c’est ptet des option que je n’ai pas vu mais il a l’air assez limité malgré tout. 

Or, pour moi, tout ceci est primordial quand on fait du gros projet. C’est mieux que le pur javascript, y a pas photo, mais on est loin de ce qui existe aujourd’hui pour java/GWT

zefling Abonné

Le 14/07/2016 à 18h56

Pochi a écrit :

Y a quoi comme eco-système pour :

analyser le code (genre SonarQube)

avoir une idée de la couverture du code par les tests

J’ai testé Visual Code Studio, c’est pas trop mal, c’es très réactif mais ça manque encore beaucoup d’aide à la complétion de code (les import sont pas détecté comme le fait eclipse pour java, j’ai pas trop vu de modification de signature de méthode…) et y a toujours ce truc horrible du script dans le html qui n’est pas dynamique (je change le nom d’un champ d’une classe, je dois me tapper la modif à la main dans le html, relou). Après c’est ptet des option que je n’ai pas vu mais il a l’air assez limité malgré tout.

Or, pour moi, tout ceci est primordial quand on fait du gros projet. C’est mieux que le pur javascript, y a pas photo, mais on est loin de ce qui existe aujourd’hui pour java/GWT

On est sous Netbeean avec le plug-in Typescript, qui gère très bien le Typescript d’Angular (mais très mal les vue, les codes comme , il n’aime pas trop ). Pour les tests on utilise Jasmine, mais pour être franc, Angular bouge tellement, c’est tellement mal documenté (et on est tellement à la bourre), qu’on n’arrive pas vraiment à bien les faire.

C’est sûr que l’environnement meilleur pour java/GWT , qui est beaucoup plus mature. Et puis, Angular2 est toujours en beta pour moi (malgré le RC4 qu’il affiche). Il y a beaucoup trop de bugs, il manque bien trop de choses pour dire que c’est stable. D’ailleurs, on s’était lancé dessus dans l’espoir que ça soit stabilisé avant le ngConf… ce qui n’a pas du tout était le cas. Rajouter à cela que les outils qui gère bien le TypeScript sont en fait encore assez rare : Chrome est d’ailleurs le seul navigateur que j’utilise comme débuggeur.

En tout cas, je ne sais pas si j’utiliserais typescript pour réécrire mon petit projet. Pour l’instant, pour le mien, je ne pense pas le faire.