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 !

JS++ : du JavaScript étendu avec les classes
Les types, etc. grâce à ce langage de programmation pour applications Web et mobiles

Le , par vermine

26PARTAGES

9  1 
JS++ : du JavaScript étendu avec les classes, les types, etc.
grâce à ce langage de programmation pour applications Web et mobiles


JS++ ou JavaScript++ est un langage de programmation pour construire des applications Web et mobiles. Il étend le langage JavaScript en apportant une gestion des types, des classes et d'autres fonctionnalités.

En principe, si vous connaissez bien le JavaScript, vous n'aurez aucun souci avec JS++. Il vous suffit d'intégrer dans votre code les « extensions » que vous désirez.

Par exemple, le typage est garanti à deux niveaux : la compilation et l'exécution. Une variable déclarée comme int représentera toujours un entier. Ce qui n'était pas nécessairement vrai jusqu'alors. Fort heureusement, ce typage est optionnel. Ce qui signifie que vous pouvez faire évoluer votre code au fur et à mesure en faisant coexister les déclarations JavaScript standards et les types de JS++.

Le langage est multiplateforme, il peut s'exécuter dans le navigateur et sur le serveur.

Ce langage gère notamment :

  • les types tels que bool, string, external, byte, int, unsigned short, float, Arrays, etc. ;
  • les modifiers comme final, static, etc. ;
  • les classes ;
  • les imports ;
  • les modules ;
  • le drag & drop ;
  • et bien d'autres choses.


En fait, le compilateur Onux JS++ unifie les types dans un seul type connu comme le type externe unifié. La vérification des erreurs au moment de la compilation fait de JS++ un langage semblable à Java (ce n'est qu'un exemple).

Il est à noter que JS++ n'est pas open source et n'est pas entièrement gratuit. La bibliothèque standard l'est, rassurons-nous, mais les extensions ne le sont pas toutes. Je pense aux outils de cartographies et de graphiques.

Serions-nous en train de parler d'un rival à TypeScript ? Pour ça, il faudrait suivre un peu plus les spécifications ES6. Il faut savoir que JS++ est plus vieux et évolue selon (parfois du moins) les retours utilisateurs. Il y a cependant des différences au niveau des instructions de compilation qui rendraient JS++ plus simple d'utilisation. Le débat est ouvert. Que ce soit vis-à-vis de TypeScript ou bien d'autres technologies.

Téléchargement
Documentation

Source : Le blog officiel

Et vous ?

Que pensez-vous de JS++ ?

Rendez-vous sur nos forums des bibliothèques et frameworks JavaScript !

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

Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 08/06/2016 à 15:35
Non ce qui est triste c'est qu'on continue à enseigner qu'il n'y a qu'une seule façon de faire de la POO c'est d'utiliser la notion de classe.

C'est tout de même mal heureux que plus de 80% des développeurs soient persuadé que pour faire de la programmation-objet il faille en passer par des langages qui ne connaissent que la notion de classe et d'instance et pas la notion d'objet. Un comble. Alors on invente des patterns singleton et plein de trucs pour pallier les manques de ces langages qui s'étant contraints à la classe et instance n'ont d'autre choix que de bricoler des théories monstrueuses et des patterns appris comme si c'était la seule approche.

Alors lorsqu'un langage apparait avec des notions natives dans le langage qui ne nécessitent plus tout ce barda le développeur comme s'il était devenu incapable d'ouvrir son esprit dit que la chose est mal foutue, absurde, etc.

Il est étonnant de voir que dans des langages suffisamment bien pensés pour ne pas avoir besoin constructions capilotractées se voient critiqué du manque de ces constructions.

Bref on enseigne à 99,99% des développeurs que la seule façon de faire de l'objet c'est classe/interface/instance. Et on crie haut et fort que c'est la seule bonne façon de faire. Et pour le prouver on ajoute si tout le monde ou presque le dit c'est que c'est vrai.

Heureusement que les anciens ne se sont pas contentés de rester sur les langages procéduraux qui à l'époque représentaient la majorité de l'enseignement.

Mais je suis confiant, car quelque soit le langage même le plus strict quant à sa vision de la théorie ont voit toujours apparaitre des gens qui cherche à faire mieux à faire différemment.

Quant au critique qui dit que EcmaScript est un langage qui n'est pas adapté au besoin d'aujourd'hui je leur réponds qu'il est tellement inadapté que EcmaScript se voit intégré dans de plus en plus de solutions. Qu’il a fini par quitter le domaine du web où il est né pour se répandre partout! Il est sûr que son inadaptation en a fait un candidat prisé.

Tout cela me rappelle d'autres guerres de chapelle. X25 et IP un très structuré fortement normalisé avec des tonnes de capacités normalisées l'autre simple souple et facile à mettre en oeuvre et se contentant de normaliser le minimum.
SOAP et Rest un structuré normalisé fortement documenté outillé, etc. l'autre simple léger se contentant de normaliser le minimum.
Compilé/Interprété là encore la compilation apporte rigueur structure, etc. et l'interprétation souplesse, etc.

Et je constate aujourd'hui que SOAP est utilisé et que Rest aussi. Que les concepts de X25 sont présents chez tous les opérateurs réseau (même si X25 lui-même est marginal) et qu’IP est largement répandu. Quant à la Compilation/Interprétation je constate que les deux sont présent que beaucoup de langage compilé embarque des notions venues de l'interprétation et que l'interprété utilise de plus en plus de notions de compilation au point que pour certain on ne sait plus trop où les situé.

Je pense que la programmation à base de classe est un outil formidable et qu'elle a de très beaux jours devant elle. Mais qu'il y a une place tout aussi grande dans énormément de domaines où cette approche montre ses limites.

Quant à JavaScript il n'est pas parfait comme tous les langages, mais les reproches à lui faire ne sont surement pas ceux que l'on peut voir dans la majorité des posts sur les forums.

Souvent quand je lis les questions sur le forum je pense à quelqu'un qui utiliserait les mots japonais pour écrire comme en français. C’est sur que c'est mal foutu le japonais lorsqu'on veut écrire sa phrase comme en français. Mais lorsqu'on utilise les notions du japonais étrangement c'est limpide.

A+JYT
7  0 
Avatar de Watilin
Expert éminent https://www.developpez.com
Le 08/06/2016 à 12:58
Je vois beaucoup de jugements personnels sur ce fil. Et aussi des affirmations qui sont simplement fausses.
Ceux qui veulent absolument parler de programmation objet avec JS doivent se rappeler que le paradigme de ce langage, ce n’est pas les classes, c’est les prototypes. C’est ça et seulement ça qui fait toute la différence, et qui donne l’impression à ceux qui ne connaissent pas suffisamment que le langage est mal foutu.

Pour le débat entre classes et prototypes, voir la conversation L’opérateur new : bonne ou mauvaise pratique ?
5  0 
Avatar de goldbergg
Membre actif https://www.developpez.com
Le 07/06/2016 à 17:41
Bin tous le monde veux faire du JS, mais sans se faire chier a apprendre à l'utilisé, sois disant trpo mal foutu et trop compliqué (alors que c'est un des langage les plus simple...), donc on se retrouve avec tous ces pseudo langage...
4  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 08/06/2016 à 17:15
Pareil recentrer JS sur ses fondamentaux quitte à autoriser dans le navigateur l'exécution de bytecode, ASM, ou autre, produit par d'autres langages.

Au départ la balise script permettait d'exécuter d'autre langage. En 1995 j'exécutais du TCL dans le navigateur. IE y avait ajouté VBScript

Alors pourquoi pas un WASM pour tous les langages qui veulent produire du compilé, du type, etc.
Ce ne serait pas un pb de compatibilité avec l'existant je ne vois pas de restriction à ne proposer que WASM dans le navigateur. l'interprète EcmaScript pouvant très bien être un code WASM comme un autre.

Quant à EcmaScript je vote moi aussi pour la suppression des sucres en tout genre et des deprecated.

Enfin le dernier point qui pour moi est aussi grandement améliorable et qui n'a rien avoir avec le langage, mais que bien trop souvent on confond, c'est le binding DOM avec le langage.
Je pense que l'API DOM n'est pas cool. Pour preuve la liste interminable de lib qui cherche à améliorer cette interaction. Une API plus HTML et moins XML serait appréciable, moins verbeuse, plus intuitive.

A+JYT
4  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 08/06/2016 à 16:36
Content de voir autant de gens défendre la POO par prototypes, ça fait plaisir à voir un peu d'ouverture d'esprit par rapport aux modèles dits "conventionnels".

Beaucoup essaient de transformer JavaScript en Java depuis la naissance du langage, d'où son nom bâtard. Pour la petite histoire, Brendan Eich a ajouté tardivement dans la phase de conception du langage les constructeurs et l'opérateur new, à la demande de Netscape. Netscape travaillait avec Sun à l'époque et pour des raisons marketing, ils voulaient faire coïncider la syntaxe malgré le fait que les deux langages avaient des différences fondamentales (voir http://speakingjs.com/es5/ch04.html).

Cette pression pour faire ramener le langage dans la zone de confort de la majorité des devs (c'est à dire la programmation OOP classique enseignée dans les écoles) est toujours présente aujourd'hui. Le dernier cas le plus représentatif est l'ajout du mot-clé "class" en ES6 qui a été vivement critiqué par de nombreux experts, et dont le seul intérêt est d'ajouter du sucre syntaxique pour attirer plus de développeurs quitte à les tromper sur l'implémentation interne.

J'aimerais beaucoup voir non pas un JS++ mais un JS--, dépouillé de tous ses éléments dépréciés et focalisé sur ses meilleurs aspects avec la vision originale, dans la lignée de Self et Scheme. WebAssembly est peut-être la voie de sortie pour en finir avec ce langage chimère : si TypeScript et consors viennent à compiler en WASM, il pourrait en être de même avec un Mocha ou un LiveScript.
3  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 08/06/2016 à 21:21
@BugFactory: que je sache, le message de sekaijin n'était pas dirigé contre toi non plus. Pas la peine de s'énerver pour si peu

Ce n'est pas un secret qu'il y a un problème avec l'enseignement de JavaScript :
- il est boudé dans les écoles
- le net est bourré de ressources médiocres ou obsolètes du style w3schools ou toutjavascript
- c'est un langage utilisé par beaucoup d'amateurs en continuité de HTML et CSS
- beaucoup de devs sont dépendants de leurs bibliothèques/frameworks
- c'est un langage très permissif avec lequel il est très facile de faire n'importe quoi (mais aussi de belles choses heureusement)

Par expérience, que ce soit dans mon boulot, dans mon entourage ou sur ces forums, je ne peux que constater les dégâts: la majorité code en JS avec très peu de connaissances sur ce langage. En ce sens, les prototypes sont en quelque sorte à la frontière entre les bons et les mauvais développeurs JS. Je m'en sers souvent pour trier rapidement les candidats lors des entretiens. Et voilà le résultat: sur cinq candidats, deux n'ont aucune idée de ce dont je parle, deux autres font vaguement le lien avec la prog objet, et un seul sait me donner une définition satisfaisante telle que "l'objet auquel un autre objet hérite des propriétés". Tous ont mis JavaScript sur leur CV mais un seul connaissait à peu près ce mécanisme de base du langage.

Donc je comprends la réaction de sekaijin, qui a sans doute entendu comme moi un bon paquet de fois que "JavaScript c'est nul y'a pô de classes". C'est une raison suffisante pour écarter d'office une bonne partie des détracteurs. Après, s'il y en a qui comprennent parfaitement tous ces concepts et critiquent quand même la POO prototypée par rapport à la POO classique, ça m'intéresse d'entendre les arguments parce que je n'en ai jamais trouvé jusqu'ici.
3  0 
Avatar de Mouke
Membre averti https://www.developpez.com
Le 07/06/2016 à 17:35
Encore un nouveau surensemble Js qui tend à retransformer le langage initial. Exactement ce que je reprochais dans le topic sur les langages détestés.

J'ai l'impression que c'est une tentative foireuse de faire de Js une espèce de C++... Le modèle objet de Js (par prototype me semble), c'est pas sensé offrir des possibilités différentes à celles du modèle Java traditionnel ? Pourquoi revenir en arrière ?

Je suis confus, je ne comprends pas l'intérêt de cette librairie.
2  0 
Avatar de Programmator
Membre du Club https://www.developpez.com
Le 07/06/2016 à 19:38
Typescript et toutes les surcouches et frameworks du genre, malgré leurs qualités, sont juste des renforts du manche du tournevis pour que l'on puisse taper avec sur les clous, mais ça ne vaut toujours pas un bon vieux marteau.
L'image est tout à fait pertinente.
On peut espérer que le langage Javascript évolue vraiment vers une syntaxe plus conventionnelle pour le programmeur objet. D'ailleurs, c'est déjà ce qui est en train de se passer avec la nouvelle norme Ecmascript 6 (ES6); cf. cette page. Cette norme introduit notamment les classes et l'héritage via les mots clés class et extends, ainsi que les expressions lambda.
Je pense qu'on va finir par arriver à un vrai langage objet, plus adapté aux besoins des applications complexes d'aujourd'hui (d'ailleurs avant, on ne parlais même pas d'"applications javascript". C'est une question de patience. En attendant, TypeScript est tout de même une alternative intéressante, je trouve...
2  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 07/06/2016 à 20:17
Je ne sais pas trop quoi penser de ce nouveau sur-ensemble de JavaScript dans la mesure où il n'est même pas Open Source et n'est pas totalement gratuit.
Ce langage me semble très jeune, sans réelle communauté ou sponsor.
Le système de typage me semble assez basique et loin de TypeScript par exemple qui offre des concepts d'union de types, d'intersection de types et divers mécanismes pour gérer le polymorphisme et la généricité sans sacrifier au contrôle des types.
Je viens de parcourir la documentation technique, et je ne vois pas de valeur ajoutée au langage de Microsoft. S'il y a des gens qui programment avec JS++, ça m'intéresse de connaître leurs motivations et leurs retours d'expérience.
2  0 
Avatar de seikida
Membre actif https://www.developpez.com
Le 08/06/2016 à 10:48
Tout a fait d'accord @goldbergg.
Moi j'si toujours du mal a comprendre le raisonnement des ceux qui haissent le Javascript.
J'ai plus l'impression que cette haine vient plus du fait qu'ils ne comprennent pas comment ce language fonctionne et cherche toujours a le comparer avec un autre language (C, C++, Java, Php, etc...).
Personnellement je ne developpe pas de la meme maniere en Php et/ou Java qu'en Javascript et je n'essaie pas de trouver des similitudes.
Jusqu'a present, je n'ai rencontre aucune personne ayant un bon niveau en Javascript qui me dit: "le JS c'est nul"
5  3