Estudio de caso de un autor de plugins aficionado

En 2024 estaba buscando trabajo. Decidí ofrecer mis servicios como consultor de comunidades. Sin embargo, por lo general, la gente estaba más interesada en ayuda técnica para arreglar o actualizar sus sitios de Discourse. Un cliente potencial me preguntó si podía agregar un formulario de contacto para que las personas que no tenían una cuenta pudieran enviar comentarios. Busqué un poco y concluí que no era posible. Pero tenía mucho tiempo libre y seguí el tutorial para desarrolladores de plugins para ver qué podía hacer. Finalmente, logré desarrollar un plugin de formulario de contacto y cerré el contrato con el cliente.[1]

Solo para que todos tengan esto claro: ¡No soy programador de frontend! Han pasado 13 años desde que fui programador profesional de cualquier tipo. Sé cómo hacer un formulario HTML y eso es prácticamente todo lo que sé. Así que luché a través de la sección de Ember y Handlebars del tutorial y armé un parche que funcionó lo suficientemente bien. Afortunadamente, estaba familiarizado con los sistemas de plantillas, ya que los había usado en un trabajo anterior.

Encontré un trabajo en la Fundación OpenSSL[2] y dejé de lado a la mayoría de mis clientes. Pero el cliente para el que creé el plugin me mantuvo en nómina porque realmente apreciaba mi trabajo. (He realizado varios proyectos no relacionados para él.) Para ganar mi nómina, decidí actualizar el servidor de Discourse de mi cliente. Esto es lo que vi:

Solo esto aparecía en el sitio de mi cliente porque fui estúpido e instalé, pero no activé, el plugin de contacto en mi sitio de pruebas. Así que rápidamente activé el modo seguro y desactivé el plugin. El fin de semana pasado pasé un tiempo averiguando qué salió mal y cómo podría solucionarlo para mi cliente.

Después de buscar un poco, encontré Deprecación de la extensión .hbs en temas y plugins:

En la última versión de Discourse, el uso de archivos .hbs en temas y plugins está deprecado. El soporte para este formato de archivo se eliminará después de la próxima versión ESR.

Esto fue en marzo, lo que significa que, si estuviera en la versión ESR, debería haber tenido hasta prácticamente finales de septiembre para solucionarlo. Pero mi configuración de Discourse usa “tests-passed”[3], así que supongo que obtuve el error unos meses antes.

Como de todos modos voy a tener que solucionarlo (o decepcionar a mi cliente), me lancé a las instrucciones: Actualización automática de temas y plugins al formato de archivo .gjs. El primer paso fue instalar un entorno de desarrollo, ya que había cambiado de computadora portátil desde la última vez que intenté esto.[4] Cuando finalmente logré ejecutar Discourse y confirmé que mi plugin estaba roto localmente, ejecuté el proceso de lint[5]:

$ pnpm eslint --fix .

/Users/jericson/src/discourse-contact-plugin/assets/javascripts/discourse/components/contact-form.js
   1:8   error  Use Glimmer components(@glimmer/component) instead of classic components(@ember/component)          ember/no-classic-components
   3:16  error  Native JS classes should be used instead of classic classes                                         ember/no-classic-classes
   3:16  error  Please switch to a tagless component by setting `tagName: ''` or converting to a Glimmer component  ember/require-tagless-components
  20:3   error  Use the @action decorator instead of declaring an actions hash                                      ember/no-actions-hash

✖ 4 problems (4 errors, 0 warnings)

Aunque es molesto tener que cambiar mi plugin, al menos el proceso de lint me ayudó a limpiar y modernizar mi código. Sin embargo, el script automatizado falló al intentar convertir a .gjs. Así que decidí probar https://ask.discourse.com/

Tengo 12 preguntas allí. No las compartiría con un humano porque son solo las quejas de un programador cada vez más frustrado. En un momento, el bot sugirió un “enfoque moderno más robusto” para uno de mis subproblemas que incluía… un archivo .js y un archivo .hbs.

Instantánea de 8½ en la que el director tira la reseña negativa del crítico sobre 8½.

Sé por qué sucede esto. Está entrenado con discusiones de Meta Discourse y aún hay muchos posts que contienen código Handlebars, incluida la segunda parte del tutorial oficial para desarrolladores de plugins. Esas cosas se actualizarán con el tiempo, pero me preocupa que tome un poco más porque el consejo oficial para obtener ayuda con la actualización es preguntar al chatbot en lugar de preguntar en Meta Discourse.

Supongo que no debería quejarme; me ayudó a ordenar mi código y probablemente con menos fricción que preguntar a humanos.

Estabilidad de la plataforma

Ahora trabajo para la Fundación OpenSSL. Probablemente conozcas a OpenSSL por Heartbleed. Se usa en todas partes. La versión más popular para descargar es 1.1.1, que alcanzó el fin de su vida útil en 2023. La siguiente más popular es 3.0, lanzada en 2021, pero que aún está soportada como una versión de Soporte a Largo Plazo (LTS). La siguiente es 3.5, nuestra última LTS. Esas tres versiones representan casi 2/3 de las descargas desde GitHub.

Eso es un poco decepcionante porque 3.5 tiene algunas características nuevas interesantes. Pero en última instancia, las características que más importan a la gente son alguna combinación de SSL/TLS y primitivas criptográficas. A menos que te emocionen los algoritmos criptográficos post-cuánticos, pospondrás el dolor de actualizar el mayor tiempo posible.

OpenSSL está mucho más abajo en la pila que Discourse, por supuesto. Pero el principio es el mismo. A menos que haya una nueva característica, a la gente no le interesan las actualizaciones que rompen cosas. Sé que ustedes están emocionados por las nuevas características que se han agregado a Discourse. Entiendo querer cambiar una API para obtener algunas optimizaciones más adelante. Solo me preocupa que moverse demasiado rápido dañe a Discourse como plataforma sobre la cual se construyen comunidades.

Hablando de eso, hay una presentación muy útil llamada Gardening Platforms escrita por Alex Komoroske. La diapositiva 90 comienza una sección llamada “Plataforma + Ecosistema” que explica cómo las plataformas deben coevolucionar con sus ecosistemas. En este caso, Discourse es la plataforma que soporta un ecosistema de diseñadores de plugins y temas, servicios de hosting, la comunidad de Meta Discourse e incluso las comunidades construidas sobre Discourse. Una idea importante en las notas del orador de la diapositiva 98:

Pero no son independientes; están relacionadas simbióticamente.

Las acciones que ocurren en una influyen en la otra, y viceversa. Piensa en ello como bucles de retroalimentación que las conectan en ambas direcciones.

No están rígidamente unidas, es más como una banda elástica que las une. Es una atracción gravitacional.

Si una plataforma y un ecosistema se mueven demasiado rápido uno respecto al otro, el vínculo se rompe con efectos desastrosos. Confío en que Discourse hará lo correcto por el ecosistema. Solo que para mí, fines de semana como el pasado debilitaron esa confianza.


  1. Estoy moderadamente orgulloso de mi trabajo, aunque al final terminó siendo un sitio bastante estático. ↩︎

  2. ¡Presagio! ↩︎

  3. Eso también necesita actualizarse ↩︎

  4. Redis y Rails fueron más difíciles de instalar de lo que recordaba. ↩︎

  5. No sin antes pasar mucho tiempo intentando obtener eslint.config.mjs, sin embargo ↩︎

Creo que recibiste el error debido a este bug, no porque tu plugin necesite una actualización en este momento:

Pasé por lo mismo con muchos de los plugins que había escrito. No tenía el tiempo ni los recursos para modernizarlos según los estándares de Discourse. Tengo un trabajo relacionado con la ciencia de datos, así que aunque conozco los conceptos de ingeniería de software, no me mantengo al día con los detalles específicos del desarrollo web. Al final, no actualicé mi sitio durante ocho meses porque dependía de esos plugins obsoletos.

No quiero trivializar tu lucha, pero básicamente creo que con la llegada de la codificación agente, este ritmo de desarrollo ya no es un problema. Lo que me habría tomado una o dos semanas codificar y corregir, lo logré con una suscripción de 20 dólares a Claude Code y unos minutos por plugin. Además, pude optimizarlos para mejorar su rendimiento. Después de usar la codificación agente en algunos proyectos laborales y personales, creo que nunca más volveré a programar algo desde cero en mi vida. Es como la diferencia tecnológica entre escribir y entregar una carta a mano frente a enviar un correo electrónico. Es un poco triste, pero al mismo tiempo se siente como si te hubieran otorgado poderes de nivel divino.

Parece probable. Actualizarse a la última ESR (y ser un poco más vigilante en las pruebas) parece un buen plan a partir de ahora.

No creo que el ritmo de desarrollo sea un problema per se. Es el ritmo de todo. ¿Por qué no se ha actualizado, por ejemplo, el tutorial sobre plugins? Es una mina a punto de estallar en la cara de algún pobre desgraciado que quiera crear un plugin. Funcionará por el momento, pero eventualmente se enfrentarán al mismo problema que yo. La solución no es usar IA para arreglar el plugin más tarde, sino corregir las instrucciones sobre cómo crear un plugin ahora. Quiero decir, ¿no hay ninguna razón para seguir enseñando la forma antigua de hacer las cosas, verdad?

Porque somos un equipo bastante pequeño que mantiene una base de código enorme y debe implementar nuevas funciones para clientes de pago, al tiempo que brindamos soporte y mantenemos todo funcionando para nuestra comunidad de código abierto.

Solo podemos hacer tanto en un día, y la documentación a menudo se queda atrás.

Entiendo muy bien tus frustraciones, pero creo que ese punto merece una mención también.

Gracias por la información detallada, @jericson. Como bien dices, Discourse está en una posición muy diferente a la de OpenSSL, tanto en cuanto a su uso como a su lugar en la pila tecnológica. Es un equilibrio constante entre el progreso, la personalización y la estabilidad. No existe una solución perfecta que satisfaga a todo el mundo, pero siempre tenemos en cuenta los comentarios de nuestros clientes y de la comunidad de código abierto. Me encanta mucho la cita que compartiste:

:chefs_kiss:

Como mencionó @moin, la experiencia que tuviste con la deprecación de .hbs fue un error en latest durante aproximadamente una semana. ¡Muchas disculpas por ello! Aunque el uso de .hbs está deprecado, todavía es compatible. Tu código .hbs debería funcionar correctamente ahora.

Gracias por señalarlo. He revisado y limpiado las menciones restantes de .hbs en la documentación:

Lo entiendo perfectamente.[1]. Me encanta Discourse y escribí esta publicación porque quiero que Discourse siga teniendo éxito.

Algo que he aprendido es que a las comunidades no les gustan los cambios, pero están mucho más abiertas a ellos si sienten que tienen capacidad de decisión. Hay innumerables formas de dar a las personas esa capacidad. Por ejemplo, el tutorial podría convertirse en publicaciones wiki para que personas como yo puedan actualizarlas. Implementar el plan ESR también ayuda, ya que da a las personas la opción de no hacer cambios de inmediato.[2]. Poder escribir sobre mi experiencia y que sea vista por quienes gestionan el proyecto de código abierto también ayuda. Especialmente porque las quejas que expresé se solucionaron en una noche. :wink:

En “¿Escuchar a los usuarios es perjudicial?”,[3] Kathy Sierra escribió:

La mayoría de nosotros somos conscientes de que los grupos de enfoque son notoriamente ineficaces para muchas cosas, pero aún así asumimos que escuchar comentarios reales de usuarios reales es la mejor manera de impulsar nuevos productos y servicios, así como de mejorar lo que ya tenemos. Pero hay un gran problema con eso: ¡la gente no necesariamente sabe cómo pedir algo que nunca ha concebido! La mayoría de las personas hacen sugerencias basadas completamente en mejoras incrementales, mirando lo que existe y pensando en cómo podría ser mejor. Pero eso es bastante diferente a tener una visión de algo profundamente nuevo.

La verdadera innovación rara vez provendrá de lo que los usuarios dicen directamente.

Como dije, no soy desarrolladora frontend. No entiendo realmente por qué se hicieron estos cambios ni cómo me beneficiarán.[4]. Y está bien si, con el tiempo, hacen que Discourse sea mejor.

Aún así, puede ayudar a personas como yo a estar a bordo si puedo ver la visión con un poco más de claridad. Para este cambio, la propuesta es:

  1. una experiencia de desarrollo mucho mejor
  2. permitirá grandes mejoras de rendimiento en futuras versiones de Discourse

Suena bien, supongo. No noté particularmente el punto #1 y el #2 podría significar muchas cosas. Para mí, sería más efectivo algo así (y lo estoy inventando totalmente):

  1. Cuando convertimos los complementos oficiales de Discourse, descubrimos que se eliminaron X% de líneas de código. Al colocar la plantilla en el mismo archivo que el JavaScript, el código es más fácil de entender y modificar en el futuro.
  2. Configuramos una rama para probar la eliminación completa de Handlebars y descubrimos que ese cambio hizo que las cargas de página fueran X% más rápidas. Además, vimos una posible optimización que podría eliminar [algunos problemas que han planteado los usuarios].

Un poco más de detalle con el objetivo de educar a los no expertos ayuda mucho a mantener la confianza. Quizás no me gusten los cambios, pero ¿cómo puedo argumentar en contra de solucionar problemas reales que otros usuarios han enfrentado?


  1. OpenSSL tiene una dinámica similar. Tenemos una Corporación (~15 personas) que vende contratos de soporte y una Fundación (10 personas, yo incluida) que se encarga de los intereses no comerciales. Nuestra documentación también se queda atrás. Mientras escribía la publicación original, noté que todavía tenemos referencias a funciones que se eliminaron el mes pasado. Estoy trabajando en una PR para eso. Además, hicimos algunos cambios que proyectos downstream han criticado duramente ↩︎

  2. Menos útil para los autores de complementos que desean apoyar a comunidades que quieren mantenerse a la vanguardia. Pero será genial para mí, ya que creo que soy la única persona que usa mi complemento ↩︎

  3. Su blog ha desaparecido de internet, pero hay un archivo PDF. ↩︎

  4. No es que yo importe mucho en el esquema general de las cosas. Hablo de mí como representante de otras personas que dependen de Discourse. ¡Después de todo, me conozco mejor que la mayoría! ↩︎

¿Por qué necesita ser un wiki para eso? La documentación para desarrolladores se gestiona a través de GitHub. Me gusta aún más el proceso en el que los cambios son revisados que en un wiki.

Estoy de acuerdo en que la documentación del plugin debería actualizarse en este punto. El objetivo del período de “obsolescencia”, durante el cual los plugins siguen funcionando pero el sitio muestra una advertencia de que pronto dejarán de hacerlo, es dar a los autores de los plugins suficiente tiempo para corregirlos. Sin embargo, en ese mismo período, un equipo de desarrolladores remunerados a tiempo completo no pudo actualizar la documentación central de desarrollo de plugins. Es una expectativa extraña imponerla a desarrolladores individuales cuando un equipo no puede gestionarla completamente en el mismo lapso.

Para mí, esto indica que la velocidad de desarrollo es demasiado rápida y/o que los autores de plugins no son una prioridad significativa para Discourse. Personalmente, creo que es más bien lo segundo. Entiendo que algo tiene que quedar de lado, así que esto es una observación por mi parte y no una crítica. Discourse sigue siendo totalmente personalizable mediante plugins y agradezco las mejoras continuas.

Dicho esto, creo que estamos en un momento en el que una guía paso a paso para construir un plugin base es una idea obsoleta. Ahora, para un autor de plugins aficionado, solo se necesita un documento de contexto único para que un agente lo lea y genere un esqueleto de plugin. De hecho, para una base de código de código abierto como Discourse, la documentación ni siquiera es necesaria, ya que los agentes obtienen el contexto directamente de la propia base de código. Cuando trabajaba en mis plugins, vi a Claude leer los plugins existentes como una forma de aprender los patrones de diseño. Incluso pude detectar un error en el código central: Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time

Básicamente, para cualquier persona que lea esto y aspire a ser un autor de plugins aficionado, la documentación puede estar desactualizada, pero es 1000 veces más fácil construir un plugin que nunca antes lo haya sido.

Solo para aclarar este punto: la cronología de depreciación para hbs comenzó recientemente. Lo más temprano que consideraremos eliminar el soporte será después del próximo ESR (a finales de julio). Así que sí, deberíamos haber actualizado la documentación antes, pero esto no es un caso de “eliminar el soporte sin suficiente advertencia”. .hbs aún es compatible y hay mucho tiempo para realizar los cambios necesarios.

Mantenemos más de 600 temas y complementos, por lo que puedo asegurarte que también “sentimos el dolor” de estas migraciones. Hacemos lo posible por hacer los cambios lo más fluidos posible para todos y seguiremos aprendiendo de cada cambio que realicemos.

:100: Exacto

Aún no tenemos exactamente esto. Pero estamos comenzando a crear un directorio de habilidades en el repositorio principal. Además, toda la documentación de desarrollo en formato markdown se ha movido al repositorio principal, en parte para que sea más fácil para los agentes de IA consultarla.

Es posible que esté mezclando cosas en mi cabeza, ya que arreglé mis complementos tanto para la actualización de Ember 6 (el gran obstáculo de actualización para mí) como para la migración desde hbs al mismo tiempo. ¡Disculpa si fui demasiado categórico!

Pero creo que si Discourse quisiera hacer crecer el ecosistema de complementos creados por usuarios, sería útil un tutorial moderno de «vibecoding». Pero, por otro lado, ¿es deseable abrir las compuertas a una oleada de complementos generados con vibecoding? Difícil de decir :smile:

¡Ah! Eso ayuda. PR enviada.

Soy fan de publicar la documentación en GitHub. Es bastante más trabajo enviar cambios que editar una publicación de wiki, pero el paso de revisión es útil. (Y para la documentación de autores de complementos, requerir conocimientos de Git no es una barrera tan alta.)