html - llamar - jquery

¿Por qué HTML/JavaScript/CSS no son idiomas compilados y lo serán alguna vez? (9)

¿Por qué HTML / JavaScript / CSS no se están convirtiendo en idiomas compilados (o tal vez incluso se combinan en un solo lenguaje compilado)? ¿Qué ocurre si los navegadores ejecutan "Máquina virtual del navegador" y las fuentes de html / javascript / css pueden compilarse en un "código de byte del navegador"? ¿No ayudaría mucho a los desarrolladores y usuarios?

Puedo ver algunos desafíos:

¿Qué hacer con tropecientos de páginas existentes? Haga que esta compilación sea opcional, por lo que si lo desea, puede usar el antiguo y simple html. Si desea alimentar un navegador con una página compilada solo use .chtml por ejemplo.
¿Cómo los proveedores de búsqueda indexarían las páginas? Cree un descompilador que descompile el bytecode en fuentes originales exactas (por ejemplo, como flash puede descompilarse). O los proveedores de búsqueda pueden usar la misma máquina virtual y obtener los datos que necesitan de allí.
¿Cómo hacerlo compatible con todos los navegadores? Haga que un desarrollador centralizado (digamos w3c) desarrolle esta máquina virtual y luego cada navegador la incruste.

Pero ¿qué pasa con los beneficios?

Velocidad.
Tamaño.
No más html "loose" y "half-correct". Es correcto o no se compilará.
Se ve igual en todos los navegadores (compatibles).

Si no es un código de bytes, al menos tiene activada la compresión nativa, html probablemente no sea la manera más eficiente de almacenar datos. Sé que hay gzip pero ¿por qué comprimir páginas cada vez en un servidor y descomprimir en un navegador si podemos comprimirlo una vez y alimentarlo a un navegador?

Entonces, ¿qué nos impide tomar este camino (bueno, además de una gran cantidad de esfuerzo para que todo suceda)?

Velocidad.

Estás asumiendo que lleva mucho tiempo analizar HTML. Sin embargo, puede ser que ese tiempo sea insignificante en comparación con el tiempo requerido para otra cosa, por ejemplo, el tiempo requerido para diseñar el texto en la ventana del usuario final.

No más html "loose" y "half-correct". Es correcto o no se compilará.

Ya lo entiendes, usando [X] HTML.

Se ve igual en todos los navegadores (compatibles).

Pareces estar diciendo que solo debería haber un navegador, o que todos los navegadores lo soportarían por igual.

Los estándares de Internet no ocurren al tener un solo cuerpo (el w3c) implementando algo y declarándolo estándar. En cambio, los estándares de Internet ocurren al tener múltiples cuerpos independientes creando múltiples implementaciones. Una consecuencia es:

Algunas personas han desarrollado algo que aún no es estándar (es decir, van por delante del estándar)
Algunas personas aún no han desarrollado algo que sea estándar (es decir, están detrás del estándar)

HTML

HTML es más o menos XML. DTD existiría para varias versiones y los desarrolladores pueden verificarlo en cualquier momento.

CSS

CSS no es un lenguaje de programación, sin embargo, estoy de acuerdo en que el CSS "compilado" podría funcionar ya que la compilación lo comprimiría. Sin embargo, con el soporte que CSS tiene y con el número de hacks esenciales que cualquier CSS necesita tener, nunca lograría compilarlo sin errores.

JS

Como otros han mencionado, JS se está convirtiendo en un lenguaje compilado, excepto que el navegador lo compila para usted y no usted mismo.

Ah, pero Javascript se está convirtiendo en un lenguaje compilado. Echa un vistazo a Firefox 3.5 con TraceMonkey . Es increíblemente rápido en comparación con el navegador de quién sabe quién. Es verdad que JS nunca será C, pero es un lenguaje mucho más dinámico que C, y de muchas maneras eso lo hace más expresivo y poderoso.

En lo que respecta al HTML, no creo que la falta de validez del HTML sea un gran perjuicio para la velocidad. Creo que los motores que juntan la representación visual y manipulan el DOM necesitan mejorar mucho (um, IE, estoy mirando en tu dirección general ...). El cumplimiento de CSS necesita mejorar, y el CSS en sí necesita ser más poderoso. (¡Sube al autobús con CSS 3 personas!)

Pero creo que la velocidad va a mejorar en Firefox y Chrome a tal punto que las personas realmente van a comenzar a usarlo para el desarrollo de aplicaciones convencionales. Es gracioso. Adobe parece vender Flash como su plataforma para contenido web dinámico, MSFT está vendiendo Silverlight para contenido web dinámico, y Google solo quiere mejorar HTML y Javascript para mostrar contenido web dinámico. Y Google lo está haciendo bastante bien hasta ahora, debo decir ...

Creo que su idea es sólida, sin embargo, todavía no hay forma de aplicar un estándar. Por lo tanto, si hubiera una función no compatible, es muy probable que toda la página simplemente no muestre nada. En la configuración actual, aún se puede pasar información crítica.

El motor de javascript V8 (también integrado en Google Chrome, pero es de código abierto y tiene una licencia generosa, así que puedes utilizarlo en el siguiente navegador que escribas). No compila Javascript en un código máquina nativo. Por supuesto, lo hace "justo a tiempo" (como la mayoría de los compiladores modernos - Java, C #, etc.), no "antes de tiempo" (como lo hizo Fortran en 1954 cuando las computadoras eran demasiado débiles para manejar la compilación en medio de la ejecución). Me sorprendería que otros buenos motores JS, como los de Firefox y Safari, no hicieran lo mismo.

Parece que no abogas por "javascript como un lenguaje compilado" (ya que obviamente ya está compilado, si estás usando un buen motor JS), sino más bien una compilación "anticipada" (justo cuando lo más moderno los lenguajes están esencialmente abandonando la compilación anticipada). Empujar el código de la máquina en lugar del código compilable parece la idea más horrible: tamaño mucho más grande, dificultades para soportar una CPU frente a otra, pesadillas de seguridad en un espacio aislado, etc, sin demasiado en términos de beneficios compensatorios.

Dicho esto, si está realmente interesado en enviar códigos de máquina al cliente, pruebe con el cliente nativo (siempre que el cliente sea una máquina x86, olvide todos los teléfonos inteligentes del planeta, muchas netbooks, computadoras viejas, etc.) - al menos promete una solución a las pesadillas de seguridad. Si está satisfecho con nativeclient, transformar un compilador justo a tiempo en uno anticipado es un desafío técnico mucho más sencillo (si desea seguir utilizando Javascript para las fuentes en lugar de otros idiomas, por supuesto). )

Google V8 , que es uno de muchos motores de JavaScript de nueva generación, ''compila'' javascript en pseudocódigo, al igual que .NET ''compila'' c # sobre la marcha. Nada mágico aquí. Esperar más de eso esp. a medida que las webapps se hacen más pesadas y más exigentes

Vea aquí para una discusión previa sobre el asunto

No todas las razones dadas son necesariamente válidas, pero una importante es que, a menos que sea Google, los ciclos de CPU del lado del servidor son mucho más valiosos que los ciclos del lado del cliente: por lo tanto, es más fácil que el cliente compile / optimice a menudo se genera dinámicamente HTML / JavaScript, en lugar del servidor.

Conocido

Sus ideas tienen validez cuando se aplican a JavaScript. Como otros han notado, hasta cierto punto varios proveedores están tratando de aplicar esos principios a JS incluso ahora. Otro gran paso en esta área probablemente sea el Chrome OS que Google ha anunciado. Sin embargo, cuando se trata de (X) HTML y CSS, creo que sus ideas pueden estar perdiendo el sentido.

La red mundial no es una plataforma de aplicaciones incorrecta e incoherente, sino una colección masiva e inédita de documentos interconectados. El poder de la web radica en la abstracción de los datos de los diseños visuales a menudo rígidos (y frágiles) y en la funcionalidad in-page cada vez más compleja proporcionada en gran medida a través de JavaScript. La codificación de estas páginas en (X) HTML es ideal para hacerlas accesibles a la audiencia más amplia posible, tanto en términos de navegadores como en términos de conocimiento técnico requerido para crear una página.

Cada vez más, la web se utiliza como una plataforma de aplicaciones, que es un uso potente y emocionante de esta tecnología, pero no podemos perder de vista el hecho de que estas aplicaciones "web 2.0" impulsadas por Ajax son meramente documentos con funcionalidad extendida. La compilación no tiene sentido para un documento y la compresión ya está ocurriendo (a través de gzip y similares).

En una nota más práctica, el W3C se mueve a paso de tortuga y los proveedores de navegadores se turnan para saltar entre las características experimentales de soporte en las especificaciones sin terminar y se toman su tiempo soportando otras especificaciones que han estado sobre la mesa y en uso común durante años. . Todo el proceso es como pastorear gatos. No aguantaría la respiración para que hagan el tipo de cambios radicales que estás proponiendo en el corto plazo.

Como HTML y CSS no son códigos, no se pueden compilar. El motor V8 de Google Chrome realmente convierte JS en código de bytes, ¡esperamos que otros motores de renderizado sigan su ejemplo!

http://code.google.com/apis/v8/design.html

Recientemente hemos rediseñado un sistema de plantillas php que he ayudado a crear para usar minify para comprimir múltiples JS y CSS en un solo archivo, ya que nuestros tamaños de archivo caen a aproximadamente el 20% de los tamaños combinados originales. Minify también hace gzip y el almacenamiento en caché, por lo que es realmente sorprendente para acelerar los sitios web.

http://code.google.com/p/minify/

En resumen, no puede compilar sin código, que son HTML y CSS. JS se puede compilar y está empezando a ser, pero todo depende de lo que los navegadores tengan ganas de hacer.

Los navegadores solo necesitan estar al tanto de los estándares web compatibles. Cuantos más navegadores hacen esto, menos dolor de cabeza tienen los desarrolladores web. Estaba bastante contento con la caída de soporte público de YouTube para IE6. Necesitamos más acciones como esa para que la web avance.