Reprise du message précédent :

  "Spring c'est grand maintenant" ? Tu l'as utilisé quand pour la dernière fois, en 2005 ? J'y ai touché pour la première fois genre vers 2007-2008 et c'était déjà conséquent... et on faisait déjà plein de trucs avec, notamment l'inversion de dépendances. Ce qui n'est pas du tout orienté web, par exemple.
'fin bon, /HS, c'était un exemple pour différencier "apprendre un langage" vs "apprendre un framework".

Pas si c'est à des fins d'apprentissage. Hello World tout le monde s'en branle, l'intérêt c'est de créer un projet, le compiler et avoir un résultat. Faire ses premiers pas avec une techno, langage ou framework.
D'autre part, le gros argument de l'article n'est pas de réécrire du code pour le plaisir :

Déjà il y a du doute, "perhaps". Y a bien évidemment des fois où l'utilisation d'un framework va apporter plus de bénéfices que ça ne créera de problèmes. Mais surtout, l'accent est mis sur la dépendance : tu vas importer du code qui fait probablement plus de trucs que tu n'en as besoin et en plus que tu ne connais pas (ce qui implique des problèmes de sécurité ou de confiance mal placée). Et ce sans parler des "leaky abstractions".

Ca dépend du framework. Par exemple Angular (le 1, je ne connais pas le 2), qui introduit énormément de choses propres à Angular et pas du tout au JavaScript "vanille". Et d'ailleurs, si tu ne sais pas bien faire de JS, tu auras du mal à comprendre Angular. Il faut commencer par apprendre JS avant.

Bref. Ca ne répond toutefois pas à la question originale et que je pose aussi Quelle(s) bonne(s) ressource(s) pour apprendre JavaScript vanille ?

Javascript the good parts.

et moi je suis en train de me battre avec appcache  ( notamment pour faciliter la migration appcache ->service worker )
Javascript, the ugly parts

Me suis mal exprimé mais cdi ou freelance qui veut rester à son compte, sans lien de subordination bien sur.

Fuck fuck that was fun mais maintenant un mec bourré qui est techniquement mon employé veut pas me filer ses clef des voiture.
 

Est-ce que pour toi ES6 et 7 comptent dans le JS Vanilla ?

je croays qie tu n'avais pas le permis ?

pour moi c'est du vanilla quand sa tourne sans moteur de build dasn les browser récents. ES7 est exclu, mais ES6 est ok.

0x90 a une voiture ?

 
A ma gauche je bosse avec un developpeur qui apprend le frontend en maintenant un projet angular. Il a appris a déclarer une directive, et un service, mais ne comprend pas comment le framework remplace les balises avec son template. Il sait juste que ça le fait en mettant du code là et recopiant le nom de la directive dans une balise. Et quand ça le fait pas, il m'appelle parce qu'il a pas les outils pour comprendre où regarder.
 
 

A la rigueur c'est un peu le but du framework, tu fous pas les mains à l'intérieure pour voir comment il va mettre en place sa mécanique de fou.
Angular c'est une super usine à gaz qui fait des choses, mais beaucoup trop de choses, il y a 10x trop de choses, c'est peut-être un peu pour ça qu'il est devenu populaire au près des devs backend.
Mais c'est le framework utilisé en masse dans la boite

 
Justement, je voulais que personne ne conduise

C'est ce qu'on utilise aussi  
Ca fait le boulot je vois pas le soucis, puis c'est quand même agréable à utiliser

Quelqu'un a une bonne introduction aux relay/falcor, au fait d'avoir des composants qui décrivent du querying de graph compositionel? J'ai lu les docs relay mais pour le moment ça clique pas, je vois pas comment ca marche pour un système non trivial et/ou dynamique.

 
Pour moi le souci c'est qu'il faut déjà avoir un niveau correct en front pour utiliser angular correctement.  
Deux exemples concrets dans mon projet:
- le nombre de listeners (en voila une de leaky abstraction) augmente très facilement de trop et ralentit l'appli sur navigateurs mobiles. Aller corriger ça après coup a été funky.
- les dévs ne se rendaient pas compte que des balises au nom inconnu n'étaient pas traitées pareillement entre les différents navigateurs (pas les mêmes propriétés par défaut), et ont eu des problèmes de layouts tordus à cause de ça.  
 
Et du coup, si on part du postulat qu'il faut avoir un niveau correct pour s'en servir, ben on a moins (voire pas) besoin d'angular.

Je ne peux pas parler pour Angular en particulier, mais je crois que tu n'as pas compris l'intérêt d'un framework. Ce n'est pas parce que tu sais faire à la mimine que tu dois t'en passer.

Je me sers d'angular (sur une app en cours avec pas mal de formulaires )
Je me sers de backbone sur un autre projet, et j'ai même un projet récent avec juste jquery côté client + silex côté serveur
J'ai des projets avec react/d3/...  
 
Tout simplement parceque c'est le bon outil pour l'usage cible.

 
Lol.

 
Belle argumentation
Je suis d'accord avec toi, mais je trouve la conclusion bizarre. Pourquoi faudrait il se passer d'angular si on sait comment ça marche / a un niveau correct ?  

Des gens ont testé le framework Phalcon PHP ? Des retours particuliers ?

Pour ceux parmi vous qui bossent sous Windows ( ) et qui réalisent les designs de leurs sites ou applications avant de coder, vous avez une alternative à proposer à Sketch ?
 
Le gars qui bosse sous cet outil chez nous produit des résultats impressionnants en peu de temps et du coup, je trouve l'approche plus pertinente que du wireframing type Balsamiq qui est sympa pour du layout, mais nettement moins vendeur pour le client.
 
Pour ceux qui n'ont pas la chance d'avoir un designer ou spécialiste UX dans l'équipe, vous traitez comment le sujet ?

 
Je dis que mieux on sait coder moins on a besoin d'un framework (cad moins on est obligé d'utiliser les différents composants du fw), et vous comprenez que je dis qu'il ne faut pas utiliser de fw quand on sait coder.
Et je pense que c'est une bonne idée d'essayer d'en utiliser le moins possible parce que c'est du code qu'on ne connais pas et qu'on a pas envie de connaitre. Mais a cause des "leaky abstractions" justement on va devoir se pencher dans la boite noire a un moment, en général le jour de la livraison. Je trouve aussi qu'on en utilise souvent juste parce que c'est un choix "safe". Typiquement personne va critiquer un dev qui va proposer angular pour faire son frontend. Par contre on sera plus suspicieux si il propose juste require.js. Et du coup j'ai l'impression que pour pas avoir a se justifier beaucoup de projets commencent avec un fw dont on a pas besoin.

Dans un monde idéal je suis complétement d'accord avec toi, mais dans la plupart des cas on utilise cette boîte noire pour gagner du temps (donc de l'argent ), même si au final c'est pas adapté à 100% et que c'est un peu moins performant que du sur mesure.  

Et du coup on se retrouve avec un node.js couplé à un angular, une petite partie PHP symfony quelque part, et du jquery/jqueryUI + un FW CSS bien lourd (ps aux autres dev : arrêtez d'utiliser les classes col-xx-x des FW MERCYYYYY), avec des petits morceaux de vanilla à droite et à gauche ...

Y'a pas du monde au devoxx par hasard ? j'y suis la

 
Exactement, vu que nous ne somme pas dans un monde idéal.

Perso j'y serai que ce soir.
Pour tout ce qui est web, t'as le talk sur les PWA (qui est euh... maintenant) et le talk d'Hubert Sablonnière sur les JSON Web Tokens (connais pas le contenu mais le speaker est excellent). Le talk sur la crypto par Thierry Abaléa doit valoir le détour aussi mais spa pur web (enfin je pense pas).
Et pour rester dans l'esprit du topic, t'as aussi la prez des gars de Sfeir sur la quête du Graal
 
'fin y a pas mal de trucs qui ont l'air bien cette année pour le web. En même temps, avec 8 à 12 confs en parallèle sur chaque créneau, ce serait malheureux qu'il n'y ait rien...

 
Pourquoi ça ?

 
Ou on l'utilise parce que c'est un gain en productivité et que réinventer la même chose à chaque projet ou devoir expliquer comment c'est architecturé à chaque nouvelle recrue n'est pas efficace.
 
Entre être un dev qui bosse seul sur son petit projet 1x ou être sur un projet développé par des 10aines de dev, le résultat  ne sera pas le même.

 
Je suis de l'avis que si tes recrues sont pas des tanches, elles doivent savoir reconnaitre un controller d'un DAO.

Tu codes en assembleur j'imagine du coup ?

Peut être parce que require.js c'est de la merde   A tout hasard  

 
(j'ai pas tout quote)
 
c'est moi, ou c'est niveau cour d'ecole la discussion la ?

Ouais, t'as raison, j'arrete.

 
On a pas eu la reponse a ca.

C'est moins lisible

Moins lisible que quoi ?

class="sidebar" par exemple

D'ailleurs, une sidebar y'en a en général qu'une, donc .sidebar ou #sidebar ?

<aside>

Voila, mon exemple n'était peut être pas le meilleur

C'est plus pour une tangente que pour une sidebar, normalement.