JavaScript y sus frameworks, cómo hemos cambiado

Como cuento en el About-Me del blog, uno de mis proyectos más viejos y que todavía funciona con un número de visitas más que aceptable es el portal OnlyHouseMusic.org.

En realidad, es la primera web mínimamente decente que hicimos con Miguel, mi socio en PixelAvengers y su segunda versión ya va para 4 años en la web sin tener que hacer grandes cambios. Algún día publicaremos la versión 3.0, con Kohana, jQuery, APC, Memcache y todas estas cosas tan molonas pero la verdad es que la versión actual sin cacheado, sin framework JS, sin objetos (sí, yo también programaba scripting) ni sistema de plantillas va como un tiro. De hecho es curioso porque en más de una entrevista al ver que cargaba tan rápido me preguntaban por los sistemas de cache que usaba y en alguna ocasión me he tirado de la moto jejeje.

El caso es que nos ha salido la necesidad de tocar un poco el JavaScript para añadir una modal que dependa de una cookie y he tenido una experiencia religiosa que me apetece contar.

Hace 4 años, el AJAX estaba en plena ebullición, jQuery, Prototype y el resto se estaban empezando a extender pero en esa ocasión decidí usar JavaScript puro que total para lo que hacíamos era más que suficiente.

En estos años he aprendido a usar jQuery y la verdad es que al tener que tocar ese viejo código me ha entrado nostalgia y por qué no decirlo algo de urticaria. Y es que uno ya esta mayor para ir haciendo cosas como:

<script type="text/javascript">
  var req=false;
  try{
     req=new XMLHttpRequest();
  }catch(err1){
     try{
          req=new ActiveXObject("Msxml2.XMLHTTP");
     }catch(err2){
         try{
            req=new ActiveXObject("Microsoft.XMLHTTP");
        } catch(err3){alert('Error creando objeto AJAX');
     }
  }
 }
</script>

Si no te suena haber leído este código, es que no estuviste en los comienzos del Ajax 🙂

Como siempre, el problema es Microsoft y su “gran” navegador Internet Explorer, con sus múltiples versiones a cada cual más desastrosa. Eso provoca que aparte de hacer esto, haya que hacer cosas como…

<script type="text/javascript">
      if( typeof( window.innerWidth ) == 'number' ) {
	myWidth = window.innerWidth;
      } else {
        myWidth = document.documentElement.clientWidth;
      }
</script>

Para algo tan trivial como obtener la anchura del navegador donde se está viendo la página
O grandes cosas como…

<script type="text/javascript">
// var elem = un tag de un xml que recibimos
var tittext = '';
if(elem.textContent) { tittext=elem.textContent; } 
else if(elem.innerText) { tittext=elem.innerText;  }
else { tittext=elem.text; }
</script>

Para intentar recuperar el texto interior de un tag XML, que si mal no recuerdo daba problemas a veces con Konqueror y con Safari 2.

Podéis imaginaros el suplicio que era hacer que la página se viera bien en todos los navegadores.

Debido a esto, durante muchos años Explorer dominó el mercado y fue gracias a que la gente se empezó a preocupar de seguir los estándares que esta situación ha ido cambiando.

Y por supuesto, los frameworks JavaScript han ayudado un montón. Yo no conozco demasiado ninguno que no sea jQuery pero las tareas anteriores se pueden hacer de forma muy sencilla y nos olvidamos de la compatibilidad con los 5-6 navegadores que debemos comprobar.

De todas maneras, también es cierto que quizás se está abusando de poner muchísimo JavaScript con los frameworks, sus plugins y total a lo mejor solo queremos hacer un hide y show, que se puede hacer en JavaScript puro 2 líneas en vez de descargarnos las 100ypico Ks que pesan la mayoría (aunque gzipped y minified sea mucho menor).

En cualquier caso, si no dominamos mucho mucho de JavaScript recomiendo encarecidamente no perder el tiempo y usar uno de los frameworks dominantes y aceleraremos el desarrollo de nuestra página y mejoraremos su compatibilidad de forma drástica. Los expertos dicen que quizás Prototype permite hacer más cosas si tenemos que hacer una aplicación con muchas acciones JS pero está claro que jQuery es facilísimo para hacer efectos debido sobretodo a la gran documentación que hay sobre él.

JavaScript nació como un “juguete” para hacer pequeñas cositas y poco a poco se está revelando como uno de los lenguajes con más futuro, sobretodo ahora que la nube empieza a crecer. Cada vez hay más tendencia a pasar todo a aplicaciones via navegador debido a la facilidad de deploy si lo comparamos con las aplicaciones de escritorio y probablemente los próximos años irán muy buscados los buenos desarrolladores en JavaScript.

Para terminar el post, os recomiendo el libro JavaScript Patterns de O’Reilly, mi lectura actual en el metro camino de Privalia que creo que es de lo mejorcito que he leído en JavaScript, por su claridad y ejemplos de código.

You may also like...

4 Responses

  1. Alberto says:

    Cómo olvidar esos cortes de JS!! Cada vez quedan menos que los hayan vivido/sufrido esto ehhh….que esto es como los que nacen y ya empiezan con los i7 quad core xDDD.

  2. Raul says:

    Ya me he comprado el JavaScript Patterns, leeremos a ver… :mrgreen:
    La verdad que, de todos los libros que me he comprado, los de O´Reilly son en mi humilde opinión, y de largo, los más prácticos y mejor explicados

  3. Ricard Clau says:

    Ese Raulito que no creía en JS y el AJAX… cómo hemos cambiado!

  4. Raul says:

    Jejeje… todo ha sido ponerse :mrgreen:
    Por cierto, del Javascript Patterns pillo la mitad por no decir un cuarto, mejor empezar por el principio: Javascript Cookbook, del año pasado. Más “llano”