Ayer estuve en el centro de coworking (ES) (cuya web desmerece el espacio físico y el buen quehacer que tienen) de un miembro de la Comunidad. Era una visita por placer, por poder charlar en persona sobre temas que llevamos tiempo compartiendo vía digital (economía colaborativa, sociedad de control,…), para tramar algunos cambios de algo que los miembros de la Comunidad ya conocen, y que pronto haremos público. Y de paso, aproveché para asistir a un meetup sobre desarrollo y explotación de pages builders y themes en WordPress.
Y es que precisamente hacía unas horas habíamos conocido una de las iniciativas más interesantes, radicales, y sobre todo, apasionantes, del mundo WordPress.
Automattic, la empresa detrás de este popular gestor de contenido (con el que además del 25% de las webs que visita (EN), también está construida esta humilde morada), sacaba aplicación para OS X (ES).
Una aplicación nativa para mac, hablando en plata. Algo que muchos medios recogieron obviando la verdadera noticia, muchísimo más trascendente.
Para conocerla, nos toca meternos en las tripas de este proyecto, y hablar un poco de cómo un lanzamiento aparentemente tan poco crítico sirve de Caballo de Troya para redefinir el futuro de la web.
Empecemos.
El gestor de contenido líder sufre de los males de la edad
WordPress es un proyecto que nació hace ya diez años, que se dice pronto, y ha llegado a donde está gracias a una comunidad de entusiastas del software libre, y a una batuta bastante bien dirigida, que no ha dudado en abrir el kernel conforme el mercado lo exigía a extensiones y plugins que se habían vuelto un estándar.
Pero es precisamente esta razón la que le podría fagocitar en un futuro. WordPress está desarrollado en PHP, un lenguaje que a muchos nos encanta, que previsiblemente recibirá un nuevo soplo de aire fresco con la futura versión (ES), pero que reconozcámoslo, no es lo más puntero en cuanto a tecnologías web.
La feroz evolución que ha sufrido JavaScript en estos últimos años ensombrece la estabilildad y escalabilidad de PHP, y eso es un problema cuando la web de hoy se espera que sea lo más inmediata y accesible posible.
Para cualquiera que gestiona uno o varios WordPress sabrá que conforme el tráfico de la web aumenta, y sobre todo, conforme mayor complejidad tienen sus entrañas, más pesado y lento se vuelve, teniendo que recurrir a varias estrategias de optimización que en su día traté en varios tutoriales.
Por contra, JavaScript permite realizar consultas en tiempo real (sin nueva carga), lo que disminuye considerablemente el número de recursos pedidos en cada consulta, y esto hace que al final la web se sienta más liviana.
Por supuesto, la mayoría de temas de WP hacen uso de tecnologías como jQuery para dotar de dinamismo a PHP, pero las tripas siguen siendo PHP, que además encuentra problemas para adaptarse a escenarios más modernos, como es el mundo móvil.
Y aquí está el quid de la cuestión. Por muy bien que lo haya hecho Automattic, hay que reconocer que el panel de administración de WordPress huele a viejuno. Y la cosa va a peor si para colmo estamos en un dispositivo móvil, que aunque la interfaz sea adaptativa, la administración se vuelve un verdadero dolor de muelas.
Así, lo importante del lanzamiento de una versión oficial nativa de WordPress para OS X no es la propia aplicación, sino cómo ha sido desarrollada.
Porque este software es el primer ejemplo que tenemos de utilización de la REST API de WordPress, que vendrá implementada (si no ocurre algún contratiempo nuevo) en la próxima versión 4.4 (EN).
Sobre la llegada de REST API (Calypso) a WordPress
¿Cuál el la verdadera noticia? Precisamente que gracias a esa REST API, WordPress pasará a ser algo más que un “simple” gestor de contenido.
Ya no solo hablamos de que cualquiera pueda diseñar una experiencia de administración distinta a la que por defecto WordPress nos ofrece, sino que WordPress podría ser utilizado como un software de gestión de recursos para un servicio web. Una biblioteca que cuenta con un sistema eficiente de roles y permisos al que realizar peticiones mediante API para alimentar un sistema final, que sería el que el usuario consumiera.
El mejor ejemplo que se me ocurre es el desarrollo de una aplicación móvil, que por ejemplo, gestione el stock de una tienda. Se podría desarrollar el frontend de la aplicación con la tecnología nativa que proceda según el SO, crear un tipo de datos para cada producto en stock en WordPress, y alimentar a la aplicación sin tener que desarrollar ese backend, ya que WP pasará a gestionarlo como hoy en día lo hace.
De esta manera, se separa lógica de presentación, pudiendo usar WP como gestor de stock y sirviendo a los clientes una aplicación muchísimo más liviana, que en verdad está tirando de WordPress.
Por supuesto, todo esto ya se podía realizar con apaños (mismamente el suministrar contenido de un blog mediante RSS era algo que la mayoría de aplicaciones de consumo de contenido utilizaban). Pero a partir de ahora se podrá realizar a nivel de API.
Descontando el hecho de que también se podrá rediseñar y parametrizar a un nivel muchísimo mayor la experiencia a los mandos de un WordPress.
Si el éxito de estos nuevos CMS, como Medium, radica en que la experiencia de publicación de contenido se ha simplificado hasta el máximo nivel (entras en tu página, y sin ni siquiera tener que acceder a un panel de administración, la última entrada es un espacio en blanco en el que ponerte ya a escribir), la REST API de WordPress permitirá diseñar este tipo de comunicación con la base de datos, lo cual seguramente acabe por ofrecer desarrollos paralelos diseñados para tipologías de web específicas (portal, blog, foro, tienda,…) mucho más acertados que el único generalista que hoy en día tenemos.
Y por último, atendiendo a las tecnologías que se han usado para su desarrollo (node.js (EN), react (EN) y babel (EN)), todas dependientes de JavaScript, es una verdadera apuesta por los lenguajes de nueva generación. Un lavado de cara que WordPress necesitaba como el comer.
La REST API de WordPress, siguiendo la filosofía abierta del proyecto, está liberada bajo el nombre de Calypso, al escrutinio de la comunidad vía GitHub (EN). hoy en día, instalable como un plugin, a falta de que salga la futura versión que ya incluirá el desarrollo en su kernel.
Está diseñada para funcionar con WordPress.com y páginas autoalojadas que tengan instalado JetPack. Y las posibilidades son sencilla y llanamente, inmensas.
Justo el cambio que WP necesita para seguir liderando la web.
Renovarse o morir, de hecho, como en su día comenté al respecto.
¡Buen movimiento, chicos!
Interesante. Mucho, la verdad.
Entiendo que un cambio de esta naturaleza se introducirá de inicio en los “wordpress.com” que gestionan. En su momento me resultó una decisión difícil de tomar, pero elegí perder funcionalidad a cambio de facilidad en la gestión. Mi tiempo para el blog es limitado y priorizo el escribir al “hacer magias” para que todo funcione. Así que mi pregunta es, ¿cómo de fácil va a ser aprovechar estas nuevas funcionalidades para los que no queremos volvernos demasiado locos con código? ¿Qué nos ofrece sin tener que “picar” demasiado?
Si es que lo sabes y lo puedes decir sin tener que matarme luego, vaya. 🙂
Jajaja, en efecto Luis. De hecho tu razón de decidirte por el .com y no el autoalojado responde muy bien a la inquietud que tienen muchos más usuarios: ¿Y yo para qué quiero tanto?
En principio estará disponible para los que tenéis blog en WordPress.com, y para los que tengan un blog de WordPress y hagan uso de JetPack, que ya sabes que nos lo están metiendo hasta en la sopa como plugin de añadidos de tecnologías diseñadas por Automattic.
Y respecto a tu pregunta, la respuesta es bien sencilla: Es un cambio dirigido a desarrollo, no al usuario final. ¿En qué lo acabaréis notando? En que seguramente empiecen a proliferar aplicaciones y servicios para utilizar WordPress.com sin tener que “sufrir” su panel de administración. En que surgirán temas y extensiones enfocados por ejemplo a transformar un blog en WordPress en algo gestionado de forma semejante a como ocurre en Medium.
Pero que ahora WP tenga API REST es una apertura dirigida a desarrolladores, que o bien quieren darle una vuelta de tuerca a WP, o bien hasta ahora no se atrevían a tocarlo por ser un software desarrollado en PHP (hay mucho maniático por el mundo).
Resumiendo: que verás cambios. Nuevas opciones de interacción con tu blog, sean o no oficiales, que quizás se adapten mejor a tu forma de trabajar.
Buenos días, Pablo,
Javascript es un lenguaje en capa de presentación, en el navegador. PHP es un lenguaje de servidor, que devuelve HTML al navegador. Ambos se complementan. Y PHP no crea ningún tipo de problema en los móviles porque se ejecuta en servidor y devuelve respuesta en HTML al frontal web.
Una cosa es que se haga un buen diseño por parte del analista, con una arquitectura de tres capas bien definida (DATOS+NEGOCIO+PRESENTACIÓN) y otra es que compares un lenguaje de navegador que, aunque no tenga que recargar toda una página para obtener datos, SÍ NECESITA de la intermediación de PHP, JSP, ASP… para poder acceder a ellos y mostrarlos, extrayendo la información directamente o mediante JSON o XML, enviado como respuesta por el servidor, a través del lenguaje de NEGOCIO usado en esa web (PHP, JSP, Java Servlet, ASP…)
Si a todo esto le añadimos que leer “Caballo de Trolla” ha hecho que me sangren los ojos (es “Troya”), sólo me queda una pregunta por hacerte:
¿En serio esto lo has escrito tú?
:P. Gracias por la corrección. Normal que te sangren los ojos.
Soy humano, como todos, y también cometo errores. Muchos los consigo corregir antes de publicar (reviso una vez el artículo), pero de alrededor de 9000 palabras que publico cada semana es normal que se cuele alguno.
Ya está corregido.
Respecto a lo que comentas, y aunque tengas toda la razón del mundo, hay que entender que JavaScript no es únicamente un lenguaje “de navegador”. Sabrás más que de sobra que “lo que ahora parece molar” es precisamente tirar de node.js para el servidor, por su inmediatez y porque de paso todo se queda en el mismo lenguaje.
Hay bastante tirria (al menos que yo vea en los grupos de desarrollo) por PHP, que se siente anticuado, e incluso más en WordPress, que por su arquitectura dinámica requiere unos recursos que escalan a un ritmo quizás demasiado alto.
Al menos hasta que veamos salir la nueva versión, que parece ser “un milagro” en cuanto a recursos y velocidad de lectura con BDs relacionales.
En PHP no puedes programar para móvil. Por lo que comentas (es un lenguaje interpretado), así que al final dependes de JavaScript para presentarlo. Y con este cambio, se podrá abstraer aún más esa capa de PHP, sirviendo prácticamente toda la web con JS, y tirando de WP únicamente para lo que necesites. O seguir tal cual estamos. La cuestión es que ahora habrá capacidad de elección.
Ahí es donde iba con el artículo.