<< Comment the class before coding it | Implement micro formats on your website >>

Think twice before using any third-party assemblies

by Mads Kristensen 13. June 2007 05:09

A lot of people have asked me why we don't use third-party assemblies in BlogEngine.NET, so I thought it was about time to explain why.

One of the most important rules that I laid down before starting on the BlogEngine.NET project, was that no third-party assemblies were allowed. This rule was forged out of the assumption that most of these assemblies did a whole lot when only a little bit was needed for BlogEngine.NET, and that little bit was easy to write our selves.

It’s obvious that it would take longer to write the code instead of just referencing the assemblies, but it was worth the extra effort. BlogEngine.NET is build for .NET developers so my initial thought was that they wanted to be able to change every little thing they wanted to suit their needs. Third-party, precompiled assemblies doesn’t allow for easy customization so that would counter the .NET developers needs. That has a big part in why BlogEngine.NET is so open and simple to customize

If you look at most other .NET blog and CMS platforms in existence today, you’ll see that they make heavy use of various third-party assemblies. All of the assemblies and libraries are open source or at least free of charge and they are all very powerful and easy to use. However, the decision has been made so we had to come up with alternatives to the libraries and that proved surprisingly effortless for our simple needs.

What we didn’t use

Web control libraries
There are many web control libraries that offer date-time pickers, special grids etc. that we could have used, but let’s face it. A date-time picker is just a JavaScript representation of the already existing ASP.NET Calendar control with some AJAX functionality. Other controls can be much harder to write yourself but we didn’t need them.

XML-RPC.NET
It’s a very cool library for handling trackbacks and pingbacks and pinging Technorati, Feedburner etc. when new posts are created. It does much more than that, but these features were the ones we needed. XML-RPC is standard XML that can be parsed and XPath’ed so why did we need a third-party library for handling XML?

Rich text editor
I’m a big fan of both FreeTextBox and FCKeditor which I’ve used in many projects over the years. They each have their advantages and can be extended and modified fairly easy. So can tinyMCE and it is purely JavaScript, so that’s what we decided to use. There were other reasons as well, such as almost perfect XHTML generation and other minor factors. Well, and of course the fact that it’s JavaScript so we can change whatever we want.

HTTP compression
There are quite a few compression libraries that can gzip or deflate the HTTP response stream. Instead we used the build in compression classes in the CLR and wrote a single HttpModule to do the job.

CAPTCHA controls
There exists hundreds of CAPTCHA control libraries for ASP.NET both visible and invisible ones. However, a CAPTCHA is one of the simplest things to write – it takes only 20 lines of code to create a rock solid invisible one – so that’s what we did.

As you can see, we did a lot of reinventing for BlogEngine.NET, but it actually wasn’t that big a deal.

In the enterprise

For enterprise projects where third-party dependencies can be costly, it would be beneficial to be sure what the needs are and if they can be built instead of bought. You should also weigh the value of owning the code instead of using third-parties. It various from project to project and from library to library, but one thing remain the same: third-party dependencies is not as flexible as building your own implementations.

The hobby project

Most hobby projects start when you get an idea and want to realize it real quick. Then you don’t want to do much reinventing because that would just slow you down and your code is probably not essential either. In those cases I would use as many third-party libraries as possible to get the code running and my project realized.

Think twice

There are many factors to consider before using third-party libraries and some demands real thought. You have to be real careful about using third-party libraries for essential components, because then you loose control of the most important parts of your application. For BlogEngine.NET we also had to consider our target group - the developers.

If you base your business/application on a component provided by third-party, you might want to think twice.

* Only $4.95/month ASP.NET & Windows 2008 + IIS 7 Hosting! FREE SQL Included

95574ee1-cdd5-4540-97c4-54bfd01f5ea4|13|4.1

Tags: blogengine, simplicity

BlogEngine | Random thoughts

Refactor the code before you write it Have you ever heard the saying “If you don’t know where to look, don’t look at all”? Think ...Comment the class before coding itTurn your small home project into well architected pieces and save time.Validate a form before submitting it in ASP.NETShows how to run ASP.NET validators client-side without hitting the submit button

Comments

6/13/2007 12:25:43 PM #

This is very interesting read and I agree. However for the MetaBlogApi support you might want to consider using the xml-rpc.net - at least for us (umbraco) it simplified the development a lot.

hartvig |

6/13/2007 3:03:09 PM #

Niels, we already implemented all the XML-RPC calls our selves and it was very straight forward. If you can use the XmlTextWriter and XPath, then you can build your own implementation.

Mads Kristensen |

6/13/2007 3:51:03 PM #

Trackback from DotNetKicks.com

Think twice before using any third-party assemblies

DotNetKicks.com |

6/13/2007 4:13:13 PM #

Interested to see the use of the phrase 'Third-party, pre-compiled assemblies' - where should one logically draw the line - for example an open source assembly that has source code available for it or one of the JavaScript libraries such as Prototype or similar. Is the distinction one of being able to see what the code holds and being able to modify it ...

DavidMiles |

6/13/2007 4:32:53 PM #

That's true David, but not all free third-party assemblies are open source. The importance is that you are able to modify it easily if you want to and that is not always the case. Even if it is open source, it is still not as easy to modify as if it was part of the main project. Coding styles are different, it might not be well commented or documented and it might be written in another language.

Mads Kristensen |

6/13/2007 8:49:47 PM #

Good point.
I find very interesting how software developers are very interested in refactoring to make their software more maintenable but at the same time don't consider third party libraries as a dependency.

People think that using a external library free them of wasting time in some functionality, and it's false. You have first to learn the interface and usage, then discover the limitations for your current project and how to resolve them, and then maintain that dependency during the life of the project updating to new versions and so on.

Dan |

6/14/2007 12:51:23 AM #

I couldn't have said it better myself.

Chris Pietschmann |

6/14/2007 1:25:25 AM #

I do agree that using third-party assemblies is not always a good idea, but they do help you create a lot of code very, very fast. Often, the code has even been thoroughly testet, which means that not only do you save time developing, you also save time testing.

I write a lot of code that has a life span of maybe 1-2 years, and it would be really silly to spend two or three days programming and testing, when an assembly can get the job done in 30 minutes.

The point is, of course, to use the assemblies carefully and intentionally, since they can be huge relief and make twice as productive as you would be without them.

Jesper |

6/15/2007 12:37:07 PM #

@Dan: Regarding "People think that using a external library free them of wasting time in some functionality, and it's false. You have first to learn the interface and usage, then discover the limitations for your current project" I think that's a very general statement

The real answer must be, it depends. When I said that the XML-RPC.Net assembly helped us, it was simply because it was a done, well-tested managed wrapper around an existing laid-down specification. Making our own wrapper - even though it's a pretty fast and trivial task - wouldn't give us any benefits of choosing an existing, light-weight, throughly tested solution with a very liberal license (MIT). The spec wouldn't change and choosing XML-RPC made it possible for us to focus on improving the core product rather than spending time developing and testing a proxy.

hartvig |

6/15/2007 11:49:28 PM #

Yeah I know, my english limitations bring to confussion.
I mean, Scott Hanselman wrote a post yesterday with guidelines for projects, and one guideline was "never reinvent the wheel"
So if you can't reinvent the wheel, you are obliged to use a third party library ? It's no sense, you can end with a blog engine that has an o/r mapper, MS Ajax Library, MS Enterprise Library, some dependency injection container, MetaWeblog library, no-spam library, gravatar library, log4net, ...
So like Mads say think twice before using it, libraries are very useful indeed but if you only need asynchronous javascript for sending a comment you can live without microsoft ajax.

Dan |

6/17/2007 9:20:41 AM #

Pingback from brennan.offwhite.net

Brennan’s Blog » Blog Archive » Using Third Party Assemblies

brennan.offwhite.net |

6/19/2007 4:49:56 PM #

You might be taking your "thinking twice" a bit too far when you ignore a library like XML-RPC.Net, when XML-RPC support is needed, and you then proceed to write a 1000 or two lines of code to implement XML-RPC. Sacrificing a thorough implementation of the specification in favor of a lesser, mishmash of "as needed features" doesn't strike me as the greatest of ideas.

chrixian |

6/19/2007 5:35:25 PM #

chrixian, I didn't need to write 1-2000 lines of code to do XML-RPC. Only around 100. That illustrates my point perfectly I think.

Mads Kristensen |

6/20/2007 8:11:21 PM #

I don't agree:
if you want to build sw for business, you want to focus on the real business content, not spending 50% of the time building your own logging engine, or SOAP parser, or ORM.
But if you want to build sw for fun, then maybe it's just because you want to spend time learning, so it's good to build something yourself.
Anyway, I think that lately on the .NET community we are seeing to much people with the NotInventedHere approach.

Simone |

6/21/2007 12:47:40 AM #

Simone, of course you want to focus on the business and of course you don't want to spend 50% of the time reinventing the wheel, but each project must have a balance. It's the balance that is key, because you also don't want to put your entire business model in the hands of third-party vendors, but only the parts where it makes sense.

Mads Kristensen |

6/21/2007 6:46:32 AM #

Yep, but developers, especially young ones or opensource tend to reinvent the wheel way too much, and this post I think can be misinterpreted.

PS: posting using my current Kiwi identity now