Angular 4.0 disponible : objectif, réduire le poids des applications web

Angular 4.0 disponible : objectif, réduire le poids des applications web

Et personne ne s'en plaindra

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

24/03/2017 3 minutes
139

Angular 4.0 disponible : objectif, réduire le poids des applications web

Angular, un framework de Google conçu pour le développement des applications web, est désormais disponible en version 4.0. Les nouveautés sont nombreuses, avec un support amélioré de TypeScript, une amélioration des performances ou encore une parité fonctionnelle de la version Universal.

Angular est un framework très largement utilisé aujourd’hui. Il doit faciliter le développement des applications web et met en avant, depuis sa version 2.0, le langage TypeScript de Microsoft, qui est pour rappel un surensemble de JavaScript adapté aux gros projets. En octobre, Google avait annoncé qu’un changement important allait s’opérer dans la numérotation, l’équipe adoptant une gestion sémantique des versions.

Le code AOT réduit de 60 % le plus souvent

Voilà donc Angular 4.0, qui est en fait la troisième version majeure du framework, la 3.0 n’ayant pas existé. Les nouveautés sont assez nombreuses, et bien qu’il s’agisse d’une mouture importante, elle est « compatible avec la 2.X.X pour la plupart des applications ». L’un des axes d’amélioration est de rendre les applications construites avec Angular plus légères et plus rapides. Plusieurs nouveautés vont donc en ce sens.

Dans la plupart des cas, le code généré AOT (ahead-of-time) est ainsi réduit de 60 %. L’équipe précise que plus les modèles utilisés sont complexes, plus les gains sont visibles. Plusieurs développeurs auraient confirmé d’importants gains pendant la période de test. Par ailleurs, toutes les animations ont été extraites d’Angular/Core et réunies dans leur propre paquet. Si le développeur n’en a pas besoin, le code généré n’en sera que plus léger.

Prise en charge des dernières versions de TypeScript

Angular 4.0 apporte également la compatibilité avec les versions 2.1 et 2.2 de TypeScript, et donc les améliorations apportées au cours des derniers mois par le langage, ainsi que de meilleures performances pour ngc. Universal, qui permet un fonctionnement d’Angular sur un serveur, a de son côté été mis à jour et est de nouveau en phase avec le framework principal. Universal était initialement un projet de la communauté, désormais adopté par l’équipe de développement.

Parmi les autres apports, signalons une plus grande souplesse pour *ngIf et *ngFor, la génération de cartes des sources quand une erreur apparait dans un modèle, l’arrivée des Flat ES Modules, le support expérimental des builds ES2015, tout comme celui des annotations Closure, ouvrant la voie à des optimisations.

139

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le code AOT réduit de 60 % le plus souvent

Prise en charge des dernières versions de TypeScript

Commentaires (139)


Il y a eu une version 3 ? J’ai l’impression que la 2 est sortie hier. C’est calqué sur Chrome ?


WTF, ça sort d’où cette version 4?








revker a écrit :



Il y a eu une version 3 ? J’ai l’impression que la 2 est sortie hier. C’est calqué sur Chrome ?





dans l’article: Voilà donc Angular 4.0, qui est en fait la troisième version majeure du framework, la 3.0 n’ayant pas existé. :) 



Il est incompatible avec la version 2 ? <img data-src=" />








revker a écrit :



Il y a eu une version 3 ? J’ai l’impression que la 2 est sortie hier. C’est calqué sur Chrome ?







Nouvelle version tous les 6 mois.



Versioning and Releasing Angular



“objectif, réduire le poids des applications web”



&nbsp;go switch vanilla&nbsp;<img data-src=" />



Maintenant je vais lire&nbsp;<img data-src=" />


C’est annoncé rétro-compatible avec les versions 2 dans la plupart des cas (l’article le mentionne <img data-src=" />)



Mais bon quand je vois ça qui débarque de nulle part (bon je ne suis pas Angular de très près mais je n’ai tout de même jamais entendu dire qu’une version 4 devait sortir avant cet article) ça n’arrange pas ma méfiance avec les outils de dev by Google. Ils font ce qu’ils veulent comme ils veulent puis un jour ils vont foutre tout ça à la poubelle en laissant sur le carreau les milliers de devs qui avaient décidé de suivre le mouvement.


J’ai pas trop accroché à Angular (ni le 1 trop brouillon, ni le 2 trop jeune). J’ai récemment découvert EmberJS et c’est juste top. Un vrai framework JS open-source et communautaire, bien conçu, qui incite au bonnes pratiques et qui évolue bien sans être au main d’une seule entreprise comme Angular


mais non c’est un versioning en puissance de 2 voyons

<img data-src=" />


De nul part annoncé depuis le octobre 2016… <img data-src=" />


C’était amusant angular.js mais suis revenue a la source, le classique asp.net web.api / mvc. Avec les partial view et le bon vieux jquery pour l’appel ajax: on en arrive au même résultat mais, plus robuste et meilleur maintenabilité pour de grosses apps comparé au one page !


Je troll mais placer dans la même argumentation jQuery, robustesse et maintenabilité, c’est fort en chocolat.&nbsp;Angular est un framework qui réponds à un besoin en apportant une architecture et une logique (approche par composant, middleware, reactivité, testing, etc), pas une librairie pour manipuler du DOM et faire des effets wahou. Tu&nbsp;as juste déplacé le côté framework vers le serveur.


Faut le lire l’article pas foncé vers les commentaires comme un forcené








Chiendelune a écrit :



Je troll mais placer dans la même argumentation jQuery, robustesse et maintenabilité, c’est fort en chocolat. Angular est un framework qui réponds à un besoin en apportant une architecture et une logique (approche par composant, middleware, reactivité, testing, etc), pas une librairie pour manipuler du DOM et faire des effets wahou. Tu as juste déplacé le côté framework vers le serveur.





+1.



“la génération de cartes des sources”



il m’a fallu 2s pour faire le rapprochement avec les sourcemaps <img data-src=" />


Ces frameworks évoluent trop vite.


Il à pas déplacer le framework vers le server, il est revenue a se qui se faisait avant et qui fonctionne toujours aussi bien (les framework ont été déplacé vers les clients, par l’inverse).

Et par “robustesse et maintenabilité”, je pense qu’il faisait plus allusions a Asp.Net qu’a&nbsp;jquery&nbsp;qui n’est qu’un outils.


Pour commencer à s’amuser à créer des petites applications c’est interessant comme framework ou il y a mieux ?


Pour ma part c’est la compatibilité “avec la plupart” des éléments qui m’a précisément fait laisser tomber le Javascript. À cause de ça et de l’évolution des navigateurs il est malheureusement impossible de maintenir une application plus de deux ans. Et comme il n’y a pas de phase de compilation on ne découvre ces problèmes qu’à l’exécution. Alors certains me parlerons de tests automatisés, oui c’est vrai… sauf que les frameworks de tests automatisés évoluent à la même vitesse que le reste en JS et sans garder forcément de compatibilité ascendante…



&nbsp;Et ne parlons pas du JS côté serveur…


Si tu commence, je te conseillerai personnellement VueJS. C’est un framework encore peu connu par rapport à Angular ou les autres “gros” mais il est très performant et surtout simple pour commencer. Pour apprendre les best practices et s’amuser c’est le top.



&nbsp;Et en plus, c’est un framework bien construit et que tu peux sans problème utiliser par la suite pour de plus grosses applications.


Tout dépends de ce que tu veux faire avec ta petite application. Si tu as besoin d’un truc simple et rapide, tu peux partir sur React, VueJS voir Meteor (pour avoir le côté serveur) qui ont une courbe d’apprentissage plus simple et qui sont moins contraignant sur la structure.

&nbsp;

&nbsp;Après, si tu veux un truc très structuré, tu peux partir sur du EmberJS ou Angular 2. Tu as un mini tuto sur le site officiel d’Angular 2 qui va te donner une idée de la complexité.








axelpeigne a écrit :



…VueJS. C’est un framework encore peu connu&nbsp;





Et pourtant y’a pas plus hype depuis 2ans…









goldbergg a écrit :



Il à pas déplacer le framework vers le server, il est revenue a se qui se faisait avant et qui fonctionne toujours aussi bien (les framework ont été déplacé vers les clients, par l’inverse).

Et par “robustesse et maintenabilité”, je pense qu’il faisait plus allusions a Asp.Net qu’a&nbsp;jquery&nbsp;qui n’est qu’un outils.





C’est pas vraiment déplacer, c’est séparé 1 grosse application en 2 applications (qui peuvent être grosse aussi). L’approche uniquement serveur, c’est pas plus robuste et maintenable qu’avoir (une API +) un Front, c’est juste centralisé à un seul endroit donc on a un monolithe qui est pas forcément plus maintenable avec une scalabilité plus complexe donc pas forcément plus robuste. &nbsp;Après, l’approche uniquement serveur fonctionne(ra) toujours aussi bien et c’est pour ça que je l’utilise encore quand j’ai pas besoin de faire (trop) de front ou que la performance d’affichage n’entre pas en jeux.

&nbsp;

Ca sort du sujet de cet article du coup j’argumenterais pas plus.









Chiendelune a écrit :



Je troll mais placer dans la même argumentation jQuery, robustesse et maintenabilité, c’est fort en chocolat. Angular est un framework qui réponds à un besoin en apportant une architecture et une logique (approche par composant, middleware, reactivité, testing, etc), pas une librairie pour manipuler du DOM et faire des effets wahou. Tu as juste déplacé le côté framework vers le serveur.











goldbergg a écrit :



Il à pas déplacer le framework vers le server, il est revenue a se qui se faisait avant et qui fonctionne toujours aussi bien (les framework ont été déplacé vers les clients, par l’inverse).

Et par “robustesse et maintenabilité”, je pense qu’il faisait plus allusions a Asp.Net qu’a jquery qui n’est qu’un outils.







Oui c’est bien ça <img data-src=" />. JQuery c’est un choix presque par défaut aussi si tu veux faire de l’ajax et manipuler un peu le dom (qui souvent se résume a changer une partie du contenu html… mais rien n’empêche d’ajouter un plugin jquery pour des composants plus dynamiques style un datatable, slider / galerie… la base quoi). En js vanilla c’est quand même moins agréable. <img data-src=" /> Non mais pour la vue / modèle, générer coté serveur pour certains gros projets en sa finalité c’est plus intéressant. En plus mvc 6 et razor c’est très propre pour afficher les données du modèle.



Ceci dit, pour une webapp one page, très axée appel de donnes (surtout si c’est du temps réel), pour un projet qu’on veux éventuellement déployer en multiplate-forme, oui y a angular, react, meteor.. le choix ne manque pas !



C’est clair








axelpeigne a écrit :









Chiendelune a écrit :





<img data-src=" /> Je prend note merci.









revker a écrit :



Il y a eu une version 3 ? J’ai l’impression que la 2 est sortie hier. C’est calqué sur Chrome ?









gogo77 a écrit :



WTF, ça sort d’où cette version 4?







En fait il sont passer à la version 4 pour uniformiser les numéros de version des paquets internes. Il était tous en 2.x.x sauf router qui était en 3.x.x

Du coup avec la 4 il uniformise tout ca et tout le monde passe en 4.x.x









gogo77 a écrit :



C’est annoncé rétro-compatible avec les versions 2 dans la plupart des cas (l’article le mentionne <img data-src=" />)



Mais bon quand je vois ça qui débarque de nulle part (bon je ne suis pas Angular de très près mais je n’ai tout de même jamais entendu dire qu’une version 4 devait sortir avant cet article) ça n’arrange pas ma méfiance avec les outils de dev by Google. Ils font ce qu’ils veulent comme ils veulent puis un jour ils vont foutre tout ça à la poubelle en laissant sur le carreau les milliers de devs qui avaient décidé de suivre le mouvement.







C’est bien pour ça que personnellement je ne conseille jamais les frameworks venant de cette boite.



C’est un retour personnel de toi même ou bien c’est un retour de ta boîte suite à de nombreux gros projets avec plein de dev ?



(d’un point de vu personnel, je vais dans ton sens, les entreprises ont plutôt l’air de surfer sur la vague JS partout)


Je ne suis pas trop dans la communauté JS donc je ne sais pas, mais en tout cas quand je parle de ce type de framework à mes clients ils connaissent tous Angular, certains connaissent React ou EmberJS mais j’en ai jamais eu qui connaissaient VueJS.



Mais tant mieux si c’est plus connu que l’idée que j’en ai, pour moi c’est vraiment un très bon framework.


Ca me troue le Q à chaque fois que je lis que pour faire un appel Ajax ou manipuler le DOM, faut JQuery ou un autre framework…


Oui je me doute bien que ça avait été annoncé et que j’avais simplement loupé l’info à l’époque et j’admet ma mauvaise foi sur ce coup là <img data-src=" />



Mais bon je trouve le développement de cette librairie chaotique, à l’image de plein de choses proposées par Google où c’est toujours aux utilisateurs de s’adapter à ce qu’ils veulent bien donner et jamais l’inverse. Je n’ai aucune confiance en eux pour réaliser des projets à long terme avec leurs outils.


Bizarre la police du “by Google” dans l’image d’Angular, non? <img data-src=" />




Les nouveautés sont nombreuses, avec un support amélioré de TypeScript,

une amélioration des performances ou encore une parité fonctionnelle de

la version Universal.





On parie qu’Angular 5.0 proposera un support amélioré de TypeScript, des améliorations de perf ? Il manque juste “la correction de bugs” et “totally amaaaazing” pour être candidat au Changelog Twitter Style Competition <img data-src=" />


GWT, AngularJS et Angular sont toujours supportés…








Pochi a écrit :



C’est un retour personnel de toi même ou bien c’est un retour de ta boîte suite à de nombreux gros projets avec plein de dev ?



(d’un point de vu personnel, je vais dans ton sens, les entreprises ont plutôt l’air de surfer sur la vague JS partout)







Surtout sur de gros projets en entreprises. Le truc avec angular aujourd’hui, c’est que ça veut devenir le truc de base qu’on va utiliser quel que soit le projet web… De toute façon, d’un point de vue développeur, ça se vend bien car c’est magique. Mais force de constater, une fois qu’une application web gonflé, on voit vite ses limites et lourdeurs (on oublie pas que derriere c’est que du JS). Je dirais même qu’on a même plus tendance a coder scripter de manière peu optimal, a faire des appels api a outrance et peu utiliser de la mise en cache. Peut etre avec TS les choses vont changer, mais a cause de la syntaxe et la structure de angular, une fois atteint l’application a maturité, bref grossi, on s y retrouve largement moins bien qu’un langage traditionnel en objet, donc la structure .net <img data-src=" />.



Mon experience est toute autre. Avoir un mix html / js autant coté serveur que coté client trouve rapidement ses limites à mesure que l’application grossi au temps au niveau du développement que pour l’expérience de utilisateur.&nbsp; La logique applicative se retrouve distribuée au niveau du serveur et au niveau du client avec des mixes qui peuvent être peu joyeux pour pallier au limite de l’approche serveur.&nbsp;



&nbsp;








plop97 a écrit :



J’ai pas trop accroché à Angular (ni le 1 trop brouillon, ni le 2 trop jeune). J’ai récemment découvert EmberJS et c’est juste top. Un vrai framework JS open-source et communautaire, bien conçu, qui incite au bonnes pratiques et qui évolue bien sans être au main d’une seule entreprise comme Angular







Ma définition de “Bonne pratique” : ne pas programmer en Javascript <img data-src=" />



Oui tu le fais en vanilla en 5 lignes.



10 si tu prends en comptes IE.



Ah et puis il faut charger le polyfill X parce que le browser X ne suit pas les redirections.



Et le polyfill Y parce que l’autre ne fonctionne pas en local



Et le polyfill X-Y parce qu’il y a des légères incompatibilités si tu utilises X en même temps que Y



…&nbsp;


Ah c’est sûr qu’autrefois, c’était bien lourd, les requêtes Ajax. Mais ECMA a fait de gros efforts pour les rendre plus accessibles sans avoir à passer par des librairies externes !

&nbsp;

&nbsp;Essaie Fetch https://developer.mozilla.org/fr/docs/Web/API/Fetch_API/Using_Fetch), ou sinon un simple système de promesses. Reste plus qu’à attendre quelques années pour que tous les navigateurs “supportables” comprennent Fetch…



EDIT: V1nce, plus haut, a bien ciblé le problème…








Folgore a écrit :



Oui c’est bien ça <img data-src=" />. JQuery c’est un choix presque par défaut aussi si tu veux faire de l’ajax et manipuler un peu le dom (qui souvent se résume a changer une partie du contenu html… mais rien n’empêche d’ajouter un plugin jquery pour des composants plus dynamiques style un datatable, slider / galerie… la base quoi). En js vanilla c’est quand même moins agréable. <img data-src=" /> Non mais pour la vue / modèle, générer coté serveur pour certains gros projets en sa finalité c’est plus intéressant. En plus mvc 6 et razor c’est très propre pour afficher les données du modèle.



Ceci dit, pour une webapp one page, très axée appel de donnes (surtout si c’est du temps réel), pour un projet qu’on veux éventuellement déployer en multiplate-forme, oui y a angular, react, meteor.. le choix ne manque pas !





Sauf que pour manipuler le DOM et faire de l’AJAX, jQuery n’apporte presque rien.

&nbsp;



Pour ceusses qui se posent des questions sur le saut de version, c’est un peu la même histoire que pour Android.



Google a voulu uniformiser tous les “composants” qui avaient chacun leur propre numéro de version. Ils étaient tous en 2.x, sauf le router qui était en 3.3.x. Donc désormais tous se retrouvent en 4.x pour éviter un joyeux bordel.



Et Angular 5.0 arrive en septembre ou octobre. Donc faisons toutes les blagues sur le numéro de version maintenant, ainsi on pourra parler du fond la prochaine fois <img data-src=" />








Jarodd a écrit :



Et Angular 5.0 arrive en septembre ou octobre. Donc faisons toutes les blagues sur le numéro de version maintenant, ainsi on pourra parler du fond la prochaine fois <img data-src=" />





T’es vachement optimiste toi…&nbsp;<img data-src=" />

On en est à la 56 version de chrome, et les gens continuent de troll à chaque news…&nbsp;



jQuery facilite drastiquement la manipulation du DOM et les appels Ajax. Si bien que c’est le truc que j’ajoute par défaut à chaque projet. Je crois même que j’avais craqué pour backbone à l’époque notamment car il utilisais jQuery pour la gestion du dom et ses appels Ajax.


Ah bon ? Tu peux développer un peu ?


C’est quoi l’intérêt de ce genre de Framework par rapport aux framework php classiques ?


Les framework php sont très bien, tu utilises un framework js en plus quand tu aimerais avoir un équivalent sur le front. Les front deviennent de plus en plus complexe, ils représentent à eux seuls une application entière(apps single page par exemple) de nos jours du coup les mêmes raisons qui t’ont poussées à choisir un framework par rapport à php vanilla te pousseront à choisir angular ou autre par rapport à js vanilla pour ton app single page.


Du coup tu code dans quel language pour les interactions sur tes interfaces ?








sr17 a écrit :



Ma définition de “Bonne pratique” : ne pas programmer en Javascript <img data-src=" />





Amen.

Avec l’ES2015+ j’y cru naïvement qu’il allait devenir possible de faire quelque chose de pas trop dégueulasse.

…c’était avant de le pratiquer&nbsp;<img data-src=" />



Il faut déjà commencer par bouffer ça:https://github.com/getify/You-Dont-Know-JS

Et ensuite&nbsp;aussi développé par Google, mais bien plus bas niveauhttps://github.com/google/incremental-dom/.


Je ne comprends pas pourquoi il y a autant d’effervescence avec le JavaScript, sérieusement pourquoi faire un nouveau truc tous les ans ? Je regrette amèrement l’époque ou Google soutenait activement GWT.








Folgore a écrit :



C’était amusant angular.js mais suis revenue a la source, le classique asp.net web.api / mvc. Avec les partial view et le bon vieux jquery pour l’appel ajax: on en arrive au même résultat mais, plus robuste et meilleur maintenabilité pour de grosses apps comparé au one page !





<img data-src=" />









Zed-K a écrit :



Amen.

Avec l’ES2015+ j’y cru naïvement qu’il allait devenir possible de faire quelque chose de pas trop dégueulasse.

…c’était avant de le pratiquer&nbsp;<img data-src=" />





Est ce que tu as utilisé un transporteur (Babel) et de bons polyfills (polyfill.io), histoire d’être sur une base homogène ?



J’ai commencé par le Basic, continué avec le C, C++, Java pendant longtemps, et dernièrement Python et enfin JavaScript. D’abord “à la dure” sur IE7, et maintenant en ES7 avec babel, côté client et serveur.



Dans cette dernière version, le language est très agréable. Sensiblement plus que le Python si l’on s’intéresse à la programmation fonctionnelle par exemple. Au final je préfère largement l’ES7 aux languages cités ci-dessus.



En réalité, s’il y a un truc que je n’aime pas en JS, ce sont les frameworks lourd-dingues type Angular, Backbone, Redux et ses amis, etc. En Java c’étaient les Spring, JSF, Hibernate et consorts… Python a ses mauvais côtés aussi.



Au final tout ça ce n’est qu’une histoire de goûts, de coûts et de mode. Le truc c’est d’arriver au meilleur résultat possible, en en faisant le moins possible, et avec un minimum de code “legacy” et de dette technique.






D’accord, mais bon, jamais été bridé sur le Front avec un Framework php <img data-src=" />


Arrêtez de vouloir faire des applications en JavaScript, et commencez à apprendre des vrais langages. Et la programmation.



Quand je vois l’utilisation des ressources des applications en Node, Angular, ou autre connerieJS, ça me fait bondir.



Et dire que les 10 premiers commentaires de cette Ness sont des fan boys “ouais il vaut mieux utiliser l’autre merdeJS”.

Non.



Le js est un langage de script pour faire clignoter un bouton dans une interface web, rien d’autre.








trevisev a écrit :



Est ce que tu as utilisé un transporteur





P* d’autocorrect #badUX









trevisev a écrit :



Est ce que tu as utilisé un transporteur (Babel) et de bons polyfills (polyfill.io), histoire d’être sur une base homogène ?&nbsp;



&nbsp;

Je bosse sur un projet Node.js 7.7.x, donc pas besoin.









Maxim Killigan a écrit :



Quand je vois l’utilisation des ressources des applications en Node, Angular, ou autre connerieJS, ça me fait bondir.



(…)

&nbsp;

Le js est un langage de script pour faire clignoter un bouton dans une interface web, rien d’autre.







Alors :




  1. Oui

  2. Non, même pas, parc’que oui au 1)



    https://github.com/Microsoft/vscode/issues/22900



    <img data-src=" />









Maxim Killigan a écrit :



Arrêtez de vouloir faire des applications en JavaScript, et commencez à apprendre des vrais langages. Et la programmation.



Quand je vois l’utilisation des ressources des applications en Node, Angular, ou autre connerieJS, ça me fait bondir.



Et dire que les 10 premiers commentaires de cette Ness sont des fan boys “ouais il vaut mieux utiliser l’autre merdeJS”.

Non.



Le js est un langage de script pour faire clignoter un bouton dans une interface web, rien d’autre.





T’arrives une décénnie trop tard pour dire ça… &nbsp;Faut que tu nous donnes la liste de tes “vrais” langages, histoire qu’on sache comment développer une application web.

&nbsp;

Un exemple tout con, faire un formulaire. Quand tu dois définir des contraintes de types de champs à saisir, de longueur, d’unicité, et je ne sais quoi encore, tu fais quoi ? Tu laisses l’utilisateur tout saisir, et quand ça arrive sur le serveur, tu lui renvois 3 secondes plus tard une tartine de messages d’erreurs ?

&nbsp;

Ben non, c’est du JavaScript, et même si c’est faisable enVanilla JS, pour peu que tu bosses avec d’autres personnes, sans utiliser un framework comme Angular (ou un autre, mais on est sur une news Angular…) ça va être un beau bordel très rapidement, et ça prendra 10 fois plus de temps. Avec Angular, en une heure, c’est fini, et ton utilisateur va pas se tirer une balle en arrivant au bout et en voyant qu’il a tout faux dans ce qu’il a rempli.



Bref, un bon développeur Web, il connait un langage serveur, et Javascript. Le langage serveur peut aussi être &nbsp;JavaScript, mais de mon côté, c’est C#. Et pour connaitre JavaScript, comme disait quelqu’un au dessus, faut commencer avec ça :https://github.com/getify/You-Dont-Know-JS &nbsp;









PanDaReN a écrit :



Un exemple tout con, faire un formulaire. Quand tu dois définir des contraintes de types de champs à saisir, de longueur, d’unicité, et je ne sais quoi encore, tu fais quoi ? Tu laisses l’utilisateur tout saisir, et quand ça arrive sur le serveur, tu lui renvois 3 secondes plus tard une tartine de messages d’erreurs ?&nbsp;&nbsp;



&nbsp;

Si ton serveur met 3 secondes à renvoyer une réponse, j’ose pas imagine la tronche de ton code&nbsp;<img data-src=" />



Sinon ce n’est pas la nécessité de code côté client dont il est question, mais de la qualité du seul langage qui y est autorisé.



EDIT: Et choisir la validation de formulaire pour évoquer la nécessité d’un framework JS…

Comment dire… ça en dit long ? &nbsp;<img data-src=" />









Zed-K a écrit :



&nbsp;



Si ton serveur met 3 secondes à renvoyer une réponse, j'ose pas imagine la tronche de ton code&nbsp;<img data-src=">  





Sinon ce n’est pas la nécessité de code côté client dont il est question, mais de la qualité du seul langage qui y est autorisé.



EDIT: Et choisir la validation de formulaire pour évoquer la nécessité d’un framework JS…

Comment dire… ça en dit long ? &nbsp;<img data-src=" />





Je ne demande qu’à apprendre, montre moi :)









Zed-K a écrit :



Si ton serveur met 3 secondes à renvoyer une réponse, j’ose pas imagine la tronche de ton code <img data-src=" />



Sinon ce n’est pas la nécessité de code côté client dont il est question, mais de la qualité du seul langage qui y est autorisé.



EDIT: Et choisir la validation de formulaire pour évoquer la nécessité d’un framework JS…

Comment dire… ça en dit long ?  <img data-src=" />













PanDaReN a écrit :



Je ne demande qu’à apprendre, montre moi :)







Bah déjà on parle de quel langage ? Puis, ça dépend aussi du serveur, entre un petit mutualisé et un serveur dédié avec une très bonne config il y a un monde :)



En tout cas par exemple, au boulot, on travaille sur une application métier utilisant Symfony (framework php) et faisant du multisites, et bah sur notre serveur dédié ça mets pas 3sec à répondre… Pourtant Symfony est assez “lourd”, sans parler de php qui n’est pas reconnu pour sa rapidité <img data-src=" />









Cara62 a écrit :



Bah déjà on parle de quel langage ? Puis, ça dépend aussi du serveur, entre un petit mutualisé et un serveur dédié avec une très bonne config il y a un monde :)



En tout cas par exemple, au boulot, on travaille sur une application métier utilisant Symfony (framework php) et faisant du multisites, et bah sur notre serveur dédié ça mets pas 3sec à répondre… Pourtant Symfony est assez “lourd”, sans parler de php qui n’est pas reconnu pour sa rapidité <img data-src=" />





Non mais bon, le 3sec, &nbsp;c’était une image hein :p Mais pour peu qu’il faille interroger un CRM, un SharePoint (surtout un SharePoint), ou autre pour valider des entrées, ça monte vite, d’où l’intérêt d’avoir de l’asynchrone “transparent” pour le user.

&nbsp;Après, j’ai pas dit non plus qu’il fallait sortir Angular dès qu’on avait un formulaire à faire, c’est un exemple parmis d’autre du gain de productivité sur une appli web un minimum complexe. Tout est une question de coûts.

&nbsp;



Bah le “problème”, c’est qu’on peut largement faire ça sans angular… c’est pour ça qu’à titre personnel je vois pas l’intérêt <img data-src=" />



Bon faut dire, je suis orienté dev backend et non Front, je me contente de Bootstrap pour ça <img data-src=" />


Merci, je l’aurais pas mieux dit que toi. C’est pénible d’entendre toujours ce javascript bashing quand il n’y a pas d’alternative qui soit aussi unanimement supportée par les navigateurs.



Par ailleurs merci pour les livres, j’ai commencé la lecture.








Cara62 a écrit :



Bah le “problème”, c’est qu’on peut largement faire ça sans angular… c’est pour ça qu’à titre personnel je vois pas l’intérêt <img data-src=" />



Bon faut dire, je suis orienté dev backend et non Front, je me contente de Bootstrap pour ça <img data-src=" />







L’exemple du formulaire de PanDaRen montre surtout l’utilité de javascript sur un front. Si par exemple t’as un formulaire avec des contraintes, ou si tu veux mettre de l’autocompletion sur un champs, apart javascript de quel language disposes tu ?



Ensuite le choix d’un framework comme Angular ne se fait pas sur ces exemples triviaux.



Bah je le fais en JQuery, et la verif côté serveur grâce à PHP… Ou alors avec Angular tu peux faire la verif côté serveur aussi ?



Parce que la règle d’or est, ne JAMAIS faire confiance à l’utilisateur, donc une verif côté client (via js par exemple) n’est pas suffisant. ;)



J’arrive pas à visualiser le fait, que tiens pour faire telle application web je vais utiliser Angular (ou autre) et non le classique PHP/Jquery …


Justement tu confirmes ce que je dis. jQuery n’etant pas un langage mais une librairie JavaScript.



T’as toujours besoin de JavaScript quoi, pour une UX un minimum potable, le JS est incontournable sur le web :)



Encore une fois le choix d’Angular ou React ou … se fait pas sur ce genre d’exemples aussi triviaux.

Imagine toi faire l’UI de Twitter avec jQuery et t’as de grandes chances de te retrouver avec du bon spaghetti avec des ajax qui vont dans tout les sens.



Et bien sur, la verif coté serveur est obligatoire !








Cara62 a écrit :



Bah je le fais en JQuery, et la verif côté serveur grâce à PHP… Ou alors avec Angular tu peux faire la verif côté serveur aussi ?



Parce que la règle d’or est, ne JAMAIS faire confiance à l’utilisateur, donc une verif côté client (via js par exemple) n’est pas suffisant. ;)



J’arrive pas à visualiser le fait, que tiens pour faire telle application web je vais utiliser Angular (ou autre) et non le classique PHP/Jquery …





Oui, tu as raison, c’est juste que c’était pas le but de l’exemple que je donnais.

&nbsp;Angular (ou jQuery), se charge de la vérif synchrone ou asynchrone au fur et à mesure que l’utilisateur tape, pour lui indiquer de suite si il fait une connerie, et quand tout est bon, et qu’il post son formulaire, tu vérifies côté serveur histoire de pas injecter des conneries dans ta base.

Encore une fois, mon point de départ était d’abord de dire que JS est indispensable aujourd’hui pour le web (à défaut d’autre chose), et ensuite &nbsp;l’utilité d’utiliser des framework comme Angular, Backbone, jQuery (ou autre) pour ne pas réécrire la roue tous les matins.



[EDIT] Voilà, grillé.









stefann sasori a écrit :



Justement tu confirmes ce que je dis. jQuery n’etant pas un langage mais une librairie JavaScript.



T’as toujours besoin de JavaScript quoi, pour une UX un minimum potable, le JS est incontournable sur le web :)



Encore une fois le choix d’Angular ou React ou … se fait pas sur ce genre d’exemples aussi triviaux.

Imagine toi faire l’UI de Twitter avec jQuery et t’as de grandes chances de te retrouver avec du bon spaghetti avec des ajax qui vont dans tout les sens.



Et bien sur, la verif coté serveur est obligatoire !













PanDaReN a écrit :



Oui, tu as raison, c’est juste que c’était pas le but de l’exemple que je donnais.

 Angular (ou jQuery), se charge de la vérif synchrone ou asynchrone au fur et à mesure que l’utilisateur tape, pour lui indiquer de suite si il fait une connerie, et quand tout est bon, et qu’il post son formulaire, tu vérifies côté serveur histoire de pas injecter des conneries dans ta base.

Encore une fois, mon point de départ était d’abord de dire que JS est indispensable aujourd’hui pour le web (à défaut d’autre chose), et ensuite  l’utilité d’utiliser des framework comme Angular, Backbone, jQuery (ou autre) pour ne pas réécrire la roue tous les matins.



[EDIT] Voilà, grillé.







Je vais reformuler autrement je pense, on est d’accord pour que le front, et dynamiser une page le JS est obligatoire, mais en ce qui concerne Angular, on peut l’utiliser côté serveur ?



Par exemple, je veux faire un mini réseau sociaux, on peut utiliser QUE Angular ? Ou faudra un autre langage derrière ? (PHP, C# etc…)



Cette explication est vaseuse lol. Pourquoi ne pas garder router en 3.x.x et upgrader les autres en 3.x.x pareillement.








stefann sasori a écrit :



Merci, je l’aurais pas mieux dit que toi. C’est pénible d’entendre toujours ce javascript bashing quand il n’y a pas d’alternative qui soit aussi unanimement supportée par les navigateurs.&nbsp;&nbsp;



&nbsp;

Le fait qu’il n’y a pas d’alternative à JS rendrait sa critique impossible ?



Ouai tu peux :

https://universal.angular.io/overview/



Mais je conseille pas, Angular n’étant pas fait au depart pour le coté serveur.

Si tu veux absolument garder le même langage des deux coté tu peux faire

AngularJs coté client et NodeJs coté serveur. Tous 2 sont en JS et s’entendent à merveille.








Zed-K a écrit :



Le fait qu’il n’y a pas d’alternative à JS rendrait sa critique impossible ?







Non. Je deplore surtout ce genre de commentaire :







sr17 a écrit :



Ma définition de “Bonne pratique” : ne pas programmer en Javascript <img data-src=" />







Que faire donc si tu banni JS en 2017 du front de ton application web ?



Tu auras besoin d’un backend derrière, qui idéalement, parle en REST. Et effectivement, ça peut être du C# (ASP.NET), PHP, &nbsp;Java, Node, etc…

Ou alors, tu peux utiliser des trucs déjà prêts comme Firebase (je ne l’ai jamais utilisé), qui s’occupe de la partie Backend pour toi (authentification, api, anaytics, etc…)








stefann sasori a écrit :



Que faire donc si tu banni JS en 2017 du front de ton application web ?





Développer dans un autre langage et transpiler.

CoffeeScript, AtScript, TypeScript, JSX, GWT, j’en passe et des meilleures.

Apple, Google, Microsoft, Facebook, chacun y va de son langage pour contourner les limitations du JavaScript et le rendre un minimum maintenable.



Je doute que l’on en soit arrivé là si le langage était si irréprochable qu’on veut bien nous le faire croire.



<img data-src=" />

Ca fait sens, Angular pousse TypeScript notamment.

Au fait, ils transpilent tous en … JS.








stefann sasori a écrit :



Ouai tu peux :

https://universal.angular.io/overview/



Mais je conseille pas, Angular n’étant pas fait au depart pour le coté serveur.

Si tu veux absolument garder le même langage des deux coté tu peux faire

AngularJs coté client et NodeJs coté serveur. Tous 2 sont en JS et s’entendent à merveille.













PanDaReN a écrit :



Tu auras besoin d’un backend derrière, qui idéalement, parle en REST. Et effectivement, ça peut être du C# (ASP.NET), PHP,  Java, Node, etc…

Ou alors, tu peux utiliser des trucs déjà prêts comme Firebase (je ne l’ai jamais utilisé), qui s’occupe de la partie Backend pour toi (authentification, api, anaytics, etc…)









D’accord merci des reponses :)









stefann sasori a écrit :



Au fait, ils transpilent tous en … JS.





Bah oui, il faut bien qu’ils génèrent du code exécutable par la machine cible.



&nbsp;C’est pas parce que le compilo C++ génère in fine du x86 c’est une bonne pratique de coder directement en assembleur&nbsp;<img data-src=" />



Le problème récurrent, c’est que la critique de JS est dans 99% des cas faite par des personnes qui n’ont pas encore compris ce que pouvait être l’approche d’un langage prototypal, trop habitués à leurs petites habitudes du bon vieux C++/Java/C#/whatever avec leurs petites classes, interfaces, héritage, et leur modèle de données basé sur le carcan de son approche statique.



Et donc tu te retrouves encore et encore avec des gars qui t’expliquent qu’un tournevis caynul, parce que ça ne permet pas de planter des clous aussi bien qu’un marteau. Ils n’ont même pas compris qu’on parlait de vis, pas de clous.


Tips : il suffit de prendre la tige de tournevis à pleine main et de taper sur le clou avec le manche en bois.








Zed-K a écrit :



Le fait qu’il n’y a pas d’alternative à JS rendrait sa critique impossible ?





Comme pour toutes critiques, il est important de maitriser un minimum.

Or quand on lit plus haut que le Js c’est de la merde, c’est mal utilisé car ca devrait être limité à faire clignoter un bouton… tu te dis que certains ont la critique un peu trop facile <img data-src=" />









Zed-K a écrit :



Développer dans un autre langage et transpiler.

CoffeeScript, AtScript, TypeScript, JSX, GWT, j’en passe et des meilleures.

Apple, Google, Microsoft, Facebook, chacun y va de son langage pour contourner les limitations du JavaScript et le rendre un minimum maintenable.



Je doute que l’on en soit arrivé là si le langage était si irréprochable qu’on veut bien nous le faire croire.







L’univers Javascript, c’est un peu comme un catalogue de toutes les erreurs que l’on peut commettre en programmation : on empile de manière malpropre des couches sur des couches sur des couches pour oublier la misère initiale d’un langage mal foutu et sans ambition écrit sur un coin de table ainsi que les tares de ses API et l’inconsistance des standard.



Le plus amusant, c’est de voir certains se demander pourquoi des sites arrivent à ramer sur un PC de compétition et pourquoi on y trouve autant de bugs…









stefann sasori a écrit :



Que faire donc si tu banni JS en 2017 du front de ton application web ?







Tu pose une excellente question. <img data-src=" />



D’abord, la première étape, c’est de réaliser d’ou viens le problème.



Le problème, c’est qu’en imposant un langage pour le “front” web, les navigateurs ont tué toute compétition sur les langages pour la programmation… ce qui revient à imposer la médiocrité.



Javascript n’a pas été conçu à la base pour répondre à l’usage actuel.



Comment en sortir ?



D’abord il faut s’autoriser mentalement à sortir de la résignation que l’on voit chez ces milliers de programmeurs qui sont tellement relégués à un rôle d’exécutant du bas de la chaîne qu’ils ont perdu tout regard critique sur les outils qu’ils utilisent.



Pour la solution, une idée parmi d’autres serait de monter un collectif “on ne veut plus de ce langage” qui fasse du lobbying pour faire changer les choses.









brazomyna a écrit :



Le problème récurrent, c’est que la critique de JS est dans 99% des cas faite par des personnes qui n’ont pas encore compris ce que pouvait être l’approche d’un langage prototypal, trop habitués à leurs petites habitudes du bon vieux C++/Java/C#/whatever avec leurs petites classes, interfaces, héritage, et leur modèle de données basé sur le carcan de son approche statique.



Et donc tu te retrouves encore et encore avec des gars qui t’expliquent qu’un tournevis caynul, parce que ça ne permet pas de planter des clous aussi bien qu’un marteau. Ils n’ont même pas compris qu’on parlait de vis, pas de clous.







Malheureusement, il y a aussi de bonnes raisons pour lesquels l’approche statique s’est imposé au cours du temps. Et ce choix fut celui des programmeurs qui ont choisi les langages qu’ils préféraient par élimination darwinienne.



De l’autre côté, Javascript n’est pas le fruit d’un choix des programmeurs, mais celui d’une dictature qui s’est imposée à eux… sans possibilité de choix. <img data-src=" />



Rappelons qu’entre autres :



Les langages orientés prototype sont loin de permettre une exécution aussi rapide qu’un langage “statique”. Parce que plus un compilateur peut circonscrire les possibilités, plus il peut optimiser.



La soit disant souplesse apportée par beaucoup de langage qui font tripper les étudiants est dans la pratique quotidienne de la programmation plus un gadget inutile qui aboutit à de graves problèmes de rigueur, de structure et de lisibilité plutôt qu’une fonctionnalité utile.



On pourrait également ajouter que ceux qui savent s’y prendre avec les langages “statiques” ne se sont jamais plaint de soit disant “limitations”.







CryoGen a écrit :



Comme pour toutes critiques, il est important de maitriser un minimum.

Or quand on lit plus haut que le Js c’est de la merde, c’est mal utilisé car ca devrait être limité à faire clignoter un bouton… tu te dis que certains ont la critique un peu trop facile <img data-src=" />







Dans toutes calamité, il y aura toujours des gens compétents qui arriveront mieux que d’autre à limiter les dégâts, voir mieux pour les plus doués… et qui finiront par s’en gausser.



Mais la réalité du monde la programmation, c’est une majorité de gens formés à l’économie qui font des travaux “à l’arrache”…



Et les gens compétents en programmation ont justement mieux à faire de leur vie que de récupérer les conneries que le manque de rigueur permis par certain langages fait proliférer partout et au quotidien.



Bref, plus vite l’humanité aura refermé ce triste épisode, mieux on se portera.









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



Bah oui, il faut bien qu’ils génèrent du code exécutable par la machine cible.



 C’est pas parce que le compilo C++ génère in fine du x86 c’est une bonne pratique de coder directement en assembleur <img data-src=" />







On est d’accord !







sr17 a écrit :



Tu pose une excellente question. <img data-src=" />



D’abord, la première étape, c’est de réaliser d’ou viens le problème.



Le problème, c’est qu’en imposant un langage pour le “front” web, les navigateurs ont tué toute compétition sur les langages pour la programmation… ce qui revient à imposer la médiocrité.



Javascript n’a pas été conçu à la base pour répondre à l’usage actuel.







En fait on est tous conscient de cela, je te rejoins donc sur ce constat. Et j’ajoute que Javascript a pris trop de place du fait que les navigateurs n’ont pas été foutu de s’entendre pour proposer une meilleure alternative. En même temps on peut pas trop leur en vouloir, c’est pas leur rôle de définir des standards, mais au W3C. Le W3C s’est bien vautré à mon avis sur ce point.







sr17 a écrit :



Comment en sortir ?



D’abord il faut s’autoriser mentalement à sortir de la résignation que l’on voit chez ces milliers de programmeurs qui sont tellement relégués à un rôle d’exécutant du bas de la chaîne qu’ils ont perdu tout regard critique sur les outils qu’ils utilisent.



Pour la solution, une idée parmi d’autres serait de monter un collectif “on ne veut plus de ce langage” qui fasse du lobbying pour faire changer les choses.







C’est la ou le bat blesse. Les développeurs se sont adaptés à JavaScript et ils arrivent à respecter les cahiers des charges des clients avec. Le client veut que “le bouton clignote”, tu disposes juste de JavaScript pour le faire, tu te poses pas de question et tu le fais en JS.

Par contre, il y a @Zed-k qui parle dans les commentaires de mettre en avant les nouveaux langages qui transpilent en JS.

Moi perso cette solution me va actuellement car je crois que le futur (j’entend l’évolution) se chargera lui même de virer définitivement Javascript du web. Les besoins en perfs seront de plus en plus importants à l’avenir et le JS pourra pas suivre, les grands acteurs du web seront donc obligés de proposer autre chose. C’est juste une question de temps.

A ce propos, j’ai vu dans un commentaire sur macg, que Apple pousserait swift sur le web (backend et frontend). Je sais pas si c’est crédible mais c’est ainsi que je vois l’avenir du web.

Des solutions open source poussées par les grands acteurs du web qui uniformisent le développement front end et backend.









stefann sasori a écrit :



je crois que le futur (j’entend l’évolution) se chargera lui même de virer définitivement Javascript du web. Les besoins en perfs seront de plus en plus importants à l’avenir et le JS pourra pas suivre, les grands acteurs du web seront donc obligés de proposer autre chose. C’est juste une question de temps.





Pousse la réflexion un peu plus loin: les perfs sont-elles la seule métrique, le seul critère qui vaille la peine d’être évalué pour tous les aspects d’un projet ?



Et si par le plus grand des hasards tu te surprends à répondre par la négative, la question qui vient immédiatement ensuite, c’est de se demander en quoi le JS peut proposer d’autres avantages sur d’autres critères, qui le rendent encore aujourd’hui attractif pour une belle palanquée de devs (et pas juste quelques illuminés épars, mais une cohorte - dont des cadors reconnus - qui ne s’investit pas uniquement dans des technos ultra récentes genre nodeJS, juste pour le plaisir de perdre leur temps).







<img data-src=" />









brazomyna a écrit :



Pousse la réflexion un peu plus loin: les perfs sont-elles la seule métrique, le seul critère qui vaille la peine d’être évalué pour tous les aspects d’un projet ?







Non







brazomyna a écrit :



en quoi le JS peut proposer d’autres avantages sur d’autres critères, qui le rendent encore aujourd’hui attractif pour une belle palanquée de devs







Je l’utilise personnellement parce que d’abord qu’il soit interprété par tous les navigateurs ensuite qu’il remplisse sa mission: apporter de l’interactivité sur une page web sans obliger l’utilisateur à la reloader, et surtout c’est ce qu’on me demande!







brazomyna a écrit :



dont des cadors reconnus





Apple et Google ? Ils sont arrivés en retard, Javascript régnait déjà sans partage sur le web(Avec déjà des millions de sites intégrant du code Javascript), ils étaient obligés de le supporter pour espérer briller sur le web auprès de IE et Netscape/Firefox.



Ensuite google a essayé de proposer son alternative avec Dart mais c’était trop tard.



Javascript s’est imposé surtout par manque de concurrence au début.

Actuellement il est si populaire que ce qui le fera chuter sera probablement l’arrivée d’un concurrent open source utilisable coté client et coté serveur ou ses propres problèmes de perfs devenant rédhibitoires avec les nouveaux usages sur le web (3D, réalité virtuelle, réalité augmentée)









brazomyna a écrit :



Pousse la réflexion un peu plus loin: les perfs sont-elles la seule métrique, le seul critère qui vaille la peine d’être évalué pour tous les aspects d’un projet ?







Pour avoir vu des projets qui ont cramé une paire de millions (oui oui, en euros) en coup d’infra à cause d’une appli mal branlée qui a besoin de la puissance d’un datacenter complet pour être exploitée par 500 personnes…. J’ai envie de dire que c’est le cadet des soucis des décideurs.



Et les éditeurs sont pas mieux, vu qu’en général ils vont dire “bah rajoutez des serveurs” en balançant des précos à coup de mainframe à 12To de RAM et 50 CPU alors qu’une VM Linux suffit amplement.

Et après le client se demande pourquoi il paye 500k€ par an de coup d’infra pour une “simple appli”.









stefann sasori a écrit :



Je l’utilise personnellement parce que d’abord qu’il soit interprété par tous les navigateurs ensuite qu’il remplisse sa mission: apporter de l’interactivité sur une page web sans obliger l’utilisateur à la reloader, et surtout c’est ce qu’on me demande!





Apple et Google ? Ils sont arrivés en retard, Javascript régnait déjà sans partage sur le web(Avec déjà des millions de sites intégrant du code Javascript), ils étaient obligés de le supporter pour espérer briller sur le web auprès de IE et Netscape/Firefox.



Ensuite google a essayé de proposer son alternative avec Dart mais c’était trop tard.



Javascript s’est imposé surtout par manque de concurrence au début.

Actuellement il est si populaire que ce qui le fera chuter sera probablement l’arrivée d’un concurrent open source utilisable coté client et coté serveur ou ses propres problèmes de perfs devenant rédhibitoires avec les nouveaux usages sur le web (3D, réalité virtuelle, réalité augmentée)





Je parlais du foisonnement des dernières années, où js est sorti du cadre des navigateurs pour aller s’implanter dans des domaines où il était pourtant totalement absent, et donc où l’argument “il était déjà là, on n’a pas eu le choix” n’en est pas un. cf. nodejs.









SebGF a écrit :



Pour avoir vu des projets qui ont cramé une paire de millions (oui oui, en euros) en coup d’infra à cause d’une appli mal branlée qui a besoin de la puissance d’un datacenter complet pour être exploitée par 500 personnes…. J’ai envie de dire que c’est le cadet des soucis des décideurs.





Un contre exemple n’est pas un argument. D’autant plus quand rien ne vient étayer le fait que la ‘root cause’ principale de l’échec était une conséquence d’un souci de perf du langage lui-meme.

Je peux t’en citer une paire de projets qui ont pris l’eau. Et dans 99% des cas c’est avant tout la gestion du projet qui a été défaillante (choix archi foireux, specs pas claires, analyse absentte ou defaillante, …). Bref rien qui se rapporte aux qualités ou faiblesses d’un langage donné.









stefann sasori a écrit :



Javascript s’est imposé surtout par manque de concurrence au début.&nbsp;





Javascript (comme son nom l’indique) est arrivé quand tout le monde était persuadé que les applications lourdes seraient en Java sur le client. JavaScript était là grosso modo juste pour faire le lien entre les boutons de la page et l’applet, voire “pour faire clignoter un bouton” quand une applet Java était de l’overkill.



L’histoire a fait le reste quand Java s’est viandé et js s’est trouvé tout seul aux commandes.

&nbsp;



Angular, React, Vue ou autre, il faut d’abord connaitre le javascript. Avec les navigateurs récent, ça tourne très bien, même sur du code lourd.

Je développe sur GWT avec Smartgwt pour les pages complexe, c’est autrement évolué qu’Angular. Angular seul, c’est un peut comme GWT, on a les composants des base (boutons, input, form) un modèle vue/modèle/controleur et le lien avec le serveur en REST. Mais en dehors de ça, dès que l’on veut faire des tableaux, des vue arborescente, voir un “Rich Text Edit”, c’est pas prévu de base.

Avec Smartgwt, on peut faire ça :http://www.smartclient.com/smartgwt/showcase/#main C’est pas simplement un pauvre formulaire nom/prénom/adresse <img data-src=" />

Typescript, ça a été fait pour que les développeur java se mettent au développement front, la syntaxe est quasi pareil, avec des trucs sympa que j’aimerais retrouver en Java, comme la syntaxe du constructor.








spidermoon a écrit :



Angular seul, c’est un peut comme GWT, on a les composants des base (boutons, input, form) un modèle vue/modèle/controleur et le lien avec le serveur en REST. Mais en dehors de ça, dès que l’on veut faire des tableaux, des vue arborescente, voir un “Rich Text Edit”, c’est pas prévu de base.





Et c’est plutôt une bonne pratique d’avoir une approche modulaire, ave un ‘core’ relativement minimaliste et le reste qui est découplé dans des’plugins’ séparés. Ca permet de pouvoir contrôler finement ce qu’on inclut ou pas en fonction de son projet, sans s’encombrer de choses inutiles.



Et pour les fonctionnalités additionnelles avec angular, tu as des choses comme angular-ui ou encore angular-material









brazomyna a écrit :



Et c’est plutôt une bonne pratique d’avoir une approche modulaire, ave un ‘core’ relativement minimaliste et le reste qui est découplé dans des’plugins’ séparés. Ca permet de pouvoir contrôler finement ce qu’on inclut ou pas en fonction de son projet, sans s’encombrer de choses inutiles.



Et pour les fonctionnalités additionnelles avec angular, tu as des choses comme angular-ui ou encore angular-material







Mais ce n’est pas pour Angular2, pas encore :(



Le lien de material pour Angular 2 est:&nbsp;https://material.angular.io/



Il est encore en phase beta.








stefann sasori a écrit :





Moi perso cette solution me va actuellement car je crois que le futur (j’entend l’évolution) se chargera lui même de virer définitivement Javascript du web. Les besoins en perfs seront de plus en plus importants à l’avenir et le JS pourra pas suivre, les grands acteurs du web seront donc obligés de proposer autre chose. C’est juste une question de temps.







C’est en effet plus que probable.





A ce propos, j’ai vu dans un commentaire sur macg, que Apple pousserait swift sur le web (backend et frontend). Je sais pas si c’est crédible mais c’est ainsi que je vois l’avenir du web.

Des solutions open source poussées par les grands acteurs du web qui uniformisent le développement front end et backend.





Quel que soit les qualité d’un langage, il ne conviendra jamais à tous les usages. Et il ne faut pas répéter les erreurs du passé en laissant une multinationale acquérir trop de pouvoir sur les standard du web.



Pour le futur du “langage du web”, Je pense qu’il faudrait améliorer le concept de Web Assembly.









brazomyna a écrit :



Je parlais du foisonnement des dernières années, où js est sorti du cadre des navigateurs pour aller s’implanter dans des domaines où il était pourtant totalement absent, et donc où l’argument “il était déjà là, on n’a pas eu le choix” n’en est pas un. cf. nodejs.







Un commercial vous dira qu’a partir du moment ou il existe des millions de programmeurs qui ont été contraint d’apprendre Javascript, cela crée des opportunités commerciales.



Et ces opportunités commerciales engendrent des produits… qui contribuent eux même a répandre Javascript.



C’est un peu comme une infection zombie.



Je vous conseille de lire l’un des livre de Bill Gates “La route du futur” qui s’est interrogé sur les raisons pour lesquels le plus mauvais ordinateur du marché de l’époque(Le PC) est devenu le standard. Il explique comment ses défauts ont engendré des intérêts commerciaux qui ont fait sa promotion.









sr17 a écrit :



Un commercial vous dira qu’a partir du moment ou il existe des millions de programmeurs qui ont été contraint d’apprendre Javascript, cela crée des opportunités commerciales.





Tout comme un employé d’edf vous dira que promouvoir un langage super pas optimisé est une méga aubaine pour inciter à consommer encore plus d’énergie.



De toute façon, c’est clair que les millions d’adeptes de nodejs sont pour un tiers des commercieux complotistes, un autre tiers des moutons suiveurs incapables de prendre du recul et le dernier tiers des dev. tellement abrutis qu’ils sont pas capables de comprendre les quelques principes triviaux d’un langage fortement typé.



Et puis tant pis si on n’avance pas le moindre élément étayant cette thèse, l’important c’est pas tant de présenter la réalité, mais bien de se forger une posture, genre “regardez-moi les mecs, z’avez-vu comment que ch’suis fort, j’arrive même à avoir un regard critique de vieux routard pendant que les autres se débattent dans leur petites considérations étriquées et leur hype à 2 balles. Mais on me la fait pas à moi.”.



Et le jour où on nous démontrera par a+b que notre thèse ne tient pas 2 secondes, on pourra toujours s’en sortir en invoquant les complots et autres “faits alternatifs”. Après tout, Trump a bien démontré que ça fonctionnait bien de nos jours.



C’est pas un contre-exemple mais un témoignage d’expérience externe (je ne suis pas dev, je me contente d’intégrer) où peu importe le choix de la techno ou du progiciel, dans la majorité les cas les décideurs se tapent des perfs. (pareil pour la sécu, même si de ce côté c’est en train d’évoluer)



J’ai déjà réussi à faire un travail d’optim avec certains éditeurs (pourtant loin d’être des gros, à la limite de la start-up) qui ont apprécié avoir un grand compte pour leur apprendre “à grandir”. Mais d’autres s’en tapent complètement et leurs “architectes” iront te balancer que si ça rame t’ajoutes du serveur ou de l’espace disque parce que leur requête SQL mal branlée met 15 secondes pour renvoyer 20 lignes de résultats.








brazomyna a écrit :



Tout comme un employé d’edf vous dira que promouvoir un langage super pas optimisé est une méga aubaine pour inciter à consommer encore plus d’énergie.



De toute façon, c’est clair que les millions d’adeptes de nodejs sont pour un tiers des commercieux complotistes, un autre tiers des moutons suiveurs incapables de prendre du recul et le dernier tiers des dev. tellement abrutis qu’ils sont pas capables de comprendre les quelques principes triviaux d’un langage fortement typé.



Et puis tant pis si on n’avance pas le moindre élément étayant cette thèse, l’important c’est pas tant de présenter la réalité, mais bien de se forger une posture, genre “regardez-moi les mecs, z’avez-vu comment que ch’suis fort, j’arrive même à avoir un regard critique de vieux routard pendant que les autres se débattent dans leur petites considérations étriquées et leur hype à 2 balles. Mais on me la fait pas à moi.”.



Et le jour où on nous démontrera par a+b que notre thèse ne tient pas 2 secondes, on pourra toujours s’en sortir en invoquant les complots et autres “faits alternatifs”. Après tout, Trump a bien démontré que ça fonctionnait bien de nos jours.







L’économie est le moteur de nombreux comportements humains. Ce n’est pas un complot, simplement de la sociologie.



La proposition de NodeJs est commercialement efficace et bien ciblée : vous savez programmer du front Web en Javascript, vous pourrez faire la même chose côté serveur avec le même langage.



Quand au fait de penser qu’une majorité de programmeurs web auraient une bonne compréhension des mécanismes internes des langages, je pense qu’il ne faut pas rêver.









brazomyna a écrit :



“regardez-moi les mecs, z’avez-vu comment que ch’suis fort, j’arrive même à avoir un regard critique de vieux routard pendant que les autres se débattent dans leur petites considérations étriquées et leur hype à 2 balles. Mais on me la fait pas à moi.”.







En même temps, on ne va pas non plus s’excuser d’avoir de l’expérience, ni d’avoir consacré un certain temps à étudier les mécanismes de bas niveau des langages. <img data-src=" />




Non, mais je ne dis pas le contraire: effectivement, l’optimisation à tout crin est rarement une priorité, mais cet état de fait n’est pas guidé par une ignorance, ou un manque de jugeotte. Il est avant tout guidé par une notion de compromis rationnel: entre un dev. facturé 500€ et 1000€/j vs. un serveur plus puissant qui coûte au pire quelques milliers d’euros supplémentaires, dans 90% des cas, consommer de l’homme.jour pour optimiser à fond est contre productif comparé à l’option “upgrade du serveur”.





Alors oui il y a les 10% des cas extrêmes dans lequel tu pourras piocher quelques contre exemples ; du cas du dev. qui code avec ses pieds, à celui du mauvais choix pour une application extrêmement exigeante en termes de perfs.



Ca n’en fera pas une généralité pour autant. Encore moins si tu considère les 1% des projets parmi ces 10% pour lesquels l’optimisation porte sur la nature du langage, sur lequel certains font une fixette.









sr17 a écrit :



L’économie est le moteur de nombreux comportements humains. Ce n’est pas un complot, simplement de la sociologie.





Non, c’est une théorie fumeuse qui a autant de valeur que la mienne à propos de l’agent EDF.





En même temps, on ne va pas non plus s’excuser d’avoir de l’expérience, ni d’avoir consacré un certain temps à étudier les mécanismes de bas niveau des langages.



C’est dommage de voir autant d’expérience gâchée par une incapacité latente à remettre en question ses petites certitudes et son ego.



Tu as dû confondre vieillesse et sagesse, manifestement.









brazomyna a écrit :



Non, c’est une théorie fumeuse qui a autant de valeur que la mienne à propos de l’agent EDF.





C’est dommage de voir autant d’expérience gâchée par une incapacité latente à remettre en question ses petites certitudes et son ego.



Tu as dû confondre vieillesse et sagesse, manifestement.







L’ennui, c’est que les insultes et les attaques personnelles ne sont pas pour autant des arguments.



On a le droit de ne pas être d’accord. Mais il faut savoir garder un ton respectueux.









brazomyna a écrit :



Non, mais je ne dis pas le contraire: effectivement, l’optimisation à tout crin est rarement une priorité, mais cet état de fait n’est pas guidé par une ignorance, ou un manque de jugeotte. Il est avant tout guidé par une notion de compromis rationnel: entre un dev. facturé 500€ et 1000€/j vs. un serveur plus puissant qui coûte au pire quelques milliers d’euros supplémentaires, dans 90% des cas, consommer de l’homme.jour pour optimiser à fond est contre productif comparé à l’option “upgrade du serveur”.



Alors oui il y a les 10% des cas extrêmes dans lequel tu pourras piocher quelques contre exemples ; du cas du dev. qui code avec ses pieds, à celui du mauvais choix pour une application extrêmement exigeante en termes de perfs.



Ca n’en fera pas une généralité pour autant. Encore moins si tu considère les 1% des projets parmi ces 10% pour lesquels l’optimisation porte sur la nature du langage, sur lequel certains font une fixette.







Sauf que quand c’est que quand c’est du côté “front” que ça rame, il ne suffit pas de rajouter des serveurs.



Et une mauvaise expérience utilisateur se traduit par une perte de fréquentation…



Quand on a une idée de l’overhead qui découle des caractéristiques dynamiques d’un langage, on comprends pourquoi certains rêvent de mieux que Javascript.



Et le fait d’empiler les framework sur un langage lent ne fait qu’amplifier le problème…









brazomyna a écrit :





Tu as dû confondre vieillesse et sagesse, manifestement.







Vous savez, les langages dynamiques, ce n’est vraiment pas nouveau.



Ils nous ont aussi fasciné à une époque…



Je pense que j’ai du tomber sur 100% de projets de merde <img data-src=" />


On a eu la meme conversation (dyanmique vs compilé) il y a quelque années…



Je vois que tu ne changes n’évolue pas.








SebGF a écrit :



J’ai déjà réussi à faire un travail d’optim avec certains éditeurs (pourtant loin d’être des gros, à la limite de la start-up) qui ont apprécié avoir un grand compte pour leur apprendre “à grandir”. Mais d’autres s’en tapent complètement et leurs “architectes” iront te balancer que si ça rame t’ajoutes du serveur ou de l’espace disque parce que leur requête SQL mal branlée met 15 secondes pour renvoyer 20 lignes de résultats.





Rajouter des serveurs, ça a toujours été la seule réponse des éditeurs (du plus petit au plus gros) aux problèmes de perf que j’ai rencontré. Jamais je n’ai vu un éditeur se remettre en question sur la qualité de son code même quand on lui fait la démonstration qu’on peut passer de 30 minutes de traitement à 2 minutes rien qu’en optimisant quelques requêtes.&nbsp; <img data-src=" />









sr17 a écrit :



Sauf que quand c’est que quand c’est du côté “front” que ça rame, il ne suffit pas de rajouter des serveurs.



Et une mauvaise expérience utilisateur se traduit par une perte de fréquentation…



Quand on a une idée de l’overhead qui découle des caractéristiques dynamiques d’un langage, on comprends pourquoi certains rêvent de mieux que Javascript.



Et le fait d’empiler les framework sur un langage lent ne fait qu’amplifier le problème…







JS n’est pas plus un “langage lent” que python ou ruby.&nbsp; Au contraire même, les moteurs JS ont fait d’importants progrès. Mais bien entendu, certaines constructions rendront difficile une compilation native efficace.&nbsp;



L’overhead n’est vraiment pas l’argument principal qui font que certains revent mieux que JS.



Tu évoques les moteurs JS d’il y a 10 ans ?



&nbsp;









lossendae a écrit :



Je vois que tu ne changes n’évolue pas.





Evoluer demande un minimum de remise en question, d’ouverture d’esprit et de porosité aux arguments de tiers.

Difficile d’évoluer quand on part du principe qu’on a la science infuse, qu’on est le seul à avoir 30 ans d’xp en IT, et que toute opinion différente de la sienne est forcément le fruit d’un manque d’expérience ou de capacité de réflexion <img data-src=" />



Le plus rigolo est encore de le voir venir et revenir sans cesse sur les news à propos de ces technos qu’il voudrait conchier, pour déverser sa petit litanie d’arguments d’autorité. On dirait une boucle infinie ; autant dire qu’il est pas optimisé pour un sou <img data-src=" />









SebGF a écrit :



Je pense que j’ai du tomber sur 100% de projets de merde <img data-src=" />





Je pense que tu as surtout une vision ‘developper centric’ où tu vois avant tout le projet par son approche tech(n/olog)ique.



Effectivement, la plupart des projets ne sont pas des oeuvres d’art en terme technique ; mais ce n’est pas le but premier d’un projet. Son but premier est de faire le job qu’on lui demande, avec les contraintes qu’on a défini au départ, le tout pour un coût minimum.

Et si l’optimum est de lâcher du leste concernant la “beauté technique” pour faire plus d’économies sur les coûts de développement, le tout en continuant de respecter les contraintes définies au départ, c’est cette option qui est privilégiée.



C’est souvent le plus gros point d’achoppement entre la vision du développeur et celle du project manager.





  • Le développeur a tendance à sous-évaluer les surcoûts de développement induits par l’augmentation de la qualité du code, comparé au gain réel que ça apporte fonctionnellement au projet.



  • Le PM a tendance à vouloir minimiser les coûts direct, et a parfois tendance à sous-évaluer les impacts des choix techniques sur les coûts ‘cachés’, notamment à long terme. Et il le fait avant tout parce que les coûts cachés sur le long terme sont mal compris et évalués par les clients, et donc leur importance au moment de signer un nouveau projet, n’est pas assez prise en compte (dit autrement: le client a du mal à accepter de payer plus maintenant pour des hypothétiques promesses d’économies sur le long terme).



    Bref, comme souvent, la vérité, c’est souvent un peu la voie du milieu: au développeur de comprendre que le but ultime d’un projet n’est pas de faire le plus beau code du monde ; au PM de prendre le temps d’expliquer au client que payer un peu plus maintenant peut lui faire gagner sur le long terme ; au client de comprendre et d’intégrer cette notion et d’en faire sienne.









lossendae a écrit :



On a eu la meme conversation (dyanmique vs compilé) il y a quelque années…



Je vois que tu ne changes n’évolue pas.







Evoluer ?



Je vais sans doute vous étonner en rappelant que ce débat doit avoir à peu près 50 ans d’age. Et ce n’est pas une plaisanterie.



C’est un bon vieux problème bien poussiéreux.



Et j’ai beau suivre les progrès techniques des langages dynamiques en rêvant à des miracles, force est de constater qu’on bute toujours sur les mêmes problèmes pour les rendre efficace. Ce qui est finalement très logique, les loi de la physique n’ayant pas changé entre temps.



En parlant de progrès force est de constater que le développement de WebAssembly démontre que mon analyse sur le “fabuleux” javascript semble partagé par un certain nombre de spécialistes.



Pour conclure sur l’évolution, rien ne prouve que Javascript sera encore un langage de prédilection dans quelques années.









brazomyna a écrit :



promouvoir un langage super pas optimisé





Pour information, parmi tous langages interprétés (Python, Ruby, Perl, PHP…), JavaScript est actuellement le plus rapide, exemples :

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2…

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2…

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2…



Des gens “codent” encore avec Jquery? : x Faut évoluer hein…&nbsp;








Nithril a écrit :



JS n’est pas plus un “langage lent” que python ou ruby.







Tout à fait. Mais vous comparez un langage lent à d’autre langages lents.



Même si les profs en raffolent, ce sont tous des petit langages de script avec lesquels on écrit rarement plus que des petits projets.



Parlons plutôt des langages dont on se sert pour créer les logiciels qui sont les cadors du marché.





Au contraire même, les moteurs JS ont fait d’importants progrès.





Certes, mais malgré la débauche d’optimisations déployées on reste loin d’un vrai langage statiquement compilé.



Et le problème de pousser ce genre d’optimisation, c’est qu’on peut y récolter aussi quelques effets de bord.





Mais bien entendu, certaines constructions rendront difficile une compilation native efficace.





C’est bien cela le problème.



Pour l’instant, personne n’a trouvé la solution pour obtenir quelque chose de performant à partir des langages dynamiques.



Même si en informatique il ne faut jamais dire jamais, force est de constater que pour l’instant les langages dynamiques sont toujours une impasse en terme de performances. Pour ma part, je ne vois pas comment on pourrait solutionner le problème.



Et je pense que si quelqu’un avait pondu une thèse qui apporte des solutions, on le saurait déjà.





L’overhead n’est vraiment pas l’argument principal qui font que certains revent mieux que JS.





Quand ils verront ce que certains feront de WebAssembly, ça devrait réveiller leur capacité à rêver…



Javascript, ça fait déjà un moment qu’on touche les limites quand on veut faire des choses ambitieuses.





Tu évoques les moteurs JS d’il y a 10 ans ?





Non.



On ne peut qu’admirer le talent et le niveau technique des auteurs des derniers moteurs Javascript



Le problème, c’est que même le meilleur talent du monde n’arrive pas toujours à faire des miracles devant des problèmes qui sont peut être insolubles.



Ce qui est triste, c’est de voir autant de programmeurs croire que tout ces problèmes de performances seront réglés un beau matin par l’apparition d’un compilateur magique.



Le grand compilateur magique ne viendra pas.



je prends ta réponse comme un troll, car dire que ruby ou python ce sont des petits langages dont les profs raffolent c’est fort :)





Note en passant, WebAssembly n’est qu’un langage de bas niveau qui n’a pas vocation à être utilisé par le developpeur. Cela passera par du C/C++ ou autre compilé en WASM








tanguy_k a écrit :



Pour information, parmi tous langages interprétés (Python, Ruby, Perl, PHP…), JavaScript est actuellement le plus rapide, exemples :

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=pyt…

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=yar…

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=php







Ce sont tous des langages qui sont réputés pour être lents, voir très lents.



En comparaison, Javascript dispose aujourd’hui de moteurs beaucoup plus optimisés.



Hélas, cela ne lui permet pas pour autant de rivaliser avec des langages compilés rapides.












Nithril a écrit :



je prends ta réponse comme un troll, car dire que ruby ou python ce sont des petits langages dont les profs raffolent c’est fort :)







Tu as bien deviné, je l’ai présenté de manière volontairement trollesque.



Mais le fond n’en reste pas moins vrai. On n’écrit pas un moteur de jeu vidéo AAA, une grande base de données ou le coeur d’un Os en Python ou Ruby.



Je comparerait un langage comme Python au Basic qui fut longtemps utilisé pour l’apprentissage et de petites applications. Mais pas pour des gros programmes de premier plan qui demandent des performances.





Note en passant, WebAssembly n’est qu’un langage de bas niveau qui n’a pas vocation à être utilisé par le developpeur. Cela passera par du C/C++ ou autre compilé en WASM

[



Tout à fait. Et c’est d’ailleurs bien ce qu’on recherche. <img data-src=" />



D’ailleurs, l’intérêt c’est qu’on ne sera pas limité à C/C++. C’est la porte ouverte a la possibilité d’utiliser le langage de son choix.



On peut d’ailleurs prédire qu’avec le temps, le bound checking logiciel sera certainement remplacé par une implémentation matérielle. On pourra alors atteindre la pleine vitesse du code natif le plus performant…









sr17 a écrit :



Hélas, cela ne lui permet pas pour autant de rivaliser avec des langages compilés rapides.





Difficile de reprocher à JS de ne pas être aussi rapide que les langages compilés, il ne joue pas dans la meme categorie.



Oranges vs pommes.

Pour l’instant on a pas encore réussi à créer une “orangomme” qui aurait donc les avantages à la fois des oranges (langages interprétés) et des pommes (langages compilés).



Bah je ne suis pas développeur comme j’ai dit, donc je n’ai pas la maîtrise du langage en lui-même mais plutôt de ce qui gravite autour (vu que je suis intégrateur), et ça me permet de pointer assez vite les problèmes généralement. J’ai plutôt tendance à être très pragmatique justement et absolument pas politique, le client entend rarement ce qu’il a envie d’entendre avec moi…

On me reproche souvent de trop chercher à sécuriser une MEP par exemple … Mais derrière ils sont bien contents quand un démarrage applicatif se fait avec un taux d’incident proche du zéro. Là où d’autres sont encore à ramasser leurs dents après 6 mois.



Y’a aussi un détail dans les coûts qu’on oublie, c’est le chiffrage “psychologique”.



Style l’éditeur va te dire que ça fait 5j de dev pour un truc qui prendra 5 minutes, juste parce qu’il n’a pas envie de le faire ou parce que ça l’emmerde. Ou alors de faire payer une fonctionnalité qui est censée faire partie du standard vendu, ce genre de chose en général ça passe pas. <img data-src=" />



Donc je pense que la mauvaise volonté peut aussi méchamment peser sur la balance.



Mais ça doit venir de mon taux de projets foireux aussi. <img data-src=" />


Les besoins ne sont pas les mêmes pour tout les types d’applications.

Wikipedia, Facebook sont fait en php.

Github et Gitlab tourne avec rails.

Sentry utilise Python.



Si les langages plus bas niveau étaient plus pratique (et plus facile d’acces pour les developeur lambda), il domineraient outrageusement le marché. Ce n’est pas le cas.



Le dévelopement n’est pas une profession à part, il y a plusieurs niveau de complexité et plusieurs solution pour regler différents problèmes.



Mon DSI qui aujourd’hui ne fait plus de php, se concentrant sur du langage bas niveau ultra optimisé pour de la domotique, crache des qu’il peut sur “cette horreur qu’est php” et la supériorité des langages qu’il utilisent.

Même si je ne doute pas de ses capacités dans ses travaux actuels, et que dans l’absolu il n’a pas tout à fait tort, le code php/js qu’il a codé il n’y a pas 5 ans est un tres bon exemple de ce qu’il ne faut surtout pas faire.



Du coup je me méfie encore plus des cadors qui pensent tout savoir et qui au final, se montre incompétents une fois sorti de leurs zone de confort.



&nbsp;








tanguy_k a écrit :



Difficile de reprocher à JS de ne pas être aussi rapide que les langages compilés, il ne joue pas dans la meme categorie.



Oranges vs pommes.

Pour l’instant on a pas encore réussi à créer une “orangomme” qui aurait donc les avantages à la fois des oranges (langages interprétés) et des pommes (langages compilés).







Tout à fait.



Les deux catégories de langage ont d’ailleurs toujours coexisté avec chacun leurs usages de prédilection.



D’ailleurs, Javascript convenait très bien pour l’usage que ses concepteurs imaginaient au départ.



Le problème, c’est qu’aujourd’hui les besoins ont complètement changés. Aujourd’hui, on veut écrire de vraies applications qui tournent dans le navigateur. On veut utiliser des frameworks qui ont des fonctionnalités évoluées. Et le petit langage qui allait bien au départ montre ses limites…












sr17 a écrit :



Et le petit langage qui allait bien au départ montre ses limites…





Quelles limites ?



Oui JS a été conçu en 10j, oui il y a eu des mauvaises décisions de prise : tout le monde le sait. On peut faire bcp mieux comme langage.

Il n’empêche que l’on fait des applications complexes avec. L’écosystème est florissant, plus que n’importe quel autre langage (http://www.modulecounts.com/ ).

Personnellement je préfère même coder en JavaScript/TypeScript que C# ou Ruby.









lossendae a écrit :



Les besoins ne sont pas les mêmes pour tout les types d’applications.

Wikipedia, Facebook sont fait en php.

Github et Gitlab tourne avec rails.

Sentry utilise Python.







En cherchant bien, on trouvera toujours des exemples utilisant n’importe quel langage… même en Cobol, Basic ou Lisp.



Mais sur les serveurs, le problème n’est pas comparable.



D’abord, on peut toujours multiplier les serveurs pour compenser un langage lent (contrairement au “front”, on l’on ne peut pas multiplier les CPU de la machine du client). Et le serveur web, ça se parallélise bien.



Même si c’est un énorme gaspillage de ressources et d’argent, il est évident que les sociétés du web ont privilégié la rapidité de développement en se disant qu’elles auront toujours le temps d’optimiser si besoin après.



D’ailleurs, c’est justement ce qu’on constate quand les projets deviennent mature et comptent des centaines de milliers de serveur… et que ça commence à chiffrer sévère : A ce stade, ça commence à se gratter l’occiput en se demandant comment on peut améliorer le débat sans tout jeter aux orties, ce qui aboutit à des choses comme cela :



https://fr.wikipedia.org/wiki/HipHop_for_PHP



On peut facilement prédire que tôt ou tard, avec les normes écologique et les taxes carbone, les langages lents finiront par disparaître. Et la meilleure raison, c’est que finalement, ça n’est pas très difficile de créer de meilleurs outils.





Si les langages plus bas niveau étaient plus pratique (et plus facile d’acces pour les developeur lambda), il domineraient outrageusement le marché. Ce n’est pas le cas.





Tout à fait.



Il faut bien reconnaître qu’il manque cruellement à ces langages un environnement facile d’utilisation pour des programmeurs néophytes.



Mais au moins, c’est techniquement faisable contrairement au fait d’essayer de rendre performant les langages dynamiques…





Le dévelopement n’est pas une profession à part, il y a plusieurs niveau de complexité et plusieurs solution pour regler différents problèmes.



Mon DSI qui aujourd’hui ne fait plus de php, se concentrant sur du langage bas niveau ultra optimisé pour de la domotique, crache des qu’il peut sur “cette horreur qu’est php” et la supériorité des langages qu’il utilisent.

Même si je ne doute pas de ses capacités dans ses travaux actuels, et que dans l’absolu il n’a pas tout à fait tort, le code php/js qu’il a codé il n’y a pas 5 ans est un tres bon exemple de ce qu’il ne faut surtout pas faire.





Pour avoir programmé en PHP j’ai aussi trouvé que malgré ses défauts, ce langage apportait certaines choses intéressantes en terme de facilité. Donc je n’aurais pas une vision aussi radicale que lui.



Mais au final, sur le constat, je le rejoint. PHP ne se contente pas d’être lent, il présente aussi de redoutables travers.



Par exemple, si l’on veux écrire le code le plus performant en PHP, cela nuit assez rapidement à d’autres aspects du projet.



Un langage comme C/C++ est indéniablement plus efficace quand il s’agit de concilier optimisation, bonne structure et bonne architecture.





Du coup je me méfie encore plus des cadors qui pensent tout savoir et qui au final, se montre incompétents une fois sorti de leurs zone de confort.





En même temps, en informatique, il y a toujours eu l’outil à la mode du moment… et celui qui sera à la mode dans quelques années.



Les vieux briscards voient le chemin idéal à long terme. Et l’évolution leur donne le plus souvent raison.



Les jeunes programmeur voient concrètement les outils avec lesquels ils peuvent travailler aujourd’hui et ils n’ont pas tort. Mais ils n’ont pas toujours conscience qu’ils en verront passer d’autres…



Les deux ont raison, c’est juste qu’ils ne parlent pas toujours la même langue.










tanguy_k a écrit :



Quelles limites ?







La vitesse d’exécution par exemple. Quand il faut faire des choses complexes et empiler des couches, c’est un sacré facteur limitant.



Et il faut comprendre que ce qu’on fait sur le web aujourd’hui est une chose, mais il faut imaginer aussi qu’il y aura des évolutions et que demain, on voudra en faire plus…



Faire plus nécessitera des langages plus efficaces. Des évolutions comme WebAssembly ne sont vraiment pas la par hasard…





Oui JS a été conçu en 10j, oui il y a eu des mauvaises décisions de prise : tout le monde le sait. On peut faire bcp mieux comme langage.

Il n’empêche que l’on fait des applications complexes avec. L’écosystème est florissant, plus que n’importe quel autre langage (http://www.modulecounts.com/ ).





L’écosystème est indéniablement florissant.



Mais il ne faut jamais vous fier à cela en informatique : on a connu des environnement incroyablement utilisées qui sont passés de mode presque aussi vite qu’ils étaient arrivés.



Je sais que tant qu’on ne l’a pas vécu, ça parait difficile à croire.



Le problème avec Javascript et les erreurs de choix dans sa conception, c’est qu’il y a des choses que l’on peut toujours améliorer et des choses que l’on ne pourra malheureusement jamais améliorer. L’aspect dynamique de ce langage est l’un d’entre eux. Et cela limite la complexité de ce qu’on peut faire avec à cause du temps d’exécution.





Personnellement je préfère même coder en JavaScript/TypeScript que C# ou Ruby.





Pour ma part, je peux apprécier de coder dans nombreux langages, même des langages qui sont souvent critiqués.



Mais il faut savoir qu’avec le temps, on comprends aussi que certains langages qui paraissent moins “sympa” et plus austères au premier abord le sont aussi pour la bonne cause : cela vous simplifiera la vie par la suite.









sr17 a écrit :



La vitesse d’exécution par exemple. Quand il faut faire des choses complexes et empiler des couches, c’est un sacré facteur limitant.





D’ou WebAssembly. Mais ca ne remplacera pas JS. Pour faire des applis web (90%) on continuera d’utiliser JS comme aujourd’hui (a mon avis). Et encore une fois, les perfs de JS sont loin d’être ridicules.



&nbsp;





sr17 a écrit :



on a connu des environnement incroyablement utilisées qui sont passés de mode presque aussi vite qu’ils étaient arrivés.



Je sais que tant qu’on ne l’a pas vécu, ça parait difficile à croire.





Tu penses à quoi ? Delphi, VB6 ?&nbsp;



Ca me fait plaisir de voir que je suis pas le seul à penser que JS “c’est de la merde ™” et que c’est pas en rajoutant une vague couche de typage sur un langage qui n’a pas été pensé pour que ça va être la panacée. Mais soyons honnête, la faute ne revient pas à JS mais bien à l’utilisation d’HTML, langage statique de mise en forme de document, pour faire des UI complexes et dynamiques. Je pense également que les performances techniques du langage sont de la jolie poudre au yeux quand on voit que les soucis de performance des vrais gros projets ne sont pas techniques mais proviennent plus du design de l’application/des classes/des algos. Putain je pleure chaque jour quand je vois les milliers de lignes de code en java, les dizaines de conversions dans tout les sens, puis en javascript pour lire et afficher des données.



Sinon, y en a qui se sont essayé à la génération de page web directement côté serveur ? Je teste Spark + j2html (pas de template soit disant logicless mais avec quand même de la logique dedans <img data-src=" />). C’est simple à mettre en place et assez rapide pour faire des choses basiques. Mais je suis sur le truc depuis quelques mois et j’ai du mal à trouver le bon design dès que je veux passer aux choses sérieuses. J’ai cette sale impression que l’encapsulation des données est difficilement compatible avec l’idée même d’affichage des données, parce que soyons honnête dès qu’on donne accès aux champs, on se retrouve avec du code de merde dans tout les sens. J’essaye vraiment de faire un design réfléchit, pensé pour être facilement testable (TDD, minimum 95% de couverture, rendu html inclus), essayer d’encapsuler à mort pour éviter la duplication même la plus basique, typer le moindre champ pour éviter d’avoir des String un peu partout, mais je galère <img data-src=" />.








tanguy_k a écrit :



D’ou WebAssembly. Mais ca ne remplacera pas JS.







Rien ne permet d’affirmer cela aujourd’hui.



Qui prédisait au départ ce que l’on fait de Javascript maintenant ?





Pour faire des applis web (90%) on continuera d’utiliser JS comme aujourd’hui (a mon avis).





Pourtant, on voit tellement de choses qui rament sur le web. L’intérêt à changer de technologie est bien réel.



Et cela sans compter tout ce qu’on ne fait pas encore parce que Javascript n’est pas assez rapide.





Et encore une fois, les perfs de JS sont loin d’être ridicules.





Personne ne dit qu’elles sont ridicules.



Mais les faits sont la, Javascript est très loin des langages rapides.



(on trouve facilement des benchmarks un peu partout sur le web.)



Il faut réaliser qu’aujourd’hui des gens changent d’ordinateur pour quelques pourcent de gain alors que changer de langage de programmation apporte un gain incommensurablement plus important.



Il fut une époque ou les performances des processeurs augmentaient régulièrement. Alors on se moquait d’utiliser un langage lent. Si ça ramait, on attendait quelques mois les nouveaux processeurs.



Aujourd’hui, d’une génération à l’autre de processeur, on ne gagne presque plus rien.



Les langages restent un des rare “réservoir” de gain potentiel.





Tu penses à quoi ? Delphi, VB6 ?





On pourrait ajouter Access, DBase, FoxPro, Turbo Pascal ainsi qu’une pléthore de langages plus anciens comme Cobol, Fortran.



Même des langages comme Basic, tu aurait dit à une époque qu’il disparaîtrait, personne ne t’aura cru.




Atom qui utilise du js est un editeur de texte “riche” tout a fait honorable.








sr17 a écrit :



Pourtant, on voit tellement de choses qui rament sur le web&nbsp;





Par forcement a cause de JS mais plutot le DOM, CSS et puis surtout le réseau tout simplement.

Bon bref, on a des points de vues différents.







sr17 a écrit :



Même des langages comme Basic, tu aurait dit à une époque qu’il disparaîtrait, personne ne t’aura cru.





Ah on peut ajouter Perl à la liste aussi :)

Il y a aussi des technos qui restent très populaires malgré leur âge : SQL, C, C++, Python par exemple

Je pense que JS est la pour durer (et évoluera). Evidemment y’a bien un moment ou ca va être remplacé mais a mon avis tu peux attendre au moins 10 ans.









tanguy_k a écrit :



Par forcement a cause de JS mais plutot le DOM, CSS et puis surtout le réseau tout simplement.

Bon bref, on a des points de vues différents.







On peut dire que cela participe aussi, l’ensemble n’est clairement pas pensé pour les performances.



Mais l’ajout d’abstractions pour compenser les imperfections de Javascript et de ses API participent à accroître significativement les problèmes de mauvais usage du DOM. Quand un programmeur ne sait plus ce qui se passe réellement quand il invoque une instruction, c’est le début des problèmes.



Pour ma part, je mettrait les WebDesigner débutants à travailler sur un netbook pendant 1 an et je remplacerait leur smartphone dernier cri par un modèle d’il y a 5 ans, histoire de leur apprendre à ne pas coder n’importe comment.





Il y a aussi des technos qui restent très populaires malgré leur âge : SQL, C, C++,





Paradoxalement, dans cet univers de nouveauté permanente, quelques technologies ont traversé les âges depuis la nuit des temps. Mais le C n’est pas non plus resté sans évoluer pendant toutes ces années.



Ceux qui trouvent ce langage difficile n’imaginent pas à quel point avec les compilateurs rudimentaires d’une époque ce langage pouvait être punitif…



Pourtant, il y a eu de nombreux prétendants qui ont essayé de le remplacer. Mais aucun n’y est jamais parvenu parce qu’aucun n’a vraiment réussi à proposer un aussi bon compromis entre la bas niveau et le haut niveau, entre la souplesse et la rigueur.





Python par exemple





Python n’est pas si vieux. Son succès est quand même relativement récent.





Je pense que JS est la pour durer (et évoluera). Evidemment y’a bien un moment ou ca va être remplacé mais a mon avis tu peux attendre au moins 10 ans.





Le chemin sera certainement long, mais 10 ans, ça passe beaucoup plus vite qu’on ne le pense.



Pour le reste, il est tout à fait possible que Javascript survive à cela, ne fut ce que grâce à la nostalgie de ceux qui l’auront utilisé. Mais certainement recadré à des usages de script plus simples.



Mais pour ma part, je ne suis pas pour la suppression de la possibilité d’utiliser Javascript. Même si je pense qu’il y a un langage pour chaque chose, mais j’abhorre la vision d’une informatique avec un langage unique que les multinationales veulent nous imposer.



Quoi qu’on en dise, il n’existera jamais de langage parfait et je suis pour le libre choix du langage en fonction de la volonté et de l’usage de chaque programmeur.









lossendae a écrit :



Atom qui utilise du js est un editeur de texte “riche” tout a fait honorable.







Est ce qu’on doit pour autant gaspiller des cycles machine(et donc de l’énergie) sous prétexte que nos ordinateurs ont largement plus de puissance que nécessaire pour manipuler du texte ?



Est ce que tout le monde est réellement satisfait de la rapidité de cet éditeur ? Une petite recherche avec les mots “atom” et “slow” me laisse une réponse qui parait plutôt mitigée.



Enfin, j’ai assez pesté contre la lenteur d’Eclipse (écrit en Java) pour penser qu’il faut que les programmeurs d’aujourd’hui réapprennent à considérer la vitesse comme un point important de l’expérience utilisateur.



Chaque langage devrait se limiter à ce qu’il sait faire. Quand je vois des applications FullJS, ça me donne des boutons. L’habillage prend trop le pas sur le vrai fonctionnel.&nbsp;



Personnellement ça fait 10 ans que je bosse dans le Web et surtout en PHP. Si il n’est pas parfait, il a très bien évolué ces dernières années, la version 7 est vraiment top. Et même si il a quelques faiblesses comme certains trans-typages un peu trop implicites, je préfère ça à la lourdeur du java par exemple (que je pratique aussi de temps à autre).



Par contre, ça ne me viendrait pas à l’idée de faire un client lourd en PHP.


Oui Atom est lent, des que tu ouvre un gros fichier avec, c’est la misere. Pour faire du web, ça “peut” être suffisant.



Eclipse est une horreur, les IDE de Jetbrains ou a minima netbeans sont largement plus agréabke à utiliser mais ils réclament tous des machines relativement puissantes avec de préférence de la RAM en rab.



Apres, pour les vrais cadors, il y a vim. Ce n’est pas un troll; Un de nos consultant dba code exclusivement sous vim, et je ne peux que le regarder faire avec des yeux emerveillées. Mais arriver à ce niveau de maitrise demande dedication et une certaine dose de talent, donc “pour moi” les IDE [lourd mais] clé en mains sont plus efficace à mon niveau.



C’est cool, il faut de tout pour faire un monde. Des gens plus forts, des gens moins forts…