Okay, donc vous pensez que Twitter est une abomination.

Mais donc pourquoi?

Quelles parties ne vont pas?

Est-ce que c'est le problème de base qui serait en cause, trop compliqué?

Est-ce qu'on peut trouver des meilleurs exemples?

I est forts pour trouver des adjectifs et des noms pour critiquer, mais il en faut plus pour écrire une critique.

Go go go!

L'application n'est pas intuitive, ils veulent la jouer application web à la cool mais tout est lent. Un exemple : tu cliques sur un profile, tu as une espèce de popup avec un résumé des informations (et seulement 3 ou 4 derniers tweets, si je ne dis pas de bêtises). Tu veux voir le profil entier, c'est chargé en AJAX et ça prend du temps, alors qu'une requête à l'ancienne prendrait moins de temps, j'en suis convaincu.

Hier soir, un mec (@tsamere) lançait un "Ça va être tout noir", j'ai voulu voir si beaucoup de gens lui allaient répondre "ta gueule". Résultat : plein de personnes sur tweetbot pour iPad, 2 seulement sur la version web.

Le pire, c'est qu'on ne peut même pas leur accorder le fait que ce soit complexe à mettre en place, beaucoup de clients tiers le font (cf Tweetbot <3 où encore Echofon qui, même moche, gère super bien le coté live de twitter). Certes je parle de client lourds, mais pour avoir joué avec leur API, un bout de nodejs et des websocket, l'instantané ne serait pas un problème à mettre en place.

Le plus grave à mon sens c'est qu'ils sont en train de fermer leur écosystème aux clients tiers. C'est normal de vouloir reprendre le contrôle et (enfin) gagner de l'argent, mais pas quand c'est pour faire de la merde à coté.

À ce que je sache, Tweetbot et Echofon sont des applications natives, et non des applications web, avec une version spécifique à chaque plateforme, et capable de gérer des connexions persistantes. D'ailleurs on notera quand même que si ce côté temps réel est possible, c'est parce que leur backend est un monstre scalable.

Certes, c'est facile de coder un prototype avec Express et Socket.io, mais si tu cibles le plus de browsers et le plus de connexions (fixe, mobile, boulot…) possible, tu ne pourras pas envisager les websockets.

De plus, maintenir cette connexion persistante c'est couteux. Ils ont déjà moins de fail whale, mais imagines si sur les 2 millions de followers de Gaiman, 1% sont connectés. Ça veut dire que chaque tweet sera distribué à deux millions de personnes, dont 200 000 à des gens connectés sur un même serveur ou plusieurs serveurs parfaitement alignés sur une mémoire partagée.

Donc oui, je peux écrire mon client, mais il sera vite mort.

Dans la plupart des cas super scalables (Google, Facebook…), on aura le droit à des sockets que pour le chat, et le reste sera fait en Ajax, parce qu'on peux même pas encore envisager du temps-réel parfait à ce niveau.

Ce gros souci des applications web persiste, et on commence à voir des trucs comme Derby et Meteor, qui font ce que font déjà Twitter et Google, c'est à dire faire du rendu côté serveur et côté client de façon hybride. C'est toujours ultra lent quand bien chargé, mais c'est le plus rapide.

Oh, Google avait bien un deal pendant un moment qui lui permettait d'avoir un stream live de twitter dans les recherches.
C'est que ça doit être scalable :)

Juste que ça ne va pas dans le sens de twitter - le business, pas le service.

Enfin, bref, il y a tout a fait moyen d'avoir un client web aussi efficace qu'une appli native dans le cas de twitter. Ca reste un stream de texte au final.

Le problème, comme l'a dit @Palleas, c'est que ce n'est pas dans le sens de Twitter. Le business veut mettre en avant les cards et l'onglet Discover. Et ainsi devenir une source de news, au détriment de la contribution.

Un peu de lecture sur le sujet.

> Tweetbot

Owi <3

Justement, c'est Dalton qui a lancé App.net, spécifiquement parce que Twitter partait dans des directions que le public n'aimait ou ne comprenait pas.

Il voulait un flux brut où la sémantique était donnée par l'utilisateur et ses choix, mais eux partent dans un sens où la sémantique du flux de données est fortement contrôlée par eux.

Pour ce qui est d'une application web, comme je disais tu peux pas avoir autant de connexions persistantes en parallèle. C'est pour ça qu'on a plus accès au Firehose, ni d'ailleurs à des flux en vrai temps réel (Long HTTP ou Ajax, SSE si on veut).

Ce que je dis, c'est que le backend est super scallable, et Google a une infrastructre C++/Javascript ou le render est fait des deux côtés de l'application. Sauf que Twitter n'a pas cette infrastructure, et ils apprennent lentement comment ils vont devoir livrer leur application le plus rapidement.

On peut discuter de design. Dans ce domaine ils ont certainement du chemin à faire, mais comme tout site web client, plus on la charge, plus elle ralentie. Il suffit d'essayer une app Google ou Facebook, qui sont des monstres niveau efficacité, pour voir que mêmes eux sont lents.

C'est facile de dire que c'est pourri ou qu'on peut facilement faire mieux, mais les développeurs web de chez Twitter sont quand même super réputés dans leur domaine.

Dans ce que vous dites, le truc qui m'embête le plus est le fait qu'ils ferment leur API...