J’avais demandé si il y avait encore des gens intéressés par le tuto angularjs que j’avais commencé. En effet les ressources sur Angular sont généralement de mauvaise qualité, et la réponse avait été un gros OUI.
Je m’étais donc mis en tête de continuer. Malgré la mort annoncée du framework. Malgré une V2 qui va tout casser.
Voyez-vous, j’aime Angular. Bien que je pense que pour des grosses apps une approche comme ReactJS + BackboneJS est plus saine, pour une petit app rapide ou du prototypage c’est très productif et pratique.
En plus, je n’aime vraiment pas manquer à mes engagements, et en presque 3 ans de ce blog, je les ai tenu. J’ai toujours publié les articles promis. Toujours répondu aux mails. Parfois avec des mois de retard, certes, mais je n’ai signé aucun contrat moral sur les deadlines :)
Je vais néanmoins faire une exception ici et envoyer le tuto Angular au cimetière. Toute mes excuses à ceux qui l’attendaient.
Bien sûr il y a le fait que j’ai beaucoup de travail. Cependant si c’était la cause principale je n’écrirais plus ici car ça me demande des heures et des heures chaque semaine.
C’est surtout qu’il se trouve que j’avorte régulièrement des tentatives de retravailler dessus. C’est un signe de manque de motivation certain, et je viens d’en comprendre aujourd’hui la raison : c’est du Javascript.
Jusqu’ici le blog s’était autorisé régulièrement des sorties de la ligne éditoriale, mais un tel travail, un guide complet sur Angular, enterine le JS comme un sujet majeur du site.
Or ce n’est pas le cas.
Du coup non seulement me motiver à faire le dossier me demande une énorme énergie (qui pour le moment se transforme en procrastination coupable), mais en prime je me dis que c’est dépenser des ressources pour faire le taff d’une communauté qu’au final je ne supporte que par obligation professionnelle.
Le résultat est donc que bien que je vais continuer à parler de JS et à coder en JS (programmation Web oblige), je ne vais pas lui accorder autant de place sur S&M ou dans mes heures de loisir.
Je remercie ceux qui prennent le temps de le faire, après tout je profite de leur travail. De mon côté, je vais me concentrer sur les domaines qui me sont plus chers, et parler d’autre chose uniquement de manière ponctuelle. L’investissement me parait plus judicieux.
Vouloir t’éparpiller n’est pas une bonne idée.
De plus depuis 3 ans déjà, t’as réalisé un travail énorme sur l’explication de python.
Et avec les évolutions de python, t’auras encore beaucoup de boulot.
T’es pas jésus qui veut sauver tout le monde.
A un moment les utilisateurs d’Angular doivent se bouger pour faire à Angular ce que t’as fait à python.
Si il y a personne, tant pis pour Angular qui sera réservé à quelques personnes et agonisera.
Petite parenthèse par rapport à php, Rasmus Ledorf a toujours répété que le succès de php qui est un langage pourri (il le dit lui même) est dû aux 80% de noobs qui font des tutos et répondent aux questions dans les forums : la langage est pourri mais la communauté est forte.
C’est pour cela que Ledorf s’oppose à toute évolution rapide du langage pour ne pas perdre sa base de 80% d’utilisateurs.
T’as aucun regret à avoir de ne pas sortir un tuto Angular.
Je suis d’accord avec ultra, mieux vaut se concentrer sur python.
D’ailleurs, Ninja Squad a sorti un très bon ebook sur angularjs 1.
“De plus depuis 3 ans déjà, t’as réalisé un travail énorme sur l’explication de python”
+1
Et encore “travail énorme” c’est peu dire. Ça m’a toujours surpris de voir le débit des articles postés ici, d’autant plus que chaque article est de qualité et à une énorme valeur. Je me demande vraiment où tu trouves le temps de faire tout ça, en plus seul et bénévolement… c’est exceptionnel.
Je fais partie de ceux qui attendaient la suite du tuto dans un coin de leur tête et franchement c’est pas grave, on survivra ! C’est vrai que les ressources dispo sont pas légion, mais il y a quand même quelques tutos et guides dispos sur le web.
Ce qui me plairait bien un jour, c’est d’avoir ton avis sur les outils / libs / frameworks JS que tu utilise éventuellement dans ton taf’ et qui t’aident à supporter ce language. S’il y-en a.
Quoi qu’il en soit, merci pour ton implication à travers ce blog :)
Je suis nouveau sur ce blog, mais si tôt découvert, si tôt adopté. Bravo pour la qualité de tes exposés, c’est génial d’avoir une telle doc à dispo.
Et sage décision de ne pas (trop) te disperser : Trouver le juste milieu entre l’enfermement dans une technologie et le maintien d’un niveau de veille suffisant est délicat, tu sembles y réussir, bravo !
Et encore merci pour le taf :-)
Est ce que cela marque la ligne éditoriale ou le choix n’est que personnel ?
En d’autres termes est ce que des articles contributeurs sont bienvenues ? Sur des sujet comme : les nouveautés d’ES6, React Flux.
Salut,
c’est toujours dommage de voir ce genre de boulot partir, mais ça se comprend.
Une petite proposition qui vaut ce qu’elle vaut, si ton tutoriel est sous licence libre, est-ce que cela te botterait de proposer à la communauté de Zeste De Savoir de le reprendre, le retravailler pour le publier à la fin sans pour autant que ça ne bouge la ligne éditoriale (excellente) de sam&max.
Bonne continuation !
@TychoTa: les articles contributeurs sont beaucoup plus rares, donc ça ne pose pas de problème si c’est du JS.
@artragis: tout le blog est sous licence creative common donc vous pouvez sans problème le faire. Si on est prévenu, on fera un petit article pour dire ou trouver la suite.
Sinon pour faire du python à la place du JS, y’a Brython ou encore Skulpt.
Je suis pour toute initiative rendant possible la mort et la disparition de Javascript.
Angular fût une branlette passagère. On se branlera sur autrechose !
@buffalo974 #YaUnArticlePourÇa http://sametmax.com/python-like-na-aucun-interet/
Ca vaut quoi franchement ces solutions clients en python ?
[edit] (pour le message du dessus)
Le problème c’est que les navigateurs ne supportent pas python du coup on est tjs obligé de retranscrire en JS si j’ai bien compris ?
batisteo merci pour le lien. Si les navigateurs ont été crées avec du C, et que python peut appeler du C avec ctypes, je me dis qu’ à force … On finira bien par voir apparaître un navigateur qui parle python ?!
La question que je me pose, c’est pourquoi ça n’ existe pas encore ?
@buffalo974 : je me posais récemment exactement la même question sur le sujet, ça m’a limite empéché de dormir, du coup j’ai fait quelques recherches sur le sujet, et la réponse est : “Ca n’existera probablement jamais”. Pourquoi ?
Parce que ça forcerait tous les éditeurs de navigateur (Apple, Microsoft, Google, and co) a faire de la maintenance supplémentaire des langages pris en charge par leur navigateur. Gérer Javascript (compatibilité des nouvelles versions, optimisations des perfs, etc.) demande déjà du boulot apparemment. Ils veulent éviter la fragmentation ! Concrètement, ils n’y gagneraient rien à rentre les navigateurs compatibles avec d’autres langages. Autrement dit, le “merci” des développeurs a moins de valeur pour eux que des centaines de développeurs supplémentaires à engager pour maintenir les langages supplémentaires.
En plus, il faudrait qu’ils se mettent tous d’accord…Si Python est supporté dans Chrome, mais pas dans Safari, ça ne sert à rien.
Et puis vient ensuite le choix des langages : pourquoi Python et pas Ruby ? Pourquoi Ruby et pas bidule ? etc..
Le plus rageant dans tout ça, c’est que techniquement, il n’y aurait absolument aucun problème à utiliser Python (et beaucoup d’autres langages) dans les navigateurs. Mais l’histoire a fait que c’est JS (pas le meilleur) qui s’est imposé car il était là le 1er.
Vous imaginez l’équivalent d’un meteor.js en python ? Un framework 100% Python permettant de faire le back ET le front, de manière unifiée ? Oui ça fait rêver, mais non ça n’arrivera pas.
Donc en gros aujourd’hui on a 2 solutions pour faire un site moderne (désolé pour le parti pris) :
– Soit je veux un langage unique, et donc j’accepte de prendre un langage caca comme JS, et après je m’éclate à faire du meteor ou autre.
– Soit je veux au moins un backend avec un langage décent, donc je fais du python/ruby de ce côté, et je subis l’utilisation d’un langage différent pour le front.
Pour finir, Google a tenté tout de même d’introdure un nouveau langage en plus du JS dans les navigateurs, qui s’appelle DART, mais le projet a avorté : http://techcrunch.com/2015/03/25/google-will-not-integrate-its-dart-programming-language-into-chrome/
Concrètement, a lieu d’intégrer le langage “purement natif” dans Chrome, il va s’agir de conversion vers du JS (on retombe dans les solutions merdiques).
Il y a un tuto sur angular2 ici
http://autourducode.com/angular2-premier-pas/
@walt oui c’est sûr que ça demande du boulot de maintenance. Mais les 3 exemples que tu as pris sont des
entreprises. On pourrait imaginer que des dev indépendants à l’ image de ceux qui ont crée Linux ou Mozilla nous pondent un navigateur bilingue : par défaut il lirait le javascript, mais il switch sur un mode python si il lit la balise . A terme il redeviendrait monolingue suite à la disparition du JS ^^.
Actuellement, tout le monde fait par automatisme du JS parce que c’est lui qui a le “monopole” pour raison historique, donc il bénéficie des dernières évolution cool : meteor.js , node.js etc. Normal il a une énorme communauté.
Mais si demain on se rend compte qu’on peut obtenir un gain de productivité conséquent grâce au python ?
Je pense que le projet Brython est un prototype, une preuve de faisabilité. Son gros problème c’est qu’il est
forcé de traduire en JS.
Le langage de base d’un ordinateur est l’assembleur (basiquement une représentation “lisible” par les humains des instructions machine). Aujourd’hui nous ne développons plus en assembleur (sauf pour de rares exceptions très spécifiques) parce que c’est vite complexe et qu’il existe des compilateurs qui écrivent de l’assembleur bien plus efficace que nous à partir d’un langage plus proche de nos modes de pensée (C, C++, Python, etc).
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.
Sauf que Javascript n’est PAS un assembleur :
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 :
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.
Y’a un peu d’ espoir pour le futur ? dans quelle direction ?
Il y a deux bons points :
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.
Sur le thème des améliorations du JS : http://pro.clubic.com/creation-de-site-web/langage-programmation/html-5/actualite-770804-webassembly-google-microsoft-mozilla-transforme-javascript-binaire.html
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 ! ^^
Ca me fait penser à ça : https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
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 :
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 :
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 :
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 :
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 :
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.
En effet ça fait un paquet de choses sympas ! Tu commences quand ? (ah non pardon tu as déjà une plate-forme de blog en cours au temps pour moi ^^).
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>
Si, on peut carrément avoir un meteor.js en python, justement :)
Est-ce que ça signifie “pouvoir faire un site web (front+back) entièrement en Python ?” Comment c’est possible ?
Non, mais ça veut dire pour faire des la mise à jour temps réel avec des modèles côté clients qui font automatiquement des modifications sur le serveur de manière transparente.
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.