J’ai du travailler sur kendo, et en suis plutôt satisfait.

(kendo apporte une UI en plus du reste)

(le source kendo est compréhensible)

C a été la révolution car c’est un super macro-processor (même C++ n’est que macro à mon sens…)

Java a apporté la gestion automatique de la mémoire, un gros gain de productivité.

JS est l’adaptition pour Mr tout lemonde, et permet de coder vite.

50 ans et on est toujours dans la même veine !

Il y a beaucoup de nouveau langages, plus ou moins sexy, réduction de code, clarté, etc.

Mais il faut rester pragammatique.

Les solutions actuellement viable, à mon sens, sont :

– des langages proches / compatibile avec cette famille historique

– l’usage des “trans-compiler” pour les comptiler en langage “natif”.

– que le code généré soit lisible / debuggable avec reférence au source.

Exemple: Typescript compilé en Javascript.

Les extension au langage doivent prendre la forme de framework

– simple

– debuggable

– auto documenté

bref…

N’aimant pas JS, mais ayant porté intérêt à angular, voici un nouveau sujet:

            http://reactivex.io/

C’est multilangage, et finalement le point le plus attendu dans la programmation moderne:

– la gestion des asynchrone.

(Perso: je plussois l’initiative nodeJs, bien que perso je préfère java)

(arf, je devrait dire Csharp, même si java finira par rattraper tardivement son retard)

(Js et autre sont cool car tu code à la volée)

(Java nous offre une garantie par le typage à la compilation, c’est non néglligeable)

(ES6 ne réconcilie nullement ces deux langages et ne sera manifestement pas adopté)

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 ! ^^