Reprise du message précédent :

On parle pas de sass/less là, on parle d'autoprefixer au lieu d'utiliser des mixins/includes, c'est indépendant. Tu peux même utiliser autoprefixer tout seul sur du CSS pur. Le principe c'est que t'écris ton CSS3 propre, tu dis à autoprefixer quels navigateurs tu veux supporter et il va cross-référencer les stats caniuse et ajouter uniquement les préfixes (et syntaxes alternatives) nécessaires.

J'aimerai bien utiliser Grunt, Gulp, autoprefixer, Less. Mais je sais pas par où commencer.

1) LESS => tu crée 2 feuilles de styles histoire de modulariser un gros paté existant en plusieurs fichiers.
2) t'es comme un con, tu te demandes comment crée ton fichier .css en output
3) tu installes grunt et grunt-contrib-less et la task qui-va-bien
4) tu veux utiliser border-radius mais HFR dit que c'est pas le boulot de LESS, tu installes autoprefixer via grunt-autoprefixer (tu te re-felicite d'avoir commencé grunt)
5) tu fou tout à la poubelle pour utiliser gulp
6) tu vire less pour SASS
7) tu vire gulp pour brunch et SASS pour Stylus

Pour en revenir sur le choix de stack, je dirai que c'est une question de culture. Chez nous, avec donc du Node/Angular et utilisation massive de npm, ça nécessite de faire les choses autrement qu'avec une stack plus monolothique.
 
L'avantage c'est que généralement, quand on trouve un bug dans une dépendance, on le rapporte et c'est vite corrigé. Si ce n'est pas le cas, on peut le corriger nous-même (petites libs = facilité de maintenance)
 
Donc oui, faut aussi « intervenir » de temps en temps pour ajouter des trucs ou améliorer une petite lib, mais ça fait parti du taff (et on reste positif sur le temps gagné à utilisé des petites briques).
 
Après c'est sûr que c'est pas fait pour tous le monde

Chez nous qui va bien : Gulp et Less.

Sinon jette un œil à ça : http://yeoman.io/generators/
Ça aide bien à boostraper un projet web

Oublie grunt ca devient vite un bordel au niveau de la conf, gulp est bien mieux

Ah mais je suis certain. Sauf que j'ai pas encore étudié la question entre
Gulp/Grunt
et Less/SASS/SCSS. Bah, de toutes façons, j'vais essayer 2-3 trucs, et voir ce qui me convient le mieux à l'usage.
Le truc, c'est idéalement, mon appli, qui a plusieurs JS, plusieurs CSS, combine le tout en 1 gros fichier de chaque type pour la prod, histoire de pas avoir 50 http calls.

Ça c'est assez basique, on utilise nous pour minifier tout le merdier

Cf notre fichier pour « xo-web » : https://github.com/vatesfr/xo-web/b [...] ulpfile.js

En dev, tu utilises les sourcemaps pour pouvoir débugger facilement, en prod c'est rassemblé/minifié

ben ayant été chef de projet puis chef de chefs de projet responsable d'une roadmap, j'ai été du côté du mec a qui on explique que le truc fait 6 mois avant est en fait totalement nul et qu'il faut le refaire (je parle pas de refactoring : de réécriture). Par ailleurs je déteste perdre mon temps, donc j'aime bien planifier un peu ce que je fais.
Quand j'étais plus jeune j'aimais bien jouer avec tout ce que je trouvais, mais j'ai plus le temps pour ça. Je passe de ce fait surement à côté de trucs super bien, mais ce compromis me va bien.
Et encore une fois, je vous admire tous de vous plier à cette obsolescence programmée pour votre job. Il se trouve que j'aime bien le management pour plein de raisons, mais autant le côté dev me manque parfois (donc je code pour le plaisir), autant l'aspect "autoformation à marche forcée en continue" me saoulait beaucoup...et tu te pas descendre du train sous peine de devenir complètement obsolète, ou te contenter de bosser dans une niche.
 

moi j'ai pas hésité pour le coup, j'avais déjà essayé SASS l'année dernière et trouvé très bien :
- foundation et bootstrap sont dessus
- j'aime bien le côté progressive enhancement des CSS, on peut commencer avec un truc basique puis insérer des trucs après
 

je suis pas forcément d'accord : ce qui m'intéresse moi c'est ce qu'on fait avec les outils, modérément l'outil en lui meme. Aujourd'hui si je caricature les dernières évolutions ce sont les SPA, et le REST pour offrir une API comme approche architecturale. L'asynchrone y'a pas eu besoin d'attendre Node, et on savait scaler des sites autrement avant.
 
Par ailleurs je sais pas l'age que tu as ni ton XP pro, mais au bout d'un moment ça lasse un peu le changement continu, surtout si la finalité change peut, et que t'es donc surtout sur un changement de technos. Je préfère passer mon temps d'apprentissage à apprendre des choses qui m'ouvrent des perspectives nouvelles. En simplifiant : si j'ai un marteau dans ma caisse à outil, apprendre l'utilisation d'un nouveau marteau ne m'apporte pas forcément grand chose. Apprendre l'utilisation d'une tournevis m'ouvre des perspectives nouvelles. (note : je ne suis plus dans une logique d'expert, en tout cas plus technique. Je respecte complètement l'approche du gars qui me dit : moi je veux êre le meilleur expert en marteau du monde. Perso je préfère le management / expertise fonctionnelle, mais c'est purement une question de gout ).
 
Un mec qui fait du RoR / Django, sur les 5 dernières années il a pu vachement capitaliser, les frameworks évoluant progressivement. Un mec qui fait du JS, il peut capitaliser sur rien à part sa connaissance pure du langage...tout le reste change trop vite.
 
y'a des tas de trucs intéressants avec JS en ce moment, ça manque pour moi d'un groupe avec les bons moyens qui sorte un stack bien intégré, bien maintenu, bien documenté, pour générer de la traction. Angular était ce qu'il y avait de plus proche. En tant que "décideur", même si je trouve le truc intéressant, je serais réticent à ce que l'équipe technique parte à fond là dessus, parce que c'est pas sec (et que notre coeur de métier c'est de vendre du café, pas de faire de l'IT)
 

faut voir où tu es sur ta chaine de valeur : en effet je doute que la plus value première de ta boite ce soit de contribuer des patchs sur des libs microscopiques JS mais ça peut rester une externalité positive intéressante

La chaîne de valeur c'est d'avoir un soft qui poutre rapidement sans réinventer la roue. Des fois il manque pas grand chose dans une roue existante pour que ça convienne exactement à notre besoin, donc feu, on contribue
 
Mais par rapport à la possibilité d'avancer très très vite grâce à ces libs, on gagne un temps fou (XO était en PHP au départ, je peux te garantir l'accélération de malade en passant à Node/NPM, alors qu'on connaissait pas la techno justement, et inversement mon associé était vraiment calé en PHP).

donc c'était un bon choix

 
Après comme je disais, ça nous convient, mais c'est pas universel Faut « aimer » bosser comme ça (c'est très philosophie Open Source, bazar vs cathédrale tout ça)

 
Tu sais quoi machine. Reste comme t'es tu me fait bien marrer du profond fondement interne de mon psyché.
Au mieu t'as 10 ans et tu génères des mots sans même avoir prie soin d'observer leurs effets.
 
En gros tu parles sans savoir comment ça vas faire dans ton cerveau.
Tu vie soumis à ce dernier.
Tu est à peine conscient que tu n'exprime rien.

J'ai bien nagé au fait.
 
Vous savez nager ?  

 
De plus en plus de gros noms de la SV ( LinkedIn, Netflix, Apple, Yahoo! ) lancent des applis en Ember.js. La courbe d'apprentissage plus élevée et la longue période de gestation/maturité le rend moins attractif, mais toutes les pièces commencent à s'assembler correctement. Ember 2.0 va retirer pas mal de concepts qui rendaient l'apprentissage compliqué.
 
C'est surtout pas forcément fait pour résoudre les mêmes problèmes. Avec Angular ou React, tu peux apprendre des bouts de la techno et en faire quelque chose qui s'insère dans ton app. Alors qu'Ember est la base de tout et nécessité de tout apprendre.
Du coup, c'est plus simple rapide d'avoir quelque chose qui marche avec Angular/React, mais si tu as une application avec un certains niveaux de complexité, tu peux rapidement finir avec une bouillie, là où les conventions en Ember te serviront de garde fou et permettent à un développeur de passer plus rapidement d'une app à l'autre.

 
J'ai l'impression qu'on a déjà eu ce débat où je m'étais fait lynché, mais ce n'est pas de l'obsolescence programmée pour moi. C'est une évolution du web en tant que plateforme qui crée de nouvelles perspectives, et les outils de développement sous nos yeux. La multiplication des terminaux ( réduisons ça au lancement de l'iPhone et de la 3G ), la standardisation du web ( Firefox, Chrome ), la maturité/puissance des terminaux fait qu'une appli cliente full JS est quelque chose devenue réalisable.
 

 
C'est pas faux. Mais tu tiens le discours de vieux ou du pauvre, à quoi bon rouler en Tesla quand je peux aller plus loin en 2CV
 

 
C'est faux. Ça fait 3,5 ans que je fais du Ember. Et ça fait AMHA presque 3 ans que je capitalise dessus, sans constamment tout réapprendre tous les 3 mois.
 

 
Là où jQuery était suffisant pour bricoler, la répétition du développement d'applications JS ainsi que l'augmentation de la complexité font qu'on cherche à amener dans le navigateur les concepts éprouvés sur d'autres plateformes/autre niveau de la stack. Et comme toute version 1.0, tout le monde tente et apprend de son échec. On arrive à la phase 2.0, on peut espérer/voir une augmentation de la maturité et une accélération de l'adoption.
 
Mais quand on voit les outils de dev/debug ou la documentation, on voit quand même que le développement web en général a encore de sacrés progrès à faire pour arriver au niveau de ce qui se faisait au niveau desktop il y a 10 ans ( du moins pour quelqu'un comme
moi qui était du côté Windows ). Et ca se voit aussi dans le niveau des développeurs ( plus facile de trouver un mec moyen qui a bidouillé un site web qu'un mec qui a tenté de faire ca en C++ )

 
Je pense que c'est une erreur que beaucoup ont fait et font en choisissant Angular par rapport à Ember par exemple : le nom Google rassure, car géant du web.
 
Mais pour ceux qui suivent un peu, Google en a pas grand chose a foutre de la communauté et n'est pas un éditeur de logiciel. En interne, Angular n'est pas maître chez eux, et rien ne tend à prouver que cela va devenir le cas.
 
Ce ne sera ni la première ni la dernière fois qu'ils tueront un projet, et ce n'est pas parce que c'est FOSS que c'est maintenu correctement.

Fait quand même un tour du côté de Meteor.JS, sur 15 ans de code, c'est le premier avec lequel je me dis "ouep, là c'est cool".
 
Alors bien sur, il y a des parties tu vas te dire "avec X ou Y ca serait casé, et là je met 5 minutes de plus H-O-N-T-E-U-X ".
 
Mais globalement l'approche est plutôt bonne, et même si a mon avis en scalabilité ca le fait pas, ca reste très novateur dans l'approche comme techno (et depuis maintenant 2 ans, c'est sécure car au début ouch )

je l'ai pas trop regardé celui là. Je déduis de ton post que je devrais.
 

ces évolutions sont géniales, mais on peut en bénéficier sans que l'outil qu'on utilise doive changer tous les 6 mois.
 

si je sais conduire, je peux conduire une Tesla : c'est qu'une évolution d'une 2CV. La tesla ne rend pas mes skills de conducteur obsolètes.
 

faut que je regarde. Le fait qu'Apple ait sorti Apple Music dessus m'avait titillé
 
 

+1... mais du coup j'évite d'être un early adopter sur ce coup là, parce que j'ai pas vraiment le temps de me tromper.
 

gros +1, le tooling fait peur (cf mon sarcasme sur les gens qui se foutaient de Maven alors que JS a essentiellement recréée un truc identique)
 

j'ai le luxe d'attendre, puisque je dois pas shipper du code en production pour gagner ma vie. Donc je vais tranquilement attendre que ça murisse

Franchement le blabla outils/2CV/Tesla j'adhere pas ...
J'essaye de rester au taquet des technos JS, résultat ca fait 3ans que je fais du angular 1.x et j'estime avoir encore avoir pas mal de mois voir années avant de passer a angular 2.x pour de la prod. Donc l'argument des technos qui changent tous les 6 mois...

Entre temps, je lurque du coté de nodejs, meteor, react, angular2... résultat : ca m'a permis de me mettre à l'ES6 par exemple. Et niveau "javascript" global, j'ai bien "upé" en terme de skills, ce qui me sera fortement utile lors de l'apprentissage de la techno JS qui emergera après. Question skills JS transverses / perenité, ca ma semble bien.

Bref j'estime etre meilleur pilote en testant pleins de voitures, et je piloterais mieux les futurs voitures en restant au taquet sur les actuelles

Accessoirement ca m'a permis de me faire embaucher dans une boite et d'avoir un bon salaire parce que j'avais les bons mot-clefs du moment

Bon après j'aime me vautrer dans la nouveauté, et par chance mon comployeur et mes clients ne me demande que ca...

Tu peux commencer à zieuter ES7 alors

Oui il parait

Ca va presque finir par avoir tout le syntactic sugar de Python a force

Chez nous c'est déjà utilisé Ya des trucs chouettes ! (enfin moi j'y ai pas trop mis les mains dedans ces derniers temps mais je fais confiance à mon équipe )

Je te dirai ça si j'ai de nouveau la chance d'écrire un peu de code d'ici la fin de l'été

Tu peux y aller c'est mur globalement
 
Il y a deux ans, j'aurais pas dit ça, l'idée étant d'exposer la BDD côté user -et de gérer à ta place la passerelle client/serveur-, il y a 2 ans, TOUT était exposé, et il fallait à la mano limiter les UPDATE/DELETE, failles de sécu potentielles a gogo donc...
 
Maintenant ils ont mis en place un mécanisme de publish/subscribe permettant de restreindre pour chaque user le jeux de donnée auquel tu as accès et la porté des modifs possibles. C'est propre, et ca limite lourdement les soucis, la gestion des users est automatique qui plus est (un simple fichier de config et rulez), bref, les gens leur ont reproché ces deux soucis (pas de restriction + pas de gestion user facile), les deux sont top maintenant

Pas comparable au reste.
 

Je vois pas comment tu peux faire ça de manière efficace avec Angular.

 
Tu es obligé d'avoir le routeur Angular pour avoir un widget ?

Avec les temps de compilation d'un template C++ \o/

tu balance 1Mo de js , dès le premier widget

Sans parler de la stack de merde, surtout en 2.0.

 
Je ne connais pas, donc j'ai du mal à voir le rapport.

Il dit que le truc est un monolythe

Ca j'ai compris.
 
Mais je ne vois pas en quoi télécharger quelque chose force à l'utiliser.

Il parle du hit http visiteur je pense..

 
ça ira mieux quand les navigateurs supporteront bien ES6...vers 2020

 
Ça avance bien tout de même : https://kangax.github.io/compat-table/es6/
 
Enfin sauf si tu parles des trucs Apple, là ça serait 2050 peut être

On parle de web, c'est pas super comme façon de penser et il n'est pas pensé pour être découpé.

Filer 1mo de js a télécharger en plus à c'est énorme. Il faut qu'il y ait un vrai gain, pas juste deux pauvres widget. A moins que tu ne sois fan de sites qui mettent 3 plombes a se charger

Je ne vois toujours pas le rapport avec la courbe d'apprentissage. Mais visiblement, je suis le seul donc je dois avoir tort.

Je ne parlais absolument pas de la courbe d'apprentissage
 
Juste qu'angular : tu l'utilise pour l'intégralité ou pas du tout . Impossible de mettre quelques widgets sur un site sans ajouter une montagne de javascript inutile