Un pequeño aporte; mi conocimiento es limitado, solo pretendo iniciar la discusión.

Ajax

En el 2003 estaba en sexto grado; en aquel entonces los cibercafés apenas empezaban a aparecer en los rincones de los pueblos. Juegos en línea de primera generación como Legend y Westward Journey estaban en pleno auge. Con la intención de probar, le di dos yuanes al dueño del cibercafé para registrar una cuenta y jugar, y durante la hora siguiente estuve, re, gis, tran, do, la cuen, ta.

En esa época el cibercafé usaba un ancho de banda de 512k. Al registrarme, llené un montón de información, la envié, la página saltó: “¡Boom! La información que ha completado es incorrecta, por favor vuelva a llenarla”. Luego regresaba a la página de registro, y así en bucle. Ahora pienso a menudo: si ajax se hubiera popularizado entonces, me habría ahorrado 2 yuanes.

Entonces, ¿qué es ajax?

Primero, ajax es una tecnología. En la interacción web anterior, cuando el usuario hacía clic en un botón, como el de enviar, tenía que esperar la larga interacción de datos con el servidor; durante ese tiempo no podía hacer nada más que encender un cigarrillo. Lo que hace ajax es que, al enviar una solicitud al servidor, no tenemos que esperar el resultado, sino que podemos hacer otras cosas al mismo tiempo, y cuando haya un resultado, podemos ocuparnos del asunto después.

De hecho, la tecnología ajax ya había sido implementada por Microsoft en 1998. Sin embargo, no fue hasta febrero de 2005, cuando Jesse James Garrett de Adaptive Path publicó el artículo “Ajax: A New Approach to Web Applications”, que la gente, tras leerlo, pensó: “Vaya, no está mal, esto mola”. Después de eso, ajax se popularizó a gran escala.

La aparición de ajax mejoró enormemente la experiencia de usuario en la web. Hoy en día, por muy atrasado que esté el desarrollo de TI en nuestro país, el inicio de sesión y el registro de todos los sitios web ya han implementado la interacción con ajax. Después de que el usuario completa la información, la página sabe si el envío fue exitoso sin necesidad de actualizarse, y se corrige donde haya error.

Además, ajax, como solución de separación entre frontend y backend, ha sido adoptado por la mayoría de las empresas nacionales que no son muy “low”, e indirectamente ha provocado el declive de lenguajes de scripting web como PHP.

jQuery

En la programación JS de los primeros años, la eficiencia del código era extremadamente baja, sobre todo al manipular el DOM. Un desarrollador que quería agregar un evento a un botón tenía que escribir un largo bloque de código repetitivo para obtener el botón, y luego otro largo bloque de código repetitivo para agregar el evento. Aunque los veteranos encapsulaban las operaciones comunes, para los novatos que no sabían encapsular era sin duda algo muy doloroso, especialmente con todo tipo de problemas de compatibilidad.

En 2006, con la misión de salvar a los novatos y hacerles “do more”, nació jQuery. La importancia del nacimiento de jQuery: primero, logró compatibilidad con IE6, 7, 8 y varios navegadores que dominaban por separado; segundo, simplificó enormemente la manipulación del DOM, mejorando mucho la eficiencia del desarrollo. jQuery fue tan popular que algunos desarrolladores frontend solo sabían escribir jQuery y no JS nativo. Hasta hoy, no es exagerado decir que jQuery es “write once, see everywhere”.

Otro significado de jQuery (en mi opinión) es que catalizó el interés y la exploración de la gente por el frontend. En comparación con Linux, con un costo muy bajo puedes crear un efecto que haga que una chica que no sabe programar diga: “Oppa, eres increíble”, haciendo que la gente piense: “Oh, otra vez no está mal, esto mola”. Desde entonces, una gran cantidad de bibliotecas y complementos basados en jQuery surgieron como hongos después de la lluvia. La industria del frontend prosperó y floreció, y el desarrollo web entró en una nueva era.

Chrome

Todas las artes marciales del mundo provienen de Google. En la era de IE6, 7 y 8, aunque Firefox también desafiaba lentamente la posición de IE, palidecía en comparación con el impacto disruptivo del navegador Chrome, que Google comenzó a promover en 2009. Chrome usaba el núcleo de código abierto de Apple, WebKit, con buenos estándares de diseño y buena respuesta del mercado; impulsó la rápida evolución de los navegadores e hizo que IE desapareciera por completo en Windows 10.

El lanzamiento de Chrome dio un paso más en la simplificación del inicio en el frontend. Sus herramientas de depuración integradas son útiles y sencillas; con ellas podemos ver fácilmente el estado de la red, el orden de carga, realizar depuración con puntos de interrupción, etc. Además, las extensiones de Google brindan una gran comodidad a los desarrolladores.

Actualmente, la última versión de Chrome ha comenzado a usar el núcleo Blink; en las versiones de prueba ya se pueden rastrear y depurar animaciones CSS3. Cuando todavía no lo había ni imaginado, Chrome ya lo había implementado.

En una palabra: sin Chrome no hay nueva China, y solo podríamos usar Firefox.

GitHub

Con la aceleración de la iteración de los proyectos de software, las herramientas de control de versiones también evolucionaron continuamente, pasando por CVS, SVN y GIT. Hasta ahora, CVS casi ha desaparecido lentamente de la industria de Internet; SVN existe como almacenamiento de archivos y documentos. GIT, la herramienta de control de versiones creada por Linus, el inventor del kernel de Linux, se ha convertido en el estándar de versiones de código. GitHub, gracias a git, se convirtió en una comunidad para la colaboración en equipo de desarrolladores. En enero de 2015, los desarrolladores registrados en GitHub superaban los diez millones, y los proyectos de código abierto, decenas de millones. Entre ellos, en 2014 los desarrolladores chinos fueron los que más rápido crecieron en GitHub. Casi puedes encontrar todo el código que quieras… como username..password..

OAUTH

La diferencia entre OAuth1 u OAuth2 y los métodos de autorización anteriores es que la autorización de OAuth no permite que un tercero acceda a la información de la cuenta del usuario (como nombre de usuario y contraseña).
Contexto de origen: en el escenario de servicio más común, el usuario necesita usar los servicios de dos empresas diferentes: iniciar sesión y verificar en la empresa A, descargar contenido; luego iniciar sesión y verificar en la empresa B, subir contenido al servicio de la empresa B, lo cual es complejo y lento. Tanto el usuario como A y B quieren interoperar los servicios. Así surge la necesidad de verificar la identidad. El antiguo mecanismo de nombre de usuario y contraseña haría que las empresas A/B tuvieran permiso para ver e incluso modificar los recursos de usuario de la otra. Para lograr la confirmación de identidad y la interoperabilidad de servicios, Google, Yahoo y Microsoft lideraron la creación de OAuth 1.0. El posterior OAuth 2.0 fue una nueva planificación de las grandes empresas de Internet basada en la seguridad de HTTPS.

Actualmente, el escenario de aplicación más común se centra en el inicio de sesión autorizado, como WeChat, QQ, Weibo, etc.

JSON

Aunque JSON es un estándar que surgió en 2001, no se aplicó ampliamente hasta después de 2008, cuando se popularizaron las aplicaciones Ajax, el iPhone y los dispositivos Android. Los antiguos sistemas de servicios eran en su mayoría de nivel empresarial, por lo que XML era beneficioso para los servicios empresariales orientados a Java. Pero para servicios API con limitaciones de tráfico y semántica simple, XML es voluminoso, redundante, difícil de aprender y ocupa ancho de banda.

El año pasado, cuando acababa de empezar a trabajar, el backend me devolvía un array. Sin derecho a opinar, dudé mucho entre recorrer el array o convertirlo a formato JSON.

La popularización de JSON refleja desde otro ángulo una ventaja del desarrollo web: no importa si tu backend es Java, Ruby, PHP o Python, mientras me des una interfaz en formato JSON, puedo sostener todo el mundo.

DJANGO&RAILS

El desarrollo ágil rompió el modelo de investigación y desarrollo de proyectos. En la era Web 2.0 posterior a 2010, HTML5 prevaleció, el trabajo de frontend se separó, y la ventaja de los scripts web como PHP ya no era tan evidente, aunque seguía teniendo ventajas en CMS y plantillas de foros. La mayor ventaja de Django y Rails es que hacen posible que individuos o equipos pequeños de dos o tres personas implementen un producto completo. Tomando Instagram como ejemplo: inicialmente dos ingenieros de Python usaron Django para implementar rápidamente todas las funciones del servidor; cuando los usuarios crecieron, separaron los servicios de alto tráfico y grandes datos.

Aunque la realidad es cruel y Rails está cada vez peor, si desaparece primero IE8 o Rails solo es cuestión de tiempo. Pero sus soluciones han sido imitadas por muchos de los más jóvenes. La gente recordará esta flor efímera.

Bootstrap

Bootstrap es un framework GUI para web que Twitter abrió como código abierto en 2011. jQuery compatibilizó la parte de JS en diferentes navegadores, y Bootstrap compatibilizó la parte de CSS en diferentes navegadores. Incluso se puede decir que, como desarrollador backend, no necesitas saber CSS, no necesitas un frontend, no necesitas diseñador: solo tienes que leer la documentación de Bootstrap y puedes montar un sistema de administración backend bonito y elegante. Otros frameworks GUI similares comunes son Foundation de Zurb, Materialize de Google; Baidu también lanzó un framework móvil llamado GMU.

Personalmente, no me gustan estos frameworks GUI, aunque simplifican CSS y logran algunos efectos impresionantes; aunque los he usado en proyectos; aunque no quiero admitir que soy un hipócrita. El mayor defecto de estos frameworks es que son todos iguales: todas las páginas se ven iguales, el mismo nav, el mismo sidebar, los mismos formularios, hasta el brillo al pasar el mouse es idéntico. Es como si yo tuviera tres piernas (aunque ciertamente tengo tres piernas), la gente diría que soy peculiar y les llama la atención; pero si todos tuvieran tres piernas, la web perdería su encanto. Otro defecto es que son pesados: un CSS ocupa más de 100 KB de tráfico, y sus plugins JS dependen en su mayoría de jQuery. ¿Puedes soportarlo?

Por supuesto, la idea de proponer HTML en rejilla (grid) para resolver el diseño responsivo es digna de tomar como referencia.

La popularización de los sistemas IOS y ANDROID

Después de 2009, el rápido desarrollo de iOS y Android provocó los siguientes cambios en el desarrollo web:
1. HTML5 se implementó primero en los navegadores móviles; los dispositivos Android e iOS apoyan completamente HTML5 y CSS3, acelerando la desaparición de IE.
2. El acceso a internet pasó a ser en cualquier momento y lugar. Las páginas de clic de ratón y contenido complejo se volvieron cada vez más simples, y el diseño responsivo se hizo popular rápidamente.
3. La interacción entre las apps y el servidor se basa en su mayoría en el protocolo HTTP, igual que la web; se plantearon los conceptos de webapp y hybrid app.

En cuanto a las webapps, aquí hablaré brevemente de las ventajas de la web frente a las nativas.

• Multiplataforma: el famoso “compilar una vez, ejecutar en cualquier lugar”
• Sin instalación: abre el navegador y úsalo.
• Despliegue rápido: para actualizar solo hay que actualizar el código en el servidor, a diferencia de la app cliente que requiere actualizar la versión.
• Hiperenlaces: puede enlazarse con otros sitios web y ser indexado por los motores de búsqueda.

Suena impresionante, pero estas ventajas no resisten un análisis serio. En primer lugar, los hábitos de uso de los usuarios de diferentes sistemas son distintos: los usuarios de iOS están acostumbrados a que el botón de retorno esté en la esquina superior izquierda, mientras que los usuarios de Android están acostumbrados a que esté en la parte inferior de la pantalla. El product manager pregunta: ¿dónde lo ponemos? Je, ni idea. En segundo lugar, una vez vi un informe de investigación que preguntaba a los usuarios si preferían usar el cliente o la versión web.

Los usuarios que prefieren el cliente superan con creces a los de la versión web. Si me preguntas qué prefiero, yo también prefiero el cliente. Si me preguntas por qué, creo que me da más sensación de seguridad, y además actualizar la versión me hace sentir muy bien, me da sensación de presencia, me hace saber que no he sido olvidado por el mundo, que vuestro producto se está actualizando y que se preocupa por mí. Además, los enlaces... ¿para qué quiero yo SEO en un cliente? Y esto no ha terminado, las webapps tienen todavía un montón de defectos. El mayor de ellos es que no tienen aceleración por GPU; querer implementar una animación un poco compleja es pedirle peras al olmo al navegador. Además, las páginas web son de un solo hilo; al cargar el DOM se bloquea JavaScript, y el resultado es: lag. Con el lag viene la frustración, y con la frustración, cerrar la página. Un usuario menos.

Pero hybrid es diferente. Una app hybrid significa aplicación nativa híbrida: las páginas que necesitan actualizaciones frecuentes se colocan como web y se actualizan de forma remota. Esta es una solución fiable. BAT tiene muchos casos, como el SDK de JS publicado por WeChat, la versión Android de Baidu Mobile y Taobao.

Por supuesto, hay muchas trampas aquí. Si tengo la oportunidad, os contaré los agujeros en los que he caído.

NodeJS

Estuve dudando un rato sobre si node pertenece a la categoría de front-end. Creo que sí pertenece.

Resolver la alta concurrencia siempre ha sido un tema que a los chicos del backend les gusta discutir. Por ejemplo, en nuestro sistema de monitoreo en tiempo real Haojin, teóricamente cada conexión genera un nuevo hilo, y cada nuevo hilo puede necesitar 2 MB de memoria asociada. En un sistema con 8 GB de RAM, el número máximo teórico de conexiones concurrentes es de 4,000 usuarios. Con el crecimiento de los usuarios, esperamos que el programa de monitoreo pueda soportar a más usuarios, por lo que hay que añadir más servidores. Por supuesto, esto aumenta los costos operativos, especialmente los costos de servidores. Además del aumento de costos, hay otro problema técnico: los usuarios pueden usar diferentes servidores para cada solicitud, por lo que cualquier recurso compartido debe compartirse entre todos los servidores. Llegados a este punto, la tecnología llega a su cuello de botella. El propósito original del nacimiento de Node fue resolver este problema. La forma en que Node lo resuelve es cambiando la manera de conectarse al servidor: cada conexión emite un evento que se ejecuta en el proceso del motor de Node, en lugar de generar un nuevo hilo del sistema operativo para cada conexión y asignarle algo de memoria asociada.

Node.js pertenece al lenguaje del lado del servidor. En este movimiento de separación entre front-end y back-end, es un arma ventajosa para el front-end. Al mismo tiempo, también proporciona una gran cantidad de herramientas programables para la automatización del front-end (grunt, bower, gulp, etc.). Taobao y Baidu siempre han mostrado un gran interés por Node.js, y naturalmente creo que esto es una tendencia. El año pasado, Meituan creó el equipo del hotel Meituan y eligió Node como lenguaje de backend, acaparando la mayor parte del trabajo del backend. Estoy pensando: JavaScript de front-end más Node, más la demanda de habilidades de UI, ¿en el futuro los ingenieros de front-end deberían llamarse ingenieros de extremo completo?

BIG DATA

Los grandes datos fueron probablemente el término más candente de los últimos años. Un montón de mis compañeros, al oír que la minería de datos tiene un salario anual de 300,000, se lanzaron en estampida a hacer bases de datos.
La mayoría de las veces, cuando hablamos de grandes datos, en realidad hablamos de minería de datos, análisis de datos, recomendación inteligente y análisis en tiempo real con volúmenes masivos de datos. Las soluciones técnicas de cada empresa son diferentes; solo enumero dos casos de éxito nacionales:
• El comercio electrónico personalizado de JD.com; los escenarios incluyen recomendar diferentes productos a diferentes usuarios basándose en dimensiones como comportamiento, preferencias, ubicación geográfica, tiempo y relaciones de amistad; el orden de los resultados de búsqueda de productos también es diferente para diferentes usuarios...
• El mapa de migración de 8 horas de Dongguan de Baidu Maps; el recordatorio inteligente de búsqueda de Baidu
• 360 Mobile Guard: la función antispam de números de teléfono selecciona, a través de la ubicación geográfica, identidad y tendencias de spam del usuario, los 1,000 números más relevantes entre los 256 millones de números de teléfono marcados, y los escribe en un archivo de texto de 10k en el teléfono del usuario, logrando protección antispam sin conexión y sin ninguna interacción de red.

HTML5+CSS3

Esta es una palabra que se ha manoseado hasta la saciedad en los últimos años. Todos hablan de HTML5, y si les preguntas qué es HTML5, tampoco lo saben explicar. Simplemente es genial, es deslumbrante, es genial y deslumbrante.

En mi opinión, HTML5 es solo una exageración colectiva; la atención que atrae supera con creces las funciones que ofrece. HTML5 solo proporciona algunas API nuevas, es como cuando una app pasa de la versión 1.0 a la 2.0 y añade la función de "personas cercanas". Además, las API que proporciona solo están probando aguas en el lado móvil; en el lado de PC, debido a problemas de compatibilidad, nunca pueden ser legitimadas oficialmente. El desarrollo en PC todavía se basa en HTML 4.0 + CSS2 con mejora progresiva. En cuanto a CSS3, su característica más celebrada, la animación, no es más que lo que Flash ya dejó de usar.

El rápido desarrollo del lado móvil catalizó el desarrollo de HTML5, y el desarrollo de HTML5 también impulsó a los navegadores a estandarizarse.

En este camino hacia la estandarización, WeChat ha sido fundamental. Páginas como 1024, "Círculo del gato neurótico", "Taobao: Diez años" y LEXUS NX, que integran una gran cantidad de elementos de HTML5 + CSS3, dejan una impresión profunda.

Además, Microsoft abandonó el nombre en clave de IE y desarrolló Edge; los fabricantes de navegadores no dejan de estandarizar; el borrador de HTML5 se ha finalizado; el borrador de ES6 se implementa y perfecciona constantemente. El camino del front-end parece una gran avenida, y estoy lleno de expectativas.

Futuro

¿Juegos web 3D? ¿WebOS? ¿Realidad virtual?

Finalmente, con la mejora del rendimiento del hardware de los usuarios, el ancho de banda de red cada vez más grueso, la madurez gradual de los sistemas de sensores, Retina y la tecnología WebGL, junto con el próspero desarrollo de O2O, ¿se harán realidad todas estas cosas?

Fuente: http://www.cnblogs.com/sussski/p/4634595.html