Discussion :

[SylvainPV]

Ah non, j'ai choisi précisément le JS comme langage principal pour éviter ce genre de désagrément Oui Paypal a basculé sur Node pour ses applis web. Il y a aussi Walmart qui a géré le dernier Black Friday et ses millions d'acheteurs concurrents avec du Node. Comme baptême du feu c'est pas mal !

J'oubliais, on a des nouvelles des dernières chamailleries entre Joyent et io.js ?

[vermine]

Pas spécialement. L'un et l'autre continuent de sortir des versions en leur nom distinctif sans vraiment faire référence à l'autre.

[danielhagnoul]

Plus d'excuses, la norme est enfin sortie : Standard ECMA-262 ECMAScript® 2015 Language Specification.

Free book online : Exploring ES6 Upgrade to the next version of JavaScript

[danielhagnoul]

Abandon d'Object.observe !

[SylvainPV]

Oui, Twitter est en feu sur ce sujet... Plusieurs personnes dont Brendan Eich s'en réjouissent, je ne comprends pas pourquoi. On a toujours besoin d'une solution de détection de changement viable en JavaScript ! Angular, Ember, Polymer, tous ces frameworks ont fait leur propre tambouille. J'ai moi aussi bricolé de mon côté pour ObjectModel. Les solutions actuelles sont inefficaces :
- les getters/setters ES5 ont beaucoup trop de contraintes
- tout comme les proxies ES6 qui obligent à perdre la référence à l'objet initial
- se baser sur les DOM events comme Polymer et Riot ? Un coup dans le mille, un coup dans l'eau...
- dirty checking ? Trop complexe, performances médiocres, et on perd la synchronicité des changements.

Que reste-t-il ? La spec Object.observe n'était pas parfaite, mais c'était une vraie solution à ce problème. Simplement parce que d'autres libs comme React ont choisi des voies autrement plus radicales comme l'update général et systématique d'un DOM virtuel, cela ne signifie pas que l'idée de base du data binding était mauvaise. La preuve, elle est encore largement répandue dans la plupart des frameworks populaires.

Bref, très déçu par cette décision qui semble injustifiée et pénalisante (notamment pour Node qui doit en assurer le support pendant 30 mois à cause de la release LTS). Ce n'est pas une décision définitive, mais vu que les pro-React sont en train de parader sur Twitter comme si leur équipe venait de gagner la coupe du monde, je crains fort qu'ils ne fassent pas marche arrière.

[Invité]

Avec des frameworks exceptionnels et modernes, comme AngularJs, couplé à des bases de données en ligne comme FIREBASE(2013) qui stockent les modèles de données JSON, et qui permettent l'authentification, autant dire que la lumière provient de ce couple.

En effet, il n'y a plus de Back End à coder, ni de code Sql à taper, tout est automatique.

[SylvainPV]

Ça y est, la messe est dite ?

Tu auras beau raconter partout que AngularJS+Firebase fait des miracles pour toi, il n'empêche que ça ne reste que ton petit besoin personnel, pas le nôtre. Prêcher une techno unique n'a aucun sens, pas plus que d'affirmer qu'un marteau peut remplacer un tournevis.

Sur mon projet actuel, je lead la partie front qui tourne sur Angular 2. Le back, bien plus complexe, est construit sur une architecture micro-service JavaEE. J'ai beau bien connaître Angular et être spécialisé front, jamais je n'aurais la bêtise de proposer de déplacer toutes les règles métier et la complexité du code côté client. Firebase ? Ce n'est qu'une bête couche de persistance des données, ça ne couvre absolument pas nos besoins. Une base NoSQL ? On a bien un MongoDB qui tourne, mais le gros des données reste géré en SQL, choix le plus logique quand on a besoin de gérer des requêtes complexes impliquant des dizaines de tables différentes, et pas juste bêtement recracher des objets déjà structurés.

Enfin, je doute que ça serve à quelque-chose d'argumenter avec toi si tu penses sérieusement qu'on a tous "plus besoin de coder en back-end", comme j'ai pu le lire ici ou là. Essaie de faire preuve d'un peu plus d'humilité, car c'est le genre d'inepties qui montre bien que tu manques d'expérience en entreprise.

[Invité]

Firebase gère l'identification, ce n'est pas un MongoDb, ce n'est pas pour rien que Google l'a racheté et qu'ils misent dessus. Je pense que c'est le futur. Non, je ne pense pas que dans la majorité des cas, ce dont tu parles, les jointures sur les bases de données relationnelles soient encore utiles.Désormais, la plupart des projets pourront être réalisés sur ce type de nouvelle architecture de type Firebase. Ce n'est pas parce que la majorité des entreprises utilisent encore ces principes de base de données relationnelles, pour raison financières ou dinosauresques, que c'est la voie à suivre.
En 1980 aussi, il y avait des serveurs avec des lecteurs à Bande, et des dinosaures de 1965 prétendaient que c'était le top du top, alors que des disques durs étaient déjà sortis. Normal puisqu'ils étaient employés par le société qui produisait les bandes magnétiques, ils allaient pas risquer de perdre leurs emplois. Mais c'est vrai que le code AngularJs est visible, même uglifié, et c'est chiant.
De plus, certes je n'ai qu'un niveau très moyen, il semble qu'il est possible de programmer sans champs ID certains modèles de données avec ses nouveaux systèmes, lorsqu'on le désire, ce qui allège encore le code et permet d'aller plus vite.
Et pardon, mais , une révolution comme le 3 ways binding que propose Firebase ne peut être passée sous silence, c'est révolutionnaire. C'est à dire que les données sont synchronisées en temps réel, entre les vues, le modèle et la base de données, et ceci assez simplement.

Salut et merci.

[progdebutant]

Prêcher une techno unique n'a aucun sens

Et je ne suis pas d'accord avec ça :

"Si l'on repart de la base […] un langage à objets est suffisant"… Quelle base ? Un langage procédural aussi est suffisant.

Pour moi un langage procédural peut certes faire des choses équivalentes mais de façon bien moins pratique.
Un personnage RPG en procédural avec ses objets et ses actions sera moins pratique à faire en procédural par exemple à cause de tout ce qui va avec le personnage :
Liste d'objets du personnage
Compétences du personnage
Actions du personnage
caractéristiques du personnage
etc...

Gérer tout ça de la même puissance que le langage objet je n'y crois pas trop sauf si on me le démontre.

[danielhagnoul]

La meilleure nouvelle du jour : Chrome 49.0.2623.28 beta-m (64-bit) est disponible.

Il est compatible à 91 % avec ES2015, selon https://kangax.github.io/compat-table/es6/.

Source : http://googlechromereleases.blogspot.fr/

[SylvainPV]

Et on a maintenant les Proxy supportés par le trio Edge/FF/Chrome ! Pour le data-binding c'est le top, j'ai hâte de voir comment les futurs frameworks vont les utiliser. Adieu les $watch(), adieu le dirty checking !

[danielhagnoul]

Je redécouvre Firefox avec plaisir grâce à l'édition pour les développeurs. La version 46.0a2 (2016-02-11) est compatible à 90 % avec ES2015.

[danielhagnoul]

Disponibilité des modules dans les navigateurs le 2017-05-02 :

• Safari 10.1
• Chrome Canary 60 : il faut activer le flag "Experimental Web Platform" dans chrome:flags.
• Firefox 54 : il faut activer le flag "dom.moduleScripts.enabled" dans about:config.
• Edge 15 : il faut activer le flag "Experimental JavaScript Features" dans about:flags

Tutoriel en anglais : https://jakearchibald.com/2017/es-modules-in-browsers/
Tutoriel de MDN (pas à jour) : https://developer.mozilla.org/fr/doc...uctions/import

[Doksuri]

Hello, je ne savais pas trop ou poster ca, ni meme si ca vallait un nouveau topic, donc je le rajoute ici

ES2017 (ES8) est dispo
https://www.ecma-international.org/p...s/Ecma-262.htm

This Standard defines the ECMAScript 2017 general-purpose programming language.

version html
version pdf (7Mo)

[danielhagnoul]

The state of JavaScript 2017

Les résultats de cette enquête annuelle m'intéressent pour voir la percée de ES2015+, mais il y a d'autres choses à en retenir. Voici deux points importants, je vous laisse découvrir le reste.

1. https://stateofjs.com/2017/flavors/results
   
   
   

   Lorsque vous parlez de JavaScript, vous ne parlez pas seulement d'une seule langue, mais d'une gamme de «saveurs» qui se résument toutes à la même cible. Bien qu'ES6 soit maintenant une norme bien établie, elle pourrait être un jour mise au défi par la montée en puissance de TypeScript, qui devient rapidement le leader de l'espace JavaScript typé.

2. https://stateofjs.com/2017/front-end/results
   
   

   Comme toujours, la bataille pour le mindshare JavaScript est menée par des frameworks frontaux. React est toujours le joueur dominant ici, mais Vue fait de gros gains grâce à la popularité décroissante d'Angular. D'ici 2018, ce graphique pourrait finir par être très différent !

[domi65]

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<input type="button" value="Envoyer" onclick="envoyer()" />

c'est complètement obsolète et donc à proscrire.

Pas d'accord. C'est tout à fait valable. Seulement, le javascript n'est pas séparé du HTML.

Si tu veux placer tout ton JS dans un fichier externe, alors c'est pas bon, ni si tu veux un gestionnaire plus poussé, mais ce n'est pas en soi une mauvaise pratique. Et c'est clair que c'est moins savant que document.querySelector('[type=button]').addEventListener('click',function {...}).
mais ça fonctionne très souvent pareillement, si des biblis externes ne viennent pas foutre le b*****

[melka one]

Ce que je constate c'est que lire du JavaScript devient de plus en plus imbuvable bientôt il faudra avoir fait 10 ans mini de JavaScript afin de comprendre ce que fait un code et pendant ce temps les framework et autre ce régales.

[le_chomeur]

Génial de voir l'évolution de ce thread 10 ans plus tard ^^

étant passé sur typescript , je continue d'évoluer dans le monde du javascript et j'y prends toujours autant de plaisir