Mais ? Le développement front-end est un bordel sans nom ?! - Page 12

Surtout que par rapport à l'époque de la guerre IE/Netscape, il y a maintenant des polyfills pour émuler les fonctions qui n'existent pas sur un navigateur, des frameworks qui masquent les détails d'implémentation, etc. Donc c'est plus facile qu'avant de faire des sites/applis qui fonctionnent partout.

Évidemment ça peut ne pas suffire si on veut utiliser la dernière feature à la mode qui vient à peine de sortir, mais est-ce que ça vaut le coup de sacrifier la compatibilité pour ça ? Pour un outil de gestion des congés, je vois mal ce qui peut justifier de ne supporter que Chrome...

Les problèmes de ces émulations, c'est que ça raaaaa…me à fond sur les vieux navigateurs, parce que ces navigateurs n'ont déjà pas les performances d'un navigateur dernier cri (parce que les moteurs JavaScript ont été de plus en plus optimisés en vitesse avec le temps), alors si en plus on leur fait avaler tout un paquet de code supplémentaire pour simuler une centaine de fonctionnalités récentes, ça ne va plus du tout. Si on ouvre ces sites avec, par exemple, KHTML, le navigateur ne répond plus du tout. Certains arrivent même à planter le plus récent Qt4WebKit de la sorte. Les développeurs croient qu'il suffit de rajouter un émulateur magique pour que leur code tourne partout, mais généralement ça ne fait qu'empirer les choses.

Le site de Lenovo (FR) se casse complètement la gueule sur chrome (cross-domain scripting, me semble, je me souviens plus), mais sous firefox, il fonctionne nickel.

Sauf que ça m'a empêché de télécharger les pilotes du lecteur de cartes (micro)SD 1 an; quand j'ai fini par installer firefox, je me suis aventuré sur le site de Lenovo, et tout fonctionnait.

J'ai pété un plomb.

D'ailleurs hier chrome bouffait 2 go avec juste 2 onglets, je pense qu'il y a un sérieux problème au niveau de la gestion de la mémoire... (pas de flash ouvert). Je veux bien que ce soit parce que je suis sur la branche dev, mais quand même...

En fait il fait des malloc() de 100 Mo en avance pour les futurs onglets que tu ouvriras

1024Mo tu veux dire

ben non, sinon c'est plus en avance.

Du coup j'suis pas encore repassé à firefox, parce que j'ai pas la force d'aller importer tous mes mots de passe, et mes favoris, mais faudra que j'le fasse.

Firefox peut importer ça directement. Ça prend 3 clics.

Oué, mais j'ai juste la flemme d'aller cliquer

Zeph (./321) :
"le site fonctionne correctement sous Chrome et Internet Explorer, la solution conseillée est d'utiliser l'un de ces navigateurs".

Moui. Par "le site fonctionne", la traduction exacte est "le code JS est foireux, mais Chrome et IE sont suffisamment permissifs pour laisser passer l'erreur tandis que Firefox l'intercepte".
Et les glandus qui ont programmé le site n'ont pas cherché à vérifier sur Firefox. À ce stade ce n'est pas une erreur de compatibilité.

C'est merveilleux :
https://twitter.com/jo_liss/status/843875280888434690/photo/1

Et c'est l'autrice de https://github.com/broccolijs/broccoli qui se plaint de la situation?

(ce qui est merveilleux aussi c'est d'écrire un article sur twitter)

(je suis bien d'accord, mais bref)

Ca me rend dingue de voir su JS partout. Je ne comprend pas, le langage n'est pas beau, c'est chiant à écrire. Et c'est de plus en plus régulier lorsque je visite des sites que d'un coup le ventilo se mette à tourner bien fort, car il y a un site qui me bouffe tout...

pareil mais que veux tu, c'est devenu le BASIC moderne...

C'est surtout que les navigateurs l'imposent parce qu'ils n'acceptent rien d'autre. (Certes, il y a la transpilation, mais c'est encore pire comme usine à gaz que du code écrit nativement en JavaScript!) Et comme les gens veulent faire tout et n'importe quoi en web…

C'est surtout formidable de voir que l'utilisation de JS est en train d'alourdir encore plus les pages que l'utilisation passée de Flash, c'est un comble.

Arvi89 (./345) :
Je ne comprend pas, le langage n'est pas beau, c'est chiant à écrire.

C'est partout, tous les navigateurs, pas besoin de plugins, aucun concurrent sérieux. Avec le navigateur, on a inventé un ordinateur virtuel qui ne connaît qu'un seul langage de base.
La preuve, il y a même des langages plus évolués qui ont pour tâche de se compiler en JS.

Meowcate (./348) :
C'est surtout formidable de voir que l'utilisation de JS est en train d'alourdir encore plus les pages que l'utilisation passée de Flash, c'est un comble.

Quelqu'un en doutait ? Pour moi c'était évident depuis le début.

Tout le monde ou presque s'est réjoui de l'arrivée du HTML5 en disant que ça allait magiquement résoudre tous les soucis du Flash, mais du point de vue perfs théoriques, c'est encore pire :
- ça tourne aussi dans une machine virtuelle
- contrairement à Flash, le code n'est pas précompilé (donc le navigateur doit le compiler, et ça supprime la possibilité d'optimiser le bytecode en amont)
- le code à exécuter est écrit dans un langage mal fichu

Le seul point positif en pratique pour les perfs, c'est que les développeurs de navigateurs font du meilleur boulot qu'Adobe (qui n'a jamais été foutu du faire du code efficace). Mais ça n'est pas magique non plus.

Vu la gueule du code de Flash ce n'est pas dur....

Zerosquare (./349) :
- ça tourne aussi dans une machine virtuelle

Certes, mais si on veut faire du multi-archi et sécurisé, on n'a pas vraiment le choix

Zerosquare (./349) :
- contrairement à Flash, le code n'est pas précompilé (donc le navigateur doit le compiler, et ça supprime la possibilité d'optimiser le bytecode en amont)

asm.js permet d'avoir quelquechose qui ressemble à un bytecode en partie optimisable en amont, mais c'est clair que ça reste du bricolage.
WebAssembly par contre devrait assainir un peu la situation.

Zerosquare (./349) :
- le code à exécuter est écrit dans un langage mal fichu

J'ai pas fait trop de flash, mais il me semble que l'action script était aussi un langage de merde de la même famille que le JS, non?

Oui AS est un derive de ECMAscript

Zerosquare (./349) :
- contrairement à Flash, le code n'est pas précompilé (donc le navigateur doit le compiler, et ça supprime la possibilité d'optimiser le bytecode en amont)

Je trouve que cet argument est léger, à mon avis la compilation en bytecode a un coût négligeable vu la simplicité du JS et de sa grammaire, surtout comparé au JIT qui s'effectue probablement derrière aussi bien en Flash qu'en JS. C'est d'autant plus vrai que les navigateurs modernes (Chrome mais probablement les autres aussi) mettent en cache la version "bytecodisée" des scripts et non la version texte, donc le coût de compilation ne se paie qu'à la première page vue. Ça me semble pas pouvoir expliquer tous les maux du monde.

Pour moi le problème c'est surtout que Flash permettait une réutilisabilité assez faible à cause de son environnement fermé : il n'y a jamais eu de dépôt de composants réutilisables en Flash ou ce genre de choses, donc jamais de gros frameworks non plus, à mon avis ça a limité assez naturellement le poids des projets.

Zeph (./353) :
Pour moi le problème c'est surtout que Flash permettait une réutilisabilité assez faible à cause de son environnement fermé :

Je ne sais pas si c'est à cause de son environnement fermé, mais c'est clair qu'il n'y a jamais eu de communauté avec plein de codes et libs dispos (à ma connaissance).

Par contre, je trouve que malgré tout, le JS représente une avancée par rapport à Flash : plusieurs implémentations indépendantes, par nature bien intégré à la page web, normalisé.

Après, c'est normal qu'il ait du succès : on n'a pas le choix, c'est JS ou JS.

Non tu as JScript aussi et VBScript #loin#

Zeph (./353) :

Zerosquare (./349) :
- contrairement à Flash, le code n'est pas précompilé (donc le navigateur doit le compiler, et ça supprime la possibilité d'optimiser le bytecode en amont)

Je trouve que cet argument est léger, à mon avis la compilation en bytecode a un coût négligeable vu la simplicité du JS et de sa grammaire, surtout comparé au JIT qui s'effectue probablement derrière aussi bien en Flash qu'en JS. C'est d'autant plus vrai que les navigateurs modernes (Chrome mais probablement les autres aussi) mettent en cache la version "bytecodisée" des scripts et non la version texte, donc le coût de compilation ne se paie qu'à la première page vue. Ça me semble pas pouvoir expliquer tous les maux du monde.

Tous les maux du monde j'irais pas jusque là, je disais juste que par principe ça partait avec des désavantages par rapport à Flash (qui en avait déjà lui-même).

Zeph (./353) :
Pour moi le problème c'est surtout que Flash permettait une réutilisabilité assez faible à cause de son environnement fermé : il n'y a jamais eu de dépôt de composants réutilisables en Flash ou ce genre de choses, donc jamais de gros frameworks non plus, à mon avis ça a limité assez naturellement le poids des projets.

Je n'y avais pas pensé mais c'est très probablement vrai aussi.

Flan > je ne dis pas que remplacer Flash par du JS n'ait pas été une avancée, mais que ce n'est pas la panacée que certains espéraient : à part le côté ouvert, techniquement le JS n'est pas meilleur que Flash (ce sont juste les implémentations qui sont plus performantes, et encore il a fallu un certain temps pour y arriver).

Moi j'aimais flash parce qu'on n'en avait pas besoin. Donc tu prenais toute la merde qu'avait créé ce monde et tu la blacklistais avec flashblock, et tu te retrouvais dans le monde des arc-en-ciels et poneys angéliques. C'était magique. Maintenant c'est de la merde encore pire bien sûr mais tu peux rien faire pour. Pire cette merde est dans nos applis desktop.
(Et je ne fais pas volte face, j'en ai déjà parlé il y a plus de 6 mois, et à multiples reprises en observant Slack ; Hipchat est mieux mais quand même ridiculement consommateur. Genre là je n'ai qu'un compte mais il consomme quand même dans les 700 Mo de RAM quand tu comptes tous les processes qu'il spawne.)

SublimeText a le même souci, si je laisse l'ordi tourner avec Sublime en premier plan l'autonomie est genre du tiers ou de la moitié de si j'affichais le bureau ou une page web simple. Bon dans mon cas j'utilise le curseur en semi-phase, qui fait qu'il est animé de façon fluide. Sublime consomme nettement moins avec le curseur blink. Atom n'a pas cette opti.

SublimeText n'utilise pas Node/JS c'est du natif

A propos, Qt et son QML, c'est quoi par rapport à Node/JS ? Encore complètement autre chose ? Il me semblait que c'est proche du JS.