Reprise du message précédent :
et un truc tout con ou tu detectes les possibilité du client au chargement du template?
tu lances une requete $.getJSON que tu tentes de decorer et d'inclure puis tu check le rendu.
 
si ca colle pas tu sais que tu es en mode merdique et ta factory te retourne un mode DOM, genre au lieu de $.getSON() ca te fera des $.load() avec les urls qui vont bien.

Tu ajoutes un header à tes appels de données. Le serveur se démerde à te renvoyer au choix : une page complète, un bout de DOM ou du json. Ou du XML. Ou du WTFSONML3.59a.

Ouais mais ça se trafique les headers aussi.

Sinon, autre question : j'ai fini mon bidule qui fait bouger des petites bulles (finalement j'ai foutu ça dans un canvas).
j'ai foutu un listener sur mousemove, ça me detecte bien si ma souris est sur une bulle quand je la bouge (et ça stoppe l'anim)

MAIS : si je fous la souris sur le canvas en dehors d'une bulle, et que j'attends que la bulle arrive sur la souris, ça declenche pas l'event (normal, c'est du move)
mouseover ne fonctionne pas, ya-t-il d'autres solutions ?

le fiddle quivabien : http://jsfiddle.net/6jab13tb/
merci

Euh, moi ca stoppe l'animation des que je bouge la souris n'importe ou dans le canvas.

oui mais non, un client va modifier ton header .... et après ? il se bug son front lui meme en ne pouvant pas l'afficher ...
Les headers ca s'utilise. Sinon ca existerait pas. Apres faut pas les utiliser n'importe comment en gardant en tete qu'ils contiennent des données pas forcément fiable (donc on fait gaffe avant de les utiliser aveuglement pour gérer des contraintes de sécurité par exemple)

Oui normal je dois encore optimiser la routine qui checke si le pointer est sur une bulle.
Là pour l'instant à chaque move de souris ca parse le tableau des bulles pour checker leurs positions.

C'est tout l'intérêt? Le client demande le content-type qui l'intéresse, s'il est pas foutu de le gérer il est con et c'est tout.

Foundation 6    
 
https://github.com/zurb/foundation-sites-6

C'est compréhensible ? pour publier sur linkedin

Angular1 a eu , et a toujours une énorme traction : beaucoup d'utilisateurs, beaucoup de projets, et surtout un énorme écosystème de librairies et d'outils

Mais cela ne doit pas cacher les difficultés que rencontre une équipe pour produire une application Angular de qualité : compréhension et optimisation du $digest (détection des changements), chemins différents d'implémentation (directive ou controleur ?) , notions faciles à mélanger (factory, service), intégration dans une application isomorphique ou universelle.

Angular2 pose les choix de manière très différente. Voici un petit tour d'horizon des éléments clés, tels qu'ils sont aujourd'hui.

Attention, Angular2 est encore en alpha, certains éléments vont forcement bouger.

Tout est composant
Une application doit être découpée en composants, héritiers  des directives d'angular1 et de polymer. Ces composants indépendants  peuvent directement embarquer leur feuille de style et leur template. L'api publique d'un composant est définie explicitement par ses input/output, son fonctionnement interne est clarifié avec les événements du cycle de vie.

Détection des changements
Dans Angular1, il fallait utiliser $scope.$apply (ou des méthodes qui l'appellent, comme $timeout) pour indiquer qu'un objet avait changé.  Angular2 utilise zone.js pour détecter ce qui à changé automatiquement. L'intégration de librairies tierces est donc largement simplifiée

Découplé du DOM
La partie rendu est découplée de la partie calcul, avec deux objectifs: rendre trivial le rendu côté serveur et permettre un rendu multi processus côté client avec un webworker.  Ca me fait rêver à une approche à la React native, avec des renderer natif android, ios ou même console

Le Routeur
Seul composant qui devient plus complexe, il devient aussi plus puissant. Largement inspiré de ui-router, il intègre directement la gestion de routes asynchrones et la gestion d'état.

ES6/Typescript :
Il est possible d'écrire des applications Angular2 en ES5, mais je vous conseille largement de mettre en place un processus de build pour écrire du code gérant au minimum les annotations et la gestion des modules puis de le transpiler vers ES5.
Pour en savoir plus

• Le site officiel : https://angular.io/
• Si vous ne devez lire qu'un article :  http://victorsavkin.com/post/11837 [...] -angular-2
• Le routeur : http://yakovfain.com/2015/11/02/an [...] -overview/
• Documents de designs d'angular2 : https://drive.google.com/folderview [...] 5pVUk#list
• Les intros par firebase et de ionic
• comprendre en profondeur zone.js : https://www.youtube.com/watch?v=3IqtmUscE_U

comprendre le routeur en créant  une application angular2 avec de l'authentification : https://auth0.com/blog/2015/05/14/c [...] n-between/

Merci

Yep, modulo quelques mini typos (une double espace par ici, une phrase un peu maladroite à la fin du « Découplé du DOM », et probablement de mettre tout ça en syntaxe MD avec un joli rendu).

Tu peux t'ouvrir un Ghost Blog et poster ensuite sur LinkedIn l'URL (et surtout caler un analytics derrière déjà )

Je pense que pour le premier, je vais le publier directement sur linkedin. Ensuite je vais monter blog.stri.im , mais faut que je vois avec mon co propriétaire de nom de domaine

C'est juste que j'trouve qu'avec bon un rendu depuis un MD, tes noms de méthodes et autres ressortent super bien
 
Après je connais pas la syntaxe dispo sur LinkedIn

Hello!
 
petite question JS
 
 
Je me suis fait un JS (en procédural forcément, étant novice), où j'ai mis au début un var debug = true/false. Si debug est à true, alors j'affiche des messages dans la console. Sauf que je me retrouve avec plein de if(debug){console.log("machin" ); } dans mon code.. Il doit forcément exister une manière + élégante de faire ça ?

 
 
Et dans ton code, t'utilise MyLog(msg);

Heu, c'est pas top top comme fonction
 
Déjà ne pas utiliser console.log.apply(this, arguments), tu perds bcp de cas/utilisation...

Lol le switch et en plus les appels qui limitent le nombre d'arguments
 

lol oké

Je vais regarder ça
 
Merci  

pour éviter les "if" en cascade tu peux faire :

Tu vas pas faire ça à chaque call de myLog...

S'il veut éviter les if en pagaille, il peut. Mais le "meilleur" moyen reste d'appeller la fonction et de la quitter ou non en selon l'état de debug.

Le meilleur serait d'avoir un code moins monolithique, des tests unitaires, et utiliser des Points d'arrêts pour débugger son code (ou le mot clé "debugger" )

comment tu peux inferer ca avec le peu de code presente ?
 

bien que debugger "proprement" (et pas a coup de log / printf) est extremement important, il ne faut pas pour autant negliger le logging (a tous les niveaux).
 
En theorie, c'est a ta logging library de filtrer les messages qui ne sont pas au "niveau" de logging que tu desires. Un flag de debug - en plus de polluer ton code - te force a un choix binaire alors que la majorite des libraries de logging ont evoluees vers un controle par niveau (ce qui laisserait sous entendre un certain consensus ).
 
Dans le cas du JS - a ma connaissance - et du console.<bla> "natif", le "filtrage" se fera essentiellement lors de l'affichage de ta console / de tes logs ou tu peux selectionner quels types de messages tu veux afficher.

Tu peux aussi greffer des trucs plus évolués qui vont reporter au serveur les messages d'erreur.

https://github.com/bengillies/ember [...] arallel.js
 
https://github.com/adambom/parallel [...] ib/eval.js
 
'tain y'a des gens qui sont forts, ça a zéro % de chances de tourner dans une sandbox et ça lance un worker à chaque update de propriété sans buter le précédent.
 
Je me sens seul à vouloir faire du multi-thread sérieux en JS

 
 
Je mets pour la première fois une app Node en prod autre part que sur heroku, c'est quoi les trucs à faire et à ne pas faire ?
Je viens de voir PM2 (https://github.com/Unitech/pm2), vous connaissez d'autres outils du genre ? Indispensables selon vous ?
 
Merci  

pm2 est indispensable.  
Il vient ten plus avec quelques bonus , comme pm2 monit, ou la possibilité de lancer plusieurs app avec une seule ligne de commande

Chez nous c'est systemd (et pas système D ) mais c'est parce que notre app tourne que sur un seul nœud et n'a pas vocation à scaler horizontalement (appliance chez le client, on fait pas du SaaS)

Comme Node à une facheuse tendance à se terminer en cas d'exception, dans tous les cas il te faut un truc pour remonter automatiquement (systemd le fait très bien par exemple, même s'il est pertinent dans un cas d'un seul nœud encore une fois )

Ha je connaissias pas pm2 merci

On tourne uniquement sur forever en ce moment en prod

Votre camp : Framework ou vanilla http://aerotwist.com/blog/the-cost-of-frameworks

moi c'est comme toutes les libs, ça me fait chier de rentrer dans le système de quelqu'un d'autre, mais c'est toujours l'équilibre implémenter maison/trouver sur le marché.
Donc j'ai pas de position définitive, mais c'est clair qu'il faut passer sa vie à naviguer entre les lubies des uns et des autres quand on prend des libs externes (parce que t'as pris 2 libs de 2 devs avec des lubies différentes). Et surtout cette tendance des mecs célèbres dans l'open-source à être arrogants et polarisés avec leurs manières de faire.

Ca dépend, s'il faut pondre un poc avec des lists, du bordel, des vues qui communiquent à mort avec le model, je sors angular parce que j'ai un truc à poc tout près.
 
Si c'est un petit poc à la bite et au couteau, je sors zepto en mode modulaire (je ne prends que ce qui m'intéresse) pour la communication vue/model je gère un peu à la mano.

le site devox 2016 : 10Mb  
Sympa pour un site d'experts

 
Vanilla le plus possible. Le dev frontend ressemble de plus en plus a un mille feuilles ou le dev se contente d'utiliser des outils qui font des trucs magiquement, et j'aime comprendre toute ma codebase. Ca, et la possibilite de reprendre un dev abandonne depuis 6 mois sans devoir migrer les libs ou les reapprendre.

ça marche que quand tu fais des trucs simple, mais j'ai beaucoup d'exemples où tu peux pas tout mettre dans ta tête.

 
Je me demande si repasser sur du client lourd pour les cas complexes ne serait pas une bonne idée.

 
Je ne construis pas de "sites web", mais des applis qui fonctionnent dans un browser.
 
Du coup, un framework m'apporte plus que de ne pas en utiliser un.

 
Je ne suis pas sûr que ce soit propre aux mecs de l'open source
 
Et comme souvent, on ne retient que les plus vocaux.

Non vraiment, ne serait ce que pour les problématique de déploiement / mise à jour

 
Si au moins c'était pour un truc qui claque, mais même pas, il est aussi complètement dégueulasse.