PreambleThere 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!
IntroductionIt 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:
- Standard WebForms
XSLT (numerous of implementations)
So, let's dive deeper into them.
ComparisonI’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.
LicensingI 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 ActivityThere 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.
DocumentationDo 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 :)
PerformanceI have already made a little bit of testing. But let’s keep them for a while for one of the next posts :)
Master Pages supportBoth 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.
LocalizationIn 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 markupYes, 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 ViewsBoth 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.
IntellisenseIt 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 supportThere 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 CachingWhat 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 CurveIt 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:
- Try to create pages on both engines and look at them
- Compare performance of both engines at least on some very simple scenarios.
Looking forward to your comments and help in this article improvements!
Vote on DZone: http://www.dzone.com//links/aspnet_webforms_vs_spark_view_engine_part_1.html