( http://haxe.org )

Bonjour,

Je commence à m'intéresser à ce langage mais je reste néanmoins assez dubitatif... il y a vraiment peu d'avis sur le net à son sujet, et j'ai par conséquent du mal à savoir si ça vaut vraiment le coup de s'y mettre (je souhaite compiler en particulier vers du JS et PHP).

Le typage strict m'intéresse pas mal, ainsi que la notion de classes et d'héritage qui serait un vrai plus pour du dev JS, néanmoins j'ai l'impression de faire du code un poil plus élégant en Haxe, mais qui se compile au final dans des JS ou PHP qui sont tout de suite moins regardables...

Pensez-vous qu'Haxe soit vraiment intéressant pour du développement web ? Qu'en est-il de l'optimisation ?

C'est un sujet intéressant, j'avais vu aussi ce langage mais comme toi, je trouvais pas beaucoup de retours alors j'ai préféré attendre pour voir plus en détail ce que ça donnait

Après c'est normal que le code compilé dans un autre langage soit moins regardable, mais ça veut pas dire que c'est pas optimisé. Avec GWT (qui est d'ailleurs très impressionnant), on peut transformer du Java en Javascript et le résultat est super optimisé (probablement plus que si on le faisait avec du JS "à la main") alors que quand tu regardes la tête du code...

Je crois aussi que je vais attendre un peu, je me vois pas changer toutes mes habitudes pour un langage dont je ne suis pas vraiment convaincu.

Puis je trouve ça assez fastidieux de devoir recompiler toutes les 5 minutes pour voir les modifs.

L'un des rares articles que j'ai trouvé est celui-là: http://www.jetpackhq.com/blog/2012/12/04/whats-wrong-with-haxe/

J'ai jamais utilisé de langage fortement typé, mais j'avoue que le dernier exemple me rebute pas mal... je sais pas comment ça se passe en Java ou C++ mais j'apprécie bien d'avoir des "équivalents booléens" de chaque type en JS et PHP, sans avoir à faire if(foo != '') ou encore if(bar > 0).

En plus de ça j'ai pas l'impression que l'on puisse réellement coder en Haxe sans se soucier du langage de destination... il se passe quoi si je fais une implémentation des WebSockets en Haxe destinée à du node.js avec les API qui vont bien et que je passe ça en PHP ? Ou en JavaScript client ?

Au final j'utiliserai js.Lib.document.getElementById('toto') dans une classe avec héritage et implémentations, et le .textContent sera fortement typé. Ça me fait pas penser à un langage universel à part entière mais une sorte de surcouche bâtarde à différents langages.

Go demander à https://twitter.com/deepnightfr Il code tout en Haxe, vu que c'est un gars de chez Motion Twin (qui développe Haxe)

Bonjour , depuis bientôt 3ans certains ont ils poursuivi l'expérience avec ce langage J'avoue que j'aime bien le concept.

J'ai pas approfondi avec Haxe… ce qui m'intéressait le plus, c'était de pouvoir le compiler du même code dans différents langages, mais en pratique c'était pas du tout ça, je me retrouvais à faire du Haxe pour PHP, du Haxe pour JS, parce qu'évidemment on a souvent besoin de fonctions natives, qu'Haxe rend juste plus difficiles à utiliser (c'était une calamité à utiliser avec le DOM dans mes souvenirs), mais du coup c'était au final très difficile de faire du code isomorphique, et ça a donc perdu pas mal de son intérêt à mes yeux.

C'était déjà une de mes grosses craintes à l'époque (cf. mon message « précédent » (de 2012)), et ça s'est avéré être le cas.

C'était aussi juste horrible pour utiliser des librairies externes, en devant déclarer une classe externe avec toutes les méthodes, ou avec un genre d'eval « untyped » ou tu passes ton code qui appelle la librairie sous forme de chaîne de caractères.

Par principe, ça rend également plus difficile (impossible ?) la possibilité de partager du code avec la communauté d'un langage donné, typiquement tu peux difficilement publier une librairie PHP ou JS codée en Haxe, parce qu'elle se ballade avec tout le runtime Haxe. (Et d'ailleurs, est-ce qu'il y a un moyen propre d'exposer son code Haxe à du code natif, en respectant les normes d'import du langage ? Je ne trouve que de la doc sur l'utilisation de fonctions natives, mais pas pour exposer des bindings provenant du code Haxe.)

Le langage a peut-être pas mal évolué depuis le temps par contre, mais j'ai clairement perdu l'envie d'en faire, y'a quasiment plus rien qui m'intéresse dans la syntaxe et que je n'ai pas dans les autres langages que j'utilise. Les difficultés d'interfaçage avec le langage sous-jacent sont pour moi problème majeur, et j'estime qu'Haxe est un mauvais choix dès qu'on veut vraiment interagir avec l'écosystème du langage cible, ce qui est systématiquement le cas dans mon utilisation.

Ok ok je vois du coup ça me refroidit même si j'avoue que ce style d'outils m'intéressent , là je me suis installé Opalang mais j'ai aussi quelques craintes sur l'utilisations de Lib Js externes car il faut tout packager d'après ce que je comprend. Moi je viens surtout des langages dynamiques et j'ai un intérêt pour la prog fonctionnelle aussi bien Elixir qui est proche de Ruby que du Ocaml ou du Clojure via Clojurescript. Typiquement ce qui me tente dans les Opalang , Ur/web c'est l'aspect sécurité mais je comprend que ce coté tout en un rebute pas mal de monde et aura peut être du mal à percer dans le web je ne sais pas ce que ça t'inspire et si tu connais ces technos.

Je ne connais ni Opa, ni Elixir, ni ClojureScript.

---

Opa a une syntaxe sympa, son approche fonctionnelle m'attirerait bien plus que Haxe. Le premier exemple sur la page d'accueil a un goût très prononcé de JSX d'ailleurs (mais JSX est extrêment proche du JS contrairement à Opa, et a juste une légère surcouche syntaxique pour le HTML).

Le fait qu'Opa gère en interne la communication entre le client et le serveur, c'est un nogo total pour moi. Une abstraction syntaxique légère et compréhensible, oui, mais une abstraction de cet ordre, qui cache totalement l'implémentation qui va être faite, les protocoles utilisés, qui sont complètement inaccessibles depuis le code que tu écris, non. En l'occurrence, du code qui est « simultanément pour le navigateur et serveur », ça pue l'abstraction à problèmes (sauf dans le cas peu probable (pour un truc comme ça) où elle est parfaite).

Le langage a sa propre syntaxe pour accéder à une bases de données, automatiser l'écriture des requêtes (WTF ?), et tu as le choix uniquement parmi les bases de donénes supportées par le langage. Encore une fois, ça sent l'abstraction foireuse.

Les appels non bloquants intelligents (qui définissent ce qui bloque ou pas en fonction des variables que tu utilises), ça a l'air sympa, mais c'est à nouveau une abstraction implicite plutôt qu'explicite, et ça a tendance à attirer les problèmes.

Je ne comprends pas en quoi Opa supporte le HTM5 et CSS3, mais si ce truc est aussi une abstraction au HTML et au CSS, ça ne m'insipre rien de bon (ce côté tout en un qui comme tu le dis rebute pas mal de monde, car il t'emprisonne dans une technologie et ses possibilités, au lieu de te donner de la liberté, du choix et de la flexibilité).

Le typage statique et le type checker, c'est un plus. Par contre en JS natif, tu as Flow qui fait office de type checker, je l'ai jamais utilisé mais ça a l'air prometteur (encore un truc de Facebook, comme React/JSX, technologiquement je trouve qu'il y a vraiment du bon chez Facebook (et Netflix et CloudFlare) en ce moment – pas des boîtes que je porte particulièrement dans mon cœur mais faut dire qu'ils ont de très bons ingénieurs).

---

Le ClojureScript a l'air de s'intégrer pas trop mal dans l'environnement JS, sans à première vue ajouter d'abstractions dangereuses (et au contraire des additions de sécurité/typage intéressantes).

Les additions comme les structures de données immutables sont aussi très bonnes à prendre, mais il ne faut pas oublier qu'il y a immutable-js en natif qui est assez impressionant sur le sujet (KOUKOU Facebook, oui, encore ).

Bref, pour quelqu'un qui aime la syntaxe de Clojure, ça me semble valoir le coup d'essayer. De la même façon que j'ai rien contre CoffeeScript pour ceux qui aiment la syntaxe.

---

Elixir, ça m'a l'air un peu à part, dans la mesure où c'est un langage non transpilé qui tourne sur la VM Erlang. Du coup j'ai rien de plus à dire que si tu voulais utiliser Erlang, OCaml, Haskell, C++ ou que sais-je pour ton code serveur, dans ces cas là la question c'est plus les librairies existantes dans le langage en question, et son intégration avec des librairies C existantes (et/ou Erlang dans le cas d'Elixir)…

---

En bref, quand c'est principalement une question de syntaxe, mais que ça ne te masque rien et que l'on peut intéragir proprement et simplement avec l'écosystème de destination, je dirais que ça vaut le coup d'essayer pour peu que la syntaxe te plaise.

Plus il y a d'abstractions qui sont ajoutées et qui t'éloignent de l'écosystème cible, voir t'emprisonnent dans l'écosystème-langage-framework source, moins ça m'inspire confiance, et en l'occurrence c'est pour ça que j'éviterais clairement Haxe et Opa (du peu que j'ai vu).

Par rapport à la sécurité du langage que tu sembles chercher, en JS, munis-toi d'un outil comme standard (feross/standard sur GitHub), ESlint, JShint, JSlint (dans mon ordre de préférence) bien configuré (sauf pour standard qui est déjà bien configuré), voir essaie un type checker comme Flow. Pour le reste, saisis-toi des innombrables librairies de l'écosystème JS, qui seront celles de ton choix, et pas les fonctionnalités limitées d'une abstraction fermée ; si tu veux te simplifier la vie, en vrac, Browserify pour avoir une gestion de modules propre côté client et partager du code entre serveur Node.js/io.js et navigateur, Babel pour profiter des additions ES6/7 dès maintenant, lodash pour des utiliitaires sympas, React, ou plus classique, Swig, Jade, etc. pour compiler des templates aussi bien côté serveur que client, Highland ou RxJS (entre autres) pour la programmation fonctionnelle réactive (un cadeau du ciel en JS à mes yeux).

Les abstractions et le sucre syntaxique, ça peut être bon à prendre quand c'est ciblé, et qu'il y a une correspondance directe avec le langage (par exemple, Regenerator pour transpiler des générateurs ES6 en ES5 c'est un peu à la limite question correspondance avec le langage, mais ça a l'avantage de ne faire qu'une chose, et de le faire décemment, donc j'utilise), et je me méfierais vraiment de toutes les abstractions plus ambitieuses, surtout quand elles te rendent captif et qu'elles tentent de masquer le fonctionnement même d'une technologie, plutôt que de se construire autour en harmonie.

J'avais dit « en bref » ?

Y

Y a des chances que je regarde Flow vu que je fais déjà un peu de React . Je comprend d'où vient ta méfiance moi les abstractions ne m'ont jamais forcément gêné d'autant que j'ai parfois remarqué que certains les dénoncent pour mieux se la jouer , exemple sur Rails dont un mec se plaignait que c'était trop magique est trop simple pour lui même si cela était vrai ce qui reste encore à démontrer je trouve que ça permet de te focaliser sur la logique de ton application et faire abstraction de choses qui te font clairement chier après certains aiment réellement tout gérer de A à Z le plus finement possible je trouve logique que certains outils soient créer pour limiter le nombres d'erreurs comme le cas le plus connu de la réservation d'avions : Dans le temps avec les premières implémentations du retour arrière sur les navigateurs un retour lors de la réservation d'un vol pouvait te bousiller ta réservation en changeant tes choix aléatoirement , ça explique en partie la création d'Ocsigen si je ne m'abuse et c'est aussi la raison d'être de langages comme Opa ou Ur/web qui te forcent en effet à te soumettre à une techno donnée mais ça peut être un avantage , typiquement dans le web où tu dois habituellement 36 langages ah et tu passes sur tel framework il faut changer de langage pour les templates entre les Twig , les ERB , les Haml , les Jinja2...
Après concernant Opa c'est encore jeune et certaines choses me rebutent comme la gestion des librairies JS qui me semble plus complexe que dans un framework plus classique.

Tu prends un exemple risqué avec Rails, aujourd'hui j'ai l'impression que c'est l'un des frameworks web sur lequel tu peux le plus facilement te péter la gueule avec un code qui a l'air parfaitement correct, principalement à cause de la recherche d'une API « magique » plutôt qu'explicite.

---

J'ai rien contre les abstractions en général, j'en use (et abuse) moi-même tous les jours. Par contre j'ai beaucoup plus confiance en une abstraction très ciblée et comphérensible, à l'opposé d'une abstraction envahissante, qui fait plein de trucs à la fois, et qui tente de masquer la nature même du problème qu'elle abstrait (du genre avoir toute la couche HTTP entre deux fonctions innocentes dans un même fichier).

J'ai donc tendance à composer de nombreuses petites abstractions indépendantes, pour me simplifier la vie sans prendre trop de risques, et surtout sans perdre en liberté (si je veux changer une librairie par une autre pour faire un job donné, c'est rarement un problème).

Ça tient pas mal de la philosophie Unix en fait ; des librairies qui font une chose, et le font bien, qui sont construites autour d'une interface universelle (à appliquer au langage choisi, mais en JS ça sera typiquement les modules CommonJS (de plus en plus les modules ES6), les promises, les streams et les event listeners Node) ce qui leur permet de facilement interagir entre elles, et qui sont transparentes sur leur fonctionnement (pas de mauvaises surprises en utilisant une librairie qui tente de faire de la magie). C'est en m'entourant de librairies qui respectent ça que j'ai le plus le sentiment d'être efficace, et que j'ai le plus confiance dans mon code et ses dépendances.

Je crois que c'est ce dernier paragraphe que j'essaie d'accoucher depuis le début en fait, ça résume plutôt bien mon point de vue sur le sujet.

C'est l'outil le plus sympa qu'il m'ait été donné de voir pourtant , je compte aussi toucher à Flask et Django et j'ai déjà touché à Sinatra pour un projet perso (mon Portfolio en SPA) , je compte toucher à Symfony mais le PHP est pour moi un langage bien dégueu une fois qu'on a goûté à l'élégance de Ruby .

surtout sans perdre en liberté (si je veux changer une librairie par une autre pour faire un job donné, c'est rarement un problème). Justement Rails est bien pour ça .
Après tout est question de goût , j'aime me masquer des choses quand je réalise que je perdrais un temps fou à coder un truc qui n'apportera rien à mon application et que d'autres ont fait mieux que moi .

Je suis tombé sur https://www.nativescript.org/ aujourd'hui. Il se vend bien et je pense que ça pourrait être intéressant de s'y pencher 1h ou 2.

J'ai vu ça aussi et j'attend aussi Reactnative avec impatience