Recreating the wheel - musing about following asp.net vNext
Over the past year I have wrote, re-wrote and refactored the back-end code of my blog a number of times. I originally started off with the goal of trying to write a single page blog without using the bloated System.Web namespace and all the overhead that it brings. Doing a lot of Angular.js work at the time and running into some SEO concerns I decided to create the blog as a SPA application and implement some form of pre-rendering so that the content can still show up on Google.
Original Technologies used
-WebAPI 2 running on top of OWIN, static html files with all rendering done client side using Angular.js
Nancy- The first re-working was fairly small in adding the open source Nancy Framework in order to cut down the original loading time on the home page. Using strictly static html files with all of the data being loaded via ajax was just too slow.
ASP.NET vnext announced
After I had already finished my blog Microsoft announced what is being referred to as ASP.NET vnext, which is basically a re-write of ASP.NET MVC from the ground up removing the dependencies taken on System.Web, combining WebAPI and MVC and introducing a new leaner version of the core pieces of .Net where you only load what your application needs. I was excited from the very first announcement of .Net vnext. Like many developers I had run into a few bottlenecks with .Net's slow startup time and often wanted to host my application on Linux (something that I have done in the past using Mono but the effort and trouble wasn't worth it). It seems that the original MVC borrowed/stole a lot of idea of the then "cool" technology of Ruby on Rails with the re-write of .Net Core and ASP.NET vnext boring/stealing many of the great things from Node.js with its loading of just what you use and being able to handle a very high request load on fewer resources.
vNext alpha 1 and 2
I first rewrote my blog and got 90% of it working on alpha 1 of ASP.Net vNext. Like any first Alpha the code was really raw and I ran into a lot of things that just didn't work. The interesting thing with Microsoft developing vNext in the open on Github is that when I ran into odd errors or archaic messages I was actually able to dig into the code and see why it was throwing specific errors and how it was expecting my code to work. I probably should have held off on re-factoring my code to work with vNext but it is fun from time to time to follow a a new technology and see how it develops. When alpha 2 was released I was able to get my blog working completely with the new vNext and have been running on alpha 2 for a number of months now.
Grunt and precompilation
Alpha 3, 4 and Beta 1
With running and work keeping me busy I followed most of the changes but didn't get the full blog up and running on any more of the releases until Beta 1 which is a lot more solid than the alpha builds. Watching the progression of the project its been interesting seeing changes and even participating on some of the discussions on Github about features that I think need to be changed or propositions of others that seem wise. I have done most of my development on this project using Visual Studio though I did try using a simple text editor (Notepad++) with the first alpha release. As I didn't want to muck up my main development machine I did all of my development on a VM which felt really slugging with how many resources Visual Studio uses and my main laptop getting to be a couple of years old now so lately I have switched over to trying the Open Source Atom editor out as it has c# autocompletion and tools for grunt and have been surprisingly pleased with it though it has some areas such as file searching and window layout that need some updating. I may switch to using the Atom editor for many of the things that I used to use Notepad++ but am still uncertain about using it for c# projects but still need to use it a little bit more to see how I like it once it becomes more familiar.
vNext won't be done for a while and it will probably be a while after that before I get to use it on a daily basis at work but following the project has taught me a few things that I am putting into place on production projects that I oversee such as using Grunt over script bundles.