Version imprimable
Ah non, j'ai choisi pr�cis�ment le JS comme langage principal pour �viter ce genre de d�sagr�ment :mrgreen: 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 ?
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. :?
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
Pi�ce jointe 180921
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.
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.
�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.
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.
:applo:Citation:
Pr�cher une techno unique n'a aucun sens
Et je ne suis pas d'accord avec �a :
Pour moi un langage proc�dural peut certes faire des choses �quivalentes mais de fa�on bien moins pratique.Citation:
"Si l'on repart de la base [�] un langage � objets est suffisant"� Quelle base ? Un langage proc�dural aussi est suffisant.
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.
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/
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 !
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.
:yaisse2: :ccool:
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
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
version htmlCitation:
This Standard defines the ECMAScript 2017 general-purpose programming language.
version pdf (7Mo)
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.
- https://stateofjs.com/2017/flavors/results
Citation:
Envoy� par Traduction de la conclusion de cette page par Google
- https://stateofjs.com/2017/front-end/results
Citation:
Envoy� par Traduction de la conclusion de cette page par Google
Pas d'accord. C'est tout � fait valable. Seulement, le javascript n'est pas s�par� du HTML.Citation:
Envoy� par FaridM
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*****
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.
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 :)
