haskell - framework - happstack
Comparando los frameworks web de Haskell Snap y Yesod (4)
Los dos frameworks web de Haskell en las noticias recientemente son Yesod (en 0.8) y Snap (en 0.4).
Es bastante obvio que actualmente Yesod admite muchas más funciones que Snap. Sin embargo, no soporto la sintaxis que Yesod usa para su HTML, CSS y Javascript.
Entonces, me gustaría entender lo que me estaría perdiendo si en lugar de eso fuera con Snap. Por ejemplo, no parece que el soporte de base de datos esté ahí. ¿Qué hay de las sesiones? ¿Otras características?
Aviso justo: soy el desarrollador principal de Yesod.
No estoy seguro de lo que no le gusta de la sintaxis de Javascript: es un javascript sencillo con interpolación de variables. En cuanto a CSS, Yesod ahora tiene Lucius, que le permite usar también CSS simple. Para HTML, puede usar fácilmente cualquier otra biblioteca que desee, incluido Heist (lo que Snap usa). Dicho esto, es un poco extraño omitir Yesod sobre la sintaxis CSS / Javascript, cuando Snap ni siquiera tiene una sintaxis para ello. Usted es bienvenido a su solución de archivos estáticos.
Yesod viene con soporte sin problemas para autenticación / autorización, URL seguras para el tipo, widgets, correo electrónico y un montón de cosas pequeñas por todas partes (ruta de navegación, mensajes, destino final). Además, Yesod tiene un conjunto bastante rico de paquetes complementarios para cosas como comentarios y rebajas, y algunas bases de código grandes del mundo real para seleccionar ejemplos. Si alguno de estos le resulta atractivo, es posible que desee verificar si sus alternativas los respaldan.
Probablemente te refieres a la versión antigua de yesod. Las últimas versiones de yesod tienen una sintaxis simple para html, javascript y css.
La sintaxis html de la biblioteca de plantillas de yesod es html simple con etiquetas de apertura y cierre completas y todos los atributos html normales. Sí, puede omitir el cierre de etiquetas y utilizar accesos directos para los atributos de identificación y clase. Pero no tienes que hacerlo. Puedes seguir escribiendo html plano.
No solo eso, sino que las plantillas html pueden residir en archivos separados, al igual que en la biblioteca de plantillas de Snap Heist.
Las plantillas de script Java (julius) son archivos de JavaScript simples, que también residen en archivos separados.
La plantilla css sí tiene una sintaxis diferente, pero la versión reciente de yesod ahora también ofrece una sintaxis css simple.
Si vas con Heist no tendrás urls de tipo seguro.
En Heist, las plantillas html se leen desde el disco duro cada vez. Yesod compila todas las plantillas directamente en el ejecutable. No se lee ningún archivo del disco duro. Así la respuesta es mucho más rápida. Puedes ver los puntos de referencia tú mismo.
En Yesod puedes crear widgets que cooperen bien. Snap no se ocupa de los widgets en absoluto. Tendrás que rodar el tuyo.
Prueba Hamlet, podrías terminar gustándote. Una reacción negativa a nivel superficial no es infrecuente. Sin embargo, nadie que haya utilizado realmente hamlet se queja.
Además, ¿por qué no usar Happstack? El hecho de que no estén "en las noticias" no significa que no tengan un marco sólido.
Revelación completa: soy uno de los principales desarrolladores de Snap.
En primer lugar, hablemos de lo que es Snap. En este momento, el equipo Snap mantiene cinco proyectos diferentes en hackage: snap-core, snap-server, heist, snap y xmlhtml. snap-server es un servidor web que expone la API definida por snap-core. El robo es un sistema de plantillas. xmlhtml es una biblioteca de análisis y representación XML / HTML utilizada por heist. snap es un proyecto general que los une a todos y proporciona la poderosa API de snaplets que hace que las aplicaciones web sean compuestas y modulares.
Yesod tiene una gran cantidad de proyectos sobre hackage. La mayoría (todos?) De ellos se enumeran en la categoría de Yesod . Algunos de los notables son yesod-core, warp, persistente y hamlet.
La realidad del desarrollo web de Haskell es que es mucho menos una opción exclusiva que lo que parece percibirse. En general, los proyectos están muy débilmente acoplados y son bastante intercambiables. Podría crear un sitio web utilizando warp (el servidor web del equipo de Yesod), el robo (el sistema de plantillas del equipo Snap) y el estado ácido (el sistema de persistencia del proyecto Happstack). También puedes usar snap-server con hamlet o persistente.
Dicho esto, los dos proyectos definitivamente tienen algunas diferencias. La mayor diferencia que puedo señalar de manera objetiva es que los proyectos de Yesod suelen hacer un uso intensivo de Template Haskell y quasiquoting para crear DSLs concisos, mientras que los proyectos Snap se adhieren a la creación de bibliotecas combinadoras que favorecen la capacidad de composición. Casi cualquier otra diferencia que pueda pensar será subjetivamente sesgada hacia Snap. Obviamente, los paquetes paraguas que llevan el nombre de los dos proyectos harán elecciones específicas para los componentes mencionados anteriormente, y estas elecciones se reflejarán en las dependencias del proyecto. Pero eso todavía no significa que no puedas usar algo diferente y usarlo también.
Snap tiene sessions y authentication , interfaces con varias bases de datos y un manejo agradable de formularios ( here y here ) usando digestive-functors que incluyen soporte preempaquetado para listas de tamaño considerable dinámicamente anidadas. Estos son solo algunos de los ecosistemas en crecimiento de snaplets conectables . Las sesiones y los snaplets de autenticación se escriben de una manera que es independiente del back-end. Así que con una pequeña cantidad de código de pegamento debería poder usarlo con casi cualquier sistema de persistencia que se pueda imaginar. En el futuro, Snap mantendrá esta política con la mayor frecuencia posible.
En su mayor parte, creo que la elección de Snap vs Yesod vs Happstack es menos una cuestión de características y más un gusto personal. Cada vez que alguien dice que uno de los marcos no tiene algo que otro tiene, la mayoría de las veces será bastante fácil extraer la funcionalidad que falta del otro marco al importar el paquete necesario.
EDITAR: para una comparación más detallada de los tres grandes marcos web de Haskell, consulte mi reciente publicación en el blog . Para una comparación más áspera (pero posiblemente más útil) que usa algunas generalizaciones más amplias, vea mi Matriz de Comparación de Haskell Web Framework