Pregunta

Por día, soy un desarrollador web de aplicaciones para usuario, pero en mi tiempo libre me meto con otros lenguajes como C, Objective-C, Python, etc. Cuando empecé en el desarrollo web, la idea de las aplicaciones web era simplemente empezando.

Desde entonces, han aparecido dos marcos sorprendentes, SproutCore's SproutCore y 280 North's Cappuccino (+ Objective-J). SproutCore está siendo utilizado por Apple para su aplicación MobileMe y 280 North lanzó 280 Slides. Ambas aplicaciones son increíbles y son un testimonio de lo que es posible en la web. Así que el impulso está cambiando. Las aplicaciones web comienzan a verse y actuar como aplicaciones de escritorio.

Entonces, mi pregunta es esta: ¿deben las aplicaciones basadas en la web seguir los estándares web, la separación del marcado (contenido), la presentación (diseño) y el comportamiento (funcionalidad) o no?

No estoy seguro de SproutCore ya que no he mirado el código fuente, pero sé que si vas a 280slides.com y desactivas el JavaScript, todo desaparece. Te quedan algunas palabras sin sentido.

Permítame aclarar, entiendo que las aplicaciones basadas en web como 280 Slides están diseñadas para tener JavaScript activado y no para ser funcionales sin él, pero en mi trabajo diario mi principal objetivo es escribir un marcado limpio, separar el contenido, la presentación y comportamiento para que nuestro sitio y aplicaciones puedan ser utilizados por tantas personas como sea posible.

¿Fue útil?

Solución

Parece que las otras personas que han respondido hasta ahora no tienen ni idea de lo que estás hablando.

Al igual que yo, lo has golpeado en la cabeza para hacer que tus aplicaciones web sean lo más accesibles posible. Es decir, deberían funcionar sin scripts y sin hojas de estilo. JavaScript y CSS solo deben usarse para mejorar la experiencia. No deben ser requeridos.

SproutCore y Cappuccino son marcos para el desarrollo de front-end que requieren que el usuario tenga habilitados JavaScript y CSS. Su pregunta es acerca de cómo reconciliar esto con el dogma del día.

Desafortunadamente, no tengo una respuesta clara. Me gusta el hecho de que SproutCore y Cappuccino (y probablemente otros) estén probando los límites de lo que es posible dentro de un navegador web. También creo firmemente que la información y los servicios provistos en la web deberían estar disponibles para la mayor cantidad de personas, dadas las limitaciones de la tecnología.

La forma en que aborda sus soluciones debe basarse en un profundo conocimiento de su base de usuarios. Si está trabajando en una aplicación de iPhone, no necesita preocuparse por la accesibilidad tradicional a la web, ya que la experiencia es intensamente visual. Si está creando una aplicación web para una audiencia general, estos nuevos marcos probablemente sean una mala elección (si valora el acceso más amplio posible a su información y servicios).

Con el tiempo, es probable que el software del lector de pantalla mejore su interpretación de las interfaces con JavaScript pesado, por lo que quizás este problema se desvanezca. La cosa es que otra cosa es probable que " brote " arriba en su lugar.

Otros consejos

Javascript es un estándar web, ciertamente más que, por ejemplo, Flash, que anteriormente se usaba (y todavía se usa) para aplicaciones web ricas. En este sentido, SproutCore y Cappuccino son mejoras gigantescas en mi libro.

La pregunta aquí realmente parece ser cuán importante es la accesibilidad. Y esa es en gran parte una decisión personal basada, como dijo Andrew, en conocer a sus usuarios. Para algunas aplicaciones, la accesibilidad realmente no tiene mucho sentido, 280 Slides es un buen ejemplo de esto. Es una aplicación de diseño gráfico que se trata en gran medida de comportamientos visuales. No tiene mucho sentido degradarlo a texto plano. (Al menos, una aplicación basada en texto destinada a lograr lo que hace 280 Slides sería algo completamente diferente).

Sí. Al principio será difícil, pero una vez que el código base madure, estarás agradecido de haber seguido esos rigurosos estándares.

Editar: un beneficio adicional será la portabilidad a muchas plataformas basadas en web a través de perfiles CSS y otras cosas.

El modelo MVC se puede aplicar tan fácilmente a las aplicaciones de escritorio como a las aplicaciones basadas en web. No veo muchas razones para distinguir entre los dos, especialmente porque la línea es más borrosa en el caso de las aplicaciones web.

No conozco estos marcos en particular, pero muchos marcos web en la actualidad están estructurados en torno al modelo MVC, como ASP MVC, CakePHP, Ruby on Rails, etc.

Separe tanto como pueda y se pagará al final. Cuando las cosas se complican y se vuelven peludas :)

Creo que deberían. Siguiendo ese tipo de MVC design permite que los cambios se implementen más fácilmente, proporciona buena separación de preocupación , y generalmente es más fácil de entender para los recién llegados a un proyecto.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top