Aurelia and JSPM – A match made in heaven

JSPM is awesome. To show how amazingly easy it is here is the worlds’ shortest tutorial –

Starter code

Grab the aurelia/skeleton-navigation repo.

git clone https://github.com/aurelia/skeleton-navigation.git

Install the dependencies listed there (npm install -g gulp, npm install -g jspm, npm install, then jspm install)

Now our base app is functional.

Add a new dependency from NPM

For this example let’s choose everyone’s favorite formatter – `markdown` – from npm –

jspm install npm:markdown

Use it

In the welcome.js view model add this import at the top –

import markdown from 'markdown'

And use the tool –

console.log(markdown.toHTML(''));

That’s it!

Few notes on JSPM install –

jspm install npm:markdown <~ tells jspm to install the package from npm named markdown. This allows us to import from markdown; without having to specify the exact path when using JSPM’s partner in crime, system.js.

Best Parts of Aurelia Part 1 – Composing custom elements / templates

In a renewal of a previous set of posts that I did around Durandal.js, I wanted to start a new series on Aurelia, the successor to Durandal.js and Caliburn.Micro.  Aurelia is an awesome collection of libraries that make up an amazing framework that is focused on future specs of the JavaScript language while still supporting a large set of current browsers.

Code

For this quick highlight of the features we will use this repo, which is a basic layout out with multiple columns which contain some widgets –

https://github.com/PWKad/aurelia-layout

It is a basic fork of the Aurelia skeleton-navigation. For any questions please visit the official gitter –

https://gitter.im/Aurelia/Discuss

Composing templates and custom elements

What’s the difference between using the compose element vs a custom elements? In what situations do we use each of them with Aurelia? How does it fit into the web components spec?

Compose:

  1. Can be used to dynamically compose templates (not forced to define the template type)
  2. Can use same view model but different view for each item in an array
  3. You can separate your views and view models into the smallest bits of (re-usable) code needed.

Imagine you want to create between 1 and 3 number of columns that are in charge of their own visibility and data-binding.  Easy.  Using the compose element with a repeat.for binding.

<compose view-model="./column" model.bind="column" repeat.for="column of selectedColumns.columns"></compose>

In this case we are using the compose element to bind to a template where we can provide our own view-model, view, or model. Let’s dissect what we did above –

Set the view-model to ./column to let the compose custom element know that A view-model can be found in this same folder “./” named column.js “column”. The compose custom element will then look for a corresponding view to bind to, and locates in the same folder or by convention if we have one set.

What’s really cool is we could have bound the view-model to a property so if we were iterating over an array of columns in our parent view-model we could have set a different view-model / view pair based on some condition, such as ‘columns/green’ to indicate a column in good standing vs ‘columns/red’ to represent one in bad standing.

We bind the model to the column, which in this context is set to a column we defined in our repeat.for binding.

This means in the parent view-model (such as layout.js) we need to define a property called columns which is an array, such as –


export class Welcome{
	constructor(){
		this.columns = [{ name: 'column1' }, { name: 'column2' }];
	}
}

Custom element:

A custom element is basically a web component. It uses the future spec to create a view-model / view pair that is highly re-usable and componentized.

Now we need to create a column view template in the same folder. Let’s create a new .html file and wrap the .html in a template tag that let’s Aurelia know this is a template that we want to re-use.



  <div class="column">${column.name} if you lower-case it is ${column.lcName}.</div>


Next we create a view-model to pair up to it to allow handling any of this particular columns’ properties or methods. In this example we create an ES6 module but in our skeleton-navigation app Aurelia can convert this to your favorite module format (AMD, CommonJs, etc…)


export class Column {
  constructor () {
    this.column = { name: '', lcName: '' };
  }

  activate(col) {
    this.column.name = col.name;
    this.column.lcName = col.name.toLowerCase();
  }
}

Here we are defining an activate callback that the module loader will call when first activating the view-model and pass the column we bound the model to before in the parent. This was the compose binding before where we used model.bind in our view.

How does it work together?

In the case above the view model column.js and view column.html make up a custom element. We used the compose custom element to instantiate an instance of it to dynamically render it in the DOM.

What else could we do instead?

We could import it directly in the DOM –

  <import from='./column'></import>

And then use it as a custom element there directly –

<column model.bind="column"></column>

The difference here is we are forced to use the column view-model and view pair.

Wrap-up

What we went over –

1. Compose’ing custom elements allow a very dynamic way to create partials that truly separate out our code in to functional areas.

2. Custom elements are web components that need to be imported or composed to use.

3. The templating engine for Aurelia is truly amazing and built for the future, but designed for use now.

SASS and SCSS in Visual Studio 2013 with Web Essentials – starring Compass and Susy

SCSS and Visual Studio 2013 with Web Essentials – Starring Compass and Susy

Intro

Since going to Build and seeing Mads Kristensen talk about the upcoming additions to Visual Studio 2013 with Update 2 and specifically what is new in Web Essentials I have been playing around with some of the new features.  A lot of these features are not yet well documented with how-to’s because they are so new so I wanted to blog about how easy it was to integrate SCSS into a VS2013 project.

In this post I am going to touch on using Compass and Susy to create our own styles in Visual Studio 2013.  I

Requirements

Resources

Lazy dev’s resources

The fun part

Let me start by saying that before starting this work I had no previous experience with Compass nor Susy, I do not have Ruby installed on my Windows machines, and I had almost no problems along the way with this set-up.  I received the SCSS and SASS Compass files from a designer and wanted to be able to take over their compilation and make sure that I could edit and maintain them as needed.  I would recommend having a build of Compass and Susy in SASS / SCSS file type already if possible, if not follow the instructions on their website to obtain it.  If you want to grab the built source check out the Github link for Compass and grab everything in that folder.

My first step was to bring all of the SCSS into my project.  The files that I brought in also contained SASS from a designer that needed to be converted but I will detail that more below.  I created a default ASP.NET MVC 5 project that the styles could be applied to for something like a style guide later.  Once I dragged and dropped all of the relevant files over we should be ready to rock.

Convert all SASS to SCSS

You may not need to do this, but if your project contains any SASS we need to convert it to SCSS file type.  The reason is that the SASS files do not appear to compile in Visual Studio without using any other plug-ins.  Also the SCSS syntax / format should be more familiar for most developers who are familiar with CSS and using brackets { } and semi-colons ;.  The SASS syntax follows the HAML indentation-style format which if you aren’t familiar with like me looks like Ruby.

I converted all of the SASS files very easily using the SASS to SCSS Converter website which is 100% free and extremely easy to use.  Simply copy the SASS into the left pane and proper SCSS is output on the right.  It can’t be any easier unless Web Essentials supported SASS to SCSS conversion, which it currently does not, but I am working on a plug-in for now to do it for you without leaving VS2013.

Fix all of the references

By default all the Compass files are happy with @importing their dependencies based on the namespace compass such as –

@import "compass/reset/utilities";

But we need to help Web Essentials find the dependencies using a more relative paths like this –

@import "../../reset/utilities";

The good thing is that once we start typing VS/WE will give us Intellisense to find the files without guessing.  The only thing that I noticed is that when you use Intellisense it wants us to use the fully-qualified file name (including the _ prefix and .scss format) which doesn’t follow SCSS convention.  It may work good either way but to follow convention remove the underscore and format.

NOTE : Along the way each individual SCSS Compass file will probably not compile properly.  The reason is that Compass uses Mixins and Variables that may not yet be available.  This is Ok!  We only need our main SCSS file to compile in the next step.

Let’s start using Compass!

After fixing all of the references and making sure we are only using SCSS file types we can create our own SCSS file to be the main style aggregate.  If you are incorporating Susy as well simply make sure to follow the same steps as we did with Compass above in fixing the references.  Create an application.scss in your project at the same or higher level as _compass.scss.  Simply right-click on a folder and ‘Add Item’ and search for SCSS file type.

Our project structure shouldn’t matter too much but this is what I am using for now –

  • application.scss
  • _compass.scss
  • _susy.scss
  • compass (dir)
  • susy (dir)

Using the @import directive will create a dependency on an other SCSS file, so let’s @import compass and susy

@import 'compass';
@import 'susy';

Now that Compass has provided us with a bunch of mixins and variables that we can use lets try it out.  For production we should separate our style logic into partials for good practice but for now let’s just do it right here in the application.scss  Add the following two lines to see our work in progress –

header {
  @include bleed;
}

Ok that doesn’t seem very beneficial.  What did we just do?  Susy has a mixin called bleed that can be applied and will give us some reusable margin and padding helpers to make our header bleed into columns.  Check out the mixin at susy/_padding.scss in your project to get a better understanding of what it is doing under the covers for us.

Compile it

By clicking save (or pressing Ctrl-S of course) we can save our SCSS and Voila! we should see the following output – 

header {
  margin-left: -1em;
  padding-left: 1em;
  margin-right: -1em;
  padding-right: 1em; }

This isn’t going to fix everything but it’s a good start.  Start creating some awesome stuff and feel free to link to it in the comments below

Changing the output directory and other settings

If you want to change where the CSS outputs to or change settings such as minifying the compiled CSS automatically you can do so by going to Tools/Options/Web Essentials/SASS and make your changes there.

Good luck!

Building the first SPA JavaScript game using Breeze.js and Durandal.js

So in the wild everyone is teaching you how to build a new enterprise application using single page application (SPA) architecture and libraries like Breeze.js.  I am a huge proponent of Breeze.js and what it can do for your application, but that is a different subject.  What I wanted to do now was share a project I am working on / building for a game contest that interests me.

Richard Garriott, the creator of Ultima Online, posted this challenge for developers to re-create a 1977 game called DND1 that was originally written in BASIC for a TeleType machine.  I started to try to figure it out and somewhere along the lines realized this would be fun to do in a single page application to show how powerful things like Breeze.js and Durandal.js can be for any purpose.

Check out the github here – http://github.com/PWKad/dnd-sota

Check out the working version of the game here – http://dnd.sotaexchange.com/

Let me know what you think in the comments!

Why Ember.js matters for Web Development

Over the last two years I have converted from being solely a Microsoft-stack developer into using a mix of technologies.  I no longer shy away from tech just because I might need to switch over to my Linux distro to get it fired up.  I love to try out new things if for no other reason than just to see how easy it is to use and find out more about why people are adopting it.  I have gotten to where I prefer to use Sublime Text as my editor instead of Visual Studio.  I like the ease of development that Linux offers me on my dual boot Win 8 / Ubuntu system and how powerful the terminal can be.  I still prefer Windows for my every day computing, but I can understand the other side as well.

Sometimes it seems that people on the other side hate on Microsoft technology just because they are so open source.  It makes sense sometimes when they argue that Microsoft charges for everything where open source tech is generally free, but to call C# and .NET bad compared to PHP or Python development is mis-informed, but that’s another post entirely.  I bring this up because in my quest for the perfect client-side framework I have stumbled upon something that is so open-source and community driven yet is embodying that which I feel is the perfect framework.

Of course it sounds cliche to say the new tech I am adopting and learning is the next greatest thing, but the truth is it is amazing.  Say what you want about the .NET framework and ASP.NET MVC and how much overhead is provided that is not needed, but you can’t say that it’s hard to use or slow.  The overhead that is provided is there to make the technology easy to learn and use.  It’s so easy in fact that it conventionally provides controllers, views, and mark-up for said views to basically build an app from scratch without having to write any code at all.  For the purist who loves to build everything from scratch this can be a real pain, but for new developers and for a team of developers who need to share the code base and build a product together this is invaluable.  It offers the team a convention to follow to build something great.  Why does that matter?  Because Ember.js is the new ASP.NET MVC.

Ember took a long time to build.  I don’t need to give the history (you can Google that if you wish) but the fact is the core Ember team took a long time to get things right.  The early adopters spent countless hours building Ember apps only to have huge breaking changes come.  Features were deprecated to get things right.  I admire them but I am glad it wasn’t me that had to go through this growing phase.  I had applications that I had to build and I built them in a framework that I loved.  The problem was that the community for that framework never grew out of the small niche of developers who realized the power and simplicity of it.  I plan to write another post on the topic, but the reality is if you want good quality dev’s you have to use technology that excites and draws good talent.

So why am I writing this post?  After spending three long weeks of researching Ember.js and trying to understand what problems it solves I had my aha moment – the answer was always there right in front of my face but it was so simple it was hard to comprehend.  Ember provides everything by convention.  If you don’t build controllers, it builds them for you.  Want to change the model from a single item to a collection?  No problem, just do it.  Ember is so opinionated about the future of the web it doesn’t wait for someone to tell it how to build it – it does it for them.

In a pure Ember application everything can be broken down to routes and resources, and resources and routes.  It’s so simple that the first time you see it that it is hard to fathom that a web application can be reduce to that level of simplicity.  Web Components can be delivered in many different ways.  Views can be rendered or created as partials.  Any way you spin it it’s already defined on how it should work and what Ember will do to provide it to you.

Ok, Ember.js is awesome, why should my team adopt it?

One of the biggest complaints about Single Page Application frameworks such as Angular, Backbone, Durandal, and the like are that it’s hard to scale.  It’s not hard for a developer to scale the application if they know what they are doing, but when that developer leaves the company it’s hard to scale the application to other developers.  Instead of spending the necessary time to learn the technology and scale it most developers see working code and are afraid to hack at it.  Ember provides conventions that are easy to follow and therefore it’s easy to look at another developers code and understand what it is doing.  This makes building an application that can be shared between many developers easy.  Being that Ember promotes code organization and the separation of concerns so well it is no surprise that the application is easier to break out when it grows.  The main problem that I have so far is that Ember-Data tries to tackle more than it should – which is why I hope to soon finish building out a Breeze plug-in to use with Ember and provide rich queryable data.

In a time when everyone talks about Angular just because it’s the ‘next big thing (from Google)’ it’s really refreshing to see something that is both more opinionated and easier for developers to understand.

Please feel free to leave comments on why I am wrong or how to help others may land here find bliss in Ember.js

jsBin for rapid prototyping

Until recently I was an avid user of jsFiddle.  I used jsFiddle to create and save the smallest examples of a problem or some front-end code I needed to test against.  I really think this helped me to write good re-usable code that I could always go back to and try to break or recreate an issue to see if it was that code or some other outside problem.

I started playing around with Ember.js lately and a lot of the examples and questions on StackOverflow.com reference the Ember jsBin.  I have been following @rem for a while on Twitter so I had seen the references to jsBin before but hadn’t really given it a shot.  When I started using it I realized some really neat things – 

1. Every time I needed a feature it was already there, and easy to find

2. It was embedded all over the web and working great (unlike a fiddle which was always just a link)

3. It was perfect for giving product teams a way to rapidly proto-type

At my current job we have a product team that likes to play around with styles.  They have gotten good enough with messing around with HTML to be able to mess around in Chrome to give us something to look at when building it out.  The problem is they have to screen shot it or copy – paste into an e-mail.

After playing with jsBin I decided to create a quick and dirty canvas for them to use for prototyping.  I figured it would take an hour or so to get it looking ok but there I was 10 minutes later with a non-functional but great looking snap shot of our web app.  I went to share it with our product team and realized there were a few options for sharing that were perfect for them to use – 

1. A live look at the output (that updates when changes are made to the bin)

2. An editable version for them to create screen mocks with

This was great.  This was exactly what product wanted to be able to share with customers and directly make changes to colors and such to allow them to give instant feedback.  They were able to immediately start prototyping new views and how they wanted them to look.

After sharing it the first time I immediately wanted to start a ‘fork’ of the project to try out a few extra things.  Boom, one of the first options I found was to ‘clone’ the bin.

Pro-tip to you – create your own jsBins and use them in your organization.  If nothing else it will get product off your back and give them something to play with.