L’admin de #Wordpress réécrite de zéro sous la forme d’un client javascript
►http://ma.tt/2015/11/dance-to-calypso
▻https://en.blog.wordpress.com/2015/11/23/the-new-wordpress-dot-com
voilà #SPIP rép à ça… je pense qu’il va rapidement falloir offrir une #API compatible avec celle-ci !
Thousands more PHP developers will need to become fluent with JavaScript to recreate their admin interfaces in this fashion.
Héhé, j’en connais qui ne seraient pas rassuré⋅e⋅s par ça ^^
En plus des technologies derrières, plein d’idées en #ergonomie de l’admin aussi.
C’est surtout une horreur : pour se connecter à un admin wordpress il faut maintenant télécharger plus de 2 Mo de JS et autres trucs, résultat leur admin ne marche plus en 3G vu le temps fou que ça prend à charger. Et comme ça ne marche pas sans JS, impossible de juste recharger la page, ça ne juste marche pas. Bravo les sous-doués. Facile de designer des trucs qui pètent quand on a de la fibre au bureau. Venez vivre dans le reste du monde. Rien qu’ici en Australie les réseaux mobiles et ADSL sont une horreur, et ça le montre vite. Des sites comme CapitaineTrain, tout à base de JS bien lourd, sans fallback, ne marchent juste pas. Quand tu rapporte le problème on te dis gentiment d’aller te faire foutre. Belle idéologie de web accessible… :(
100% d’accord @bohwaz je suis complètement dans cette approche là : ça doit marcher sans Javascript (ce que j’essaye de faire pour toutes mes interfaces dans SPIP, que ce soit en admin ou en public).
Moi ce qui m’intéresse c’est surtout les améliorations d’ergonomie d’admin.
Mais après, avoir comme cœur une API qui sait vraiment tout faire, et que les interfaces (PHP, JS, client lourd sur le bureau, etc), ça me parait quand même une nécessitée aujourd’hui (et ça on l’a pas dans SPIP). Ce qu’il faut c’est que l’interface fournie par défaut ensuite soit vraiment accessible (ce qui n’est pas le cas ici apparemment).
Au sujet de l’accessiblité, en regardant vite faite leur exemple (une app Desktop et non une webapp), je pense qu’il migre vers un model App d’un côté (sur mobile ou bureau) et serveur API de l’autre.
Et quoi qu’il en soit, dans ce modèle le coût de la première connexion est élevé, mais après les données sont réduites au minimum.
Oui pour cette partie là je suis d’accord : que ce soit une application native ou même une webapp JS : dans les deux cas le but est de la télécharger UNE fois quand t’es dans un endroit avec de débit. Et ensuite c’est terminé, il n’y a plus que des interactions de contenus.
The new WordPress.com | scruffian
▻https://scruffian.wordpress.com/2015/11/23/the-new-wordpress-com
For the last year and some, I have been working on a secret project at Automattic. Today this project was released Open Source for the whole world to see.
This has been a fascinating experience; this project has changed a lot of things about the way we work at Automattic. Many of the changes have been technical; this was my first project using Node and React for example. However for me the biggest change is not the technology but the process.
À noter que pour ce projet ils parlent intégralement d’open source, jamais de logiciel libre. Et que ce projet a été développé en secret par une petite équipe, avec le code public dans un second temps.