¿Seaside sigue siendo una opción válida?

Question

Seaside just released un candidato de lanzamiento para la próxima versión 3.0, por lo que apareció en mi radar de nuevo. Como actualmente estoy reflexionando sobre qué marco web usar para un proyecto futuro, me pregunto si es algo a considerar. Lamentablemente, la mayor parte de la publicidad de Seaside data del '07, que probablemente sea una o dos generaciones para la web. Así que espero que la comunidad aquí puede responder a algunas preguntas

1. marcos basados ​​en la recuperación estuvieron bastante grande cuando la mayor parte de su flujo de trabajo fue principalmente en HTML, por ejemplo, formulario presentado. Para los entornos pesados ​​de JavaScript de hoy en día, eso ya no parece merecer la pena.

2. ¿Squeak puede manejar una carga de trabajo razonable? A partir de otras preguntas aquí y en otras partes, parece que para una escala adecuada, otra implementación (Gemstone, etc.) probablemente se iría mejor a la larga, pero no tengo una idea adecuada de cuán lejos está eso. Las sesiones parecen ser bastante costosas.

3. Sé que las comparaciones son difíciles, pero la mayoría de los artículos que se encuentran en la red establecen Seaside and Rails uno al lado del otro. ¿Cómo harían combinaciones como Scala/Lift, Clojure/Compojure o Erlang/Nitrogen?

Answer 1

que tienen respuestas a la pregunta de uno y dos:

1. Esto es cierto. Sin embargo, desde la versión 2.8 Seaside ya no es un marco estrictamente "basado en la continuación". Seaside usa continuaciones solo en el módulo de flujo. Desde Seaside 3.0, el módulo de flujo es incluso opcional. También tenga en cuenta que Seaside tiene un fuerte soporte de Javascript desde 2005, esto es mucho antes de que los marcos principales comenzaran a agregar la funcionalidad de Javascript. En la actualidad, Seaside cuenta con la compatibilidad incorporada de JQuery y JQueryUI.
2. Por supuesto, eso depende de lo que almacene dentro de los objetos de la sesión, pero normalmente las sesiones son pequeñas (menos de 20 KiB). Use el generador de perfiles de memoria en su aplicación para determinar el consumo exacto de memoria.

Answer 2

En Smalltalk tenemos ahora tres marcos de Internet para tener en cuenta, además de Mar también

• Aida/Web y
• Iliad.

Ambas soluciones resuelven de manera efectiva el flujo de control similar a tres, pero sin necesidad de continuar. Ambos también tienen una integración Ajax muy fuerte, en realidad ya no te das cuenta de que estás trabajando con Ajax.

Ambos también escalan bien el consumo de memoria. 10.000 sessions spend 220MB en Aida/Web, eso es aproximadamente 23 KB por sesión, que puede optimizarse aún más hasta 400B por sesión. Esto significa que puede ejecutar no solo muchos sitios web desde la única imagen de Smalltalk. Por supuesto, siempre puede actualizar a la solución de equilibrio de carga, cuando realmente lo necesita. Que es de mi experiencia muy raramente necesaria.

En comparación con Ruby on Rails, un amigo mío se quejó de que necesita 50 MB de memoria inicialmente para cada sitio web de la tienda que está vendiendo. Luego recurrió a la solución Aida/Web, donde necesita aproximadamente el mismo MB para la imagen, pero luego solo unos pocos KB por cada sitio web adicional de la tienda.

Answer 3

Y hay un nuevo libro costera: http://book.seaside.st/book

Answer 4

encuentro la productividad del trabajo en un IDE Smalltalk con un buen conjunto de abstracciones outweights todos los otros temas en los proyectos de ingeniería dominada. Funciona bien como un sistema empresarial para una empresa pequeña con aproximadamente 100 (usuarios simultáneos, pero no pesados) en un único servidor (sin ir a SSD). Desde 2007:

• Seaside ha demostrado ser capaz de realizar el cambio de flujos de trabajo html a javascript;
• Seaside ha sido portado a un montón de Smalltalks diferentes;
• Ha visto Gemstone lanzar GLASS;

El nuevo 'cog' vm con un rendimiento mucho mejor ha sido lanzado hace unas semanas y muestra una gran promesa para un mejor rendimiento.

Answer 5

Avi Bryant, el desarrollador de Seaside, dijo que AJAX triunfa en todas las situaciones. Sin embargo, también puede crear aplicaciones razonablemente potentes con Seaside y AJAX.

La aplicación de una aplicación web se puede realizar en otros marcos bastante bien utilizando Ajax.

Creo que falta un Framework integrado Smalltalk-to-Javascript Seaside como Cappuccino-for-Clamato, actualmente. Me gustaría poder crear aplicaciones Javascript reales usando Smalltalk.

Answer 6

1. Javascript es increíble, pero ser capaz de lidiar con un flujo de trabajo complicado de una manera limpia y económica en el lado del servidor (como Seaside lo permite) impide que se vuelva obsoleto. La economía y la utilidad son cosas que dan resultados a corto y largo plazo. Pero decir esto en abstracto no tiene ningún valor en absoluto. Debería hablar de una aplicación precisa y decidir si la orilla del mar es parte de su grupo de ventajas competitivas para formar una ecuación que oscile (y saber por qué).
2. Acerca de la ampliación de la carga de trabajo con Seaside, la respuesta corta es que puede escalarlo como el infierno yah (para la respuesta larga, consulte mi respuesta aquí: Does Seaside scale?).
3. hombre también sin respuesta :) rtY una variación de lo que realmente está tratando de pedir

Creo que lo mejor que puede hacer es un prototipo de algo en un fin de semana.

Si puedes hacer un prototipo en dos días y puedes atraer algo de atención y disfrutaste de la experiencia en desarrollo de hacerlo junto al mar, entonces tendrás la base de lo siguiente.

Solo le cuesta su tiempo (puede publicar en un servidor amazon).

Por cierto, esta semana escuché sobre una startup que hizo su prototipo a mano (era todo estático y procesaron cosas manualmente). Bastante sorprendente y loco y barato. Cuando sintieron que tenían suficiente influencia en la idea (que la tenían) implementaron la aplicación (con cualquier tecnología, estoy seguro que no es un desafío para un desarrollador de mar)