Angular 1 is dead. Where to now?

August 7, 2016

Angular 1 has a massive market. It is by far the most widely used JavaScript framework available. It is a very opinionated framework, it has declarative power, and developers tend to lean towards the MV* patterns which has a whole lot of benefits and with which they are familiar with. So Angular itself is not going away any time soon.

The biggest problem with Angular 1 is that it is no longer being actively maintained. The main reasons for this are Componentisation, Performance and an inability to play well with search engines (SEO), which, incidently, are the main factors that have made its main competitor, React, so popular. There is also quite a significant learning curve with Angular.

Componentisation enables you to build custom component trees quite easily, and the resulting code is usually much more maintainable. Performance was always a killer in Angular 1 due to watches and the digest cycle, which was basically a system for monitoring every single changing item on your page.

There was a limit of 2000 watches, and as soon as you went over that, IE pages simply ground to a halt. Finally, having a whole lot of script on the page did not make Search Engine Optimisation easy at all. Search engines don’t know what to look at with a single page application. They find it hard to walk the tree of links between your pages, because they aren’t seeing what you are seeing, they need to interpret the script behind the scenes that is being executed.

So the Angular team announced a complete rewrite of Angular 1, because they found that the structural problems with Angular 1 could not be resolved via a simple upgrade. They gave their own existing product a resounding fail. In doing so, they signed its death warrant.

What do you select then, if you have a whole lot of experience in Angular 1, and need to choose a JavaScript framework for your next project?

Well, after analysing the market, reading a whole stack of analysis and reviews, having a play around with the technologies, I can say that there’s not a lot in it. Because Angular 2 is so different to Angular 1, you don’t need to automatically choose Angular 2 going forward. That said, because of the strength and size of the Angular 1 market, I don’t see Angular 2 going away any time soon.It may be an easier sell to management, especially how much was previously invested in Angular 1 training, to go to Angular 2.

Steve Sanderson, from Microsoft, produced the following table, showing the benefits of the few of the frameworks. I really thing the server side pre-rendering is important, especially when one of the major complaints with Angular 1 was the lack of deep-linking and SEO support.

Angular 2 Knockout React React + Redux
Language TypeScript TypeScript TypeScript TypeScript
Build/loader [1] Webpack Webpack Webpack Webpack
Client-side navigation Yes Yes Yes Yes
Dev middleware [2] Yes Yes Yes Yes
Hot module replacement [3] Yes, limited Yes, limited Yes, awesome Yes, awesome
Server-side prerendering [4] Yes No No Yes
Lazy-loading [5] No Yes No No
Efficient prod builds [6] Yes Yes Yes Yes

There is one framework not shown here that has gained some traction in recent times and that is Aurelia, which has recently been released (RTM). Aurelia was created by the developer who produced Durandal. He later joined the Angular 2 team, had some input into that, but later left that team because he disagreed with some of their decisions. And some of those decisions are probably valid, while others may not have been, such are the egos of developers. Aurelia is supposed to have a more simplified syntax to Angular but doesn’t currently have the market penetration.

I like to keep things simple. I like to look at what has solid traction, and try to limit my choices based on what the technical capabilities are, maintainability, performance, ease of learning it and popularity. This tells me that the two frameworks with the most promise are actually Angular 2 and React+Redux.

Although Angular 2 has only reached RC4, I still consider it a viable choice today, as, remember, by the time  your app is released it will most likely have gone to RTM. There are actually a number of significant applications that have been built in Angular2 release candidate. The strong tooling and support when Angular 2 is finally released is also a consideration, as whatever your choice is, you really will want longevity of your code base, and you certainly don’t want to be embarrassed by making a fringe choice that has potential that never materialises.

Alternatively, you might choose to go with React+Redux, which is also available with Visual Core 1.0 and Visual Studio 2015. React is supported by Facebook, and is part of a more advanced ecosystem. Facebook are also innovating faster to answer any architectural issues related to component-based frameworks. Each framework tries to steal the best bits from each other, and both React and Angular have been doing this.

If it was pure performance I was after, I think I would have to go with React. React is not an Angular killer, however, mainly because of the size of the Angular base and the structure it provides.  React is probably a lot simpler to learn, while Angular 2 has become better at this. It really comes down to how structured you need your code to be versus how much performance you need to get out of your web servers. With massive cloud based sites, extra web servers and lower serving capacity costs money, so I’d say they’d probably be better with React.

 

Edit: I just found another table that is worth linking to, by Shannon Duncan. It has more attributes compared, which make it much more interesting:

angular2-vs-react

That article may be found here: Angular2 vs React


Installing Angular 2 to run with Visual Core 1.0 in Visual Studio 2015

August 7, 2016

I initially had a lot of trouble even finding references to people using Angular 2 in Visual Studio 2015. It seems that no matter what I fiddled with, there were failures at every turn. It ended up being quite tricky to get it working. In the end I found that the best way to get going in Visual Studio 2015 was to use yeoman to create your base. And then work backwards to figure out where I went wrong.

Yeoman is yet another package manager. Basically, smart people put together packages with technologies that they think are right together, and submit the packages to yeoman. You go to yeoman.io and you can look up the packages that others have put together.

I initially tried via the yeoman web site, clicked on Discovering Generators, then searched for Angular2, and found the aspnetcore-angular2 package. It was ok, but I had trouble getting it working with ES5.

I recently went to NDC Sydney, and saw a session by Steve Sanderson. He has put together a great yeoman package that works with Visual Core 1.0 in Visual Studio 2015. The package is called generator-aspnetcore-spa, and installation details are available from his web site: Steve Sanderson’s blog. It has been updated to RC4, and the TypeScript target is set to es5, so it will run on most popular modern browsers.

The beauty of Steve Sanderson’s package is that it also supports React as well, in case you want to give that a try.


Why you should (almost) always choose an off-the-shelf grid and not build your own.

July 30, 2016

Recently I was in a situation with a whole lot of people who I think should know better. We were building an application and I was not there when the questionable decision was made to build their own grid.

There are a whole swag of reasons, except in the simplest of cases, why you should never build your own grid. Grids can be complicated, and they can require a significant investment to obtain even the simplest of features that you would otherwise get in an off-the-shelf product.

Features like sorting, filtering, frozen columns, frozen rows, summing, hierarchies, cell editing, data exporting, pagination etc. For high volume data, they also include virtual paging, which loads data into the grid page by page, instead of all at once. They can be styled however you want them, and they are fully tested. Sure, they can require a little bit of learning to achieve what you need, but the cost of doing this is significantly less than the build your own solution. The only time you run into problems is when there is too much bloat, or you are trying to do too much with the grid, a problem you would probably have regardless of which path you took.

But you don’t need to believe my opinion. It is a principle of Domain Driven Design. Eric Evans, the original author of Domain Driven Design has a Domain Driven Design Navigation Map which clearly states “Avoid over-investing in generic sub-domains.”

A grid is a perfect example of a generic sub-domain. From Eric’s Diagram:

domain driven design navigation map - generic subdomain

So next time someone is absolutely adamant that they need to build their own grid, see through that for what it is, especially if they claim to be Domain Driven Design experts.


Notes from building a first ASP.Net Core App (part 10)

July 25, 2016

There’s a new feature called Tag Helpers. They are attributes that you add that help clean up the html tags. They are actually executed just like yellow code, on the server. I’m going to set up a simple one to show redirection to a separate page.

  1. In the Home folder, add a new MVC View Page called Detail.cshtml. This will simply display the details for a single Hotel. Add the following code:
    @model MyFirstAspNetCoreApp.Models.Hotel
    
    <html>
    <head>
        <title>Home</title>
    </head>
    <body>
    <h1>Welcome!</h1>
        @Model.Id <br/>
        @Model.DisplayName
    </body>
    </html>
    
  2. Now we need to add a method to the Home Controller so that knows about the Detail page. In the Home Controller, add the Detail method, as follows:
    using Microsoft.AspNetCore.Mvc;
    using MyFirstAspNetCoreApp.Services;
    using System.Linq;
    
    namespace MyFirstAspNetCoreApp.Controllers
    {
        public class HomeController : Controller
        {
            private IHotelDataService hotelData;
    
            public HomeController(IHotelDataService hotelData)
            {
                this.hotelData = hotelData;
            }
            public IActionResult Index()
            {
                var model = hotelData.GetAll();
                return View(model);
            }
    
            public IActionResult Detail(int id)
            {
                var model = hotelData.GetAll().First(h => h.Id == id);
                return View(model);
            }
    
        }
    }
    

    Note that I’ve cheated a little with the use of First in the LINQ above. It’s a sample app and I need to keep it as simple as possible.

  3. Next we need to add a Tag Helper dependency to our project. Right-click on references and select the Nuget Package Manager. Choose browse and in the search box type TagHelpers. Select the Microsoft.AspNetCode.Mvc.TagHelpers package, install the latest version and blindly accept the licence. After installing the package, there will now be an extra dependency in the project.json file for the newly installed package.
  4. There is a new type of file you can use in Asp.Net now called a View Imports file. That file is called _ViewImports.cshtml. You can add import statements to that file and they will be imported by every file in that folder or in any subfolders. Right-click on the Views folder, and add a new MVC View Imports Page called _ViewImports.cshtml (the default.)
  5. Inside the _ViewImports.cshtml file I add the following line of code, which tells the application that I will be using all the tags in the current assembly:
    @addTagHelper "*, Microsoft.AspNetCore.Mvc.TagHelpers"
    
  6. Now, to keep things simple, I am going to change the DisplayName being presented in the Home Index.cshtml page to a link. In the Home Index.cshtml, I change the contents of the li tag as follows:

    @model IEnumerable<MyFirstAspNetCoreApp.Models.Hotel>
    
    <html>
    <head>
        <title>Home</title>
    </head>
    <body>
        <h1>Welcome!</h1>
        <ul>
            @foreach (var hotel in Model)
            {
            <li>
                <a asp-controller="Home" asp-action="Detail" asp-route-id="@hotel.Id">@hotel.DisplayName</a>
            </li>
            }
        </ul>
    </body>
    </html>
    

    Interestingly, you don’t actually need to specify the asp-controller tag if that’s the controller you are currently in. Also, this doesn’t mean that the old ActionLink methods aren’t still available. The following line would still work, it just doesn’t look as aesthetically appealing:

    @Html.ActionLink(@Model.Id.ToString(), "Detail", new { id = Model.Id })
    
  7. Run the application (F5) and when you hover over the links, you should see the last argument (id) change in the link. Click on one of the links, and you should see the details of that link displayed on the Detail page.

Notes from building a first ASP.Net Core App (part 9)

July 24, 2016

I now want to connect my application to the database. The Entity Framework has been completely re-written for Dot Net Core. Larger ORMs such as Entity Framework and nHibernate are great ideas, especially with their integration with LINQ, because they allows you to write SQL-like syntax in your middle-tier, instead of manipulating SQL strings. This means that they essentially shift any syntax errors that would normally be found at runtime back to compile time, and anyone that has studied the benefits of discovering bugs earlier in the development life-cycle knows that the earlier you find an error in the process, the cheaper it is to correct.

That’s all well and good, except that the performance price for doing this has sometimes been a factor of 10x. That is, queries that would take 500ms in Entity Framework have taken only 50ms in Dapper, a streamlined, cut down ORM (known as a Micro-ORM), and marginally less with a straight Sql Data Reader (perhaps around 48ms).

So many people, especially people that code for high performance sites, have moved away from Entity Framework and are now using Micro-ORMs, such as Dapper.

And as I’ve suggested above, the downside is that Micro-ORMs such as Dapper force us to return to using strings, which returns us to the position of potentially only discovering errors in SQL at runtime. To counteract this, developers must absolutely write a lot of tests to ensure this situation does not occur.

But for now, I want to see how to get the new Entity Framework to work, so I will set up the application to perform some work, then later on perhaps I will run a few tests comparing the new Entity Framework to Dapper.

So next, I need to install Entity Framework Core edition. And I want to configure it for Database First Migrations.

  1. Open up Package Manager Console, and run the following commands:
    Install-Package Microsoft.EntityFrameworkCore.SqlServer
    Install-Package Install-Package Microsoft.EntityFrameworkCore.Tools –Pre
    

    Note the Pre in the second command. That is because the Tools for the Entity Framework Core actually haven’t made it to RTM yet. They are still working on them. But in the meanwhile, we can still use the pre-release version. The Tools part is what gives us Migrations in the Package Manager Console.

  2. Some modifications are needed to the project.json file. Make the following additions to the project.json file, found in the root folder.
    {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.0",
          "type": "platform"
        },
        "Microsoft.AspNetCore.Diagnostics": "1.0.0",
        "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
        "Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
        "Microsoft.Extensions.Logging.Console": "1.0.0",
        "Microsoft.Extensions.Configuration.FileExtensions": "1.0.0",
        "Microsoft.Extensions.Configuration.Json": "1.0.0",
        "Microsoft.AspNetCore.StaticFiles": "1.0.0",
        "Microsoft.AspNetCore.Mvc": "1.0.0",
        "Microsoft.EntityFrameworkCore.SqlServer": "1.0.0",
        "Microsoft.EntityFrameworkCore.Design": {
          "type": "build",
          "version": "1.0.0-preview2-final"
        },
        "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final"
      },
    
      "tools": {
        "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final",
        "Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"
      },
    
  3. Now we need a Database Context object. I created new Folder called DBML in the root of the project, and added a new class called HotelDbContext.
    my-first-asp-net-core-app-folder-structure-4
  4. Inside the HotelDbContext, I have inherited from the Entity Framework’s DbContext class, set up a constructor to pass in options such as the connection string, and made a reference to the Hotels DbSet. This is how EntityFramework knows that the Hotel class is what it wants to generate database objects for.
    namespace MyFirstAspNetCoreApp.DBML
    {
        public class HotelDbContext : DbContext
        {
            public HotelDbContext(DbContextOptions<HotelDbContext> options) : base(options)
            {
            }
            public DbSet<Hotel> Hotels { get; set; }
        }
    }
    
  5. The next task is to create the new Sql Hotel Data Service. We will switch the Hotel Data Service from the Dummy Hotel Data Service to the Sql Hotel Data Service.
    In the services folder, I have created a new IHotelDataService.cs file. I have taken the original IHotelDataService.cs interface and have now put that into the IHotelDataService.cs file, removing it from DummyHotelData.cs. Then I added a new class, which also inherits from IHotelDataService, as SqlHotelData. The Services folder now looks like this:
    my-first-asp-net-core-app-folder-structure-5
  6. Here is the new code for SqlHotelData:
    using System.Collections.Generic;
    using MyFirstAspNetCoreApp.Models;
    using MyFirstAspNetCoreApp.DBML;
    
    namespace MyFirstAspNetCoreApp.Services
    {
        public class SqlHotelData : IHotelDataService
        {
            private HotelDbContext context;
    
            public SqlHotelData(HotelDbContext context)
            {
                this.context = context;
            }
            public IEnumerable<Hotel> GetAll()
            {
                return this.context.Hotels;
            }
        }
    }
    

    Note that the SqlHotelData constructor takes a HotelDbContext object as an argument. This is passed in when the class is instantiated. I have then used that context object to obtain the list of Hotels in the GetAll() method.

  7. Back to configuration, and I have discovered that application settings are now meant to be stored in a file called appsettings.json. It says so in a comment the web.config file. So I have renamed my custom configuration file to appsettings.json.my-first-asp-net-core-app-folder-structure-6
  8. This requires a change in the Startup.cs file. Modify the Startup constructor to point to the correct settings json file:
    public Startup()
    {
        Configuration = new ConfigurationBuilder()
                       .SetBasePath(Directory.GetCurrentDirectory())
                       .AddJsonFile("appsettings.json")
                       .Build();
    }
    
  9. While we’re here, we may as well set the data context and redirect from the Dummy data source to the Sql data source. In the Configure Services method, comment out the old Dummy line and introduce the new Sql line:
    public void ConfigureServices(IServiceCollection services)
    {
       services.AddMvc();
       services.AddSingleton<IMyCustomConfiguration, MyCustomConfiguration>();
       services.AddSingleton(implementationFactory => Configuration);
    
       //services.AddScoped<IHotelDataService, DummyHotelData>();
       services.AddScoped<IHotelDataService, SqlHotelData>();
    }
    
  10. Now the reason I needed to fix up the appsettings file was that this is where I want to add in the database connection string. Go to the appsettings.json file and add a new connection string for the Hotel Database.
    {
      "my-custom-message": "The quick brown fox!",
      "ConnectionStrings": {
        "HotelDatabaseConnection" :  "Data Source=(localdb)\\mssqllocaldb;Initial Catalog=MyHotel"
      }
    }
    
  11. To wire this up and add the DbContext in, go back to the ConfigureServices method and add a services.AddDbContext line, as follows:
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
        services.AddSingleton<IMyCustomConfiguration, MyCustomConfiguration>();
        services.AddSingleton(implementationFactory => Configuration);
    
        services.AddDbContext<HotelDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("HotelDatabaseConnection")));
        //services.AddScoped<IHotelDataService, DummyHotelData>();
        services.AddScoped<IHotelDataService, SqlHotelData>();
    }
    
  12. Now for the fun bit: Migrations. Because we’ve installed the Entity Framework Core tools and added the “Microsoft.EntityFrameworkCore.Design” dependency in the project.json file, we should now be able to run the migrations from the Package Manager Console window. Open up the Package Manager Console and type:
    Add-Migration MyFirstMigration
    

    If successful, it should show the line “To undo this action, use Remove-Migration.” If you look in you project, there should now be some generated migration code under a new folder called Migrations. I won’t go into it, but feel free to take a look at this.

  13. Finally, to get he migration to execute, go to the Package Manager Console and enter:
    Update-Database
    

    After a bit, it should respond with “Done.”

  14. Go to the View menu in Visual Studio 2015, and select “SQL Server Object Explorer”
    my-first-asp-net-core-app-sql-server-structure
  15. You should see the results above. But we’re not ready to execute it just yet – there is no data. Right click on the dbo.Hotels table and click View Data. We will insert the data there.
    my-first-asp-net-core-app-sql-server-data-entry
  16. Now run the application (F5), and you should see the new data appear in the browser:
    my-first-asp-net-core-app-updated-data
  17. And that’s it! Hopefully I haven’t missed anything. Post a comment if I have and I’ll try to be responsive and fix it pronto.

Notes from building a first ASP.Net Core App (part 8)

July 23, 2016
  1. To change it to a list of hotels, the first thing I want to do is set up a dummy data source for the hotels. That’s because I’m not actually getting the data from a database. I want to be able to switch the code over to a database at a later stage, and I don’t want the application to know when I do that. This is important for later, as it is this concept that allows us to independently unit test components.
  2. I have added a HotelDataService class to a Services folder at the top level of my Solution:
    my-first-asp-net-core-app-folder-structure-3x
  3. Inside the HotelDataService, I have the following code:
    namespace MyFirstAspNetCoreApp.Services
    {
        public interface IHotelDataService
        {
            IEnumerable<Hotel> GetAll();
        }
    
        public class DummyHotelData : IHotelDataService
        {
            IEnumerable<Hotel> hotels;
            public DummyHotelData()
            {
                hotels = new List<Hotel>
                {
                    new Hotel { Id = 1, DisplayName = "Sofitel" },
                    new Hotel { Id = 2, DisplayName = "Westin" },
                    new Hotel { Id = 3, DisplayName = "Novotel" }
                };
            }
    
            public IEnumerable<Hotel> GetAll()
            {
                return this.hotels;
            }
        }
    }
    
  4. By using an interface, we can separate the source of data from the delivery of that data.
  5. Next, we need to tell the application that this is a service to be injected into a page. And we need to tell it that the data that we want for now is the Dummy Hotel Data. That’s done back in the Startup class, in the ConfigureServices method, as follows:
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
        services.AddSingleton<IMyCustomConfiguration, MyCustomConfiguration>();
        services.AddSingleton(implementationFactory => Configuration);
    
        services.AddScoped<IHotelDataService, DummyHotelData>();
    }
    

    Note the AddScoped method. This tells the application that each http request should get its own instance of that service, whatever the IHotelDataService supplies, which in this case is DummyHotelData.

  6. Back in the controller, the hotel data service can now by injected via the constructor. Remember, that’s the pattern with dependency injection now:
    namespace MyFirstAspNetCoreApp.Controllers
    {
        public class HomeController : Controller
        {
            private IHotelDataService hotelData;
    
            public HomeController(IHotelDataService hotelData)
            {
                this.hotelData = hotelData;
            }
            public IActionResult Index()
            {
                var model = hotelData.GetAll();
                return View(model);
            }
        }
    }
    

    See the addition of the HomeController constructor, with the hotel data service interface? The application understands that it needs to look up the list of services to obtain an instance from IHotelDataService. It is stored in a local variable that can then be used on the page.
    The model is then set to retrieve the data from the data source on line 13.

  7. Finally, I update the Index.cshtml page to strongly type the IEnumerable and also to display the entire list of hotels:
    @model IEnumerable<MyFirstAspNetCoreApp.Models.Hotel>
    <html>
    <head>
        <title>Home</title>
    </head>
    <body>
        <h1>Welcome!</h1>
        <ul>
            @foreach (var hotel in Model)
            {
            <li>
                @hotel.DisplayName
            </li>
            }
        </ul>
    </body>
    </html>
    

Notes from building a first ASP.Net Core App (part 7)

July 23, 2016
  1. Controllers should inherit from a Controller base class. This will give you a significantly enhanced set of features related to being a controller.
  2. Go into the HomeController class and change it to inherit from Controller:
    public class HomeController : Controller
    
  3. You should have a formal way to encapsulate the decision of a controller. As a result of this, instead of returning a string from the Index() method, I decided to return a View of a model I created.
  4. At the top level I added a Models folder, and I have added a Hotels.cs class file to that. I have added the following code:
    namespace MyFirstAspNetCoreApp.wwwroot.Models
    {
        public class Hotel
        {
            public int Id { get; set; }
            public string DisplayName { get; set; }
        }
    }
    
  5. Next, I changed my Index action method to return the new View complete with model, as follows:
    public class HomeController : Controller
    {
       public IActionResult Index()
       {
          var model = new Hotel { Id = 1, DisplayName = "Hilton" };
          return View(model);
       }
    }
    
  6. Next, add a Views folder to the solution at the top level of the folder structure, and add an Index.cshtml file to that folder.
  7. As an aside, it looks like Microsoft have decided that the best place for all these MVC folders is at the top level of the project folder structure. I never would have guessed that. But if you don’t have an Index.cshtml file and you run the application, it will tell you where it is attempting to look in /Views/Home/ for the Index.cshtml file. I initially tried to put this under wwwroot, and it couldn’t find it. I put it at the top level of the project and it found it. I have since moved everything to the top level. As  a result, my wwwroot folder is now empty! My solution is now looking like this:
    my-first-asp-net-core-app-folder-structure-2
    Oh well, its all a learning experience!
  8. When moving the folders above to the root level, remember to remove the .wwwroot. from the namespaces.
  9. In the Index.cshtml folder, I have added the following:
    <html>
    <head>
        <title>Home</title>
    </head>
    <body>
    <h1>Welcome!</h1>
    <div>The hotel name is: @Model.DisplayName</div>
    </body>
    </html>
    
  10. Run the application (F5), and see the result. The Hotel name is displayed in the browser.
    my-first-asp-net-core-app-hotel-name
  11. The model is currently not strongly typed in the cshtml page. If you want to strongly type the model, you need to tell Index.cshtml what the type of the model is. Add the following to the top of the file:
    @model MyFirstAspNetCoreApp.Models.Hotel
    
  12. When you do this, any time you reference Model on the page, it should invoke intellisense and show you all the other options available on the Hotel object. Note that it is no longer in the wwwroot namespace as I’ve moved it to the root folder of the project and renamed the namespace.
  13. Next I will return a list of Hotels.