Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Brendan Eich, créateur du JavaScript, devient PDG de Mozilla

Et il ne va clairement pas s'ennuyer

Brendan Eich, créateur du JavaScript, devient PDG de Mozilla

Le 25 mars 2014 à 16h10

Alors même que Mozilla vit actuellement un tournant de son histoire face à une concurrence qui ne faiblit jamais, l’éditeur décide de changer de PDG. Le nouveau venu est loin d’être un inconnu puisqu’il s’agit de Brendan Eich, le créateur du JavaScript.

brendan eich

Un nombre croissant de défis 

La période est actuellement un peu floue pour Mozilla. Sur le terrain des navigateurs, Firefox doit faire face à la progression rapide et déchainée d’un Chrome que rien ne semble pouvoir enrayer. Dans le même temps, Internet Explorer s’est lui-même nettement amélioré et la version 11 remporte un joli succès auprès des utilisateurs.

 

Firefox doit quant à lui redoubler d’efforts et la future mouture 29, actuellement en bêta, proposera notamment une interface rafraichie ainsi qu’une synchronisation beaucoup plus simple. On a pu voir cependant à la faveur de l’annulation de la version spécifique à Windows 8 que les ressources de l’éditeur étaient limitées : malgré un travail d’un an et demi, tout le travail est tombé à l’eau à cause d’un manque flagrant de testeurs.

Brendan Eich, nouveau PDG de Mozilla 

Alors que Mozilla a de grandes ambitions dans le domaine mobile avec Firefox OS, la question du PDG devait également être réglée. Gary Kovacs avait en effet annoncé son départ en avril de l’année dernière. Depuis bientôt un an, l’entreprise se cherche donc un nouveau PDG et c’est Jay Sullivan qui a dirigé la structure par intérim. Mais cette recherche est désormais terminée puisque Brendan Eich est officiellement le nouveau patron de Mozilla.

 

Ceux qui suivent l’actualité informatique connaissent sans doute ce développeur, à qui l’on doit notamment le JavaScript, un langage très largement utilisé aujourd’hui par la quasi-totalité des sites web. Le nom n’est pas nouveau non plus en interne car Eich a été longtemps dans le conseil d’administration de la fondation Mozilla. En 2005, à la création de la Mozilla Corporation, il en devient le directeur technique. Il occupait ainsi ce poste depuis cette date.

Firefox OS devient la grande priorité 

Cet ancien de Netscape Communications et du projet Mozilla va donc diriger désormais l’entreprise, notamment à travers la négociation difficile du virage mobile. Dans une interview accordée à Cnet, Brendan Eich indique que la plupart des efforts vont être redirigés vers Firefox OS, car il reste encore beaucoup de travail. Cela signifie que Firefox lui-même, en tant que navigateur, ne sera plus nécessairement le produit le plus mis en avant par l’éditeur. Il s’agit du même type de transition que chez Google : le navigateur est jugé suffisamment stable et efficace pour servir de base à tout un écosystème (le tout en utilisant une base Linux).

 

Selon Eich, Mozilla va continuer à se concentrer sur le marché des smartphones à très bas prix, notamment le segment des 25 dollars. Un objectif particulièrement délicat à atteindre tant les contraintes sont conséquentes : le très faible coût de production ne permet qu’une faible puissance, qui doit elle-même suffire à alimenter le système de manière à ce que l’expérience reste agréable. Or, les premiers modèles de téléphones Firefox OS péchaient justement sur le terrain des performances et on attendait des modèles plus puissants.

Compter sur la scène mobile 

Cette volonté de viser l’entrée de gamme avant tout pourrait également permettre à Mozilla de gagner rapidement en parts de marché. Pour Eich, l’un des objectifs est de « compter » sur la scène mobile et de pouvoir influencer les développeurs. Mozilla devra d’ailleurs mettre en place un nombre plus important de services à disposition, et l’un d’eux est d’ailleurs le Mozilla Location Service. L’éditeur espère également faire davantage compter Firefox dans le monde mobile car, disponible uniquement sur Android, il a du mal à se faire une place au soleil. D’autant que cela permettrait de casser le quasi-monopole du moteur de rendu Webkit dans ce domaine.

 

Certains se demanderont peut-être comment les tâches sont distribuées entre Brendan Eich et Mitchell Baker, l’actuelle présidente de la fondation Mozilla. Les deux responsables ont travaillé ensemble depuis de nombreuses années, mais Baker gardera le contrôle général de la fondation et de l’orientation globale. Elle préside également aux choix qui sont faits dans les éléments et fonctionnalités à inclure dans Firefox. Cependant, tout le fonctionnement opérationnel de l’entreprise dépendra de Brendan Eich, de même que la négociation des contrats, la réalisation des produits, et l’ensemble des efforts à faire pour parvenir aux objectifs.

Commentaires (95)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Très bonne nouvelle <img data-src=" />



Et dire qu’il y a encore 5 ans le JS était encore très mal vu…

votre avatar







Ujoux a écrit :



Très bonne nouvelle <img data-src=" />



Et dire qu’il y a encore 5 ans le JS était encore très mal vu…







Perso, je vois le JS d’un tres mauvais oeil, comme la plupart des technos web … des patch sur des patch pour faire un truc qui fonctionne …



Le JS est un truc vraiment moche par moment a voir dans certains projets et ca permet des choses que les technos web ne permettent a la base pas du tout car non prevu initialement pour, geniale.



Je prefere de loin les applis connectees, ce qu’aurait du etre le web a la base que ces monstres de browser qui essaient de faire tout et n’importe quoi maintenant … au point de vouloir etre des OS<img data-src=" />









En gros, mettre le gars a l’origine d’une telle techno(souvent comparer analogiquement a l’assembleur) a la tete de mozilla, je sais pas si c’est vraiment une bonne nouvelle


votre avatar







Lafisk a écrit :



Perso, je vois le JS d’un tres mauvais oeil, comme la plupart des technos web … des patch sur des patch pour faire un truc qui fonctionne …



Le JS est un truc vraiment moche par moment a voir dans certains projets et ca permet des choses que les technos web ne permettent a la base pas du tout car non prevu initialement pour, geniale.



Je prefere de loin les applis connectees, ce qu’aurait du etre le web a la base que ces monstres de browser qui essaient de faire tout et n’importe quoi maintenant … au point de vouloir etre des OS<img data-src=" />









En gros, mettre le gars a l’origine d’une telle techno(souvent comparer analogiquement a l’assembleur) a la tete de mozilla, je sais pas si c’est vraiment une bonne nouvelle







Tu as juste vu du JavaScript fait par des personnes qui ne savent pas l’utiliser…



Et ne t’inquiètes pas pour Mozilla… Brendan Eich a participé à la création de JavaScript depuis 1995 chez Netscape, le projet mozilla.org en tant qu’architecte depuis 1998 et est CTO depuis 2005.



En revanche, son arrivée est contestée du simple fait de ses positions anti-gay très marquées…


votre avatar







Lafisk a écrit :



Perso, je vois le JS d’un tres mauvais oeil, comme la plupart des technos web … des patch sur des patch pour faire un truc qui fonctionne …



Le JS est un truc vraiment moche par moment a voir dans certains projets et ca permet des choses que les technos web ne permettent a la base pas du tout car non prevu initialement pour, geniale.



Je prefere de loin les applis connectees, ce qu’aurait du etre le web a la base que ces monstres de browser qui essaient de faire tout et n’importe quoi maintenant … au point de vouloir etre des OS<img data-src=" />







En gros, mettre le gars a l’origine d’une telle techno(souvent comparer analogiquement a l’assembleur) a la tete de mozilla, je sais pas si c’est vraiment une bonne nouvelle





+1. Et je suis dev. Javascript <img data-src=" />


votre avatar







EMegamanu a écrit :



Tu as juste vu du JavaScript fait par des personnes qui ne savent pas l’utiliser…



Et ne t’inquiètes pas pour Mozilla… Brendan Eich a participé à la création de JavaScript depuis 1995 chez Netscape, le projet mozilla.org en tant qu’architecte depuis 1998 et est CTO depuis 2005.



En revanche, son arrivée est contestée du simple fait de ses positions anti-gay très marquées…





Clair, j’ai fait pas mal de JavaScript jQuery et du NodeJS, et plus on l’utilise, plus on se rend compte qu’il fait tout ce qu’on veut, et correctement.

Et en plus de ça, avec le fait que IE8 ne va plus être maintenu d’ici 15 jours, on va bientôt ne plus avoir à ce soucier des navigateurs qui comprennent rien au JS.



Franchement, le problème du JS aujourd’hui, c’est que tu dois plus ou moins tout coder en double, à cause d’IE6-7-8. On enlève ces trois navigateurs et personnellement je n’aurais plus rien à reprocher au JS.


votre avatar







Lafisk a écrit :



Perso, je vois le JS d’un tres mauvais oeil, comme la plupart des technos web … des patch sur des patch pour faire un truc qui fonctionne …



Le JS est un truc vraiment moche par moment a voir dans certains projets et ca permet des choses que les technos web ne permettent a la base pas du tout car non prevu initialement pour, geniale.



Je prefere de loin les applis connectees, ce qu’aurait du etre le web a la base que ces monstres de browser qui essaient de faire tout et n’importe quoi maintenant … au point de vouloir etre des OS<img data-src=" />



En gros, mettre le gars a l’origine d’une telle techno(souvent comparer analogiquement a l’assembleur) a la tete de mozilla, je sais pas si c’est vraiment une bonne nouvelle





Yep de belles applications proprio monoplateforme y’a que ça de vrai <img data-src=" />.

Les différentes technos sont complémentaires, le vieux débat du web vs appli native me parait totalement inutile, chacune répond à un besoin spécifique dans un cadre spécifique.



Pour ce qui est de Javascript j’attends de pied ferme l’ECMA Scrtip 6 qui devrait pas tarder à sortir et qui permettra de faire quelques trucs sympa et un code plus propre et moderne.


votre avatar

Un des types qui a financé la loi “proposition 8” en Californie. Bien joué Mozilla, vous vous êtes faits plein de potes aux USA. <img data-src=" />

votre avatar

Oui enfin, la très grande majorité des sites Web que vous visitez aujourd’hui contient du javascript, et une très grande partie de ceux-ci contiennent du jquery.



Donc on dira ce qu’on veux le Javascript est indispensable et dans bien des cas une alternative beaucoup plus fiable a Flash. Seulement les dev d’aujourd’hui sont tellement nuls à chier en JS qu’il préfère faire des appli flash only alors que dans la plupart des cas avec Jquery (et HTML5) tu peux en ressortir un équivalent aussi bien foutu.



Bref beaucoup de critiques sur le JS, mais tu te rend compte qu’en fait les mecs n’y pigent quedale du fait qu’ils soient des fanboys Adobe. Puis il n’y a pas photo au niveau de la bande passante, ces objet flash, deviennent… De plus en plus lourds… Alors qu’en Ajax si tu te démerde bien tu peux économiser une bande passante de folie sur ton site Web.



Et pour être honnête quel pourcentage de gens qui n’utilisent pas flash (non-natif), et ceux qui n’utilisent pas JS (volontairement désactivé car activé d’office sur tout les navigateurs)…



Donc oui moi je vois une bonne opportunité pour Mozilla d’avoir à sa tête l’un de ces grands qui à fait évoluer le Web, quelque soi ses positions politico-gay-catho-je-sais-pas-quoi.



Rageux, fanboys à vos claviers…

votre avatar







Ujoux a écrit :



Très bonne nouvelle <img data-src=" />



Et dire qu’il y a encore 5 ans le JS était encore très mal vu…







Pourquoi il est bien vu maintenant ?

Ce n’est pas parcequ’il universellement utilisé que c’est un langage de qualité….


votre avatar







Inny a écrit :



Un des types qui a financé la loi “proposition 8” en Californie. Bien joué Mozilla, vous vous êtes faits plein de potes aux USA. <img data-src=" />



<img data-src=" />


votre avatar







g30lim4 a écrit :



Oui enfin, la très grande majorité des sites Web que vous visitez aujourd’hui contient du javascript, et une très grande partie de ceux-ci contiennent du jquery.



Donc on dira ce qu’on veux le Javascript est indispensable et dans bien des cas une alternative beaucoup plus fiable a Flash. Seulement les dev d’aujourd’hui sont tellement nuls à chier en JS qu’il préfère faire des appli flash only alors que dans la plupart des cas avec Jquery (et HTML5) tu peux en ressortir un équivalent aussi bien foutu.



Bref beaucoup de critiques sur le JS, mais tu te rend compte qu’en fait les mecs n’y pigent quedale du fait qu’ils soient des fanboys Adobe. Puis il n’y a pas photo au niveau de la bande passante, ces objet flash, deviennent… De plus en plus lourds… Alors qu’en Ajax si tu te démerde bien tu peux économiser une bande passante de folie sur ton site Web.



Et pour être honnête quel pourcentage de gens qui n’utilisent pas flash (non-natif), et ceux qui n’utilisent pas JS (volontairement désactivé car activé d’office sur tout les navigateurs)…



Donc oui moi je vois une bonne opportunité pour Mozilla d’avoir à sa tête l’un de ces grands qui à fait évoluer le Web, quelque soi ses positions politico-gay-catho-je-sais-pas-quoi.



Rageux, fanboys à vos claviers…





Oui enfin les framework ont pas mal aidé au développement du Javascript pour contourner ses faiblesses. Par exemple la syntaxe reste souvent très peu lisible et pour certaines choses tu te retrouves souvent à ne jamais retrouver la même solution pour les même objectifs… Genre faire une classe ou un module et chacun y va de sa petite cuisine. Ça me fait penser un peu à ce qu’on avait à une époque avec le PHP.



Bref. C’est un langage utile mais il à ses limites. De ce coté j’attends impatiemment l’ECMA Script 6.


votre avatar







AlphaBeta a écrit :



Pourquoi il est bien vu maintenant ?

Ce n’est pas parcequ’il universellement utilisé que c’est un langage de qualité….





Tout a fait <img data-src=" />



seb2411 a écrit :



Yep de belles applications proprio monoplateforme y’a que ça de vrai <img data-src=" />.

Les différentes technos sont complémentaires, le vieux débat du web vs appli native me parait totalement inutile, chacune répond à un besoin spécifique dans un cadre spécifique.



Pour ce qui est de Javascript j’attends de pied ferme l’ECMA Scrtip 6 qui devrait pas tarder à sortir et qui permettra de faire quelques trucs sympa et un code plus propre et moderne.





Ben c’est justement le probleme du JS, repondre a des problematique qui n’etaient pas la a la creation du web … en franchement, je fais du c# .net, et l’integration avec JS, c’est franchement pas naturel ….



Que ce soit C#, Php etc… le comportement des cycles de vie d’une page est largement plus chiant qu’une applie normale qui serait connectee, pour avoir fait les deux, je peux te le garantir.







blackdream a écrit :



Clair, j’ai fait pas mal de JavaScript jQuery et du NodeJS, et plus on l’utilise, plus on se rend compte qu’il fait tout ce qu’on veut, et correctement.

Et en plus de ça, avec le fait que IE8 ne va plus être maintenu d’ici 15 jours, on va bientôt ne plus avoir à ce soucier des navigateurs qui comprennent rien au JS.



Franchement, le problème du JS aujourd’hui, c’est que tu dois plus ou moins tout coder en double, à cause d’IE6-7-8. On enlève ces trois navigateurs et personnellement je n’aurais plus rien à reprocher au JS.





C’est bien ce que je reproche a JS, et aux navigateurs par extensions, c’est de vouloir etre des couteaux suisses …



A la base le dev web devait faire en sorte d’etre independant de la plateforme sur laquelle tu etais sauf que ce probleme a ete remplace par celui du navigateur sur lequel tu es … donc en gros on a juste deporte le pb et en plus on ce tape des technos patchee dans tout les sens <img data-src=" />


votre avatar







jpaul a écrit :



+1. Et je suis dev. Javascript <img data-src=" />







Javascript :

Par défaut, le code est non typé.

Par défaut, le code est moche.

Par défaut, les règles d’écritures sont approximatives, mais rigoureuses à l’exécution. Cf : “Putain, pourquoi ça marche pas ?”

Par défaut, on ne fait pas de test ou de debug offline.

Les clones JS de Maven et de JUnit sont récents.



En résumé, c’est aussi approximatif que puissant.



Les frameworks tentent de cadrer les choses, mais la plupart sont encore jeunes. (node js en version 0.10.25, Angular JS en 1.2.14 daté de 2014)



Ah, j’oubliais : j’ai dû me taper du JS à l’époque des navigateurs sans debugger performants…



Le JS oui, mais pas sans Framework, et encore, il faut choisir le bon.


votre avatar

C’est comme le Java c’est un langage qui permet de faire plein de truc mais c’est pas pour autant un truc bien foutu.

J’aime bien les exemples de cet article :

http://sametmax.com/un-gros-troll-de-plus-sur-javacscript/

votre avatar







Inny a écrit :



Un des types qui a financé la loi “proposition 8” en Californie. Bien joué Mozilla, vous vous êtes faits plein de potes aux USA. <img data-src=" />







Soutient à une proposition de loi contre le mariage homo, ensuite on peut supposer que le bonhomme est pro-life et contre les taxes : c’est un républicain quoi. Du coup Firefox va devenir le browser du Tea Party ? <img data-src=" />


votre avatar







Jarodd a écrit :



A la base c’est une actu sur Mozilla, pas Javascript… On pourrait oublier le passé du nouveau boss et recentrer le débat sur l’avenir de la MoFo ?



Perso je trouve que faire de Firefox OS la priorité est une bonne chose. C’est un OS d’avenir (pas forcément en France), qui respecte la philosophie du web, donc je soutiens l’initiative <img data-src=" />







Moi pas … <img data-src=" />

Firefox OS va se positionner sur un marché de niche avec d’autre nombreux concurrent Tizen, Ubuntu, Sailfish et sans doute un petit dernier que j’ai du oublier …



De plus les marchés émergent intéressent également Google et Microsoft … C’est pour moi un gaspillage de ressource … sans compter le fait que des applications en javascript n’auront jamais les perf d’une application native ou managé (surtout avec les projet Android RunTime (ART) et Projet N de MS) …



Coté PC :




  • la gestion du projet Electrolys m’a laissé perplexe : on commence, on arrête pour finalement relancer le projet récemment (si ma mémoire est bonne).

    -Toujours pas de sandbox en 2014 <img data-src=" /> Ce n’est clairement pas le navigateur le mieux sécurisé et les primes peu élevé pour les failles FF du Pwn2Own en atteste.

  • Le projets Shumway consistant a interprété le Flash via des techno web n’est peu etre pas le projet le plus nécessaire de ces dernières année …

  • La chromification de l’interface de Firefox avec le projet Australis a été longue pour ce qu’elle est … Bon je suis pas forcement fan des onglets arrondie mais le reste est bon …



    Coté Mobile :

    Je sais pas trop ca fait longtemps que je l’ai désinstallé (Chrome et Dolphin me suffise) mais il était pas mauvais dans mes souvenirs



    Enfin voila j’ai peut etre été méchant avec Firefox mais ca reste mon navigateur de prédilection … Mais face a un IE qui ne cesse de se bonifier, et un Google plus qu’agressif possédant des sites web permettant de faire imposer certain “standard” (je pense au DRM video qui s’imposera surement grâce en partie au contenu premium de Youtube), je pense que Mozilla est sur une pente descendante <img data-src=" />




votre avatar

Je m’explique : dans certains contextes d’entreprises, il faut du mature et de l’industrialisé.



En mars 2014, les frameworks Javascript ne répondent pas à ces critères. Ils sont innovants, puissants, portables, intéressants, mais pas matures.









EMegamanu a écrit :



Faux… tu confonds typage fort et typage faible.





C’est pas que je confonds, c’est juste que je mets non typé et faiblement typés dans le même panier.







EMegamanu a écrit :



Que veux-tu dire par là ?





Débugger une bête fonction offline, hors contexte navigateur. Comme quand on débuggue un pauvre JUnit en Java.









EMegamanu a écrit :



Il me semble que ça fait un bail qu’il y a des outils de test unitaire…

En revanche ton “clone de Maven” m’intéresse. Un lien stp ?





Sur la partie gestion de dépendances, recherche “javascript dependencies management” et tu tomberas sur des trucs comme requirejs ou injectjs.





Et puis bon, quand on s’est habitué à la complétion de code, c’est dur de redescendre à la saisie en couleurs… IntelliJ ou Tern, c’est récent ou payant.





Ma conclusion, c’est qu’il faudrait trouver un langage qui remplace Java ET Javascript. La même syntaxe côté client et serveur, mais avec des API différenciées. Comme GWT finalement.

Sauf que GWT, c’est mignon, mais c’est de la grosse usine à gaz. A tel point que Google l’a laissé à la communauté …



Peut être Dart ?


votre avatar







EMegamanu a écrit :



En même temps, va faire un développement sans utiliser de framework ou de bibliothèque quel que soit le langage… Ca revient à réinventer la roue. ^^;







Ouais c’est comme vouloir utiliser Java pour faire du web sans aucun framework… <img data-src=" />


votre avatar







EMegamanu a écrit :



faudra qu’on m’explique d’ailleurs le coup des parseInt… parce que je n’arrive pas du tout à reproduire ce comportement.







Tout bêtement que si ta variable contient un nombre en tant que chaîne genre:

var chiffre = ‘1’;



Javascript va concaténer la chaine au lieu de l’additionner. Et comme des fois des variables récupérées en Ajax ne sont pas cast en int server-side, du coup ça foire…

<img data-src=" />


votre avatar







Groumfy a écrit :



Je m’explique : dans certains contextes d’entreprises, il faut du mature et de l’industrialisé.





C’est pas comme si ces framework n’était pas fait et utilisé par les plus grosses boites de la planète <img data-src=" />


votre avatar







g30lim4 a écrit :



Tout bêtement que si ta variable contient un nombre en tant que chaîne genre:

var chiffre = ‘1’;



Javascript va concaténer la chaine au lieu de l’additionner. Et comme des fois des variables récupérées en Ajax ne sont pas cast en int server-side, du coup ça foire…

<img data-src=" />







Non rien à voir… (voir mon post plus bas)

Et encore une fois, toujours vérifier les saisies utilisateurs…







zefling a écrit :



Ouais c’est comme vouloir utiliser Java pour faire du web sans aucun framework… <img data-src=" />





Ca ramène au temps des “scripts” cgi. ^^;



votre avatar

Tablette Alcatel 7” à 79 € sous Firefox OS



Je n’ai pas trouvé d’équivalent sous Tizen ou Ubuntu <img data-src=" />

votre avatar







g30lim4 a écrit :



Oui enfin, la très grande majorité des sites Web que vous visitez aujourd’hui contient du javascript, et une très grande partie de ceux-ci contiennent du jquery.



Donc on dira ce qu’on veux le Javascript est indispensable et dans bien des cas une alternative beaucoup plus fiable a Flash. Seulement les dev d’aujourd’hui sont tellement nuls à chier en JS qu’il préfère faire des appli flash only alors que dans la plupart des cas avec Jquery (et HTML5) tu peux en ressortir un équivalent aussi bien foutu.



Bref beaucoup de critiques sur le JS, mais tu te rend compte qu’en fait les mecs n’y pigent quedale du fait qu’ils soient des fanboys Adobe. Puis il n’y a pas photo au niveau de la bande passante, ces objet flash, deviennent… De plus en plus lourds… Alors qu’en Ajax si tu te démerde bien tu peux économiser une bande passante de folie sur ton site Web.



Et pour être honnête quel pourcentage de gens qui n’utilisent pas flash (non-natif), et ceux qui n’utilisent pas JS (volontairement désactivé car activé d’office sur tout les navigateurs)

…couic…





J’ai bâti un cours Javascript en 1997 car j’y croyais beaucoup. Tout le monde me disais que j’étais cinglé. Aujourd’hui, Javascript est (presque) partout sur le Web et heureusement car c’est mieux que le Flash tout pourri. Vive le couple Javascript/HTML5.

Perso j’ai toujours trouvé que le gestionnaire d’événements était top dans Javascript (dès la première version et maintenant c’est encore mieux avec le modèle DOM niveau 2). Ceux qui disent que Javascript n’est pas un bon langage sont très souvent ceux qui n’en utilisent que la petite partie la plus visible. Quand on fait de la programmation en grand (“programming in the large”) en Javascript, on mesure tout son potentiel.


votre avatar

C’est sur que y’a des cotés pourris dans le JS (je pense notament aux aberations style ‘typeof Nan &gt; “number”’, les parseInt et companie mais le JS d’une maniere generale n’est pas si pourri que ca quand meme.



Par contre je dirais pas la meme chose du css…

Toujours pas de systeme de grid css stable en 2014 (la base d’une UI quoi) …

votre avatar







AlphaBeta a écrit :



Pourquoi il est bien vu maintenant ?

Ce n’est pas parcequ’il universellement utilisé que c’est un langage de qualité….





C’est un langage de qualité, pas comme ton commentaire <img data-src=" />


votre avatar







EMegamanu a écrit :



En revanche ton “clone de Maven” m’intéresse. Un lien stp ?





Dans ce domaine, visiblement (je fais très peu de Javascript et uniquement sur des petits projets perso à la maison, mais je suis l’actualité malgré tout), il y a Grunt qui s’est fait une petite place. Plus récemment, il y a Gulp qui est apparu, et qui a l’air très sympa pour ce que j’ai pu en voir.


votre avatar







seb2411 a écrit :



Oui enfin les framework ont pas mal aidé au développement du Javascript pour contourner ses faiblesses. Par exemple la syntaxe reste souvent très peu lisible et pour certaines choses tu te retrouves souvent à ne jamais retrouver la même solution pour les même objectifs… Genre faire une classe ou un module et chacun y va de sa petite cuisine. Ça me fait penser un peu à ce qu’on avait à une époque avec le PHP.



Bref. C’est un langage utile mais il à ses limites. De ce coté j’attends impatiemment l’ECMA Script 6.





Moi pas connaître PHP, moi pas connaître Javascript ; Moi critiquer parce que… <img data-src=" />



Petite anecdote d’aujourd’hui : Langage JAVA - Découverte d’une méthode nommée « MyClass.arrondir() » - JavaDoc : « Comme je comprends à ce que fait la classe BigDecimal sur ces méthodes d’arrondie, alors je crée la mienne et elle est exacte !! »



T’es pas ce genre de développeur ?


votre avatar







seb2411 a écrit :



C’est pas comme si ces framework n’était pas fait et utilisé par les plus grosses boites de la planète <img data-src=" />







La taille de la boite ne change pas grand chose. Un historique de versions de 2 ans, c’est jeune. Quelque soit la techno.



Si les grosses boites arrivaient à sortir le produit parfait et sans bugs, ça se saurait.



J’ai vu de tout :




  • Le framework magique qui fait du gros boulot “sauf” pour les cas à la marge, mais qui plombent le projet, car chiffré en optimiste.

  • Le soft proprio qui ne corrigera un bug que dans la prochaine grosse version : ça signifie se trimballer un bug, ou faire avec des contournements à la con.

  • Le framework opensource et central, dont il manque des fonctions “évidentes” mais que personne n’avait vu. Du coup, patch maison …




votre avatar







EMegamanu a écrit :



Non rien à voir… (voir mon post plus bas)

Et encore une fois, toujours vérifier les saisies utilisateurs…





J’ai jamais dit le contraire ;)



Je fait moi-même partie d’un groupe de validateur de modules pour un CMS, donc niveau vérif des saisies d’utilisateurs je suis calé.



Mais là je te parle par exemple d’une réponse d’un serveur en Ajax ou le mec ne caste pas ces entier dans une chaîne JSON par exemple <img data-src=" />


votre avatar







Lafisk a écrit :



Tout a fait <img data-src=" />

Ben c’est justement le probleme du JS, repondre a des problematique qui n’etaient pas la a la creation du web … en franchement, je fais du c# .net, et l’integration avec JS, c’est franchement pas naturel ….



Que ce soit C#, Php etc… le comportement des cycles de vie d’une page est largement plus chiant qu’une applie normale qui serait connectee, pour avoir fait les deux, je peux te le garantir.





C’est bien ce que je reproche a JS, et aux navigateurs par extensions, c’est de vouloir etre des couteaux suisses …



A la base le dev web devait faire en sorte d’etre independant de la plateforme sur laquelle tu etais sauf que ce probleme a ete remplace par celui du navigateur sur lequel tu es … donc en gros on a juste deporte le pb et en plus on ce tape des technos patchee dans tout les sens <img data-src=" />





Sauf que vous avez tendance à oublier pourquoi Javascript à été créé et ce qu’est Internet.



Un document de 1980 à tout autant de valeur, si ce n’est plus, que celui qui est produit aujourd’hui.



Je suis désolé mais une page codé correctement avec les standards de l’époque (parce que oui même à l’époque les recommandations existaient) doit et devra toujours s’afficher et fonctionner.



Il n’y a pas que ton petit nombril <img data-src=" />







Jypyx a écrit :



C’est comme le Java c’est un langage qui permet de faire plein de truc mais c’est pas pour autant un truc bien foutu.

J’aime bien les exemples de cet article :

http://sametmax.com/un-gros-troll-de-plus-sur-javacscript/





Un gros sac remplis de Trolls velus.







Jypyx a écrit :



Ouais enfin il y a certain exemple de code qui ne sont pas du tout débunkés.

L’histoire des parseInt() et des opérations, par exemple, restent quand même des bonnes grosses aberration du Javascript.





Il l’enterre aisément, de par ses divers liens.







EMegamanu a écrit :



faudra qu’on m’explique d’ailleurs le coup des parseInt… parce que je n’arrive pas du tout à reproduire ce comportement.





Juste une histoire d’Illuminati, l’essentiel est que le comportement soit totalement maîtrisé à partir du moment où la documentation du langage est lue.


votre avatar







EMegamanu a écrit :



Le soucis avec le JavaScript c’est qu’il s’agit d’un langage soit interprété, soit compilé à l’exécution. Du coup parler de typage statique/dynamique me parait alambiqué (en mode mauvaise foi <img data-src=" />)





Il n’y a absolument rien d’alambiqué, le typage est fait dynamiquement à l’exécution et si éventuellement ce type a déjà été rencontré alors la VM peut utiliser une version pré-compilée de la fonction pour ces types précis d’arguments.





Edit : Du coup, dynamique/statique je laisse ça de côté vu que je ne saurai le définir, mais dans le cas de JavaScript c’est du Implicite/Faible. A comparer au C Explicite/Faible et au C++ Explicite/Fort.



Un typage est dynamique si certains types ne peuvent être déterminés qu’à l’exécution.



C’est le cas en javascript parce que tu peux à tout moment ajouter de nouveaux membres via par exemple myObject[myString] = ‘abc’. Puisque la valeur (et même parfois le type) de myString ne peut pas être connue à l’avance, il est impossible de connaître le type de myObject après ça. Le même problème se pose avec un tableau contenant plusieurs types selon les indices, puisque ces indices ne peuvent pas être connus à l’avance.



Bien sûr, en pratique, un compilateur peut inférer le type de certaines variables à l’avance. Sauf que d’une part l’incertitude tend à se propager rapidement (et javascript rend le boulot malaisé) et d’autre part la complexité de ces algorithmes est en O(n^3) même si c’est souvent un simple O(n^x avec x &lt; 2) qui reste quand même très coûteux pour du JIT. Je t’invite à chercher “inclusion based pointer analysis” si le sujet t’intéresse.





Mais les deux notions statique/dynamique et fort/faible ne sont pas incompatibles :

fr.wikipedia.org WikipediaEn revanche la notion de typage fort/faible est, elle, subjective et ne devrait pas être utillisée. Sans doute voulais-tu dire que les comparaisons standard et quelques autres opérations en javascript sont laxistes. Ça, oui, c’est acceptable.





mais dans le cas de JavaScript c’est du Implicite/Faible. A comparer au C Explicite/Faible et au C++ Explicite/Fort.



Implicite, oui, c’est correct. Note cependant qu’on peut avoir un typage implicite et statique, c’est le cas par exemple des systèmes Hindley-Miller que l’on rencontre dans certains langages (F# par exemple).









Ujoux a écrit :



Et dire qu’il y a encore 5 ans le JS était encore très mal vu…





Mais le JS est toujours mal vu, même s’il a été nettoyé et amélioré. Si JS a du succès c’est parce que nous n’avons pas le choix.


votre avatar







arno53 a écrit :



Concernant une app Firefox sous WP et Windows RT, c’est pas totalement de leur faute : Microsoft interdit la compilation JIT du Javascript sur WinRT, ce qui empeche Firefox et Chrome de sortir avec leur moteur javascript … Par contre ils pourraient surement porter leur moteur de rendu et utilisé le moteur javascript d’IE en attendant que Microsoft propose une alternative … J’imagine que c’est pour préparer l’arrivé de Midori qui interdit aussi la compilation en temps réel …







Ouais non mais d’accord, mais ça c’est l’excuse facile! Sur iOS Firefox est obligé d’utiliser des parties du navigateur Safari, et là ça dérange pas Mozilla! Alors pourquoi ça les dérangerais d’utiliser certaines parties de IE pour Win 8 RT et WP? <img data-src=" />


votre avatar







HarmattanBlow a écrit :



Si JS a du succès c’est parce que nous n’avons pas le choix.







Très juste.







HarmattanBlow a écrit :



Mais le JS est toujours mal vu, même s’il a été nettoyé et amélioré.







Précision : et sera toujours mal vu : le coeur de JS ne pourra pas être nettoyé beaucoup plus qu’il ne l’est actuellement, il y aura toujours null et undefined, === ect…



On peut seulement ajouter par dessus (ECMAScript 6/TypeScript) et améliorer la librairie “standard” (je pense à Date qui est vraiment miteux).



Si on veut vraiment nettoyer le cœur de JavaScript, il faut malheureusement créer un nouveau langage =&gt; Dart


votre avatar







tanguy_k a écrit :



Si on veut vraiment nettoyer le cœur de JavaScript, il faut malheureusement créer un nouveau langage =&gt; Dart





On s’en fiche de Dart. La réponse à Javascript ce n’est pas d’imposer un langage de plus. C’est de redonner la liberté du choix du langage.


votre avatar







seb2411 a écrit :



Nop si tu as un framework tout fait qui fait du très bon boulot, qui est bien documenté et testé, tu vas pas dépenser du fric et du temps sur ton projet à refaire la même chose.





Je pensais plutôt à des implémentations qui viennent en remplacement pas en complément pour pallier une faiblesse, ou alors je ne te comprends pas.



Pour illustrer, imaginons qu’un framework t’offre une méthode de chiffrement plus robuste que celle fourni par le langage que tu utilises.







seb2411 a écrit :



Pas du tout. Dans le cas du javascript même faire ce qui correspond à une classe peut se faire de différentes manières. Dans d’autres langages une classe ressemble à une classe. Tu n’as pas 36.000 façon de le faire.





Sauf que Javascript n’est pas un langage orienté objet.







seb2411 a écrit :



Oui et non. Pour un projet perso tu fais ce que tu veux oui. Pour un projet en équipe si tu veux faire du bon boulot c’est pas du chacun pour soi. Il faut se mettre d’accord sur des standards de codages (tu dois connaître PSR ?) et essayer de travailler de la même manière. Ca réduit le boulot des relecture du code et ça facilite l’intégration de nouveaux membres dans l’équipe. De plus des framework permettent aussi des standardiser énormément certaines partie du travail qui sont souvent répétitive.





Ce que je voulais faire comprendre c’est que, à un instant T, pour une même fonctionnalité, 1 développeur choisira de passer par une closure, tandis que le second utilisera une classe Utilitaire (dans le cas d’un langage orienté objet).



Il est évident que je ne sous-entendais pas que tu pouvais monter ta propre DAO dans ton coin, pour toi tout seul <img data-src=" />







seb2411 a écrit :



L’époque ou la POO n’éxistait pas. (PHP2 ?). Et depuis la 3 oui il y a eu pas mal de nouveauté bienvenues pour ne pas dire nécessaires.



Oui mais je n’ai pas attaqué PHP. Simplement fait remarqué qu’a une époque il n’était pas aussi complet riche qu’il l’est aujourd’hui.











seb2411 a écrit :



Ca permettra de faire de la POO propre et pas mal d’autres choses intéressante (Google sur le sujet tu verras).



Je bosse presque exclusivement avec PHP et Javascript. Maintenant je sais que je suis pas le seul à attendre ES6 avec impatience.







Il faut bien comprendre une chose, JavaScript n’a pas de modèle de classe.



Voici un article de chez Pompage.net qui explique bien ce principe.



En tout cas, une chose est sûr JavaScript a et aura de beau jour devant lui et EcmaScript et bienvenu <img data-src=" />


votre avatar







HarmattanBlow a écrit :



On s’en fiche de Dart. La réponse à Javascript ce n’est pas d’imposer un langage de plus. C’est de redonner la liberté du choix du langage.





Rien n’est imposé, la VM Dart c’est en plus de la VM JS =&gt; choix :-)



J’imagine que tu veux parler de asm.js (ou tout du moins du principe d’une VM avec un bytecode).





votre avatar







Lafisk a écrit :



Euh, ok, en plus de passer pour un semi troll, tu te rend compte que tu es complètement hs part rapport a ce que je dis ….



La rétro compatibilité c’est beau mais ca en fait pas une bonne techno





Tu l’as vraiment compris mon message ? Effectivement, l’histoire de Javascript prouve Ô combien tes propos sont exactes, pardonne-moi.



Une techno massivement utilisée est une bonne techno que tu le veuilles ou non <img data-src=" />







Lafisk a écrit :



Je ne dis pas le contraire, je dis que ça a mal évolué justement. A la base, le web c’était fait pour partager des documents statiques, et plutôt scientifique a l’origine (aujourd’hui, le web est tellement dénaturé que tu fais ca avec latex en perdant le cote partage).





Le Web, c’est nous, on en fait ce que l’on veut, c’est pas parce qu’aujourd’hui tu peux faire plus que tu dois impérativement le faire.







Lafisk a écrit :



La techno html était bonne en soit même si un peu bancale.





Elle l’est toujours et même cette technologie a évoluée dans le bon sens.







Lafisk a écrit :



A cela, certains ce sont dit, ce serait cool si ca pouvait être dynamique … et la, la catastrophe commence, on commence à renvoyer des réponses html entière pour simuler un semblant de dynamisme et de la pire onn ce dit ce serait encore plus cool si on pouvait renvoyer des réponse html partielle et les intégrer a la page en cours ….. <img data-src=" />





Javascript, ce n’est pas que cela.







Lafisk a écrit :



Pour être honnête, ca me fait penser a ce que je vois souvent dans les petits projets open source, un truc pensé par un geek pisseur de code, sans offense, mal structuré et qui s’enfonce a chaque fois un peu plus. La preuve en est qu’on est obligé de créer des surcouche comme jquery, typescript etc… qui par analogie sont ce qu’est le c a l’assembleur pour js, ie des surcouche. Le seul qui soit plus framework que surcouche c’est ajaxcontroltoolkkit





Le C une surcouche à l’assembleur. Pitié !

Effectivement, tu ne sais pas de quoi tu parles, sans méchanceté aucune :

Framework != Couche applicative

Framework = Boîte à outils







Lafisk a écrit :



Du côté webform, les technologies ont elles aussi évoluées mais la avec plus de bon sens je trouve.





Les Webform ? Les formulaires Web donc. Merci qui ? Merci JS.


votre avatar







tanguy_k a écrit :



Rien n’est imposé, la VM Dart c’est en plus de la VM JS =&gt; choix :-)





C’est une restriction moins grande mais ça reste une restriction sévère. et puis franchement quitte à supporter deux langages autant en avoir deux franchement différents. Dart c’est vraiment le truc inutile pour moi et qui va encore complexifier inutilement les navigateurs avec tout ce que ça va poser comme problème. Je préfère cent fois que Mozilla, Opera ou Canonical n’ait pas à claquer du fric pour ce truc inutile.





J’imagine que tu veux parler de asm.js (ou tout du moins du principe d’une VM avec un bytecode).





  • Malheureusement tu introduits alors une étape supplémentaire de compilation



    Pas du tout ! Le JS et Dart doivent aussi être parsés et compilés et ces deux opérations sont beaucoup plus complexes pour ces deux langages. Si étape supplémentaire il y a c’est en comptant la compilation faîte en amont par le développeur. C’est comme protester contre l’assembleur au motif qu’il serait plus rapide pour le CPU de traiter directement des sources C++ : absurde.





  • De plus tu perds en perfs (j’ai pas de chiffres) entre une VM avec 1 seul langage vs VM avec bytecode (c’est pas moi qui le dit mais Lars Baken.wikipedia.org Wikipedia(computer_programmer) j’ai pas vérifié en expérimentant)



    Non, ce n’est pas ce qu’ils disent et ce n’est pas ce qui est expliqué dans tes liens. Ce qu’ils disent c’est qu’un langage dynamique implémenté par-dessus un bytecode optimisé pour le système de types de Java est inefficace et je suis totalement d’accord. Et tous leurs arguments contre un bytecode spécialisé du type de celui de Java, et notamment des restrictions intrinsèques, sont parfaitement valables.



    Mais ils ne s’appliquent pas à quelque chose de vraiment générique, beaucoup plus proche d’un langage assembleur neutre, comme l’est pNaCl ou asm.js. A ce niveau les inconvénients disparaissent presque totalement (la différence de perfs est au pire microscopique et le plus souvent nulle) alors que l’avantage de pouvoir choisir son langage est extrêmement important.



    Foutons Dart au feu parce que, non, ce ne sera pas gratuit, ce sera un boulet de plus dans le jardin des hordes de standards du web que doivent supporter ces titans que sont les navigateurs. Virons 90% de tout ça, virons JS, virons dart, virons html, etc (bon, pas tout de suite). Faisons du navigateur un OS aussi neutre et léger que possible. Le reste, des langages aux bibliothèques, doit être du ressort des tierce-parties.







    Presteus a écrit :



    Une techno massivement utilisée est une bonne techno que tu le veuilles ou non <img data-src=" />





    Cobol est donc le meilleur des langages ?





    Le Web, c’est nous, on en fait ce que l’on veut, c’est pas parce qu’aujourd’hui tu peux faire plus que tu dois impérativement le faire.



    Personnellement je t’assure que je n’ai aucune influence sur les standards. Et dans le web tout est codifié par des standards écrits par des acteurs aux itnérêts particuliers.


votre avatar







Presteus a écrit :



Tu l’as vraiment compris mon message ? Effectivement, l’histoire de Javascript prouve Ô combien tes propos sont exactes, pardonne-moi.



Une techno massivement utilisée est une bonne techno que tu le veuilles ou non <img data-src=" />







Faudrais deja que tu commences par comprendre les miens, Cf en dessous



Je vais t’apprendre un truc quantite != qualite. C’est enormissime comme connerie ce que tu viens de dire quand meme …





Le Web, c’est nous, on en fait ce que l’on veut, c’est pas parce qu’aujourd’hui tu peux faire plus que tu dois impérativement le faire.





On m’a pas trop demande mon avis sur les standards actuels ;;; et je doute qu’on t’ai demande quoique ce soit.





Elle l’est toujours et même cette technologie a évoluée dans le bon sens.





L’html, mouai, bof bof pour l’evolution et de toute facon c’est pas celle que je critique le plus … le JS est une belle daube, le php aussi par exemple, le c# webform, j’ai beau en faire, c’est pas non plus terrible quand meme.





Javascript, ce n’est pas que cela.





euh, plus ou moins grosso modo quand meme …





Le C une surcouche à l’assembleur. Pitié !

Effectivement, tu ne sais pas de quoi tu parles, sans méchanceté aucune :

Framework != Couche applicative

Framework = Boîte à outils





et c’est moi qui comprends pas ce que t’ecris mais t’es pas foutu de comprendre le terme analogie … ajaxcontroltoolkit est une boite a outil, le typescript, jquery etc… deja beaucoup moins





Les Webform ? Les formulaires Web donc. Merci qui ? Merci JS.



Merci JS, non justement, on voit que tu as pas bien lu mes commentaires et tout compris de travers…


votre avatar







Lafisk a écrit :



Faudrais deja que tu commences par comprendre les miens, Cf en dessous



Je vais t’apprendre un truc quantite != qualite. C’est enormissime comme connerie ce que tu viens de dire quand meme …







On m’a pas trop demande mon avis sur les standards actuels ;;; et je doute qu’on t’ai demande quoique ce soit.







L’html, mouai, bof bof pour l’evolution et de toute facon c’est pas celle que je critique le plus … le JS est une belle daube, le php aussi par exemple, le c# webform, j’ai beau en faire, c’est pas non plus terrible quand meme.







euh, plus ou moins grosso modo quand meme …







et c’est moi qui comprends pas ce que t’ecris mais t’es pas foutu de comprendre le terme analogie … ajaxcontroltoolkit est une boite a outil, le typescript, jquery etc… deja beaucoup moins





Merci JS, non justement, on voit que tu as pas bien lu mes commentaires et tout compris de travers…











Presteus a écrit :



Pour conclure :

De mon avis personnel, les détracteurs ; d’un langage en fonction de « leur » langage de prédilection ; ont autant d’expertise dans « leur » langage que ce qui ressort de leur « contre-argumentaire ».





votre avatar







Presteus a écrit :





je travaille en c# webform, j’ai l’air de le defendre ?



t’es pas doué pour debattre, meme joueur joue encore …



En tout cas, c’est sur, tes arguments me laisse sans voix … surtout celui de quantite = qualite <img data-src=" />


votre avatar







Lafisk a écrit :



je travaille en c# webform, j’ai l’air de le defendre ?



t’es pas doué pour debattre, meme joueur joue encore …



En tout cas, c’est sur, tes arguments me laisse sans voix … surtout celui de quantite = qualite <img data-src=" />





Je stoppe le débat parce qu’il est vide de sens et non parce que je n’ai pas ou plus d’argumentaire.



J’avais juste envie de venir faire du bashing aussi simplement que vous le faites avec Javascript et PHP principalement.



[edit] N.B : A aucun moment je ne fais l’apologie de la quantité contre la qualité, tu as simplement mal interprété mes propos, nuance <img data-src=" />


votre avatar







Presteus a écrit :



Je stoppe le débat parce qu’il est vide de sens et non parce que je n’ai pas ou plus d’argumentaire.



J’avais juste envie de venir faire du bashing aussi simplement que vous le faites avec Javascript et PHP principalement.





lol c’est bien <img data-src=" />

ciao


votre avatar







HarmattanBlow a écrit :



&gt; - Malheureusement tu introduits alors une étape supplémentaire de compilation



Pas du tout ! […] Si étape supplémentaire il y a c’est en comptant la compilation faîte en amont par le développeur.





Donc il y a bien une étape supplémentaire… CQFD.

Et c’est loin d’être un détail, non ?







HarmattanBlow a écrit :



Mais ils ne s’appliquent pas à quelque chose de vraiment générique, beaucoup plus proche d’un langage assembleur neutre, comme l’est pNaCl ou asm.js.





Il faut différencier PNaCl et NaCl. PNaCl s’appuie sur le bytecode de LLVM. On est plus proche de la JVM que du langage machine/binaire.



De toute façon, Google promeut les 2 approches :




  • un langage de script pour le web performant et sans les défauts de JS

  • un bytecode ou langage assembleur (peu importe le nom, comme tu veux)



    Pour l’instant la vision qu’en on les concepteurs de asm.js et NaCl/PNaCl, c’est pour faire fonctionner du code existant C/C++/autre (que des exemples de jeux video pour l’instant) dans un navigateur web, pas pour écrire des applications web. Ça évoluera peut être, mais je ne le crois pas.







    HarmattanBlow a écrit :



    Faisons du navigateur un OS aussi neutre et léger que possible.





    Approche intéressante, mais je suis pas sur que ça soit le sens de l’histoire (heureusement ou malheureusement - j’ai pas d’avis) :)


votre avatar







tanguy_k a écrit :



Donc il y a bien une étape supplémentaire… CQFD.

Et c’est loin d’être un détail, non ?





Étape en amont, sur la machine du développeur et allégeant le travail sur la machine de l’utilisateur ! Tu es en train de prétendre que la compilation est une mauvaise chose, c’est délirant.





Il faut différencier PNaCl et NaCl. PNaCl s’appuie sur le bytecode de LLVM. On est plus proche de la JVM que du langage machine/binaire.



Je différencie bien les deux et le bytecode pNaCl est beaucoup plus proche d’un langage assembleur que du bytecode java. En particulier le bytecode pNaCl se focalise sur la manipulation de données primitives via leurs adresses (lire mémoire, stocker dans mémoire) et non pas sur la manipulation d’éléments d’un système de types de haut niveau comme le bytecode java (lire membre de, instancier tel type, etc).





Ça évoluera peut être, mais je ne le crois pas.



C’est Dart qui polluera, pas asm.js.





Approche intéressante, mais je suis pas sur que ça soit le sens de l’histoire (heureusement ou malheureusement - j’ai pas d’avis) :)



Mais si c’est dans ce sens là qu’on va aller, c’est inévitable, parce qu’un écosystème de tierce-parties innove plus rapidement que les comités techniques rédigeant les standards. Demain un framework UI plus riche et plus rapide que html sortira et c’est lui qui s’imposera. Sans parler du fait que Chrome, Mozilla et d’autres voient déjà le navigateur comme un OS.



La seule question est de savoir quels seront les dénominateurs communs à moyen terme : un bytecode rapidement parsable et compilable fournissant d’excellentes performances pour tout le monde ou bien un langage de haut niveau (JS) limitant les possibilités d’optimisation de tous les autres langages ? Un accès efficace au GPU ou bien un html lourd et encombré par la rétro-compatibilité ? Autrement dit quelles dettes techniques nous traînerons-nous et combien de temps ? Parce que c’est ce que JS et html vont être : des dettes techniques.


votre avatar







HarmattanBlow a écrit :



Tu es en train de prétendre que la compilation est une mauvaise chose, c’est délirant.





?

Ne pas avoir d’étape de compilation c’est évidemment un (gros) plus pour le confort du développeur, sinon les langages de script n’existeraient pas.



JavaScript est un langage de script tout comme Python ou Ruby et pour revenir à Dart :



“If you’re writing JavaScript, your “compile step” is just refreshing the browser. Dart must be equally simple to use. […] we want to keep the fast ‘edit-refresh-view’ cycle that JavaScript developers love […]”



Donc quand j’ai écrit dans mon 1er commentaire :



J’imagine que tu veux parler de asm.js (…)




  • Malheureusement tu introduis alors une étape supplémentaire de compilation



    Y’a strictement rien de “délirant” la dedans. Le “malheureusement” c’est pour le confort du développeur.







    HarmattanBlow a écrit :



    c’est inévitable





    Je me garderais bien d’avoir des certitudes sur le futur.


votre avatar







tanguy_k a écrit :



Pour simplifier la compilation c’est une transformation (ou une traduction).





Je te remercie mais je suis l’auteur de plusieurs compilateurs et outils de compilation j’ai donc une très vague idée de ce qu’implique la compilation.







  • Quand tu transformes un langage haut niveau vers un bytecode “haut niveau” proche du langage source (CLR, JVM) =&gt; rapide



    • Quand tu transformes un langage haut niveau vers un langage bas niveau (de surcroît générique) =&gt; lent



      Non, primo l’étape la plus longue c’est toujours l’analyse. D’autant que de nos jours la plupart des compilateurs battissent leurs graphes SSA durant cette phase pour détecter des variables non-initialisées et autres joyeusetés.



      Ensuite en mode développement/débogage, là où la compilation doit être rapide, on n’optimise pas, donc la traduction du bytecode en assembleur est triviale.



      Par ailleurs tu n’as qu’à te rendre compte que ton navigateur fait cent fois pire que tout cela avec JS puisqu’il faut en plus reconstrurie un système de types et que pour autant tu n’as pas le temps de le remarquer. De même que les bytecodes Java et Dotnet sont transformés par les compilos JIT plus rapidement que tu ne peux t’en rendre compte.



      Enfin tu devrais te rappeler que la compilation est conduite de façon incrémentale : on ne régénère pas en temps ordinaire le projet d’un bout à l’autre, seulement les parties modifiées. Et c’est pour ça qu’au quotidien la compilation AOT est instantanée, foi d’un mec qui passe ses journées à presser F5.





      C’est pour ça que je te demande des chiffres pour LLVM : ils ne sont pas de l’ordre de la demi-seconde, sinon tu m’aurais déjà cloué le bec depuis longtemps.



      Tu n’as pas de chiffres parce qu’un compile C++ est lent pour d’autres raisons (en-têtes, templates et inclusions) et parce qu’un compilo Java compile en bytecode. Donc il n’y a aucun chiffre disponible. Et parce que de toute façon je pourrais bien perdre du temps avec des recherches google pour te trouver des chiffres que tu m’enverrais quand même balader en prétendant que la compilation AOT ma bonne dame ça prend des heures.



votre avatar







Lafisk a écrit :



Ben c’est justement le probleme du JS, repondre a des problematique qui n’etaient pas la a la creation du web … en franchement, je fais du c# .net, et l’integration avec JS, c’est franchement pas naturel ….



Que ce soit C#, Php etc… le comportement des cycles de vie d’une page est largement plus chiant qu’une applie normale qui serait connectee, pour avoir fait les deux, je peux te le garantir.





Oui enfin c’est normal que les chosent et les technos évoluent pour s’adapter aux besoins. On va pas rester bloquer aux technos d’il y a 20ans.



Pour ce qui est du dev, perso la partie javascript me casse encore les c mais si tu utilises des framework tu as quand même des choses assez modernes et efficaces.


votre avatar

Et bien sûr le talk WAT <img data-src=" />

votre avatar







Groumfy a écrit :



Javascript :

Par défaut, le code est non typé.





Faux… tu confonds typage fort et typage faible.







Groumfy a écrit :



Par défaut, le code est moche.





Ce peut être le cas aussi en C ou en PHP… Il faut avoir des bonnes pratiques avant tout…



En revanche y a quelques archaïsmes qui restent là par compatibilité, et au comportement parfois surprenant (du genre Error() qui est équivalent à new Error()… :( )





Par défaut, les règles d’écritures sont approximatives, mais rigoureuses à l’exécution. Cf : “Putain, pourquoi ça marche pas ?”



Les closures ça surprend toujours au début, mais une fois bien gérées on se rend compte que c’est vraiment puissant. :)





Par défaut, on ne fait pas de test ou de debug offline.



Que veux-tu dire par là ?





Les clones JS de Maven et de JUnit sont récents.



Il me semble que ça fait un bail qu’il y a des outils de test unitaire…

En revanche ton “clone de Maven” m’intéresse. Un lien stp ?





En résumé, c’est aussi approximatif que puissant.



La puissance sans maitrise n’est rien.





Les frameworks tentent de cadrer les choses, mais la plupart sont encore jeunes. (node js en version 0.10.25, Angular JS en 1.2.14 daté de 2014)



Ah, j’oubliais : j’ai dû me taper du JS à l’époque des navigateurs sans debugger performants…



Le JS oui, mais pas sans Framework, et encore, il faut choisir le bon.



En même temps, va faire un développement sans utiliser de framework ou de bibliothèque quel que soit le langage… Ca revient à réinventer la roue. ^^;


votre avatar







Lafisk a écrit :



A la base le dev web devait faire en sorte d’etre independant de la plateforme sur laquelle tu etais sauf que ce probleme a ete remplace par celui du navigateur sur lequel tu es … donc en gros on a juste deporte le pb et en plus on ce tape des technos patchee dans tout les sens <img data-src=" />







Encore une fois : vire IE de l’équation…



Pour être indépendant de la plate-forme il faudrait générer des pages (pseudo) statiques et donc exit C# (ou plutôt exit Asp.net vu que tous les composants nécessitent javascript pour fonctionner)


votre avatar







blackdream a écrit :



Clair, j’ai fait pas mal de JavaScript jQuery et du NodeJS, et plus on l’utilise, plus on se rend compte qu’il fait tout ce qu’on veut, et correctement.

Et en plus de ça, avec le fait que IE8 ne va plus être maintenu d’ici 15 jours, on va bientôt ne plus avoir à ce soucier des navigateurs qui comprennent rien au JS.



Franchement, le problème du JS aujourd’hui, c’est que tu dois plus ou moins tout coder en double, à cause d’IE6-7-8. On enlève ces trois navigateurs et personnellement je n’aurais plus rien à reprocher au JS.







Le problème c’est que tout les browser ne l’interprètent pas de la même manière et maintenant que les vieilles versions d’IE sont de moins en moins supportées, de nouveau mauvais élèves se dévoilent :





jQuery Core has more lines of fixes and patches for WebKit than any other browser.



When we started our jQuery 2.0 cleanup to remove IE 6/7/8 hacks, we were optimistic that we would also be able to remove some bloat from lingering patches needed for really old browsers like Safari 2. But several of those WebKit hacks still remain. Even when they have been fixed in the latest Chrome or Safari, older WebKit implementations like PhantomJS and UIWebView still don’t have the fix. We’ve had to put back several of these as users reported problems with the beta. It’s starting to feel like oldIE all over again, but with a different set of excuses for why nothing can be fixed.





Source


votre avatar







Jypyx a écrit :



C’est comme le Java c’est un langage qui permet de faire plein de truc mais c’est pas pour autant un truc bien foutu.

J’aime bien les exemples de cet article :

http://sametmax.com/un-gros-troll-de-plus-sur-javacscript/





Exemples largement débunkés d’ailleurs. <img data-src=" />

Réponse à Un gros Troll de plus sur Javascript sametmax.com/un-gros-troll-de-plus-sur-javacscript/


votre avatar







Jypyx a écrit :



C’est comme le Java c’est un langage qui permet de faire plein de truc mais c’est pas pour autant un truc bien foutu.

J’aime bien les exemples de cet article :

http://sametmax.com/un-gros-troll-de-plus-sur-javacscript/







<img data-src=" />

Excellent lien je me suis régalé à la lecture…

Je ne suis pas dév mais ça fait longtemps déjà que j’entends dire que Javascript est une calamité…

Aussi lu un article qui déjà que PHP produisait des erreurs que personne ne comprenaient mais pas les connaissances pour juger.



Tant mieux j’en profiterai pour me mettre au python cet été même si je sais que ce n’est pas un langage web..



Sinon c’est quoi la polémique de ce monsieur ??


votre avatar







Ujoux a écrit :



Très bonne nouvelle <img data-src=" />



Et dire qu’il y a encore 5 ans le JS était encore très mal vu…





Il est toujours mal vu par beaucoup.



Je vais y aller fort et tous les pro du JS vont me tomber dessus mais je m’en fiche : ce langage est tout bonnement immonde, c’est même une véritable plaie je dirais.



Aucun typage fort, ajout dynamique de propriété dans un objet, des closures qui ont été spécifiées dans le langage par un esprit totalement malade, un overload de l’opérateur + pour à la fois additionner et concaténer, explosion (ou pas, ce qui serait encore pire…) au runtime si typo dans un nom de variable…



Ce langage n’a pas été conçu à la base pour l’usage qui en ai fait aujourd’hui, et c’est une source énorme de problèmes. Ce n’est pas pour rien que tout le monde essaye de créer un nouveau langage compilable en JavaScript (Dart de Google, TypeScript de Microsoft…etc.). On a envie de garder JavaScript car çà marche sur tous les browsers, mais plus personne n’a envie de coder en JS.



Le seul avantage de ce langage est donc d’être reconnu par tous les browsers (corollaire : d’avoir des framework type JQuery par dessus qui fonctionnent bien sur tous les browsers). Et en fait c’est vraiment malheureux, car çà le rend indispensable pour le web alors que c’est une horreur.


votre avatar







Mr Burns a écrit :



<img data-src=" />

Excellent lien je me suis régalé à la lecture…

Je ne suis pas dév mais ça fait longtemps déjà que j’entends dire que Javascript est une calamité…





Tu peux aussi lire mon post juste au-dessus du tien. Attention au son de cloche unique…

Bien souvent (certes, pas toujours), ceux qui parlent du JS en mal sont ceux qui le maitrisent et le connaissent le moins bien. <img data-src=" />


votre avatar







arno53 a écrit :



Le problème c’est que tout les browser ne l’interprètent pas de la même manière et maintenant que les vieilles versions d’IE sont de moins en moins supportées, de nouveau mauvais élèves se dévoilent :







Source







Quand jQuery n’est pas lui même le mauvais élève.



Exemple : Le sélecteur “:required”, reconnu par les navigateurs, utilisable en javascript. il est donc utilisable immédiatement par \(() et par \)().find… mais tu ne peux pas l’utiliser avec un $().filter …


votre avatar







Mr Burns a écrit :



Sinon c’est quoi la polémique de ce monsieur ??







Il est en faveur de cette loi anti-gay, et en tant que CEO ça passe pas … Plus d’infoici


votre avatar







arno53 a écrit :



Il est en faveur de cette loi anti-gay, et en tant que CEO ça passe pas … Plus d’infoici







<img data-src=" />







Crysalide a écrit :



Tu peux aussi lire mon post juste au-dessus du tien. Attention au son de cloche unique…

Bien souvent (certes, pas toujours), ceux qui parlent du JS en mal sont ceux qui le maitrisent et le connaissent le moins bien. <img data-src=" />







Oui j’ai vu après que j’ai posté merci…

Et comme j’ai dit, je n’ai pas les connaissances pour juger même si j’entends souvent des dévs écharper JS.

Mais comme je connais le 1er site puisque je me suis mis au python récemment (en attendant d’avoir du temps pour m’y mettre) j’aurais tendance à privilégier leur thèse…

Après je doute pas qu’on puisse faire des choses puissantes avec JS mais c’est un débat sans fin…


votre avatar







Crysalide a écrit :



Exemples largement débunkés d’ailleurs. <img data-src=" />

Réponse à Un gros Troll de plus sur Javascript sametmax.com/un-gros-troll-de-plus-sur-javacscript/







Ouais enfin il y a certain exemple de code qui ne sont pas du tout débunkés.

L’histoire des parseInt() et des opérations, par exemple, restent quand même des bonnes grosses aberration du Javascript.


votre avatar







Jypyx a écrit :



Ouais enfin il y a certain exemple de code qui ne sont pas du tout débunkés.

L’histoire des parseInt() et des opérations, par exemple, restent quand même des bonnes grosses aberration du Javascript.







faudra qu’on m’explique d’ailleurs le coup des parseInt… parce que je n’arrive pas du tout à reproduire ce comportement.


votre avatar

A la base c’est une actu sur Mozilla, pas Javascript… On pourrait oublier le passé du nouveau boss et recentrer le débat sur l’avenir de la MoFo ?



Perso je trouve que faire de Firefox OS la priorité est une bonne chose. C’est un OS d’avenir (pas forcément en France), qui respecte la philosophie du web, donc je soutiens l’initiative <img data-src=" />

votre avatar

Edit foireux :

J’ai trouvé :https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects…



J’ignorais que la base octale pouvait être indiquée par un 0 (non significatif) préfixé, et que certaines implémentations de JavaScript considérais au choix d’appliquer cette base octale, ou une base décimale…



Tout l’intérêt du coup de ne jamais faire confiance aux saisies utilisateurs, de lire la doc, et paramétrer correctement les appels de fonctions. :p

votre avatar







Presteus a écrit :



C’est un langage de qualité, pas comme ton commentaire <img data-src=" />







Mmmh je te remercie pour l’insulte…. mais Java Script reste un très mauvais langage devenu star par la magie de Netscape si ma mémoire est bonne….


votre avatar







EMegamanu a écrit :



Quand jQuery n’est pas lui même le mauvais élève.



Exemple : Le sélecteur “:required”, reconnu par les navigateurs, utilisable en javascript. il est donc utilisable immédiatement par \(() et par \)().find… mais tu ne peux pas l’utiliser avec un $().filter …





Pour ma part, JQuery, n’est pas un vraiment un framework, je le considère tel un pseudo-langage basé sur Javascript.

Je pense cela car, j’estime que, lorsqu’une interrogation du DOM ne donne jamais de pointeur sur le DOM, ce n’est pas du Javascript. Tu ne peux pas atteindre le DOM sans passer par le bac à sable JQuery.



Je préfère de loin l’approche Mootools, apporté la puissance d’un langage prototype en le faisant passé pour une langage objet.



Quand on étudie JQuery (le modifieur de DOM plus rapide que son ombre) et Mootools (le champion de la maintenabilité), on ne peut être qu’obligé de reconnaître que Javascript est un langage merveilleux.



Pour conclusion, comme tout langage, il suffit simplement de le dompter :)


votre avatar







Groumfy a écrit :



La taille de la boite ne change pas grand chose. Un historique de versions de 2 ans, c’est jeune. Quelque soit la techno.



Si les grosses boites arrivaient à sortir le produit parfait et sans bugs, ça se saurait.



J’ai vu de tout :




  • Le framework magique qui fait du gros boulot “sauf” pour les cas à la marge, mais qui plombent le projet, car chiffré en optimiste.

  • Le soft proprio qui ne corrigera un bug que dans la prochaine grosse version : ça signifie se trimballer un bug, ou faire avec des contournements à la con.

  • Le framework opensource et central, dont il manque des fonctions “évidentes” mais que personne n’avait vu. Du coup, patch maison …





    Honnêtement certains framework JS sont stables et matures.


votre avatar







Presteus a écrit :



Moi pas connaître PHP, moi pas connaître Javascript ; Moi critiquer parce que… <img data-src=" />



Petite anecdote d’aujourd’hui : Langage JAVA - Découverte d’une méthode nommée « MyClass.arrondir() » - JavaDoc : « Comme je comprends à ce que fait la classe BigDecimal sur ces méthodes d’arrondie, alors je crée la mienne et elle est exacte !! »



T’es pas ce genre de développeur ?





??


votre avatar







AlphaBeta a écrit :



Mmmh je te remercie pour l’insulte…. mais Java Script reste un très mauvais langage devenu star par la magie de Netscape si ma mémoire est bonne….





À aucun moment, je ne t’insulte ; en revanche, relis ton commentaire envers Javascript <img data-src=" />



On peut se targuer d’avoir plus d’affinité avec un langage qu’un autre mais certainement pas qu’il est mauvais surtout quand on est simplement utilisateur de ce langage.


votre avatar







seb2411 a écrit :



??





Je te pique avec une première phrase lourde de sens, enchaîne avec une petite anecdote « Développeur vs Concepteur » et j’ai juste droit à 2 pauvres points d’interrogation.



Je te recite en détaillant :







seb2411 a écrit :



Oui enfin les framework ont pas mal aidé au développement du Javascript pour contourner ses faiblesses.





On ne contourne pas une faiblesse avec un framework, on implémente une nouvelle solution.







seb2411 a écrit :



Par exemple la syntaxe reste souvent très peu lisible et pour certaines choses tu te retrouves souvent à ne jamais retrouver la même solution pour les même objectifs…





Ceci est un problème de management et non de développement, si 2 développeurs développe la même fonctionnalité il y a de forte chance qu’il la pense de manière totalement différente.



Ici, seul le chef de projet est à blâmer.







seb2411 a écrit :



Genre faire une classe ou un module et chacun y va de sa petite cuisine.





C’est pas le but de tout langage que de pouvoir faire sa petite cuisine ?







seb2411 a écrit :



Ça me fait penser un peu à ce qu’on avait à une époque avec le PHP.





Quelle époque de PHP parles-tu ? Parce que je la suis et la pratique depuis PHP 3 et c’est la même ; il y a eu aucune révolution dans PHP.



J’en resterai là sur PHP parce que je peux devenir très vite méchant quand on tape sur mes amis <img data-src=" />







seb2411 a écrit :



Bref. C’est un langage utile mais il à ses limites. De ce coté j’attends impatiemment l’ECMA Script 6.





Tout comme pour PHP, ECMAScript 6 ne changera pas radicalement le monde Javascript, c’est une pierre de plus à l’édifice qui permettra d’être parfois plus concis.



Pour conclure :

De mon avis personnel, les détracteurs ; d’un langage en fonction de « leur » langage de prédilection ; ont autant d’expertise dans « leur » langage que ce qui ressort de leur « contre-argumentaire » (c’est à dire souvent rien).


votre avatar



Le problème c’est que tout les browser ne l’interprètent pas de la même manière et maintenant que les vieilles versions d’IE sont de moins en moins supportées, de nouveau mauvais élèves se dévoilent :







Source



Ha, ouai, c’est vrais que maintenant que tu le dis sur j’ai eu pas mal de problème avec webkit y’a deux ans. A l’époque on avait décider que ça servait à rien de le débuger. Depuis on m’a jamais demander la compatibilité dessus : Chrome / Firefox / IE uniquement. Au final, c’est pas vraiment un problème, du moment que les environnement n’empêche pas d’installer un autre navigateur (via des règles sur le store, genre ce qu’Apple avait fait il me semble).

votre avatar







arno53 a écrit :



Moi pas … <img data-src=" />

Firefox OS va se positionner sur un marché de niche avec d’autre nombreux concurrent Tizen, Ubuntu, Sailfish et sans doute un petit dernier que j’ai du oublier …



De plus les marchés émergent intéressent également Google et Microsoft … C’est pour moi un gaspillage de ressource … sans compter le fait que des applications en javascript n’auront jamais les perf d’une application native ou managé (surtout avec les projet Android RunTime (ART) et Projet N de MS) …



Coté PC :




  • la gestion du projet Electrolys m’a laissé perplexe : on commence, on arrête pour finalement relancer le projet récemment (si ma mémoire est bonne).

    -Toujours pas de sandbox en 2014 <img data-src=" /> Ce n’est clairement pas le navigateur le mieux sécurisé et les primes peu élevé pour les failles FF du Pwn2Own en atteste.

  • Le projets Shumway consistant a interprété le Flash via des techno web n’est peu etre pas le projet le plus nécessaire de ces dernières année …

  • La chromification de l’interface de Firefox avec le projet Australis a été longue pour ce qu’elle est … Bon je suis pas forcement fan des onglets arrondie mais le reste est bon …



    Coté Mobile :

    Je sais pas trop ca fait longtemps que je l’ai désinstallé (Chrome et Dolphin me suffise) mais il était pas mauvais dans mes souvenirs



    Enfin voila j’ai peut etre été méchant avec Firefox mais ca reste mon navigateur de prédilection … Mais face a un IE qui ne cesse de se bonifier, et un Google plus qu’agressif possédant des sites web permettant de faire imposer certain “standard” (je pense au DRM video qui s’imposera surement grâce en partie au contenu premium de Youtube), je pense que Mozilla est sur une pente descendante <img data-src=" />









    +1000! <img data-src=" />



    Je pense aussi que Mozilla va finir par se faire bouffer tout cru par Chrome (au niveau des pdm) parce qu’ils n’auront pas voulu être agressif, et qu’ils finiront par couler. Ca leur pend au nez et au lieu de corriger des problèmes qui sont là depuis des années comme les fuites mémoires ou de créer une sandbox pour Firefox sous Windows et une version pour WP et Win RT afin de prendre dés maintenant des pdm sur ces OS que les autres ont abandonné, ils s’occupent de construire un enième OS mobile qui restera très confidentiel et qui sera + une perte financière qu’autre chose… Ils font vraiment n’importe quoi! <img data-src=" />


votre avatar







JR_Ewing a écrit :



+1000! <img data-src=" />



Je pense aussi que Mozilla va finir par se faire bouffer tout cru par Chrome (au niveau des pdm) parce qu’ils n’auront pas voulu être agressif, et qu’ils finiront par couler. Ca leur pend au nez et au lieu de corriger des problèmes qui sont là depuis des années comme les fuites mémoires ou de créer une sandbox pour Firefox sous Windows et une version pour WP et Win RT afin de prendre dés maintenant des pdm sur ces OS que les autres ont abandonné, ils s’occupent de construire un enième OS mobile qui restera très confidentiel et qui sera + une perte financière qu’autre chose… Ils font vraiment n’importe quoi! <img data-src=" />





Concernant une app Firefox sous WP et Windows RT, c’est pas totalement de leur faute : Microsoft interdit la compilation JIT du Javascript sur WinRT, ce qui empeche Firefox et Chrome de sortir avec leur moteur javascript … Par contre ils pourraient surement porter leur moteur de rendu et utilisé le moteur javascript d’IE en attendant que Microsoft propose une alternative … J’imagine que c’est pour préparer l’arrivé de Midori qui interdit aussi la compilation en temps réel …


votre avatar







Presteus a écrit :



Je te pique avec une première phrase lourde de sens, enchaîne avec une petite anecdote « Développeur vs Concepteur » et j’ai juste droit à 2 pauvres points d’interrogation.





J’ai surtout rien compris à ce que tu voulais dire.







Presteus a écrit :



On ne contourne pas une faiblesse avec un framework, on implémente une nouvelle solution.





Nop si tu as un framework tout fait qui fait du très bon boulot, qui est bien documenté et testé, tu vas pas dépenser du fric et du temps sur ton projet à refaire la même chose.







Presteus a écrit :



Ceci est un problème de management et non de développement, si 2 développeurs développe la même fonctionnalité il y a de forte chance qu’il la pense de manière totalement différente.





Pas du tout. Dans le cas du javascript même faire ce qui correspond à une classe peut se faire de différentes manières. Dans d’autres langages une classe ressemble à une classe. Tu n’as pas 36.000 façon de le faire.



De plus un bon framework te permettra d’avoir un tronc commun beaucoup plus grand justement. Et donc de faciliter le travail en équipe.







Presteus a écrit :



Ici, seul le chef de projet est à blâmer.





Rien avoir. Si ton chef de projet commence à faire du micromanagement sur le moindre détail de code c’est plus un chef de projet.







Presteus a écrit :



C’est pas le but de tout langage que de pouvoir faire sa petite cuisine ?





Oui et non. Pour un projet perso tu fais ce que tu veux oui. Pour un projet en équipe si tu veux faire du bon boulot c’est pas du chacun pour soi. Il faut se mettre d’accord sur des standards de codages (tu dois connaître PSR ?) et essayer de travailler de la même manière. Ca réduit le boulot des relecture du code et ça facilite l’intégration de nouveaux membres dans l’équipe. De plus des framework permettent aussi des standardiser énormément certaines partie du travail qui sont souvent répétitive.







Presteus a écrit :



Quelle époque de PHP parles-tu ? Parce que je la suis et la pratique depuis PHP 3 et c’est la même ; il y a eu aucune révolution dans PHP.





L’époque ou la POO n’éxistait pas. (PHP2 ?). Et depuis la 3 oui il y a eu pas mal de nouveauté bienvenues pour ne pas dire nécessaires.







Presteus a écrit :



J’en resterai là sur PHP parce que je peux devenir très vite méchant quand on tape sur mes amis <img data-src=" />





Oui mais je n’ai pas attaqué PHP. Simplement fait remarqué qu’a une époque il n’était pas aussi complet qu’il l’est aujourd’hui.







Presteus a écrit :



Tout comme pour PHP, ECMAScript 6 ne changera pas radicalement le monde Javascript, c’est une pierre de plus à l’édifice qui permettra d’être parfois plus concis.





Ca permettra de faire de la POO propre et pas mal d’autres choses intéressante (Google sur le sujet tu verras).







Presteus a écrit :



Pour conclure :

De mon avis personnel, les détracteurs ; d’un langage en fonction de « leur » langage de prédilection ; ont autant d’expertise dans « leur » langage que ce qui ressort de leur « contre-argumentaire » (c’est à dire souvent rien).





[/quote]

Je bosse presque exclusivement avec PHP et Javascript. Maintenant je sais que je suis pas le seul à attendre ES6 avec impatience.


votre avatar







Presteus a écrit :



Sauf que vous avez tendance à oublier pourquoi Javascript à été créé et ce qu’est Internet.



Un document de 1980 à tout autant de valeur, si ce n’est plus, que celui qui est produit aujourd’hui.



Je suis désolé mais une page codé correctement avec les standards de l’époque (parce que oui même à l’époque les recommandations existaient) doit et devra toujours s’afficher et fonctionner.



Il n’y a pas que ton petit nombril <img data-src=" />





Euh, ok, en plus de passer pour un semi troll, tu te rend compte que tu es complètement hs part rapport a ce que je dis ….



La rétro compatibilité c’est beau mais ca en fait pas une bonne techno



seb2411 a écrit :



Oui enfin c’est normal que les chosent et les technos évoluent pour s’adapter aux besoins. On va pas rester bloquer aux technos d’il y a 20ans.



Pour ce qui est du dev, perso la partie javascript me casse encore les c mais si tu utilises des framework tu as quand même des choses assez modernes et efficaces.





Je ne dis pas le contraire, je dis que ça a mal évolué justement. A la base, le web c’était fait pour partager des documents statiques, et plutôt scientifique a l’origine (aujourd’hui, le web est tellement dénaturé que tu fais ca avec latex en perdant le cote partage).

La techno html était bonne en soit même si un peu bancale. A cela, certains ce sont dit, ce serait cool si ca pouvait être dynamique … et la, la catastrophe commence, on commence à renvoyer des réponses html entière pour simuler un semblant de dynamisme et de la pire onn ce dit ce serait encore plus cool si on pouvait renvoyer des réponse html partielle et les intégrer a la page en cours ….. <img data-src=" />



Pour être honnête, ca me fait penser a ce que je vois souvent dans les petits projets open source, un truc pensé par un geek pisseur de code, sans offense, mal structuré et qui s’enfonce a chaque fois un peu plus. La preuve en est qu’on est obligé de créer des surcouche comme jquery, typescript etc… qui par analogie sont ce qu’est le c a l’assembleur pour js, ie des surcouche. Le seul qui soit plus framework que surcouche c’est ajaxcontroltoolkkit



Du côté webform, les technologies ont elles aussi évoluées mais la avec plus de bon sens je trouve.


votre avatar







Lafisk a écrit :



…





Il y a quelques années et même encore recement j’aurais été d’accord avec toi. On utilisait (bidouillait) globalement les technos web pour en faire des choses pour lesquels elles n’étaient pas faites.



Aujourd’hui les choses ont pas mal évolue et même si on ressent encore l’héritage des “pages web” on se dirige vers de solutions qui sont quand même mieux structure et propres.



De mon point de vue on est en train de voir disparaître les frontières entre site web et application, car d’un cote les applications utilisent de plus en plus les technos web et de l’autre les sites web utilisent des technos venant du monde des applications.


votre avatar







EMegamanu a écrit :



Faux… tu confonds typage fort et typage faible.







Encore faux… Parler de typage fort ou faible ne sert qu’à indiquer qu’on aime ou non le langage en question.

C’est de typage statique ou dynamique qu’il faut parler pour que ça veuille vraiment dire quelque chose <img data-src=" />


votre avatar







Chiassard a écrit :



Encore faux… Parler de typage fort ou faible ne sert qu’à indiquer qu’on aime ou non le langage en question.

C’est de typage statique ou dynamique qu’il faut parler pour que ça veuille vraiment dire quelque chose <img data-src=" />







Le soucis avec le JavaScript c’est qu’il s’agit d’un langage soit interprété, soit compilé à l’exécution. Du coup parler de typage statique/dynamique me parait alambiqué (en mode mauvaise foi <img data-src=" />)



Mais les deux notions statique/dynamique et fort/faible ne sont pas incompatibles :

fr.wikipedia.org WikipediaDe toute façon, on ne peut pas dire que les types sont très nombreux en JavaScript : number, string, boolean, undefined et object.



Edit : Du coup, dynamique/statique je laisse ça de côté vu que je ne saurai le définir, mais dans le cas de JavaScript c’est du Implicite/Faible. A comparer au C Explicite/Faible et au C++ Explicite/Fort.


votre avatar







seb2411 a écrit :



Il y a quelques années et même encore recement j’aurais été d’accord avec toi. On utilisait (bidouillait) globalement les technos web pour en faire des choses pour lesquels elles n’étaient pas faites.



Aujourd’hui les choses ont pas mal évolue et même si on ressent encore l’héritage des “pages web” on se dirige vers de solutions qui sont quand même mieux structure et propres.



De mon point de vue on est en train de voir disparaître les frontières entre site web et application, car d’un cote les applications utilisent de plus en plus les technos web et de l’autre les sites web utilisent des technos venant du monde des applications.





Les choses s’améliorent avec html5 mais y a encore du chemin pour avoir la souplesse d’une application connectée dans une page web. Au boulot, en faisant notre propre framework, on est arrivé à simuler certains comportement par exemple, ca nous facilite beaucoup le dev mais y en a qui sont tout bonnement impossible à reproduire. Ajoute a ca que ceux réclamant les fonctionnalités et faisant les specs fonctionnelles n’ont jamais fait aucun dev web de leurs vies et tu obtient un beau border


votre avatar

C’est peut être une bonne chose si cela permet à firefox de rattrapper son retard par rapport à chrome.

votre avatar







tanguy_k a écrit :



?

Ne pas avoir d’étape de compilation c’est évidemment un (gros) plus pour le confort du développeur, sinon les langages de script n’existeraient pas.





En quoi serait-ce un gros désavantage d’attendre une demi-seconde en plus lors du déploiement et une demi-seconde en moins lors de l’exécution ?



Faut oublier le C++ et son modèle d’inclusion obsolète, la compilation d’un langage moderne en mode débug c’est extrêmement rapide et beaucoup plus rapide qu’une compilation JS JIT avec son inférence de types (même en mode paresseux).


votre avatar







HarmattanBlow a écrit :



Faut oublier le C++ et son modèle d’inclusion obsolète, la compilation d’un langage moderne en mode débug c’est extrêmement rapide […]





Tu parles de C# et Java ? VM bytecode =&gt; on tourne en rond.



Disons que tu as raison et qu’ils sont stupides de créer un langage interprété puisque l’étape de compilation c’est facile et (presque) instantanée pour le développeur…


votre avatar







tanguy_k a écrit :



Tu parles de C# et Java ? VM bytecode =&gt; on tourne en rond.



Disons que tu as raison et qu’ils sont stupides de créer un langage interprété puisque l’étape de compilation c’est facile et (presque) instantanée pour le développeur…





Ce n’est pas ce que j’ai dit bon sang !



Ce que j’ai dit c’est qu’il sont stupides de créer un langage plutôt qu’un bytecode élémentaire analogue à un langage assembleur. Ce qui serait beaucoup plus léger à transporter, plus rapide à compiler par le navigateur, rétablirait le choix du langage et offrirait à tous ces langages le loisir de profiter de performances maximales ou quasi-maximales.



Le coût d’une demi-seconde par compilation pour le développeur, compensée par un démarrage plus rapide (vu que parser JS et reconstruire un système de types c’est pas gratos), me semble un très maigre prix à payer et je pense que toute personne sensée peut en convenir.


votre avatar







HarmattanBlow a écrit :



Ce n’est pas ce que j’ai dit bon sang !



Ce que j’ai dit c’est qu’il sont stupides de créer un langage plutôt qu’un bytecode élémentaire analogue à un langage assembleur. Ce qui serait beaucoup plus léger à transporter, plus rapide à compiler par le navigateur, rétablirait le choix du langage et offrirait à tous ces langages le loisir de profiter de performances maximales ou quasi-maximales.



Le coût d’une demi-seconde par compilation pour le développeur, compensée par un démarrage plus rapide (vu que parser JS et reconstruire un système de types c’est pas gratos), me semble un très maigre prix à payer et je pense que toute personne sensée peut en convenir.





J’etais pas sur d’avoir compris ton comm non plus en fait et reformuler, je ne peux que approuver <img data-src=" />


votre avatar







HarmattanBlow a écrit :



un bytecode élémentaire analogue à un langage assembleur. Ce qui serait beaucoup plus léger à transporter, plus rapide à compiler par le navigateur, rétablirait le choix du langage et offrirait à tous ces langages le loisir de profiter de performances maximales ou quasi-maximales.





Et ce “bytecode élémentaire” qui résout tous les problèmes (“choix du langage”, “performances maximales”, “une demi-seconde par compilation”), qui rend donc obsolète les JVM, CLR, interpréteurs ect…



T’imagines bien que je vais te demander son petit nom, des liens et des chiffres :)


votre avatar







tanguy_k a écrit :



Et ce “bytecode élémentaire” qui résout tous les problèmes (“choix du langage”, “performances maximales”, “une demi-seconde par compilation”), qui rend donc obsolète les JVM, CLR, interpréteurs ect…



T’imagines bien que je vais te demander son petit nom, des liens et des chiffres :)





Il n’a pas dit que ca existe mais que ce serait mieux si on avait eu ca, sauf erreur de ma part.


votre avatar

L’idée de base est la même que pNaCl qui est un bytecode type assembleur (et non pas un bytecode type java). Le problème de pNaCl c’est qu’il vient avec les API de Google. Il y a aussi asm.js mais celui-ci est plus long à parser et plus volumineux. Ou peut-être le nouveau bytecode du projet Singularity de MS mais je crains qu’il soit d’un niveau trop élevé.





Et je ne dis pas que ça rend osbolète les VM & co, simplement qu’on peut construire ceux-ci par-dessus sans inconvénients, tout comme on les construit aujourd’hui au-dessus du langage assembleur.

votre avatar

Le problème majeur de javascript, c’est que la plupart des personnes qui en font tout un fromage sont des dév travaillant essentiellement sur d’autres langages durant leurs journées.

votre avatar







Lafisk a écrit :



Il n’a pas dit que ca existe mais que ce serait mieux si on avait eu ca, sauf erreur de ma part.









HarmattanBlow a écrit :



L’idée de base est la même que […]





“L’idée de base” ?



On va s’arrêter la parceque parler d’une utopie (1) sortie de ton imagination, ça n’a strictement aucun intérêt à mes yeux.



Parles-en à Lars Bak, ca fait 20 ans qu’il travaille sur ces sujets (VM Smalltalk, HotSpot, V8 et maintenant Dart), il t’embauchera surement.



<img data-src=" />



(1) que je souhaite se réaliser comme tout le monde; “choix du langage”, “performances maximales”, “une demi-seconde par compilation” : bref que des avantages et aucun inconvénients - elle est pas belle la vie la, hein ??


votre avatar







tanguy_k a écrit :



“L’idée de base” ?



On va s’arrêter la parceque parler d’une utopie (1) sortie de ton imagination, ça n’a strictement aucun intérêt à mes yeux.



Parles-en à Lars Bak, ca fait 20 ans qu’il travaille sur ces sujets (VM Smalltalk, HotSpot, V8 et maintenant Dart), il t’embauchera surement.



<img data-src=" />



(1) que je souhaite se réaliser comme tout le monde; “choix du langage”, “performances maximales”, “une demi-seconde par compilation” : bref que des avantages et aucun inconvénients - elle est pas belle la vie la, hein ??







Tu peux te moquer, mais en soit du temps ou il fallait faire des programmes en assembleur car il n’y avait rien d’autre a cote, les mecs devaient avoir le meme reaction que toi, car surement incapable de ce projeter dans l’avenir et voir comment on pourrait faire “mieux”. Heureusement que tout le monde n’a pas penser comme ca en tout cas, sinon je serais pas informaticien aujourd’hui.



votre avatar







tanguy_k a écrit :



On va s’arrêter la parceque parler d’une utopie (1) sortie de ton imagination





Une “utopie” sur laquelle travaillent Google, Mozilla et MS avec des solutions déjà téléchargeables aujourd’hui et soumises à divers comités de standardisation.





Parles-en à Lars Bak, ca fait 20 ans qu’il travaille sur ces sujets (VM Smalltalk, HotSpot, V8 et maintenant Dart), il t’embauchera surement.



Encore une fois tu n’as pas compris ce qu’il disait. Tu n’as pas compris que le type de bytecode dont il parlait n’était pas celui dont je parlais et que ses arguments concernant l’absence de bytecode pour Dart ne s’appliquaient pas du tout à ce dont nous parlons.





bref que des avantages et aucun inconvénients - elle est pas belle la vie la, hein ??



Effectivement, que des avantages et aucun inconvénient. Oui, la vie serait plus belle qu’avec JS ou Dart.


votre avatar







HarmattanBlow a écrit :



Une “utopie” sur laquelle travaillent Google, Mozilla et MS avec des solutions déjà téléchargeables aujourd’hui et soumises à divers comités de standardisation





Des noms, liens, articles, chiffres… ?


votre avatar







tanguy_k a écrit :



Des noms, liens, articles, chiffres… ?





Les noms tu les connais déjà : asm.js, pNaCl, midori, etc.


votre avatar







HarmattanBlow a écrit :



Les noms tu les connais déjà : asm.js, pNaCl, midori, etc.





asm.js et PNaCl s’appuient sur LLVM pour la compilation (LLVM est, comme tu l’as souligné, effectivement plus bas niveau que la JVM par exemple).

Donc d’après toi LLVM compile du code en “une demi-seconde”.




  • Si c’est le cas j’ai effectivement tort =&gt; ce que je qualifiais d’utopie n’en est pas une

  • Si c’est pas le cas, ça tient donc du domaine de l’utopie

    Et ben j’attends les chiffres.



    Rappel de tes propos :





    HarmattanBlow a écrit :



    […] ils sont stupides [ndlr : Lars Bak] de créer un langage [ndlr : Dart] plutôt qu’un bytecode élémentaire analogue à un langage assembleur [ndlr : asm.js, PNaCl, LLVM…].

    Ce qui serait [ndlr : bullet points]

  • beaucoup plus léger à transporter

  • plus rapide à compiler par le navigateur

  • rétablirait le choix du langage

  • offrirait à tous ces langages le loisir de profiter de performances maximales ou quasi-maximales

    […]

  • Le coût d’une demi-seconde par compilation pour le développeur

  • compensée par un démarrage plus rapide

    […]




votre avatar







tanguy_k a écrit :



Donc d’après toi LLVM compile du code en “une demi-seconde”.





Voici deux propositions parfaitement logiques :



a) Il est plus rapide de compiler un langage vers le bytecode LLVM que vers un langage assembleur spécialisé. Donc la compilation AOT vers ce bytecode serait plus rapide que ne l’est la compilation JIT aujourd’hui.



b) Il est extrêmement plus rapide de compiler un bytecode LLVM vers de l’assembleur que de parser, analyser, construire un système de types et finalement compiler vers de l’assembleur un langage comme JS. Donc la compilation JIT de ce bytecode serait plus rapide que la compilation JIT de JS.





La seule chose sur laquelle tu peux pinailler c’est que dans le (a) la compilation AOT totale est en fait comparée à une compilation JIT paresseuse. Mais les compilations AOT de Java ou dotnet vers leurs bytecode respectifs sont extrêmement rapides (de l’ordre de la demi-seconde pour de gros projets) et l’usage du bytecode LLVM n’introduit pas de difficulté supplémentaire.


votre avatar







HarmattanBlow a écrit :



les compilations AOT de Java ou dotnet vers leurs bytecode respectifs sont extrêmement rapides (de l’ordre de la demi-seconde pour de gros projets) et l’usage du bytecode LLVM n’introduit pas de difficulté supplémentaire





C’est la ou tu te trompes.

Pour simplifier la compilation c’est une transformation (ou une traduction).





  • Quand tu transformes un langage haut niveau vers un bytecode “haut niveau” proche du langage source (CLR, JVM) =&gt; rapide

  • Quand tu transformes un langage haut niveau vers un langage bas niveau (de surcroît générique) =&gt; lent



    Pour simplifier encore :

    Quand on transforme A vers B, plus B est différent de A, plus c’est compliqué (donc lent) et inversement.



    Il n’y a pas de miracle, tu peux pas avoir les avantages sans les contreparties.



    C’est pour ça que je te demande des chiffres pour LLVM : ils ne sont pas de l’ordre de la demi-seconde, sinon tu m’aurais déjà cloué le bec depuis longtemps.

    Tu imagines bien que Google ne se lancerait pas dans Dart en plus de PNaCl si PNaCl n’avait que des avantages.


Brendan Eich, créateur du JavaScript, devient PDG de Mozilla

  • Un nombre croissant de défis 

  • Brendan Eich, nouveau PDG de Mozilla 

  • Firefox OS devient la grande priorité 

  • Compter sur la scène mobile 

Fermer