Web developper tool de Chrome

Suite au Tweet de Stéphanie Walter j'ai étudiée les vidéos de présentation des différents outils de la Web developper tool de Chrome.

La souplesse d'intervention sur le html et le css m'a séduit.
Les extensions proposées comme Closure Compiler et PageSpeed et expliquées dans les vidéos apportent une complémentarité au produit.
Je la trouve vraiment intéressante au point que je vais abandonner Firebug.

Je ne sais ce qu'en pensent ceux qui l'ont testée mais je suis vraiment bluffé.

Malheureusement, Firebug ne fait plus le poids pour un travail professionnel. Malgré mon affection pour Firefox et sa mission, le manque en terme d'outillage de développement m'a forcé à passer à Chrome (depuis environ 1 an désormais).

Avoir un context dans sa console (choisir le frame d'exécution du code), et la timeline (et tout ce qui s'y relie: profiler, heap snapshot, etc) font vraiment toute la différence. Il y a bien plus, comme la gestion du storage hors ligne, l'émulation de touch events, éditer son code javascript en temps réel... etc.

SBoudrias a écrit :
Malheureusement, Firebug ne fait plus le poids pour un travail professionnel. Malgré mon affection pour Firefox et sa mission, le manque en terme d'outillage de développement m'a forcé à passer à Chrome (depuis environ 1 an désormais).

De toutes façons Firebug fait de moins en moins le poids face aux outils par défaut de Firefox aussi
Mais oui, Chrome est bien plus pratique sur certains aspects.

De toutes façons on finit toujours par utiliser deux ou trois navigateurs, ce qui n'est pas forcément une mauvaise chose.
Modifié par BlueScreenJunky (23 Mar 2013 - 08:38)

Il ne faudrait pas non-plus que ça amène sournoisement à concevoir plus sérieusement pour Chrome que pour les autres navigateurs.

S’ils essaient autant de plaire, ça peut être un bien, mais peut aussi avoir de mauvaises conséquences si des gens se laissent trop happer.

Je ne trouve pas que le produit soit trop orienté. S'il le devenait il suffirait juste d'en changer.

Les développeurs de Chrome ont certainement conscience que cet outil est destiné à une population spécifique dont une partie est déjà familiarisée avec d'autres développer tools.
C'est pourquoi ils tentent de s'imposer en répondant aux attentes d'une communauté exigeante et critique.

J’ai sûrement un biais dut au fait que je crois qu’il y a des limites à ne pas dépasser avec le JavaScript, et qu’on ne fera jamais des applications dignes d’applications natives avec lui et qu’il ne faut pas trop lui en demander, alors je n’en demande peut-être pas beaucoup à une console de développement : juste un inspecteur DOM, un inspecteur des styles actuellement appliqués à un élément et une console d’erreur JavaScript et CSS (et je trouve dommage qu’il n’y ait pas de log d’erreur pour le HTML mal-formé). Je n’utilise quasiment que celle d’Opera, et de temps en temps celle de Firefox, et je suis autant à l’aise si par hasard j’utilise celle de WebKit ou d’IE8, rien ne me manque, sauf un validateur HTML intégré, que je ne comprends même pas comment il se fait que ça n’en fasse pas partie tellement ça devrait être la base de la base pour un navigateur.

D’ailleurs, justement, il y a un validateur HTML dans la console de Chrome ?

Et aussi, Chrome et Chromium sont différents ou pas en ce qui concerne cette fameuse console ?
Modifié par hibou57 (23 Mar 2013 - 11:55)

Bonjour,

avec plusieurs années d'habitude de Firebug et bien bien plus de besoins CSS que JS (ces mois-ci dans une proportion de 100% vs. 0 ), je reste avec Firebug mais si j'ai plus de besoins JS... ouais dew nous a montré des choses bien sympas réalisables avec Chrome

Pour ce qui est des outils internes de Firefox : la partie RWD (Shift-Ctrl-M) est mon quotidien et ce sélecteur de résolution est un énorme gain de temps. A tel point qu'ensuite les tests dans Chrome et IE9 sont Redimensionner à la main une fenêtre et devoir vérifier visuellement quel breakpoint RWD on vient d'atteindre, pfff. Je vais peut-être (ré)installer un logiciel pour le faire quelle que soit la fenêtre tiens !
Modifié par Felipe (23 Mar 2013 - 14:00)

hibou57 a écrit :
je crois qu’il y a des limites à ne pas dépasser avec le JavaScript, et qu’on ne fera jamais des applications dignes d’applications natives

Et pourtant, c'est déjà le cas (Facebook, Twitter, Sound Cloud, Adobe Edge). Sans compte des plateformes OS entièrement construite sur le web et les web applications: Firefox OS, Chromebooks, etc.

Javascript est rarement le vrai problème en terme de performance et s'il pose encore problème en terme d'accessibilité ce n'est pas parce que langage n'est pas accessible, mais parce qu'il y a un manque d'intérêt pour le sujet de la part des professionnels en accessibilité; à part quelques articles vague sur ARIA.
Modifié par SBoudrias (23 Mar 2013 - 22:03)

C’est sûr qu’avec des quadruple cœur à 4GHz (pour faire une image)… La question est aussi dans la maintenabilité. Avec un OS en JavaScript, la limite est largement dépassée, il n’est pas adapté à ça, parce qu’il n’a pas été prévu pour ça, mais pour des petites choses, souvent même vite faites. C’est même pour ça qu’il est non-typé ou qu’il est laxiste avec la syntaxe ou qu’il a un opérateur eval.

Sinon quelqu’un a une idée de pourquoi il n’y a pas de validateur HTML dans les consoles des navigateurs ? Je ne me l’explique pas.
Modifié par hibou57 (24 Mar 2013 - 02:26)

Et pourtant, JavaScript a été conçu pour concurrencer des langages non-natif à la plateforme web comme les Java applets et Flash - qui sont tous deux assez complet.

Quant au fait qu'il soit non typé, ça n’a pas empêché pas d'autres langages largement utilisés sur desktop de se faire une bonne place: Ruby et Python notamment, mais aussi plusieurs autres langages fonctionnel. Et il fait sensation en guise de langage serveur avec Node.js justement parce qu'il réclame moins de ressources que les serveurs traditionnels - alors sur la question de la performance on repassera.

Qui plus est, un appareil mobile a rarement quatre coeurs et ça n'empèche pas de développer des applications entièrement codés en JavaScript avec FirefoxOS, PhoneGap (racheté par Adobe) ou Worklight (produit d'IBM).

JavaScript est un excellent langage de programmation. Il est très éloquent et largement extensible (on peut créer n'importe qu'elle interface sur son implémentation de base, regarde jQuery, AngularJS, Ember, Enyo, YUI, etc etc).
Modifié par SBoudrias (24 Mar 2013 - 03:25)

Je ne vais pas aller trop loin sur cette question, parce qu’elle n’est pas le sujet initial du topic : je ne nie pas que JavaScript est populaire et que d’autres dans le même catégorie que lui sont tout aussi populaires, je dis seulement qu’il est mauvais de l’utiliser pour ce à quoi il n’est pas adapté (un jugement qualitatif, pas de popularité). Après évidemment, on peut tout faire avec tout ce qui est Turing-complet, et on peut même faire un OS en SQL si on veut (SQL est Turing-complet depuis je ne sais plus quelle date, mais il l’est). Il y a ce que l’on fait, et il y a comment on le fait (et pour quelles conséquences). On peut bêcher un jardin avec une fourchette, si on veut, mais ce n’est pas la bonne manière de faire. La popularité n’est un bon indicateur dans ce domaine (et dans aucun domaine), il y a bien des choses qui sont répandues et qui sont mauvaises. Je n’ai pas envie d’en dire plus.

P.S. Attention au biais qui est de mal considérer ce que l’on ne connais pas… bien des gens ne connaissent que ce que tu mentionne, et ça fait un beau biais d’appréciation.
Modifié par hibou57 (24 Mar 2013 - 07:40)

a écrit :
Et pourtant, c'est déjà le cas (Facebook[...]

Je suis pas certain que Facebook soit le meilleur exemple d'appli non-native, dans la mesure où elle était tellement mauvaise qu'ils ont fini par devoir refaire l'appli en natif.

Ça bouge également *beaucoup* chez moz en termes d'outils de dev

@Felipe a écrit :
Pour ce qui est des outils internes de Firefox : la partie RWD (Shift-Ctrl-M) est mon quotidien

Je l'ai utilisé jusqu'à ce que je découvre la version CS6 de Dreamweaver où je gagne encore plus de temps car j'ai mon rendu en direct en fonction des supports que j'ai prédéfinis.