Acometida al lado del cliente en el desarrollo web

En los últimos meses, reconocí una gran emoción sobre las secuencias de comandos del lado del cliente en el desarrollo web. Pero si bien las tecnologías del lado del servidor son maduras, estables y bien aceptadas por los desarrolladores de back-end, las tecnologías del lado del cliente son inmaduras (es decir, en comparación con el gran marco del lado del servidor) y muchos desarrolladores de larga data no les gustan. Sin embargo, todos están haciendo desarrollo del lado del cliente en estos días. Personalmente, espero que esos grandes marcos del lado del servidor desaparezcan en unos 2-5 años, observando la tendencia actual.

¿Por qué es así? ¿Cómo podría el desarrollo del lado del cliente nuevo y "difuso" en HTML5 / JS posiblemente ser superior a las soluciones grandes y bien pensadas del lado del servidor?

Esto es verdad:

Acometida al lado del cliente en el desarrollo web

Pero no se limita al lado del cliente, es un movimiento de pila completa.

Sé que esto puede ser sorprendente. Por favor, escúchame.

¿Por qué es así? ¿Cómo podría el desarrollo del lado del cliente nuevo y "difuso" en HTML5 / JS posiblemente ser superior a las soluciones grandes y bien pensadas del lado del servidor?

En primer lugar, ambos están bien pensados.

En segundo lugar, porque es mejor.

Buena pregunta.

Pero "mejor" es subjetivo, por lo que la respuesta a su pregunta es, ¿qué es específicamente mejor?

Vuelve a visitar la pregunta:

¿Cómo podría el desarrollo "difuso" del lado del cliente en HTML5 / JS posiblemente ser superior a las grandes soluciones del lado del servidor?

Because small is nimble.
And big is clunky.

Es flexibilidad.

No parece un gran problema. ¿Lo hace? Flexibilidad.

Sin embargo, la flexibilidad subyace a todo. Una mejora en flexibilidad: mejora todo.

Mantenibilidad Extensibilidad. Escalabilidad. Modularidad. Usabilidad. UX

Y es más rápido de implementar. Esta es la realidad. Más rápido y mejor.

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, no es una moda y no desaparecerá. Solo estamos viendo las semillas de una tecnología que crecerá para proporcionar contenido informático y comportamiento de interacción a las tabletas. Tabletas

Los teléfonos inteligentes fueron la adopción más rápida de los medios de comunicación desde la televisión en la década de 1950. Ahora, no solo tenemos teléfonos inteligentes, también tenemos tabletas.

Ya en desarrollo en Mozilla y Windows, el sistema operativo que se ejecutará en dispositivos futuros en sus mercados -> HTML / JS.

Quedan muchas soluciones e innovaciones.

Está surgiendo una pila completa de JS, basada en la flexibilidad.

Espero que eso ayude.

Esta historia siempre ha tenido dos lados; tanto el código del lado del servidor como del lado del cliente tienen sus ventajas y desventajas.

Las ventajas de las secuencias de comandos del lado del cliente incluyen:

• Se puede hacer más receptivo, son posibles grandes cambios sin viajes de ida y vuelta del servidor.
• El código se ejecuta en el cliente, lo que reduce el uso de recursos en el servidor.
• La separación entre lógica y presentación se vuelve física.
• A veces es más fácil equilibrar la carga, especialmente si se usa la autenticación por solicitud.

Pero el script del lado del servidor también tiene muchas ventajas:

• Usted controla la máquina en la que se ejecuta el código.
• Casi todo es posible: si su servidor puede hacerlo, también puede hacerlo su script.
• Los usuarios no pueden modificar su script antes de ejecutarlo.
• Los usuarios no pueden usar bloqueadores de secuencias de comandos para evitar que se ejecute su secuencia de comandos.
• Los usuarios no pueden ver lo que hace su script, solo pueden observar el resultado.
• El código funcionará de manera confiable con cada cliente que pueda imaginar, incluidos lectores de pantalla, navegadores web textuales, arañas de motores de búsqueda, raspadores, acumuladores, bots IRC, máquinas de muy bajo nivel, navegadores bloqueados por script, lo que sea.
• Los complementos de usuario tienen menos probabilidades de romperse.

Para las aplicaciones web altamente dinámicas, el enfoque centrado en el cliente siempre ha sido una opción popular, porque es la única forma de proporcionar una experiencia de usuario de escritorio decente y receptiva: sin secuencias de comandos del lado del cliente, cada una de las acciones del usuario requiere una ronda viaje, lo que significa al menos medio segundo de retraso, generalmente más. Pero para un sitio informativo que es básicamente un grupo de páginas estáticas servidas desde una base de datos (por ejemplo, wikipedia), la ventaja es marginal, mientras que los beneficios de las secuencias de comandos del lado del servidor siguen siendo abrumadores.

La exageración observada proviene de una combinación de dos desarrollos recientes:

1. HTML5 y su corona de tecnologías relacionadas. Tomó demasiado tiempo, pero ahora finalmente tenemos un estándar que contiene todo lo que necesita para crear esas aplicaciones web dinámicas de escritorio sin acumular hacks y navegadores convencionales que las implementen correctamente.
2. Potencia de procesamiento disponible. Las PC de escritorio de hoy en día son tan potentes como un servidor web de nivel de entrada, los teléfonos celulares de nivel de cliente son prácticamente las computadoras de escritorio de 2005, y las implementaciones modernas de JavaScript son lo suficientemente eficientes como para inclinar el equilibrio del rendimiento: por ahora, los recursos del lado del cliente son más baratos que el servidor recursos

De hecho, nada ha cambiado en términos de en qué son buenos los enfoques centrados en el servidor y en el cliente; lo que ha cambiado es que centrarse en el cliente ahora es más fácil y económico de hacer y funciona mejor que hace unos años, lo que lo convierte en una opción viable para muchas más aplicaciones de lo que solía ser.

El lado del servidor siempre estará presente. No puedes sentarte del lado del cliente para todo. Por ejemplo, no querrá usar un diseño Backbone.js MVC para su microcontrolador enviándole parámetros en tiempo real desde una grúa aérea de producción.

No te creas la exageración.

Hice el cambio en 2009 de un marco PHP del lado del servidor a una solución ExtJS del lado del cliente vinculada a los servicios web del lado del servidor.

Las razones de la migración para mí fueron:

1. Mejor seguridad al reducir la cantidad de puntos finales y código en el servidor.
   Al pasar a los servicios web, usted valida la entrada en el límite del servicio web y tiene un control más exacto sobre la E / S de su servidor. No hay una capa de interfaz de usuario del lado del servidor que confunda su arquitectura de seguridad.
2. Rendimiento mejorado debido a la menor cantidad de viajes de ida y vuelta del servidor
   La arquitectura cambia, por lo que las recuperaciones de datos pueden ocurrir con menos frecuencia y los datos se pueden almacenar en caché localmente con la representación de la interfaz de usuario que no requiere ningún viaje de ida y vuelta. Los viajes de ida y vuelta son los que matan el rendimiento de las aplicaciones web.
3. Rendimiento mejorado debido a la capacidad de almacenamiento en caché de la interfaz de usuario
   La capa de la interfaz de usuario se puede alojar en un CDN por completo. Incluso he creado aplicaciones web sin conexión insertando el código de la interfaz de usuario en el caché de aplicaciones HTML5.
4. Mayor fidelidad de la interfaz de usuario (controles enriquecidos del lado del cliente)
5. Los desarrolladores de terceros pueden usar la misma API que usa mi propio front-end, y puedo reutilizar fácilmente las API en todos los módulos si comparten características.
   Esto significa menos desarrollo, control de calidad, documentación, ...
6. Me gusta programar en JavaScript mejor que PHP, Python o Java

Pero, no se equivoquen, lo que está sucediendo ahora es una exageración. Se expandirá y muchas aplicaciones web volverán a utilizar una arquitectura de interfaz de usuario del lado del servidor.

Otro factor que impulsa el entusiasmo por las soluciones del lado del cliente es el crecimiento de las aplicaciones móviles. Si crea un sitio web basado en gran medida en JavaScript y AJAX del lado del cliente, y también crea aplicaciones nativas de iOS y Android, existe una buena posibilidad de que los tres puedan usar los mismos servicios REST para hacer que todos sus datos vayan y vengan .

En primer lugar, el usuario no ve (y a veces ni siquiera le importa) lo que no es el servidor. No importa qué tan bien esté escrito el código del lado del servidor, los usuarios no apreciarán la aplicación si la parte del cliente no está bien hecha. A veces, incluso la buena interfaz de usuario es más importante que la funcionalidad.

Un servidor de alojamiento grande y poderoso es bastante costoso. Es mucho más barato implementar parte de la lógica (excepto la validación) en el lado del cliente. Por lo tanto, podría usar un servidor de alojamiento más pequeño (por lo tanto, más barato), ya que no se cargaría tanto.

Estas son las razones por las que, a pesar de la inestabilidad, las tecnologías del lado del cliente están ganando más popularidad. Además, JS y HTML / CSS son compatibles con (casi) todos los navegadores modernos.

Estas dos partes de las aplicaciones no pueden existir por separado. Y parece que Internet no se va a ir a ninguna parte en el futuro cercano.
No creo que big server-side frameworkssea ​​probable que desaparezcan tampoco. Siempre habrá empresas que puedan pagarlos y utilizarán sus ventajas significativas.

El desarrollo web del lado del cliente está fuertemente asociado con los navegadores web y los cambios en ellos con el tiempo. La solución que proporciona ahora puede no funcionar en un par de meses debido a cambios significativos en los motores de representación de páginas de los navegadores web. Algunos navegadores son / eran incompatibles con los estándares y, por lo tanto, requerían aún más esfuerzo adicional de los desarrolladores solo para lograr el resultado esperado.

Hay algunas soluciones que intentan solucionar este problema. Por ejemplo, si usa jquery, se asegura de que su script funcionará en los navegadores compatibles con esta biblioteca jquery en particular. Pero solo depende de sus autores proporcionarle compatibilidad con algunos / la mayoría / todos los navegadores. La pregunta es qué equipo lo apoyará mejor. ¿Será el equipo de motools, el equipo de jquery, otro equipo? Si no brindan soporte a un navegador web en particular, es posible que su proyecto no funcione en ese navegador.

La emoción que parece haber existido durante mucho tiempo. Lo vi cuando se introdujeron Shockwave y su sucesor Flash, hubo un "gran regreso" de interfaces de usuario enriquecidas una vez que se enviaron bibliotecas js complejas, primero con motools, luego con jquery (comencé a usarlas en este orden). Hubo Flex y JavaFX. Pero ninguno de ellos puede obtener una gran participación en el mercado. Algunos requieren complementos que con el tiempo a menudo exponen al usuario final a vulnerabilidades de seguridad, otros pueden no funcionar en el lado del cliente debido a algunas configuraciones personalizadas (por ejemplo, JavaScript deshabilitado en el navegador de los clientes).

Por otro lado, la solución del lado del servidor generalmente se escribe solo una vez. No necesita preocuparse de que todo falle y tendrá que volver a escribirse una vez que se envíen los nuevos Firefox / Chrome / IE / Opera. Tampoco debe preocuparse de que el cliente intente alterar su aplicación y / o corromper los datos.

Absolutamente de acuerdo con tus sentimientos. También creo que más allá de lo que está diciendo, veremos una caída dramática en REST y un aumento masivo en los sockets web por la forma principal en que vemos que los sitios se comunican con sus servidores. Vert.x, Node.js, etc., todo el lado del servidor, así como el lado del cliente, se está moviendo a la programación controlada por eventos. Java EE, PHP, Rails, etc. todos necesitan adaptarse o perderán muy rápidamente.