Is it possible to only use a managed dynamic language such as javascript in a Silverlight application, with no server side compilation before deploying to the client? I'm looking for 0 server side compilation of any code here - would like the entire application to be 100% compiled/interpreted in the browser. I skimmed through the DLR specs but I didn't notice such an option.
Technically the answer is yes. Silverlight is a pure client side technology that runs a cut down, secure CLR in a plug in. The Silverlight API is accessible scripting languages including Javascript, F#, IronPython and IronRuby.
However, it is questionable whether you should progress because there doesn't seem to be any community or support around this. Furthermore, Silverlight is in support mode and you have to consider whether it is worthwhile investing your energy in such a dimly lit corner.
There are a few technology demonstrations by Jimmy Schementi here. Also check out the references in DLR Wikipedia entry. The old silverlight forums used to have an entire subforum dedicated to Javascript and Silverlight. This is now gone. Consider that as a warning if you decide to progress in this direction.
A few years back, there was an SDK that included a working IronPython and IronRuby with Silverlight, some demos and build scripts. Look for Chiron, which packages scripts and xaml into a single .xap (zip) file. This is in the DLR. There were some cool examples which demonstrated a python and ruby interpreter running in the client side in a Silverlight plugin.
Alternatively, you can develop most of your application in a typed language and then expose parts of it to javascript via a Javascript bridge. The MSDN has some short write up on how to do this.
Related
At my job we are developing a GIS application which will be developed using Silverlight + .NET
But, I heard that Silverlight will not be supported by Microsoft as also they are stopping Silverlight, is it true ?
Is it suggestable to use Silverlight if so with which version of silverlight we can use. ?
Thanks.,
Use Silverlight 5. Current version have 10 year support, and it better than Flash, java or damn it html.
In the future you can migrate to another .NET-based framework by easily porting code.
About silver light support, you can find these answers from Microsoft Silverlight Support Lifecycle Policy.
Keeping in mind that MS would support these browsers till 2021, I would recommend using Silverlight5 if you really have to use Silverlight.
However for new developments I would recommend you to evaluate Html5 as well.
YES! Silverlight is still the best technology to use for web based Line of Business applications. Silverlight will be supported for another 10 years and it will be available within Windows 8 desktop. Silverlight +[Arc]GIS are a great combination. It is so easy to create full functioning application and with little effort. Silverlight is not dead. It is still a great technology to use that is available on (almost) every platform.
Ultimately it comes down to:
1) What do you know: Are you an HTML/JavaScript ninja? Then use that, do you know Flex better then your own children? Or are you a skilled .Net assassin?
2) How much time do you have? Do you want to learn something new and have gobs of time? Then go for that new shiny object (HTML5) and get yourself some street cred.
This probably belongs on programmers.stackexchange.com. However:
Silverlight will continue to be supported for some time, but all signs point to it no longer being actively developed.
If you want a technology that's actively developed, I'd recommend HTML 5 for web based applications and WinRT for Windows 8+ native applications.
Ultimately, though, you should go with what works best for your situation. After all, WinForms is still used on many successful greenfield projects.
Silverlight is based on the NPAPI architecture that is no longer supported on Google Chrome (from browser version 42 upward) though you can still run it on IE and Firefox. HTML5 is supported on all browsers.
From a career standpoint, using Silverlight (which uses XAML) gets you an easier entry into developing apps for Metro/Windows Store/Universal Windows Apps (these can be developed using HTML5/JS too but you'll find a larger developer base using C#/XAML).
Finally if you're already a WPF developer, it's fastest if you develop for Silverlight. See Silverlight vs Flash vs HTML5.
I'm building a LMS system using Sharepoint (WSS 3.0) with the Sharepoint Learning Kit (SLK). One of the requirements is to be able to host Silverlight content within the SCORM package. Has anyone done this before? I haven't been able to find much (anything) online that talks about how to do this. Most of the content tools that exist for SCORM are able to handle Flash, but I haven't come across anything that will do Silverlight.
If all else fails, I'll try to manually build a SCORM package, but I'd really like to find some examples or howtos of doing this with Silverlight first.
Has anyone done this before?
I haven't done it personally before, but from a SCORM perspective the content is a black box. It shouldn't matter if it is implemented in Flash, Silverlight, or whatever. The complex part about using plug-in technologies with SCORM is establishing communication with the SCORM API via JavaScript. In Flash, it can be tricky to communicate establish a communication link between the Flash movie and JavaScript in the browser. It looks like this is a straightforward process in Silverlight.
Check out SCORM CLOUD, and then build an API to talk to it. http://www.scorm.com/
Hope this helps,
Dan Linstedt
http://danLinstedt.com
Silverlight 3.0 beta has just been announced at Microsofts Mix Conference in Las Vegas.
Two features of the new beta are 3D-graphics and the ability to run applications outside of the browser, which to me seemed to be two of the major features that WPF (Windows Presentation Foundation) previously offered over silverlight.
I am currently evaluating WPF and Silverlight for possible use in our companies future development activity, and this announcement has left me confused as to the intended direction of these two UI technologies and why I would choose one over the other.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision? Given the announced changes to silverlight, Would your decision have changed had you made it now, and if not, why?
Any advice would be appreciated.
The biggest difference I find is the asynchronous model you have to adopt
in your Silverlight application.
It does seems like an advantage (and it can be), but it does make
life very difficult sometimes.
There are also some limitations that can be a real challenge like the absence
of print support.
I would recommend Silverlight over WPF when:
- There is no need for best possible performance (graphics included)
- Can get around the absence of print support (it will come, we just don't know when)
- Camera/Microphone support is not needed
- Can tolerate the assync app/development model
- Can tolerate limitations on WCF (no support for WS-Security at this point)
- There is no need to store huge amount of data on the client.
- There is no need to direct integration with client side applications like Office.
- Has a server to host your application
I would say the main difference is that WPF requires the client to have the .Net 3.0+ framework. Silverlight only requires the runtime. Now that being said, WPF is geared more for controlled environments such as an intranet. Silverlight is meant for the public web. Another difference is that Silverlight is cross platform (Windows, Mac, Linux in the future & Cross browser). WPF is meant for Windows only.
The .Net framework can be a huge download for some users. Silverlight is only 4-5MBs. This is a big difference to run your app on the web, but not a big issue if its an internal application at your company.
Silverlight is Sandboxed which is meant for web use. So if your app requires more permissions you will need WPF.
There are also some differences between Silverlight code and WPF. But from what I've heard, the ultimate goal is to get a Silverlight to run inside of WPF with minimal code changes. But they aren't there just yet.
I have just worked on a WPF project that in hindsight we feel we might have chosen SilverLight for. It is probably more important to know the differences and select the one that is most appropriate for what you're doing.
Here's my starter for ten on some of the important differences - there were originally some differences in the available controls, but that has largely been smoothed out now.
Silverlight
Runs entirely on the client with AJAX
calls to the server for data
Can run on any server, including Windows and Linux / Apache
Uses COMPACT .NET framework
WPF
Runs on the client... usually calls services for data
Runs on Windows XP / Vista with .NET 3.5
Utilises the entire .NET framework
Silverlight is basically a stripped down version of WPF in order to make the runtime libary download as small as possible.
As a result, WPF simply has a lot more functionality available in it and tasks that are simple in WPF often become not so simple in Silverlight.
If running as a web app is not a requirement then the decision is a no-brainer - WPF all the way.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision: Well since WPF was desktop only (or browser based using XBAPS - but that was more a deployment system than a real system) that was a good reason to it.
"Would your decision have changed had you made it now, and if not, why?" - No Silverlight, even on the desktop in v3, is still highly sandboxed and so certain functions are going to be hard/impossible to do due to the sandbox. Also the ability to use DirectX parts in WPF will still give another optimisation area which Silverlight and it's 3d won't be able to use.
It's worth noting that Silverlight's 3D is not the full 3D support of WPF, but only projection of 2D into 3D - i.e. take the 2D plane and allow rotation in X, Y & Z directions. WPF has full 3D modelling with materials, view ports, lighting and camera positional support etc.
I'm well along in the development of our first WPF app for release. Silverlight 3 looks great, but for this application I would still have chosen WPF. The application centers around presenting and manipulating very large sets of images hosted on a central server on our clients' networks. Additionally, the software update/change rate will be minimal. Mass import of new images from a local drive, no Internet connectivity requirements, performance concerns, etc. make this a project well suited for WPF.
One of our upcoming projects, however, will require many remote users to access a single data store on our network. The data they work with requires significant validation and error handling, so running that code locally is ideal. They will need the ability to work both on and offline and remain in synch (probably with SQL Data Services). SLOOB (Silverlight Out Of the Browser) will most likely be our choice for that one so they can have all the Silverlight advantages but use it like a regularly installed application, even without an Internet connection.
Both formats have their place: the trick will be to avoid using Silverlight for everything - we have more tools than just 1 hammer. :-)
Another difference is that with SL you only have one 'window', you can't have dialogs (they can be simulated but their size is limited to the main window) and you can't add multi monitor support.
If you have to interact with existing business applications (e.g. open a document in the archive viewer) you need to use WPF.
I recently have built several internal tool using wpf, and I chose it simply because It was easier for me coming from win32 work. I don't really think that the differences are major, and really... everything i have seen/heard indicates that porting between wpf and silverlight is quite easy.
Storage: You only have 25MB of isolated storage out-of-browser. If I remember correctly from some mix09 video, this limit is lower if your app is in-browser.
http://bliny.net/blog/post/Out-of-Browser-with-Silverlight-3.aspx
No FlowDocument: So there are limitations there too.
This may seem like a high-level question. But that is because I'm unfamiliar with cutting edge ASP.net and even less with this behemoth called Sharepoint. So please bear with me..
First off is it possible to take functional custom WPF controls which contain certain unmanaged subcomponents that do DirectX rendering (for performance reasons) and drop it into ASP.Net? as an example consider a specialized chart control
Does Sharepoint add anything that makes this possible ?
The use-case is to take certain panes or areas from a thick WPF client and slot it into an existing Sharepoint based solution.
Is this possible or are they (WPF Controls and Web Controls) as different as chalk and cheese? (Assume that the current control interface can be freely changed.) Would it wise to develop web-aware stripped down version of these controls than to attempt to hammer the current controls in somehow...
On a fundamental level, can a web-page contain a control which takes over the rendering for its client-area/rectange ? Or does everything have to broken down into plain html by the time it hits the browser.
I found a few unanswered queries online. But other than that its unexplored (or forbidden).. in either case I'd like to know. Thanks for reading..
The short answer is: Yes it's possible but you probably don't want to do it.
Asp.Net, with the exception of java script, is primarily a server side technology. Meaning that the majority of the processing code runs on the server vs. the client. IIRC share point is built on top of Asp.Net and thus has the same format.
WPF is a client side technology. The code runs on the actual physical client computer.
Combining these two technologies into one application does not work due to their conflicting natures. However, there are several options for you.
Silverlight: It's easiest to think of this as flash for .Net. It allows for rich WPF applications to be run via a web browser on client machines. It's a subset of the full .Net framework but rich enough to build great applications.Silverlight is limited in that it must be a 100% managed solution. You're post mentions using a DirectX control which I presume is native code. If this is the case Silverlight will not work for you
ActiveX controls: These allow for essentially any form of client code to be hosted in a web browser and run on the client machine. This includes .Net, WPF, C++, etc ... If you have a native component this is really your only option.Unfortunately though, ActiveX controls are following out of favor. Primarily due to their insecure nature. Once you run an ActiveX control on your machine you're at the mercy of the control author and it's easy to do malicious acts.More data on ActiveX controls: http://en.wikipedia.org/wiki/ActiveX
Is it possible to build a good medium to full sized application using just silverlight as a host?
A few things that would be needed:
- dynamic pages (one silverlight "screen" can switch between screens, like a normal app.
- similar to a java applet which launches from the browser
I see that Telerik sells RadControls for WPF...but this is only useful (to me) if Silverlight can be a rich client platform through the web.
Although still a somewhat immature platform, Silverlight 2.0 supports many of the features that I would expect from a platform needed to create full sized applications.
Data access through web services and local data/object query support with Linq
Many feature rich controls such as datagrid, treeview, etc
A very usable subset of the CLR (common language runtime)
Access to restricted local storage on the client machine
It is cross platform
There are already some great add-ons, like Telerik and the Silverlight Control Toolkit
For your specific scenario, Microsoft has published a tutorial on Multi-page Applications
Absolutely. I've been looking into this and believe that it's as easy to do in Silverlight as it is in any other language. Remember that Silverlight 2 uses C# 3.0 and from that you can build anything that's not included in the Silverlight version of the CLR. Also, the fact that Microsoft gives you access to the .NET source code means that you can compile the missing parts of the .NET libraries with your application. (No idea about the licensing issues with that though.)
I've seen a presentation of a full featured CRM application two days ago. Although it's still alpha: It looks and feels like any office application. I don't know details but for me it's a proof of concept.