On pourrait bien entendu, utiliser brython pour donner l’illusion qu’on utilise du python par tout, mais je suis pas fan des pre-processeurs.

Plus sérieusement, certes l’intégration directe dans le framework est un plus mais je trouve pas que ce soit essentiel dans tous les cas. C’est pas la mort de faire un pip install + de rajouter une app dans Django. Là je parle pour certains de tes exemples, pas tous évidemment. Le plus chiant finalement je trouve c’est de devoir parcourir les github pour trouver les bons packages qui vont bien.

Sinon, j’arrive toujours pas à digérer le fait qu’on aura sûrement jamais un équivalent de meteor.js en python…

Au moins avant on n’avait que php et mysql et personne n’utilisait le JS</vieux con>

D’un coté, le bytecode devrait permettre l’amélioration de la portabilité, d’un autre côté, ça veut dire quand même qu’on va se faire chier à compiler le langage, et faire les sources maps qui vont avec, et les mappers, et donc avec le setup qui va avec. Et bien entendu il faudra envoyer tout truc qui n’est pas dans la lib standard, donc encore des trucs à uploader. Et il y aura des fuites d’abstractions qui vont nous bouffer les couilles.

Encore une fois ça va dans le bon sens, mais comme javascript n’est pas de l’assembleur, et qu’au final c’est un bidouillage pour faire au mieux avec ce qu’on a, ça va avoir un gout bizarre à la fin.

Mais bon, c’est fantastique qu’on ait des génies qui essayent de mettre au point des moyens de contournement décents. Et qui sait, peut être que dans 10 ans les gens coderont tous comme ça, et quand on dira que c’est une couche de merde sur une tartine de pisse (un langage interprété sur un pseudo bytecode créé en langage interprété tournant au dessus d’une VM dans une sandbox de navigateur et qui fait ses imports via des appels TCP/IP), ils auront la même réaction que quand on discute avec les vieux codeurs fortrans qui nous sortent que Python est c’est pas optimisé :)

Pour les frameworks nouvelles générations, ça s’inscrit tout simplement dans la lignée de commulations de technos qui arrivent à maturités en Python. On a maintenant tout un tas d’outils isoles :

• gestionnaires de cache
• vm tracantes
• lib asynchrones
• file systèmes watchers
• sérialiseurs
• RPC
• PUB/SUB
• gestionnaires de file
• scheduleurs
• routeurs

Ces trucs sont au point. D’un autre côté on a la 3.5 qui va proposer async/await et les types hints, qui vont attirer pas mal de monde, de nouveaux types codeurs, des nouveaux profiles, et entériner des pratiques naissantes dans le monde de Python.

Je gage donc certains vont vouloir faire mieux que NodeJS / Tornado et utiliser ces éléments pour faires des choses un peu mignones.

Déjà il y a plein d’outils Node sur lesquels on est en retard et qu’il faut copier :

• transpilers automatiques
• auto reloaders de pages
• routing websocket aussi facile que le routing HTTP

En Python on a tout ça, mais ça demande du travail d’intégration.

Ensuite, y a du travail à faire pour rendre certains outils plus friendly avec la prog asynchrones :

• les ORM
• les templates

Enfin, y a des systèmes qu’on utilise tous les jours en prog web qui n’ont aucune raison de manquer dans un framework digne de ce nom :

• tasks queue
• bdd clé / valeur embarquée
• settings partagés entre tous les clients et mis à jour en temps réel
• multi-processing à la carte

Ainsi, on peut imaginer piocher dans ces trucs là, coller le tout au cul de crossbar.io, mélanger avec du async/await, et obtenir un framework web avec la syntax de flask, mais qui permet des trucs cool du genre :

• envoyer une tache de longue durée dans une file, et récupérer le pourcentage de progression en une ligne sur une page web
• choisir quelles routes vont taper dans quel processus et donc répartir la charge par CPU
• reloader un de ses micro-services à chaud
• injecter du code JS à distance dans un navigateurs pour les tests
• avoir un console log sur un navigateur mobile qui print sur ta console de l’ordi
• avoir tous tes fichiers less, coffeescript, hype.mabite, etc qui sont pré-processé dans un tab du navigateur via web worker en rpc. Pas besoin d’installer nodejs sur son serveur.
• des modèles JS qui font du RPC automatiquement pour faire du CRUD load balancé.

Tout ça est déjà possible (et certaines choses existent en Python, ou ailleurs), mais on peut faire des frameworks qui ont tout ça intégré. Et je pense que les derniers ajouts à Python vont catalyser tout ça.

Sam, tu peux en dire plus sur les frameworks nouvelles génération ? C’est mal de mettre l’eau à la bouche comme ça et de partir ! ^^

Le JS s’améliore, et quand on pourra utiliser ES7 sur le browser on commencera à être un peu plus chez mémé. Ca sera pas parfait, mais ça sera vivable.

Ensuite, le Python s’améliore. La 3.5 risque d’amener la naissance de frameworks web Python nouvelles générations qui devraient nous faciliter bien la vie.

• il n’a rien de bas niveau. En fait, tout est de haut niveau, mais les instructions sont réduites au minimum.
• pour implémenter tout un tas de trucs dessus il faut donc réimplémenter des trucs de bas niveau avec des outils haut niveau. Le truc n’a pas de division entière par exemple, donc tu prends ton float, et tu le round…
• mais toute réimplémentation passe par du code qui passe par le réseau. Tu ne peux pas envoyer une VM Python de 15 pour ta page web, c’est pas raisonnable.
• l’assembleur est optimisé pour les performances ET la faible consommation de ressources. Donc tu peux implémenter des trucs dessus plus haut niveau et t’assoir sur l’overhead. Pour JS, tu as les performances AU PRIX de la consommation de ressources, particulièrement de mémoire vive. Donc si tu utilise une surcouche, tu rajoutes encore de l’overhead.
• JS assume certains paradigme et en exclus d’autres. Le typage est zarb, le code est zarb, l’event loop est implicite… Donc si tu veux implémenter autre chose, tu ne peux pas sortir de ce paradigme, tu dois créer une API qui le masque. En plus d’être dégueulasse, c’est peu performant et il y a toujours des fuites du niveau d’abstraction.

Alors oui, on peut utiliser JS comme on utilise un assembleur, mais ce n’est pas un bon outil pour ça. C’est juste, encore une fois, le seul outil qu’on ait.

JS n’est bon à rien, et en rien. Il est mal foutu, c’est un brouillon qu’on se traine.

Certes, des gens brillant font des choses brillantes avec, performantes, utiles, fantastique.

Mais c’est MALGRE le language, pas GRACE au langage.

Tout autre langage ferait mieux. Malheureusement on a que celui là dans le navigateur.

Et comme on a que celui-là et que le Web est tout, on a investi des ressources incroyables dans le JS pour pallier sa nature déficiente. Si tu investis la moitié de ces ressources dans n’importe quel techo, tu aurais un truc extra-ordinnaire :

• tu prends la V8 de google et tu l’applique à un autre langage ? Boom ! Perfs de ouf. 10X celles du JS actuel.
• tu mets les commités d’amélioration ES6 et ES7 sur un autre langage ? Boom. Features de ouf (JS n’a pas encore rattrapé son retard malgré ça).
• tu transferts la communauté des devs web sur un autre langage ? Boom, doc et libs incroyable. (Quand on voit le nombre de personnes là dessus, on se dit que ce potentiel est tellement gaché, tant les tutos JS sont souvent merdiques)

Toutes les qualités de l’environnement JS sont uniquement liées au portail captif qu’est le navigateur, qui a forcé tout ce petit monde à payer la taxe JS. Rien à avoir avec le langage, qui est mal foutu, un verru dans le monde de la programmation.

Si le Javascript était l’assembleur du navigateur web, alors nous n’aurions plus à y toucher (sauf encore pour de rares exceptions très spécifiques) puisque nous disposerions d’un langage de haut niveau capable de compiler du Javascript. C’est le rôle du compilateur de connaître les subtilités et faiblesses du langage et les variantes selon les plateformes, et non le rôle du développeur. Ainsi, nous pourrions utiliser n’importe quel langage de haut niveau que l’on souhaite pour peu qu’il existe un compilateur adapté.

Un bon informaticien est un informaticien fainéant qui automatise les tâches rébarbatives. Ecrire du javascript compatible, propre et performant est une perte de temps: écrivons un programme qui le fait pour nous et concentrons nous sur les vraies problématiques.

Ce temps viendra, nous sommes encore à la préhistoire des technos web.