Pourquoi HTML/JavaScript/CSS ne sont pas des langages compilés et seront-ils jamais?
Pourquoi HTML/JavaScript/CSS ne sont pas de devenir les langages compilés (ou peut-être même de fusionner en un seul langage compilé)? Que faire si les navigateurs étaient en cours d'exécution "Navigateur de la Machine Virtuelle" et html/javascript/css sources pourrait par compilé dans un navigateur "bytecode". Ne serait-il pas aider les développeurs et les utilisateurs?
Je peux voir quelques défis:
-
Quoi faire avec des milliards de pages existantes? Faire de cette compilation en option, donc si vous voulez, vous pouvez utiliser le bon vieux html. Si vous souhaitez charger un navigateur avec une page compilée juste utilisation .chtml par exemple.
-
Comment les moteurs de recherche seraient les pages d'index? Faire un decompiler qui serait décompiler bytecode dans exactes des sources originales (par exemple comme le flash peut être décompilé). Ou les moteurs de recherche peuvent utiliser la même machine virtuelle et d'obtenir les données dont ils ont besoin à partir de là.
-
Comment faire pour le rendre compatible avec tous les navigateurs? Avoir une centralisé développeur (disons w3c) afin de développer cette machine virtuelle, puis chaque navigateur de l'incorporer.
Mais qu'prestations:
- Vitesse.
- Taille.
- Pas plus "lâche" et de "demi-correct" html. C'est soit correcte ou ne compile pas.
- Regarde la même chose dans tous les (pris en charge) du navigateur.
Si ce n'est un bytecode puis au moins avoir quelques natif de compression passe, html n'est probablement pas le moyen le plus efficace de stockage des données. Je sais qu'il est gzip mais pourquoi de compresser les pages à chaque fois sur un serveur et de le décompresser dans un navigateur si l'on peut compresser une fois et de le donner à un navigateur?
Donc ce qui nous empêche de prendre cette route (bien, en plus d'une énorme quantité d'efforts pour que tout se)?
- J'ai édité le titre et le texte, changer le mot "interpréter" à "compilé": je pense que "compilé" est ce que tu voulais dire. S'il vous plaît pardonnez-moi (et à l'inverse mon edit) si j'ai eu tort.
- Vous avez un très bon point. Je suis un développeur web et j'ai été en cours d'exécution pour les problèmes de gauche et de droite qui serait peut-être fixé par votre idée.
- Alors que nous sommes rodomontades ... Veuillez également vous css orienté objet! Ils devraient être emboîtables ..... Devrait accélérer considérablement la recherche du processus de la table ...
- "Regarde la même chose dans tous les (pris en charge) navigateur" n'est pas quelque chose que vous recevrez par le compiler. Comme ils le font maintenant, chaque navigateur serait la mise en œuvre d'interprétation du bytecode différemment.
- wasm est la réponse
- 6 ans plus tard, et la question est toujours valide. AUTANT de vitesse de chargement peut être gagnée que si la plupart des tout a été compilé. Donc beaucoup moins de place pour le piratage. C'est tellement plus facile d'obtenir un bon environnement de développement, d'exécuter, de tester, le mettre dans un navigateur comme un "build".
- est droit. Wasm, ou web de l'assemblée, s'est développé comme la compilation d'un standard du web. webassembly.org
Vous devez vous connecter pour publier un commentaire.
Ah, mais le Javascript EST en train de devenir un langage compilé. Découvrez Firefox 3.5 avec TraceMonkey. Il est incroyablement rapide par rapport à la messagerie unifiée vous-savez-qui de son navigateur. Il est vrai que le JS ne sera jamais C, mais il est beaucoup plus dynamique de la langue que C est, et dans de nombreuses façons, ce qui le rend plus expressif et puissant.
Autant que HTML, je ne pense pas que le manque de validité de HTML est un préjudice énorme à la vitesse. Je pense que les moteurs de mettre ensemble la représentation visuelle et de manipuler le DOM besoin d'obtenir beaucoup mieux (euh, c'est à dire, je suis à la recherche dans votre direction générale...). CSS conformité doit obtenir mieux, et CSS lui-même a besoin d'obtenir de plus en plus puissants. (Prendre le bus avec le CSS 3 personnes!)
Mais je pense que la vitesse va de mieux en mieux sur Firefox et Chrome, à tel point que les gens vont commencer à l'utiliser pour intégrer le développement de l'application. Il est drôle. Adobe semble être la vente Flash que leur plate-forme pour le contenu web dynamique, MSFT est la vente de Silverlight pour le contenu web dynamique, et Google veut juste vraiment améliorer HTML et Javascript pour afficher du contenu web dynamique. Et Google fait assez bien jusqu'à présent, je dois dire...
Vos idées sont valables quand elles sont appliquées à JavaScript. Comme d'autres l'ont noté, à un degré ou à un autre de plusieurs vendeurs essayez d'appliquer ces principes à JS, même maintenant. Une autre grande étape dans ce domaine sera probablement le Chrome OS, Google a annoncé. Cependant, quand il s'agit de (X)HTML et CSS, je pense que vos idées peuvent être à côté de la question.
Le world wide web n'est pas un buggy et l'application uniforme de la plateforme, mais une massive et sans précédent de la collection de documents interconnectés. La puissance du web est dans l'abstraction des données à partir de la souvent rigides et cassantes) des présentations visuelles et de plus en plus complexes-des fonctionnalités de page en grande partie grâce à JavaScript. L'encodage de ces pages (X)HTML est idéal pour les rendre accessibles au plus large public possible à la fois en termes de navigateurs et en termes de connaissances techniques requis pour l'auteur d'une page.
De plus en plus le web est utilisé comme une application de la plate - forme qui est un puissant et passionnant utilisation de cette technologie, mais nous ne devons pas perdre de vue le fait que ces Ajax-driven "web 2.0" apps sont simplement des documents avec des fonctionnalités étendues. La Compilation n'a pas de sens pour un document et de compression est déjà le cas (via gzip et autres).
Sur une note plus pratique, le W3C se déplace à un glacier du rythme et les fournisseurs de navigateur à tour de rôle entre sauter le pistolet à soutenir les fonctions expérimentales dans les specs et en prenant leur temps doux de soutenir d'autres spécifications qui ont été sur la table et dans l'usage courant depuis des années. L'ensemble du processus est comme l'élevage des chats. Je ne voudrais pas retenir mon souffle pour eux de faire le genre de changements radicaux vous proposons tout moment bientôt.
Depuis HTML et CSS ne sont pas de code, il ne peut pas être compilé. Le V8 de Google Chrome, le moteur ne fait convertir JS en byte code, s'attendre à d'autres moteurs de rendu pour les suivre!
http://code.google.com/apis/v8/design.html
Nous avons récemment retravaillé un système de template php que j'ai aidé à créer pour utiliser rapetisser pour compresser plusieurs JS et CSS dans un fichier à chaque, en voyant nos tailles de fichier baisse d'environ 20% de la origial tailles combinées. Minify aussi ne gzip et la mise en cache, donc c'est vraiment incroyable pour l'accélération de sites web.
http://code.google.com/p/minify/
En bref, vous ne pouvez pas compiler non code, HTML et CSS sont. JS peut être compilé et commence à l'être, mais tout dépend de ce que les navigateurs envie de le faire.
Navigateurs juste besoin d'être sur la balle quant à l'appui des standards du web. Le plus de navigateurs ce faire, le moins de maux de tête nous les développeurs web ont. J'ai été très heureux avec YouTube est très de dépôt public de soutien pour IE6. Nous avons besoin de plus d'action comme ça pour le web pour aller de l'avant.
La V8 moteur javascript (également intégré à Google Chrome, mais il est open-source et possède une licence de sorte que vous êtes les bienvenus à l'utiliser dans le prochain navigateur de vous écrire!) ne compiler en Javascript en code machine natif -- bien sûr, il le fait en "juste à temps" (comme sur la plupart des compilateurs -- Java, C#, etc!), pas "à l'avance" (comme Fortran n'en 1954, quand les ordinateurs étaient tout simplement trop faible pour supporter la compilation dans le milieu de l'exécution). Je serais surpris si d'autres bonnes JS moteurs, tels que ceux dans les derniers Firefox et Safari, ne font pas la même.
Dirait que vous êtes la promotion du javascript, un langage compilé" (car il est évident qu'elle ne l'EST déjà compilé, si vous utilisez un bon moteur JS), mais plutôt "à l'avance" compilation pour elle (juste au moment où la plupart des langues modernes sont essentiellement abandon d'avance sur le temps de compilation). En poussant la machine mais plutôt à un code compilable code en bas de la fil de sons comme la plupart idée horrible -- taille beaucoup plus grande, les difficultés dans l'appui à un CPU vs un autre, de la sécurité des cauchemars correctement dans le bac à sable, etc, etc) avec pas grand-chose en terme de compensation des prestations.
Cela dit, si vous êtes vraiment désireux de pousser code machine pour le client, essayer nativeclient (tant que le client est une machine x86 - oublier chaque téléphone intelligent sur la planète, de nombreux netbooks, le bon vieux mac, etc) -- au moins il promet un correctif pour la sécurité des cauchemars. Si et quand vous êtes heureux avec nativeclient, en transformant le just-in-time compiler en avance sur le temps, on est beaucoup plus facile défi technique (si vous souhaitez continuer à utiliser Javascript pour les sources, plutôt que d'autres langues, bien sûr).
inspect elementen code machine!!. Vraiment, si le html et le css ont été envoyés pré-compilés pour les navigateurs client puis développement front end serait le plus difficile travail de programmation.Voir ici pour une discussion sur la question
Pas toutes les raisons données sont nécessairement valide, mais un point important est que, sauf si vous êtes Google, côté serveur CPU cycles sont beaucoup plus précieux que côté client cycles: il est donc plus facile pour le client de compilation/optimiser ce qui est assez souvent généré de façon dynamique en HTML/JavaScript, plutôt que sur le serveur.
Ken
Vous êtes en supposant que cela prend beaucoup de temps à analyser le code HTML. Mais peut être que c'est négligeable par rapport au temps nécessaire pour quelque chose d'autre, par exemple le temps nécessaire à la mise en page du texte sur la fin de l'utilisateur de la fenêtre.
Vous obtenez déjà que, à l'aide de [X]HTML.
Vous semblez vouloir dire qu'il ne devrait être qu'un navigateur, ou que tous les navigateurs ne le soutenir également.
Des normes de l'Internet ne se fait pas en un seul corps (w3c) la mise en œuvre de quelque chose et les déclarer une norme. Au lieu de cela, les normes d'internet se produire par le fait d'avoir plusieurs organes indépendants de la création de plusieurs implémentations. Une conséquence en est:
Je pense que votre idée est bonne, cependant il n'y a encore aucun moyen d'appliquer une norme. Donc si il y a un non-fonctionnalité prise en charge, il ya une bonne chance que la page ne serait tout simplement pas afficher quoi que ce soit. Dans la configuration actuelle, critique de l'information peut aussi être transmis.
Google V8, qui est l'un des nombreux de la nouvelle génération de moteurs javascript 'compile' javascript en pseudo-code, un peu comme .NET 'compile' c# à la volée. Rien de magique ici. S'attendre à plus de esp. comme webapps obtenir de plus lourd et de plus en plus exigeants
HTML
HTML est assez bien XML. DTD avais existent pour les différentes versions et les développeurs puissent vérifier qu'à tout moment.
CSS
CSS n'est pas un langage de programmation, cependant je suis d'accord que "compilé" CSS pourraient travailler, voyant que la compilation de le compresser. Toutefois avec l'appui que la CSS a et avec le nombre de hacks CSS doit avoir, vous ne gérer à compiler sans erreurs.
JS
Comme d'autres l'ont mentionné, le JS EST en train de devenir un langage compilé, sauf le navigateur compile pour vous et vous pas vous-même.