Friday, December 4, 2009

ASP.NET WebForms vs Spark View Engine. Part 1


There is no "the best", "one fits all" engine, framework or something else. I didn't try to choose the best, I just tried to investigate the possibilities to have them in mind for line of the upcoming projects and to have a possibility to choose between them depending on the requirements.
Also, I’m not a guru in both engines, I had just made a surface comparison and appreciate any comments, fixes and additions!


It is always good to have a choice, a possibility to choose between different technologies, frameworks, engines etc. I like ASP.NET MVC because it allows me to choose many things - from IoC to View Engine. And elder it becomes - more choices become available. And this is very good!
But it's also a pain - headache when you try to choose the best one for your project. And I had such a pain when chose a View Engine for my project.
In first cycle I considered all the engine I knew:
After some investigations (which actually won't be described here - may be in other post) I had chose Web Forms and Spark engine as finalists. I won’t tell you about what these engines are – I think references is enough for the moment and you will do your “homework” if you are interested in one of the engines.
So, let's dive deeper into them.


I’ve chosen the functionality that is very important or even critical for me to have in View Engines and made a comparison taking into account this functionality.
And this article is the only first part of upcoming articles. In the second one I'm going to show differences in markup and in the third – little performance comparison.


I don't want to use components I couldn't debug, investigate and sometimes fix. I don't like also to pay for some components if there is free analogues. That's why this point is important for me.
Web Forms engine is included into the ASP.NET MVC under MS-PL so could be freely used in any MVC project. Source codes are also available.
Spark is redistributed under Apache License 2.0. So no problems should be with their usage. Also Spark source code could be easily debugged and even changed. Last point is actually the only big difference between two engines.

Community and Project Activity

There are so many projects that had started successfully and looked perspective but then failed because of lack of support from the community, because of many defects that couldn't be resolved or couldn't be explained by someone. That’s why for long-term projects I'd prefer quite well supported and active projects.
WebForms Engine definitely has a greater community than Spark. For a long time Spark were developed only by one person, so support, new features and response time was not as good as for WFVE.  Nowadays, the situation is better for Spark - community is growing and many people like it. And this trend continues. So we'll hope Spark won't die and will grow and be filled with features.


Do you like to understand the framework by debugging their code? Always. Without documentation. I think nobody likes. Lack of documentation is on of the top-10 pains of almost all Open Source projects. They just write code and do not have time to write a documentation. So I was very interested in the quality of documentation of the projects.
Web forms definitely has better documentation. Spark has only several pages with plans to write more. But these pages and samples were enough for me to understand base concepts and use Spark for test project. But I'm afraid that for some really difficult case it could be lack of documentation. But feel free to ask the community :)


I have already made a little bit of testing. But let’s keep them for a while for one of the next posts :)

Master Pages support

Both engines have master pages support (Layouts in Spark). And this support is quite good: multiple content place holders on one master page, nested master pages, possibility to dynamically define master pages, add master pages locations etc.
At the same time Spark engine has such a unique features as “render” directive (please, correct me if WF engine has it to0) and may be some other ones.
NB. I have found and interesting peculiarity: if you name content placeholder in master page, say, MainContent and then give the same name to the content placeholder in the child Master Page (Layout) than this piece of  markup will be rendered twice.


In spark there is a possibility to define language specific-view and using already written components apply this views.  Also both engines support functionality provided by ASP.NET.

C# in markup

Yes, it could lead to spaghetti-code but sometimes it’s strongly necessary to have such an ability – to just write code in markup. Both engines provides it. But IMHO Spark does it in more beauty and easier-reading way. Any way you can use Web Forms like <% %> expressions in Spark too.
Also I like how conditions (if-else) and cycles (each) are written in Spark. It’s simple, easy understandable and do not lead the markup looks like a mess.
So I’d say that Spark C# support is a little bit better and more beautiful (subjectively).

Partial Views

Both engines also provide it. What I like about Partial Rendering in Spark is a possibility to partially render files implicitly and explicitly, define custom search locations, importing files and macroses. Last two are what WebForms Engine is really short of: it could reduce the size of pages and concentrate common parts in several files exchanging the behavior that is not easy to implement using Master Pages.


It goes without sayings that WebForm Engine has better Intellisense support, but Spark team has prepared Intellisense VS Addin and Schemas that could be used and simplify developers work.

Themes support

There are many samples of how to implement Themes support using both engines. Principles are the same and Spark is distributed with the sample (actually not full) and this code base could be easily injected into the project and used there. It didn’t take much time to rewrite code from ASP.NET Web Forms Engine to Spark one.

Precompilation and Caching

What I like about Spark is a variety of precompilation and caching options: you may precompile all views in batch during start-up, you may choose view to precompile, you may create assembly during build time thus improving performance of run-time, you can cache whole view and you can even cache part of a template (configuring caching with parameters, TTL, utilizing ValueHolder and signaling which allow you to make caching more sophisticated).
Standard cache can almost everything from what Spark can. But imho it is done not so good, clear and even some possibilities don’t exist in Web Engine cache or harder to implement (e.g. partial caching).
Precompilation is another song which is sang better by Spark and actually it could increase start up performance of you site and make it less “hackable”.

Learning Curve

It is one of the most important parameters, especially on small projects. Nobody want to spend a half of the project trying to learn and apply new technique or framework. But you know it took several hours for me to read through the all reference of Spark and understand general concepts.
But definitely for former Web Forms developers standard engine will be much more easier to understand and use, because Spark anyway require from devs to turn their minds a little bit. Moreover, I think on large projects when you dive into the Spark deeply there could be some hard to understand or hard to implement things which could lead to hours of learning, surfing and recoding. As it is usual with many frameworks.

Resume and What’s next?

Actually it’s to early to make a decision what engine is my preference based on the arguments written here. At least I should do the following:
  1. Try to create pages on both engines and look at them
  2. Compare performance of both engines at least on some very simple scenarios.
And I’ve done it. So a little bit of patience and you will be able to get acquainted with them.
Looking forward to your comments and help in this article improvements!

kick it on
Vote on DZone:


Khalipski Siarhei said...

Hi Alex

Thanks for the good investigation about 2 more useful view engines for ASP.NET MVC. I think this information will be very useful for my next ASP.NET MVC projects.

And I have some questions:
1) – It is very interesting to know your investigation details about another view engines. I understand that Web Form and Spark view engines are more useful engines. But have information about statuses of the another view engines will be very good;
2) – From the current post I see that standard view engine is more applicable for my projects. But performance can have impact on this summary. I look forward to seeing you next post with the performance results!

Aleksandr Sliborsky said...

Hi Siarhei,

Thanks for commenting.
1. Yes, I'm going to publish brief comparison table with some comments on other engines.

2. It definitely will be :)