Carson Gross es el creador de HTMLX y Hiperscritola mente detrás El desarrollador con cerebro de Gruga profesor de ingeniería de software en la Universidad Estatal de Montana y coautor de Sistemas hipermedia.
Fue un placer escuchar a Carson sobre el ímpetu detrás de proyectos como HTMX e Hyperscript, los fracasos de REST, por qué JavaScript llegó para quedarse y mucho más.
Tyson: Es difícil elegir por dónde empezar aquí, así que voy a seguir con Desarrollador cerebral Grug. Siento que podría recomendar a todos allí para todas las preguntas relacionadas con la programación.
Bruto: Ja, lo aprecio. Creo que vale la pena leerlo para la mayoría de los desarrolladores. Sin embargo, lo orienté hacia desarrolladores más jóvenes. Ciertamente no es perfecto (es difícil serlo cuando usas una voz de cavernícola y tratas de ser gracioso), pero creo que la mayoría de los consejos son sólidos.
Tyson: Es cierto que la mayoría de los problemas de codificación en los que me he metido fueron principalmente el resultado de pensar que era inteligente.
Bruto: Sí, creo que todos los que han programado durante un tiempo han experimentado ese punto en el que te das cuenta de que has profundizado demasiado y ya no puedes mantener el sistema en tu cabeza. No sé si es siempre pensar que eres demasiado inteligente o simplemente no reconocer cuando las cosas empiezan a complicarse demasiado. Además, la dinámica social en los trabajos tecnológicos castiga a las personas que dicen cosas como: «Esto es demasiado complicado para mí».
Tyson: Eso es muy cierto acerca de la atmósfera que rodea a admitir que es demasiado complicado. Una vez hablé con un amigo: «JavaScript es tan flexible que puedes codificar cualquier cosa» y él me respondió: «Jaja, esa es una charla peligrosa». Él estaba en lo correcto.
¿Tienes alguna idea sobre javascript como idioma?
Bruto: Creo que JavaScript es un buen lenguaje de programación. En mi opinión, no es un gran lenguaje de propósito general. De una manera un tanto extraña, me parece C++: ahora tiene demasiadas características y formas de hacer las cosas. Por otro lado, JavaScript tiene una característica increíble: está ahí, en el navegador. Y eso, en mi opinión, lo convertirá en el principal lenguaje de programación para la web en el futuro previsible.
Tyson: Estoy bastante impresionado por Hiperscrito, pero tengo la sensación de que es algo divertido para ti. ¿Podría contarnos sobre la experiencia técnica en la implementación del analizador, etc.?
Bruto: Seguro. Hyperscript es un lenguaje de secuencias de comandos que «compite» con JavaScript como una opción para las secuencias de comandos front-end. Está basado en HyperTalk, el lenguaje de secuencias de comandos para HyperCard, y tiene características que creo que mejoran la experiencia de creación cuando simplemente intentas escribir secuencias de comandos en una página web. Por ejemplo, el tiempo de ejecución de Hyperscript resuelve automáticamente las promesas que encuentra, por lo que los escritores de guiones no necesitan ocuparse de ellas. Tiene una sintaxis natural, similar a la del inglés, que a algunas personas les encanta y muchas odian. Definitivamente es un proyecto que me apasiona, pero espero llegar a la versión 1.0 este año, después de que se lance HTMX 2.
En cuanto a su implementación, sí, se implementa en JavaScript como un tiempo de ejecución basado en lexer, analizador y evaluación. Me sorprendió que el tiempo de ejecución de JavaScript fuera lo suficientemente rápido como para permitirme salirme con la mía, pero lo es. No intentaría implementar un minero de Bitcoin en Hyperscript, pero es lo suficientemente rápido para secuencias de comandos DOM ligeras. El analizador y el tiempo de ejecución de Hyperscript están justo al borde de la complejidad que estaría dispuesto a asumir con JavaScript.
Tyson: HTMX es otra codificación impresionante. Mi introducción aHTMX fue uno de los artículos más leídos en InfoWorld el año pasado, lo que demuestra que hay mucho interés en él. Este proyecto también parece más serio, ya que busca restablecer al menos la posibilidad de una verdadera arquitectura REST.
Bruto: Sí, ha sido un año salvaje para HTMX. Para los lectores que no han oído hablar de ella, HTMX es una biblioteca de JavaScript que escribí y que permite agregar atributos, muy similar en espíritu a la href y action atributos de enlaces y formularios en HTML estándar. Usando esos atributos, puede activar solicitudes AJAX y luego reemplazar partes del DOM con el HTML con el que responde el servidor.
Tyson: Yo diría que HTMX extiende el vocabulario del buen HTML para cubrir algunos casos de uso modernos, en particular, AJAX. ¿Es esa una descripción justa?
Bruto: Sí, esa es una buena manera de explicarlo. A veces digo que HTMX «completa HTML como hipermedia» en el sentido de que permite que cualquier elemento de la página emita una solicitud HTTP en respuesta a un elemento y luego coloque esa respuesta en cualquier lugar del DOM.
Probablemente suene bastante simple, y lo es, pero con solo esa pequeña generalización de HTML, desbloqueas muchos patrones de UX que tradicionalmente han estado reservados para JavaScript. Los ejemplos incluyen desplazamiento infinito, carga diferida de secciones de una página y validación del lado del servidor mientras se escribe.
Tyson: Debo decir que pensé que sabía bastante lo que significaba REST, pero estuve equivocado durante mucho tiempo. En tu artículo abordas cómo surgió eso, ¿Cómo llegó a significar REST lo opuesto a REST?
¿Le importaría resumir para los lectores la diferencia entre REST según lo previsto y REST tal como se implementa comúnmente?
Bruto: *risas* Bueno, no vamos a cambiar la forma en que la industria utiliza el término REST. Hoy en día, ese término significa «API JSON sobre HTTP» y eso es lo que probablemente significará durante el resto de nuestras carreras.
Sin embargo, eso no es lo que originalmente significaba REST. En cambio, REST era una descripción de la forma en que funcionaba la World Wide Web (su arquitectura de red) antes de que existieran las API JSON; solo enlaces y formularios que impulsan las interacciones a través de un navegador. El término DESCANSAR Provino de una famosa disertación de Roy Fielding, y definió una serie de restricciones a las que debe ajustarse un sistema RESTful.
Hoy en día, la mayoría de las API JSON denominadas «RESTful» no satisfacen esas restricciones. Aún más gracioso, un sitio web estático simple con un par de páginas HTML que enlazan entre sí. hace satisfacer todas esas restricciones. Por lo tanto, alguien que crea un sitio web estático simple es, en cierto nivel, un mejor ingeniero «REST» que las personas con sofisticados títulos de ingeniero API JSON «RESTful» en sus currículums.
El lenguaje no va a cambiar, pero creo que vale la pena entender el significado original del término y, en particular, lo que se llama interfaz uniforme restricción de REST para comprender realmente por qué la web es tan flexible.
Tyson: No he asistido a una clase de programación desde principios del milenio. ¿Todavía usas libros? Es una broma. (Creo.)
¿Cómo es ser profesor de programación? Puedo tomar CSCI 468 ¿de ti?
Bruto: ¡Ja! Bueno, si quieres tomar 468, que es la clase de compiladores que enseño, puedes simplemente leer Elaboración de intérpretes por Bob Noystrom y obtener alrededor del 50%. Nos dirigimos a la JVM con código de bytes en el back-end y, para ser honesto, eso no es tan interesante a menos que seas un gran experto en Java.
Me gusta enseñar. Definitivamente hay desventajas: el salario es una mierda y hay que lidiar con la burocracia. Pero hay muchas ventajas y disfruto haciendo que los estudiantes superen el obstáculo hasta que sientan que pueden programar por sí mismos.
Tyson: Sí, definitivamente lo soy un chico de Java.
Entonces, esto es volver un poco al tema REST, pero desde una perspectiva más elevada. Eres coautor de Sistemas hipermedialo que demuestra que la forma en que está diseñada la web proporciona una arquitectura de aplicación sobre la que podemos construir, si la analizamos correctamente.
Bruto: Definitivamente, y HTMX intenta aprovechar esa arquitectura de red mejorando HTML como hipermedia, en lugar de reemplazar esa arquitectura original por una nueva, es decir, API de datos JSON de formato fijo. En el libro, intento esbozar la naturaleza sistémica del funcionamiento adecuado de los hipermedia. Por ejemplo, durante mucho tiempo no me di cuenta de lo importante que era el cliente hipermedia (por ejemplo, los navegadores) para que la interfaz uniforme funcionara correctamente. Realmente es necesario tener un sistema completo (hipermedia como HTML, un protocolo de red como HTTP, servidores hipermedia y clientes hipermedia) para que todo funcione según lo previsto.
Tyson: Para terminar, me gustaría resumir todo lo importante en unos cuantos comentarios breves y divertidos, pero ya hecho eso. Intento encontrar cosas con las que no estoy de acuerdo en la filosofía de Grug, pero realmente no puedo. Complejidad de expresión, cierres, diciendo no … grug tiene buenos consejos para todos estos temas.
Pero tengo curiosidad por Los sentimientos de Grug sobre el patrón de visitante.. Lo usé y pensé que fue bien. Al final, el proyecto no se envió, pero el código era sólido. Dime qué pasa con el patrón de visitantes.
Bruto: Sí, no estoy 100% en contra del patrón de visitantes, a pesar de lo que dice el ensayo de grugbrain. (En general, no estoy 100% a favor o en contra de nada en el desarrollo de software). Sin embargo, a menudo pienso que es mejor codificar operaciones directamente en un árbol en lugar de tener otra cosa lateral que realice operaciones sobre el árbol. A veces esto mezcla un poco las preocupaciones, pero eso no me importa en este caso.
Como ejemplo, en Hyperscript, los elementos del árbol de análisis tienen los métodos de evaluación definidos y se definen directamente en el lugar donde se analizan. Esto mezcla preocupaciones, pero creo que agrega claridad al programa, porque cuando quieres entender cómo, por ejemplo, funciona el comando «esperar», puedes ir a un lugar y ver cómo se analiza y evalúa. Lo encuentro muy útil.
Tyson: ¿Por qué sabemos que la complejidad es mala para nosotros pero de todos modos nos sentimos atraídos por ella?
Bruto: Bueno, una vez más, creo que aquí hay presiones de la industria en juego. El software es una industria brutal y parecer poco inteligente puede perjudicar gravemente su carrera. Esto significa que todos sentimos presión para demostrar que somos inteligentes, y también sentimos presión para no admitir que el código de otra persona es confuso o nos parece demasiado complicado. En muchos círculos, “sofisticado” es elogio y “tonto” es crítica.
Entiendo esa dinámica y comprendo a los ingenieros que sienten esas presiones. Esta es una de las razones por las que sugiero que los ingenieros superiores que tienen una posición segura en una organización de ingeniería proclamen en voz alta que las cosas les parecen demasiado complicadas, si en realidad así es. Esto también permite que los ingenieros más jóvenes expresen sus preocupaciones y alivia esas presiones organizativas, al menos hasta cierto punto.
Copyright © 2024 IDG Communications, Inc.
