Podcast: Téléchargement
Dans ce tout premier numéro, @fXzo, @antoined et Seb nous parlent de Single Page Applications.
Frameworks MVC Javascripts
Environnements de dev
- Yeoman,
- WebStorm (IntelliJ)
- Eclipse + Plugin WTP ou Aptana
- Cloud9
- Sublime Text
- Debug avec Angular Batarang
Push server vers client
- Websocket
- Server Send Events
- Comet
- Encapsulation des technos de push : Atmosphere ou SockJS
- NodeJS & Socket.io
Les frameworks front-end
Le Gist de l’épisode
WebSocket Angular service : https://gist.github.com/lrvick/5134870
Bravo pour cette nouvelle émission. Il y a peu de podcast de dev en français.
Le sujet est bien construit. La comparaison des frameworks MVC m’a beaucoup interessé car je n’ai jamais eu le temps de tous les tester, mais je suis aussi déjà tombé amoureux d’angular js.
En espérant vous retrouver « tout soudain » et régulierement.
Ah et juste pour le mini troll sur vim Fabrice, je te conseille l’excellent http://vimgolf.com/
Merci pour les encouragements
Un lien intéressant sur Angular.js (vs Ember): http://eviltrout.com/2013/06/15/ember-vs-angular-its-not-even-close.html
Cool! moi je suis pas dev. mais c’est toujours intéressant comprendre un peut plus le monde des dev! merci excellente initiative…
Sympa le podcast!
Un bon comparatif des frameworks JS MV*
http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/
Merci ! J’espère que je n’ai pas trop dit de bêtises sur Node.js 😉
Non t’inquiète 😉
Merci pour ce podcast d’excellente qualité 🙂 Dommage que vous ayez occulté Knockout.js qui est de bonne facture, et toute la suite Kendo UI qui apporte une pléthore de composants graphiques. La partie sur le push est vraiment sympa, on a toujours peu d’informations dessus. A bientôt en tout cas !
Oui on a occulté pas mal de framework Javascripts, mais on ne les a pas tous testés.
Je post au fil que j’écoute :
Quel est la différence entre SPA et du web 2.0 (ajax and co) ?
Quand on y réfléchit, c’était la volonté de Mozilla depuis quelques années avec XUL 😉
Ce qui me fait peur avec les outils de compilation javascript comme GWT c’est les erreurs javascripts qui peuvent être rencontrés:
on a écrit du java, c’est du javascript qui est exécuté et les erreurs vont concerner le javascript 🙁 Comment déboguer ce genre de projet ?
Le pas à pas n’est pas une réponse à 100%: ça l’est en mode « développement » mais pas en mode « production » , où l’utilisateur a un soucis, il a tel erreur avec tel contexte, et la il est plus difficile de faire du pas à pas 🙁
Alors que si on a codé le javascript, on aura juste besoin de l’erreur pour simplement aller voir le soucis 😉
Je suis plus pour les frameworks javascript (jQuery,Mootools…) dans ce cas la 🙂
Un autre soucis: l’intervention d’un autre développeur (astreinte/vacances) qui pourra plus facilement corriger un soucis full javascript qu’un soucis sur du GWT: il lui faudra installer la librairie, paramétrer un IDE… + se former en urgence pour éviter d’avoir à nous appeler en vacances pour intervenir.
A quoi ressemble le code javascript compilé ? peut-on éventuellement intervenir directement dessus ou c’est comme le code perl généré par Talend (ETL) ?
J’entends beaucoup parler de json/ajax… mais QUID de la sécurité ? du xss/xsrf/sql injection… ?
Pour l’exemple de la todolist, mise à jour chez tout le monde, jetez un coup d’oeil sur APE qui permet de faire du push Ajax 😉 : http://www.ape-project.org/
Vous en parlez après avec COMET 🙂
Merci pour le PodCast ! Petit retour au fil du stream.
Je travaille depuis +10ans sur un outil CMS, Portail, RSE, Web collaboratif, noSQL a mettre en oeuvre de nombreuses techno front/back grands comptes.
Au final on a fait le choix de ne surtout pas faire du SPA car ce sont des solutions d’informaticiens BackEnd qui veulent gérer le Front. Alors que le Front web est gérer par des métiers d’ergonomes, graphiste, webdesigner, etc, … qui n’ont pas la même démarche.
Lors de DevoxxFR, le DG de Zenika ? Zenexity ? avait taclé GWT. Et je suis 100% d’accord car c’est une surcouche pour « ne pas apprendre » qui impose des choses…
Heureusement les choses vont dans le bon sens avec Bootstrap, et les technos DOM Shadow / WebComponent qui viennent améliorer/enrichir le web. AngularJS est un premier pas.
Je n’inclus pas BackboneJS qui est une fois de plus trop MVC ! Vous ne pouvez pas demander à un WebDesigner d’aller coder des centaines de ligne de code (et des test unitaires) pour intégrer une charte.
(Dans notre produit nous utilisons depuis 8 ans Ajax-Refresh une techno proprio mix entre les logique de Bootstrap et Angular)
Il est effectivement possible de faire d’excellents site non SPA. En même temps, de mon point de vue c’est avec cette techno qu’on obtient un maximum de fluidité et les meilleures performances perçues de la part des utilisateurs.
A propos de ce point, prévoyez-vous un mode « sans js » ?
Autant en intranet, on peut imposer un navigateur et le fait d’activer javascript, autant sur le net , on ne peut pas imposer à certains clients de mettre à jour leur navigateur / politique vis à vis du javascript (oui certaines sociétés désactive javascript des postes clients 😉
Le problème avec le mode sans js c’est… qu’il n’y a pas de js. Il faudrait prévoir une version de l’appli avec génération des pages HTML statiques sur le serveur ce qui est assez lourd. On pourrait imaginer que GWT prévoit ça mais je ne sais pas.
C’est vrai, sans JS une SPA ne sert à rien ! Et offrir une appli « html classique » en plus d’une SPA revient presque à faire deux fois le travail.
Il faut bien cibler la population d’utilisateur. Même si je suis d’accord, cela existe, je n’ai jamais rencontré de client où la contrainte était « js off »…
Et je pense que cela est encore plus vrai sur Internet : l’utilisateur qui utilise son navigateur avec JS désactivé se prive quand même de nombreux services…
Donc pour des applis orientée grand public, sur Internet, je pense qu’on peut considérer que la population avec JS désactivé est minime. Pour une appli interne, effectivement cela fait parti des contraintes dans certains cas. Dans ces situations, pas de SPA, à moins d’accepter de maintenir 2 applications en parallèles.
PS : La nouvelle version de Spotify dans le browser, https://play.spotify.com, est un bel exemple d’une SPA !
J’ai cliqué le bouton vert sur Chrome iPad. C’est du Hard Core Responsive 😉
Pour les clients « sans Js » ils ont peut être changé de politique entre temps (ça date d’une dizaine d’années quand je bossais en agence de pub)
Par contre 3 questions:
1. Qu’en est-il de la sécurité: vous parlez json,ajax and co, mais comment vous protégez-vous du Xss/Xsrf/sql injection… ?
2. qu’en est il également du référencement ? la plupart des sites de ce type ont des urls non référençables ? passer par un robots.txt avec des pages statiques ?
3. Dans mon premier commentaire je fais le parallèle avec XUL de mozilla, qu’en pensez vous ?
Bonjour Mika,
1. Pour la sécurité, le SPA ne change pas grand chose à la règle. Comme toujours, il faudra eviter les contrôles sur le browser et les concentrer sur la partie serveur. C’est lui qui a le dernier mot au final.
2. Pour le référencement, les robots de Bing et Google savent de plus en plus interpréter le code JS et identifier certaines requêtes de type Ajax.
Sinon HTML5 propose PushState pour permettre de s’affranchir du hashbang (#!) dans l’URL. Par exemple, « www.example.com/#!categorie/item/1 » devient « www.example.com/categorie/item/1 ».
Ca marche très bien avec backbone.js et un navigateur récent. Je n’ai pas eu l’occasion de tester avec les autres frameworks.
Il y a un très bon article à ce sujet sur le blog de ippon si cela t’intéresse 🙂
http://blog.ippon.fr/2013/06/07/resolvez-vos-problemes-de-hashbangs-grace-au-pushstate-en-html5/
Ok pour la vérif coté serveur pour l’sql Injection, mais comment gérer vous le xsrf /Xss?
vous n’avez pas peur d’une modif Xss qui modifierai un lien destinataire d’une requête AJax ?
Vous faites des innerHtml/ajout au dom sans vérifier le contenu json ?
Je ne sais pas s’il existe des protections contre le Xss embarquées dans les frameworks SPA.
Par contre si tes requêtes Ajax se font sur ton serveur, alors là tu peux contrôler en amont le contenu que tu vas renvoyer au navigateur.
A l’inverse, si tu tapes sur l’API REST d’un serveur tiers directement depuis le browser, tu n’as plus trop de choix : tu dois lui accorder une confiance aveugle (pas top).
Pour ma part, je vois une SPA comme un client opaque qui vient taper sur une liste de services REST que j’expose depuis mon serveur. La logique métier et les contrôles restent coté serveur. La SPA n’est là que pour mettre en forme les données et offrir un confort de navigation à l’utilisateur.
Pour le Xss, il me faudrait une application d’exemple pour vous montrer les potentiels failles en question
Et concernant le Xsrf ?
On pourrait plus facilement faire du DDOS sur une SPA,non ?
Pour le cas Xsrf/Csrf sur les ASP, il y a un paragraphe sur le site d’OWASP
http://open.bekk.no/owasp-top-10-for-javascript-a5-cross-site-request-forgery-csrf/
Et pour le xss:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.233.1_-_HTML_escape_JSON_values_in_an_HTML_context_and_read_the_data_with_JSON.parse
Google fournit des précos lorsque ton site est une SPA : https://developers.google.com/webmasters/ajax-crawling/docs/getting-started?hl=fr
J’ai découvert, il y a peu, une entreprise fr qui s’occupe de cette problématique, et qui fonctionne plutôt pas mal (je l’ai testé sur mon site app.voxxr.in) : http://seo4ajax.com
Son principe : ils utilisent un crawler PhantomJS qui va va crawler toutes les pages de ton site et, sur chacune d’elle, attendre que la page ait fini de se charger (plus de requête AJAX en cours) et va enregistrer le contenu HTML ainsi généré.
Tout ce qu’ils demandent ensuite de mettre en place, c’est un petit proxy qui va regarder si le query param _escaped_fragment_ est présent (google bot) et, dans ce cas, qui proxifiera la page HTML « brute » mise à dispo par seo4ajax qui sera alors correctement indexée par le crawler google.
Je trouve cela plutôt malin 🙂
+1 effectivement c’est une bonne idée 😉
note: comment il sait si il doit ou non « cliquer » sur le lien (pour eviter de soumettre 36 fois un formulaire 😉
Je doute fortement que le crawler (aussi bien googlebot que seo4ajax) soumette des formulaires (imagine sinon, si tu vérifies rien, le bot te remplit ta base à chaque indexation :-D).
En fait, googlebot est pas très malin : il ne fait que chercher les liens dans ton html (uniquement les <a href>) et derrière il fait une requête sur l’url ciblée (en remplaçant éventuellement les hashbang #!xxx par un ?_unescaped_fragment_=xxx lorsque le href commence par un #!) … et ainsi de suite.
Rien de plus.
Ce qui sous-entend que si tu fais une navigation « en javascript » (a coup de binding de l’évènement « click » sur tel ou tel élèment du DOM), ta page cible ne sera pas indexée.
Je comprends mieux: ca ne marche que sur un type de navigation, dommage 🙁
Note: je ne suis pas très au fait des SPA en général, mais je pensais que les boutons / liens étaient plus du genre href= »# » onclick= »appelMaFonction();return false » 😉
Note2: quand je parlais de formulaire, je ne parlais pas forcément de bouton submit mais de liens qui émettait une requete ajax vers une partie serveur mettant à jour des données en base:
Non généralement les SPA sont justement en href= »#mapage » pour 2 raisons :
– Première raison évoquée précédemment : ça rend le site crawlable (à condition de respecter les préco de google et de signifier que le lien est un « lien de SPA » avec un #! … pour les différencier des liens vers de simples « ancres » qui n’auront pas vocation à être indexées). Imagine-toi que si le crawler de google devait attendre que « toute la page soit rendue » (ie toutes les requêtes ajax sont parties et revenues, requêtes ajax « séquentielles » incluses), ça multiplierait énormément le temps de parsing d’une page par le crawler (il serait plus souvent en attente qu’en réel parsing de la page).
– La seconde raison, et non des moindres, est que cliquer sur un fragment d’url (les liens en « #… ») ajoute un step dans l’historique de ton navigateur => en utilisant ce mécanisme, les SPA préservent l’historique et tu peux donc très bien utiliser les boutons back/next de ton navigateur pour te déplacer dans cet historique
Ta note 2 explique justement très bien la raison pour laquelle les crawlers ne simuleront jamais un « clic » sur les liens (pour exécuter le JS derrière) : sinon ils seraient vus comme des web bots potentiels qui viennent spammer les données de ton site. Ils se cantonneront toujours à uniquement « suivre » les liens présents dans ta page, sans jamais exécuter de javascript déclenché sur une action utilisateur.
D’où l’importance, si tu veux un bon SEO, de privilégier largement les liens « standards » que la navigation par JS.
Je vous remercie de votre réponse, comme je l’ai dit je ne programme pas de SPA c’est un autre monde pour moi 😉
Je fais au plus proche du javascript/ajax voir un peu d’html5 pour mes besoins perso 🙂
note: je suppose que dans les frameworks SPA, il y a une partie qui parse ces URLS particulières pour appeler les bons controlleurs 🙂
Un épisode sur le fonctionnement des SPA serait le bienvenue, une sorte de « zoom sur «
C’est tout à fait ça : je ne connais pas bien les rouages internes d’Angular mais sur Backbone, tu as une méthode (Backbone.history.start()) à appeler au chargement de ton application, qui se mettra en « observation » sur les changements de fragment de ton url, et déclenchera alors un appel de ton routeur qui s’occupera de router vers le bon controleur 🙂
C’est très intéressant comme fonctionnement 😉
Je suis toujours étonné de voir des entités repenser à partir d’un existant « fini » une nouvelle piste d’exploitation agrandissant ce champ des possibles 😉
Depuis plusieurs versions nous n’avons plus de mode « sans js » que ce soit Intranet ou Internet
1. Car en terme d’accessibilité le poste client est super équipé (cf. plusieurs conf ParisWeb)
2. Car le JS devient indispensable pour avoir des interfaces riches
Mais :
1. Pour un client, qui doit gérer les très fort pic on a un mode « strip to the bone »
2. Avec une approche HTML « amélioré » par le JS (à la bootstrap) on est pas pénalisé par un JS cassé, etc, …
Pour le responsive design, personnellement j’utilise une redirection avec une directive de redirection en fonction du paramètre HTTP_USER_AGENT, j’ai donc deux sites : l’un très épuré uniquement en version mobile, dont certains contenus (certains jeux) ne sont pas disponible (car non prévu pour du tactile) (le site de prévention en question: http://supercapote.com)
Pour l’editeur, personnellement j’utilsie geany, j’avais fait un article sur ses points forts: http://dupot.org/post-14.html
Pour info, je suis habitué à travailler sur plusieurs projets en même temps, donc le fait de pouvoir l’instancier une fois par bureau est tres pratique 🙂
Dans chrome: F12 🙂
Merci pour les infos et l’éditeur que je ne connaissais pas. Le HTTP_USER_AGENT est effectivement une solution qui nécessite de bien synchroniser les évolutions des front-ends, surtout quand on fait évoluer l’API serveur.
Oui et non: on peut prévoir le site pour qu’il soit modulaire: avec les frameworks MVC, on peut même choisir à la volée une vue desktop/mobile 😉
Par exemple, sur mon framework, je propose la notion de « module intégrable », après libre à vous en version desktop d’afficher tous les modules sur la même page et de passer par des onglets pour la version mobile.
Au final vous auriez un seul code lourd derrière, et une déclinaison d’affichages 😉
ps: au fait, comme vous pouvez le voir, votre podcast est une bonne initiative saluée par la communauté dev 😉
ps2: oubliez pas un ptit flux rss, pour pouvoir s’abonner ^_^
http://feeds.feedburner.com/NipDev doit fonctionner normalement. Et il y a itunes aussi
Concernant le Push Serveur, il est important de préciser que les grandes entreprises Françaises sont ENCORE équipée de IE6/7/8
Ce qui veut dire:
– Faire du LongPolling
– Se battre avec les proxy, etc, …
– Faire du Polyfill
Et attention !
– Atmosphère nous à posé des problèmes avec les Serveur d’Appli « industriels » WebSphere/WebLo …
– Et le Long Polling n’est pas magique et va maintenir donc bouffer des connexions ce qui rends le serveur bancale si il y a plein de vieux navigateurs.
C’est très juste. Les entreprises qui sont encore en IE<=8 ne sont pas celles en pointe de l'innovation 😉 Elles ne pensent même pas à développer des applications réactives. C'et surtout dommage pour les utilisateurs internes qui ne peuvent pas profiter de ces possibilités sur les appli qui le proposent.
En fait si, nous avons de nombreux clients qui veulent des « nouvelles technos » mais :
– Avec un environnement IE6-9
– Avec du websphere / weblogic
En fait c’est très politique, ils ne peuvent pas renouveler leur parc car ils ont des applis métier hard codé pour IE.
Bref, obligé de bien cibler ce qui est possible ou pas.
Concernant le Long Polling, des technologies réactives côté serveur (non-blocking IO) permettront de limiter la charge sur le serveur (et éviter d’avoir un thread inutilement occupé pour chaque requête « en attente » sur le serveur), même si le problème des connexions ouvertes demeure.
Netty par exemple pour un serveur NIO
Bonne vidéos avec une progression pas à pas pour apprendre Angular.js : http://www.egghead.io/
Quand vous dites en début d’émission que Angular est un pas vers l’évolution du web vers des normes plus dynamiques, je vous suggère de regarder ici : http://x-tags.org/ et http://www.polymer-project.org/
Merci c’est intéressant en effet
Nous avons oublié de mentionner l’excellent TODOMVC http://todomvc.com/ Ce site propose l’implémentation d’une application de TODO avec la quasi totalité des frameworks disponibles. Cela permet de comparer sur une application simple. Autre sujet dont on n’a pas eu le temps de parler : la modularisation avec require.js. http://requirejs.org/
Ce sera pour une autre fois
Effectivement ‚ il faut en garder sous le pied pour tenir la distance.
Bravo pour cette première tentative.
Tiens un nouveau podcast à découvrir, je pense l’écouter ce soir. Sinon, il y a une faute de frappe dans le lien vers le flux RSS du podcast dans le menu à droite (pas de t à la fin)
Intéressant ce nouveau podcast! Quelle va en être la fréquence? En tous cas j’espère qu’il durera longtemps, bon courage à vous et merci!
On va essayer toutes les 2 (ou 3) semaines.
Il y a un problème dans le site : a droite le lien vers le rss de nipdev amène vers nipdevT (et feedburner connais pas ^^)
excellent podcast merci
personne n’a encore mentionné Meteor ( http://meteor.com ), c’est pourtant le second framework le plus populaire d’après l’article déjà cité ( http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/ )
une phrase de l’article qui résume bien Méteor:
« Crazy amazing framework from the future, barely reminiscent of anything you’ve ever seen (except perhaps Derby) »
C’est parce qu’on ne connaissait pas. Merci pour l’info je vais regarder.
il y a une erreur dans le liens rss
http://feeds.feedburner.com/NipDevt, le t est en trop.
C’est corrigé normalement
belle performance. Un podcast sur le dev est vraiment casse-gueule ; vous-vous en êtes bien tirés !
Après avoir tentés d’autres podcast sur ce thème, j’ai souvent été déçu et je n’ai pas poursuivi les écoutes car il est dur de parler de sujets souvent assez visuels (le code, ça se lit comme un roman 😉 ).
J’aime bien certains webcasts d’Octo ou Xebia car il y a souvent un petit support powerpoint qui rend l’écoute plus dynamique ; malheureusement, on ne peut pas les regarder le matin dans sa voiture pour aller au bureau !
Si je devais me lancer dans une proposition : traiter moins de sujets par podcast (dans le pilote il y en a à peu près 3 ou 4 qui mériteraient un épisode) ; avantage, le podcast est plus court et plus digeste ; cela vous laisse des cartouches pour les suivants (un format de 30 max me parait pas mal).
Et pour une approche gamification : proposer un challenge ou un quizz en fin d’épisode sur le sujet abordé.
Encore bravo pour ce pilote.
Je suis d’accord avec toi sur le fait de traiter moins de sujets mais plus en profondeur. En même temps pour un épisode 0 c’était pas plus mal de faire un survol global je pense.
En revanche je ne suis pas pour le quizz. Le podcast « The Walking Web » fait ça et je trouve assez ennuyeux. J’ai l’impression que ça n’amuse que les podcasteurs (et encore je ne suis pas sûr…)
Merci pour ce premier podcast Nipdev !
Merci pour vos encouragements. C’est vrai que même en restant centré sur un thème (ici les Single Pages Applications), on s’aperçoit qu’on pourrait consacrer plusieurs émissions en creusant certains sujets. Je pense qu’on fera un petit sondage après 3 ou 4 émissions pour se recalibrer en fonction des résultats.
Hello, j’ai loupé le lien de la vidéo de le SPA avec angularJS, de la page statique à la page dynamique, a t-elle été diffusée ?
J’adore les nipPodcast et ce nouveau venu, nipdev, est sympa à écouter ! Je les écoute en différer…
Une petite réaction à ce podcast : Pour moi, le meilleur outil de développement pour HTML/CSS/JS c’est Firebug dans Firefox. De loin le meilleur.
A bientôt !
J’étais un grand fan de firebug pendant longtemps mais je lui préfère maintenant le Developer Tools de Chrome encore un peu plus ergonomique à mon goût.
En fait c’est logique : le développeur principal de firebug est passé chez Chrome il y a deux ans
Source: http://www.journaldunet.com/developpeur/client-web/le-createur-de-firebug-passe-chez-google-0711.shtml
Ca fait un moment que je n’ai pas utilisé firebug. A une époque je trouvais qu’il faisait souvent planter mon firefox. J’utilise maintenant l’outil de dev natif de firefox qui est devenu assez complet. Les nouvelles versions de firebug apportent-t’elles beaucoup de choses que firefox ne fait pas de façon native?
Pour ceux qui sont curieux de « voir » une stack js se monter en intégrant du tooling et quelques librairies JS, j’ai donné un talk de 3h (université) à DevoxxFr cette année, qui est disponible gratuitement sur Parleys :
http://parleys.com/play/5171549ee4b0b4a14e5f7289/chapter0/about
http://parleys.com/play/5171936ee4b0b8f57dc3bbd6/chapter0/about
N’hésitez pas à aller y faire un tour, j’y parle notamment de Yeoman, Sass, Bower, RequireJS, Handlebars, BackboneJS, Rivetsjs 🙂
Félicitations pour ce nouveau podcast. Le premier épisode couvre des sujets très intérressants et est riche en information.
Je vois ce genre de podcast comme un moyen pour les développeurs de se maintenir à jour, connaitre l’actualité dev et pouvoir suivre le fil des nouveautés dans un monde ou tous les jours de nouvelles technos emmergent et ou dès lors il n’est pas toujours facile de savoir quels sujets doivent être creusés/étudiés.
Merci et bonne continuation,