TSBOARD (constructor de comunidades de código abierto escrito en TypeScript)
(github.com/sirini)¿Qué es TSBOARD?
- TSBOARD significa Type Safety BOARD, y es un constructor de comunidades y tablón de anuncios escrito en TypeScript.
- Su backend fue construido usando el runtime Bun, que ya fue presentado antes aquí en GeekNews, junto con el framework web ElysiaJS. Gracias a eso, funciona más rápido que los motores de foros tradicionales.
- En el frontend se usaron Vue y Vuetify. Pero como el sentido estético del desarrollador deja bastante que desear, escribo esta publicación con la esperanza de que en el futuro pueda recibir ayuda de algún diseñador generoso. (+ por supuesto, ¡también necesito ayuda de desarrolladores generosos!)
¿Por qué lo hice?
- Empecé a desarrollar programas web con
PHP, y soy un desarrollador que pasó por la época de Zeroboard y Gnuboard. - El último recuerdo que tenía de JavaScript en mi cabeza era que sin
jQueryera un lenguaje bastante inútil (...). - Pero me terminé enamorando, aunque tarde, de las continuas mejoras del estándar, de la aparición de
Node.jsy de TypeScript de Microsoft. (La verdad, creo que me enamoré demasiado tarde). - Por eso quise volver a crear una aplicación web, y quería escribir en puro TypeScript el clásico tablón de anuncios que siempre hacía.
- Además, quise construirlo para que fuera fácil de usar y, de ser posible, funcionara de forma más rápida y segura.
Ventajas propias de TSBOARD
- TSBOARD está escrito en TypeScript tanto en el frontend como en el backend, lo que garantiza al máximo la seguridad de tipos. (Nada es perfecto, pero este fue el aspecto al que más atención le puse).
- Para quienes ya han hecho desarrollo full-stack basado en
Node.js, es un diseño fácil de entender y listo para usar de inmediato. Como yo también lo fui aprendiendo desde cero mientras lo desarrollaba, tomé como referencia muchas buenas prácticas de otras personas. - Incluye todas las funciones necesarias para crear sitios de comunidad de tamaño pequeño y mediano. Al desarrollarlo, tomé como referencia reconocidos sitios de comunidad de Corea como Clien, Quasar Zone, Giggle Hardware y también Damoang, que apareció recientemente.
También tiene desventajas.
- El runtime Bun no funciona correctamente sobre CPU virtuales. En servicios de hosting con servidores virtuales económicos es difícil aprovecharlo bien. Como TSBOARD también depende de Bun, le aplica la misma limitación.
- TSBOARD usa un enfoque de Client Side Rendering. Como alguien que todavía le tiene cariño a PHP, incluso el término Server Side Rendering me resultaba más bien ajeno. Aunque tiene varios pros y contras, quise probar primero un enfoque nuevo para mí, y como desarrollé TSBOARD con el objetivo de reducir la carga del servidor, esto sin duda puede ser una desventaja para algunas personas.
- En realidad ya pasaron más o menos seis meses desde que empecé a desarrollarlo, pero todavía tiene muchas carencias y apenas ahora siento que puedo presentarlo. Espero poder superar estas limitaciones con la ayuda de esas personas generosas que encuentre en el futuro.
Cierre: soñando con el día en que comunidades famosas adopten TSBOARD
- Al ver que Gnuboard pasó de PHP a Python, sentí que las aplicaciones web también siguen intentando cosas nuevas. Lo mismo pasa con Rhymix, nacido de XE. La web sigue siendo dinámica, y el desarrollo también.
- Yo también quería aportar, aunque fuera de forma modesta, al ecosistema web a través del proyecto TSBOARD, así que dejo aquí esta presentación.
- Sueño con el día en que algún nuevo sitio de comunidad adopte TSBOARD. jaja
¡Gracias por leer este texto tan largo!
21 comentarios
No estoy seguro de si ayude dejar un comentario adicional en una publicación que subí hace unas 2 semanas jaja,
pero mientras pensaba cómo reflejar los comentarios relacionados con SEO que recibí en GeekNews,
implementé
sitemap.xmlpara aplicar la optimización para motores de búsqueda y lo dejo aquí como comentario para compartirlo.Para ir directo a la conclusión, los motores de búsqueda finalmente recopilan los datos accediendo a
robots.txt>sitemap.xmly luego a la rutahttps://tsboard.dev/tsapi/seo/main.html (página de ejemplo).
Si un usuario llega a través de una búsqueda, configuré esa página para que desde ahí pueda volver a entrar al sitio original mediante enlaces.
Pueden revisar los detalles en el siguiente enlace.
https://tsboard.dev/board/free/18
Yo también estaba pensando en correr con bun un proyecto que hago como hobby, pero me sorprende que no funcione bien en una vCPU. Y al registrarme, como en la condición de la contraseña decía mayúscula, pensé que no era necesario incluir minúsculas, pero resultó ser una trampa jaja. Creo que debería decir mayúsculas y minúsculas.
Por si acaso, dejo una respuesta. Quienes estén considerando el runtime de Bun ya no tienen que preocuparse por problemas de funcionamiento en CPU virtuales...! Lo probé en la versión 1.1.31 y confirmé que funciona sin problemas. :)
Ah, muchas gracias por el comentario, y sin falta voy a corregir también la parte de las condiciones de la contraseña que mencionaste. Jajaja
Bun, para ser sincero, yo tampoco lo he usado tan a fondo, pero mientras lo usaba tuve muchas experiencias sorprendentes en varios sentidos. También me pasó muchas veces que funciones que en Node.js daban por hechas simplemente no funcionaban por alguna razón (entre ellas, por ejemplo, el problema de que no se soportaba la opción
recursive: trueal crear carpetas), y también vi muchas cosas que mostraban una obsesión sorprendente por la velocidad (por eso mismo no pude evitar tomarle más cariño).Ahora le dicen Bundows, y el runtime de Bun ya tiene soporte oficial en Windows, pero antes de la versión 1.1 no funcionaba y había que ejecutarlo sobre WSL2. Sobre lo que comentaste del funcionamiento en CPU virtual, es muy probable que Bun siga sin soportarlo en el futuro. Aunque sí ofrecen una distribución (baseline) para CPUs que no soportan instrucciones AVX2, la falta de soporte para CPU virtual —no sé si sea una limitación de Zig, el lenguaje en el que está desarrollado Bun— sigue siendo una situación decepcionante en varios aspectos. Lo que sentí al usarlo, en pocas palabras, es que Bun también parece haber sacrificado algunas cosas por priorizar la velocidad.
Por si acaso en el futuro algún usuario de Bun llega a ver este comentario, quisiera agregar solo una cosa más: a pesar de varias limitaciones, Bun es una opción atractiva. Sobre todo si eliges ElysiaJS como framework web, creo que al menos en términos de velocidad no habrá nada que echar de menos. Si me tocara volver al inicio y elegir otra vez el runtime... lo pensaría un poco más, pero aun con varios problemas creo que igual terminaría eligiendo Bun. Esa obsesión casi fanática por la velocidad, y esa actitud de desafiar un ecosistema de runtimes de JS donde ya parece haber una respuesta establecida, de alguna manera me llegan al corazón. Jajaja
Mientras revisaba el código en GitHub, me surgieron algunas dudas y quería dejar estas preguntas.
En lo personal, me impresionó mucho ver que salió un board de este tipo basado en TS, justo algo que me gustaría que existiera.
¡La configuración de claves foráneas se aplicó en la actualización v0.8.40!
https://tsboard.dev/board/free/18
¡Ah, gracias por el comentario!
Con lo de definir relaciones, supongo que te refieres a que no están configuradas las claves foráneas. No había una razón en particular; pensaba probar a configurarlas una vez que la estructura de las tablas estuviera más o menos definida, pero como me fui ocupando de otras cosas en el camino, todavía no había podido aplicarlo. Como ya se han estabilizado bastante las dependencias entre las tablas de TSBOARD y las columnas que se referencian, ahora voy a dejar también configuradas las claves foráneas y trataré de cambiarlo a una forma que garantice mejor la integridad.
Sí pensé un momento en NoSQL... pero ya había demasiadas cosas nuevas por aprender primero, desde el lenguaje TypeScript hasta Vue y Node.js/Bun, así que decidí no cambiar. Las bases de datos relacionales ya tienen bastante tiempo por toda su larga historia, pero también me preguntaba si no será porque siguen siendo útiles y por eso todavía se usan mucho en tantos lugares. Al momento de escribir este comentario pienso así, aunque si más adelante surge alguna necesidad, podría considerar algo como MongoDB jaja.
La verdad, personalmente me sorprende que todavía no hubiera existido un tablón basado en TypeScript, pero creo que también es cuestión de tiempo. ¡Ojalá aparezcan muchos otros proyectos con un estilo distinto al de TSBOARD! jaja ¡Gracias por el comentario!
Sinceramente, como pensé en los antiguos tipos de foros en PHP, no esperaba gran cosa, pero después de ver el sitio de demostración (https://tsboard.dev) cambié de opinión. La calidad es muy buena.
¡Creo que este tipo de cosas podrían ser necesarias!
¿Implementaste directamente el editor? Vaya... Supongo que probablemente usaste un motor de editor (?), pero se siente una artesanía impresionante.
¡Gracias por tu comentario! Te agradezco aún más que hayas visto con buenos ojos la calidad del sitio tsboard.dev. jaja
Sobre el soporte para SSR que mencionaste, preparé una hoja de ruta dividida en dos etapas, y mi idea es aplicar primero medidas complementarias para luego, en versiones posteriores, seguir desarrollando con una mezcla adecuada de CSR y SSR. Para optimizar un poco más el SEO manteniendo un rendimiento suficiente, sobre todo yo también necesito aprender mucho más, así que creo que me hará falta algo más de tiempo. Tengo la esperanza de que, si no me rindo y sigo avanzando de forma constante, también pueda conocer a otros desarrolladores talentosos, aprender más rápido y quizás recibir ayuda. jaja
En el caso de usuarios no autenticados, cuando hice TSBOARD no lo contemplé para acortar el tiempo de desarrollo y mantener la simplicidad del diseño, pero lo pensaré un poco más. En este momento, al dejar esta respuesta, si hubiera que considerar a usuarios no registrados harían falta muchos cambios, así que por ahora parece difícil. ^^;;;
El editor lo armé pieza por pieza sobre la base de tiptap, pero terminó llevándome mucho más tiempo del que esperaba. Si mal no recuerdo, antes era CKEditor o algo así... y parecía que bastaba con traer algo ya hecho. Pero hoy en día hay que montarlo así, pieza por pieza, como si estuvieras armando LEGO. T.T Además, me costó todavía más trabajo integrar las funciones de TSBOARD. Mientras lo hacía, pensaba que ojalá alguien hiciera este editor por mí jaja... Si alguien necesita un editor usable basado en tiptap, creo que podrá desarrollar más rápido y más fácil tomando como referencia el código que implementé en TSBOARD.
Más gente de la que esperaba lo ha visto de forma positiva, al punto de que siento que fue una pérdida de tiempo haber dudado tanto sobre si escribir o no el post de presentación. A TSBOARD todavía le falta mucho, pero aun así, les pido por favor que lo sigan apoyando.
Empecé desarrollando con php y ahora también estoy en una etapa en la que, fascinado por TypeScript, estoy probando mucho.
Me alegra porque siento una especie de afinidad.
¡Mucho gusto! Yo también, sin darme cuenta, he ido recorriendo un camino parecido. Jaja. Personalmente me da pena que al lenguaje PHP todavía lo sigan regañando por todos lados, pero después de probar TypeScript, pienso que quizá está bien que le llamen un poco la atención. Jaja. Ojalá que tú también, yeppyshiba, hagas muchos proyectos divertidos con TypeScript. :)
Está increíble 👍
¡¡Muchas gracias!! Es un proyecto al que todavía le falta mucho, pero me hace feliz que lo vean con buenos ojos. jaja
Seguiré mejorándolo con más esfuerzo para poder recomendar TSBOARD con total confianza cuando llegue el momento en que lo necesiten. :)
Esto era algo que me faltaba... gracias.
¡Gracias por dejar un comentario! Si algún día llegas a necesitar un programa web similar a TSBOARD, me encantaría que lo recuerdes y lo pruebes. Seguiré trabajando duro para mejorarlo y que puedas usarlo más cómodamente cuando lo necesites.
Oh...! Recuerdo el board sirini de la época de PHP, de verdad ha pasado muchísimo tiempo.
En su momento hasta desarrollé skins para Sirini Board y reporté vulnerabilidades de seguridad; ¿cómo has estado? :)
Al ver el código, lo que sentí es que el código del lado del servidor tiene bastante vibra de PHP jaja (¿código js con sensación de PHP?)
Como mencionó otra persona, si es CSR, probablemente tenga la desventaja de ser menos favorable para SEO y cosas así.
Ojalá se puedan mejorar bien esos aspectos jaja
¡Ah, entonces era usted ese benefactor que me ayudó antes! Me da mucho gusto volver a encontrarlo, jaja.
Además, tanto antes como ahora, me da un poco de pena sentir que solo hago cosas simples que a cualquiera se le podrían ocurrir. ^^;;
El código del backend, tal como comentó, tiene bastante influencia del estilo de PHP, jaja. A veces yo también me pregunto si en JS no habrá alguna función que usaba en PHP, y termino buscándola cada vez o incluso poniéndole a mis funciones nombres parecidos. Supongo que, conforme me acostumbre más al código de JS/TS y siga refactorizando, irá mejorando más. Jajaja.
En la parte de SEO, como usted dijo, tendré que hacer mejoras. Mi idea, aunque todavía es algo simple, es agregar otras páginas estáticas como RSS, así que voy a intentar varias cosas.
Por cierto, de verdad me sorprende y me agradece mucho saber que hay alguien que aún me recuerda de la época de PHP4. La verdad es que dudé bastante si escribir este post o no, jaja;;. Seguiré esforzándome para poder ayudar, aunque sea un poco, a más personas. ¡También denle mucho cariño a TSBOARD!
Leí la publicación y me surgieron unas dudas, así que dejo un comentario. (No he visto el código)
Me da curiosidad por qué no desarrollaron el backend para que fuera compatible con Node.js (¿el rendimiento es demasiado bajo como para compensar las desventajas que mencionaste?) ¿Y si es CSR, cómo planean manejar el SEO? Me parece que en una comunidad también hay que prestar atención al tráfico que llega desde búsquedas.
¡Hola! Gracias por dejar un comentario. (La verdad pensé que iba a quedar enterrado entre la indiferencia, así que me conmovió)
También pensé muchísimo en los puntos que preguntaste, así que me gustaría que lo vieras simplemente como otra forma de pensarlo.
Ah, como referencia, después de PHP no volví a dedicarme al desarrollo web ni una sola vez en mi vida laboral. Tampoco presté atención a la época de cambios con Node.js ni a cuando React cambió el mundo web, así que puede que haya perspectivas que me resulten algo ajenas. jaja
Cuando empecé a desarrollar TSBOARD, asumí por adelantado que ya debía existir algo famoso basado en Node.js (aunque yo no lo conociera), ya fuera un foro, un blog o algo parecido a lo que yo quería hacer. Como mencioné al principio, en mi vida laboral no tenía ocasión de hacer desarrollo web, y además nunca había hecho algo que pudiera llamar un side project, así que creo que por eso pensé así. Di por hecho que obviamente habría algo hecho sobre Node.js, así que no tenía mucho sentido que yo hiciera otra cosa nueva; ya que iba a aprender algo desde cero, mejor hacerlo sobre Bun. Y así fue como llegué hasta donde estoy ahora.
Si pensamos en el tema del rendimiento, en realidad creo que para el tipo de comunidad pequeña que yo tenía como objetivo (menos de 10 usuarios concurrentes), Node.js era más que suficiente. Antes de evaluar Bun, también hice pruebas con Node.js + Hono y, sinceramente, a mí me parecía que no había ningún problema. Sin embargo, el rendimiento abrumador que prometía Bun, junto con el rendimiento de ElysiaJS, que se basa en Bun, me impresionaron muchísimo y no quise renunciar a eso. Como yo pensaba que ya debía existir por ahí algún excelente foro hecho sobre Node.js por otra persona, creí que para competir con ese foro imaginario necesitaba un rendimiento todavía mayor, y al final terminé renunciando a la compatibilidad con Node.js y diseñándolo de forma dependiente de Bun. (Ahora me arrepiento un poco. Resulta que no había... ¿foros famosos basados en Node.js como GnuBoard, Rhymix o XE? ¿O fui yo el que no supo encontrarlos?)
Lo que comentaste es totalmente cierto. Si quieres conseguir tráfico desde buscadores, al final Google tiene que poder leer el contenido y hacer el matching para las búsquedas. Esta parte todavía no la he implementado, pero estoy pensando que, si el usuario lo desea, quizá se podrían compartir por separado los contenidos más recientes en una forma estática, como si se expusiera un feed RSS. También he pensado que, si se expone externamente en formato JSON, a los recolectores les sería más fácil actualizar los datos. Lo seguiré pensando un poco más. (Había pensado en RSS, pero parece que hoy en día casi nadie usa eso, ¿no? Tal vez llevo demasiado tiempo alejado de la web T_T)
Independientemente de las medidas para complementar el SEO, la razón por la que elegí CSR fue porque quería reducir de forma más activa la carga del servidor. Hasta donde sé, incluso en el caso del sitio Damoang, que apareció recientemente (no sé si se puede mencionar así sin problema el nombre de una comunidad), la carga de tráfico y del servidor es bastante considerable. Al pensar en algo como un community builder, el SEO también es importante, pero primero quise resolver lo que impacta directamente en los costos, así que prioricé CSR. Yo, que todavía sigo queriendo mucho a PHP, en realidad me siento más cómodo con SSR, pero pensé que si el cliente usa de manera más activa su poder de cómputo, quizá el servidor podría recuperar algo más de margen. Podrías verlo como una decisión tomada con esa idea.
Espero que esto haya aclarado un poco tus dudas. Y además, como las decisiones que tomé tienen ventajas y desventajas muy claras, en realidad no creo que TSBOARD sea la respuesta correcta. Solo diría que fueron decisiones que tomé considerando varios trade-offs, dentro de lo limitado de mi perspectiva. Si más adelante TSBOARD llega a usarse mucho más, siempre podría cambiar de opinión e intentar otras cosas. jaja
Como ya está diseñado para CSR, parece que para cambiarlo a SSR haría falta un trabajo casi al nivel de rehacerlo por completoT_T
Últimamente dicen que los crawlers de búsqueda también han mejorado un poco en el soporte de JS, pero... de todos modos, no creo que puedan igualar a HTML puro.
En un navegador normal se podría manejar con CSR, pero en el caso de los bots de búsqueda (GoogleBot, Yeti, etc.), también podría existir una forma de procesarlo con SSR.
Personalmente, creo que ese tipo de enfoque es una solución temporal y que, al final, si se quiere dar buen soporte a SEO, quizá SSR sea la respuesta correcta.
Incluso si es CSR, cuando al final aumenta mucho el volumen de solicitudes, se generará carga en el backend, así que parece buena dirección reducir esa carga mediante un diseño de caché y varios mecanismos^^;
En el caso de TSBOARD, como mencionaste, todo está hecho con base en CSR, así que parece que al menos en la versión v1.y.z habrá que trabajar con un enfoque solo CSR. Si pensamos en algunas mejoras, como la estructura hace que todos los posts aparezcan en la primera pantalla, podríamos aplicar SSR solo en esa primera pantalla, o bien, como dijiste, agregar una página aparte para que los bots puedan rastrear la parte de HTML plano. Intentaré reflejar medidas de mejora en la línea de versiones v0.9.z.
Ah, por cierto, me preocupa un poco que haya personas que piensen “¡TSBOARD no se puede encontrar en búsquedas porque usa CSR!”, así que quisiera comentar que, en el caso de Googlebot, según entiendo ya ha mejorado lo suficiente como para poder indexar también el contenido de sitios web hechos con CSR. (¿Será porque es Google...?) Está claro que es un enfoque desfavorable para SEO, pero no significa que no funcione en absoluto, así que creo que no hace falta preocuparse demasiado.
No solo existen CSR y SSR, también debe haber enfoques intermedios, así que lo pensaré un poco más y también intentaré definir una hoja de ruta para v2.0.0 con el objetivo de mejorar el SEO. (Aunque todavía falta bastante jaja). Gracias por el consejo, y aunque es un proyecto al que aún le falta mucho, les pido su apoyo para TSBOARD.