Les futurs logiciels se feront en ligne et avec du Javascript

Un billet que je mijote dans ma tête depuis longtemps. Je suis de plus en plus séduit par les applications en ligne, et notamment par la qualité et la rapidité de ce que l’on peut faire en Javascript. Dans Javascript, j’inclut bien sûr tout ce qui se passe via AJAX, qui n’est pour moi que la version « dynamique » de Javascript. Donc pour moi, nous allons arriver dans une êre où on va arrêter purement et simplement de bâtir les logiciels professionnels en mode « offline » et ne faire plus que du online via Client léger (du SaaS si vous préférez).

Bon, de ça, j’ai déjà parlé. Ce qui vient après est nettement plus intéressant.

Voyez-vous, ce qui intéresse actuellement les boites de recrutement (sortes d’entreprises où l’on demande -pour pas cher- à des gens qui n’y connaissent rien, de faire un premier tri de candidats), ce sont les compétences en Java-J2EE. Si vous avez fait du J2EE à l’école, mais que vous avez fait du Struts, Hibernate, Tapestry, Spring MVC en entreprise, et que vous dites que non, vous n’avez pas fait du J2EE en entreprise (considérant avec raison que les frameworks cités ci-dessus ne sont pas du J2EE pur), et bien point de salut pour vous, vous ne passerez pas à l’étape suivante (pour moi, dire que j’avais travaillé sur du GlassFish, des JSP et du JDBC à plusieurs reprises à l’école + du NetWeaver en entreprise n’aura pas suffit à convaincre de ma capacité à faire « du J2EE »).

Cette constante ambition de trouver des « développeurs J2EE » me semble d’autant plus idiote que je ne crois pas (mais alors, pas du tout) au J2EE, ni d’ailleurs aux freworks MVC « classiques » pour faire du logiciel, même si c’est avec ça que beaucoup sont développés à l’heure actuelle. En tout cas pas après ce que j’ai pu voir des possibilité offertes par le Javascript.

Voilà quelques frameworks qui font des choses tout à fait fantastiques :

  • GWT : Java vers Javascript, a mon avis le plus gros potentiel dans les 5 à 10 années à venir. Si vous cherchez un boulot, oubliez le J2EE (ou voyez-le en vitesse), et foncez vers GWT.
  • Pyjamas : le portage de GWT en python. Je n’ai pas regardé, mais j’ose espérer que cela fait aussi bien que le GWT.
  • Ruby On Rails : Tout le monde connait (enfin tous ceux qui ont entendu parler de Ruby). Son gros point fort ? L’intégration d’AJAX au sein du framework. En ruby, il y a aussi SproutCore.
  • Gianduia : pour faire du Javascript en Cocoa, j’en ai parlé ici : Avec Gianduia, Apple vise Flash et Silverlight, mais aussi GWT. Il y a aussi Cappucinno.
  • ASP.NET : Au vu de ce qui a été fait sur Hotmail, et que tout est en Javascript, je pense que le potentiel est là, il n’y a plus qu’à l’exploiter.
  • ExtJS : En Javascript, mais plus orienté création d’application que JQuery et Prototype (à mon avis).

Donc avec cela, je pense que l’on tient les outils de création des logiciels de demain. Ces logiciels seront aussi facilement utilisables que ceux d’aujourd’hui (voire bien plus à mon avis), et il suffit que suffisamment d’entreprises/clients comprennent que leur salut est dans le Javascript (certains, comme SFEIR, l’on déjà compris), pour que cela continue à se développer. Avec le partenariat que vient de signer Google (pour intégrer GWT à Spring Roo), je ne doutte pas que la balance va commencer à peser dans ce sens.

Pour ma part, mon choix est déjà fait : je vais me mettre dès que possible au GWT et un peu à ExtJS, Pyjamas viendra ensuite : j’espère que cela saura me trouver du boulot pour la décennie à venir.

3 réflexions sur « Les futurs logiciels se feront en ligne et avec du Javascript »

  1. Je te conseille aux Editions Eyrolles : Programmation GWT 2 par Sami Jaber qui est très bien écrit sur le sujet, et regarde un peu du coté de Google AppEngine/java qui permet de très rapidement mettre en oeuvre des applis GWT.

    Les framework Javascript ne traitent que de la partie cliente des applications, et il subsiste le backend à implémenter, et c’est pourquoi aussi les technologies comme J2EE ont encore de beaux jours devant elles.

    RépondreRépondre
  2. @Vincent: MErci pour le conseil de livre, je vais voir ça 🙂

    Pour la précision sur la partie cliente/partie serveur, c’est tout à fait vrai. Pour ma part, je privilégierais plutôt une interface REST JSON via PHP/MySQL/Apache, cela me semble bien plus rapide à développer (pour mes besoins en tout cas) et plutôt assez simple.

    RépondreRépondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.