Meligy’s AngularJS and Web Dev Goodies – Issue 4: ng-europe Special

Hello there,
First, allow me to welcome all the new subscribers who joined the newsletter since last issue. You can view the newsletter archive at any time on gurustop.net/newsletter. I’d also like to thank all the subscribers who have been on board for a few issues already. Please make sure to tweet about the newsletter to all your friends to get on board as well.

This time we have a bit of a theme around ng-Europe conference and recent Angular.JS 1.3 and 2.0 announcements.

A small warning though. This is a bit of a different issue. One that I get to be a bit more chatty at instead of just describing the links being shared. As always, I’d love to hear from you whether this style is better or worse. Reply to this email or mention me on twitter as @Meligy.

ng-europe

ng-europe is the European version (was held in Paris) of ng-conf 2014, the first big single-track Angular.JS conference. It took 2 days with presenters from the Angular team and community leaders. The conference is important as it’s the place where the Angular team finally explained their big plans for Angular 2.0, and a few related topics got more exposure like Angular Material Design.

Conference Notes:  Day 1  |  Day 2    (biggest announcements came out in day 2)
A wiki-style collection of notes written by conference attendees. The best place to go to for getting a summary of the conference. You can later decide which sessions you might want to watch in details.

Video: All ng-europe Videos
All the conference videos are on YouTube. Check them out. Plenty of good stuff.

ng-europe Session Slides
For times when/if you need to refer to any of the session of the session slides.

Video: ng-conf 2014 Videos & Slides
I found this while preparing the newsletter, from the same site that put the ng-europe slides together. If you are bored you can check it out. Most if not all topics are still relevant.

Angular 1.3

Angular 1.3 was announced in early October, the main focus has been speed improvement and getting some directive improvements for form manipulation. We see one-time bindings, new way to create validations and show error messages, and more. Beware though, no IE 8 support.

Official Announcement — AngularJS 1.3.0 – superluminal-nudge
The post where Angular.JS 1.3 was announced. A good summary with links to documentation for each of the new major features. There’s alway the full changelog as well.

Vide: Angular 1.3 by Jeff Cross & Brian Ford at ng-europe 2014
I thought I’d highlight this video in particular. If you have 20 minutes to spare, watch this video, a good walkthrough of the features from the team that developed them.

Angular 2.0

Angular 2.0 has been in design phase since last December, while Angular.Js 1.3 was in development as well. Since then, we knew Angular 2.0 is going to be a big change and a complete rewrite, but we didn’t know how big exactly till ng-europe.

In Angular 2.0, the team plan to use EcmaScript 6 module system to replace Angular’s own module system AND dependency injection.

They also plan to use ES 6 classes to create directives in a new way that doesn’t just replace the current directive system but also the Angular controllers. With no controller, there will be no $scope as well (they referred to $scope as “Directive Definition Object”, DDO in ng-europe).

While on it, Angular 2.0 will also get rid of jqLite in favor of using the DOM directly (since it’s designed for modern browsers, where the DOM API has evolved enough already).

RIP in AngularjsJS 2

Video: Angular 2.0 Core by Igor Minar & Tobias Bosch at ng-europe 2014
(Just highlighting the relevant ng-europe video)

The announcement of Angular 2.0 had many reactions, more negative than positive. The main issue is that Angular 2.0 as explained in ng-europe feels like an entirely different framework.

Angular 1.x (The way from 1.3 to 2.0)

The announcement of Angular 2.0 makes people very skeptical of using Angular 1.x, even with Angular 1.3 still new, having tons of great features and performance. Here are a few write ups and news that help you make an informed decision whether to use Angular 1.x or not.

New Project Lead for Angular 1.x
Igor Minar (@IgorMinar on twitter), the AngularJS team lead, has decided to assign the most active Angular.JS community member as the leader of Angular 1.x. He says that there’s a lot of work to be done in Angular 1.x and if he focuses on both releases, not much of it will happen as he’s mainly focusing on Angular 2.0. Also check Angular 1.x: The plan forward, the letter Igor wrote to the team about the change.

Angular.JS Weekly Meeting
While not specific to Angular 1.x, this seems to THE place to watch for what’s happening in the Angular 1.x space. It’s as close as we can get to what the team is thinking, at least for now.

If you watched the ng-europe videos, you might be confused about the migration path from Angular 1.x to 2.0, as it looked like there isn’t going to be any. Looking at the plans and meetings for Angular.JS team, there are a few hints that suggest things might be a bit better than expected.

For example, there is a plan to share some critical components between Angular 1.x (1.3 in fact) and 2.0. Material Design and the Angular 2.0 router are the biggest names to mention in this context. Some 3rd party libraries have similar ambition as well, like Restangular.

Screw You Angular
Although the title suggests a rant, this post is actually tries to address all the criticism AngularJS got for lack of obvious migration path from 1.x to 2.0 (I was collecting these posts for the newsletter since they had very good points, but changed my mind as the post links to them anyway).
The answer the post provides is that the team hasn’t thought about migration because Angular 2.0 doesn’t exist yet! Once v2.0 gets more shape, the team can then think what the migration path to that could look like.
Not a very bad argument, and since the author is an AngularJS insider, it’s more of a knowledge than a guess.

AtScript

It seems that even EcmaScript 6 was not enough for Angular 2.0 vision of declarative programming that the team decided to implement their own language, AtScript! Crazy, huh?

It sure it. Many reject Facebook’s JavaScript framework, ReactJS, just because it introduces a new language (extension of JavaScript, .jsx files) that mixes HTML and JavaScript and requires its own compiler to translate to JavaScript. Angular.JS did something similar except the syntax isn’t as weird.

AtScript, is an extension of TypeScript that should be able to compile to ES 6 (and then can be compiled to ES 5, the current JavaScript) or Dart (I know, I don’t care too, but BTW, most of the PoCs and early experiments of Angular 2.0 and some 1.x were in Dart). It adds some annotations that the framework will use to differentiate different kinds of directives and more…

AtScript

AtScript, Google’s new superset JavaScript runtime
A good article with highlights from the ng-europe session.

Video: Miško Hevery – Keynote on AtScript at ng-europe 2014
The video of day 2 keynote where AtScript was announced. Pretty fun to watch BTW.

Video: ES6 in Angular 2.0 by Erik Arvidsson at ng-europe 2014
This video explains how Google is planning to extend its ES 6 to ES 5 compiler so that it handles AtScript as well (from the user point of view). You get to see how the pieces of the puzzle come together.

AtScript Primer
The official AtScript design document.

If you are like me, you must have been quite surprised that Google has considered Microsoft’s TypeScript as a base for AtScript, here’s what Sir Anders Hejlsberg, the father of C# and TypeScript, thinks about that, in 140 letters or less:

More from @Meligy / GuruStop

Thanks a lot for making it that far. If you like what I brought you today, let’s connect in even more ways!

Follow me on twitter — @Meligy

Check The Newsletter Archive — https://gurustop.net/newsletter

Get friends to receive the newsletter — https://gurustop.net/newsletter/signup

Remember that you can just reply to this email or mention me on twitter to tell me what you feel needs to change in next issue. And please to tweet it to your friends too, the more people enjoying this, the more it encourages me to make it better.

Until next issue,

Meligy

Meligy’s AngularJS and Web Dev Goodies – Issue 3

Hey there,
Welcome to Issue 3 of the newsletter. If you want to check the previous editions, you can go to gurustop.net/newsletter. You can access a particular issue like, for Issue 2 you go to gurustop.net/newsletter/2.

This time I have played a bit with the schedule and the order of sections. The idea is to experience different ways and hear your feedback on what works better. either on twitter or by email (simply replying to this message).

SEO — News

Video: Google will render JavaScript by end of the year
During AngularJS NYC usrgroup for September 2014, Brad Green, a Google engineering manager working on Angular.JS among other things said that Google crawler will render all JavaScript by the end of this year, and their should be tooling for checking that in Google Webmaster Tools as well – Discuss on reddit.

Angular.JS — Libraries

bind once for Angular.JS < 1.3
A set of directives that allow you to bind values to the UI only once instead of watching for model changes to update the UI. This is particularly useful when you have a long readonly list inside ng-repeat where most properties are unlikely to change until the entire list changes (and then the whole template will be re-rendered).
The concept is now native in Angular.JS 1.3, and there are other libraries that try to enhance it, like angular-watch-require and angular-watch-when.

overmind.js
If you use require.js and want to have lazy-loaded modules with it, there are several tries out there that get that sort of thing done. If all you want though is just lazy loaded modules that are loaded and bootstrapped on the fly when a certain route tree is matched (like areas in ASP​.NET MVC Areas or Rails Namespaces). Might be good for large Angular.JS apps. It also has been mentioned on the Adventures in Angular podcast.

JavaScript — MVC Frameworks

MVC Architecture
A very nice article about how we don’t exactly implement MVC as 3 parts, Model, View, and Controller. We usually had other parts too. I think the closest way to how I implement MVC is the last picture in the article.

Why I Don’t Want Your JavaScript Framework but I Love You
If you are in the mood of reading about what homework you may want to do before you actually go ahead and use a JavaScript framework, this could be a good read.

JavaScript — Ember.JS

I have a few links for Ember.JS this time that it will feel like I’m moving to it, although I’m not, I still find its innovation very inspiring as you’ll see below.

Mistakes I Made in My First Ember Project
If you have been following the newsletter for a bit, you know I value knowing how other SPA/MVC/MV* frameworks solve the same problems that Angular.JS solves. I think this knowledge is beneficial regardless of the framework because many of the issues have equivalent in every framework, and thinking about different approaches can really help you get the most out of whatever framework you use.

Event Delegation in Ember.JS – StackOverflow
When you use ng-click inside ng-repeat in Angular.JS, it doesn’t usually set one event handler for the parent of the element and use event bubbling to set it, although you can do it yourself via a directive. It was interesting to find out randomly via StackOverflow that event bubbling is how Ember.JS works by default!

Building rich single-page application with Ember.js
Historically, one of the things that stopped many people from learning Ember.JS was how hard it was to get to understand its pieces. This is now changing a lot (or may I say changed?) with better documentation and more great guides, like this one, which was very simple and lovely to browse.

JavaScript — ES6

Traceur is Awesome! … but still a little Painful
Don’t be turned off by the title. Traceur is a nice tool from Google to compile ES6 code to ES5 code that can run in any ES5 browser (most browsers, and even older ones can be polyfilled). This post describes what the experience is like when using it (.NET people might find using TypeScript a better option for its VS integration though, although it’s not not exactly ES6, you can sometimes go even crazier with some F# mix).

JavaScript — Debugging / Performance

Video: Advanced Debugging Techniques with Chrome
A must see video of what goodies exist in Google Chrome dev tools (including some of the relatively new features like new enhancements to emulation), this is probably a must-watch video for you. I have been using the tools for years and found quite a few things I didn’t know before.

JS Parse and Execution Time
When you use a framework (quite often you should), there’s only so much you can control in terms of performance. This article examines the time it takes to parse and execute jQuery on so many browsers and devices. It has some interesting observations, like how the total times vary like crazy between different devices, and how device hardware is still the major determinator is hardware rather than software (OS or browser).

Security – HTTPS

I think we are in the (very?) early days that will lead to all websites running HTTPS by default. Apart from privacy concerns, SCARY attacks, there’s also industry leaders push and relative ease of implementation. But it’s not something that everyone needs to worry about just yet.

SSL and SEO: Don’t Panic
There are a few messages that I want to send from sharing this:
1. Google announced they will consider SSL as one of its many ranking factors
2. This doesn’t mean you should freak out if you are not using SSL (the point of the link above)
3. But SSL is worth it anyway, as in most recent hardware and software (including IIS 8 and maybe 7.5) it’s already fast (the traditional old concern about SSL, apart from cost for tiny websites).

Slides: Is TLS fast yet?
If you are thinking about implementing HTTPS and worried about CPU performance, your server documentation documentation should tell you whether there are significant performance overhead (I checked some common ones and they were all saying nothing to worry about). This presentation helps assure the same idea.

Cloudflare – Introducing Universal SSL
The well known CDN provider Cloudflare announces availability of SSL services for all their plans, including their free plan. They serve files in HTTPS, and can be configured to pull assets (as source files to publish on the CDN) from HTTPS URLs as well. Here’s a basic write up of how to use it.

Security — General

Waxing Poetic with SwiftOnSecurity
I didn’t plan to make this newsletter mostly about security as it ended up being, but this story that reminds us of how some users can be so vulnerable in a way we can’t blame them for, is quite a good read.

Microsoft — Windows 10

Video: Windows 10: Enterprise Features & Core Experience for Businesses
You must have seen a ton of Windows 10 videos already, for me, this was pretty much the deepest one of them that related to me as a developer and showed the philosophy of the product.
One fun moment in the beginning of the video was giving a reason for the name, Windows 10 (instead of Windows 9), apart from considering Windows 8.1 as 9 (if you want) which the video didn’t suggest, it said that the main idea was calling it Windows One, similar to Xbox One and One Drive, etc. Windows One was taken as Windows 1, so they went for Windows 10! (if this is silly still – I think it was meant to be more funny than true-, I promise the rest of the video isn’t).

Video: Scott Hanselman Detailed Windows 10 Tour in just 8 Minutes
Scott is very well known in the ASP​.NET developer community as his work at Microsoft is mainly around that community and ASP​.NET MVPs, etc. He is a great person and speaker. His Windows videos are not something that he does for work, which makes them even greater and more realistic.

Windows 10 Insider Program / Preview
Just in case you missed the URL to get the technical preview! I have heard a few positive comments from some of those who played with it, especially on a Surface laptop (of course).

Apple / IPhone / iOS — Quick Links

iPhone 6 Screens Demystified
Also check their iPhone resolutions guide

iOS 8, thoroughly reviewed
Very long / detailed review

Video: Steve Jobs introduces WiFi to the masses with a hula hoop!

JavaScript — Quick Links

Promises in the Google APIs JavaScript Client Library
Google’s JavaScript SDK now return promises, for easier integration into promises-all-the-things!

Bye Bye Javascript Promises!
async/await like code in JS?

rcss.js
A JavaScript library to generate responsive stylesheets.

Explorations In Automatically Fixing JavaScript Linting-errors
By Addy Osmani from Google

Calculating Standard Deviation with Array.map and Array.reduce, In JavaScript
A bit of a different challenge

More from @Meligy / GuruStop

Thanks a lot for making it that far. If you like what I brought you, let’s connect in even more ways!

Follow me on twitter — @Meligy

Check The Newsletter Archive — https://gurustop.net/newsletter

Get friends to receive the newsletter — https://gurustop.net/newsletter/signup

Remember that you can just reply to this email or mention me on twitter to tell me what you feel needs to change in next issue.

Until then,

Serializing A PagedList Using JSON.NET In ASP.NET MVC – Gotcha And Workaround

Recently I discovered that there’s no one standard way for AJAX-driven server-side paging in ASP.NET MVC (in Web API, you can expose an IQueryable). For the case in hand, I decided to use PagedList for the server bit of the game.

PagedList

The PagedList interface looks a bit like this (for demonstration only, real code is a bit different, check its source code for the real stuff):

It provides nice properties for paging, and exposes itself as enumerable and has an indexer. Apart from this snippet, the library also provides an extension method ToPagedList() to apply to any enumerable and allow it to populate the properties from it (by enumerating on it, and by calling the Count() method).

We were also using JSON.NET for JavaScript serialization, which is pretty much defacto standard nowadays.

The JSON.NET Serialization Problem

JSON.NET has a nice implementation, if you serialize a class that implements IEnumerable<T>, and you don’t have a special treatment rule for it (via what JSON.NET calls “Converter” classes), when you serialize an instance of the class to JavaScript, it will be serialized as a JavaScript array, where the enumerated objects are the contents of this array. Makes lots of sense right?

Well, yes, except when you have a custom collection like PagedList, and you want to treat it as an object that has several properties, not as an array. JSON.NET does provide a solution for this actually, all you need to do is apply the [JsonObject] attribute to your class.

Unless you don’t own the source code of this class.

In this case, you need to inherit from it. By doing this, I lose the nice ToPagedList() extention method (because it creates an object of the PagedList class directly), but luckily it does nothing but calling new PagedList() with the parameters we give it, so, we don’t lose much.

Here’s how my implementation looks like:

Apart from having to copy the constructors to pass parameters to the base ones, have you noticed the extra Items property in there?

That’s because the Subset member it includes is actually a field, not a property, and JSON.NET won’t serialize that by default, I could override it somewhere else, but since I’m fiddling with this here, it made sense to just stick a property to the class.

Bonus: A Bit More On Implementation

In my actual code, I have added the Dynamic Linq NuGet package, and assumed a single property for sorting (which was fair for the situations where I intend to use this), so, I complemented the code above with another class that looks like this:

This allows the controller to instantiate an instance of the SerializablePagedList class, pass it all the way to whatever repository method I have.

The repository method will take it as a parameter, work out what IQueryable it needs, and instead of passing it to UI, it calls CreatePagedListFromQueryable(), which returns an innocent-looking PagedList object (because SerializablePagedList inherits PagedList) that the repository can pass back to the controller, which can serialize it to JavaScript without a problem, then the rest is all JavaScript code to work out how create the paging parameters, and how to use the returned paging hints.

Even more, now that I think about it, maybe I should change the return type to SerializablePagedList, to make the Items property visible to the developer (because they’d think it’s magic, and in coding, magic is BAD). I’ll leave this as an exercise for you :)

Final Words / Disclaimer

The motivation behind this post is that I found the problem of serializing PagedList using JSON.NET a challenge and I wanted to help others work it out faster than I did. Is this how I’d recommend doing paging? Well, I don’t know, but if it’s what you choose, I hope that I have saved you some time.

And more importantly, is it good enough to be the defacto standard I mentioned I was after in the beginning of the post? Not really. I think it’s not bad, but definitely not the best. I’d love to see less clever (read: hacky), and more simpler solutions.

Manually Compressing Any ASP.NET Page, PageMethod, MVC Action, HTTPHandler,..

Compressing A Single ASP.NET Response Manually

This post is about compressing your HTTP result without using IIS Dynamic Compression. I’ll save the story to the end and give you the code first:

Well, this shows how to do the compression itself. Depending on how you do ASP.NET, you probably will call it differently.

In my case, I called it manually from an ASP.NET Webforms PageMethod (more on why below), but if you are using ASP.NET MVC for example, you probably want to wrap it in an ActionFilter and apply that to the action you want to compress its output. Let me know in the comments or on twitter if you have a problem implementing it in a particular situation.

IIS Dynamic Compression

IIS 7+ has built in dynamic compression support (compressing output of server-side scripts like ASP.NET, PHP, etc.). It’s not by default because compressing dynamic content means running the compression for every request (because it doesn’t know what the server-side script will generate for every request, the point of using server-side programming is generating dynamic content!).

Static compression on the other side (caching static files like styles and scripts) is on by default because once the static resource is compressed, the compressed version is cached and served for every future request of the same file (unless the file changes of course).

General advice: I’d say if your server side scripts expect to return large text-based content (say, large data, even after paging, etc. like large reports or whatever), always turn dynamic compression on, at least for the pages that expect to return large data sets of text.

In many cases though the majority of large files will be scripts (and possibly images) will be the larger parts though, which are often taken care of (for scripts for example) by IIS static compression or ASP.NET Bundling.

Python, Ruby, or PHP? (My Take On Answering The Question)

A friend I know has been developing desktop applications with .NET for quite long time. He wanted to improve himself even more by going out of his comfort zone learning more stuff he’s not familiar with. So, he spent some time learning client side web technologies and wanted to add some “non” .NET server technologies to the mix. He emailed me asking for recommendations on what to learn,: “Ruby, Python, or PHP ?”.

 

After sending the answer, as with other previous emails, I thought maybe I’d share it with you here.

python-logoPython

Let’s start with Python, since it’s the language I know least about (take that as a disclaimer against everything I claim about it next). Note that Python also has similar options to Ruby (maybe even earlier than Ruby had for some of them) even the MVC application frameworks (like django), but they aren’t booming as much as, say, Ruby..

Python’s real power is that it’s one of the old languages with great standard library doing networking and several pieces of functionality, in a way closer to C++ than it is to .NET or Java. I think also it’s runtime is historically has better performance and wider platform support than, Ruby.

I’d argue though that those benefits are usually less important in the web world, where you worry about web specific features (templates, personalization, AJAX support, etc…), than library features really, and only have a known set options for the platform hosting the web app/.

Ruby

Here Ruby comes to play, with similarly old-enough-to-be-mature age, more web friendly (ex: white-spaces significance is optional), and generally getting a sense of dynamic features with C#/Java familiar syntax as "option" syntax style (rarely used). The ease of catching calls to non-existent members by one handler (method_missing or something) inspired a lot of nice syntax APIs.

 

The key attraction around Ruby world is not Rails. It’s actually Ruby gem, the "package manager" inspiration for NuGet and alike.This made sharing Ruby libraries and frameworks really easy, like other scripting languages, they allow you to extend the console features as well and add commands that perform repetitive tasks and code generations and so, which is an area .NET capability is still lacking much in.

 

Another killer thing about Ruby is the integrated eco-system. People would be using Git, github, Ruby, Ruby Gem, Rails, MongoDb, SASS (for CSS), CoffeeScript (for JavaScript), Heroku (cloud hosting),… and al of them have a specific workflow (or series or workflows) that make development much easier. This is also one main area in addition to console extensions that you’ll be blown away with.

 

Obviously, most people working with Ruby use Rails, the MVC framework for it, which has its own common workflows using specific options for ORM, mails, and other common tasks. It’s the opposite of .NET where we care about multiple options, they "do" have multiple options, but they care about the awesomeness of the experience with the option they choose rather than the ability to replace this option in the future. Quite another mindset shifting.

 

I’d suggest you don’t start with Rails. Start with Sinatra instead. Sinatra is like a basic web framework that just handles routes and templated views and few other things. People loved it for its simplicity and a lot of people build proof of concept and prototype startup ideas using it, especially when things don’t involve DB, or a lot of DB work. It’ll also introduce you to the way you depend on scripting a lot to perform various tasks in development.

 

Don’t get too deep into Sinatra, once you get to the point you think you understand its pieces well, move on to the next level, Rails (next in terms of number of features built-in, not in terms of better). Build something with it, usually people choose to create To-Do list or a Blog as those are the hello-world apps in web world, right? Try to discover which gems most Rails developers use most and really teach yourself to follow the workflow most tutorials and users will suggest. Expect a lot of "you are doing it wrong" times :)

PHP

A note on PHP: The reason PHP is still strong and won’t die any time soon is the amount of awesome web apps built with it over the years. WordPress, Drupal are the obvious names, but hey, the examples are uncountable. PHP has been trying to adopt to recent trends and copy features from other languages (like everybody else do), but I think it’s just causing it to lose it’s original power, which is being a simple lightweight language.

Modern PHP developers have created their own common workflows as well and those moved beyond going MySQL-PHP to REST and MVC framework and more, but the workflow for something like Ruby feels more "natural" rather than "addition" and hence makes more sense the more you apply it in your coding practices.

Node

Another option you haven’t mentioned is NodeJS, or server-side JavaScript.A lot of people who do Ruby for long time mix bits of other languages in their workflows, like Scala and Clojure and others. So, being used to this, many Ruby guys actually turned to become NodeJS guys.

They copied the usual workflows pieces to their usage of Node, like git, and NPM (the Node equivalent of Gem or NuGet), and even equivalents of Sinatra (which is almost standard, called ExpressJS) and Rails (various options). Some mix it with CoffeeScript and DB tools (although JavaScript doesn’t have special features to create ORMs like Ruby method_missing and mixins), and it’s quite booming recently.

 

It’s also a good time to consider it since Windows support just recently became good enough to use (earlier it didn’t have NPM support for example, which is like Ruby without gem, pure key piece of the workflow missing and making the platform pretty much useless).

 

I think Node will bring you some of Ruby workflows via ExpressJS and brothers, and make you more fluent in JS (which is becoming THE universal language of the web), and blow your mind in the special way it handles creating the web app (although ExpressJS makes it more like just handling routes in ASP.NET MVC or Sinatra).

imageConclusion

So, I’d go for long term spending on Ruby then Rails (going a b it of Sinatra), or do some plain Node stuff for a while and then start learning ExpressJS. Whatever you do, keep an eye on what’s usually called "workflow" in these areas, which is like "best practices" in our own terms. Whenever you do something and it feels harder than it should, it’s likely because you are not following another piece that makes it easier for other people who do both.