How to Build HTML Helpers like Html.BeginForm() in ASP.NET MVC

If you’ve used ASP.NET MVC for more than five minutes, you’ve probably used the Html.BeginForm helper method.

@using (Html.BeginForm()) {
// Form Fields go here

This method wraps your content in a form tag. It’s a handy way to build forms, but we can also create our own html helpers for other container elements. In this post, I’m going to show you how to wrap a Bootstrap row in an HTML helper.

Bootstrap, the UI library that comes with .NET, makes it easy to build professional looking web applications. One of it’s primary disadvantages, however, is that you have to write a lot of markup to get your layouts to work correctly. We can reduce this by creating a custom HTML Helper that works like Html.BeginForm().

@using (Html.BeginRow()) {
// Grid content goes here

Step 1

Create a Private Class that implements IDisposable. Have the constructor take a TextWriter object. Set the dispose method to use the text writer to output the closing tag for the row.

private class RowContainer : IDisposable {
    private readonly TextWriter _writer;

    public RowContainer(TextWriter writer) {
        _writer = writer;

    public void Dispose()

Step 2:

Create an HTML helper extenstion method that creates the beginning tag and returns the object created in Step 1. You can use ViewContext.Writer to directly output the markup.

public static IDisposable BeginRow(this IHtmlHelper htmlHelper, string cssClass = "") {
    var writer = htmlHelper.ViewContext.Writer;
    writer.WriteLine(string.Format("<div class='row{0}'>", cssClass));
    return new RowContainer(writer);

Step 3

Use the helper in your Razor view with a using statement, just like BeginForm(). When the using statement disposes the returned object, it’ll close out the tag.

@using (Html.BeginForm()) {
// Form Fields go here

Additional Information

Full Code

How the Monty Hall Problem Can Make You a Better Software Developer

Being called the smartest person in the world makes you huge target for trolls. Marilyn vos Savant was listed in the Guinness Book of World Records under “Highest IQ”. This propelled her into the national spotlight. She then proved that IQ doesn’t mean everything by becoming columnist for Parade. The listing also made her a popular target of criticism, especially by academics. There are whole websites devoted to proving her wrong. This is not one of them. This is a story about how she was right and what we, as software developers, can learn from her experience.

How to Play “Let’s Make a Deal”

The Monty Hall problem is a famous math problem that’s based on an old game show called “Let’s Make a Deal”. The game begins with three doors. One of the doors has a fabulous prize. You don’t know what’s behind any of the doors and each door has an equal chance of containing the prize. You are then asked to select a door. After selecting your door, the host of the show reveals one of the other losing doors. You are then given the option to switch.

The question is:

Would switching doors give you a better chance of winning the prize?

The intuitive answer is that switching doors provides no benefit. Remove one door and your 1 in 3 chance becomes a 1 in 2 chance of winning. Since each door has an equal chance of being correct, the remaining door isn’t any better than the one you picked. This is the answer most people come up with when they first hear this problem.

This logic, while intuitive, is flat wrong.

The correct answer is that switching gives you a 2/3 chance of winning, as opposed to your 1/3 chance you have sticking with your door. The key to this problem is that revealing one of the incorrect doors doesn’t change the initial probability. You already know one of the doors is going to be wrong. What is important is that the host is basically giving you the option to select two doors instead of one.

Here’s another way to think about it. Switching and losing means that your initial selection was the right one. Your probability of winning with your initial selection is 1/3. Thus, the probability of you losing when you switch is 1/3, which means your probability of winning is 2/3.

If you still don’t believe me, the Khan Academy explains this problem well:

The Time the Smartest Person in the World Got Flamed by Everyone

Marylin vos Savant answered this same question in her column in 1990. Even though she was correct, the public sent her a truckload of hate mail. Many academics also piled on the criticism.

Here’s a sample of the feedback she received (Source):

Since you seem to enjoy coming straight to the point, I’ll do the same. You blew it! Let me explain. If one door is shown to be a loser, that information changes the probability of either remaining choice, neither of which has any reason to be more likely, to 1/2. As a professional mathematician, I’m very concerned with the general public’s lack of mathematical skills. Please help by confessing your error and in the future being more careful.

Robert Sachs, Ph.D.
George Mason University

May I suggest that you obtain and refer to a standard textbook on probability before you try to answer a question of this type again?

Charles Reid, Ph.D.
University of Florida

And my personal favorite:

You made a mistake, but look at the positive side. If all those Ph.D.’s were wrong, the country would be in some very serious trouble.

Everett Harman, Ph.D.
U.S. Army Research Institute

It took Marylin several tries to explain the concept well enough for the majority of her readers to understand it. I found her explanation to be clunky, so I posed the problem to my Facebook friends. What resulted was the longest comment string I’ve had in a long time. My friends, several of whom have advanced degrees, had a tough time with the problem. The people who knew the correct answer had a tough time explaining it to the doubters.

What can this story teach us about building better software?

There are several lessons this story can teach us about psychology, thinking things through, and humility.

1. People are bad at estimating risk

This story illustrates that people are not good at understanding probability. There’s a whole slew of cognitive biases (brain fails) related to estimating probability.

List of Cognitive Biases

This is important to software development because much of what we do is estimate and mitigate risk. For example, mitigating security risks is incredibly important. Due to our inability to measure risk well, we may spend resources fixing low risk problems that were recently featured in the news instead of fixing high risk issues.

Risk also factors into software estimation. People are terrible at estimating how long it takes to do anything over a day. This is why agile software projects measure tasks using relative complexity (story points, T-shirt sizes, etc…) instead of hours. Agile projects also break down work into bite sized pieces, which are easier to comprehend.

2. Watch out for red herrings

Another important aspect of software development is filtering out irrelevant information. In the Monty Hall problem, the host opening the losing door doesn’t change the probability. You already knew one of the doors was a losing door. I find that it’s important to remember this when I’m debugging code. Good testers tend to report more information than you need and it’s up to you to figure out what’s useful and what’s not.

3. Be skeptical of “experts”

Many of Marylin’s critics were highly educated. All three of the quotations I mentioned were from PhD’s, including one professional mathematician. In our society, we tend to take the opinion of experts at face value. Pew Research recently did a survey on the beliefs of scientists vs the beliefs of the public. (link) This survey was widely reported on.

While the opinion of experts is vital, remember that they specialize in narrow areas. Any opinions they have outside of those areas should be subject to the same scrutiny that you give any smart person. Too often, people who are experts in one area are considered experts in other areas as well. A good example of this is when the media asks famous actors about their opinions on political issues. The tendency to allow irrelevant traits, such as beauty or skill in an unrelated field, to effect our judgement someone’s ability is called the halo effect.

You can use the halo effect to your advantage. Dressing sharp and being a good conversationalist can increase your credibility. While it’s acceptable to go a tech conference in a t-shirt and jeans, people will think you are more professional if you wear something nice.

The halo effect also applies to software. In the book Emotional Design, Don Norman explains how people find aesthetically pleasing objects to be more effective. When building your own software applications, pay attention to the design of the interface. Making things look good will make your software appear to be more useful.

4. Don’t be mean.

When doling out criticism, be nice. It hurts a lot less if you’re later proven wrong. This doesn’t mean you should sugar coat things, but you can deliver sharp criticism without being mean about it. Many of the people who wrote in nasty comments ended up apologizing for it once they realized their mistake.


The story of Marilin vos Savant and the Monty Hall problem has many lessons for software developers. If you want to learn more about the topics in this post, check out the resources below.

Khan Adademy: Monty Hall Problem
Maylin vos Savant: Game Show Problem
List of Cognitive Biases
The Availability Heuristic
The Halo Effect
Emotional Design (Amazon)

Legacy Systems, Legacy Thoughts

There’s nothing like replacing a legacy software system to stoke the fires of self-righteousness. You get to pull some poor users out of the dark ages and save them from a system may have been state of the art last decade, but is junk now. (Ignoring the fact that the old system lasted that long because it did what it what the users wanted it to do.) It’s especially fun when the old system is so laughably bad that it was obsolete the day it was written. Unfortunately, these projects come with a few pitfalls.

The first pitfall is that you can end up building the same legacy system in a new technology. It’s hard to transfer old paradigms into new ones and if you’re not careful, you can end up repeating old mistakes. I worked at a company that was creating an ASP.NET web app built over an existing database. Many of the tables in this database had no keys or relational data. The original system was built on a mainframe using flat files. When that system was upgraded in the 90’s, the flat files were just copied over. There was no regard to modern relational database structuring. When the ASP.NET version came along, the plan was to just copy over each of the old pages, one by one. Management didn’t take modern web and object oriented practices into consideration. Needless to say there was some debate between the developers and management.

The second pitfall can come while gathering requirements. When gathering requirements for the new system, it’s easy (and often correct) to reference the old system. There are two problems using the old system as the primary reference for requirements. First, the system sometimes does things a certain way because of technical constraints. I once worked on replacing a system that had lots of batch processes. Many of those processes were not needed because modern systems were fast enough to process those records on the fly. Second, many times, old systems don’t reflect the business practices of people who use them. There are lots of instances where users have to do something convoluted to get their old system to behave how they need it to. Watch out for these types of scenarios, fixing them is a good way to score brownie points with your customers.

The third pitfall happens when the builders of the new system don’t recognize the advantages of the old system. In the system I mentioned in the first point, the legacy system allowed for rapid keyboard entry. The new system, being a web application, did not optimize for keyboard entry. In the beginning, the developers ignored the users because of the “obvious” superiority of the new way of doing things. Eventually, we realized our error and created a keyboard entry optimized set of web controls. The users were much happier. While it may be fun to mock the old system, you should also pay attention to your users and make sure you aren’t creating a system that’s worse than what they started with. Just because it’s pretty and new doesn’t mean it’s good for the customer.

In summary:
1. Make sure your new system is using new paradigms. Don’t repeat legacy design.
2. Be careful when gathering requirements from the old system. Especially when it comes to implementation details.
3. Don’t make a new system that’s worse than the system you’re replacing.

How I Build Tech Talks: Part 1

How I Build Tech Talks: Part 1

Last year, I created my first tech talk and delivered it to several venues. I enjoyed the experience, so I decided to produce a new talk this year. This time though, I want to document the process of building the talk while I’m working on it. I think it’s important to see things unfold while they happen. Often, you see a polished talk and you don’t see the work that has gone into it. This isn’t meant to be a list of recommendations from on high, but a log of how I like to build talks. Feel free to use what works and forget what doesn’t.


Last year, I gave two versions of my D3.js talk in five different venues. I’ve also delivered several talks at work. Additionally, I did speech and debate in college for two years. While I’m no Scott Hanselman, I know my way around a lectern.

Step 1: Topic selection

Last year, I picked a topic I didn’t know much about (D3.js). I picked that topic because I knew building a talk would force me to learn about it. This year, I want to deepen my understanding of a topic I have experience with. I work with ASP.NET MVC in my current job. Additionally, I enjoy building UI components. When I started using ASP.NET MVC a few years ago, I had a hard time finding information. The books on MVC cover the basics well, but the reference material is incomplete. (Example) Doing a talk on building UI in ASP.NET MVC would deepen my own knowledge while helping others.

Building UI in ASP.NET MVC is a broad topic, so I drafted a list of subtopics to help me narrow my scope down.

Here’s my, clustered into similar topics:

HTML Helpers
Editor and Display Templates
Custom Validation

Grunt / JS automation
Bundling and Minification

Web Performance

UI Testing (like Selenium)
JavaScript Testing (like QUnit)

That’s way too many things for an hour long talk. Each of the above clusters could be it’s own talk. To narrow the scope, I’m going to remove anything that doesn’t have to do with building UI components. This leaves me with the following list:

HTML Helpers
Editor and Display Templates
Custom Validation

Step 2: Generate a Theme

Now that I have a topic list, I want to create a theme for the talk. A theme gives structure to the talk and provides a narrative for people to latch on to. I believe that in software development, you should bake good defaults into easy to use components. This lowers the cost of development and increases the quality. Good components allow you to create a great user experience without having to drop a ton of code on each page. My theme for this talk is going to be how to build better software in less time.

Another thing I’m trying to do with this talk is build in more stories. Stories are one of the primary ways people communicate. Studies show that stories engage emotions, which provides a stronger connection than raw data.

Step 3: Generate an Abstract

The next step is generating an abstract. An abstract is a summary of you talk that you can submit to conferences and user groups. It’s important to have a strong abstract because that’s how your talk is picked by conference organizers.

Keys to a Good Abstract

  1. A catchy title.
  2. A clear benefit to the audience.
  3. A summary of the topic.

Here’s my abstract:

ASP.NET MVC UI Recipes: Build Better Interfaces With Less Code

Who doesn’t want to get more done in less time?

ASP.NET MVC gives us an excellent toolset for building web applications. Unfortunately, due to it’s rapid evolution, good documentation is hard to find. However, using some simple techniques, you can build user interface components that can speed up development while maintaining a clear separation of concerns. In this presentation, we’ll learn how to build custom controls, templates, and custom validation. Save time while creating cleaner code.

Step 4: Make An Outline

The next step is building an outline. I don’t memorize my speeches, so the outline is what I study when I prepare. I use my outline to put my topics and demos into a logical structure. I tend to capture a lot of detail in my outlines and then make a simpler outline for reference. I haven’t finished my outline yet, so I’m not going to share it.


This is the first in a series of blog posts documenting my process for building tech talks. As I mentioned before, feel free to use what works and forget what doesn’t.

Telling Stories With Data and D3.js (Video)

If you missed out on my D3.js talk from last year, the fine people at MadJs recorded it.

Psychology for Software Developers: Dunning-Kruger Effect

The more I learn about software development, the more I notice the things I don’t know. Each tactic I pick up or lesson I learn just leads to more questions. It’s like lighting a candle in the dark and realizing that you’re in a room full of doors. Then, as you open each door and turn on the light, you find more rooms to explore. When I started out, I was so sure of myself. Each problem had the “one right way” solution. Now, when I see a problem, I see several imperfect solutions, each with their own trade offs.

This seems like a common problem.

John Sonmez feels the same way:
Simple Programmer: The More I Know, the Less I Know

So does Scott Hanselman:
I’m a Phony. Are You?

They aren’t the only ones either.

Psychologists call this the Dunning–Kruger Effect.

The Dunning-Kruger Effect is when unskilled people overestimate their abilities and skilled people underestimate their abilities. As you become better at something, you realize how little you know. It’s like getting to the top of the mountain only to find that you are at the bottom of a way bigger mountain. It sucks.

This concept has huge implications in software development. Software development is a complex field filled with people who have strong opinions. This creates situations where confident, unskilled people have an advantage when determining technical direction. This can lead to poor choices and technical debt. It’s easy to trust someone who’s confident over someone who isn’t sure of the right answer. Even when not being sure of there is a right answer is the right answer. (This explains most of politics, but I digress…)

What can we do to counter this effect during technical discussions?

If you’re unsure of yourself, don’t be afraid to present the facts and make your case anyway. It’s better to be wrong than to allow bad ideas into your project. You probably know more than you think.

If you’re confident of a particular solution, look for alternative view points. Let the other side make their case. Realize that the person who has a few years of experience on you may know something you don’t. Even if they have trouble articulating that knowledge, it’s your responsibility to listen. You may learn something.

If you’re a manager trying to decide between two viewpoints, don’t let the louder person automatically win. It’s easy to side with people who are confident or articulate, but it’s important to hear out both sides.

What about when you’re just feeling unskilled?

For me, the best way to feel competent is to write code. The code doesn’t care how smart you feel that day. If it works, you win. For me, adding value makes me feel competent. If I can pull off some complex functionality or learn something new, I feel like I know what I’m doing.

OR/M Pain: Maybe Stored Procedures Aren’t So Bad

When I first started using OR/M, I looked forward to not writing boilerplate SQL code. As a lazy developer, I prefer to automate boilerplate code generation. After using OR/M for couple of years, I am beginning to miss stored procedures. OR/Ms like Entity Framework reduce the need for cookie cutter code, but they have some major flaws.

The first flaw is that OR/Ms are a leaky abstraction. The goal of any abstraction is to hide the internals of the thing you are trying to abstract. OR/Ms fail at this. Entity Framework, the OR/M I use the most, falls down on complex queries. For example, if you want to join in a related entity, you can use the Include() statement. The problem with Include() is that it generates horrendous queries that have terrible performance. You can’t do more than three or four includes in a single query. You end up having to either do a bunch of small queries or build a stored procedure. This defeats the purpose of OR/M.

The second flaw is that configuring complex relationships can be painful. I’ve used nHibernate (Fluent API) and Entity Framework (Code First,). Configuration in both OR/Ms is painful. I have spent hours trying to configure a particular database relationship. I’ve done small model changes generate migration scripts that left me scratching my head. One major advantage of Entity Framework is that the documentation is excellent. MSDN does a good job of highlighting common configurations, and there’s lots of information on the web.

The final flaw of OR/M is that you lose the ability to use a lot of features of the database. For example, until recently, you couldn’t create a unique key in Entity Framework. Entity Framework still doesn’t support database triggers. You can live without these features, but it does limit what you can do with OR/M.

This leads us to the obvious question:

Are OR/Ms a waste of time?

The answer, of course, is “umm… maybe”.

If you have a project with a simple data model or low performance requirements, OR/Ms will save you time. If your project is more complex, then you should consider skipping the OR/M. There’s nothing wrong with using stored procedures. Sometimes the old ways are the best ways.

More on OR/M Pain:
Bendyworks: Actually Using the Database ORM is an anti-pattern

Building Antifragile Software

Software developers spend most of their time taming chaos into orderly systems. Along the way, there’s often lots of random issues that can throw you off track. Heavy processes like waterfall development sought to eliminate as much risk as possible. Unfortunately, this risk avoidance often lead to lots of pain at the end of a project. After several decades of failure, we now use agile practices that expect chaos. Dealing with chaos and risk are important for anyone who builds software for a living.

I recently read Antifragile by Nassim Nicholas Taleb. Antifragile is one of those books that changes how you see the world. Once you understand the concept of antifragility, it becomes a useful analytic tool. As a software developer, I started thinking about how to build less fragile software.


Antifragile is about how some things become better when exposed to volatility. For example, when you lift a heavy weight, your body makes itself stronger. It becomes stronger in response to stress. Additionally, if you never exercise, your body becomes weak. The human body needs some stress to be healthy. The author talks about three different states.


Fragile things suffer from volatility. Think of a teacup. If you drop it, it will break. Fragile things tend to be rigid and over-optimized. Think of a complex code base with lots of dependencies. One small change can cause the whole system to come crashing down. Systems that are fragile tend to suffer from a small number of devastating events.


Resilient things are indifferent to volatility. Think of a rock. If you drop it, nothing happens. Resiliency can come from redundancy or structural integrity. Think of a well structured code base with lots of automated tests. Failures are generally caught and corrected for before they can cause a problem. Many of the principles of software development revolve around building resilient software programs.


Some systems go a step beyond resiliency and become antifragile. Antifragile things actually gain with disorder (up to a point). Changes are generally frequent and have a small impact. Free market economies are a good example of antifragile systems. Individual businesses are fragile, but the system is strong because the best businesses survive. Evolution is another example of an antifragile system. Individuals of a species can die, but the best adapted animals get to reproduce. This causes the species as a whole to get stronger with volatility.

Other summaries of Antifragile

Art of Manliness – Beyond “Sissy” Resilience: On Becoming Antifragile


So how does this help us make better software?

There are lots of software development practices that captialize on chaos. The key is to use frequent failures as learning expiriences. Here are some examples:

Agile Software Development

Agile processes revolve around building software in tight iterations with frequent customer feedback. Frequent exposure to criticism reduces the impact of criticism. It also allows you to gather more accurate information about what the users want. Additionally, your process continually improves, which means your team becomes more effective over time. This is in contrast to waterfall processes that front-load understanding and are fragile. One mistake in understanding can have a large and painful impact in waterfall projects.

Frequent releases / Continuous Integration

If you do hard things frequently, like releasing software, they become easier. A frequent release cycle breeds processes that make deployment easy and reversible. Continuous integration allows companies like Facebook to push several updates a day. This gives them a huge advantage over slower companies.

Chaos Monkey

The chaos monkey is a process build by engineers at Netflix. It is a program that randomly breaks processes. The introduced chaos allows developers handle problems in a controlled way. It also encourages resilient design in the first place. Contrast this to companies that avoid chaos. Random failures occur at inconvenient times and the fix is likely to consist of bubblegum and duct tape.

More Info:

Minimum Viable Product

A minimum viable product is a small product used to test the market. Because the product is cheap to build, you can run many iterations. Each iteration allows you to learn more about your potential customers. These experiments allow companies to find profitable products quickly. This process allows smaller companies to exploit market situations that bigger companies cannot.


The world of software development is chaotic. We should not fear the chaos, but instead build systems that capitalize on it. Modern software development practices expect change and use it to create better software. Using these processes, we can build software that isn’t just resilient, but is also antifragile.

If you’re interested in learning more, check out Antifragile

Book Review: Soft Skills by John Sonmez

Have you ever wished that you had a manual for how to live the good life? A guidebook that will tell you how to make the best decisions. I certainly do. John Sonmez has taken a crack at this task with his latest book, Soft Skills: The Software Developers Life Manual.


The core premise of Soft Skills is that being a good software developer starts with being a good person. By “good”, I mean someone who has their life under control, makes good life decisions, and can achieve their goals.

Soft Skills is a book about a lot of things. It covers general career skills, like interviewing, setting career direction, and marketing yourself. It also covers skills that increase your job performance, like learning and productivity. Additionally, it covers general life skills, like managing your finances and fitness (mental and physical). Soft Skills reads like a summary of many of the top business and self help books.

While the book covers many topics, it does so in bite sized pieces. Chapters run around 5-10 pages each, so it’s easy to read and reference. Since most of the topics stand alone, it’s also easy to skip around and focus on the topics that interest you the most.


These are a few concepts from the book that I found useful.

Business Mindset

Instead of having an employee mentality, software developers should treat themselves as a business. Their primary asset is their ability to produce working software. Adopting this mindset makes it easier to think clearly about career choices and gives you a sense of autonomy. Like any other business, you must invest in improving your assets (aka. human capital), and market your skills.

Career Direction

Software developers have three routes for advancement, each with advantages and disadvantages. This book dissuaded me from considering freelancing as a future career goal. The routes are:

  • Employment – High stability, but lower income and lower freedom.
  • Freelance – More freedom and money, but also more hassle and risk.
  • Entrepreneur – High risk, but near infinite upside on rewards and lots of freedom.

Personal Marketing

Marketing is multiplier that can catapult your career into the stratosphere. You marketing yourself by helping out your fellow developers. You can do this in a vareity of ways, including writing, speaking at conferences, and making videos.


The finance information in this book is great. John “retired” at age 33, so you know he’s doing something right. I enjoyed reading about the ups and downs on his journey to financial independence. He covers a variety of topics, from general finance to the different types of investments.


One of my favorite things about John Sonmez, whether it’s his books or his videos, is his attitude. John is upbeat and pragmatic. He doesn’t believe in zealotry, which is something that plagues our industry.

Who’s this book good for?

This is a good reference book for any software developer. People who are early in their careers will derive the most benefit, but it’s a good book even you’re a few years into your career. I wish I had this book about eight years ago when I was graduating college. If you are well read in the topics the book covers, you may find the content a little shallow, but I’m happy with my purchase.

Soft Skills (Amazon) (Manning)
The author’s web site: Simple Programmer

Navigating the Mobile Development Landscape – September 2014

Smartphone and tablet adoption has exploded in the past five years. This trend has encouraged me to start exploring mobile development technologies. I found that there are lots of ways to build apps for mobile devices. Several mobile development technologies leverage my current web development skills. I’m going to cover the four primary ways to build mobile applications.

1. Responsive Design

The easiest way for a web developer to get started in mobile development is to build mobile-friendly web applications. You can build web applications that work on most screens by applying CSS tactics like media queries and relative sizing. Front end frameworks like Bootstrap and Foundation make it easy to build responsive web apps. Responsive design should be the default for any new web application. You never know when someone is going to try to browse your app with their Internet enabled toaster.

Responsive design is great because it has the flattest learning curve for a web developer. The other huge advantage is that you don’t need to build a separate app for each platform.

Unfortunately, building a mobile web app means you have to design for the lowest common denominator. You don’t get access to the platform specific features like a native app. You also have to deal with network issues and browser quirks. Additionally, most people on mobile devices prefer to use apps instead of their web browser.


2. Hybrid Application

Hybrid applications are another way to use existing web skills to build mobile apps. You develop hybrid apps using standard web technologies like CSS, JS, and HTML5. They have some access to platform specific features via JavaScript apis. Unlike pure web applications, hybrid apps can be sold in app stores alongside native apps.

At first glance, hybrid development sounds like a great deal. A single code base that can be used on all the major mobile platforms and still have access to platform specific functionality. The people who make hybrid application platforms claim that hybrid apps compose the majority of top apps in the app store.

Unfortunately, there are serious flaws to the hybrid development model. The first is that hybrid apps are much slower than their native counterparts. Performance is better than a few years ago, but hybrid apps are never going to be as performant as native apps. Additionally, hybrid apps don’t behave like other native apps. There are lots of transition effects and other native behaviors that are hard to replicate in a hybrid app.


3. Xamarin

The Xamarin platform offers the ability to build cross platform mobile applications using C#. With Xamarin, you build the user interface for each platform using C# wrappers for native libraries. You can then use shared libraries for all the core business functionality. Xamarin claims that you can have up to 95% code reuse on their platform.

Xamarin is great for .NET developers who want to build mobile apps because using tools they are familiar with. You can get near native performance and significant code reuse between platforms.

Xamarin is not perfect though. Xamarin is expensive and it comes with a steep learning curve. Not only do you need to learn the APIs for each mobile platform, you also need to learn Xamarin.


4. Native Applications

The final, and most obvious option, is to build separate apps for each native platform you wish to support. While its inconvenient to have to build separate apps, going 100% native has some advantages. First, each app will have a native look and feel without having to resort to outside libraries. Second, pure native development offers the best performance. Finally, all the major native app platforms have great references and development resources. There will be better support and more open source code for native developers than any of the hybrid platforms.



I’ve spent a lot of time reading about different mobile development options. Additionally, I watched demos of several different mobile development plaforms. (Specifically, native Android, Window, and iOS developement, several Xamarin demos, and Telerik’s App Builder.) Based on that experience, I’m going to focus on mobile web applications and native development. Mobile web applications leverage my current skills as a web developer. I also think the mobile web option will become more popular as mobile web browsers get better. Hybrid development looks promising, but based on what I’ve learned, it’s a “good enough” solution at best. Native development provides the best user experience and is a prerequisite to “combination” platforms like Xamarin. Overall, there’s no shortage of ways to build a mobile app.