Bundling and Minification with Web Essentials

Pta.Build.WebEssentialsBundleTask A few months ago, the Tachyus web application used a C# + F# web application approach to separate the front-end HTML, CSS, and JavaScript from the back-end F# ASP.NET Web API application. With this configuration, we introduced Web Essentials to bundle and minify our CSS and JavaScript at build time within Visual Studio. To simplify deployments and better group related and shared code, we decided to merge the back-end with another Web API application, which used the F# MVC 5 project template. We originally tried using CORS, which worked great in almost every environment. Unfortunately, the one environment in which we ran into trouble was our staging/production environment. Since we are building an internal-only API, we haven’t spent the extra effort to make our APIs evolvable; therefore, we decided to just merge all three projects together into the F# web project. This worked rather well, except for Web Essentials. We abandoned Web Essentials, as well as any form of bundling or minification at that time.

Fast forward to last week: we again split the front-end application out into a separate, C# project. We did this for several reasons:

  • We ran into trouble trying to remote debug the F# web project
  • The project had grown to the point that it was quite large, and it made sense to separate the two for maintenance
  • It’s common even in other languages to separate the front-end into a separate folder or project as different teams are often responsible for the different apps, which is not quite our case but close
  • We wanted to clean up our Angular code so that we had less Angular spread throughout and more standard JavaScript; for this we wanted to use bundling again

I was able to add Web Essentials back into the solution since we were again using a C# project. However, this had its own challenges, specifically in the form of communication to the rest of the team that they would need to install Web Essentials in order for their updates to take effect.

Fortunately, my colleague Anton Tayanovskyy recently found and pointed me toward the WebEssentialsBundleTask, which is a MSBuild task that will run the Web Essentials transformations at runtime depending on the build configuration, i.e. Debug or Release. This tool provides explicit script references for Debug builds and a bundled (and minified, if desired) version for Release builds. It seems to only require the presence of a Web Essentials-style .bundle file to work, so I would expect this to work equally well with a F#-only solution, though I have yet to try that. The WebEssentialsBundleTask has its own issues, though. It will modify your index.html file whenever it runs, so you must make sure to revert changes you don’t want to keep. We rarely change our index.html file since nearly everything is built in the form of Angular directives or templates. Nevertheless, you should consider the cost to your own project.

You may wonder why we didn’t just build a simple FAKE task. After all, whitespace¬†in JavaScript is relatively meaningless, so a very simple concat + remove could probably get the job done, especially since we use ; where applicable. I definitely considered this option, as well as creating new FAKE tasks built around a node.exe using tools like grunt.js or gulp.js. In the end, these all seemed like overkill with the availability of Web Essentials, at least until we had evaluated whether WE would work for our purposes. We are still evaluating. What are you using? Did you find this helpful?

F# Web Stack Group

I’ve recently seen an increase in the number of those interested in F# programming for web development. I don’t think this is a recent phenomenon; I just haven’t had the privilege of running into many of them previously. Nevertheless, we have decided to band together to provide a set of useful, well-designed libraries for web development in F#.

If you are interested in learning more, please join us in the F# Web Stack Google Group. I’ve added a list of current projects and efforts in the welcome message so that you can gain your bearings quickly. Current topics include merging various projects into a cohesive stack and planning one or more type providers to build out server and client boilerplate from API documentation.

WebSharper UI Improvements

The WebSharper project has been making significant strides of late in the realm of building composable and reactive user interfaces, especially for the purpose of building SPA-style applications. You can find documentation and demos for WebSharper.UI.Next on its new site hosted on GitHub. Team members have also been blogging about how to build UIs with the new tools on the WebSharper blog.

Anton Tayanovskyy also joined Community for F# a month or so ago to describe the concepts behind the design of WebSharper.UI.Next and how it is different from some other popular approaches, including the virtual DOM approach used in Facebook’s React library. You can find the recording on YouTube.

F# on the Web

I recently presented to the Houston Functional Programmers meetup on the topic of using F# for web development. This is an update to my talks with a similar title based on my experience building a real application for Tachyus. I cover data access using the FSharp.Data.SqlClient and building web APIs using ASP.NET Web API with Frank. You can find the video on YouTube.

How to use base.SendAsync in F# DelegatingHandler

If you’ve ever tried to create an HttpMessageHandler in F#, you’ll have been bitten by the problem of not being able to call base.SendAsync from a callback. The solution is actually quite simple. Just wrap the HttpMessageHandler and expose the protected SendAsync method as a public or internal member:

Now, you can call CallableSendAsync in the correct sequence:

OWIN and IAppBuilder

OWIN v1.0 is now over a year old, and Microsoft is shipping its Katana implementation as part of its Visual Studio 2013 ASP.NET project templates. I think this a tremendous victory for both Microsoft and its community around open source efforts. Congratulations to all involved!

As with all such victories, however, there are a few items that could have gone a bit better. The one I’d like to focus on in this post is IAppBuilder. IAppBuilder is a simple interface meant to provide a common builder API similar to that found in Rack and Connect. Unfortunately, the IAppBuilder does not expose any members that relate to the OWIN application delegate signature. Worse, IAppBuilder is the only type contained in the owin.dll you can pull from NuGet, and several packages now reference and even require this dependency.

Why does this matter?

First, the big debate from the outset was to ensure no dependency was necessary. The original owin.dll had only the standard type aliases for the AppFunc and other delegate signatures of the pre-1.0 OWIN spec. Once we moved to the simpler AppFunc: Func<IDictionary<string, object>, Task> signature, the need for a common assembly disappeared, only it was replaced with the IAppBuilder. I don’t recall exactly when or why this happened. The major problem is that implementations like Simple.Owin, Fix, and Dyfrig, which don’t rely on IAppBuilder, are incompatible with a majority of the current “OWIN” middlewares available today. Here’s an example. You can read more of the discussion here.

Second, the lack of prescribed types in IAppBuilder members means that different implementations may not adhere to the Liskov Substitution Principal. In fact, this is currently the case in the Fix library referenced above. Further, unless you are willing to read the source for the IAppBuilder implementation you are using, you may have trouble writing a middleware adapter that works. (Note: It’s not hard to write a middleware using IAppBuilder, but the interface is insufficient to understand what is required.)

Third, the initial IAppBuilder defined in Katana presents an interesting but also undefined behavior of “falling through” to the next middleware when a 404 is returned. This is a fantastic invention that really helps achieve a terrific goal of hosting different application frameworks side-by-side in the same process. However, this isn’t part of the OWIN specification and not necessary for all applications. In addition, the choice of a 404 as a meaningful event seems a bit of a hack. In my opinion, a proper router middleware would better solve this problem.

Last, IAppBuilder blocked the (perceived or real) problem of not having defined a middleware signature for OWIN applications. For my F#-based OWIN applications, this wasn’t a problem, since F# supports easy function composition that works really well with the OWIN signature. However, many developers trying to use OWIN in C# expressed this as a problem, and a few options have appeared, most of which more or less mimic the function composition I use in F#. The current consensus appears to be that Func<AppFunc, AppFunc> is the right approach. However, that decision is awaiting a reboot of the OWIN governance model to sort out.

Summary

I want to make it clear that I think Katana is a terrific product. I’m thrilled that it has made it into the ASP.NET templates and will become the standard for writing ASP.NET applications in the not so distant future. I’m even more thrilled at how Microsoft picked up and adopted the effort and worked with the community. In fact, two Microsoft employees were responsible for writing the OWIN specification.

Nevertheless, I want to make sure Katana does not become OWIN. OWIN is meant to be an open specification with no default implementation. IAppBuilder is not specific to Katana, but Katana does possess the best example and most popular implementation. Others are free to incorporate IAppBuilder but should pay close attention to the Katana implementation to do it right.

Most importantly, know that you don’t need IAppBuilder at all to build an OWIN application or host. OWIN relates directly to the AppFunc signature and environment dictionary as defined in the specification. Build to your heart’s content.

Software Gardening, or The Fallacy of Software Architecture

I just bought and began reading Brooks’ The Mythical Man Month. I’ve only made it into the original preface, and I’ve already made what is to me a startling discovery (at least to me). When I combine the nuggets I’ve gathered from Kay with those I’ve collected from Joe Armstrong, notably that from the first Lambda Jam, I find the software analogy to architecture to be yet another myth.

Rather than architecture, which may be more accurately applied to hardware, I would rather analogize software to gardening or agriculture. Consider the recent film Man of Steel, in which Kryptonians essentially grew their weapons, buildings, etc. rather than built it in our sense of the term. Now consider the analogies to biology (Kay) and physics (Armstrong) and imagine how your projects might have turned out differently if you thought of “growing” your software. If you combine this with concepts from biology, you may think of *nix-style single-purpose programs or libraries that can be composed into more complex structures via message passing. Each is easy to test, to reason about, to compose.

This isn’t just about the programmer either. Consider the business perspective. Businesses need the agility, when possible, to respond to events as quickly as possible. Business does not need the most beautifully designed solution. Business needs a solution that will work, adapt, deliver when called upon. Consider a tree that bends in a storm is shaped by the winds and forces that beat upon it. No tree looks alike, and none looks architecturally beautiful, but they all have their own rugged beauty. Not even every piece of fruit is exactly alike another from the same tree, yet they share common properties. Isn’t this the way we see software develop and evolve?

Why do we strive so hard for architecture, when gardening will serve better?

I’ve just had this thought tonight. I’ve no idea of its validity or shortcomings. Perhaps this will open a discussion. Perhaps that discussion will begin with a link that describes this in much greater detail. Perhaps someone will point out that Agile/NOOO/Reactive Manifestos address these very points. Perhaps. I still think that perhaps we need an alternative to “architecture.”

Why F#?

I’ve often been asked to answer the questions, “Why F#? Why is it important?” I struggle to answer this question. I don’t really understand it. Part of the problem is that I try to provide an answer. These questions cannot be answered without first understanding why the questioner likes or enjoys his or her current tool chain. So, if you are curious about why someone might want to use F# and don’t want a stream of unique language features, please comment and tell me why you like what you use today. I would really like to know. I really want to be able to help you find an answer because I think F# has a lot of great benefits for everyone.

I also realized that this question is hard because I don’t have another story. I came to .NET from writing a lot of VBA, PHP, Ruby, and JavaScript. I lucked out in coming to C# when .NET 3.5 was just released. While I find C# (and VB.NET for that matter) very useful languages for building applications, I never had a love for them. I did love LINQ, so I naturally fell in love with F# because of its similarities to LINQ and terse, Python-like syntax. However, these are not reasons for choosing a language.

Ultimately, I use F# because I think about problems in such a way that F# is a natural expression of my thoughts. I have rarely released any production software written in F#, but I nearly always prototype ideas in F# before translating to C# in my projects. I find the translation to C# takes additional thought processes that get in my way when trying to solve the original problem, so this works for me. I could easily push the F# into my apps; I don’t simply because most of my clients want to maintain C# codebases. As I mentioned above, C# is a great language and very useful for building applications.

I know many people who think F# is interesting but don’t write it. I think the hurdle is simply a paradigm shift. Much like paradigm puzzles, you typically have to have someone show you or walk you through the paradigms. Once you understand it, you have a hard time trying to remember how you didn’t understand it before. For that reason, I recommend you find a local F# user group or join the Community for F# for an online meet up. Visual F# MVP Mathias Brandewinder spent his summer traveling around hosting machine learning dojos, and those really help people through the necessary paradigms. If he comes through your area, definitely join in, even if you don’t think you care about F#.

Visual C# MVP Bryan Hunter has often commented that just knowing multiple languages helps you write better code and understand how to best and most simply solve problems. He’s right. Don’t stop at F#. Try other languages outside of .NET such as Erlang, Clojure, JavaScript, and other languages and platforms unlike your own. You will never regret the lessons you learn and will usually find new, simpler ways to solve problems.

Production vs. Consumption

I recently started listening to The Limits of Power and found a striking revelation regarding the Open Source community. In an early part of the book, Bacevich recounts President Jimmy Carter’s comments on a crisis facing the nation that was ignored and culminated, at least to some degree, in our present debt crisis. He highlighted the shift from the production-oriented culture of the years before Vietnam to the consumption-oriented culture we have today.

An exception I see lies within the Open Source community. In OSS, we create, share, help, and produce quality, assisting one another in our efforts. Those in OSS spend a lot of their free time producing. I’m sure many of us consume quite a lot, as well, but we all share a spirit of productivity that at least some part of the US culture has lost.

Why? Is the IT industry so different? Is it just so new that so much opportunity abounds? I don’t think so, but I have not engaged heavily in other industries outside of plying my trade to help them. Perhaps we hold the keys to the realms of innovation?

Regardless, I celebrate OSS and its community for their ability to rise above mere consumption and produce. Well done!