flankerLe 08/08/2014 à 23:36
Bof. Il reste plein de choses super compliquées à faire en HTML par rapport à un client lourd classique.
Imaginons un cas de travail classique : j'ouvre deux fois le même document, une fois sans y toucher (comme référence), une fois en écriture avec plusieurs vues à chaque fois.
Même pour un truc de base, il faut :
* émuler une mémoire partagée entre les vues correspondant à la même ouverture de document, et répercuter les changements faits dans une vue sur les autres vues
* réécrire un explorateur de fichiers (bah oui, ça serait dommage de pouvoir utiliser un truc tout fait)
* sauvegarder les opérations sur le serveur (faudrait pas que l'utilisateur perde tout avec un F5 malencontreux), mais pas trop quand même (il n'avait pas forcément envie de sauvegarder !)
* exporter sous forme de fichier (parce que l'utilisateur a peut-être envie de le mettre sur clef USB)
* avoir un format de stockage côté serveur qui se prête bien aux lectures/écritures intensives (donc une BDD, mais tous les documents ne s'y prêtent pas) pour toutes les opérations de modification entre deux sauvegardes ; et tu ne peux pas le faire en local parce que l'utilisateur bosse peut-être sur deux machines
Bref, que des trucs fournis naturellement par l'OS mais que chaque application va devoir recoder…