Pourquoi n'implémentent-ils pas Python et Ruby dans les navigateurs web ?

Question

Je me demande pourquoi ils n'implémentent pas d'autres langages comme Python et Ruby dans les navigateurs web.

N'ont-ils pas leur place en tant que langages de programmation clients, ou bien JavaScript a-t-il été le premier à être implémenté, et le support de JavaScript a-t-il été maintenu parce qu'il fonctionnait ?

Je veux dire... Je déteste vraiment JavaScript par rapport à Ruby, peu importe à quel point j'essaie de l'aimer, dès que je vois du code Ruby j'ai envie de pleurer pour JavaScript pour être si laid.

N'y aura-t-il aucune chance pour Ruby et Python du côté des navigateurs (sans avoir à utiliser Silverlight) au cours des dix prochaines années ?

Answer 1

À l'époque où JavaScript a été conçu, Python aurait été à un stade très immature (1.2-ish) et Ruby n'aurait pas du tout existé. Ce que nous considérons aujourd'hui comme un langage de script moderne n'existait pas à l'époque. Python n'a pas obtenu la prise en charge d'Unicode (vital pour un navigateur Web) avant la version 1.6, plusieurs années plus tard ; Ruby... eh bien, oui.

Le langage de script dominant à l'époque était Perl. Soyons reconnaissants que Eich n'ait pas copié que .

Techniquement, un langage destiné à être exécuté du côté client doit disposer de solides capacités de sandboxing que CPython et Ruby n'ont pas. Alors que Python peut peut être intégré dans IE via l'hôte Windows Scripting, ce qui compromet complètement votre sécurité. Il n'est pas trivial de créer une version sandboxée d'un langage qui n'a pas été conçu pour cela.

N'y aura-t-il aucune chance pour Ruby et Python du côté du navigateur ?

Non, pas du tout, même sous une forme restreinte qui a résolu les problèmes de sécurité. Même Microsoft n'a pas pu faire en sorte que le VBScript pour le web devienne populaire. JavaScript est le langage qui fonctionne partout ; vous ne serez pas en mesure de vaincre cette inertie.

À ce stade, nous devons nous concentrer sur l'amélioration de la langue. La standardisation de la cinquième édition d'ECMAScript est un grand pas en avant, offrant de nouvelles méthodes qui aident vraiment à écrire du code laconique qui passe autour de fonctions comme des blocs Ruby. Et l'implémentation JavaScript de Mozilla offre quelques nouvelles fonctionnalités intéressantes comme les générateurs de style Python. (D'un autre côté, elle prend également en charge E4X, une vilaine vilénie pour le langage, alors peu importe).

JS n'est pas si mal, écrit avec goût. Bien sûr, la majorité du code existant, et dans les tutoriels, est tout sauf de bon goût. Mais ce n'est pas un problème limité à JS.

Answer 2

Microsoft vous permet d'utiliser un grand nombre de langages différents sur le navigateur - avec le dernier add-on Silverlight (je ne suis pas sûr que cela comprenne encore les langages dynamiques comme Python et Ruby, pour lesquels MS a des implémentations solides connues sous le nom de IronPython et IronRuby ; je crois, du moins, que le plan est de les prendre en charge, s'ils ne le sont pas encore).

Mais apparemment, la plupart des gens ne mordent pas à l'hameçon, malgré la popularité de MS - ils préfèrent s'en tenir à des pages réalisées en Javascript (ou Flash, Actionscript, etc.), qui, malgré certains problèmes de sécurité passés, semblent être désormais "sandboxées" de manière sûre et solide, ce qui signifie qu'aucun auteur de site Web mal intentionné ne peut les utiliser pour lire vos fichiers privés (ou vos mots de passe bancaires en ligne, etc.) et les renvoyer à des personnes mal intentionnées pour qu'elles les utilisent. Je soupçonne que certaines des inquiétudes en matière de sécurité remontent à la plus grande tentative de MS pour permettre aux navigateurs (ou du moins spécifiquement à leur Internet Explorer) d'exécuter beaucoup plus de code -- les "contrôles" Active/X... qui étaient "à peine sandboxés, voire pas du tout" à certains égards. Cette fois, ils ont peut-être raison, mais (même si cela peut frustrer les programmeurs web) on ne peut pas reprocher aux gens de ne pas être tout à fait disposés à mettre leur identité et leur gagne-pain en danger.

Javascript, malgré tous ses problèmes (et Actionscript, un langage quelque peu similaire) a au moins été conçu dès le départ pour être "sandboxé" ; Python et Ruby, malgré et dans un certain sens à cause de étant des langages "plus forts", n'ont jamais vraiment été conçus pour être sandboxés... et la difficulté de réadapter le "sandboxing" dans un langage universel peut être mise en évidence par le fait que Python, par exemple, après de nombreuses années et de nombreuses versions tentant de supporter un "mode d'exécution restreint", a finalement et totalement abandonné cette idée (en ce qui concerne les versions officielles de la Python Software Foundation, du moins - bien sûr, cela ne doit pas empêcher la possibilité de versions complètement différentes telles que IronPython, PyPy, Jython, Pynie, &c, de Microsoft, mais cela n'a pas d'importance. est du moins, décevant;-).

Le site de Google "Client natif" est une tentative, que l'on espère révolutionnaire, de permettre à la course à pied code natif sur le client (via le navigateur) tout en maintenant le sandboxing et la sécurité : il faut que mûr à une technologie mûre et bien acceptée, alors bien sûr (puisque même, disons, le langage C ou le langage d'assemblage serait si bien supporté !), Python ou Ruby ne poserait aucun problème.

Il est trop tôt pour dire s'il tiendra ses promesses, bien sûr (je suis partial, étant un ami personnel de plusieurs des développeurs;-) - il a l'avantage d'être une technologie open-source, de sorte que toute faiblesse de sécurité a plus de chances d'être repérée par les "white hat" (comme ils l'ont été, disons, dans l'idée de rexec de Python) plutôt que de rester caché jusqu'à ce qu'il soit repéré. et exploité par les gars aux chapeaux noirs (comme cela se produit généralement avec les technologies propriétaires et fermées). Je ne partage pas tout à fait l'enthousiasme d'Eric Raymond lorsqu'il proclame "si l'on a assez d'yeux, tous les bugs sont superficiels"... mais je vois où il veut en venir, et je soupçonne que, du moins en ce qui concerne la sécurité et le sandboxing, il... mai ont un point!-)

Answer 3

Parce que ce serait un casse-pieds .

• Pensez-vous que les vendeurs de navigateurs voudront regrouper et maintenir deux ou trois langages juste parce que Javascript est "moche" ?

• Ne crée-t-il pas une dépendance supplémentaire dépendance supplémentaire ?

• Ne pensez-vous pas que cela créerait plus problèmes liés aux navigateurs ou à la mise en œuvre ?

• Cela a déjà été tenté dans Internet Explorer. IE prend en charge VB (et peut-être C#) comme langage de script. Pourquoi Firefox ou Chrome ne les prennent-ils pas en charge ?

Les avantages, s'il y en a, que ces langues sont censées apporter justifient-ils tout cela ?

Answer 4

Le Ruby/Python du navigateur est CoffeeScript miam.

Answer 5

Yahoo a un module complémentaire de navigateur appelé BrowserPlus qui vous permet de créer des applications web côté client avec Ruby. En effet, BrowserPlus est livré avec un interpréteur Ruby. Il est disponible depuis des années, mais il semble que peu de gens le connaissent. Son architecture avec des services plug-in n'empêche pas quelqu'un d'écrire un service Python de la manière dont ils ont implémenté le service Ruby.

Le fait que Ruby en fasse partie est quelque peu caché. Au bas de leur Démonstration de PhotoDrop Ils ont un texte sur Ruby (copié ici) :

Pourquoi Ruby ?

Vous remarquerez les références dans la description de cette démo, et tout au long de ce site, au langage Ruby le langage de programmation Ruby. Donc les questions naturelles questions sont les suivantes :

• Quel est le lien entre BrowserPlus et Ruby ?
• Pourquoi utiliser un langage de haut niveau, et plus particulièrement, pourquoi choisir Ruby ?

Bonnes questions ! Pour répondre à la première, vous remarquerez dans l'explorateur de services que il y a un RubyInterpreter publié publié. Cette chose n'offre aucune de fonctions à utiliser par les développeurs web, alors qu'est-ce que c'est ? Eh bien, il s'agit précisément d'un type spécial de service, un fournisseur qui est disponible pour d'autres services à utiliser. RubyInterpreter intègre un interpréteur Ruby complet (d'où le son nom) et permet aux services d'être services d'être écrits en Ruby. Les avantages de services dans des langages de haut niveau de haut niveau incluent la rapidité de d'implémentation et la portabilité. Pour Par exemple, l'implémentation complète de JSONRequest est finalement constituée de 142 lignes de code ruby portable. Cette caractéristique de la la plateforme, permettant aux services d'être d'être créés dans des langages de haut niveau, signifie que nous pouvons rapidement passer des idées à la réalité en termes de nouveaux services.

Alors pourquoi Ruby exactement ? La réponse est ici est pragmatique : Ruby fournit un environnement complet environnement complet avec une bibliothèque bibliothèque standard assez complète que l'on dans un téléchargement de 2 Mo ou moins. ou moins. De plus, c'est un langage agréable pour travailler, et nous sommes activement suivons et contribuons activement à son progrès. Tout cela dit, RubyInterpreter est un service juste comme tout autre service, et son existence n'exclut pas exclut le support d'autres langages de haut niveau d'autres langages de haut niveau.

En résumé, étendre le web avec langages de haut niveau est une idée une idée puissante qui permet une innovation rapide. L'intégration de Ruby est la manière spécifique que nous avons réalisée pour cette idée.