The first thing that I’ve noticed while working with the framework is that the default template does not enable source maps. Source maps are files with the .js.map extension which “tell” the browser or debugger how to map the transpiled (JavaScript) code to the original script (ES6 or TypeScript). This means that if you have the correct sourcemaps, you are able to debug the code you’ve written using ES6 directly in the browser, even though in reality it is running pure javascript. This works in a similar way to how PDB files work in .NET when debugging C# or VB applications.

If you don’t have sourcemaps, then you’re making your life much harder because you’ll be looking at the generated (transpiled) javascript which sometimes is not the easiest to read (BTW I will come back to this subject a bit later).

Enabling source maps for your Aurelia project

In order to add support for these sourcemaps, you need to use the “gulp-sourcemaps” library. There are two steps to this:

Step 1 – edit the packages.json file located in the project root and under “devDependencies” add the following line:

"gulp-sourcemaps": "^1.3.0"

This will ensure that when you build the project, the node package manager (npm) will install this dependency and you will be able to use it in your build process. Which takes us to:

This change will actually “inject” the sourcemaps plugin in the build pipeline. The end result is that whenever the project gets built, it will generate one *.js.map file for each transpiled file (inside the dist folder). The second effect, as stated above is that you will be able to debug using FireBug or Chrome Developer Tools directly the ES6 source code and the browser will internally map the breakpoints and code lines to the transpiled code.

Caveats

One of the things that gets annoying relatively quick is the fact that the Aurelia framework that gets installed using the official Getting Started guide will contain only the transpiled files. Together with the extremely thin documentation available right now, you will have to do a lot of digging in the Aurelia’s github repositories to figure out how some things are working. This is unfortunately not so easy all the time, but hopefully this will get better once the project is more mature.

The only thing that I would have liked more from the framework would have been to include the ES6 source of Aurelia and to build it normally together with my code. This would generate the correct source maps and debugging would be much easier.

Another caveat comes when using source maps for debugging is that even if the browser can track the application execution and match it with the ES6 source code, there are some situations in which you need to be aware that you are actually still running Javascript. An example of such a situation is when having a breakpoint inside a ES6 lambda (arrow function) body. Since in ES6 (same is in TypeScript) lambdas will capture the outer this, it means that you can write code like this:

class A
{
constructor()
{
this.x = 1;
this.onclick = () => {
this.x += 1; // "this.x" will refer to the same member field x defined in the constructor above because lambdas capture the this from the parent scope.
}
}
}

The trick here is that the compiled code will look something like (NOTE: this is not 100% how it gets transpiled):

class A
{
constructor()
{
this.x = 1;
var _this = this;

this.onclick = function () {
_this.x += 1; // notice the use of the _this variable to capture the this from the outer scope
}
}
}

When you have the breakpoint set inside the onclick function, the developer tools (or FireBug) will show you the original code with this.x += 1. But if you add the “this” to the watch, you will notice it’s undefined or it has some unexpected value (typically it is thee value of the window object). To be able to debug correctly, you’ll need to add the “_this” to the watch. This is one very common issue that you’ll encounter while working with any transpiled language.

In the next post I will discuss some basic aspects of running the project and writing logging information using the provided framework. This should cover the minimum required to run and debug the application.

Final notes

Based on the messages that I’ve received, I’ve also checked out various TypeScript Aurelia-based frameworks. While I am a big fan of TypeScript, I am not going to switch to that for several reasons:

The type definitions are at the moment incomplete. This means that you’ll have to update them by hand which can become a rather complex task due to the early nature of the Aurelia project.

I really like the string interpolation feature from ES6. I’m looking forward to the moment TypeScript will support this.

The import mechanism for ES6 is way cleaner than the one in TypeScript. This is another point where I hope TypeScript will be adjusted because it results in much cleaner code.

Overall the language features provided by ES6 make things much cleaner and easier to write. Looking at the TypeScript roadmap, it might become really attractive if it adopts more of the ES6 standard features.

Anyway, given the above, when the TypeScript framework is good enough, the transition can be made relatively easy from ES6 to TS.

As I’ve promised, I will start documenting my experience with Aurelia. If you haven’t read my previous introduction article, click here to get an insight of what Aurelia is.

Since I’m writing this post during Sunday night, I will keep it short and just talk about tooling.

I am not the hacker-notepad-vim kind of guy and the first thing that I need when I work with any technology/framework is a good IDE. I’m a veteran user of Visual Studio + Resharper, so obviously my first choice when starting with Aurelia was to use this.

Unfortunately, VS 2013 + Resharper does not currently have any support for ES6 so it kind of stands in your way. Of course you can still use it as a text editor, but it’s even worse than using any notepad alternative since it always highlights the whole code as having errors and the formatting just messes things up (misaligned curly brackets or parenthesis, wrong spacing etc.).

After searching a bit on the internet and almost loosing all hope to have a nice IDE for this, I found out that JetBrains Webstorm IDE actually has support for ES6, so I will be using this from now on for my experiments.

Just as a hint, if you want to set Webstorm up, check out this short video on how to use Webstorm + Traceur. The default Aurelia template already transpiles ES6 to Javascript, but if you want a more integrated experience, you can configure the IDE to do it for you:

I will start this post by specifying that I’m a big fan of Durandal. If you don’t know what that is, checkout this website: http://durandaljs.com. Durandal is a single page application (SPA) framework similar to Angular (well, it’s purpose is at least similar). Anyway, I’ve been using it for the last two years for developing enterprise applications and after you get the hang of it it becomes really easy to make clean Javascript apps with a good separation of concerns (the framework is based on the Model – View – Viewmodel pattern).

If you’re into this framework, then you might know that it’s author, Rob Eisenberg has joined the Angular team at the beginning of the last year. As it seems, this collaboration didn’t come out as it was initially expected, so this year Rob has left the Angular team and has returned to developing his OSS projects.

Interestingly, he started a new SPA framework called Aurelia, that takes the best ideas from Durandal and probably his vision of where Angular should have been going to. Aurelia starts fresh without any legacy and it provides a modern perspective of what Javascript applications should look like. Aurelia is based on a lot of conventions that should make things easy to follow, but it also allows you to override these conventions and provide explicitly the rules for different things.

The first great thing about Aurelia is that it’s very modular, built out of small pieces that can be combined together or that can be replaced with your favorite alternatives. The second great thing is that it leverages the power and clarity that the EcmaScript 6 standard will bring to the Javascript language ( hopefully ) in the near future.

Although the ES6 is currently just a draft, the Aurelia project template comes with a built-in system that uses transpiling to convert ES6 code to ES5 which is compliant with most browsers by having polyfills for any unsupported feature. This means that if you start writing applications today based on it, it is very likely that when ES6 will become a standard, your app will work natively in the browsers without any change.

Nevertheless, as the minimal documentation states, Aurelia is not bound to the usage of ES6 language constructs and features, but you can use regular Javascript or if you wish Typescript or Coffeescript.

At the moment I’m just at the beginning of using this framework for a personal project of mine, but I will start a series of posts describing my experience and any hints or guidance that I think it’s relevant to developers that want to use this framework as a foundation for their apps.

Meanwhile, check out the current documentation and getting started tutorial on the products website: http://aurelia.io

A lot of people involved in web development (including myself) have hit a problem with the latest versions of jQuery. Right now there are two versions of jQuery available on NuGet – 1.9.1 and 2.0.x. According to the jQuery team, both versions will be developed in the future and for developers targeting web applications the recommended version is 1.9.1 instead of 2.0 (jQuery UI for example does not work with v2.0).

By default NuGet will install the latest version of jQuery automatically. Of course, if you use the Package Manager Console, you can force version 1.9.1. But as soon as you update and you forget to do a safe update (see my previous post here on how to do that), you are stuck with version 2.0.

To prevent such issues, an easy solution is to force the package to stay under version 2.0 by changing it in the packages.config file like this:

This is a follow-up on my previous post with a slight variation of the command. If your package source contains pre-release packages, then the previous command is not enough. The change is minor, though:

there are situations when you need to update the referenced NuGet packages and use a safe update.Safe update means that the packages are updated to the latest version that has the same major version as the current one. For example: suppose the project has a reference to “MyPackage” version 1.2.3.4. In the NuGet repository there is a MyPackage version 1.2.7.8 and one with version 2.0.0.0.

A safe update would update the package to the version 1.2.7.8, while a regular update would update it to the latest version (2.0.0.0). While the safe update can be done using the package manager UI from Visual Studio, the safe update requires using the powershell console directly.

Fortunately, there is a very easy way of updating safely all references. Open the Package Manager Console (Tools->Library Packager->Package Manager Console) and type the following command:

How many times you had to build a console application that must receive various input arguments? I know I did a lot of times – from small development tools to various applications. And every time there was a big PITA to handle the input arguments. Every time I have reinvented the wheel, every time I had to check for the arguments, parse them, output various help messages etc.

This a post that I’ve postponed for over one month now and the main reason is that I have mixed feelings about it and it’s hard to settle on something.

Just to give some context, I am a long-term .NET developer. I’ve been working with technologies such as Silverlight and WPF for the past years on a day-to-day basis so my first natural instinct has been to go for the XAML development for WinRT. I also have relative well knowledge of Javascript, but that is not a platform that I really enjoy working on at a professional level.

The Good

The good part about XAML development on WinRT is that if you come from Silverlight or WPF, you are already in touch with the technology, the framework around it and the whole development ecosystem. With no WinRT knowledge, I was able after a few hours of studying the templates that come with Visual Studio to jump directly into the problem and work my way in there.

Another good thing is that Visual Studio 2012 now comes together with Blend and this allows you to switch easily between the two and to handle both development and design-related tasks with ease.

I have to give a big plus to the fact that VS2012 comes with a set of pre-defined project templates that get you started quickly and also gives you a straight up contact with the new user experience that Windows 8 tries to push to the market.

The framework is designed in such a way that you can make your application fit with relative ease to all the differences between resolutions, sizes and orientation of the devices. Also it is very easy to access hardware functionality from the code.

Another plus is the decision of providing standard contracts for standard operations. Search, share, settings and other functionality is regulated using standard contracts so that all applications have a common look & feel that makes it natural for end users to jump into them.

I also like the fact that the applications make good use of the horizontal scrolling, which I think is a better use of the screen real estate.

Things like asynchronous API design, integrated licensing & windows store API as well as many others are really welcome features that show a more modern approach to modern application development.

There are more things to say here, but overall I thin the good things are the ones you don’t notice so much, but instead they just blend in into your day-to-day work.

The Bad

On the bad side, I have a lot of things to comment. First of which is the fact that I was really disappointed with the maturity of the framework. My initial impression was that this is a beta or a preview of the framework.

Silverlight has matured at an incredible pace and has become a mature full-featured environment. I cannot say the same for WinRT XAML.

First of all, the list of available controls is really a joke. There are standard controls which are available in the main SL/WPF toolset and you can’t find them in WinRT XAML library. I am not talking about fancy things, but basic ones such as a Date/Time picker control (or calendar for that matter), auto complete boxes.

A design decision which really makes me unhappy (and not just me) is the removal of the grid concept from the UI. While this might make sense for twitter clients or other social or multimedia oriented applications, business apps make heavy use of this usage pattern. This is because in real life there are a lot of things that need to be displayed in tables. In my case I had to work on an invoicing application. Try to design an invoice, which is by nature a list of tabular data, without using tables. I really feel that Microsoft should come back to this decision and add support for such data, otherwise they have lost by default a lot of their customer and developer base.

Another remarkably frustrating design decision is the lack of support for binding validation. While this was one of the great things about Silverlight and WPF, in WinRT XAML you have to handle validation and feedback completely manually (this is actually the reason why I wrote the previous article regarding WinRT validation).

There are a lot of small details which are missing and cause a lot of frustration. In the Silverlight world, developers have asked several years Microsoft to include an event which gets triggered when the DataContext changes. Finally they got it. Well guess what? There is no such event in WinRT XAML. While there are workarounds, this is very frustrating.

The context menu system is also implemented in a very non-developer-friendly way. The context menu is shown asynchronously, which is ok, but you don’t really have control over its positioning and size.

Finally, one of the biggest things that the framework is missing is database support. There is a library for working with SQLite, but it has the main drawback that it makes your application platform-dependent. There are also some other options such as a database engine that uses serialization for storage. This one has been a life-saver for me, although it suffers a lot of issues caused by async file system access.

In ending, the other thing that is annoying is the lack of consistency in the XAML API. While it is maybe a bit more clear than the Silverilght/WPF api, you will find a different format for specifying assembly and namespace references, as well as the format used for specifying resource paths.

Overall, I would say that the lack of controls is the most annoying one. Of course you can create your own. Of course that there are open source projects out there that provide various control libraries (I will cover a few of them in the next posts), but for someone that just wants to start doing something, this can be a big road block.

In the next post I will provide a list of links to various tools and libraries that hopefully will make your life easier when developing WinRT XAML apps.

This is the second part post related to my experience with Windows 8 and will cover the hardware part.

First of all, I do not really own a Windows 8 tablet. I have Win8 on my development as well as on my home PC and I had the opportunity of playing around with a Samsung tablet running Windows 8.

The desktop

Until now, there was 100% support for Windows 8 on both my desktops. The performance is better than Windows 7 – startup time is minimal, overall performance is good. I didn’t have any issues with drivers so far so for this I am really happy.

The tablet

I only had the tablet for a few days, during which I could play around with it. The first impression is that it’s heavy. I would have expected it to be a bit lighter, since it’s a ultra portable device. On the other hand, it has a powerful i5 CPU, which requires active cooling. Screen was 16:9, which feels a bit strange on a tablet since it’s very long but not so wide. Anyway, 16:9 is a standard today, so I cannot complain.

The overall experience of using Windows 8 on a tablet is far better than the one on the desktop. The swipe gestures feel completely natural and the interface is very very responsive. The only thing which I don’t like so much is that the keyboard takes up too much screen estate when open.

Some gestures are only supported on the tablet. For example, if you open up a photo using the Windows 8 WinRT photo viewer, on the tablet you can swipe left/right to navigate between photos. On the desktop you can’t do that.

The part that looked strange from the desktop point of view is the opening up of the top app bar vs closing an application. Actually the gestures are clear on the tablet. Slow swipe opens up the app bar, quick (throw away-like) swipe will close the app.

Overall I can say I like the feeling of the apps on the tablet. I am waiting for the prices to drop a bit to be able to exchange also my Galaxy S2 for a Windows 8 phone. I expect there to have the same natural and flowing interaction as on the tablets (maybe even more on the phone).

The ecosystem

One thing that I feel lacking is the support for other devices. Currently you can buy Windows 8 for Intel-class processors (Intel/AMD) but the support for ARM is only for hardware companies. This means that you won’t be able to install Windows 8 RT on an ARM device that doesn’t come with it out of the box.

The part where this feels necessary is hardware used for various non-entertainment appliances (think of info kiosks, embedded devices such as car navigation systems etc.). Of course Apple also lacks this, but on the other hand Android is very widespread. You can even buy a custom, USB-stick sized computer that is able to run Android. I would really like to see the same for Windows. Enabling developers to create such systems would increase the reach of the new OS to the public.

I am aware that there is Windows CE or Windows Embedded for small devices, but I also think there is a lot of potential for Windows 8 – based systems that run on cheap ARM hardware. Think of (already mentioned) info kiosks, electronic ticket counters etc. and also think about cheap hardware for universities, libraries and internet cafés, where the main activity is internet browsing, or using dedicated, simple apps.