I'm excited about WebAssembly, but not as much about my beloved .NET, Blazor's implementation

As a web client developer these days, I'm sold on WebAssembly and looking forward to it's adoption by the multiple languages that can compile to it. However interestingly one of the things I'm beginning to feel is my personal dislike for the Blazor syntax and implementation. I suppose my multiple years being entrenched in JS/TS with really enjoying TypeScript + the SPA frameworks that have a relatively clean separation of markup (declarative) and logic (imperative) has made me have a bit of dislike for lacing the view directly with imperative view logic like this in Blazor:

@page "/myorders"
@inject HttpClient HttpClient

<div class="main">
</div>

@if (ordersWithStatus == null)
{
  <text>Loading...</text>
}
else if (ordersWithStatus.Count == 0)
{
  <h2>No orders placed</h2>
  <a class="btn btn-success" 
        href="https://www.blogger.com/2404">Order some pizza</a>
}
else
{
  <text>TODO: show orders</text>
}

As a side of humor, to format code blocks on this blog I have to select a 'brush' for the language formatting. Case in point, in the above snippet I wasn't sure if I should have picked HTML, C#, or Blazor.

This is probably because I was never a fan of the classic ASP, MVC Razor, or even Blazor implementations where view logic is interlaced with the markup (for web client code I'd even throw in JSX - as explained here). This doesn't matter a pile of beans really because this is all subjective and has absolutely no bearing on how successful Blazor or any other language targeting WebAssembly will be. I actually love the .NET stack and was carved from that block since the beginnings of my professional career, but I just don't like that particular style of implementation for the web. Shoot for all of ASP.NET's webforms shortcomings, the view overall was relatively clean (keeping logic in code separate from the markup) and pure aside the fact the tags may have been ASP.NET server-side controls but still took the shape of HTML tags (analogous in form to today's custom HTML elements).

I also do not like the JSInterop style in Blazor. You can invoke JavaScript functions from within C#, and that alone is handy I suppose, but messy. The functions you want to invoke must be available on the global scope of window. Yuck. JavaScript scope and encapsulation was difficult enough to manage through the years, I'd rather not go back to the days of hanging code off the window object making everything globally available. In 100 level examples this seems fine, but get to 10's or 100's of thousands of lines of code in an enterprise app and this could get ugly.

<script>
  window.MyFunction = (someValue) => {
    //JS code here...
  };
</script>

using Microsoft.JSInterop;
public class JsInteropExample
{
  public static Task MethodName(strings someValue)
  {
    return JSRuntime.Current.InvokeAsync("MyFunction", someValue);
  }
}

I'm probably not alone in my opinions, and that's why I'll be keeping an eye on the ability to use TypeScript as a target for WA. I like JS/TS and am comfortable with it for developing web applications. I feel many client side developers may have a similar sentiment and not want to either learn a server-side language, or just prefer the front-end languages they've been using for years. TS on it's own won't be enough (it's just a language), so it would have to be TS + some web framework (??) and we'll have to wait for the pieces to come together.

To that end I'll keep an eye on things like assemblyscript which is a TypeScript to WebAssembly compiler. It doesn't appear to have the traction some of the other compilers do at the moment, but I'm sure it or something similar will gain momentum as WA picks up and the masses of web developers may not feel like using C#, C++, or Rust.

AssemblyScript: a TypeScript to WebAssembly compiler

AssemblyScript: Status and Roadmap

I'm not counting Blazor out for sure, and it's still going to evolve as it's only an experimental project at the moment. I really enjoy developing in C# so it seems like a great match, but in it's early stages it's rough around the edges and maybe that's just my opinion that's shaped as a front-end developer. I'm pragmatic and will not count out the usefulness of developing on a single-stack and this is where Blazor shines for .NET developers. 

I'd be interested in feedback or thoughts about using TypeScript to transpile to WebAssembly or anything else along these lines, so please feel free to leave a comment and let me know.

Is ASP.NET MVC the new WebForms because of Smart Client JS Web Apps?

In the last few years JavaScript, JavaScript frameworks, and the browser have matured exponentially providing us with AngularJS, React, Aurelia, Ember, and others. These frameworks allow for web developers to create performant and rich smart client JavaScript web applications (a.k.a SPAs). So what about ASP.NET and that old trustworthy MVC implementation? As an analogy, is MVC the new 'WebForms' as to how WebForms were viewed when MVC came to the scene? Is ASP.NET MVC obsolete or considered now 'old hat' from an implementation perspective? I think it is mostly 'yes' and just a bit of 'no' to that question and I'll provide points to both.

The bold answer is yes - MVC is a relic of days past and anyone that uses it has their head in the sand. Well maybe not quite and certainly not near being obsolete. However there is some merit to the fact that ASP.NET MVC is showing it's age as an implementation choice. There are many things that JS web applications do very well and architecturally speaking just make sense. 

To begin, the JS Frameworks by nature move the heavy rendering and presentation logic to the client. This removes the burden on the server of packaging both markup and data to send to the client. The server's main responsibility is now returning only data typically in the way of JSON payloads via RESTful services (i.e. NodeJS, WebAPI), as well as the web artifacts on an as needed basis (i.e. views, images, JS, etc.). With most frameworks, once the views and associated JS is brought to the client it is cached. The combination of client side processing + caching of data and website artifacts = highly performant web applications.

The 1st time most developers get accustomed to a JS Framework creating a web application, and experience how the line between desktop applications and web application almost is non-existent they often see the many benefits and don't look back.

Add atop of all this, most JS Frameworks were built with testing in mind, have massive adoption, huge amounts of support, examples, and training which adds up to something one can feel confident moving forward with as an implementation choice.

Another advantage of smart client JS Web Applications is the fact that they make sense architecturally. MVC by nature is and should be a presentation layer architecture. In ASP.NET MVC, I still see often the architecture abused and used as the full-blown implementation for Enterprise Applications. I don't blame most for doing this as the majority of  '101' examples show this implementation so it must be what is used for everything, right? Wrong. It's analogous for those of you that have used Angular 1.x and having the controller make $http calls directly, or abusing $scope as the do-all for the app. 

A tattle-tale sign of using MVC incorrectly is if the 'Model' is directly making database calls (i.e. EF or whatever) and then having the Controller make calls to methods on the Model. This then results in bloating either the model or controller (or both) with additional business logic or model hydration/shaping. MVC should be the top layer of the cake and only concerned with presentation layer logic and manipulation. JS Frameworks for the most part solve this problem naturally because of the separation now between the client and server. It's more difficult and many times not even possible to abuse the JS Web App client implementation that was done so often in ASP.NET MVC. Now one is forced to call the server for data, and then on the server another layered implementation can exist within the RESTful service to handle logic, rules, additional underlying calls, hydration/shaping, etc.. With a JS Web App we should relegate the MV* implementation client side to only presentation layer concerns, and allow the server to do what it does best and offer up reusable RESTful endpoints, encapsulating all server logic. With MVC this was absolutely possible, however it was typically a conscious decision and had to be made usually at the project's onset in order to have decent SoC and testability. Otherwise the result would be behemoth of a web application stuffed into the slim MVC implementation. 

From a JavaScript perspective my experience as a whole in MVC usually yielded to a jQuery implementation for DOM manipulation and a multi-thousand line file named MyApp.js. At 1st this file seems like a good idea, but then it snowballs into a intermingled mess of reactionary code responding to events, registering callbacks, making AJAX calls, manipulating views, and a hundred other things all interwoven together. Most of the time I saw no forethought put into proper segregation using known JS patterns like the module or revealing module pattern, and mostly a mess of public values and methods that were a ticking time bomb of heavy maintenance. In JS Framework implementations, there is a separation of concerns between the Model and View logic allowing testing and scaling your application more correctly. The alleviates the need for JS DOM manipulation libraries like jQuery all together.

Let's pile on another thing helping out JS Web apps in the way of languages like TypeScript.

This gem which was originally created at Microsoft by the same guy that created C# and is OSS, is a superset of JavaScript and adds on a slew of features to help developers wrangle some of the JavaScript nuances. There isn't anyone here claiming JavaScript is a perfect language, but I'll tell you from 1st hand experience using TypeScript makes creating JS Web apps in my experience a whole lot easier. Static typing, build time checking of code, Interfaces and other language features that don't exist in JS, staying ahead of the ECMAScript standards and releases, OO familiarity, and many other goodies help make TypeScript a real joy to have in the toolbox when creating JS Web Apps.

So now let's look at the flip side of the coin: ASP.NET MVC's advantages. Well to begin Microsoft is doing ASP.NET in general a whole world of good in the way of .NET Core 1.0. From a project's physical structure and implantation, the new world of the web in VS.NET is brought inline with where the rest of the web and OSS community has already been in the last several years. This is to the tune of task runners like Gulp or Grunt, additional package managers in the way of NPM and Bower, .json configuration for many different project components or languages like TypeScript, and several other new changes. 

The irony is from WebForms to MVC we moved from a 'Convention over Configuration' phase. Now we are shifting back to 'Configuration over Convention'. However this is in a very good way. Instead of getting many tools, resources, and processes being dictated and packaged up by default, you need to tell your web app exactly what you want and how you want it to behave from start to finish. This is a good thing. We as developers should have full control over our applications and dictate this configuration. At first this might cause some heartburn as change sometimes does, but it's the right move and I applaud Microsoft. For so long I used to promote how much I liked living inside the comfortable confines of ASP.NET and VS.NET. This magic thing like 'bundling and minification' was done for me along with many other tasks to get up and running. There is a little more work now as this doesn't even exist anymore in .NET Core 1.0, but I can control and configure my apps to be lean and behave as I want them to.

So wait, what about the good bits of MVC?? The above was like a back-handed compliment about MVC finally catching up to more standard methods of configuring web applications. However there are a couple of big things MVC still has going for it.

1st it's quite mature. ASP.NET has been around since 2001 and the MVC implementation since 07`. That's almost 10 years going strong. In addition Microsoft is behind it and is now OSS. It's not going anywhere, anytime soon. If your looking for that rock of stability and being conservative MVC is a good choice. Keep in mind though, ASP.NET WebForms is stable and around too, but that doesn't mean it's the best decision.

2nd, because of it's maturity there are a slew of developers that have experience with using it and developing application for it. There are just some realities that exist. Things like deadlines and financial constraints are legitimate concerns. As the lead, architect, decision maker, etc. on your team you might have 10 developers that are strong in MVC and have relatively no experience with a JS Framework and JavaScript in general with a deadline fast approaching. Do you bite the bullet and try your hand at creating a JS Web App, or go with old trusty and bang it out in MVC? That's a decision you'll need to make and one I've encountered as well.

To sum things up, I do believe JS Web Apps are here and probably the best decision for net new web apps today. I personally view MVC as a bit of a heavy weight in the web ring and sometimes we need something a bit more lean to fight our development battle. I agree for the most part MVC is beginning to be viewed as the new 'WebForms' as far as making an analogy to how WebForms were viewed when MVC came to the scene. However as I've broken it down, ASP.NET MVC isn't going anywhere and is still a fine choice to make in certain scenarios. 

Who knows, maybe I'll be writing this same article in 5 years with the following title:

"Are JS Web Apps the new MVC because of WebAssembly?"

Should I Place My Business Logic In Code Or In Stored Procedures?

I see this age old question asked on forums, LinkedIn conversations, interviews, and in general developer discussions. To tell you the truth it has been discussed 1000 times before and I am going to add one more to the pile here.

This is a great debate/conversation, and I have been a part of it several times myself as well. I can honestly say there is no 'right' or 'wrong' in my opinion (OK maybe there is but let me be a little PC here as to not to offend those DB folks right from the start), but only 'pros' and 'cons' to each method. I think both have their advantages and disadvantages, and no option really screams out as the obvious choice on the surface unless there is say some significant performance advantage one way or the other. However I have my bias on 1 side of the argument as I will detail below.

In my experience this is usually who goes on each side of the debate: people with a stronger or more prominent SQL/Database background will opt for placing all the logic in the database where as true software engineers will tend to place those rules within the application and apply the appropriate architecture, design patterns, and frameworks to organize and describe them.

At the highest level Database folks will argue to place that logic in stored procedures or the database because then you can "make changes on the fly" without the hassle of "code recompile and pushing out new releases", where developers that want that logic in code will argue TSQL is such a limited language to debug and express complex business rules that can be evaluated so much better in code.

Well as far as I am concerned that is about as far as that side's (Database crowd) argument goes for me. While their argument is valid, recompiling and redeploying an app because of rule changes is typically not an impossible task. In fact with today's modern deployment options regardless of technology being used this argument is not as strong as it used to be.

In fact the whole idea of "making changes without redeployment" or "changes on the fly" is a bit skewed to begin with. Code of any type should never be changed in a production environment without being tested. Managed code is more likely to be tested using unit tests or at a minimum running the application through some end-user tests before deployment. The temptation to change a stored procedure without testing it fully is ever present, and without a stringent environment with DBAs locking down the database, this option could be exercised all too easily and is a bad idea.

As a developer I tend to try and place these rules (business rules, calculations, math, etc.) in .NET managed code. TSQL is not the easiest language to explain and implement complex business rules and is also more difficult to debug and test. My philosophy is typically to get the raw data back to the code and then manipulate it from there. You have so much more power with the .NET framework and managed code to explain the rules in code than with TSQL. While it is possible with TSQL, have you ever seen one of these 500 line stored procs with a gazillion rules that some database person was flexing their muscle at? Yuck! We are in the business of writing well formed code using OO principals and this is just not possible using TSQL and database languages.

Which side do I fall on? That's easy. I am a developer and engineer at heart and I believe in using the right design and architecture, and that those business rules (or a majority of them) should reside within the application. What's the database for? Getting data and executing some logic, but the brain of solving the business problem for me is not going to be within a stored procedure, view, or user defined function. The only time I flex a tad on this is with 1 off custom queries for say reporting where the Object Model does not currently support the data needed to create the output. In this case I might extend the logic a bit on the database side. If I can extend my Object Model to support the reporting without an extreme amount of work then by all means I will do it. However, when at all possible I keep any business rules or logic within the application.

So the answer is not always so straight forward, but hopefully this post help you think about where this logic should reside (......in the code. Wait, did I just say that!?!?). Now go ask this question on a SQL forum or blog and see what response you get. It will probably be along the lines of... "Put it all in Stored Procedures!!" Have fun coding :P

What Happened To Windows Desktop Gadgets And Why Did Microsoft Abandon Them?

UPDATE (07/05/12): This link all but confirms that Desktop Gadgets will go away as I anticipated in Windows 8: Microsoft reportedly killing off desktop gadget support in Windows 8

A quick opinion entry here post bowling night (Yes I do have other hobbies besides programming!). Anyways back on topic I was quite disappointed to see a Tweet come across a few days ago stating that Windows Gadgets were being retired and the Gallery hosting them was no more. What?!?! I actually have always been a big fan of those things. I mean as a developer that sits in front of a machine with multiple screens for 8+ hours a day, I like all the information those things provide me at quick glance. After all we are in the information overload age (i.e. Smartphones, tablets, computers, etc.) and the gadgets fit right in to that role. Desktop gadgets were 1st made popular on Macs, then Yahoo came out with their "Yahoo Widgets", and finally Windows got in the game to offer support natively in the OS beginning with Windows Vista. However the gallery has been retired and support has quickly shifted away. Here is the official Microsoft Link on the status of the retired gallery and discontinued support:

Looking for gadgets?

Here is an excerpt from the above link stating it all:

"The Windows Live Gallery has been retired. In order to focus support on the much richer set of opportunities available for the newest version of Windows, Microsoft is no longer supporting development or uploading of new Gadgets."

OK I get it. Microsoft is positioning itself for Windows 8 and its new design including a focus on 'Metro Style Apps'. Windows Gadgets don't fit at all into that new design and really hinder in some ways the competing and improved look of Windows 8. You need folks to forget about these little anchored desktop apps and focus on Metro Apps in Windows 8. This could not be as strong of a directive with these 'dead weight' mid 2000 type apps lingering around (not really my thoughts, but probably the view at a meeting at Microsoft when the decision came to retire these widgets). I had already noticed a lack of developer interest and I understand this as well. It's not the sexy thing to spend time on in present day. If you were about to sit down and create a little weather app, would you make a Desktop Gadget or a Windows Phone 7 app for the marketplace? Easy enough answer. But even the minimal support was welcomed and still created a huge portfolio of selectable and free fun, productive, entertaining, and cool apps to have on the desktop. However I think the decision to retire the gallery and discontinue support is a bit premature and let me explain why. It is not often I disagree with Microsoft because I live for the technology they pump out of Redmond, but I am not on the same page with them on this decision.

There was a time from say 1993ish to 2005ish where it was almost a necessity to buy a new computer every few years to keep the hardware up with what the applications could do. Even simple tasks like having a browser open and Microsoft Word could be dauntingly slow on an older machine. So what does one do? Buy a new computer so multitasking became a possibility and didn't drive the user nuts. Also during this time period, the cutting edge industry development and the hardware were not that far apart. Using a Windows 98 box with VB5, Access, C++, etc. and building the best apps (excluding gaming) using the latest technology didn't require any special hardware. Using a standard home PC would allow one to create, build, and deploy these types of apps.

Now we have gotten to a point where I think us in the development community and those in the R&D sector moving the ball forward may not realize the disconnect that is upon us. The cutting edge technology and its expectations in my opinion will not excite a large portion of the market share. Sometime around the mid 2000's, PC hardware began to outpace the software running on it for the 1st time which helped drive costs down on PCs and allowed the consumer to breath a bit and not have to rush out to get the new OS and machine. "Hey if I can run my browser, email my family, and write Word documents, I am set!" Not everyone is 16 years old and rushing out to get the newest piece of hardware that supports the cutting edge technology, which we were all forced to do in years passed. Microsoft could rely on the fact that users would continue to buy newer, faster, smaller PCs and along with that the newest OS too. It was a nice harmony because the software and hardware naturally moved together and everyone (users and developers) had to keep up with the same pace. You didn't find too many Windows 95 users in 2003, 8 years after it came out, but you can certainly find a large portion of home PCs (and businesses too) that are still running Windows XP 10 years after release. This is because that stable, easy to use, machine doesn't warrant being replaced. In current day Microsoft can no longer expect the average user is going to buy a new piece of hardware to support the newest OS; that hand is not naturally being forced as it once was 10-15 years ago. Therefore support of what may be deemed 'legacy' technology or software (even if it is only 5 years old) has to be taken into consideration to keep the masses happy.

So what in the heck does that background have to do with Desktop Gadgets going away you ask? Well, I think for starters a lot of late migrators to Windows Vista or Windows 7 will be disappointed when they buy the computer and see one of the 'neat' features, Gadgets, is retired even before some had a chance to use them. But more prevalent than worrying about people who are behind in technology (hey you snooze you don't get to experience it like those of us that bought it on time, Ha!), is I wonder if Microsoft is going a little hard to place all their eggs in 1 basket with Windows 8. I don't think the masses will move quickly but this is not apparent by those of us in the technical community. We will all have it as soon as it is released to Beta and installed on Day 1. But that is a bad impression for the general use market share. I don't think everyone is going to abandon their PC for a tablet running Windows 8. And don't get me wrong; I don't think Microsoft is thinking this will happen either, but I do think some feel this is what "Everyone will be doing in 5 years..." I am not so convinced. I will be all over Windows 8 because of what I do and how much I like the technology, but I am not sure about Sister, Mom, Dad, Grandma, Friend 1, and Friend 2.

So I liken retiring the Windows Gadgets the start of Microsoft's reposition for its new OS, and is just the tip of the iceberg. I hope Microsoft doesn't continue to make decisions like this to slowly force people into buying Windows 8 because their nice, stable, Windows 7, Vista, or XP machine has 20% of its features retired or not supported. It's an aggressive stance and I get the feeling from the Build conference that Microsoft will be pursuing Windows 8 harder than any OS since maybe Windows 95. I just hope it does not come back to haunt Microsoft by leaving a bad taste in people's mouth by being unwillingly shuffled along faster than they care to. It's a fine line to walk.

This isn't the only instance were they suttly or explicitly phased out technology. For example, VS.NET 2010 will not support Windows CE development. Hold the horses!! I don't recommend making new CE apps at this point in time, but I have 1st hand experience working on a current 3rd party product that uses a propriatary device runnign on Windows CE. Makes total sense why Microsoft would not support CE development in VS.NET 2010: DO WP7 DEVELOPEMENT! But once again it's these decisions that I think don't agree with the masses as evident by the feedback from this Microsoft Connect entry:

No support for Windows CE and Compact Framework development in VS2010

So maybe a bit profound for the analyzation of why the Desktop Gadets went away, but I think there is a bigger picture here. And yes personally I am disappointed and don't think it would have slowed down Windows 8's new sexy features too much. You can still search the net for the individual gadgets if you are looking for a particular one, but they are already difficult to find so zip them up and save off the .gadget files on your machine. It will not matter beyond Windows 7 though because they will not be supported in Windows 8, so enjoy them on your already out-of-date Windows 7 PC (a little tongue-and-cheek there obviously). Or you can still use Yahoo Widgets which you can check out here, and they have a massive widget library:

Yahoo! Widgets

Well the nice thing about this blog is hopefully I can come back in a few years and maybe 'eat crow' showing I was all wrong. But for the time being I am disappointed to see the desktop widgets essentially discontinued, and I feel Microsoft may have missed the bulls-eye a bit on this decision.

Anyone reading this feel free to post links to websites, SkyDrive locations etc, to share .gadget files if you wish.