To Spark or not to Spark?

Question

Been on a huge learning binge with ASP.MVC 2 lately, and recently uncovered there are different rendering engines out there... Spark especially caught my attention, couple of th

Answer 1

Actually, I was faced to the same choice several months ago, but for real business application, not for educational purpose. My answer is "to spark".

Certainly, there are some tricky things like intellisense and includes for pre-compilation. But from my prospective, the benefits are more significant. "Readability" of views is much better in spark. There is more elegant separation into partials (again, my personal opinion). I also found spark way of site localization more natural (MyView.spark, MyView.de.spark, MyView.de-DE.spark with automatic fallback, and the same for master layouts). A plenty of small conveniences - best of all I love ${} and !{} to get html encoding or to avoid it. My application works in medium trust being pre-complied.

I would rather say that spark is mature enough to be used in real development. But not perfect.

Answer 2

I know this question has been answered and was asked before Razor came out, but I would choose Razor if I were starting a new project. I have a current project with Spark and I definitely agree that it was a better choice over WebForms. But since the landscape has changed I would choose something else if I had to make the decision today.

Reasons

• The main developer of Spark was hired by Microsoft(probably working on Razor)
• The last stable build for Spark as of today has almost been one year.
• The syntax is fairly similar
• Outlining support. When creating web-pages it is critical for me to be able to collapse sections of html, Razor supports this and Spark does not.

I don't buy the argument that Razor has it's priorities wrong. They say Razor's default is code and then some markup and Spark is the opposite. I agree with that argument to a limited extent; the tools are there for both view engines to either have a code-less or code-ful view. It's up to the guy who ends up typing it out.

Answer 3

Answering the three part question in order...

1. It probably is a good idea to learn new things one at a time. Especially because nearly all of the MVC examples and tutorials will be in WebForms syntax. That said - it's best to learn in an experiment solution rather than your "real" project, so after you feel like you have MVC concepts down it's a good idea to create a new sandbox and try a few MVC + Spark pages.

2. Performance in terms of memory pressure or processor utilization probably isn't the most important consideration for all but the largest web sites... The impact on developer, and designer/creative, time may be small at first but it's cumulative and non-linear. A bit of simplification up front will save you boatloads of pain in the future, and "simple, plain syntax" is the cornerstone of Spark view engine premise.

3. That is very true. The polish and refinement of experience is the most expensive part of tooling and modern IDE's. I think that's why most OSS web stacks start with a great editor (cough TextMate cough) and work their way up from there. With Spark you can get csharp language intellisense, but that's clearly the low water mark for tooling support.

It's anecdotal, but one way to measure is how many people regret using Spark and switch back. I'm not sure of many - though the delay out of the gate in getting MVC 2 support out had some people wondering, I'm sure.

Answer 4

One of the nice parts of MVC in web apps is that you can get much closer the the bare metal of HTML which is one of the main problems many developers run into - lack of absolute control of rendered HTML

Spark is significantly closer to bare HTML than ASP.net

In general a non programming HTML designer will have more chance of understanding Spark and working with it than ASP.net

If this is an issue for you use Spark, otherwise use what ever rendering engine you want. Check out nhaml for something different

Answer 5

Depends what you want to do with ASP.NET MVC. We are in the middle of building a large enterprise app with it, and I find myself slightly wishing we used Spark. But this was only after about our 200th view was completed that I felt comfortable enough with the framework to consider snapping in something else.

I would recommend building some small apps with the regular view engine first, and if you find yourself struggling with "tag soup" step back and consider why. In many cases it just means you should have made a better ViewModel and mapped data, created an html helper, or utilized a partial file rather than filling your view with tag soup.

However, there are times when conditional and vast looping logic is required in the view, and this is when you might wish you had Spark. The nice thing is that you can use both side by side. So I'd say go with the default, and fool with it once you're comfortable.