Où va-t-on avec JavaScript ?
Participez au débat sur l'orientation actuelle et le futur de JavaScript

Le , par le_chomeur, Expert confirmé
Bonjour a tous , cela faisait un moment que je n'avais pas posté

Depuis quelques temps , je remarque une évolution des comportements vis a vis de JS , de plus en plus d'utilisateurs viennent ici pour comprendre / modifier des scripts existant en fonction de leur besoins, et bien souvent ces scripts sont basé sur des librairies / framework.

d'ou ma question , concrètement pensez vous continuez à coder comme nous le faisons aujourd'hui en repartant de zéro ( Spaffy si tu m'entends ) ou vous même passer a du full librairie pour vos dev , même les plus minimes ?

en apparté pour ceux qui ont commencé a s'y intéresser , vos retours sur l'html 5 / css3 et toutes les nouvelles fonctionnalités introduites par ceci au seins de javascript.

cdt,

Le_chomeur


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de vermine vermine - Responsable JavaScript & AJAX http://www.developpez.com
le 17/03/2015 à 8:25
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.
Avatar de danielhagnoul danielhagnoul - Rédacteur http://www.developpez.com
le 17/06/2015 à 22:49
Avatar de danielhagnoul danielhagnoul - Rédacteur http://www.developpez.com
le 02/11/2015 à 22:44
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur http://www.developpez.com
le 03/11/2015 à 0:20
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.
Avatar de - http://www.developpez.com
le 05/12/2015 à 23:49
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.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur http://www.developpez.com
le 06/12/2015 à 3:12
Ç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.
Avatar de - http://www.developpez.com
le 06/12/2015 à 15:10
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.
Avatar de progdebutant progdebutant - Membre habitué http://www.developpez.com
le 02/01/2016 à 5:58
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.
Avatar de danielhagnoul danielhagnoul - Rédacteur http://www.developpez.com
le 28/01/2016 à 22:56
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/
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur http://www.developpez.com
le 29/01/2016 à 10:30
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 !
Avatar de danielhagnoul danielhagnoul - Rédacteur http://www.developpez.com
le 11/02/2016 à 23:13
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.

Offres d'emploi IT
Développeur Web - JavaScript [H/F]
Matelli - Ile de France - Paris (75003)
Développeur javascript pour agence sportive
Mobiskill - Nord Pas-de-Calais - Lille (59000)
Développeur javascript (H/F)
CTS Consulting - Pays de la Loire - Nantes (44000)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique JavaScript : Xavier Lecomte -