figuerres said:

TommyCarlier said:

*snip*

Tommy - ok half way true....

 

but AJAX does depend on the browser running javascript

and i have seen that break it more than a few times.

 

some times a client will just puke if some error happens in the clients script and if that script works on other pc's then we are left with an unstable app and we do not know why ...

 

we wind up taking the pc and re-loading the browser to try and fix it. (well the tech on site does anyway).

and it does not fail totally.... it just crashes/hangs when they are in the second or third part of a data entry process.

fuguerres, tommyCarlier, great comments. Tommy is right gmail is a great example to show that JavaScript/Ajax works if done right.

If you listen to Douglas Crockford, he is on a mission to talk about the Good parts of Javascript; he would argue that if done right it is a good language to write apps in once you learn to avoid the bad parts!  

And now you have JQuery and RxJavaScript etc to make it easier to write better apps. 

Also as far as I know silverlight does not run on Linux, does it?

If we all were to embrace the Javascript/HTML paradigm would we be able to create a better JavaScript, and evolve the browser DOM. Yes, this is all standards work, but there is no way to get a cross platform work except through some standards work. 

ManipUni said:

What is the benefit of moving IE9 to the CLR? You asked why it isn't, but you never really said why it SHOULD?

 

If your reasoning is security then frankly IE9 could do more good by dropping back-compatibility with every existing addon and OS tie-in, and only allow back in those that supported low privileged execution. If they developed a CLR version and supported existing addons etc then it would do absolutely no good at all.

 

Frankly I'd like to see all browsers move to a "whitelist" model for automatic file type execution... Drop PDF, Office Formats, and unknown formats entirely from auto-starting and require the user download, save, and run them.

I did...touch on the benefits of writing IE on the CLR earlier in the thread...

if IE were written on the CLR we would get a lot of benefits. The innovation in the browser would drive the evolution of the CLR and vice versa. 

When Javascript needs a runtime we could use the CLR to build it? So it would become a first class CLR language. So if I need to create a library and use it outside the browser I could just do that.  We could also imagine generating Javascript libraries from .Net languages!

here is an example of the kind of things we would get; when the browser folks need to create the concept of isolation so that tabs would not crash each other for example. We could use the same technology in our .Net apps. 

The browser folks would benefit from any good work that was done on the CLR; new techniques to code for concurrency is a good example. 

there are many more benefits... 

AndyC said:

Because the vast majority of IE is a component that can be hosted inside other processes and those processes do not necessarily want to take a large dependencie on the CLR for very little benefit (and in some cases, i.e. CLR 1.0/1.1 apps, wouldn't be able to if they wanted).

Technically I think that a clr based browser would work just as well; and perform just as well. If it did not then it would push the CLR team to make a better runtime. 

The discussion about legacy investment and when to change that is a business decision. I think Jason Zander and VS team require kudos for writing thier UI in .Net. I think that overall this was a big win, we got a better UI but more importantly we got a lot of feedback to the WPF and CLR teams about improving things. Which benefited everyone!

I think that if IE were written on the CLR we would get a lot of benefit in this sense. And the innovation in the browser would drive the evolution of the CLR. And when javscript needs a runtime we could use the CLR to build it perhaps?

And I would say the same about the office folks! The enormous investment in COM is holding back innovation. 

Windows I do not know, perhaps that is a lost cause. Maybe someday we would have a CLR based OS? 

Remember we have challenges like switching to taking advantage of multi cores and GPUs that we could all share and use if we built on the CLR and developed good libraries to represent all the innovation. All the algorithms and innovation at the core of IE is opaque and unavailable; conversely the innovation on the CLR and from the community is not available to the IE team. 

turrican said:

I have been pondering the same thing myself. I think Silverlight is great for most of the "regular" user apps, no more chasing users with updates etc so it's nice. But WPF still is needed, for example in business and enterprise where you need to have local access to the PC without the sandboxing of Silverlight.

 

I got a pretty huge app in winforms which I ponder to rewrite soon, I still haven't decided to go WPF or Silverlight but I'm very much leaning towards Silverlight since it now how rightclick contex menus for example.

 

Good thing about XAML is that if I go Silverlight and get stuck on something, I can pretty much convert that app to WPF without too much headache.

great comments turrican! I was in the same boat, with the winforms situation and large applications and client base. I was waiting for wpf to mature, get more performant and controls to become available from the vendors etc. But in the mean time FLEX and HTML5/javascript arrived and so did Silverlight. So we have to reevaluate. It is good that we are discussing this. WPF right now is presented as THE option for RICH windows only standalone applications. But if we could get RICH browser based apps would we take it? I think that the quality of the browser based app is not good enough, and the programming model is not great but that is changing as we speak? And looks like people would like to combine RICH and REACH apps if they can get it!

How much innovation is happening in WPF? how many talks at MIX on WPF? Where does that leave us?

sysrpl said:

Developing text based content, such as a news article, a forum for users to exchange messages, a listing of online products, is so much easier than producing audio or video based content such as a news video, a voice chat message board, or an interactive animated product brouchure.

 

As such...

 

HTML and JavaScript = The standard for delivering web sites. Everyone uses it, everything supports it, does just everything you need.

 

Silverlight/Flash = You want some video, sounds, and animation in a web page. Fun to use, but mostly impractical.

 

 

it is still early days, but with all the audio and video support in HTML5 and IE9;

Javascript and libraries like JQuery

backend services based on  ODATA (a.k.a ADO .net services) or GDATA or REST in general

 we have a good platform for building good cross platfrom browser based applications. 

with all available what are we getting with silverlight.

Look at apps http://www.zoho.com/ or all the Google apps (Gmail included) they demonstrate that this works quite well. 

How do we justify all the investment in silverlight? I thought that is was because we could provide a rich experience (including audio/video) but that is all changed now that we have IE9 and HTML5 isn't? Could some one from the IE and silverlight teams comment? 

figuerres said:

Dev:

I would say that SIlverlight is very very very far from dead.  Flash too.

why? many details but here are a few issues:

 

HTML5 does have a video tag yes... but it does not address issues like DRM and business like cable companies and pay-per-view will not go with a NO-DRM solution.

also related is that HTML5 does not specify one video format so site owners face a problem of do they make every video on like 3-4 formats (possibly more?) or use something like Flash or SIlverlight to keep one video format?

 

leaving video now lets look at JavaScript/EcmaScript:

 

if i am trying to make money on the web and i use script + html then i am totally left open to copying of my work by any 12 year old kid.

while silverlight does not totaly protect me it at least packages the work and makes it slightly hard to copy.

also if i want to distribute a silverlight app i can send a xap file to folks all packaged.

 

and now what about a browser that has scipt disabled? or the script engine is bugged? a plain html page w/o any client script can still use and run silverlight.

 

also not everyone will have html5 right away... some folks may never get it in some corp. network cases.

 

and silverlight can run out of browser with no internet connection....

 

and you can use other programming languages than just C# and VB .... with javascrip you can only really use that....

 

also the XAML markup can create layout that can be very hard to do in html.

and html does not render the same on all browsers....

and silverlight can "chnage pages" locally which standard html does not do.

 

and there are many other details of why SIlverlight compliments html and they are not exclusive to each other.

good points figurres! Can anyone who is an expert in HTML/Javascript please respond. 

A couple of comments I do not have any solution to you question about code security. But maybe the revenue model is not from selling the code and protecting it but by getting ad revenue? 

..if the Javascript engine is turned off it could also be the Silverlight plugin is not installed. 

Also we do not have silverlight for all platforms linux for example?

The Javascript experts would argue that you do not need other languages and that Javascript is a pretty good language. And Eric Meijer was talking about using Javascript as the "assembly language" for the web; so  you could imagine generating Javascript from other languages soon. 

The html standards we can all hope will remove some of the other problems you mention.

PaoloM said:

Yeah, no.

 

HTML5 + JavaScript still does not provide the experience that Silverlight (especially with v4) can do. Besides, HTML5+JS is purely a browser technology, Silverlight is not limited to that anymore.

Paolo could you please elaborate on your comments? What features do you have in mind that provide a richer experience? Did you see all the rich interaction and graphics for IE/HTML5 that was demoed at MIX? I think that does change the equation significantly.

And maybe we can work out a way to build a CLR runtime for Javascript so it can eventually run outside the broswer and even be compiled as well. 

brian.shapiro said:

DevJunkie111 said:

*snip*

XAML is really a more powerful, flexible development platform. XAML and HTML5 will not be equivalent by any means.  Compare how easy it would be to make a circular listbox (as an example) in XAML vs in HTML5. However that doesn't mean XAML should one day replace HTML either, imo. The thing about XAML is that with its flexibility is a lot more complexity and is only friendly to use if you're an experienced developer. It also depends on a very specifically designed object framework, whereas the DOM is a lot simpler.

thanks for the comment brian, if you noticed I started a new thread to discuss this further. 

Please contribute. Do we really need these two approaches to build browser based Ui's?

on the future of browser based UI development.

I remember having a discussion a while ago about wether we needed to "invent" xaml and why we could not just evolve HTML instead. Looks like we have a clear answer now thanks to the community who pushed for HTML5. What a waste of time and resources with all the investment in silverlight and xaml, if it is going to die eventually as it should! There was all this emphasis on GPU support and rich graphics that wa available via Silverlight. Looks like that is not the case any more with IE9.

Funny I though that this Mix conf was about highlighting silverlight4; now it looks like the silverlight funeral with all the announcements on HTML5 support; i see no sense in silverlight anymore , am I missing something?

I was just getting ready to invest time in Silverlight4 for browser UIs; maybe it seems much more sensible to invest in HTML5 + Javascript; Can we get some more intelligent comments to help clarify? 

So far it seems to me that Javascript  wins by a knockout with IE9 support! 

Bass said:

DevJunkie111 said:

*snip*

The difference is HTML5 is an open standard with wide industry adoption. Silverlight is a properitary Microsoft technology.

 

From Microsoft's perspective they would rather you use Silverlight. They have more control over that, and their whole business model basically revolves around platform control. HTML5 doesn't really fit into that well.

 

I suspect HTML5 support was not Microsoft's idea. "HTML5 support was my idea."

 

Many (most) web designers seem to be firmly supportive of an open web, and Microsoft is not able to ignore them anymore.

Bass that is a good point; i remember having this discussion about wether we needed to "invent" xaml and why we could not just evolve HTML instead. Looks like we are there now! Thanks to all the developers who pushed for it. What a waste of time and resources with all the investment in silverlight and xaml, if it is going to die eventually! At that time; there was all this emphasis on GPU support and rich graphics that was only available via WPF and eventually silverlight. Looks like that is not the case any more.

Funny I though that this Mix conf was about hightlighting silverlight4; now it looks like the silverlight funeral with all the announcements on HTML5 support; i see no sense in silverlight!! I was just getting ready to invest time in silverlight4 and maybe seems much more sensible to invest in HTML5 + Javascript. Can we get some more intelligent comments to help clarify? 

I will start a new thread to discuss Silverlight v.s. HTML/Javascript.

exoteric said:

spivonious said:

*snip*

Nonsense. These are not replacements, these are complementary. But yes, it's overwhelming at times.

At least it doesn't make any sense to stop progress because we can't keep up with everything.

Thank you for all your posts, your comments are insightful. 

It is totally overwhelming!

Today I was watching the ie9 talk. So now you have HTML + JavaScript and ASP .net mvc as options to write UIs thrown into the mix.

And all of these technologies are evolving rapidly.

Given that writing good UIs is still a great challenge all these different UI technologies and frameworks make it hard for developers to focus on the "real" problem of designing and building good UIs; instead time and effort is spent on learning all these frameworks. These are not just different in terms of ideas like XAML vs HTML for mark up they also differ in strategies for managing state(Client vs. server). If we were going to be investing in HTML5; why could we not have invested in it more, so we would not need XAML? We could have built WPF engine on top of the HTML5 DSL for UIs.

And while we are discussing this, let us think of also of the complexity of many implementations of MVC, MVVM (Too many implementations to list out; corrected based on comments from wkempf).

Is this not getting way too complex?

Of course we should not stop progress in anyway; but perhaps we can do better?

Am I missing something? Please help me understand I really appreciate it.

What is the scenario here, how can we justify haveing two major UI frameworks with minor differences in the api and intricate differences in the core implementation.