Jaxer

Aaaaah, je me souviens du bon vieux temps ou je découvrais le développement Web, lors de mon premier stage d’étude, sur une application PHP…
J’avais déjà découvert les joies des incompatibilités des navigateurs: à l’époque, Netscape était le navigateur officiel, et je me battais pour qu’on utilise IE5…
Je m’étais amusé à copier/coller des petits bouts de javascript à droite à gauche, sans trop comprendre ce qu’ils faisaient, afin d’avoir une interface plus user-friendly…
J’étais en admiration sur des applets Java beaucoup plus ergonomiques que mes bouts de Javascripts…
Et je bavais sur des sites entièrement Flash, magnifiques, et performants (quand c’était bien fait…)

Puis j’ai entendu parler de DHTML: « la grosse blague », ce sont les mots que j’ai sans doute prononcés quand j’ai su que ce n’était qu’un nom marketing pour le couple Html+Javascript.

Aujourd’hui on parle de Web 2.0 ou d’Ajax. On parle aussi d’Adobe Air, ou de Silverlight (on va éviter de parler de JavaFX). Finalement, pas de grosse révolution, mais plutôt une « évolution ».

Pour ceux qui ne sont pas au courant, je développe en .Net depuis un certain temps, et en ASP.Net depuis 1 an.
Comme ça a été conclu lors d’une réunion ALT.Net, les développeurs ASP.Net sont souvent issues du monde Winforms et convertis par la tendance actuelle.
Cela donne des développeurs complètement ignorant du protocole HTTP, de l’HTML et du Javascript: « C’est du C# ou rien! »

javascript for dummies

Moi même je ne suis pas BON en Javascript, pourtant tout est la:

Bref, avec du Javascript, il est possible de faire de bonnes applications Web aussi ergonomiques qu’une application Desktop.
Et le Javascript pour le Desktop justement? Python a la vedette en tant que langage de développement d’application Linux/GTK (même si Mono le devance maintenant). Et pourquoi pas des applications GTK-Javascript avec Seed (bon lien à ce sujet)? On peut noter aussi la tentative de Mozilla avec Prism, ou Adobe Air proposant des applications Desktop/Ajax

Mais la folie Javascript ne s’arrête pas là: pourquoi ne pas faire le Backend, côté serveur, en Javascript? Et bien messieurs, c’est maintenant possible!! Et ce serveur s’appelle Jaxer d’Aptana (dont j’ai parlé dans mon précédent billet).

Jaxer est un serveur web (Apache) avec un moteur de Javascript « server side » sous la forme d’un module, exactement comme pour du PHP ou du Python (ou encore du Perl). Je me permets de citer un blog qui explique ça très bien.
En résumé: avec l’attribut « runat=server-proxy », le code Javascript est appelable depuis le navigateur mais est exécuté sur le serveur.
Petit exemple:

<script runat="server">
  var newResultSet = Jaxer.DB.execute("SELECT * FROM myTable");
  var newPrice = newResultSet.rows[0].price;
</script>

C’est aussi simple que cela. Certains diront « beurk: du HTML+Javascript+SQL dans le même source… », mais cet exemple illustre bien ce qui est possible de faire. C’est maintenant à vous de séparer les librairies « .js » des pages HTML, et utiliser des procédures stockées ou un ORM Javascript (comme ActiveRecordJS).
Dans notre cas, le code n’est visible que du coté serveur, si maintenant on souhaite appeler une fonction sur le serveur sur un événement coté client, voici le principe:

<script runat="server-proxy">
  function myServerSideFunction() {
    // ...
  }
</script>
<input onclick="myServerSideFunction();" type="button" />

Dans ce cas, l’Ajax est effectué de manière automatique et transparente: une méthode « proxy » sera visible du coté client pour appeler le code du coté serveur.

C’est bien beau, mais c’est quoi l’avantage?
Après tout, pourquoi apprendre 4 langages ? En générale, on a ça:

  • HTML: interface statique
  • Javascript: traitement dynamique coté client
  • Java/.Net/Python/PHP/Ruby: traitement dynamique coté serveur
  • SQL : traitement des données

Aptana propose ceci:

  • HTML: encore et toujours 😉
  • Javascript: traitement dynamique coté client
  • Javascript encore: traitement coté serveur
  • pas de SQL à l’aide d’un ORM Javascript : ActiveRecordJS

Donc l’apprentissage de 2 langages suffit!!

Je sais que ça ne va pas plaire aux nombreux développeurs .Net qui adorent le C# et qui connaissent mal l’HTML+Javascript… ces derniers préféreront Silverlight, mais c’est un autre débat 🙂
Pour les autres, Jaxer est rapidement testable à l’aide de la solution Cloud d’Aptana, cela permet d’éviter d’installer et cofigurer un Apache.

Publicités

4 réflexions sur “Jaxer

  1. Comme le fait remarquer judicieusement un ami:
    « Et ton javascript côté serveur est visible dans le code client ?… »
    Uhmm, en effet c’est pas terrible…
    Mais si le code « proxy » appelle des méthodes « pure server-side » inaccessibles par le clients, ça peut résoudre le truc. Sauf que je ne vois pas comment faire de références entre Javascript si ce n’est dans la page HTML.

    De plus, au cas ou le Javascript est modifié/désactivé coté client, on préconise de faire une redondance coté serveur. Exemple: si le Javascript est désactivé et ignore donc la validation d’un champ de saisie, on préconise de refaire la validation coté serveur.

    Le concept me paraissait intéressant mais j’avoue que je ne pense pas en être très fan… et vous?

  2. si tu mets tes js server-side dans un répertoire nommé « jaxer-include », il ne seront plus visible coté client

  3. Jaxer n’est pas un serveur Apache, mais un module pour Apache. C’est assez limité en fait, impossible par exemple de conserver les objets créés coté serveur dans la page finale coté client

    exemple: (source http://www.youtube.com)

    <script runat="server" >
    		var yt = yt || {};
    		var yt = {};
    	
    		yt.timing = {
    			'default_action' : 'watch',
    			
    			'timers': {
    				'watch': {}
    			},
    			
    				'experiment' : '900029',
    			
    				'wff' : true,
    			
    			'tick': function(label, opt_action) {
    				var action = opt_action || 'watch';
    				yt.timing.timers[action][label] = new Date().getTime();
    			}
    		};
    		
    	
    		yt.timing.tick('start', 'watch');
    		
    		try {
    			yt.timing['pt'] = window['gtbExternal'] && window['gtbExternal']['pageT']() ||
    						window['external'] && window['external']['pageT'];
    		} catch(e) {document.write('<b>'+e.description+'</b>');}
    		
    	</script>
    

    L’objet yt est perdu coté client

    1. En effet je me suis mal exprimé, merci pour cette précision 🙂
      Dommage que les variables soient perdues côté client (mais c’est le cas dans les autres langages). Ça peut être contourné en sauvegardant les variables dans des hidden input au format JSON (c’est en tout cas ce que je fais entre JS et C#).
      Par contre, le module support-il un cache de session côté serveur?

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s