RTFB

S'il y a bien une chose qui semble évidente si on regarde le monde du web actuel se dessiner, c'est que (presque) tous les frameworks actuels tentent d'éliminer complètement Javascript des préoccupations des développeurs. Les initiatives ne manquent pas et les systèmes complexes non plus :

• GWT - édité par Google, permet de générer du Javascript compatible avec tous les navigateurs à partir de code Java ;
• Vaadin - sur-couche à GWT simplifie encore plus le processus en incorporant plus de widgets de base ;
• SproutCore - framework Ruby génère du HTML et du Javascript pour créer une RIA complète ;
• Silverlight ;
• Flex ;

J'en passe un certains nombre sous silence et je n'évoque même pas l'excitation de certains sur HTML5 considèrant cette initiative comme le messie. Face à tout ça, il est difficile, en tant que développeur Java et Python, de dire aujourd'hui j'ai choisi Javascript !

Et ceci pour plusieurs raisons :

1. Au lieu d'aller à contre-courant en créant un système plus compliqué que le problème qu'il est censé résoudre (à savoir Javascript), je préfère mettre les mains dans le cambouis et m'en sortir en ayant appris quelque chose ;
2. Les performances sont toujours dégradés quand on créé une sur-couche à un système low-level (sinon pourquoi ferions-nous encore du C ?) ;
3. Les librairies Javascripts actuelles : jQuery, Dojo, Scriptaculous, MooTools, simplifient tellement les développements que pour beaucoup de fonctionnalités la compatibilité cross-navigateur est assurée ;
4. Les environnements de déboggage avec Firebug et l'inspection dans Google Chrome permettent de ne plus se débrouiller avec des alert() ;
5. De plus, même si pour certaines fonctionnalités j'utilise des méthodes HTML5, elles ne seront pas fiables avant quelques années.

Je ne compte pas le fait que mes applications actuelles utilisent pour beaucoup l'API Google Maps qui, bien qu'existantes pour GWT et Vaadin, reste beaucoup plus riche, performante et cohérente en Javascript.

Il y a un historique derrière cette envie de laisser Javascript dans sa tombe.

Javascript c'était le web kikoo-lol avec mister infonie au temps sacré de club-internet...

Seulement si le seul pouvoir de javascript résidait dans le fait de pouvoir poursuivre ta souris avec une bannière étoilée, je pense que non-seulement cet age là est mort, mais surtout d'autres utilisations sont apparues et sont maintenant adoptées par le grand-public.

Se mettre en marge de ça, c'est détruire un pan énorme de l'Expérience Utilisateur de ses visiteurs...

A vous de voir si ça en vaut la peine,

Vale

Que les choses soient clairs !! j'adorerais ne plus parler de voyages-sncf, mais le problème c'est qu'il fait encore parler de lui !!!

Et que comme je reste utilisateur fréquent du train (et que je ne suis jamais/pas toujours à coté d'une gare, la plupart du temps je commande mes billets via Internet...). Donc ma dernière perle est a propos d'un worflow "super bien cadré", d'un génie informatique de synchronisation...

Vous savez parfois quand vous choisissez une train, souvent marqué "Dernières places disponibles", ce qui doit arriver, arrive, lors de la validation, quelqu'un a été plus rapide, et vous revenez a la page de sélection, avec le message d'erreur suivant :

Ehh bien je pense qu'il doit y avoir un léger tiny pequeno problemo parce que ça fait exactement plus de 24 heures que le train afficher ci-dessus et le précédent SONT IN-SELECTIONNABLES. Car à chaque fois ce message d'erreur apparaît, sans la possibilité de sélectionner le "jeu" de places suivante de la même catégorie ( un peu plus cher, mais pas à 140 euros...).

Oui parce qu'ils sont gentils à la sncf, j'arrive très bien à choisir des billets à 140 euros juste en-dessous, mais franchement... si je pouvais éviter de me ruiner à cause d'un bug informatique de la sncf (encore...).

Heureusement la guérison du site est en bonne voie :