Brython, une implémentation de Python 3 pour la programmation Web côté client

**Bill Fassinou** · 07/07/2020, 16h47

Brython, une implémentation de Python 3 pour la programmation Web côté client, insère du code Python 3 directement dans une page HTML,
parviendra-t-il à voler la vedette à JavaScript ?

JavaScript et son vaste écosystème (Réact, Angular, Vue.js, etc.) dominent depuis plusieurs années la programmation Web côté client malgré tout ce qu’on peut leur reprocher. Cependant, d'autres langages comme Go et C tentent de le faire aussi. Brython, une implémentation de Python 3 tente lui aussi de remplacer le JavaScript dans la programmation Web côté client. Brython vous permet d’écrire des applications Web en Python au lieu de JavaScript, en insérant du code Python 3 directement dans une page HTML. La question est donc de savoir si ce dernier réussira à détrôner JavaScript.

Brython, pour Browser Python, est une implémentation de Python 3 fonctionnant dans le navigateur et ayant une interface vers les éléments et événements du DOM. Autrement dit, l’outil Brython supporte la syntaxe de Python 3, y compris les compréhensions, les générateurs, les métaclasses, les importations, etc., et de nombreux modules de la distribution CPython. Il comprend des bibliothèques permettant d'interagir avec des éléments et des événements du DOM et avec des bibliothèques JavaScript existantes telles que jQuery, 3D, Highcharts, Raphael, etc.

En outre, il supporte les dernières spécifications de HTML5/CSS3, et peut utiliser des frameworks CSS comme Bootstrap3, LESS… Selon ses développeurs, Brython a été développé pour remplacer JavaScript comme langage de script pour les navigateurs Web. D’après leurs explications, la vitesse d'exécution de Brython est similaire à celle de l'interpréteur CPython pour la plupart des cas d’utilisation. Son site expose quelques-unes des possibilités qu’il offre, de la création de simples éléments de document au glisser-déposer et à la navigation en 3D.

Code HTML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<html>
 
        <head>
            <script type="text/javascript" src="/path/to/brython.js"></script>
        </head>
 
        <body onload="brython()">
 
            <script type="text/python">
            from browser import document, alert
 
            def echo(event):
                alert(document["zone"].value)
 
            document["mybutton"].bind("click", echo)
            </script>
 
            <input id="zone"><button id="mybutton">click !</button>
 
        </body>
 
    </html>

Dans Brython, la sortie peut être réalisée de différentes manières, notamment avec la fonction alert() (également définie dans le navigateur) qui affiche une fenêtre popup avec le texte passé en argument. Toutefois, si Brython peut être tout aussi utile que le JavaScript, parviendra-t-il à lui voler la vedette pour ce qui est de la programmation Web côté client ? Les développeurs habitués à l’écosystème JavaScript voudront-ils se servir de ce nouvel outil ? Beaucoup pensent que non et donnent pour argument le long chemin parcouru par JavaScript jusqu’ici.

À titre d’exemple, d’après le rapport sur l’état de JavaScript en 2019 (State of JS 2019) de Sacha Greif et Raphaël Benitte, quelque 11 millions de développeurs utiliseraient JavaScript de part et d’autre dans le monde. Le rapport a montré que, qu'on l'aime ou qu'on le déteste, le langage continue de gagner du terrain et son écosystème ne cesse de croître. Il est essentiel au développement moderne et est le premier langage de programmation sur GitHub depuis 2014. Le langage Python est à la deuxième place de ce classement, devançant Java qui est à la troisième place.

Par ailleurs, d’autres programmeurs estiment que JavaScript a fait un long chemin et, malgré ses bizarreries héritées, il est en fait très agréable avec ECMAScript 6 (ES6). De plus, son écosystème contient de nombreux outils permettant d’améliorer l'expérience de développement Web. Selon ces derniers, bien qu’il serait mieux d'utiliser un langage qui n'a pas besoin de 3 signes d’égalité pour faire des comparaisons saines, Python, avec sa forte corrélation entre les espaces blancs et les blocs de code, est-il un bon choix pour la transmission et l'exécution à distance ?

À cette question, certains développeurs Python ont répondu non. Ils estiment que les objets JS sont une des plus belles choses du langage. Par contre, selon eux, les objets Python sont toujours opaques pour beaucoup de développeurs Python. Ils ont aussi ajouté que beaucoup de choses supportées par les objets Python à l’instar de l'héritage semblent ouvertement indésirables, et le système de métatypes semble bien plus compliqué qu'il ne devrait l'être (en partie parce que l'héritage confond les choses). Et vous, utiliseriez-vous Brython au lieu du JavaScript pour la programmation Web côté client ?

Sources : Brython, Page GitHub de Brython

Et vous ?

Que pensez-vous de Brython ?

Selon vous, parviendra-t-il à voler la vedette à JavaScript pour ce qui est de la programmation Web côté client ?

Les développeurs habitués à l’écosystème JavaScript voudront-ils s'en séparer pour un nouvel outil ?

Voir aussi

État de JavaScript en 2019 : les développeurs aiment un peu plus React, Angular est en déclin, un groupe de développeurs pense que JS est « trop complexe »

Python devance Java et devient le deuxième langage de programmation le plus utilisé par les contributeurs sur GitHub après JavaScript

Python 3.9, la prochaine version du langage Python : construction des types génériques dans les collections standard et un analyseur PEG pour CPython

Les tendances dans les métiers de la technologie en France en 2017, une enquête réalisée par CodinGame

**grunk** · 07/07/2020, 17h00

Haaaaa un autre transpiler , ca commençait à manquer

Plus sérieusement , amha typescript à de l'avenir, ca ne m'étonnerait même pas que dans les années à venir la norme ES tendent vers les fonctionnalité de TS. Les autres ... je parierais pas trop dessus.

**Mubelotix** · 07/07/2020, 19h34

Nan mais les gars si on a inventé WASM c'est pour faire tourner des languages compilés à haute performance comme le C et le Rust. C'est pas pour faire son malin à coder un interpréteur python dans un navigateur. Python est encore plus lent que javascript et encore ça c'est quand l'interpréteur est natif! Nan mais enfin c'est vraiment abuser d'essayer d'utiliser du python dans une page web. C'est un crime contre l'humanité.

Invité · 07/07/2020, 19h52

Envoyé par Mubelotix

Nan mais les gars si on a inventé WASM c'est pour faire tourner des languages compilés à haute performance comme le C et le Rust. C'est pas pour faire son malin à coder un interpréteur python dans un navigateur. Python est encore plus lent que javascript et encore ça c'est quand l'interpréteur est natif! Nan mais enfin c'est vraiment abuser d'essayer d'utiliser du python dans une page web. C'est un crime contre l'humanité.

Oui enfin avant de réouvrir le procès de Nuremberg il faudrait peut-être rappeler que brython existe depuis au moins 7 ans, qu'il a les mêmes performances que du python natif, et qu'il ne vise pas les mêmes publics et objectifs que wasm, C ou rust...

**Lcf.vs** · 07/07/2020, 20h08

Quel déterrage.

Un des autres points critiques, du Python, par rapport au JS, c'est justement sa syntaxe basée sur les espaces et indentations : comment minifie-t-on du Python ?

Invité · 07/07/2020, 21h34

Envoyé par Lcf.vs

Un des autres points critiques, du Python, par rapport au JS, c'est justement sa syntaxe basée sur les espaces et indentations : comment minifie-t-on du Python ?

La minification n'est qu'une des optimisations possibles. Si brython est compatible CPython, rien n'empêche d'envoyer du bytecode, ou même un paquet wheel comme avec Pypi. Et au pire, une compression gzip, c'est facile à faire.

**nhugodot** · 08/07/2020, 08h20

Python est un des langages les plus utilisés mais pas du tout par la même communauté que les dev front JS: les scientifiques par exemple. Et eux aussi aimeraient utiliser le web en front et pas Windows. Ils ne vont pas se taper JS qui leur paraît une horreur , syntaxe descendant de C via C++ et java , plutôt que a la python, Julia , etc. Ils se tourneront plutôt sur Dart sinon Brython qui leur suffira bien.
Il y a suffisamment de communautés pour que chacune ait son propre langage. A minima déjà, regardez sur les mobiles, avec Swift, Kotlin JS et maintenant Dart... Alors sur le web, pourquoi pas d'autres outils aussi selon le contexte développeur besoin cible..!

Transpilation ou WASM, tout est possible dorénavant , et ça a piqué au vif JS qui a bien évolué a cause de cette concurrence (de Dart en embuscade en particulier en 2014...).

A retenir : en python, on code bien plus vite et proprement (donc moins de maintenance applicative corrective et évolutive ) qu'en JS (ou qu'en PHP, dixit des amis experts des deux), et un site comme Quora, développé en Python, aurait amplement où se suffire de Brython pour son front, donc être développé avec une seule compétence de langage.

Après tout, avoir Python sur le front n'est il pas aussi 'normal' (ou 'anormal' surtout) que JS sur le serveur avec Node....?

A quand Julia sur le front? Ou Dart sur le serveur...?

**grunk** · 08/07/2020, 08h57

Envoyé par SimonDecoline

Oui enfin avant de réouvrir le procès de Nuremberg il faudrait peut-être rappeler que brython existe depuis au moins 7 ans, qu'il a les mêmes performances que du python natif, et qu'il ne vise pas les mêmes publics et objectifs que wasm, C ou rust...

C'est transpilé en JS , donc au mieux ca aura les perfs de JS non ?

A retenir : en python, on code bien plus vite et proprement (donc moins de maintenance applicative corrective et évolutive ) qu'en JS (ou qu'en PHP, dixit des amis experts des deux), et un site comme Quora, développé en Python, aurait amplement où se suffire de Brython pour son front, donc être développé avec une seule compétence de langage.

Admettons tu développes ton site avec Brython parce que tu veux pas faire autre chose que du Python. Ça veux dire qu'il va falloir refaire une bonne partie des lib courantes que tu aurais simplement inclues auparavant car non compatible ? Ou alors tu vas te mettre à mélanger Python et JS et au final te retrouver avec un code horrible.
Du coup on risque de se limiter à l'utiliser dans des situations simples ou des petits scripts , on va donc charger un transpiler en plus des 5 lignes de code qu'on aurait pu faire en JS en se forçant un peu. A ce moment là des outils comme TRANSCRYPT on plus de sens, au moins la compilation se fait avant.

Dans tous les cas vouloir absolument se limiter à une techno est une erreur. Chaque langage a ces avantages et il faut savoir jongler entre les meilleurs outils.
Oui python permet d'écrire du code rapidement si on adhère à sa syntaxe , mais si on à besoin de réelles performances c'est devenu un mauvais élèves. Même PHP est passé assez largement devant. Il faudra donc s'orienter vers autre chose.
Manque de bol pour le front les alternatives n'existent pas.

**Aspartame** · 08/07/2020, 10h42

Et vous, utiliseriez-vous Brython au lieu du JavaScript pour la programmation Web côté client ?

surement , et même si un retraité breton venait à coder un transpiler brainf*ck , je pense que je l'adopterai immédiatement.

c'est le futur du web de toute évidence.

plus sérieusement, pour l'aspect ludique et surtout didactique , c'est un beau projet vous ne trouvez pas ?

**Se7h22** · 08/07/2020, 11h57

Envoyé par Lcf.vs

Quel déterrage.

Un des autres points critiques, du Python, par rapport au JS, c'est justement sa syntaxe basée sur les espaces et indentations : comment minifie-t-on du Python ?

En même temps, si tout le monde utilisait des tabulations au lieu d'espaces pour indenter, la minification aurait beaucoup moins d'intérêt d'exister

Invité · 08/07/2020, 13h55

Envoyé par Se7h22

En même temps, si tout le monde utilisait des tabulations au lieu d'espaces pour indenter, la minification aurait beaucoup moins d'intérêt d'exister

oui... et que tout le monde écrive son code sur une seule ligne et avec des noms de variables et de fonctions à un ou deux caractères...

**Ken McChee** · 09/07/2020, 12h45

En vrai ca a plus l'air d'etre un POC en l'etat qu'une vraie avancee niveau web. Toujours est il que c'est sympa comme idee, je ne suis pas sur que ce soit viable pour le moment..

Sinon si on veut une librairie qui permet de faire du front end en python il y a cette librairie qui permet de "transpiler" (#motfourretout) du python en javascript et qui est compatible avec pas mal de librairies JS graphiques (D3, NVD3, plotly etc...). Ca permet de pouvoir coder toute la stack en python donc plutot pas mal...

Je laisse les liens pour ceux que ca interesse:

https://nbviewer.jupyter.org/github/...mponents.ipynb
http://www.epyk.io/
https://pypi.org/project/epyk/

**air-dex** · 09/07/2020, 15h30

Il n'y a que trois choses qui peuvent tuer JavaScript :

Qu'un nouveau langage de script soit implémenté dans les navigateurs. En bref un nouveau VBScript ou un Dart qui réussit.
Le retour des plugins dans les navigateurs, qui amèneront d'eux-mêmes des alternatives à JavaScript. En bref de nouveaux Flash.
Le WASM total, que l'intégralité de la "partie <script>" de la page (et plus si affinités) puisse passer exclusivement par du WASM, sans avoir besoin d'une seule ligne de JS pour l'y insérer. A-t-on actuellement la technologie pour ça ? Peut-on ou pourra-t-on faire ça avec Blazor, Rust WASM ou Emscripten ?

TypeScript a besoin de JavaScript pour être utilisable donc il ne le tue pas. Un code TS seul ne sert à rien aussi beau et bon soit-il, à l'instar de CoffeeScript ou Brython. Le TS doit obligatoirement passer par tsc pour devenir du JS et ainsi être utilisable. Certes TypeScript est mieux que Brython ou CoffeeScript parce que tu fais ça en amont (avant la mise en prod) au lieu de le faire sur ça à l'exécution sur la machine de l'utilisateur. C'est aussi mieux que Dart parce que le JS généré est nettement moins verbeux. Mais au final t'auras quand même du JS et tu devras quand même fouiller là dedans à un moment donné en cas de bogue (même avant de remonter rapidement au TS par les source maps si c'est possible).

**grunk** · 10/07/2020, 10h08

2. Ca n'arrivera plus. Les souçis de sécurité que cela engendre sont trop important.
3. Wasm pourrait prendre de l’ampleur si on arrive à avoir des outils simples (genre j'ai juste à appuyer sur un bouton pour compiler vers wasm). Mais ca me semble délicat par la suite de venir interagir avec le DOM qui peut être dynamique. Et il faut quand même reconnaître que JS est bien pratique pour ce genre d’interaction.

Quand à TS , il ne remplacera pas JS , mais j'aimerais bien que JS remplace TS , en intégrant petit à petit ses fonctionnalités/syntaxe. Vu que c'est développé par Microsoft et largement utilisé par Google , ca fait 2 acteurs de poids qui pourrait peser dans ce sens. Un peu à l'image de ce qui se fait avec Boost et le C++. En gros on incube les fonctionnalité dans TS et quand c'est validé on implémente dans la prochaine norme d'ES

**air-dex** · 16/07/2020, 17h39

Envoyé par grunk

3. Wasm pourrait prendre de l’ampleur si on arrive à avoir des outils simples (genre j'ai juste à appuyer sur un bouton pour compiler vers wasm). Mais ca me semble délicat par la suite de venir interagir avec le DOM qui peut être dynamique. Et il faut quand même reconnaître que JS est bien pratique pour ce genre d’interaction.

Les outils simples ne seraient pas un problème en soi. Avec un IDE digne de ce nom, tu peux déjà sélectionner ta cible de compilation et appuyer sur build afin que ça compile pour elle. WASM ne serait qu'une cible supplémentaire.

Le reste ne serait pas un problème non plus dans mon "WASM total". Dans un premier temps on pourrait imaginer des API DOM dans le langage qui sera compilé en WASM. Bien sûr cela impliquera de laisser WASM accéder au DOM, ce qui je crois n'est pas encore le cas.

Mais en fait ma pensée va beaucoup, beaucoup plus loin que ça quand je parle de "WASM total". Je pensais carrément à des pages Web 100% WASM, sans JS mais aussi sans HTML ni CSS. Notre "page" Web serait alors un "exécutable Web", avec un point d'entrée et des arguments qui lui seraient envoyés. Charge ensuite au navigateur de construire la page à partir de tout ça, en faisant tourner l'exécutable Web en WASM. On pourrait ainsi créer les pages Web avec notre framework de GUI favori (GTK, Qt, Swing...) dans le langage de notre choix et on compilerait tout en WASM comme on le fait déjà comme pour une application standalone. Ce serait comme sur le bureau, mais dans le navigateur. On ne serait ainsi plus limité ni à HTML, ni à CSS, ni à leurs limites. Bien sûr la technologie n'en est pas encore là, mais je pense qu'on finira un jour par y arriver en mode "Web 4.0" ou "Web 5.0", quand le trio HTML/CSS/JS (et donc le navigateur) sera le goulot d'étranglement du Web.

**grunk** · 17/07/2020, 09h04

Envoyé par air-dex

Mais en fait ma pensée va beaucoup, beaucoup plus loin que ça quand je parle de "WASM total". Je pensais carrément à des pages Web 100% WASM, sans JS mais aussi sans HTML ni CSS. Notre "page" Web serait alors un "exécutable Web", avec un point d'entrée et des arguments qui lui seraient envoyés. Charge ensuite au navigateur de construire la page à partir de tout ça, en faisant tourner l'exécutable Web en WASM. On pourrait ainsi créer les pages Web avec notre framework de GUI favori (GTK, Qt, Swing...) dans le langage de notre choix et on compilerait tout en WASM comme on le fait déjà comme pour une application standalone. Ce serait comme sur le bureau, mais dans le navigateur. On ne serait ainsi plus limité ni à HTML, ni à CSS, ni à leurs limites. Bien sûr la technologie n'en est pas encore là, mais je pense qu'on finira un jour par y arriver en mode "Web 4.0" ou "Web 5.0", quand le trio HTML/CSS/JS (et donc le navigateur) sera le goulot d'étranglement du Web.

QT apporte déjà plus ou moins une solution à celà. C'est pas du wasm , mais il permette de streamer un applicatif sur le web via des commande webgl. En gros on lance l'applicatif , et il devient accessible via un navigateur comme si on l'avais installé sur la machine distante.

Brython, une implémentation de Python 3 pour la programmation Web côté client

Réseau/Web Python

Discussions similaires

Partager

Partager