+972 52-548-6969
On Silverlight
I read Davy Bryon’s post about the future direction of Silverlight with a great deal of interest. But I think that Davy is missing a significant point.
First, I agree with Davy about a few things. Silverlight for public facing applications is going to be… problematic. Support for mobile devices, something that becomes ever so increasingly important, isn’t really there. And there seems to be a lot more reticence to “bet the farm” on public facing web sites by most companies. A good example of public facing Silverlight application is Justin’s blog. Which is really nice, but has the following issues:
- It has a long loading time compared to most websites.
- The scrolling inside the Silverlight application feels… wrong, compared to the one in the browser. It works, but I think it uses a different scroll size than the browser.
- I can’t zoom with the keyboard (Ctrl –, Ctrl +, Ctrl 0).
All of that doesn’t really matter, to be perfectly frank. Silverlight isn’t really meant for websites, and blogs are probably one of the most common examples of web sites. Silverlight main purpose is applications. Cast your mind a few years back, to the rise of the Web Applications. Why did it happen? Mostly because the cost of deploying desktop software to all the machines in the organization was so high. Building a web application reduced deployment costs.
But web applications are still pretty hard to do, compared to desktop applications, if you want to have similar UX. And the number one problem that keeps recurring is that you have to manually manage the state. Silverlight gives you the same null cost of deployment, but with a lot of the advantages of building desktop applications. Mostly, again, because of the state. Yes, I am well aware that there is a large body of knowledge on how to build complex web applications in pure HTML/JS. But that is still harder than building a Silverlight application.
And that is where I see Silverlight being used most often. It isn’t replacing the company’s site, it is replacing all the internal applications and systems that used to be HTML applications.
Comments
Correct. The difficulty of web development lies in managing state that usually is managed by the ui controls (is the expander expanded or collapsed? you have to post this bit of information back to the server and back to the client again). That is where the genius of aspx lies.
Ayende,
i did say this:
"One of the most important factors in your decision to use Silverlight or HTML/CSS/JavaScript for new products is the long-term strategic importance of the product. If the product you’re going to build is not going to define the future of your company, your organization or your endeavor, then there’s nothing wrong with going for Silverlight. There are a lot of benefits that come with choosing Silverlight and as long as none of the downsides are a problem for your situation, then it might very well make a lot of sense for you to build your product with Silverlight."
the internal applications that you mention are indeed what i consider to be good candidates for silverlight development. Those applications aren't often long-term strategically important products, which is more of the point of my post.
Davy,
I am not sure about you, but I saw a LOT of strategic products that are used only internally.
@Ayende
perhaps you're right... that's perhaps one of the biggest reasons why so many companies remained dependent on ActiveX for so long after it was no longer being developed.
let's see whether or not history repeats itself yet again :)
Personally I don't think Silverlight has a chance outside LOB applications. My biggest gripe with it is the loading time as all the user sees when they get to a Silverlight page is the loading sprite. And based on the 3-7 second rule most people wont wait for the application to load, and the ones that do probably wont be returning since they've subconsciously associated that particular website to be slow and sluggish. If you had to use Silverlight/Flash you should do it like gmail/gmaps and load it behind the scenes so the user never has to wait for it to load.
Like all plugins when embedded in a web page it appears foreign where Silverlight apps rarely support the back button, deep-linking, selecting and finding text on the page etc.
I think it really depends on the type of application whether or not developing it in Silverlight is easier. IMHO Silverlight is better suited for graphic intensive, all-encompassing, single-purpose applications where I think there is a law of diminishing returns where the time of adding more features takes longer the bigger the app is. Silverlight and traditional desktop apps in general are really a all-or-nothing solution, i.e. Because of the natural loose-coupling inherent in websites give you can easily seamlessly integrate different Be-spoke applications together like your companies Word Press powered website with deep links into your SAAS CRM solution that connects to your in-house accounting applications. A classic example is how google seamlessly integrates all its applications like gmail, calendar, docs, reader, with rich deep linking into each application.
Basically Silverlight/Plugins in general are a poor fit for any Content heavy or extensible websites which most websites are, e.g. building something like Word Press with all its features, extensibility and customization possibilities will be nearly impossible to replicate in Silverlight/Flash.
For those considering developing large Ajax applications I recommend checking out the Google Closure Library ( http://code.google.com/closure/library/) where Google has opensourced its framework and compilers it uses to build gmail, gmaps, etc. It's a bit more verbose than jQuery but provides a solid foundation to build rich, state-heavy applications.
I don't think Silverlight is a good choice for applications, Adobe Flex was there long time ago and it didn't become a preferred development platform. Silverlight is there too late and doesn't really offer anything new or exciting, what's worse Microsoft seems unable to keep up with the rest of the world regarding web technologies. No one knows if they will be supporting SIlverlight in future if the platform doesn't get enough traction. I'd stick to a web browser and Javascript, this is going to stay here for sure and offer more and more functionality every year.
I think it is time to develop LOB applications in such a way that they are independent of the actual UI technology at runtime. The idea is to be able to switch to ASP.NET, Silverlight or whatever you like (and whatever the future may bring) at will. You can think of this as being the same as the way we develop the data access layer in a database independent way.
@Rene
Yeah that's not going to be possible with a UI as you'll just end up with a generic abstraction which is just another UI technology that is more limited and then the underlying UI its trying to abstract. Trying to do so will probably end up doing something like JavaServer faces.
Truth be known the current UI technologies already try to be DSL for creating a UI. Where the web's HTML/CSS/JS and Flash's MXML/ActionScript/CSS and Silverlights XAML/C# already try to provide optimized language for implementing a UI's structure, style and behaviour. Personally I don't think any of them have got it right although I believe the w3c stack is capable of providing the best overall UX and has the best potential to improve in the future.
@Demis,
I know it is possible because we have done this at our company :). You are right in the sense that it provides an abstraction that is less rich than the underlying UI architectures, but that in a sense is actually a good thing if you think about standardisation. I also restricted it to LOB applications too. You surely don't want to design a game this way.
Demis,
Actually, it is REALLY easy to build composite applications with SL. Moreover, it is possible to do so in a way that is both loosely coupled and tightly integrated.
It is significantly harder to do the same in Web Apps. Indeed, in most cases, to do that, you leave the entire web model (GWT).
Rafal,
Adobe was never a developers company, MS is.
Rene,
I am sorry, but such a thing is not possible.
Or, to be rather more exact, it is possible to try, and you can even get something half way decent for the very simplest scenarios. But it doesn't work for real world applications.
Rene,
No, it is not a good thing. The problem is two folds:
a) debugging stuff is now MUCH harder (you have to drop 2 abstraction layers).
b) if you need something that isn't already there (and there is very little there, I can assure you), you have to do a LOT more work
@Ayende
Yeah? Where are they? I've never seen an integrated Silverlight suite of apps that were 'loosely coupled and tightly integrated'. Any integration between 2 bespoke Silverlight apps likely have come from the same dev team and company. I've yet to see anything even remotely close to the composability and customizability of Word Press plugins/themes built with Silverlight / Flash. IMHO I think the technology forbids it - it will require devs sticking and adhering to standards over and above the SL fx. IMHO Silverlight/Flash is likely to be rendered into a niche before this happens.
Well the Google Closure Library (that I highlighted earlier in the link above) doesn't leave the web model yet provides a great framework to build large applications. There are a suite of other JavaScript frameworks ( en.wikipedia.org/.../Comparison_of_JavaScript_f...) that never leave the web model - GWT is unique in this way.
The gap of what is only possible on the web with Silverlight/Flash is fast eroding just as modern browsers are advancing with more and more features and desktop-like capabilities.
Like I said I would only consider Silverlight for LOB or when enhanced functionality like rich visualization is required but only embedded and loaded behind an Ajax app ala gmail/gmaps style.
@Demis
seesmic desktop 2?
not having compile time compile time exception is one of the biggest problems with js/ajax applications.
testability is another problem. yes, you can test a web app UI with selenium, but it's such a pain compared with any other testing framework for SL of WPF apps...
I'm not a big fan of Silverlight (yet) but I'm 100% sure for most LOB SL is the best choice.
Instead of spending 50% of your time fixing layout problems, js errors with IE like you do when you develop any web app, you can spend 100% of your time developing business logics... that is much better for your company.
@smnbss
Yeah that's an example of one Silverlight app? that's not an example of an app that's extensible, customizable or which integrates with other silverlight apps.
YUI test and Closure Library both come with good testing frameworks. But yeah testing async apis can be more cubersome than the blocking apis were used to with C#.
If you're follow the http://deathtoie6.com camp like I have :) then layout / js problems are not nearly as bad as they were a few years ago. At only a 16% loss of market share, a modern ajax app still has significantly more reach than a Silverlight app. As a general rule starting with a reset.css and using an established js framework (which provides a unified api around most browser quirks) and re-using well tested widgets alleviates most issues in web development today.
Totally agree.
Some additional observations:
The js client side RIA library story is still immature, even after all these years It continues to be a hard problem, and the solutions that are good (extjs, sproutcore) still carry a heavy implementation burden (lock in and volatility being the worst)
Server side JavaScript frameworks are the next step in bridging the client/server impedance mismatch. The benefit of a shared language, programming model, and stack will virtually eliminate the gap. This will be huge.
Silverlight as a platform for internal LOB applications immediately loses its appeal as soon as the same team or organization has to build/maintain an external/public website on the HTML/js/CSS stack. Now you have a need to support two paradigms, which turns out to be wasteful. Consolidating on one skillet here turns out to be a huge win, in my experience. And the web stack wins by necessity.
@smnbss
Seesmic desktop??? Well, first few sentences give you a picture: yet another facebook/twitter/flickr/youtube/whatever mashup and not really a business application
I have spent some time looking at Adobe Flex and Silverlight and was fascinated about how powerful and sexy the Flex was (Silverlight seemed more bloated and boring, but that's typical for Microsoft products). But then started working with javascript and Ext JS/jQuery and that was it - very fast development, no compilations, no IDEs, no framework that hides the important stuff behind abstraction layers and boilerplate code, no designers, just a text editor and browser window where you can see the effects instantly. Why code in C#/XAML when you can use HTML/CSS or javascript in its natural environment?
Demis,
Take a look at the testimonials for Prism for Silverlight, for example.
I'll admit that I took just a peek at the tutorials, but I saw DOM manipulations there, and I decided that I had enough.
@Ayende
Well you say it's not possible or only useable in very simple scenario's and I have to disagree. I can tell you that we work with this architecture in a complex business environment (a fruit and vegetable auction with complex price structures etc.). We've abstracted the UI, data and functions and we can currently run the same application on windows forms and WPF and we are working on a runtime for Silverlight and code generation for Flex. I don't see your point about 'if you miss something you'll have a lot of work'. To build the infrastructure that was and still is indeed a lot of work. If you need a complex UI control you will have to develop the control for multiple platforms, that is right. But isn't that always the case if you want to run an app on multiple platforms? One thing you are right about: debugging is harder, but doable. The other thing is that programming this way needs some getting used to. It's not for programmers who want everything done with designers. BTW we are working on a demo to show our framework to the world.
I wouldn't exactly compare a comprehensive framework and patterns for developing large GUI applications as a comparable solution to what can achieved with a simple URL + cookies. The Communication module alone hurts my eyes ( msdn.microsoft.com/en-us/library/dd458878.aspx). If you ever need more than a simple url to navigate to any view inside an app - you're doing it wrong. Also this is only useful for developing a single large application not for deep-linking and integrating between existing ones.
Yeah there are DOM manipulations, there's also a built-in templating language but more importantly a comprehensive set of well-tested, re-usable modules/widgets with a consistent usage, event, style/customization pattern used throughout.
I think the example of Justin's blog is unfortunate as everyone and their uncle begged him not to do that. I think the power of Silverlight can be seen in comparison to other plugins (e.g. Flash) as extending the DOM not replacing it. In that light, I think you'll see that now that Apple has softened this will continue.
The other use case is a cross platform desktop-like app (i.e. AIR). I see this as very powerful.
But anyone who is building public facing website exclusively using Silverlight is making a mistake and has been making a mistake. I wish HTML5 gave us a better story (the Canvas story is a joke without a markup story to me) and CSS3 is still just a maturation, not an evolution of a stying stack (really? still no named colors/brushes?)
Hi Oren,
I agree 100% that Silverlight is meant for web apps more than web sites.
We at 3M just deployed an application that we moved from pure web app to Silverlight. It works great, and we were very happy with the move to Silverlight. The app is public-facing: http://3m.com/vas if you're interested. We did the application part in Silverlight, and did some of the more "webby" parts, like sign-up/in, in HTML+JS+CSS.
The combination worked well. I think Silverlight will have a bright future ahead of it.
After a weekend of GWT, I'd take that over Silverlight (as a business app, I'm not going to look at the media aspect of Silverlight - and with that, I'd be more inclined to look for a html5 solution). This isn't to be negative about MS or Silverlight, just in terms of practicality.
GWT gives you the power of developing in Java - no javascript necessarily. You get 'state' and services - you can build your app similiar to Silverlight - except the main differences:
it's being run in a browser - and users expect a browser web site to behavior in a manner similiar to other web sites. Ayende mentioned a few, and I could build a list as well - it's a sense of 'this looks and acts like a web site, but it doesn't do things I'm used to' - I always felt this way with Flash/Flex, and Silverlight changes none of this. (Each version of Silverlight improves on this, but I feel I have to start all over with each new product - like 'geez, I've been here 3 times in my life already - can we get a faster 'grid'!)
no plugin. Native html/css/javascript is produced. It has a very nature feeling to it - whether your a 'win32' developer or a 'web' app developer.
debugging included. (I'm comparing here to a pure javascript app)
I see a much brighter future with something like GWT... why... simple: html5. Webworkers, better drag and drop, etc...
And speaking of ext-js - take a look: http://www.sencha.com/products/gwt/
This is all coming from a .net web developer who has done some Silverlight with Prism development.
Just one last thought here: Silverlight is good for the developer - no doubt - but is it good for the end user ? They have to wait, as described, they have to install a plugin, they get a hybrid app/web experience that is truthfully alien to most end users. So, i'd personally say no. I'm leary to pick this tool just because it's 'easier for me'.
Truthfully, I'm really surprised Microsoft hasn't picked up what Nikhil has done with Script# - to me this has more potential than Silverlight has. Especially with html5 - as mentioned again, I want a site that runs in a browers, on an android, on a ipad, on a iphone, on any internet capable device.
@Steve
" Just one last thought here: Silverlight is good for the developer - no doubt - but is it good for the end user ? They have to wait, as described, they have to install a plugin, they get a hybrid app/web experience that is truthfully alien to most end users. So, i'd personally say no. I'm leary to pick this tool just because it's 'easier for me'."
I built my first website in 1993 (text 'n links! ;)), started a webdesign business in 1996 and your remarks are exactly my words about Flash around 1997-> (back then, it was called macromedia flash). In 1996, I thought (and Sun did too) that Java applets would take the crown of doing advanced web stuff. What disappointed me back then was that the things it could do was limited to the applet area. With flash, same thing.
The availability problem for flash (and java applets, which never made it, oddly enough) went away when windows came shipped with flash: everyone had the plugin, so building a website with flash wasn't going to limit the audience. Still, the playing field for the stuff you wanted to do was limited by the area of the flash plugin in the web page.
Silverlight has inherited all these problems of its predecessors Flash and Java applets: it is limited to the plugin area on the web page and has to be installed (although MS is slipping sliverlight onto windows through windows update), so your remarks are spot on, although nothing new.
My old objections against Java applets (and flash, and thus silverlight), the limited playing field on the web page, is actually gone with Javascript and HTML 5/css3, well... more or less. The downside of HTML5/JS is that you need to run the latest browser versions. This might sound like 'yeah, but why wouldn't you?', but many people don't upgrade to the latest and greatest, just download patched versions (if at all). This has been true in the old days of netscape/mozaic and it is still true today. I.o.w.: before many websites will use the new goodies it will take a long time. And we all know that something else is then 'hip and new' and we'll be chasing that.
The above remarks are also the reason why I believe SL will in the end fail. Not because of its features or commitment of MS, but because it falls into the same traps as competitors Flash and Java applets have fallen into, plus it has disadvantages over Flash which are not fixable: flash is on every system, and every prof. designer out there knows how to use it and create stuff for it, using professional, mature tools. We as developers might think (perhaps rightfully) it sucks, but they don't care, like they never have.
I still wonder why developers haven't jumped on Java applets before, as you could do great things with it (also visual effects, although you had to revert to demoscene framebuffer coding for that ;)). Perhaps marketing, not sure.
GWT is indeed an amazing toolkit. Your remarks about it clearly show what MS should have done with .NET instead: create a GWT like toolkit for .NET.
Unfortunately, nobody, including Microsoft, seems to have enough imagination to see a future for Silverlight that is not constrained by the typical limitations of plug-ins.
Except Miguel de Icaza: http://tirania.org/blog/archive/2010/May-03.html
That's a real pity, especially for people who don't think that HTML and JavaScript should be the end of all innovation around user interface programming, but what can you do...
Unless that happens I agree with Frans: GWT for .NET, with full Visual Studio support, would be the way to go. Unfortunately, MS seems to be drunk with HTML5-Kool-aid too, thinking that together with jQuery this makes for an excellent native programming environment.
Ayende,
"Support for mobile devices, something that becomes ever so increasingly important, isn’t really there."
Silverlight is what they are using for Windows Phone 7 development. Or do you mean those mini-browser things?
So I RTFA and that's what you meant.
what is the difference between gwt and asp.net .
What about for a public facing web applicaiton. By that I mean, not the "website", but a web applicaiton which is SaaS based?
I see no issue with this, although alot of the distinctions people point out always say "Internal apps". Why not external? Again, I'm not talking about delivering content, but rather an actual complex applicaiton which is customer facing over the web.
What I don't understand is why the customer should care. The customer should use whatever application provides them with the best feature and allows them to do their job as efficiently as possible. What does it matter if it's in silverilght/html/flash? If it works, and it saves / makes them money, what is the relevance?
If a developer can produce faster results, shorter turn around time, more maintainable code and better results, why not choose the techology? This is good for both the customer and developer.
I have no bias here... other than from experience I find developing Silverlight code much easier and maintainable than html/css/javascript. All technologies are fine. But why the confusion of politics vs results?
Do whats best for the customer and the product. Deliver the best results now.
Steve/Frans --
Actually I believe Microsoft does have a .NET implemented on top of JavaScript -- see www.nikhilk.net/ScriptSharp-Large-Projects.aspx, in which Nikhil explains Script# is used for Office Web Applications (which, in case you haven't seen it, is just amazing).
Joe,
SL doesn't work on my iPhone.
Ziv,
thanks, I was vaguely aware of Script#, but until recently hoping to avoid it using SL. I was not aware that they used it for OWA though. Maybe not just the pet project I thought it to be... Time to take another look!
HTML/CSS/JS is so much better than Silverlight, just look at how much better Google Finance is than this Silverlight app:
http://www.google.com/finance
http://www.freestockcharts.com/
(/sarcasm)
I'm actually on a project where we're building a huge application using Silverlight and Prism. Granted, not a lot of thought went into why this was being done, but whatever. There are some 1,000 user controls and millions of lines of code behind, viewmodels, and wcf services.
It is not easy, nor is it pleasant to work with.
I could go into great detail, but I think what I've found most frustrating is just how hard it is to debug. You're looking at a screen trying to figure out what is going on and you can't just do View Source because it's all hidden from you. And often when silverlight fails at rendering the XAML is fails spectacularly, basically a core dump to IE that you have to try to interpret.
It's ok for small things, but don't let anybody talk you into building a LOB app.
Steve,
I assume you, big & complex apps with JS aren't fun to deal with. Not by a long shot.
And I am willing to bet that a lot of the complexity is the result of the approach that you have taken to develop things.
Steve,
and when you're done fighting your way through JS, though enjoying the ease of all the standard features such as view source during development, you deploy and start getting complaints from users who kill your app via the back button, Ctrl+N, get confused in browser tabs, mess with browser settings etc.
Then come back and tell me that this openness helps with developing LoB apps.
@Stefan
Who's killing apps with the back button? You're meant to support it - Do what the user expects and go back to the previous page the user was on. Use jquerys or google closures history widget and get this well tested behaviour for free.
The back button is a plugin problem and actually what kills silverlight/flash apps.
One of the most annoying things is Silverlight/Flash suppressing browser shortcuts. When a user presses Ctrl+N they expect a new tab so give them that. Its just another case of where a plugin feels foreign embedded inside a browser.
Demis,
"""
Who's killing apps with the back button? You're meant to support it - Do what the user expects and go back to the previous page the user was on. Use jquerys or google closures history widget and get this well tested behaviour for free.
The back button is a plugin problem and actually what kills silverlight/flash apps.
"""
Amen!
FLASH/SL apps are orthogonal to the browser experience from all sides. To me, text zooming and the back button are the most visible.
Had most SL fans here were working at Google when gmail was introduced, they would have killed the project since "it's too hard to do in a browser vs a plugin, and JavaScript isn't a real language". Granted, I hear their line: developing a web app is more resource consuming then SL. But still, if you are not future proofing your app, you may earn a lot today, but be hated/ridiculed tomorrow, such as those FrontPage developers of yesteryear.
From the twittosphere i hear of some Microsoft shops and developers who are recently checking Google's open-source tools (GWT, Appengine, Closure Library (esp the compiler/minifier), ExplorerCanvas, other APIs, charts ...., not to mention Java/Python)
Sure Microsoft will copy these in the future. My prediction: GWT First, then Microsoft will reimplement AppEngine in dotnet as the new Azure :-)
Oh, and my biggest prediction: Microsoft will open-source the entire dotnet stack and drop the patent hanging-sword. But this will happen only after they are force to do that.
@Demis that makes sense for web sites, but not sense at all for LoB apps. the app is supposed to behave as the app author intended it to, anything else just causes development, testing and training costs and potentially breaks the app. nothing is free, no widget can prevent side effects that are caused by a user repeating a task in a position that the app author did not explicitly handle.
start a SL app OOB and you're free from all that crap. that's what developers need, and there's no problem with that for users. they don't expect a back button or tabs in a fat client app either.
@Meini,
"Had most SL fans here were working at Google when gmail was introduced, they would have killed the project"
that's the kind of thinking that slows everything to a grind. google is just google. they can afford that. they can even afford building a complex app like wave using HTML, using a team of probably very gifted developers just to see it crash several times at the presentation and later dump it. they can afford that.
these days, everyone seems to think they have to build their enterprise apps as if they had millions of users, required ridiculous amounts of concurrency, partitioning etc, needed to be equally available on every last device etc.
repeat after me: i am not google. i am not amazon. relational DBs with acid transactions and complex quieries in live data might work perfectly well for me. i can still chose to take the different route where it is required. but often, life can just be simple!
(besides that, i insist that with a little imagination, SL and related technologies could be built into browsers too, making much of the plugin friction go away)
Ummm, that makes sense for all websites / web applications. If your app is designed correctly use links when you're supposed to and Forms/HTTP Posts where appropriate everything just works. High Training costs are the results of bad UX - not because it behaves like other websites which users are most familiar with since they spend most of their day navigating websites. i.e. Not Silverlight/Flash apps.
There shouldn't be any special treatment just because its an internal website.
You mean like breaking basic browser functionality? Like using the back button which is the most important button in a browser? The back button allows the user to navigate back from where they came and its importance is fundamental in providing a good UX in navigating a large website without fear of getting lost. It keeps the user in control which if you want the user to understand and use your application is paramount.
@Demis sorry, but I can tell from what you're writing that you've never created a decently complex LoB app. you're living in a different world, which is ok, but why do you have to push your opinion on people trying to accomplish totally different things?
@Stefan Wenig
Funny guy, because my websites don't have problems? Different world? where 90% of the apps are written in Silveright? Really pushing opinions? Like make websites behave like a normal websites and caring about UX and not breaking the back button??
Making assumptions of what I have / have not accomplished are you? Your total recommendations essentially boil down to: Screw the web - use Silverlight!
My guess is because of your lack of experience developing proper applications on the web. Sounds like its you who might need to get up to speed on how to write usable applications for end users.
I was just saying that you're using the web for different things than you're trying to get me to do. If that's enough to cause an outburst of bad behavior, then this discussion is over.
That's exactly the kind of bullying that RIA supporters seem to have given in to, btw. Everyone thinks HTML is the future? Well, let's not bet on anything else then. They are so loud, they will eventually win.
Why does nobody start with the question "do I actually want HTML to be the (only) future?"
Or, "do I really want to implement that 500 page customer specification using javascript?"
Well, shame on us then.
Please highlight where I have ever tried to get you to do anything?
Agreed, lets end it. There's no meaningful discussion to be had with your straw-man arguments and opinions on my world views. The so-called outburst eventuated when you stopped talking about anything remotely tangible and decided to highlight that my writing was the result of my lack of accomplishments in the topic of discussion.
highlighting is off, quote:
so you claim that what you prefer is the only right way, not just for the kind of things you've actually built yourself, but for anything. the arguments you present are correct in a certain context, but don't relate to the stuff some other people are doing every day, or to the problems they are facing. simple as that. no need to get all defensive over not being in the LoB business, or insulting for that matter.
That quote is referring to how web sites or applications on the web should work. If you're developing an application that runs in the browser you shouldn't break well-understood conventions and metaphors (which most plug-ins embedded in web pages do). I didn't say not to develop desktop applications or that all applications should be websites. Infact that's one of the only niches in which I said Silverlight makes sense.
That's the thing, A significant part of my career is a back-end systems developer developing internal business apps using WinForms/WPF/Flex apps as well as Websites. I naturally take offence to that my pro-web stance is confused with a lack of experience building LOB apps.
Forgive me for not always re-reading the entire thread and just answering one post at a time.
I was explicitly not defending the role of SL as a plugin. I regret that the Web seems to be damned to be a place where nothing but HTML et al is allowed to live, but I explicity pointed to other options, such as OOB or integrating CLI/SL with the browser in a deeper way. (The key is they'd eventually have to be standardized.) If you ignore this and repeat that the most important thing for LoB apps is to support the back button, and these things are never any extra work, we'll have a hard time having a productive conversation.
If you actually think that building large LoB apps using HTML is as simple as doing it using SL or WPF (can't speak for Flex), we just have different opinions. No way we'll sort that that in a online discussion.
But you might just think that some apps just shouln't be in the web? That's exactly the problem that arises from the web being limited to HTML: incompatible proprietary technology islands are created to solve the deficiencies of HTML, both in terms of what you can do and the developer experience. If the web would open up, allow for some competition again, standardize later, we could actually have progress without these.
Other people think that WPF & Co are just lock-in technologies (I agree) and we should therefore just surrender to HTML (I don't).
Seems we have digressed. However, could of notes from above:
Script# - great work - but just a technical note - it's not currently sponsored by Microsoft. It's created by an employee of Microsoft. Also, it's not currently open source -although I saw a note that in the roadmap the intent is open source. Great stuff, but honestly, I'm very nervous about structuring my client's bread and butter applications in this regards. If it goes open source, or get's support, etc... then certainly it makes for a more viable option. I think it makes it harder to justify.
I don't mind an 'out of browser' Silverlight application. That tends to blur the lines where the user isn't in a browser, it's more of a 'slim WPF' with smaller footprint. That part - I actually think is pretty cool. AIR was mentioned - and AIR to me has the same more acceptable approach as a Silverlight OOB.
Stefan Wenig, from your comments, i get a sense that you are dreaming of a future full of SL. Meaning more jobs, more apps, and higher market share for the plugin, say 95%, (screw those 5%, they should get Win :-)
unfortunately, your dream is my nightmare :-)
One more thing. You may buy the "SL is cross-browser" spill from msft. I certainly don't. I'm older. Did you know that there was an IE for the Mac? Did you know that there was even IE for Unix? I'll let you find more examples. MSFT does things only for their interest. Many companies do, and usually it's OK. But consider:
1) What Google contributed as open source cannot be taken away
2) When you talk about communication technologies, i.e. protocols, image formats, multimedia formats, etc. these shuld be open.
@Stefan Wenig
Yeah there may have been some confusion, I was only ever talking about web apps vs Flash/Silverlight plugins.
I consider Out-of-browser Silverlight to be more a Desktop application UI framework which in this space also competes with Adobe Air, Java UI (Swing & SWT/RCP) and QT cross-platform UI frameworks. If you need Desktop-like features that doesn't need access to native libraries then Silverlight is a good solution - I don't think this was the topic here though. A further question would be why Silverlight over WPF (if you only needs to run on Windows)? But that's a discussion for another post.
This SL app we're building is data entry. There's nothing we are doing that really . The most complicated javascript type thing would have been the menu and maybe some calendar controls.
Stefan,
It's funny, but you remind me of myself 10 years ago. I used to defend ActiveX, but you know looking back it was a bad choice... just like Silverlight is for building business apps.
Use Silverlight for streaming video, that's what it is good at.
Silverlight isn't cross browser. We see behavior differences between Firefox and IE just on Windows. There are notable differences with Mac.
and it doesn't run on Linux.
HTML does, that's why HTML works.
Steve,
SL certainly run on Linux. That is what Moonlight is all about
Steve,
To be fair, given that most ActiveX was C++ apps, I would choose HTML over that in a heartbeat, too
@Demis, you can consider this out of scope, but that's where the fun is. If you accept SL as a web plattform, you can handle it like a browser. just point the runtime to a URL, execute the app, done. no restrictions, just like HTML, but without the disadvantages of a decades-old design-by-committee mix-of-technologies platform that was always intended to create content, not apps.
java on the client is dead, for whatever reason. i guess the UI libs sucked, but it really doesn't matter. flash is proprietary only. no way it will ever be available on every platform/device. SL could be via moonlight. Qt needs native compilation. does not compete in this game.
@Steve, it's funny I remind you of your past self, but even 10 yrs ago I thought ActiveX was crap. I really don't understand how you can compare them.
SL is available as Moonlight, patents for large parts are open via the OSP, and before anybody reminds me that XAML and other things are not: yes of course, if SL was to become a major web platform, MS would have to put everything under OSP that would be part of that package. also, once we get over the mono-hating and accept moonlight as a viable player, it could easily innovate on it's own.
it's really not that hard to imagine once you get over the bah! microsoft, and bah! plugin reactions and actually try to think ways that would make SL a good option.
but all of this is theory, MS is not behind it. miguel de icaza tried a bit, but the response was less then enthusiastic and I guess that's it. About as useful to think about that as it is to think about why java didn't make it on the client. just didn't. it's a pity though.
so we can either build SL plugin/OOB apps and hope that MS doesn't grow tired of supporting it, or build our apps using HTML. of flash, or native apps for that matter.
the future sucks.
@Meni i already mentioned Moonlight and the OSP. either you're not aware, or you chose to ignore it. fine.
I don't know why my options are your nightmare. obviously to a large part of the HTML-crowd, other people's choices are evil. you wouldn't have to use it.
BTW, I don't care about multimedia codecs or anything in this context.
@Steve Gentile:
100% agree about Script# not being a technology to bet the farm on. interesting though that they built office web apps using this...
yes, please microsoft, open source that!
as for plugins: read http://tirania.org/blog/archive/2010/May-03.html
many things are possible. it just takes some thinking outside the box.
Until Moonlight releases on the same timelime as Microsoft does, it's not a viable option. Right now it supports SL2, but most Silverlight development is done in SL3 and SL4.
So how do you deploy your silverlight app to Linux users? Publish the application through Citrix?
Why not just use HTML and have it work to begin with?
if you want to address linux, restrict yourself to the current feature set of moonlight. it's really that simple. also, a generally acceppted plattform based on SL technologies would have to be based on this same common ground and be fully covered by the OSP or similar.
your argument is the same as saying that you cannot create cross-plattorm apps in HTML because IE is always behind.
@Stefan
Yeah and then you're back to running it as a plug-in again, watching the loading sprite waiting for it to load, running an application inside and application changing how its parent is supposed to run, and all the other fun quirks I talked about earlier. Yeah its not like HTML doesn't load or behave like it, it's only similarity is that it uses XML for its UI markup. Even with the benefit of hindsight Microsoft isn't able to match the simplicity, expressiveness and power of CSS. And that 'decades-old design-by-committee mix-of-technologies platform' is responsible for the most successful phenomena in technology known to date.
No one's mono hating, my entire open source web services stack ( http://www.servicestack.net) runs on Mono, hell it even runs on MonoTouch ( http://www.servicestack.net/mythz_blog/?p=417) -. Those guys are cool.
I'm not anti Microsoft, I'm anti their NIH approach to creating new technology. Rather than provide enhanced solutions to enhance what's already out there they choose to re-write and provide a supplementary implementation. I would much rather they focused on bringing C# in the browser then creating yet another RIA plug-in and lock people into their world. It's another example of their all-or-nothing solution which is reminiscent of their approach with SOAP where rather than embrace HTTP and its REST-ful architecture they focused on creating a complicated specification that routes everything through HTTP POST controlling the entire software stack whilst at the same time giving up a lot of advantages inherent in HTTP ( http://www.servicestack.net/mythz_blog/?p=154). Eventually I believe simplicity and power will win, which is why I think most web services created and published today are not SOAP-based.
I would agree that Silverlight OOB is a great choice for a light-weight managed cross-platform Desktop. Although as you might have noticed I don't agree with it as a plug-in, I have my reasons for disliking it - others may have equal reasons to prefer it.
Although I've never been a fan of Java UI, its a memory hog, it been responsible for some of the most sophisticated cross-platform applications to date in Eclipse and IDEAJ (and all other Jet Brains IDE's). Adobe makes Flash and Air players available for Windows, OSX and Linux and Android today there's even an open source implementation ( http://en.wikipedia.org/wiki/Gnash). The flash packager for iPhone also enables flash application to run on the iPhone. There's even an open-source flash player that plays flash .swfs using pure javascript and SVG (No flash player required: http://paulirish.com/work/gordon/demos/). It has much better cross-platform support than Silverlight.
@Stefan
Not the same thing, you can provide enhanced functionality to advanced browsers that support it whilst degrading gracefully for older ones. You can't do that with Silverlight, if you don't write for the minimum base-line it won't run.
Demis,
"I'm not anti Microsoft, I'm anti their NIH approach to creating new technology."
Amen to that! Also, Microsoft is bound to make a dotnet copy of everything Google is doing. For example GWT and AppEngine. Not only that but all the many fine open-source libraries of Java. Oh, the effort! And it's going to be a few years behind.
RE Microsoft, here is an excerpt from a blog post at msdn:
1) The cloud creates opportunities and responsibilities
2) The cloud learns and helps you learn, decide and take action
3) The cloud enhances your social and professional interactions
4) The cloud wants smarter devices
5) The cloud drives server advances that drive the cloud
WTF? Had i been working with Microsoft technologies I'd really start to worry. Morons at the helm.
@Demis
"You can't do that with Silverlight, if you don't write for the minimum base-line it won't run."
not true. if you use a static language like c#, it's more difficult. the best way might be to use conditional compilation and build two versions, but there are other ways too. and there's room for improvement, things that MS could do if SL should become a standard that they then extend. you could also use a dynamic language in SL.
but the point is that unlike web sites, an app is something that should be tested in every configuration, so it's probably not a bad idea to build different versions at all. littering user agent checks across an entire app is a much worse idea than doing this on a web site.
@Stefan
Building different versions for each configuration is an admin, deployment and versioning burden which is why its avoided if possible. With web applications you are running and testing the same website, there is one url, one version.
this boils down to a preference between static and dynamic typing, flexibilty vs. compile time safety. if that's what you want, and you want to address different SL/ML versions with different features, SL + C# is hardly for you. SL+Iron* might be.
Silverlight is ideal for internal LOB apps.
Silverlight fanbs, how about this scenario: MSFT buys Facebook, put Silverlight in Facebook pages. [BTW, this almost happened, IMO, with Yahoo]
To me that would be a nightmare!
Some fanbs are saying Silverlight is for apps/LOB, and in contrast HTML is for pages. Would FB be an app or not? Discuss pls
-meni, open-standards fanboi
what if MS bought FB and re-implemented it using ActiveX?
FB is not suited for SL at all.
Stefan, you brought up an interesting point, ActiveX. I see many similarities between ActiveX and Silverlight. The main one, is that with both, Microsoft is tempting developers who think web development is too hard. With both, microsoft is saying: use your current skill-set.
Yes, there are differences. The main one I think is that Microsoft "learned" from it's activex failure and market SL as cross-platform. Only fanboys buy that, i see it as a bait. Also there are some security differences.
Don't misunderstand me. Silverlight is great technology. But it's not s standard, not open, and not cross-platform. I think it will be someday. MSFT has no choice.
it's available for Win, OS X, WP7 from MS and for other platforms in the form of Moonlight. if only fanboys can see these facts, so be it.
but that's beside the point. I'd be calling for a brave effort on the side of MS to get beyond that, standardize, open up, and make SL an alternative platform.
not only for people who are to stupid to code html, as you make it sound, but also for those who need to build more complex stuff than the average web developer can even imagine in a limited timeframe.
Comment preview