In modern web application design, the requirement to add client-side code is becoming increasing popular. After all, websites that have rich client-side behaviors are now the norm on the Internet. Adding client-side code into your SharePoint solutions is definitely something that will improve the user experience.
Beyond improving the user experience, there are SharePoint design scenarios where client-side code can do what server-side code cannot. Let's examine a simple example. Imagine a scenario in which you are required to develop a sandboxed solution that retrieves content from a public web service on the Internet and then writes this content into a SharePoint list. The problem with using server-side code in a sandboxed solution is that you cannot call out to a web service.
However, you can redesign your sandboxed solution to include custom ECMAScript code or a Silverlight application that calls out to the web service directly from the user's browser. After your client-side code retrieves the content from the web service, it can then write the content into a SharePoint list by using either the client object model or ListData.svc. This example provides yet another motivation for why you might want to include client-side code in a SharePoint solution.
If you decide you want to add client-side code to a SharePoint solution, the next step is to choose between writing custom ECMAScript code-behind pages or developing one or more Silverlight applications. Let's look at the pros and cons of each approach.
ECMAScript has an advantage of reach over Silverlight because it is supported across a larger number of browsers. Furthermore, browsers include built-in support for ECMAScript, whereas Silverlight applications do not run unless the user downloads and installs the Silverlight runtime. Although the download and installation of the Silverlight runtime can be completed over the Internet in a matter of seconds, you must still acknowledge that Silverlight development makes an assumption that the user will trust a Microsoft software component and install it from across the Internet. This might not be a good assumption to make in wide-reach scenarios, such as when you develop a commerce application for the Internet where you want to reach the maximum number of potential users.
In most SharePoint 2010 environments, you can typically assume that it will not cause problems to deploy Silverlight applications with your SharePoint solutions. After all, SharePoint Foundation includes several different Silverlight 3 applications in standard pages, such as the creation page that is available by selecting the More Options command on the Site Actions menu.
The fact that SharePoint 2010 users are required to install Silverlight 3 just to get the complete built-in experience means that you can typically assume that they will already have the Silverlight 3 runtime installed on their computers. If you plan to use Silverlight 4 instead of Silverlight 3, you must assume that users are willing and able to install an updated version of Silverlight on their computers.
The final point to consider when choosing between ECMAScript and Silverlight concerns developer productivity. In this area, Silverlight development is the clear winner. That is because you can work inside Visual Studio 2010 and write your code in C# or Visual Basic. You experience all the benefits of compile-time type checking and IntelliSense as you call methods in the .NET Framework and the client object model. You can also create service references that make it much easier to program against web services, such as ListData.svc.
The experience programming ECMAScript in Visual Studio 2010 is nothing like the experience programming a Silverlight application. There is no compile-time type checking, nor is there any IntelliSense when you program against the client object model. Furthermore, you need advanced programming skills with ECMAScript and ASP.NET AJAX to call out to a web service, such as ListData.svc, or to perform the required thread switching from a callback method before updating something in the UI. If you are just beginning to learn to write client-side code, developing with Silverlight will be a much better option than writing code by using ECMAScript.
Before developing SharePoint client-side application consider following points.
Features
|
Silverlight
|
ECMAScript
|
Easy data retrieval
|
No
|
Yes
|
Easy Programming
|
No
|
Yes
|
User Interface
|
Very Attractive, No need to more efforts on UI Design.
|
Totally Depend on web designer
|
Minimum Users
|
Good option
|
-
|
Maximum Users
|
Fare option. Because may all users browser does not have Silverlight installed.
|
Very good option. Because easy to load, support maximum browsers.
|
Data Processing
|
Very easy
|
Difficult to implement
|
Best Scenario
|
Great User Interface and Advance data processing like accessing multiple lists and combining its items.
|
Accessing one list item and display it’s in grid view or detail view.
|
MSDN Reference Link: http://msdn.microsoft.com/en-us/library/gg552613.aspx
No comments:
Post a Comment