En nuestra empresa, necesitamos construir una interfaz web en una plataforma Linux integrada. Veo 2 opciones: utiliza una tecnología en la que el HTML y JavaScript se generan en el lado del servidor (Think JSP, Grails, pero es algo que está utilizando C ++ y genera HTML / JavaScript) o crea un 'cliente' HTML5 aplicación que habla con un backend generador de JSON o XML.

Tengo la sensación de que las aplicaciones web actualmente tienden a ir con la última, pero ¿cuáles son las ventajas de hacerlo? (Los desarrolladores del proyecto eligen la primera, principalmente porque saben que C ++ es mucho mejor que HTML y Javascript)

AJAX

Creo que su pregunta se reduce a "¿Debería mi aplicación web generar HTML en el lado del cliente o del servidor?" La generación del lado del cliente se comunica con el servidor utilizando AJAX, aunque la X (XML) generalmente se ha reemplazado con JSON, pero la mayoría de las personas todavía lo llaman AJAX porque suena mejor. Del lado del servidor, el servidor solo crea HTML en el servidor.

Tengo mucha experiencia con XML y casi ninguna con JSON. Todo lo que sé sobre XML me hace sugerir que use JSON si es posible.

AJAX Pros:

• Envíe menos datos a través de HTTP (S) para que puedan ejecutarse más rápido.
• El servidor es esencialmente un servicio web para que otras personas (o usted) puedan escribir sus propios clientes. Esto puede ayudar al crear una versión móvil de su sitio. Además, muchos inventos se vuelven populares por razones que su creador nunca tuvo la intención. Los servicios son más amigables para las personas que encuentran nuevos usos para su código.
• Parece una nueva aplicación

AJAX Contras:

• Depuración de JavaScript
• ¿Complejidad?
• Las cosas que puede hacer con JavaScript a menudo son completamente imposibles de usar para personas ciegas o discapacitadas.
• Puede requerir más código total (mayor almacenamiento general en su dispositivo integrado)

Servidor de cliente

Todas las aplicaciones web usan arquitectura cliente-servidor. El protocolo HTTP obliga a las aplicaciones web a comportarse de esa manera. AJAX utiliza una solución alternativa para esa limitación de diseño, pero el modelo básico subyacente de HTTP sigue siendo cliente-servidor. No me obsesionaría con la mejor forma de aplicar MVC a las aplicaciones web. Si tiene que hacer MVC por razones políticas, mire cómo lo hace Ruby / Rails. En realidad, Rails es una gran arquitectura para copiar (o usar).

Servicio vs. App.

Un buen servicio es casi siempre mejor que una aplicación. ¡Pero hacer un buen servicio es difícil! Es posible que deba realizar la aplicación antes de poder escribir una especificación diseñada lo suficientemente bien para un servicio. No haga su trabajo más difícil de lo que debe ser. Para la versión 1, concéntrate en hacer una gran aplicación. Hasta que su aplicación sea relativamente estable y esté seguro de que cumple con los requisitos de su usuario, tener un servicio probablemente no le servirá de ninguna manera. Diseñar el servicio incorrecto demasiado pronto es una pérdida de tiempo que sigue perdiendo a medida que intenta arreglar su interfaz de servicio y lidiar con la refactorización masiva del código del servidor y del cliente que seguirá.

C / Web

Guau. Trabajé en C y Asamblea durante 3 años antes de cambiar al desarrollo web. No puedo pensar en un lenguaje peor para escribir una aplicación web, especialmente desde un punto de vista de seguridad. La validación de entrada y el escape de salida son tan críticos ... SANS publica una lista de los errores más comunes cada año. Desbordamientos de búfer, inyecciones, problemas entre sitios (codificación de salida incorrecta) ... Todos estos errores son realmente fáciles de hacer en C o ensamblaje. Al menos un lenguaje como Java tiene una cadena que es inmune a los desbordamientos y un mecanismo de manejo de excepciones que generalmente evita que los errores fuera de uno permitan que el código malicioso acceda a la memoria del sistema. Sin mencionar el manejo de juegos de caracteres internacionales (use UTF-8 cuando sea posible).

Si necesita usar C por razones de memoria o firmware, entonces eso es lo que debe hacer. ¡Sólo sé cuidadoso!

Soporte de navegador

El primer paso para crear una aplicación web es descubrir qué navegadores utilizarán sus clientes. W3Schools y Wikipedia son buenas fuentes de estadísticas generales, pero YMMV.

Donde trabajo ahora, actualmente validamos que nuestra aplicación solo crea HTML de transición XHTML 1.0 válido. También utilizamos el Doctype y el formato específicos necesarios para evitar el Modo Quirks en IE, lo que hace que el HTML entre navegadores sea más fácil de escribir (ver consejos en mi blog ). Probamos en las últimas 3 versiones de IE, además de Firefox y Chrome en Windows y Linux (Safari usa el mismo motor de renderizado que Chrome). Con esa validación y prueba, nuestra aplicación funciona prácticamente en todas partes (Windows, Mac, Linux, iPhone, Android, etc.) excepto BlackBerry.

BlackBerry nunca ha tenido un navegador real con JavaScript, por lo que no lo admitimos. Los usuarios de BlackBerry están acostumbrados a no tener un navegador web real, por lo que no se quejan. Tal vez eso está cambiando? Intentaría preguntar a algunos clientes qué navegadores están utilizando y asegurarme de probar con esos navegadores.

Resumen

Todos los sitios web están construidos en HTML y HTTP. Tenga a mano una buena referencia de estas tecnologías mientras realiza su aplicación. En el curso de la creación de una aplicación, incluso con un kit de herramientas, se encontrará con problemas que requieren una comprensión básica de estas tecnologías para resolverlas.

Probablemente también deba sentirse cómodo con CSS y la compresión de imágenes para hacer algo que se vea decente y responda rápidamente. JavaScript, servidores web y navegadores son áreas de conocimiento adicionales que finalmente necesitará.

Si construye su HTML en el lado del servidor, su base de código probablemente será más pequeña y es posible que no necesite aprender JavaScript. El modelo del lado del servidor significa que sus programadores escribirán un código (C?) Que genera HTML que pueden ver directamente antes de enviarlo al cliente. El modelo AJAX significa que sus programadores escribirán JavaScript que genera HTML. No conozco muchas herramientas para validar o incluso ver el código HTML generado por JavaScript dentro de un navegador, lo que dificulta la programación correcta.

Donde trabajo ahora, utilizamos un enfoque híbrido que ocasionalmente involucra código Java que genera JavaScript que genera HTML. Si ustedes son nuevos en el desarrollo web, ese no es el lugar para comenzar. Supongo que tendría que decir que a menos que tenga razones convincentes para usar un modelo AJAX, comenzaría con el modelo anterior de generación de HTML del lado del servidor y veré qué tan lejos lo lleva.

Este último tiene la ventaja de que convierte su "back end" en un "servicio de datos" genérico (lo que sea que eso signifique en su contexto).

Su cliente HTML es entonces uno de los muchos consumidores posibles de esos datos. Piense en la aplicación iOS, la aplicación Andriod, la aplicación Windows 8, las API, etc., como otros consumidores.

Una forma común cada vez mayor de una aplicación web es una mezcla de ambos, tendiendo a uno u otro lado.

El primer enfoque es más tradicional, ha estado allí durante años y está bien documentado (aunque c ++ generalmente no es un lenguaje popular para eso).

La segunda opción es más moderna y está presente en los blogs y foros de desarrollo hoy en día. Una de las razones de esto es la creciente necesidad de servir la misma aplicación a otras interfaces, dispositivos móviles y API de servicios. El segundo enfoque tiende hacia un cliente más rico y más receptivo.

En general, eso depende de otras restricciones, como la familiaridad del equipo y el caso de negocios.

Algunas preguntas que pueden ayudarlo a evaluar sus opciones:

1. ¿Tiene el equipo experiencia en el lenguaje y la plataforma?
2. ¿El equipo está dispuesto a aprender nuevos enfoques y tecnologías?
3. ¿La aplicación aprovecha las ventajas de ser más fácil de programar para otros dispositivos (iPhone, Android, Windows 8, etc.)
4. ¿Otra aplicación interna o externa integrada con servicios o datos estará disponible para la aplicación?

Para tales aplicaciones de "intranet", uso el enfoque de cliente gordo (JavaScript / HTML5-app + JSON) con ExtJS4.

Para los sitios web normales de "Internet", usaría un enfoque más "clásico".

Los clientes tienen que renderizar el sitio de todos modos, entonces, ¿por qué no cargarlos con todo el proceso y simplemente darles los datos para completar? Simplemente modifica el código del servidor para generar respuestas (simplemente JSON o XML), lo que ahorra rendimiento. Además, dado que siempre hay más clientes que servidores, todo el sistema se escala mucho mejor si los clientes realizan más trabajo.

El código del cliente se entrega con HTTP, aún puede enviar fácilmente nuevas versiones a los usuarios sin ningún mecanismo oscuro de actualización. (Simplemente reemplace HMTL / JS / CSS)

La única razón por la que preferiría un enfoque clásico en los sitios web normales son los motores de búsqueda.