node.js

node.js es la tecnología de moda. Lleva JavaScript hasta el servidor y permite hacer aplicaciones completas con el. Conoce porque está haciendo tanto ruido.

scroll

No soy un desarrollador al uso. No me siento atraído por un lenguaje o tecnología, ni por su belleza intrínseca, ni por la teórica potencia de su diseño o sintaxis, sino por la aplicación práctica y real de los mismos para construir cosas. Cosas reales.

Aún sigo asistiendo atónito a luchas infantiles sobre la calidad de tal o cual lenguaje, librería, framework o sistema de control de versiones. Idioteces. Casi todas las tecnologías me parecen interesantes, pero, últimamente, he de reconocer que hay una que me llama la atención mucho más que el resto: node.js

node.js logo

Node.js es una librería de lectura y escritura, orientada a eventos, que se ejecuta sobre V8, el rapidísimo interprete de JavaScript de Google. Simplificando: permite ejecutar JavaScript en servidor con capacidad de consultar y persistir datos por cualquier canal de lectura/escritura como un fichero,un socket o una base de datos. Simplificando de nuevo: con las nuevas capacidades de lectura y escritura, aparece la posibilidad de crear aplicaciones completas desarrolladas completamente en JavaScript.

[no_blockquote text=”JavaScript es un lenguaje de juguete que sólo utilizan bohemios, gente de mal vivir o, peor aún… ¡diseñadores!” text_color=”” title_tag=”h3″ width=”” line_height=”” background_color=”” border_color=”” show_quote_icon=”yes” quote_icon_color=”” quote_icon_size=””]

¿Y qué?” -pensaréis muchos- “JavaScript es un lenguaje de juguete que sólo utilizan bohemios, gente de mal vivir o, peor aún… ¡diseñadores!“. Puede ser, yo antes creía algo parecido, pero os contaré el proceso mental que me llevo a convencerme de que estaba equivocado.

The path of Bo: el camino del guerrero

Ya he comentado que, para mi la tecnología no es el fin, sino el camino. Así que, os contaré donde empezó el camino que me llevo a node.js: movilidad. Creo que el futuro está en los dispositivos móviles y que las nuevas aplicaciones serán móviles desde su concepción.

El gran problema de la movilidad es la variedad de plataformas existentes: iOS, Android, RIM, Windows Mobile… Un equipo pequeño puede hacer grandes cosas en el sector móvil, pero es imposible que pueda asumir el desarrollo multiplataforma.

Mi camino a node.js

Pero aparece HTML5 y, con el, un montón de nuevas funcionalidades (base de datos local, posibilidad de trabajar offlinewebworkerswebsockets, canvas…) que permiten crear aplicaciones increíbles casi tan potentes como las nativas, pero basadas en el navegador. Un navegador que, en el caso de las dos plataformas principales, además está basado en el mismo motor: Webkit, compatible con una gran mayoría de esas funcionalidades avanzadas.

¿De verdad se necesita una aplicación móvil nativa? Yo creo que el 99% de las aplicaciones móviles actuales se podrían hacer con HTML5, ahorrando costes y ampliando el mercado de las mismas.

Además, existen aplicaciones como PhoneGap que empaquetan una aplicación HTML5 para que se distribuya como una aplicación nativa en los markets de todas esas plataformas, haciendo prácticamente indistinguible para el usuario las aplicaciones nativas y las desarrolladas con HTML5.

Una vez convencido de que HTML5 ha revolucionado el desarrollo móvil y comenzar a desarrollador con el…  ¿Adivináis como se puede trabajar con sus nuevas funcionalidades? Efectivamente, JavaScript.

Y al aprender JavaScript en serio como parte del proceso que te llevará a dominar HTML5, es donde empiezas a ver todo el sentido a node.js porque ¿No os parece elegante y revolucionario poder utilizar -por primera vez en el desarrollo web- el mismo lenguaje de programación en el cliente y en el servidor?

Mucho más sobre node.js

Por supuesto, node.js es mucho más que JavaScript ejecutado en servidor. Su diseño permite crear aplicaciones ultraescalables, al estar basado en programación asíncrona y orientado a eventos en vez de a hilos de ejecución. Podéis aprender muchas más cosas geniales sobre node.js en este genial artículo del amigo Gimenete.

Bonilla, no tienes ni idea: conclusión

Siempre hay alguien que piensa distinto que tú. Las críticas constructivas son positivas y yo no intento adoctrinar sobre el uso de node.js. He intentado explicar como he llegado hasta el y porque me gusta desde una perspectiva personal.

No soy un gurú, pero tampoco hay que confundir el intento de concreción -sólo intento, que este artículo ya va por las 1000 palabras- con la falta de unos conocimientos técnicos mínimos:

  • Sí, ya sé que si se aplica el mismo paradigma de programación en Java, por ejemplo, esta es tan rápida o más que node.js y consume la misma memoria o menos.
  • También admito que la idea de “JavaScript en el servidor” no es nueva y que ya hubo otros intentos antes.
  • Reconozco que querer desarrollador con el mismo lenguaje en cliente y servidor es algo muy personal y subjetivo. Y no tiene porque ser lo más óptimo.
  • Sé que hay aplicaciones para móviles con todo el sentido del mundo que sean nativas, como los que hacen un uso intensivo de los gráficos o de las posibilidades del dispositivo en si. Cuando digo que la mayoría de aplicaciones pueden hacerse con HTML5, me refiero a las típicas aplicaciones corporativas que sólo manejan formularios, listados y gráficos estadísticos.
  • Y sí, no hay una compatibilidad uniforme de las características en los navegadores actuales. Es más, la gran mayoría de la base instalada de navegadores de escritorio, aún no son compatibles con HTML5.

Siempre habrá peros a cualquier stack tecnológico que alguien elija, pero este me parece un buena base de partida para el desarrollo de aplicaciones móviles. Estoy expectante por conocer las propuestas y alternativas de la gente en los comentarios.

Bola Extra

 

  • Buenas

    Cuando he leido esta frase:

    “poder utilizar -por primera vez en el desarrollo web- el mismo lenguaje de programación en el cliente y en el servidor?”

    Ya te iva a enchufar este enlace

    http://download.oracle.com/docs/cd/E19957-01/816-5930-10/intro.htm#13106

    Aunque has sabdio rectificar a tiempo:

    “También admito que la idea de “JavaScript en el servidor” no es nueva y que ya hubo otros intentos antes.”

    Yo sigo viendo que es JS, aunque como ya comenté en otro artículo, no deja de progresar, pero yo qiero que sea compilado, fuertemente tipado, o, por lo menos, que exista una herramienta
    que pueda hacer una especie de “compilado” que me detecte mis errores en los proyectos de 100k lineas,¿es mucho pedir?

    Un saludo

    • ^_^ 

      Si… el maligno y vehemente Dr. Arranz nos ha estado recordando a todos que la idea de JavaScript en servidor es de cuando Franco era corneta. Ojo a los comentarios que se marca en este post: http://java.dzone.com/articles/node-js-and-server-side-java

      Entiendo lo que planteas y las ventajas del compilado y el tipado fuerte… igual que entiendo a los que prefieren justo lo contrario.

      Jeroclo tiene la misma visión, y por eso está como un niño pequeño con Scala y GWT… y por eso a mi me atraen cosas como Play.

      El típico gurú te diría “¿Para que quieres una aplicación con 100.ooo lineas? Haz 10 de 10.000. Be water my friend…”. Yo, simplemente, creo que hay un conjunto de buenas prácticas y herramientas, desde JsUnit a Jasmine, pasando por SinonJs o JsTestDriver que te permitirán seguir adelante más allá de las 100.000 lineas.

      Un abrazo.

      • Está claro que una cosa no quita la otra, usar JsUnit, modularizar tu aplicación, que nunca van a dejar de ser buenas prácticas, pero sigo echando en falta algunos puntos.

      • Sí, lo reconozco, me tengo que declarar… I love Jeroclo XD

      • odioJS

        Como ya se ha dicho, código JS en servidor no es nada novedoso, en realidad parece ser que no es novedoso en general emplear un lenguaje de scripting que pueda ejecutarse tanto en cliente como en servidor (Ruby, Python,…).

        El caso es que quien para mi lo había hecho realmente bien es Microsoft con Silverlight, que permitía un lenguaje poderoso, fuertemente tipado, compilable (auque luego el resultado sea interpretado en el CLR), y con la ventaja de estar empleando el mismo lenguaje en cliente y en servidor, y ser fácilmente depurable.

        Lo peor de todo es que hay muchos lenguajes de programación excelentes, que desde hace tiempo son infinitamente mejores que Javascript, y sin embargo se han quedado al margen del desarrollo web por no haberse conseguido implantar como estándar por falta de acuerdos entre las grandes compañías. El resultado es que al final lo que se está haciendo es potenciar y mejorar poco a poco un lenguaje de programación muy pobre, solamente por esta razón… Penoso y patético…

  • Gimenete

    Gracias por la mención 🙂

    Llevo unos meses trabajando con NodeJS y estoy encantado. Utilizar el mismo lenguaje en cliente y servidor tiene bastantes ventajas. Por ejemplo poder manejar los mismos datos estructurados en cliente y servidor sin necesidad de marshalling/unmarshalling, parsers, etc.

    También se puede utilizar el mismo código en cliente y servidor. Por ejemplo para validación de formularios, plantillas para generar HTML a partir de datos, etc.

    • Ya tocaba, ya tocaba… No sólo eso, la versión vespertina del tweet está programada para ser una Gimenete Edition ^_^

      En dos pinceladas geniales has descrito un par de ventajas definitivas para la utilización del mismo lenguaje en cliente y servidor, pero -como has podido comprobar con el compañero Más que Ceros– salir de la seguridad del compilado y el tipado fuerte… cuesta.

      Creo que hay que empezar a escribir más sobre casos de uso (y de éxito) reales y cercanos para que la tecnología acabe de explotar. 

      • Gimenete

        Salir de la seguridad del compilado y tipado fuerte cuesta. Pero bueno, también es cuestión de tener una buena cobertura de test de unidad.

        Creo que el principal problema de NodeJS es su madurez y por tanto la falta de madurez de algunos módulos, herramientas (ej: debugging), etc.

        En cuanto al resto para mi es una solución ideal: rapidez, sencillez,…

        Otros ejemplos de ventajas de usar el mismo lenguaje en cliente y servidor, un poco más excepcionales: hay módulos de reconocimiento facial, generación de gráficas en SVG, PNG, (las puedes generar en cliente, o si te interesa generar un PDF en el servidor, la generas en el servidor y la añades al PDF), etc. 

        Saludos!

    • Raúl Arabaolaza

      La verdad es que veo la fuerza del argumento desde un punto de vista tecnológico, pero acostumbrado a los entornos a los que estoy acostumbrado y a lo que cuesta en esos entornos introducir una nueva tecnología, (parte de mi trabajo es justamente de formación) creo que debo minimizar la ventaja de evitar el uso de parsers, marshallers etc. 

      Cualquiera de mis compañeros (y sus jefes de proyecto) prefiere usar un conversor JSON o XML a tener que aprender una tecnología nueva, y no es que no quieran, es que no se lo pueden permitir en sus circunstancias.Saludetes

      • Gimenete

        Poder hacer esto en una línea, pudiéndoselo pasar a la plantilla HTML y que el código javascript lo reciba TAL CUAL, no tiene precio:

        var person = { “name”: “xxx”, “addresses”: [“calle de la alpargata 2”, “calle del pepinillo 12”] }

        Sólo por curiosidad me gustaría saber cuántas líneas de código cuesta hacer la clase correspondiente en Java o en lo que sea, programar un parser, etc. Y luego que el programador frontend reciba algo decente con lo que trabajar. O sin clase Java propia; con Maps y Lists.

        Sí, seguro que con algún framework y haciendo funcionalidades reutilizables y tal se puede hacer en pocas líneas. Pero NUNCA será tan sencillo y legible como en javascript.

        Y esto es un ejemplo trivial. Supongamos que se complica “un poquito”. La diferencia comienza a ser notable.

        Saludos!

        • Raúl Arabaolaza

          Buenas,

          Esto se está convirtiendo en una conversación de dos, no se si será el sitio adecuado…

          En cualquier caso, el tema de generar JSON a dia de hoy está totalmente automatizado y el programador solo tiene que hacer cosas como 

          renderJSON(new Persona(“Juan”,”Calle falsa 13″));

          return new Persona().toJSON();

          Estando el método renderJSON o to JSON ya echos (Play framework el primero y Spring Roo el segundo), el programador frontend recibe un json exactamente igual al que tu has escrito. De la misma manera existen los análogos para convertir de json a java.

          Aún así obviamente siempre será más facil poder usar directamente javascript para definir los datos que vas a pasar al programador frontend. Pero, y ahí está lo que quiero remarcar, sigue siendo más fácil en mi opinión usar estos métodos que aprender un stack/lenguaje nuevo.

          Saludetes

          • Gimenete

            Sí se ha automatizado mucho últimamente. Pero sigues teniendo que crear una clase Persona. Y en mi ejemplo “addresses” era una lista. Sin embargo en el tuyo lo has tomado como un String. Y todo se empieza a complicar. Y si complicas un poco más el modelo de datos, todo se empieza a complicar mucho más. Y quizá necesitas 10-20 (definir la clase, propiedades, métodos de acceso) o más líneas de código. Y en javascript es una línea.

            No quiero decir que sea un infierno trabajar con JSON en otros lenguajes. Con tu ejemplo se ve que se ha simplificado mucho y es muy legible. Pero sí que considero que hay una diferencia notoria en cuanto a productividad y claridad. En JS siempre será lo más sencillo 😉

            Saludos

  • Raúl Arabaolaza

    Buenas:

    DISCLAIMER: Soy programador Java y me gusta y mi experiencia es sobretodo en temas enterprise más que en aplicaciones pequeñitas Coincido contigo en la atracción que siento hacia node.js, aunque debo reconocer que yo soy uno de esos que piensan que el mismo lenguaje en cliente y servidor no tiene por qué ser bueno siempre o lo más optimo desde el punto de vista del producto final, como tu muy bien dices es cuestión de percepción, en mi marco laboral cuanto más independiente sea una parte de la otra es, en mi opinión,  mejor.

    Peeeero si que comparto la excitación de que exista node.js, porque aunque en determinados momentos quizás no sea lo mejor o más eficiente desde el punto de vista tecnológico si que en determinadas situaciones puede ser lo más práctico o incluso la única opción viable dados tus conocimientos o plantilla. Para mi lo genial de node.js son dos cosas:

    – Permite acceder a diseñadores y programadores web javascript al “otro lado” lo cual no puede tener otra consecuencia más que un enriquecimiento mutuo entre los que llevamos toda la vida programando en servidor y los que programan en cliente. ( y lo digo por experiencia que aprender jQuery y JavascriptMVC me ha ayudado a organizar mejor mis backing beans)

    – Aumenta la visibilidad y la importancia de Javascript como lenguaje a tener en cuenta para aplicaciones enterprise.  En mi opinión los navegadores web están evolucionando hacia una especie de “Maquina Virtual Universal” respaldada por servicios en la nube y tanto Javascript como HTML son sus lenguajes naturales y a dia de hoy cualquier programador java se sorprendería lo mucho que a avanzado el desarrollo en JavaScript. 

    Comparto la preferencia sobre tipado fuerte sobretodo porque  creo que a la parte de herramientas de desarrollo le vendría muy bien para temas como refactor, find usages y similares que al final parece una tontería que no tiene nada que ver pero en la práctica un buen entorno de desarrollo puede decantar fácilmente el uso de una tecnología u otra por encima de las capacidades técnicas.

    Siento el rollazo, hoy me has tocado una fibra sensible 🙂

    • Gimenete

      Por mucho que sea javascript yo no daría acceso a diseñadores que sepan javascript. Al fin y al cabo van a acceder a la base de datos y demás recursos críticos.

      • Raúl Arabaolaza

        Pero ahora mismo (y más en el futuro con lo que conlleva HTML5) podemos afirmar que de javascript hay muy buenos programadores y no solo diseñadores, solo que en este caso ambos hablarían el mismo lenguaje y sería mucho más fácil su convivencia, se puede dejar que los programadores se ocupen de programar la lógica y los diseñadores de programar los temas relativos al diseño.

        Fíjate en frameworks como JavaScriptMVC, Backbone, Sencha, Knockout o cualquiera de los millones que están surgiendo no creo que quien los haya creado o diseñado sea inferior como programador a uno java y que no sea capaz de tocar una base de datos.

        El echo de usar Javascript no cambia que un diseñador es un diseñador y un programador un programador, pero creo que permite reducir la “incompatibilidad lingüística y mental” entre ambos.

        • Gimenete

          Sí que puede ayudar a que un *programador frontend* se entienda mejor con un programador backend. Pero no con un diseñador. Porque para mi un diseñador es alguien que diseña, y eso no tiene que ver con la programación, así que no tiene que ver con estructuras de datos, callbacks, etc.

          Sí que puede haber diseñadores que además sean programador frontend. Pero reservemos la palabra diseñador para solamente la parte de diseño. Y si además programa, será también programador.

          • Raúl Arabaolaza

            Aceptada la distinción, y el comentario posterior, da por modificado el aserto quitando diseñador y poniendo programador frontend (suena bien la verdad).

            Pero fijate que un diseñador y un programador frontend javascript pueden tener mucho más sencillo colaborar que por ejemplo un diseñador y un programador frontend tradicional java porque ambos pueden trabajar sobre un lenguaje común como HTML y CSS, mientras que en java u otras tecnologías esto no suele ser así y tecnologías como JSF o GWT no son accesibles o modificables por el diseñador. 

            Al final lo que quiero decir es que tenemos tres actores que, en este tipo de escenarios que empiezan a surgir basados en tecnologias javascript,  pueden comunicarse y cooperar entre ellos de una forma que en mi opinión no es posible, (o tan fácil) con otros casos.

            Diseñador – Programador frontend – Programador backend

          • Gimenete

            Visto así, sí. Lo único que quería puntualizar antes es que me chirriaba un poco que un diseñador puro empezase a tocar el backend 😛

  • Estoy de acuerdo con tus comentarios. Yo tambien hace unos meses (Creo que como tu, después de conocer a Cristian), que estoy metido en node.js. Tengo varios proyectos en mente en los que node.js creo que le va al pelo para conseguir los objetivos. A más a más. yo era un fanático de javascript hace 10 años. Hasta que la presión mediática me obligo a dejarlo.

    Te dejo una de ls fricadas por las que me gusta node.js (Entre otras)

    http://www.heatsynclabs.org/boutduinode-a-pool-party-with-arduino-node-js-and-an-rc-boat/

  • vellebue

    Buenos días a todos, desaparezco un día y… la que hay liada. Voy a tratar de hacer un poco de síntetsis a mi manera.

    Node.js tiene la gran virtud de plantear una forma de programar que puede hacer un uso más eficiente del servidor y por tanto permitir economizar recursos. Ahora bien, para aquellos que están acostumbrados a trabajar con la típica metodología  estándar de desarrollo “superheterodina” con el planteamiento estándar de casos de uso, tendrá que reconocer que la forma en que se traduce un diseño estándar de caso de uso (un escenario CRUD típico) a Node.js haciendo uso del cllbacks no es la más intuitiva.

    En cuanto a la polémica sobre tipado fuerte vs tipado débil que duda cabe que en principio para andar sobre seguro siempre será más recomendable el tipado fuerte. Para aquel que esté acostumbrado a programar con tests unitarios o mejor aún con TDD todo esto probablemente le sea indiferente y es más, prefiera la concisión del código que suele conferir un lenguaje dinámico de tipado débil. Recuerdo de los congresos de Ruby on Rails las discusiones sobre las ventajas de lenguajes como Ruby para programar código compacto y elegante. De todas formas si algo (un poco) he aprendido de los lenguajes dinámicos de tipado débil es que no necesariamente facilitan la escritura de un código elegante sino que más bien o eres tú el que eres capaz de escribir código elegante o si no probablemente tendrás algo difícil de mantener y por tanto mejor haberlo escrito en un lenguaje de tipado estricto.

    Como siempre en estos caso con qué gente cuente y que sean capaces de hacer es mucho más importante que la tecnología con la que quieras trabajar.

    En cuanto a Javascript cada día estoy más convencido de que lleva un destino parecido al de C. Te podrá gustar, parecerte indiferente, lo podrás odiar pero… tiene su nicho, no se ha inventado algo mejor para ese nicho y está aquí para quedarse.

    Saludos.

    • Carlos

      Apenas me encuentro documentandome acerca de nodejs. Actualmente me encuentro desarrollando un proyecto en mi universidad en donde se ve involucrado la edicion de codigo de manera cooperativa (Operational Tranformation). Ya tengo gran parte de mi aplicacion web (logica) montada sobre java y quisiera saber si hay forma de integrar java con nodejs. Agradeceria si alguien pudiera colaborarme con informacion o algunos demos donde se aplique lo mencionado anteriormente para poder guiarme. De antemano gracias por la atencion brindada.

  • Pingback: Lo mejor de mi RSS del 26 de septiembre al 2 de octubre | Linux Hispano()

  • Pingback: Crónica de la Apache Barcamp Spain | Bonillaware()