lundi 4 août 2014

Web Mobile: devons nous abandonner JQUERY?

Pourquoi abandonner JQUERY?

Tout d'abord soyons bien clair: JQUERY n'est PAS un véritable framework, c'est tout au plus un ensemble de wrappers et de polyfills permettant 1) de simplifier l'écriture, 2) d'assurer la compatibilité du code entre les différents navigateurs (principalement Internet Explorer!!!).

Il est vrai que de nos jours, beaucoup de web-designers ont commencé leur apprentissage avec JQUERY, mais, à l'heure de HTML5 et du web mobile il est temps de mettre un terme à sont utilisation, d'une part parce que la compatibilité du code Javascript au sein des principaux navigateurs mobiles est déjà là (et ce ne sont pas les parts de marché marginales d'IE mobile qui m'intéressent ici), d'autre part parce que JQUERY est beaucoup trop LOURD et LENT!

JQUERY c'est lourd?

jquery.mobile-1.4.3.min.js    : 198Ko
jquery.mobile-1.4.3.min.css : 207Ko 

Soit 405Ko à télécharger (configuration par défaut), tout ça pour gérer du DOM ...

JQUERY c'est lent?

Oui! Très lent même!

Démonstration avec chrome mobile

ici on teste JQUERY vs querySelector en sélectionnant une classe CSS.

jQuery('.selectme').hide
17 552 Ops/s
document.querySelector('.selectme').style.display = 'none';
505 819 Ops/s

La version querySelector est environ 29 fois PLUS RAPIDE!


Et ce n'est guère mieux sur l'accès par un id ...

var d = $('#myId');
68 136 Ops/s
var d = document.getElementById('#myId');
1 281 515 Ops/s


La version native est environ 19  fois PLUS RAPIDE!

L'utilisation de JQUERY implique mécaniquement l'utilisation de 20 fois plus environ de cycles CPU soit une consommation 20 fois supérieures à ce que l'on pourrait obtenir en utilisant du JS  moderne et standard... et dans le monde des webapps et du mobile la problématique vitesse/consommation est un point très important.
 

Conclusion (provisoire)


Nous verrons dans les prochains articles comment concevoir des applis ou des sites mobiles légers et rapides en s'affranchissant des frameworks qu'affectionnent tant les webdesigners qui à mon avis n'ont plus leur place à l'heure du HTML5. Nous verrons aussi quelques techniques pour optimiser notre code.


11 commentaires:

  1. Mais pourquoi faire vos tests avec un jquery 1.4.X alors qu'on partirait plutôt sur une version 2.X, plus adaptée au mobile ?

    RépondreSupprimer
  2. Eh eh… Même remarque que k20, pourquoi faire un comparatif avec une si veille version de jquery ?

    RépondreSupprimer
  3. @k20 @Teddy

    Le test fait sur JSPERF avec la version 2.1.1 donne les résultats suivant :

    var d = $("#myDiv"); -> 71 809 Ops/s
    var d = document.getElementById("myDiv"); -> 1 098 499 Ops/s

    La version native est donc ENCORE 15 fois plus rapide...

    Intrinsèquement JQUERY est handicapé par le fait qu'il doit interpréter la chaine passée en argument .... quelque soit leurs efforts et les versions qui suivront ce handicap subsistera ... CQFD!

    RépondreSupprimer
  4. Bonjour,

    Là, oui, votre test est plus plausible.
    Cela dit, c'est une vérité connue depuis un moment. cf. http://jsperf.com/jquery-vs-native-javascript

    De plus, jQuery ne s'est jamais présenté comme étant un framework mais une librairie. Elle permet du code javascript rapidement tout en étant compatible avec plusieurs navigateurs.

    Forcément, du javascript natif sera toujours plus rapide que jquery car jquery passe par "36000-lignes" pour arriver à la fameuse ligne de javascript originelle.

    De plus, il existe d'autres alternatives plus performantes telles que AngularJS, Ractive.js, etc.

    Bref.

    RépondreSupprimer
  5. angular.toJson -> 40373 Ops/s
    JSON.stringify -> 188500 Ops/s

    La version native est environ 4.7 fois plus rapide, et ce pour une opération largement employée par les Web Apps .... les devs ne peuvent même pas invoquer la concision d'écriture puisque le nombre de caractères utilisés est identique....
    Le fait que cela soit une vérité connue (par les développeurs, pas par les webdesigners) n'empêche pas que l'on continue à confier la réalisation de sites mobiles a des webdesigners et à recruter en demandant une connaissance de JQUERY.
    En fait la vraie question est peut-être : doit-on laisser la conception de sites/webapp à des webdesigners ou à de véritables programmeurs ?

    RépondreSupprimer
  6. Ces deux tests ne sont pas comparables :

    jQuery('.selectme').hide
    document.querySelector('.selectme').style.display = 'none';

    Le premier fait la modification sur tous les éléments qui ont la classe selectme, tandis que le second ne modifiera que le premier.

    Utiliser un querySelectorAll serait un peu plus lent, mais surtout imposerait de faire une boucle derrière sur les résultats.

    RépondreSupprimer
    Réponses
    1. Ils sont comparables dans le sens ou il n'y avait qu'un élément avec cette classe dans le source HTML. Mais je vais faire un test avec querySelectorAll vous avez raison.

      Supprimer
    2. Le test jsperf est ici :
      http://jsperf.com/queryselectorall-jquerytestcase;

      Sur ma tablette nexus 7 sous chrome, les résultats sont les suivant :
      jQuery selector -> 982 Ops/s
      QuerySelector & Array -> 6861 Ops/s

      La version native est donc environ 7 fois plus rapide....

      Supprimer
    3. C'est encore trop lent :)

      Merci en tous cas pour l'article !

      Supprimer
  7. Petite coquille:
    var d = document.getElementById('myId');
    au lieu de
    var d = document.getElementById('#myId');

    RépondreSupprimer
    Réponses
    1. NON! Absolument pas, ce n'est pas du JQUERY là :) Voilà ce que c'est quand on ne connait pas les fonctions natives :)

      Supprimer