Sahil Malik has a response to my SharePoint 2010 Sandbox Solutions are Bad post that you can read here: Sandbox solutions are pretty damn good. He also links to a Facebook conversation wherein Razi Bin Rai asserts "At heart of the argument of 'SB solutions are bad', there is actually more of a resistance against new way of doing things" and Sahil replies "True True Razi".

Not true at all. (I am always amazed when an Internet commenter thinks they know the mind of another from a tweet or a page of text).

There is in fact not a resistance against a new way of doing things. I came to this new technology with a great deal of excitement, but I find it distinctly lacking in its merits.

With regards to Sahil's post - I believe that proxies are a sound and vital architectural choice. But they are not part of the sandbox even though SharePoint provides the means to invoke a specific type of proxy from the sandbox. In SharePoint they are, in fact, full trust components that require administrative access to install. My guess is that those who have permission to use them will do so if they are using Silverlight or heavy javascript with the new client namespace. Furthermore, they will use some form of server side proxies regardless of whatever deployment (sandbox or farm) choices they make.

And why not? By going with a predominately client side technology you don't lose anything from the sandbox that you would have without it. Assuming you have admin access you can solve both issues #2 and #3 mentioned in my original post . But let us be completely honest about what this means; you solve them by having components outside the sandbox. Most, I think, would choose this architecture (proxies to server side services) when the UI is client side JavaScript or Silverlight with or without the sandbox. If we both agree that this is a sound architecture in and of itself, let's not confuse the subject of the merits of the sandbox as it is implemented by talking about something that is clearly separate even though complimentary.

Besides, I don't think full trust proxies will be an option on SharePoint Online or other hosted offerings anyway.

Sahil seems to be conflating my choice of the word 'Bad' with 'useless'. This is not a useless technology, but it is a bad one. As you may know, I've been slowly making Elumenotion into an ISV. I hope to have some success with SharePoint Online and its analogs and so we are working on a variety of workarounds and trying to come up with a serviceable architecture. The fact is: there are workarounds and you can build solutions.

This concession made, let me reiterate what I think was the most important part of the original post. If you are going to do development on 2010 and you have access to the server your default choice should be farm solutions unless you have a compelling requirement to do otherwise – the pronouncements at PDC and elsewhere to the contrary (sandbox should be your default choice) are nonsense. Absent a clear requirement (like the need to run as a hosted solution) going with a sandbox will result is more code with strange workarounds and potentially less secure data for more money and time. If that's not bad, then what is it?

I must admit that I was a little irked that I took the time to come up with three specific examples that Sahil ignored and substituted with a straw man when he wrote his rebuttal. I think I have addressed the full trust proxy point, but let me tackle a couple of his other points so that he need not be irked with me. ;)

First Sahil says 'Farm solutions and custom code is the number one necessary evil on SharePoint projects. It is also the number one issue that causes problems and updates. And it is also the number one issue that causes contention between IT Pros and developers.' To this I can only say '[citation needed]'. It's a huge assertion to make that does not jibe with my experiences or anecdotes from my peers or clients.

Second is that the sandbox provides a degree of monitoring that can prevent rogue apps from killing the server. I agree that this is a great thing especially if you are providing hosted services like SharePoint Online that preclude normal QA and monitoring processes for deployed code. Once again though, if you have the option of traditional development because you own the servers, traditional QA and WMI instrumentation along with ULS logging are a first line defense which should minimize the need for such a system.

Third Sahil says: 'My feeling is that there's been plenty of thought given to where and how those walls have been drawn.' My feeling is that insufficient thought and resources went into making these decisions. At some point they have to ship it and they decided where to put the resources. This stuff smacks of a version 1.0, let's get it out the door deal. I am spending a lot of time in Reflector these days looking at the SharePoint assemblies. If there is a security or performance issue that caused them to deny access to the entire SharePoint.WebControls namespace I do not see it. The code for most of these controls is simple and straightforward. However, there are hundreds of them. My purely speculative guess is that they only had so much manpower to go around and they took the easy way out by blocking them all instead of looking at them individually.