Reprise du message précédent :
J'ai jamais dit qu'il y avait une techno parfaite.

Il y a une techno qui est plus ou moins adaptée à :

* ta façon de coder
* les besoins réels derrière

Node+NPM c'est de la programmation orientée composant (façon de faire) qui sait bien gérer les I/O avec des concepts intéressants (besoins). Et ça tourne partout (navs, OS, serveurs maintenant etc.)

D'où sa popularité.

Mais c'est pas une réponse à TOUS les besoins, j'oserai jamais prétendre un truc pareil

 
Euh, entre faire des évolutions qui demandent de changer le code, c'est une chose, dire "réécrivez tout", c'en est une autre.

Perso j'aime bien le « réécrivez tout », c'est très sain pour un projet de temps en temps (après c'est parce que mon lead dev est très comme ça, et que sur des petits modules ça pose pas de soucis).

 
Donc vous comptez pas passer a Angular 2.0 ?

 
Non, pas de suite. On verra quand on fera « le grand saut », vers lequel on ira. Pas de préjugés, on regardera ça au calme

Et ils comptent maintenir la version 1 niveau sécurité ou tu viens de lancer un produit avec une techno obsolète ?

 
Le concept de « lancement » de produit n'a pas de sens, on release tous les mois Yaura un cycle de release où on va passer d'Angular 1 à autre chose, et puis voilà
 
Sachant que la partie Web c'est pas le plus compliqué quand même.

flux + react , flux +react  

 
Ça a l'air fun. https://scotch.io/tutorials/getting [...] chitecture
 
Ta des ressources qui t'ont convaincu ?

Je ne les ai pas bookmarké, mais Flux me rappelle beaucoup ce que je fais avec backbone, en mieux structuré : des stores partagé, un  bus d'evenements ...
REactjs reprends le côté magique des directives d'angular pour faire du code modulaire, mais je trouve le fonctionnement plus esthetique ( et largement plus rapide)

et react native me fait carrément de l'oeil ( si ils sortent aussi une version android)

Je n'ai pas fini de digéré le dernier né de la famille : relay pour la couche d'acès aux données http://facebook.github.io/react/bl [...] ction.html

On avait testé Backbone à l'époque (mi 2013 ?), mais trop « basique » pour nos besoins (c'est là qu'on est passé sur Angular)

c'est clair. Certains trucs basiques comme les vues imbriquées ne sont pas triviaux . Il y a une surcouche ( marionette)  mais ça ne change pas le fond du problème
 
Par contre, il n'y a pas de magie noire à comprendre.

On avait essayé Marionette aussi je m'en souviens
 
Comme quoi, peut être que dans 3 release on sera passé sur autre chose

retrouvé ( pour flux )  https://speakerdeck.com/jmorrell/js [...] -dot-dot-1

 
Thx !

 
Demande aux gars de Netscape ce qu'ils en pensent. Wait...

Je crois que pour XO, on a du le réécrire 4 ou 5 fois. À la 5ème fois, ça a du prendre 0,1% du temps de la première réécriture.
 
Là on a accumulé un peu de dette technique, ça commence à peser, paf réécriture d'un bout du moteur. 10J/H max, perfs x100.
 
Et puis réécrire tout un module != de réécrire toute une appli monolithique

 
Apres qu'il y ait eu des clients qui paient et pris l'argent d'investisseurs ?

Ça change strictement rien (la répone est oui et oui, à des degrés divers)

Et je vois pas bien le rapport. Ça nous change pas un cycle de release et que si c'est justifié (une hausse des performances par exemple, ou une meilleur maintenance), je vois pas en quoi réécrire est un problème. Encore moins maintenant qu'on est dessus à 100%, la charge on la passe dans un délai très court.

Tu peux jamais faire parfait du premier coup, ça évolue trop vite. Ceci dit, pendant nos multiples réécritures, on a pu construire notre architecture, qui elle est stable depuis 2 ans maintenant. L'implémentation est pas parfaite, mais on va au mieux petit à petit.

edit : surtout que réécrire aujourd'hui, c'est réécrire des modules. La dette technique s'accumule pas partout à la même vitesse.

edit 2 : et on est trop petit pour se permettre d'accumuler de la dette trop longtemps, car comme on vend du support, si ça merde, on est vite débordé potentiellement.

Et bien heureusement

(lurkeur)
 
ce qui me fascine toujours dans les discussions JS, c'est la profusion de framework/modules qui tourne autour...et je trouve que meme si c'est surement un luxe, c'est aussi un facteur d'obsolescence des developpeurs et des choses développées incroyables. Toutes les technos évoluent (j'ai codé professionellement la dernière fois en Java 1.4, je suis largué en java aujourd'hui, qqn qui a fait du Python 2.4 aura du mal avec Python 3.4, idem html 4 --> 5 qui apporte plein de choses)...mais sur JS on sent que c'est jeune, et je trouve que c'est un gros frein à l'adoption.
 
Je pense que si on prend les 2 dernières années, si j'avais posé la question chaque 4 mois "quel framework JS", j'aurais eu 6 réponses différentes. Ce qui veut dire que sur un projet de 4 mois, le stack que tu utilises sur ton projet est vraisemblablement déjà plus celui à la mode quand tu finis le projet...et je ne crois pas que ce soit sain. D'un point de vu "décideur", ça me foutrait les boules que notre stack soit en JS parce que ça voudrait dire que tous les 6 mois, j'aurais les devs qui viendraient la gueule enfarinée m'expliquer qu'il faut tout réécrire. Je caricature bien sur, mais ça doit etre un frein certain à l'adoption.
 
Après pour le débat sur framework modulaire vs framework "qui te guide", le débat existe sur tous les languages :
Python : Django vs Flask
Ruby : Rails vs Sinatra
Java : (le descendant de Spring/Struts/etc...) vs des framework light genre Spark
 
c'est pas propre à JS

En JS, ya bien deux notions différentes maintenant.

Le côté client, où l'écosystème des framework évolue beaucoup et s'améliore (avec ce que ça entraîne, après rien n'oblige à en changer hein !)

Et sur le côté serveur : Node n'est pas un framework

Donc je pense que ça « brouille » un peu les cartes. JS c'est tellement vaste aujourd'hui...

ouais, tenir une stack JS super fiable ca demande plus de travail que tenir une stack java.
une lib "classique" genre hibernate, suffit de chercher un equivalent en js pour comprendre...
il y a des ORM qui remplissent les memes fonctionnalités *dans les grandes lignes*, sequelize + redis par ex mais on est pas encore au meme niveau.

Je suis d'accord et je pense que ça illustre parfaitement le problème.

Chercher un pur « équivalent » exact en lib JS à la place d'une stack Java c'est faire une grave erreur et après venir dire que « JS ça va pas du tout ». Combien de fois j'ai entendu « Linux c'est de la merde je peux pas télécharger des logiciels sur Telecharger.com et les installer comme j'ai envie ».

Pareil avec SVN vs Git. C'est juste autre chose. Et ça va pas toujours convenir à tout le monde (et sans jugement de valeur aucun, chacun son truc !)

edit : c'est juste my 2 cents

 
Et c'est surtout lié à l'explosion du web comme plateforme. Firefox et Chrome ont permis une évolution, la taille des marchés accessibles, le nombre de développeurs impliqués.
 
C'est très clairement jeune et pas mature ( quand je compare la qualité des outils pour debugger sous VS en 2008 quand j'ai arrêté avec ce qui se fait aujourd'hui dans les navigateurs, ça fait marrer ).

 
Si on parle côté client, c'est pas non plus la même complexité...

ca depend ce qu'on demande coté client.
coder dans du canvas ca ressemble quand meme beaucoup a faire une applet, que ce soit en pur ou via des libs type processing.

je parlais d'ORM, j'étais pas assez clair.

Question SEO / Webmaster tools : Google me dit que j'ai une sérieuse augmentation de 404, sur ces URLs :
 
http://www.domain.tld/produit/00000,  
alors qu'elles n'ont jamais existé, jamais étés déclarées, elles sont de cette structure :
 
http://www.domain.tld/produit/00000/slug-slug-slug
 
J'imagine donc que google considère que http://www.domain.tld/produit/00000 doit exister (repertoire ?).
 
Je me fais impacter en positionnement avec de telles erreurs ?
 

 
 
 
on voit debarquer des ORM light pour tout ce qui est approche MVVM. Ce qui semble faire sens en js
 

 
Ce "faire sens" qui revient tout le temps maintenant... Parlez carrément anglais, ce sera mieux (je vis en Angleterre).

je mets ca dans le meme panier que *meilleure journée toujours* que j'utilise aussi regulièrement  

au jour d'aujourd'hui

 
Non.
 
Tu dois être capable de trouver sur quelle page un lien pointe sur cette URL ( ou verifie ta sitemap )

 
Ha mince, je viens de voir que webmaster tools m'indiquait ou ce lien était listé, et en effet, j'ai un bug dans une vue qui me pourrit certains liens    
Merci j'ai pu corriger  

Je t'invite aussi à créer une redirection pour corriger le problème

 
Au hasard, la sécurité. Si t'as choisi une lib qui n'est plus maintenue par exemple.
Je me faisais la me remarque que Jubi récemment. J'aimerais pas être dev JS en ce moment. Ca bouge trop vite pour être à jour sur le marché. Les technos backend sont bcp stables dans le temps de ce que je peux constater depuis 15 ans en tout cas.

 
+1, il est très difficile de suivre et encore plus difficile de savoir ce qui sera maintenu ou non. Il y a des effets de mode dans tous les sens. Je crois en npm car c'est un bon moyen de maintenir ses libs sous forme de packages. Je continue à utiliser jquery parce que ça a peu de chance de disparaitre et les updates sont raisonnables, ne remettent pas toujours tout en question. Quand on voit ce qui se passe avec Angular, je trouve que ça fait peur. Et quand on voit ce qu'en pensent certains contributeurs, je trouve que ça fait encore plus peur : http://eisenbergeffect.bluespire.c [...] gular-2-0/
 
Je trouve angular très bien, mais je trouve la V2 brutale et ne donne aucune garantie de pérennité. Et là, on parle que d'Angular qui est une des libs les plus utilisées et qui a le plus de chance de survivre.
En ce qui me concerne, je ne vois pas bien l'utilité d'utiliser encore un nouveau truc au niveau backend, parce que PHP est mûr, Python et Ruby aussi. C'est quoi le vrai but dans tout cela ?

 
j'ai fait répondre mes pages /produit/90200 à /produit/90200/slug, et mis un canonical vers /produit/90200/slug, sans 301 du coup.
 
Il faut préférer quoi ? la 301, ou le canonical ?

 
C'est excitant de voir l'évolution, c'est sympa de se challenger, ca justifie des $$$

 
Alors qu'avec Ember, le message a été clair dès le début : on se donne le droit de tout péter jusqu'à la 1.0, après c'est SemVer.