Denis Dollfus' Blog

DotWeb : commémoration du premier anniversaire de la disparition de Volta

Il y a un an jour pour jour le projet Volta s'arrêtait brutalement malgré un accueil enthousiaste. Volta proposait (très) ambitieusement des outils pour faciliter le codage et le déploiement des applications Web n-tier. Dans une approche très "write once run anywhere", le même code C# aurait pu être déployé sur le serveur ou sur le client, la même IHM aurait pu se matérialiser en Ajax ou en Silverlight.

Dans la série "On Trouve Tout Sur le Web" : le tombstone generator

Je suis plutôt circonspect sur le côté "write once run anywhere" tant les problématiques de performance et de cache, pour ne citer que celles-là, diffèrent suivant l'endroit où le code s'éxécute. 

En revanche le fait de pouvoir écrire en C# ce qui tournera en Javascript promettait confort et productivité. Non pas que le Javascript soit une ignominie, mais simplement que les outils d'assistance au développeur sont bien plus élaborés en C# qu'en Javascript de par le simple typage fort de C#. L'auto-completion, le refactoring semi-automatique et l'orientation objet structurante (i.e. getter et setter ) suffisent à faire la différence. 

Aborder une grosse application Ajax en C# plutôt qu'en Javascript rassure. En C# "si ça ne compile pas, ça ne marchera pas" dit le dicton. En JavaScript puisqu'il n'y a pas de compilation, il reste "ça ne marchera pas". J'ironise mais tous les développeurs qui parcourent le Web en mode "debug" savent au nombre d'erreurs de script rencontrés combien le JavaScript fait souffrir le Web. 

Bref. Y a-t-il une vie après Volta ?

Oui :

1. Il y a mieux que Volta, il y a Script#, bien supérieur à Volta parce que lui n'est pas mort. Script# a servi en interne chez Microsoft au développement d'Office 14 version Web, de Live Messenger et de Live Mesh. Script# marche bien, les contributions (ExtJS#, jQuery#) en témoignent. Un avantage de Script# est que le Javascript généré est parfaitement lisible. En revanche pas moyen de poser un point d'arrêt au sein du C#, il faut débugger en JavaScript. Néanmoins cette approche permet déjà de concevoir Javascript comme le langage assembleur du Web : un truc réservé aux experts, bien compris des machines mais peu des humains, qu'on a vu à l'école et qu'on oublie sans remord (pas .
2. Il y a mieux que Script#, il y a Google Web Toolkit (GWT). Avec un succès grandissant, GWT est de plus en plus utilisés dans les applications de taille respectable. Google Wave notamment repose sur GWT. Pour fixer les idées concernant sa popularité, d'après Google Trends GWT est presque aussi populaire que Linq. Au fait : au lieu de C#, GWT s'appuie sur Java. Gros avantage par rapport à Script#, GWT permet de debugger directement dans le code Java, plus besoin de visualiser le JavaScript, qui n'a désormais plus vocation à être lu et a fortiori édité.
3. Pour info le précurseur de ses outils s'appelle Morfik, toujours commercialisé. Je ne le connais pas.
4. Encore plus fort, pendant que je préparais ce billet qui aurait du être un simple hommage à feu Volta, Franck Laub annonce sur le forum Alt.Net l'existence de son projet de clone .Net de GWT, DotWeb. DotWeb est le seul environnement dans l'esprit "JavaScript est l'assembleur du Web" qui dispose d'un debugger C#. A suivre de très très près ! Franck recherche des contributeurs, c'est une opportunité pour des développeurs intéressés. Les sources de DotWeb, pour en avoir le coeur net,  sont disponibles ici.

Excellent timing !

Un profiler JavaScript pour IIS et Visual Studio

Annoncée le 29 avril, les Microsoft AJAX Profiling Extensions sont des extensions pour IIS 7 qui interceptent tous les fichiers JavaScript envoyés aux navigateurs pour y injecter des fonctions JavaScript de mesure de temps d'exécution. Ces mesures réalisées côté client sont ensuite renvoyées au serveur pour y être stockées jusqu'à la phase de visualisation et d'analyse menée sous Visual Studio.

Firefox et Internet Explorer sont supportés par les Profiling Extensions qui viennent finalement compléter le très spécifique profiler de Internet Explorer 8.

AJAX Profiling Extensions est dérivé du projet de recherche AjaxView (http://research.microsoft.com/en-us/projects/ajaxview/). Il n'est malheureusement disponible qu'aux possesseurs de la version de Visual Studio équipée de Performance Tool (donc Visual Sutio Team System 2008 Developper Edition ou Team Suite).

Pour télécharger Microsoft Visual Studio AJAX Profiling Extensions Power Tool : http://code.msdn.microsoft.com/AjaxView
L'annonce : http://blogs.msdn.com/somasegar/archive/2009/04/29/vs2008-ajax-profiling-extensions.aspx

JSINQ : LINQ to Objects en Javascript

Une implémentation de LINQ en Javascript vient d'être publiée sur CodePlex par Kai Jäger. Elle permet d'écrire des requêtes sur des tableaux d'objets Javascript :

var query = new jsinq.Query('\
 from order in $1 \
 group order by order.customerId into g \
 select {customerId: g.getKey(), items: g.sum(function(g) { return g.items; })} \
 into h \
 join customer in $0 on h.customerId equals customer.id \
 where h.items > 10 \
 orderby h.items descending \
 select {lastname: customer.lastname, items: h.items} \
');
query.setValue(0, customers);
query.setValue(1, orders);
var result = query.execute();

Etonnant non ?

Source http://www.infoq.com/news/2009/02/JSINQ-JavaScript-LINQ

Le projet sur Codeplex

Une page pour manipuler des expressions JSINQ

0HTML : du HTML sans HTML

Photo cc Curious_Zed

Pourquoi faut-il générer du HTML sans écrire du HTML ?

• Parce que HTML ressemble au XML, et que XML est affreux;
• Pour faire comme JavaFX, qui permet de décrire le code et les élements graphiques avec un seul langage au lieu des duos habituels graphique/code tels que XAML/C#, MXML/ActionScript et HTML/Javascript. Regardez cet exemple de code JavaFX pour comprendre comment graphiques et code (déclaratif et procédural) s'enchevêtrent en JavaFX.

Sans code côté serveur, ça serait trop facile.

Voici donc une tentative baptisée 0html (qui repose sur jQuery). Vous constaterez que les sources ne contiennent que très peu de HTML, même la balise body est manquante. Fondamentalement, c'est du HTML écrit en JSON.

Puisque je ne pense vraiment pas être le premier à y avoir pensé (plus de 200 frameworks Javascript...), connaissez-vous des frameworks qui ont déjà atteint l'objectif de créer des pages Web sans écrire de HTML (ni des montagnes de code procédural) ?

Les processeurs multi-cœurs enlisent les applications Web

Le JavaScript standard, celui qui soutient l'actuel déferlement d'applications Web, est mono-thread. Il ne pourra exploiter qu'un seul des 8 cœurs de la prochaine vague de processeurs parce qu'il n'offre aucun moyen aux développeurs d'expliciter le parallélisme des traitements, contrairement à Java, C# et C++ par exemple.

Manque de chance, l'accroissement du nombre de cœurs s'accompagne d'une baisse de la fréquence des processeurs qui laisse une impression de perte de puissance à l'usage d'applications peu ou pas parallélisées.

Dans les mois qui viennent, avec le renouvellement des machines et bien avant l'hypothétique 80 cœurs d'Intel, les applications Web vont donc s'enliser peu à peu, condamnées à s'exécuter sur un unique thread de moins en moins nerveux.

Sauf si... des solutions de multithreading non standard sont mises en œuvre, qui consistent pour l'essentiel à exposer au sein de JavaScript une extension multi-threaded que l'utilisateur doit télécharger. Aujourd'hui Google Gears (Cf. cette présentation) et Microsoft Silverlight le permettent. Pas Adobe Flash/Flex car ActionScript est mono-thread (Adobe aurait-il quelque chose dans les cartons ?).

Parions que les éditeurs de navigateurs vont chercher à imposer leurs solutions. Silverlight est plutôt bien placé mais propriétaire, Google pousse Gears dans Chrome et cherche à le standardiser via les Web Workers de HTML 5, Mozilla va livrer une version de FireFox qui implémente le même (futur) standard et Internet Explorer 8.0 ne semble pas motivé pour s'y conformer.

Avec les nouvelles technologies on n'est pas prêt de s'ennuyer...

Frameworks JavaScript : jQuery au top

Le temps a fait son oeuvre, il est plus facile de choisir un framework JavaScript aujourd'hui qu'hier.

Si vous considérez que le critère de choix est l'adoption par le plus grand nombre de développeurs, alors choisissez jQuery, pour lequel Google Trends montre une évolution stupéfiante (en rouge ci-dessous, voir aussi le lien "live") :

Si le point de vue technique guide votre choix, alors choisissez aussi jQuery. Il semble qu'il y ait quasi-consensus pour évaluer jQuery comme un framework élégant (dont une fluent interface), léger, complet et extensible. C'est en tout cas ce qu'on peut lire sur certains blogs, de la part de gens sérieux qui on eu le temps de comparer, eux. Ce papier est bon descriptif des points forts de jQuery.

Enfin bon dépêchez vous de choisir un framework Javascript avant que ce langage ne sombre dans l'oubli, occulté par des surcouches Java (Google Web Toolkit) ou C# (Script# , Volta).

LE livre JavaScript

C'est le bouquin qui surpasse vraiment les autres en termes de nombre de mises à jour (5ème édition), d'avis de lecteurs et de ventes.

Pour moi qui replonge verticalement dans le JavaScript après un double salto C++ et une vrille C#, je retrouve dans ce livre tous les attributs d'un livre de qualité. Et je peux constater que les chapitres ont suivi l'évolution de JavaScript et de l'usage qu'on en fait depuis Ajax et le Web 2.0 : closure, Javascript orienté objet, namespaces, XMLHttpRequest, animation graphiques, etc.

Et puis un bouquin de 1024 pages tout rond, c'est un must, non ?

Sur Amazon : Javascript, The Definitive Guide

Super Mario en 14 Ko de Javascript

Ce mini-jeu en Javascript  n'occupe que 14ko. Il ne contient pas d'images, sous IE les graphiques sont rendus en jouant avec les div. Impressionnant.

http://blog.nihilogic.dk/2008/04/super-mario-in-14kb-javascript.html

Productivité de JavaScript en Visual Studio 2008

La nature dynamique de JavaScript et son manque de typage explicite rend difficile la mise au point d'un système d'auto-completion de type IntelliSense. Pourtant il y a un bon moment qu'IntelliJ le propose, ayant assisté à une démo vraiment impressionnante de cet IDE au dernier JavaPolis. Même si, en informatique, "un bon moment" c'est une poignée de mois.

Visual Studio 2008 nous promet des avancées fondamentales dans ce domaine mais lesquelles ? Pour ceux qui n'ont pas la patience de télécharger la béta, voilà ci-dessous un lien vers un billet de Scott Guthrie qui nous éclaire : inférence des types, références à des fichiers JavaScript externes, à des services Web JSON, etc.

Indéniablement des progrès.

Cf. le post de Scott.