Over the last week or so we have been trying to gather information on what developers are saying about Project Jasper. (This, even in the age of rockin’ search engines is a lot harder then one thinks). As part of this, I have seen a handful of interesting comments that I wanted to comment on.

On Paul Gielens blog, in the blog comments for RAD is Making a Comeback with Jasper Ryan Ternier added the following comment:

Jasper looks cool, but it seems that the new things coming out are taking the coding out of programming.

On this point, the Project Jasper team totally agrees with Ryan. The goal of Project Jasper is not to take the coding out of programming, but to allow the developer to concentrate on code for one’s specific problem domain. In other words, one of our primary goals of the Jasper framework is to provide a model centric development experience where a majority of the app’s code is not plumbing code and/ or something the framework can take care of through convention. At a high level, the Jasper framework provides a conceptual model based on the underlying database or specified EDM. From there it also generates data classes dynamically at runtime so the developer can interact with the model in an O/R fashion. We fully expect the customization of these types and the interaction with the model to be code, and actually wouldn’t have it any other way. I don’t think we are there yet, but one of our eventual goals is to make the experience of programming against the Jasper API feel like using a DSL for one’s specific model. To be clear here, this is not our unique idea but based more on where we see the industry is headed.

Things are more efficient when they're all custom built by the coder. Have all of these things at our finger tips will allow us to create applications very quickly, but at what cost?

Have to agree with this point also. Any time one decides to use a given framework or API, there is definitely a tradeoff between control and efficiency – both of the developer and the actual code. To be clear, the Jasper framework is a high level API. In other words, we are explicitly making the choice to increase developer productivity while sacrificing developer control and some code efficiency. However, since Jasper is built on the ADO.NET Entity framework, we have a huge advantage that the developer could always drop down to the lower level API – even in an application that largely uses Jasper. That said, in my opinion we have three challenges with Project Jasper to make it useable: 1) Make sure the Jasper API is the right abstraction to solve the targeted scenarios 2) Perf and scalability need to be good enough for production deployment of those same targeted scenarios and 3) Get the layering with the lower level APIs correct. IMO, for the first CTP release we have not done a super good job with any of the challenges, but have it on the radar.

There was also an interesting thread on the comments for Mary Jo Foley’s article about Jasper.  One reader added the following:

I see where Microsoft's running with this stuff. The "quick and dirty" quote makes me nervous. Our projects are never of the quick or dirty kind, and more accurately, are usually the 6 month to a year kind. We (my company) don't want to have anything quick and dirty in our applications, we don't want any part of the application to be quick and dirty, simply because eventually one of us has to go back to that project many moons down the road, when the client requests changes, and we're looking at all this quick and dirty code. We want to find the stuff that we can read easily then.

I have two comments for this: 1) For big projects with many developers, Jasper may not be the right tool. At least initially, we are trying to tackle the writing small to medium sized apps against an existing database. i.e. exposing a legacy database via a bunch of web services or a bunch of small form based applications. 2) There may be reasons a framework like Jasper is right for your project, but we never want it to be because the code is not readable or maintainable. Hence, why the project’s motto is “Quick and Clean”. In other words, we don’t want to provide a solution where initial developer productivity is traded for code maintainability down the road.

And finally, there is this entire post which the project team found very entertaining.

My only comment on this is that we would be lying if we told you weren’t impressed by the work being done by some of the web frameworks out there, but we also believe we have a number of features that make our solution unique: Linq support, support for multiple dynamic languages (IronPython, VB, IronRuby, managed Javascript), completely dynamic data class generation, a ASP.NET story that is not revolutionary, and rich mapping support.