Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Visual Studio 2015 : Microsoft présente les améliorations apportées à l'éditeur JavaScript
Support natif d'AngularJS, RequireJS et ECMAScript 2015

Le , par Olivier Famien

5PARTAGES

2  0 
Microsoft vient d’apporter des améliorations à son éditeur JavaScript dans son environnement de développement Visual Studio 2015.

Dans la version Community Edition comme l’Enterprise Eiditon, les bibliothèques AngularJS et RequireJS ont été intégrées. Par le passé, ces bibliothèques n’étaient pas prises en charge par défaut. Désormais, c’est possible de faire appel aux bibliothèques AngularJS et RequireJS et bénéficier par la même occasion des options de codage offertes par Visual Studio telles qu’Intellisense, Go To Definition ou encore la barre de navigation.


Cette dernière permet d’accéder aux identificateurs que vous utilisez fréquemment. Les utilisateurs pourront parcourir plus aisément leur code en s’aidant de cette fonctionnalité. Ci-dessus, une illustration de l’usage de la barre de navigation avec ECMAScript 2015.

À côté de ces nouvelles caractéristiques supportées, Microsoft a également apporté à Visual Studio 2015 la prise en charge des commentaires de documentation JSDoc. Il faut rappeler que JSDoc est un générateur de commentaires servant la documentation du code JavaScript.

Il est généralement utilisé par une grande partie de communauté de développeurs JavaScript pour produire générer des commentaires de documentation pour les méthodes, paramètres, classes, espaces et autres objets sans coup férir. Le visuel ci-dessous pourra servir de témoignage de cette fonctionnalité.


Pour plus de détails, vous pouvez également consulter cette page.

Il faut également inclure au nombre des supports pris en charge, les spécifications du standard ECMAScript 2015 anciennement connu sous le nom ECMAScript 6. Les classes, les lamdas, les symboles, les proxys etc ainsi que bien d’autres API sont également supportés. Vous pouvez utiliser ce lien pour accéder à la liste complète des spécifications prises en charge pour ES2015.

Toutefois, les spécifications de cette norme ne sont pas toutes encore prises en charge. Microsoft compte travailler afin de soutenir le standard de manière complète. Rendez-vous est donc pris avec les prochaines itérations du produit afin de voir des ajouts tels que les modules ou les générateurs être intégrés.

En dernier point, Microsoft a introduit dans cette version de Visual Studio la possibilité d’utiliser la liste des tâches de l’éditeur avec le code JavaScript afin de suivre les traces des commentaires tels que//TODO,//HACK,//UNDONE ou encore les jetons de commentaires personnalisés.


En plus de ces différentes améliorations, la firme de Redmond a également mis un point d’honneur à l’amélioration des performances, les corrections de bug et l’intégration de plusieurs autres mises à jour afin d’améliorer l’expérience utilisateur de cet éditeur pour JavaScript.

Source : Blog MSDN

Et vous ?

Que pensez-vous des améliorations apportées à Visual Studio pour JavaScript ?

Avez-vous utilisé l’éditeur JavaScript de Visual Studio 2015 ? Quel retour d’expérience faites-vous ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 06/04/2016 à 20:40
Le problèmes des PCH, c'est qu'ils ne sont pas composables. Tu ne peux pas dire je prend le PCH lié à la lib A, et celui de la lib B, et je les fait tourner ensemble. Tu es obligé de faire un PCH spécifique qui ne marche que quand tu utilises A puis B.

Donc les PCH sont spécifiques à chaque projet, et doivent être générés dans chaque cas. Et se pose la question de savoir ce qu'on met dedans, et ce qu'on garde sous forme de #include en dehors du PCH. Si on n'en met pas assez, on est trop lent, si on en met trop, à chaque compilation incrémentale, on va devoir re-générer l'ensemble du PCH et perdre du temps.

On peut voir les modules comme des PCH mais qui sont composables, et où tu aurais un PCH par header (ou groupe de headers étroitement liés). Tu as généré le code précompilé pour A, celui pour B, tu peux les utiliser séparément ou ensemble, dans l'ordre que tu veux. Du coup, quand tu livres ta bibliothèque, tu livres le précompilé avec qui peut directement être réutilisé. Jamais tu n'auras besoin de le code client de parser les headers de cette bibliothèque. Pourquoi peut-on faire ça avec les modules, mais pas avec les PCH ? Voir ma réponse à la seconde question.

isolation from macros = en quoi les macros posent pb ?
Ce sont elles qui empêchent toute composabilité. Quand tu inclues un .h dans ton code, la manière de l'interpréter dépend de l'ensemble des macros définies au moment où tu l'inclues. Qui n'a jamais eu sous windows un problème pour inclure un header d'une bibliothèque third party après un #include <windows.h> parce ce dernier définit une macro min... L'idée de base est qu'un module ne dépende pas des macros définies avant qu'il soit importé, et qu'en retour, il ne pollue pas l'environnement avec ses propres macros. Et là, la modularité commence à apparaître.
Je dis "l'idée de base" parce que certains aimeraient bien pouvoir dire que sélectivement, telle ou telle macro définie dans un module pourrait être visible de l'extérieur. C'est en discussion.

il y a plus de problemes non resolus que de REELS problemes resolus (pas de gestion de namespace donc conflits potentiels, pas de versioning, description des fonctions non lisibles dans les fichiers binaires de 'package').
Je ne pense pas qu'il s'agisse forcément de réels problèmes, mais d'une simple description de ce que les modules ne sont pas, pour éviter les confusions :

Namespaces : Certains langages (Java par exemple) lient structure physique du code (modules, fichiers source) et structure logique (namespaces, classes). D'autres ne le font pas (C# par exemple). La proposition de module pour le C++ choisi de ne pas le faire. Ce n'est en rien une limitation, mais un choix qui fait sens en C++ (sinon, comment ajouter une spécialisation de std::hash ?).
Versionning : On a déjà tous des outils pour gérer les versions, tu as parlé de nuget par exemple, je ne vois pas trop quel rôle les modules pourraient jouer là dedans, à part éventuellement en terme de réflexion, qui peut toujours s'ajouter.
Binary distribution : C'est un problème potentiel. Mais d'un autre côté, les autres langages ont bien réussi à résoudre ce problème. Quand on distribue une assembly .NET, c'est bien un binaire qu'on distribue, et ça fait déjà 15 ans que ça dure sans problèmes. Ce qui va être plus dur est d'avoir un format compatible entre différents vendeurs (Microsoft a proposé d'open-sourcer le sien, Clang a dit qu'il était hors de question qu'ils l'utilisent). Mais la situation ne sera pas pire que ce qu'elle est aujourd'hui : On risque de devoir quand même compiler une bibliothèque pour le compilo qu'on utilise, comme on le fait aujourd'hui. C'est juste qu'on risque aussi de ne pas avoir besoin de le faire, si le mainteneur de la bibliothèque nous fourni un module compilé pour notre compilateur, chose qui était très difficile avant, à cause des multiplicités de gestions de macros. Donc la situation ne devient pas parfaite, mais elle s'améliore quand même.

Et sinon, pour avoir expliqué à pas mal de débutants, oui, les #include, c'est compliqué. Et parfois même des professionnels aguerris galèrent pendant des heures pour faire un #include dans certains contextes...
3  0 
Avatar de kipy4
Membre du Club https://www.developpez.com
Le 30/06/2015 à 13:51
Cette monture a l'air sympa !

J'espère qu'ils ont prévu un vrai désinstalleur ce coup-ci * rêve tout haut *
2  0 
Avatar de goldbergg
Membre actif https://www.developpez.com
Le 01/07/2015 à 13:41
"Si on possède un compte développeur chez MS on aura donc droit à la version Community ?"
La Community Edition est en libre téléchargement, n'importe qui peut l'avoir (mais pas forcement l'utiliser)

Sinon pour le Dev Android il y a trois possibilité


Si je ne me trompe, pour xamarin il faut un abonnement (y a une version gratuite mais très limité)
2  0 
Avatar de Truelle
Membre actif https://www.developpez.com
Le 21/07/2015 à 9:55
Pour ma part, utilisant la RC depuis un bon moment, je trouve cette dernière plutot instable quand je compare avec la version 2013. Je me suis empressé de voir les release notes de la version finale, en vain pour voir si il y avait des bugs fixes sur les points qui me posent problème.

Je reprendrai la version Pro quand elle sera disponible histoire de travailler avec une version finale en espèrant que ce sera mieux sinon tant pis, je ferai avec.

L’édition Community est une version gratuite qui dispose de toutes les fonctionnalités de l’édition professionnelle
C'est pas tout à fait vrai comme la version Pro dispose de CodeLens, une fonctionnalité géniale dont il est difficile de se passer. Juste pour ça je bosse avec la version Pro.
2  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 21/07/2015 à 15:04
Citation Envoyé par Issam Voir le message
je n'arrive pas a trouver une version offline de l'installateur VS 2015 .

quelqu'un sait si ça existe ?
C'est une iso a télécharger

Pour la community :
http://download.microsoft.com/download/0/7/1/071447A8-2FFB-401A-9ABF-F749663286AC/vs2015.com_fra.iso

Pour les autres, c'est dans le menu accordéon à gauche un peu plus bas :
https://www.visualstudio.com/downloads/download-visual-studio-vs
2  0 
Avatar de Médinoc
Expert éminent sénior https://www.developpez.com
Le 30/07/2015 à 22:42
Donc en gros, Visual Studio supporte enfin le Edit-and-Continue en 64 bits?
2  0 
Avatar de The_badger_man
Rédacteur https://www.developpez.com
Le 25/09/2015 à 13:05
Systèmes d'exploitation pris en charge

Windows 8.1 (x86 et x64)
Windows 7 SP1 (x86 et x64)
Windows Server 2012 R2 (x64)
Windows Server 2012 (x64)
Windows Server 2008 R2 SP1 (x64)
Configuration matérielle

Processeur de 1,6 GHz ou plus rapide
1 Go de RAM (1,5 Go en cas d'exécution sur un ordinateur virtuel)
10 Go d'espace disque disponible
Lecteur de disque dur de 5 400 tours/min
Carte vidéo compatible DirectX 9 s'exécutant à une résolution d'affichage de 1024 x 768 ou supérieure
Autres éléments requis :

Sous Windows 8.1 et Windows Server 2012 R2, la mise à jour KB2883200 (disponible via Windows Update) est nécessaire
Internet Explorer 10
Pour le développement Windows Phone :
- Windows 8.1 (x64), édition professionnelle ou supérieure
- Émulateur Windows Phone
- Processeur prenant en charge SLAT (Second Level Address Translation)
2  0 
Avatar de The_badger_man
Rédacteur https://www.developpez.com
Le 02/12/2015 à 11:50
Citation Envoyé par MikeRowSoft Voir le message
Tiens tiens Update 1!?
Microsoft aurait-il réservé le service pack pour du support technique terminé?
Les services pack (correction de bugs) n'existent plus depuis Visual Studio 2010.

Depuis Visual Studio 2012, il s'agit de mises à jour fonctionnelles.
2  0 
Avatar de miam84
Nouveau membre du Club https://www.developpez.com
Le 18/06/2015 à 8:16
De très bonnes nouvelles pour cette nouvelle version.

Déjà le suivi de trace //TODO and co, mais surtout la documentation jsDoc. Je n'ai jamais accroché aux commentaires XML de documentation que Visual Studio proposait jusqu'à maintenant. Ca ne fera pas de mal d'être un peu plus "standard" à ce niveau là aussi.

J'apprécie vraiment la politique dans laquelle se dirige Microsoft ces derniers temps.
1  0 
Avatar de tlt
Membre actif https://www.developpez.com
Le 30/06/2015 à 12:44
ça donne l'eau à la bouche. j'ai hâte que ça sorte
2  1