smalltalk seaside

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



(6)

Seaside acaba de lanzar un lanzamiento de candidato 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í pueda responder algunas preguntas

  1. Los marcos basados ​​en la continuación fueron geniales cuando la mayor parte de su flujo de trabajo era principalmente en HTML, por ejemplo, envíos de formularios. 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 encuentras 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?

  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 escalar la carga de trabajo con Seaside, la respuesta corta es que puedes escalarlo como el infierno yah (para la respuesta larga, comprueba mi respuesta aquí: ¿Seaside scale? ).
  3. hombre demasiado incontestable :) rty una variación de lo que realmente estás tratando de preguntar

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

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

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

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

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 usando Ajax.

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

En Smalltalk tenemos ahora tres frameworks web a considerar, además de Seaside

Posteriormente, ambos resolvieron efectivamente 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 sesiones gastan 220 MB en Aida / Web, es decir, unos 23 KB por sesión, que se pueden optimizar aún más hasta 400 B 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.

Comparando con Ruby on Rails, un amigo mío se quejó de que necesita 50MB de memoria inicialmente para cada sitio webshop 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.

Encuentro que la productividad de trabajar en un IDE Smalltalk con un buen conjunto de abstracciones supera a todos los demás problemas en proyectos dominantes de ingeniería. 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 que puede hacer el cambio de flujos de trabajo html a javascript;
  • Seaside ha sido portado a un montón de Smalltalks diferentes;
  • Ha visto a 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.

Tengo respuestas a la pregunta uno y dos:

  1. Esto es verdad. 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 sus objetos de sesión, pero por lo general 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.