Le Post Infeeny

Les articles des consultants et experts Infeeny

Archives de Catégorie: HTML5

Écriture/lecture/modification de fichiers dans un projet Universel app/UWP et cordova

Dans nos applications, nous avons pris le parti d’écrire nos fichiers en JSON. Nous avons donc conçu une abstraction (en WinJS, avec un système de promises) qui nous permet d’utiliser des méthodes claires et simples sur toutes les plateformes (WinRT/UWP ou Cordova (iOS/Android) )

Ce module « DataContainer » est disponible dans notre libraire WinJSContrib (Github)

Dans WinJSContrib.DataContainer, nous avons 4 fichiers qui exposent les mêmes méthodes avec des implémentations différentes :

  • read : lecture d’un élément
  • save : enregistrement d’un élément
  • remove : suppression d’un élément
  • list : liste des fichiers d’un container
  • child : création/accès container enfant

Dans une application WinRT/UWP nous allons naturellement utiliser la couche WinRT/UWP pour écrire/lire les fichiers. Pour cela il suffit d’inclure le fichier « winjscontrib.datacontainer.winrt.file.js »

Dans une application cordova IOS ou Android, nous avons plusieurs choix :

  • Utiliser une base de données : winjscontrib.datacontainer.cordova.database.js
  • Utiliser le système de fichiers avec le plugin file : « winjscontrib.datacontainer.cordova.file.js »
  • Utiliser le localStorage : « winjscontrib.datacontainer.localstorage.js » (utilisable en WinRT aussi)

Ensuite, il faut instancier un container parent et l’utiliser partout dans l’application.

Dans le JS des applications Windows 8/Phone il suffit d’instancier le container (dossier) parent :

MyApp.Data.container = new WinJSContrib.DataContainer.WinRTFilesContainer(undefined, { logger: WinJSContrib.Logger });

Et changer WinRTFilesContainer par notre choix (CordovaDatabaseContainer par exemple) pour l’application cordova en faisant attention de ne l’appeler qu’après l’enclenchement de l’évènement deviceready.

Et c’est tout, la magie s’opère à l’intérieur de notre librairie 🙂

Quelques exemples d’utilisation :

  • Pour lire un fichier :
  • Data.container.read("objKey").then(function (data) { }, function (error) { });
  • Supprimer un fichier :
  • Data.container.remove("objKey").then(function () { }, function (error) { });
  • Enregistrer un fichier :
  • Data.container.save("objKey",obj).then(function () { }, function (error) { });
  • Accès à un container enfant (sous dossier) avec la lecture d’un fichier fichier :
  • Data.container.child(folderid).read("subObjKey").then( function (subObjInFolderID) { }, function (error) { }));
  • Liste des fichiers dans un container :
  • Data.container.list().then(function (res) {}, function (error) { });

Auditing your Windows Javascript UWP application in production

Since the launch of Windows 8, I’m writing native Windows applications using HTML and JavaScript, for the Windows store and for enterprise applications. Believe it or not but I’m doing it full time and, so far, I’m really enjoying it. I know many people will disagree, especially in the Windows ecosystem, but I’m really enjoying the productivity and the expressiveness you get by writing rich client applications using HTML. And the beauty with Windows 8, and now Windows 10, is that you have full access in JavaScript to the Windows API, from rich file access, to sensors, Cortana integration, notifications, etc.

Even better, with Windows 10 and the Universal Windows Platform (or UWP) you could write one single application using HTML and JavaScript that will run on Windows desktop, laptop, tablet, phone, IoT devices, Xbox, Hololens and probably much more.

If you are familiar with the web ecosystem, you could also very easily reuse most or all of your skills and application code and use it to build awesome websites, or target other devices, with Github electron to make a Mac OsX version, or use Cordova or React native to reach iOS or Android. It really is an exciting time for web developpers.

As exciting as those experiences have been, there are a few things that are still frustrating. No matter what technology you use for development, one of them is the ability to detect and troubleshoot problems when your application have been released into the wild. Visual Studio is really great and provide many tools to help debug and audit your app on your dev box, but for troubleshooting applications in production, you’re naked in the dark.

Luckily when using web technologies, you could use some wonderful tools like Vorlon.js. This tool is really great because you could target any device, without any prerequisite. You have nothing to install on the client to have great diagnostics from your app.
I previously explained how to use Vorlon.js in production, and how to use it with your JavaScript UWP, follow those post if you want to setup the stage. In this post, we will see an overview of what you can achieve with Vorlon.js for a Windows UWP app in production, and a few guidance. What we will see is not specific to a JavaScript UWP. You could use the same things to debug a Webview in a C# or C++ application.

Inspect the DOM

Vorlon.js is designed from the ground with extensibility in mind. It features many plugins, and you could really easily write your own (we will talk more on that later). One of the most usefull for frontend applications is the DOM explorer. It’s very much like the tools you will find in the developper tools of your favorite browser.
For troubleshooting issues in production, it is very interesting to see what appened into the DOM, what styles are applyed, check the current size of the user screen, etc.



Watch the console

Another core plugin of Vorlon is the console. It will shows all console entries in your dashboard. If you put meaningful console logging into your app, this plugin is insanely usefull because you see in (almost) realtime what the user is doing, which is key to reproduce the issue. With some luck (and coding best practices), you could also have errors popping directly in the console with the stack trace (if the Promise god is with you). The console also feature an « immediate window » where you could issue simple JavaScript commands.


Check objects value

You could also have access to global JavaScript variables using Object explorer. This plugin allow you to watch values from your objects, and explore graph of objects. It’s always interesting to be able to keep an eye on your application state when trying to troubleshoot your application.


Monitoring CPU, memory, disk, …

You sometimes have to face more insidious bugs, like memory leaks, that usually requires advanced debugging tools. In the comfort of your dev box, you could use IDEs like Visual Studio to diagnose those bugs with specific tools. Modern browsers usually have similar tools, but does not have APIs to check things like memory or CPU that you could use remotely. Fortunately, when you are targeting Windows UWP, you could have access to all modern Windows APIs, and especially those about diagnostics.

That’s why the Vorlon team implemented a plugin specific to Windows UWP. It uses WinRT APIs for diagnostics and for different metadata from the client. For now, this plugin is not released, and you will have to look at the dev branch to try it out.


From the application metadata, you will get infos, such as its name, but also the application version, current language, and device family.


You will also have a glimpse at the network kind and status, and the battery level of the device.

It enables you to monitor the CPU, the memory and disk I/O. It’s especially usefull to track memory leaks, or excessive resources consumption.


And much more…

You have many more plugins within Vorlon that will help you diagnose your app, monitor xhr calls, explore resources like localstorage, check for accessibility and best practices, and so on. We cannot cover them all in one post, but I hope you get a decent idea of the many possibilities it is unlocking to help you improve your applications, both during development and more than anything, in your production environment. It’s especially usefull for mobile applications such as Windows UWP.

Writing plugin for Vorlon.js is really easy. You have to implement one javascript class for the client, and one other for displaying results in the dashboard. Writing a simple plugin can sometimes helps you save a lot of time because it can helps you analyse the problem when and where they occur. If you are proud of your plugin, submit it back to Vorlon.js !

Using Vorlon.js in production

Vorlon.js is a great debugging and auditing tool. It is designed to help you with any web technology. It works great for a website, an application with Apache Cordova or with Windows UWP applications, or even now with Node.js and Office addin (as the time of this writing, Office addin support is in dev branch).

It is great during development because you have one common tool to address many different devices, but that’s not the only way to use it.

Have you ever had a mobile website that shows problems on some device that you don’t have at hand ? or users reporting strange behavior and you cannot access it ? Vorlon can really help you diagnose problems in production, having access to console, objects, and so. But in production, you might have to integrate it in a slightly different way. In production, you probably don’t want to have it active by default to save performances, battery, network and other resources.

Fortunately, Vorlon.js comes with a small helper that will help you to turn it on, on demand. The idea is to embed a very tiny client in your application, and provide a way to your user to activate Vorlon. It could be a button in your about page, an easter egg of some sort (why not using the Konami code ?), or whatever way you would like.

Adding production client library

Let’s see how to do it. If you run Vorlon locally with default options, you have it running on « http://localhost:1337 ». The client script is available at « http://localhost:1337/vorlon.production.js ». Add a script tag pointing to it in your application like this :

<script src="http://localhost:1337/vorlon.production.js"></script>

Add it first in the head of your page, and immediately after, create an instance of Vorlon.Production :

<script type="text/javascript">
if (VORLON && VORLON.Production){
    var vorlonProd = new VORLON.Production("http://localhost:1337", "mysessionid");

By default, this code will not do anything, and it will have no impact on your app. It just allows you to turn Vorlon on when you will need it. As you probably noticed, you specify the URI for your Vorlon server, and the session id you want to use.

Turning Vorlon.js on

Now you could use your instance of Vorlon.Production to activate it with a simple function call.


The call to activate will add the vorlon client script to your page. It also adds a flag in sessionStorage. It means that Vorlon will still be active for the lifetime of your browser if your user navigate from page to page (or the lifetime of your app if you use Cordova or Windows UWP).

Sometimes you may want to force your page to reload when activating Vorlon, especially when you are auditing a single page application. To do that, just add true to your call to activate.


Persisting Vorlon activation

Some bugs die hard. You may want to persist Vorlon activation and deactivate it explicitely. To do so, you must create your Vorlon.Production with an additional argument :

<script type="text/javascript">
if (VORLON && VORLON.Production){
    var vorlonProd = new VORLON.Production("http://localhost:1337", "mysessionid",true);

With that argument, activation token will persist using localStorage instead of sessionStorage. It means Vorlon will be active until you explicitely turn it off. You could do it by calling « vorlonProd.deactivate() ».

We really hope you are enjoying Vorlon.js. Feel free to get in touch through the GitHub page.

If you run Vorlon, you could try the production helper in the sample page.

Using Vorlon.js with your Windows 10 JavaScript UWP

Vorlon.js is a great tool for diagnosing and auditing any application built with web technologies, and Windows JavaScript applications, or UWP are no exception. It means you could use Vorlon to diagnose your app running on PC, tablet, phone, Xbox, Hololens, Raspberry Pi and any device supporting Windows IoT.

However, for being able to use Vorlon.js in a UWP, you will have to configure your application sandbox to enable communication between your app and Vorlon.js server (or desktop app).

In this post, we will illustrate the different aspects for a packaged application (a JavaScript application that embeds pages, scripts, styles, …) because it is the most complicated, but what we will see here will work equally well for a hosted app (an app where pages, scripts and styles are hosted on a web server). In fact, what we will see here could also help you using Vorlon.js in a webview for a C# application.

Put your application in web context

This step is very specific to packaged applications. Packaged applications runs in a very specific security context where resources can only be loaded from inside your package. It means that you cannot use a script tag which « src » attribute points to a resource outside of your package.

For using Vorlon, you will have to force your app into a web context, allowing you to use alien resources. Be aware that doing this is a weakpoint in your app’s sandbox. It’s not a major one but do it only if you have the need to.

Putting your app in web context is very easy. You just need to update a couple entries in the manifest of your application.

First, you must change your start page. If your start page is named « default.html », replace it with « ms-appx-web:///default.html ». You could do it by editing the appxmanifest.xml, or by opening your manifest within Visual Studio.


In application context, you have access to WinRT API, but not in web context. To bring it back; you must add your start page to Content URIs. Again, you could do it manually in your manifest or with Visual Studio. Go to the content URIs tab and add a URI to « ms-appx-web:///default.html ». Don’t forget to enable WinRT by choosing « All » in « WinRT Access ».


Allow your Vorlon.js client script

Now we must allow our app to access Vorlon.js client script. This step is required for packaged and hosted JavaScript UWP, or if you want to use Vorlon in a webview in a C# app.

First you must take note of your Vorlon.js server URI, and add it to the content URIs for your app. I will use a local Vorlon instance running on localhost on port 1337.

Open your manifest with Visual Studio and go to the Content URIs tab. Add Vorlon server URI to the list. In my case, I must add « http://localhost:1337 &raquo;.


Enjoy !

You are ready to go, just start your Vorlon server and your app. If you have followed the steps above, you are now able to inspect your app. The screen capture bellow shows the WinRT API with object explorer !


If it’s not working properly, look for messages in the console in Visual Studio. You probably have misspelled some URI and errors should show up there.

Happy Vorlon.js 🙂


How to use Vorlon.js desktop

Vorlon.js is now available as a desktop version for Windows and Mac OSX. You could dowload them on Vorlon.js website and get started using Vorlon in a few seconds.

If you want to know more about Vorlon, check out this getting started video. There are also some great articles about using Vorlon.js. In this post, we will focus on the desktop version and its UI.

Vorlon desktop helps you use Vorlon to debug your website without setup  pre-requisites, and help you start and configure your environment very easily.


On the left side, you have a menu bar.


It gives you access to Vorlon’s logs, settings, and the about page with usefull info and links.

The default settings will probably fit your needs, but you could change it with the dedicated screen. It might be usefull, especially if you need to change ports (if you want to run it side by side with the server version of Vorlon for example).


To start debugging your website using Vorlon.js, just add this script to your website or application (it’s so usefull for cordova applications !):

<script src="http://MCNTAB011:1337/vorlon.js"></script>

Vorlon has a session mecanism to differenciate client web sites and applications. If you want to define a session, you just have to specify it in the url like this :

<script src="http://MCNTAB011:1337/vorlon.js/mysession"></script>

When using the desktop application, it’s likely that you will stick to the home screen. From there, you could see if Vorlon server is running, and start or stop it easily (Vorlon server will start automatically when you launch the application).

vorlon status

The desktop version also helps you manage your sessions, and configure Vorlon plugins for each session. The home page displays the list of connected and configured sessions. You could add and configure a session even if no client is connected.


The green dot indicate that the session is in use. The empty dot means that there is no client connected.

session options.PNG

For each session, you could see the number of connected clients, and open the Dashboard for that session.


The last button helps you configure your session. You could choose if the client must receive socket.io (if your website already use socket.io, turning this off may helps), and turn each plugin on or off.

session config.PNG

We really hope you will enjoy the desktop version. It’s a great way to get started using Vorlon.js. We welcome any feedback so feel free to join us on github to log your feedback or any issue you may have.


Bringing Vorlon.js to the desktop

Setting up Vorlon.js is really simple. You just have to clone the github repository and run 2 simple shell commands :
npm install
npm start
If you are familiar with git and node.js it really is a very easy and usual way to setup a web tool. If it sounds like a foreign language to you, I sincerely invite you to dig a little to become familiar with this. But…
When you look away from the blog posts writers, you will find out that many developpers don’t know about git and node.js. Some call them « dark matter developpers ». For those people, « npm install » may feel scary, and will begin by an internet search with something like « what is npm ». As a contributor to Vorlon.js I really feel concerned about user adopting and trying Vorlon for their every day « web debugging in hostile environment », not just the up-to-date developpers.
What if we could simply wrap Vorlon into an executable ? just download, and run the executable and you’re good to go. Well, we have done it, and it’s cross platform. The Windows and Mac OSX are available right now on Vorlon.js website. The linux version is missing for now. To be honest it’s just because I don’t have a linux machine at hand, and could not find time for setting up a VM. If you are volunteering for building the linux version, please get in touch !

Making a cross platform desktop app with web technologies

Vorlon.js is written with Node.js, and rewriting it with another technology would have been unwise, and a pain to maintain. In the web world you have some tools to make desktop apps. The more advanced projects are NW.js (aka node webkit) and electron (aka atom shell). Both tools works by combining Chromium (Google Chrome open source engine) and node.js. Those tools have subtle differences I won’t detail here.

For Vorlon we choose electron because it’s more oriented on the node.js part, but nw.js would probably have been great.

Making this desktop version has been easier than I previously thought, and it was really fun. The hardest part was about learning more on node.js to spawn Vorlon.js server process. The rest was just a thin ui layer on top of configuration and displaying active sessions. We intentionnally choose to keep the session dashboard as it is in the web version.

How to build the desktop version

If you want to see for yourself how easy it is, you could get to the github repository and grab the sources. Sources for the application is in the « desktop » folder. You will have to run « npm install » in the root folder to build Vorlon server. After that, you must install the modules for the desktop application. We do not initialize them with other parts of Vorlon because electron is a little fat and will take some time to download. Go to the « desktop » folder and run « npm install » and « npm start » in that folder. You should now see the desktop app running.
All the vorlon team is really proud of this new addition, and we hope it will make it easier for you to try Vorlon and debug your web sites and applications. If you have troubles or any suggestion, feel free to log it on github.

Resolving WinJS webcomponents attributes

Now that you know how to use WinJS as webcomponents, and how to declare your controls, we will talk about the mecanism for resolving attribute values.

Lets work with an example :

<win-listview id="recentItemsList" member 

You could think of attribute resolution as

[what to do]:[where to look]:[string token]

If you look at the « itemdatasource » attribute, you could read it like this : get the « recentItemsPromise » property from parent control, and wrap it in a WinJS.Binding.List for the ListView.

In this example, « recentItemsPromise » is just a string, and « ctrl » and « list » are operators. The list operator is smart enougth to see that it received a promise, and await it to set value.

Operators are just functions referenced in the namespace WinJSContrib.Utils.ValueParsers. You could provide your own operators by adding them to this namespace.

When the attribute is resolved, you will endup with something equivalent to :

list(domelement, ctrl(domelement, "recentItemsPromise"));

As you can see, their is no complex parsing involved, it is very efficient, and enforce composition. You have no limit at the number of operators you can chain like this.

You could find the list and details about built-in operators in the API documentation.

registering your WinJS webcomponents

In the last episode, we had a glimpse of using WinJS controls with webcomponents syntax, thanks to WinJS Contrib. Let’s dig a little deeper and see how you could use your own controls with it.

On platforms with non native implementation of webcomponents, the WinJS Contrib module is attaching an observer on each page controls (and releasing it on when disposing the page). This observer uses MutationObserver to track changes in the DOM and automatically build the WinJS controls that you registered. It means that controls, not on a page (like controls in default.html) are not instantiated. In such case, you must call « WinJSContrib.UI.WebComponents.inspect(element) » just like you would have to call WinJS.UI.processAll with vanilla WinJS.

Registering a control is just about providing the name of the DOM element, and how to map DOM attributes to your control implementation. If you don’t want to use DOM element attribute, you could still use data-win-options, or use both.

Declaring a control is quite easy. If you look in « winjscontrib.ui.webcomponents.js », you will find the declarations for WinJS controls. Lets look at the declaration for the DatePicker :

	WinJSContrib.UI.WebComponents.register('win-datepicker', WinJS.UI.DatePicker, {
		properties: ['calendar', 'datePattern', 'disabled', 'maxYear', 'minYear', 
				'monthPattern', 'yearPattern', 'onchange', 'current'],
		events : ['change']

You must call WinJSContrib.UI.WebComponents.register to wrap your control. You must at least provide the name of the DOM element, and the constructor for your control. The third argument is an object containing the mapping for your control. Within this object, the items in « properties » indicate the name of the properties that you want to map as attribute on the element, and « events » indicate the name of the events you want to map.

« properties » and « events » are shortcuts to build a mapping. You could provide a raw map if you have to do fancy stuf. Lets imagine that the calendar attribute used on DOM element must map to something like _calendarBuilder.calendar in your control. In such case you could use :

	WinJSContrib.UI.WebComponents.register('win-datepicker', WinJS.UI.DatePicker, {
		properties: ['datePattern', 'disabled', 'maxYear', 'minYear', 
				'monthPattern', 'yearPattern', 'onchange', 'current'],
		events : ['change'],
		map: {
			"CALENDAR" : {
				attribute : "calendar",
				property : "_calendarBuilder.calendar",
				type : "property",
				resolve : true
			"CHANGE" : {
				attribute : "change",
				property : "_calendarBuilder.changeevent",
				type : "event",
				resolve : true

This syntax is more verbose but you have total control over the mapping. Note that the mapping key should be uppercase.

Another scenario that may come in mind is how do I map a fragment/page to a webcomponent ?

This is a lesser known feature of WinJS but WinJS.UI.Pages.define actually returns the constructor for the page, with the exact constructor signature of common WinJS controls (first parameters provides containing DOM element, and second parameter for control options).

To map a page/fragment to a component, you just have to pass the constructor. If you look at the searchbar control in the sample application, you will find an example that looks like this :

var SearchBarCtor = WinJS.UI.Pages.define("/controls/searchbar/searchbar.html", {
	//control implementation not mentionned here for brievity

//for use as standard control with data-win-control
WinJS.Namespace.define('Flickity.UI', { SearchBar: SearchBarCtor });

if (WinJSContrib.UI.WebComponents) {
   	WinJSContrib.UI.WebComponents.register('flickity-searchbar', SearchBarCtor);

The last use case we will cover now is for controls containing controls. Sometimes you write a control that wraps one or more other controls. You can map those controls directly to DOM attributes by using their own registration. WinJS Contrib has a control that wrap a SemanticZoom and the two associated ListView for managing list with groupings. The declaration for this control use that pattern :

WinJSContrib.UI.WebComponents.register('mcn-semanticlistviews', WinJSContrib.UI.SemanticListViews, {
	properties: [],
	controls: {
		"listview": WinJS.UI.ListView,
		"zoomedOutListview": WinJS.UI.ListView,
		"semanticZoom": WinJS.UI.SemanticZoom
	map: {
		"DEFAULTGROUPLIMIT": { attribute: 'defaultGroupLimit', property: '_dataManager.defaultGroupLimit', resolve: true },
		"GROUPKIND": { attribute: 'groupKind', property: '_dataManager.groupKind', resolve: true },
		"FIELD": { attribute: 'field', property: '_dataManager.field', resolve: true },
		"ITEMS": { attribute: 'items', property: '_dataManager.items', resolve: true },

The mapping can also have a « controls » section, which is used as a map. The key is the prefix for the control, and the value is the constructor for the control. When you register a control, the webcomponents module is creating a mapping and attach it to the constructor. That’s why you have nothing more to pass to map child control. However, the controls you are using as child map should have been declared before declaring this one.

The control can then be declared like this :

<mcn-semanticlistviews id="semanticzoom"

Next time we will have a look at the resolution of properties and detail the various options you have.

Using WinJS controls as webcomponents

WinJS Contrib goal is to makes WinJS development faster, and simplify common tasks. Last time we saw that WinJS contrib enables using JavaScript classes to define your pages, enabling ECMAScript 6 or Typescript in your applications.

This time we will talk about something that could radically change the way you write your pages. As stated previously, WinJS Contrib override core page control. This new control has the benefit of providing an extensible page lifecycle.

The code snippets in this post are coming from the sample applications we built to illustrate WinJS Contrib features. The first is from a vanilla WinJS application, and the other is from the exact same application with WinJS Contrib and webcomponents.

With vanilla WinJS, you declare controls like this:

<div id="recentItemsList" 
        itemTemplate : select('#pictureItem') 

The control model in WinJS is very effective but this syntax for declaring controls is a bit ugly. It’s verbose, and the parsing of options does not allow extensions. In all WinJS samples, the list is bound to data in the options using a static variable. Believe me, it is really a bad practice. In some templates, you will find the data bound with syntax like this « select(‘.pagecontrol’).winControl.myData ». Despite the fact that this syntax is also ugly, in any real world application, you have to link some of your controls property to something coming from a promise. It can be http call, data stored in files, local database, etc. You end up writing code for wiring data and controls.

enter webcomponents !

WebComponents is a new paradigm, currently under discussion by W3C, to declare components as custom DOM elements. You can get details on this by looking at webcomponents.org. As the time of this writing, Webcomponents have native implementation in Blink (engine used in Chrome and Opera) and partial support in Firefox. No support in IE or Spartan yet.

Webcomponents is really a very promising spec, and almost all modern front-end framework uses this syntax. Unfortunately, WinJS does not…

WinJS Contrib has a new module, that enables using controls with a webcomponents syntax like this :

<win-listview id="recentItemsList" member 

Using this also allow many improvements on the syntax. As you can see, some of the code that resides in the controller with vanilla WinJS now moved to the declaration of the control. The resolution of control properties can be extended and use the same mecanism we described previously for providing arguments to other WinJS Contrib helpers.

We will deep dive into this mecanism in another post, but to give you a sneek peak, this mecanism use operators to resolve the property. If we look at the « itemdatasource », the string « list:ctrl:recentItemsPromise » could be read as : get the recentItemsPromise property from the containing control, and wrap the result in a WinJS.Binding.List datasource. WinJS Contrib has several operators and you could add your own.

To use webcomponents in your application, you just have to include « winjscontrib.core.js » and « winjscontrib.ui.webcomponents.js ». The module is defining the components for most WinJS controls. It maps control’s properties as attributes on the DOM element. We haven’t tested them all with this new syntax. We would be pleased to get any feedback from you if you encounter troubles with it, or if we missed some properties.

This module use core webcomponents on platform supporting it, and a polyfill for the others. The polyfill uses « MutationObserver ». It means it will work on IE11 and above, so you can use it in your Windows 8.1 and Windows Phone 8.1 applications, and obviously on Windows 10. We haven’t fully tested on Android and iOS yet but it’s the next step, because we use WinJS in many cross platform applications.

In the next posts, we will detail the resolution of properties, and the way you could declare your controls to use webcomponents syntax. In the meantime, go check the sample application, and feel free to send us feedback.

WinJS and ES6

It’s time for a new episode about WinJS and WinJS Contrib ! this time we will talk about using ECMAScript 6 with WinJS and more specifically about using JavaScript classes.

With WinJS pages, you use object literal to define your pages, something like :

WinJS.UI.Pages.define('/pages/home/home.html', {    
    processed: function(element, option){ 
    ready : function(element, options){

WinJS will build a constructor for the page and add the content of the object literal as a mixin on that constructor. When the page is invoked, the constructor is used to produce a new object that hold those methods on its prototype. What is great is that you could call WinJS.UI.Pages.define multiple time on the same page, using some external mixin. This model is very interesting because you could work in the best possible way for a developper : composition.

This programming model has no limit in terms of what you can do, however it has some drawbacks. First, a lot of developpers are not JavaScript gurus. Using OO languages along with JavaScript, they are not familiar or comfortable with the concept of mixins and this syntax looks like some esotheric thing. It’s also a different programming model than the business logic where you may enforce something more « object oriented ». I know « object oriented » is not in the « pure » JavaScript paradigm, but that’s where JavaScript is going with things like ES6 classes.

The other problem with this syntax is about the tooling. More often than not, intellisense goes nuts and does not provide you any help about a variable you created in another function, 5 lines of code above.

Last but not least, the object literal makes things like ECMAScript 6 classes, or Typescript a hell to work with WinJS. This is really odd because : 1 – Typescript is from Microsoft and it does not fit well with their own UI/front-end framework, and 2 – if you play with Windows 10 preview and dev tools, you may have noticed that, if you create an universal app in JavaScript, you can use ES6 in your application. It has not been officially announced yet but it looks like Windows 10 UAP in HTML and JavaScript uses some form of EdgeHTML (the Spartan engine). It means that you can use all the ES6/HTML/CSS goodness that comes along with it, as well as the performance benefits.

So, how could you use JavaScript / ES6 / Typescript classes with WinJS ? in fact it is quite simple. Last time we looked at the basic features of WinJS Contrib, and more specifically the fact that WinJS Contrib override WinJS page control. Once you put WinJS Contrib, you could call WinJS.UI.Pages.define with a constructor instead of an object literal.

class HomePage{
    ready(element, options){
WinJS.UI.Pages.define('/pages/home/home.html', HomePage);

If you start playing with ES6 or Typescript, you may also use some of the other ES6 features. One that could help you improve readability and reduce code is arrow functions. Arrow functions are anonymous function with a syntax identical to lambdas in C#. In addition to syntactic sugar, the arrow functions does not change scope. If you use arrow function instead of functions, the « this » scope is preserved, and you avoid writing tons of ugly code like « that = this ».

To demonstrate those features, we made an ES6 version of the demo application using JavaScript classes. This version is still a Windows 8 version transpiled using Babel, but if you want to have a lot a fun, you could bring it to a Windows 10 UAP (it’s just copying files) and drop Babel, it will work just fine and it is a wonderful playground to experiment with new features of HTML/Javascript in the new rendering engine in Windows 10.

If you want a more direct look, you could check the « searchbar » control that we used to illustrate WinJS Contrib basics on the previous post.