Silverlight&Moonlight

Please compose all posts in Emacs.

Moderators: phlip, Moderators General, Prelates

User avatar
wubrgamer
Posts: 75
Joined: Wed Feb 13, 2008 1:06 am UTC
Contact:

Silverlight&Moonlight

Postby wubrgamer » Tue Jan 20, 2009 11:25 pm UTC

http://www.mono-project.com/Moonlight

So what I take from that site is that M$ and Novell are working to open up silverlight for *nix platforms.

Sounds like a good thing.

Will/Does this end the "WE HATE SILVERLIGHT" feelings that much of the *nix community seems to have. (at least from my understanding...)

Discuss.

User avatar
b.i.o
Green is the loneliest number
Posts: 2519
Joined: Fri Jul 27, 2007 4:38 pm UTC
Location: Hong Kong

Re: Silverlight&Moonlight

Postby b.i.o » Wed Jan 21, 2009 1:17 am UTC

In my experience, Silverlight is a hell of a lot less processor intensive and buggy than flash. The Linux implementation of flash regularly ends up maxing out one of my processor cores playing a flash video online, which is ridiculous when you consider that my processor is fully capable of handing 1080p video. And non-Adobe Flash implementations are even worse, since flash has for most of its lifetime been a closed format and thus has to be reverse-engineered. Silverlight, on the other hand, has open specifications (which forced Adobe's hand in opening up flash somewhat), although it is not completely open and does require binary blobs for its media formats.

tl;dr: Microsoft's doing a lot better than they normally do and a hell of a lot better than Adobe at providing an open web multimedia platform.

There was a Slashdot story earlier today about some last-minute Moonlight patching to get Silverlight working in time for the inauguration today that had some surprisingly lucid (for /.) commentary on the whole Silverlight vs. Flash thing.

User avatar
OOPMan
Posts: 314
Joined: Mon Oct 15, 2007 10:20 am UTC
Location: Cape Town, South Africa

Re: Silverlight&Moonlight

Postby OOPMan » Wed Jan 21, 2009 7:45 am UTC

Silverlight is about as lame and iritating as Flash. Moonlight is worse.
Image

Image

sakeniwefu
Posts: 170
Joined: Sun May 11, 2008 8:36 pm UTC

Re: Silverlight&Moonlight

Postby sakeniwefu » Wed Jan 21, 2009 2:47 pm UTC

OOPMan wrote:Silverlight is about as lame and iritating as Flash. Moonlight is worse.

Hopefully, some day, someone somewhere will realize that HTML and ECMAScript standards are and have always been more than enough to display their crappy content and Flash and Sliverlight will go the way of Java applets.
I hate Java, I hate Flash, and I will hate Silverlight once retarded webmasters actually start using it.
Any person involved in any of those three abominations should be hung for crimes against humanity.
:x

User avatar
Xanthir
My HERO!!!
Posts: 5410
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Silverlight&Moonlight

Postby Xanthir » Wed Jan 21, 2009 3:45 pm UTC

wubrgamer wrote:Will/Does this end the "WE HATE SILVERLIGHT" feelings that much of the *nix community seems to have. (at least from my understanding...)

I have no opinion on Silverlight as a Linux user. I HATE SILVERLIGHT as a web developer only, where it destroys the open nature of the web, ruins device independence, and kills my ability to customize my experience.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
phillipsjk
Posts: 1213
Joined: Wed Nov 05, 2008 4:09 pm UTC
Location: Edmonton AB Canada
Contact:

Re: Silverlight&Moonlight

Postby phillipsjk » Fri Jan 23, 2009 7:09 pm UTC

On topic: I think the fear in the *nix community is that Moonlight will always be behind. Developers will default to Microsoft's implementation, and simply not test under Moonlight. It will be a repeat of the browser wars with a new twist on the JScript and ActiveX debacle.

Straying off topic: I still don't understand why they haven't dropped ActiveX yet. It is an obviously bad idea; which brings me to my other point:

Why, with the proliferation of malware and obnoxious sites, do "would-be" web standards keep treating data as executable code?
You want video? Why not an open format that can be played by the video player of your choice? (DRM/Technical Protection Measures (not exactly the same thing))

My bias: I have never liked graphical web-browsers or using a mouse to navigate.

Edit: I actually like Java (not to be confused with Javascipt). It is explicitly designed to run untrusted executable code in a sandbox. While you could use it to write a video player, I can't see people trying to abuse it as a video format.

Edit2: okay, maybe the phrase "would-be" web stanadards was unclear. Web-developers of high-profile, well funded sites seem to prefer flashy, controlling "portals" over substance and accessibility. I am ranting a bit in this post.
Last edited by phillipsjk on Sat Jan 24, 2009 3:04 am UTC, edited 1 time in total.
Did you get the number on that truck?

User avatar
ash.gti
Posts: 404
Joined: Thu Feb 07, 2008 1:18 am UTC
Location: Probably a coffee shop.

Re: Silverlight&Moonlight

Postby ash.gti » Fri Jan 23, 2009 9:35 pm UTC

phillipsjk wrote:Why, with the proliferation of malware and obnoxious sites, do "would-be" web standards keep treating data as executable code?
You want video? Why not an open format that can be played by the video player of your choice?


Do you know about SMIL? Its a media standardization so you can embed stuff like video/music into html in a standard way. SMIL+SVG actually give you basically every feature Flash/[Silver|Moon]light offer. Just right now, no browser fully supports the SMIL standards but you can get around that by linking to Apple's Quicktime or Windows Media Player they have some SMIL support, and some browsers (like Webkit and some higher versions of Firefox) offer SVG support.

It will probably be a few years before any of that becomes mainstream because the browsers need to catch up to the standards, and then people need to actually adopt the browser, but when that happens it will be really nice to.
# drinks WAY to much espresso

User avatar
Xanthir
My HERO!!!
Posts: 5410
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Silverlight&Moonlight

Postby Xanthir » Fri Jan 23, 2009 10:10 pm UTC

phillipsjk wrote:Straying off topic: I still don't understand why they haven't dropped ActiveX yet. It is an obviously bad idea; which brings me to my other point:

They? You mean Microsoft? Nobody else supports activex.

Why, with the proliferation of malware and obnoxious sites, do "would-be" web standards keep treating data as executable code?
You want video? Why not an open format that can be played by the video player of your choice? (DRM/Technical Protection Measures (not exactly the same thing))

*Actual* web standards (not Silverlight) now define the <video> tag, which can point to videos in your preferred format, and as long as the browser understands what they are, it'll play. Done!
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
phillipsjk
Posts: 1213
Joined: Wed Nov 05, 2008 4:09 pm UTC
Location: Edmonton AB Canada
Contact:

Re: Silverlight&Moonlight

Postby phillipsjk » Sat Jan 24, 2009 2:55 am UTC

By "They" I meant "Web-developers building your average high-profile website."

I haven't been keeping up with the latest web standards since HTML 4.01 and CSS2.

My favorite browser (Lynx) did single-pass rendering. This makes it incompatible (except for graceful degradation) with anything newer than HTML 3.2. The separation of content and formatting requires the DOM. The DOM seems to imply JavaScript support. (sakeniwefu used the more formal ECMAScript).

Client-side scripting in the browser has always struck me as an ugly hack that takes far too much control away from the user. 15 years ago, telnet from a computer emulating a VT100 terminal over dial-up was doing a lot of what "Web 2.0" is being asked to do today. Printing on the remote server even sent the job to the local printer (I was surprised it worked without special fiddling).

Sure, you get pictures and video now, but I miss being able to access magazine databases or card catalogs over telnet. The new card catalog is web-based. It just doesn't feel like you are interacting with a program on the server anymore. (obligatory Get off my Lawn?)

Xanthir: Yes, for ActiveX, ."they" would be Microsoft and any third-party that would be silly enough to require it.

Edit: downgraded "20 years ago" to 15.
Did you get the number on that truck?

User avatar
OOPMan
Posts: 314
Joined: Mon Oct 15, 2007 10:20 am UTC
Location: Cape Town, South Africa

Re: Silverlight&Moonlight

Postby OOPMan » Mon Jan 26, 2009 7:05 am UTC

sakeniwefu wrote:
OOPMan wrote:Silverlight is about as lame and iritating as Flash. Moonlight is worse.

Hopefully, some day, someone somewhere will realize that HTML and ECMAScript standards are and have always been more than enough to display their crappy content and Flash and Sliverlight will go the way of Java applets.
I hate Java, I hate Flash, and I will hate Silverlight once retarded webmasters actually start using it.
Any person involved in any of those three abominations should be hung for crimes against humanity.
:x


Can't say I agree on that. HTML + JS may once have been more than enough but things are starting to stretch a little thin at this point. Sure, we have Web 2.0. Sure, Web 2.0 produces "pretty" web sites.

But let's not kid ourselves. HTML was never really designed with this kind of thing in mind and neither were browsers.

At this point web development is pretty much a world that looks pretty up front but, underneath the hood, it's a mess.
HTML was never really designed with GUI interfaces in mind and writing good GUI-based web applications using HTML + JS is basically just one ugly hack laid on top of the next.

To be completely honest, I think the whole thing needs to be rethought and approached with some actual foresight.

Web development is a pain and will remain so until someone breaks the mold completely, ditches HTML (Although keeping an improved version of JS couldn't hurt)

Of course, that's not likely to happen given that clout HTML has in the real world...

Which sucks...

Same story as always. The system sucks, but getting people to use any other system is really really hard.
Image

Image

User avatar
phillipsjk
Posts: 1213
Joined: Wed Nov 05, 2008 4:09 pm UTC
Location: Edmonton AB Canada
Contact:

Re: Silverlight&Moonlight

Postby phillipsjk » Mon Jan 26, 2009 5:24 pm UTC

OOPMan wrote:But let's not kid ourselves. HTML was never really designed with this kind of thing in mind and neither were browsers.

At this point web development is pretty much a world that looks pretty up front but, underneath the hood, it's a mess.
HTML was never really designed with GUI interfaces in mind and writing good GUI-based web applications using HTML + JS is basically just one ugly hack laid on top of the next.

To be completely honest, I think the whole thing needs to be rethought and approached with some actual foresight.


This is true because. HTML is based on sgml, a document mark-up language. It is designed with a variety of output interfaces in mind (since HTML 4; before that (including the DOM requirement) each user-agent was allowed to do its own thing). I was going to link to Web Accessibility Initiative Guidelines to illiustrate, but the new ones are... abstract. Instead, a portion of the CSS2 spec will have to do: 7.3 Recognized media types

That is why I like the Java VM: It is designed to act like an OS -independent GUI. It was criticized for being slow and ugly though.

One site that I think was justified in using Flash was http://www.stickdeath.com The early stuff was done with animated gifs. I have an idea for a video standard that may be able to replace programed vector graphics, but it is barely into the paper stage (and does not use vectors; more suited to web-cams).
Did you get the number on that truck?

User avatar
Xanthir
My HERO!!!
Posts: 5410
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Silverlight&Moonlight

Postby Xanthir » Mon Jan 26, 2009 5:47 pm UTC

OOPMan wrote:
sakeniwefu wrote:
OOPMan wrote:Silverlight is about as lame and iritating as Flash. Moonlight is worse.

Hopefully, some day, someone somewhere will realize that HTML and ECMAScript standards are and have always been more than enough to display their crappy content and Flash and Sliverlight will go the way of Java applets.
I hate Java, I hate Flash, and I will hate Silverlight once retarded webmasters actually start using it.
Any person involved in any of those three abominations should be hung for crimes against humanity.
:x


Can't say I agree on that. HTML + JS may once have been more than enough but things are starting to stretch a little thin at this point. Sure, we have Web 2.0. Sure, Web 2.0 produces "pretty" web sites.

But let's not kid ourselves. HTML was never really designed with this kind of thing in mind and neither were browsers.

At this point web development is pretty much a world that looks pretty up front but, underneath the hood, it's a mess.
HTML was never really designed with GUI interfaces in mind and writing good GUI-based web applications using HTML + JS is basically just one ugly hack laid on top of the next.

To be completely honest, I think the whole thing needs to be rethought and approached with some actual foresight.

Web development is a pain and will remain so until someone breaks the mold completely, ditches HTML (Although keeping an improved version of JS couldn't hurt)

Of course, that's not likely to happen given that clout HTML has in the real world...

Which sucks...

Same story as always. The system sucks, but getting people to use any other system is really really hard.

Pfah. HTML+CSS+JS produces apps just fine. Right now you need a decent JS library, but ECMAScript is gradually getting better in the core language.

What I'm saying is, I've never been able to create a GUI app *more easily* than I can on the web. It's powerful, simple, and pretty. Anyone who says otherwise is simply too used to desktop GUIs.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
OOPMan
Posts: 314
Joined: Mon Oct 15, 2007 10:20 am UTC
Location: Cape Town, South Africa

Re: Silverlight&Moonlight

Postby OOPMan » Tue Jan 27, 2009 8:00 am UTC

Xanthir wrote:Pfah. HTML+CSS+JS produces apps just fine. Right now you need a decent JS library, but ECMAScript is gradually getting better in the core language.

What I'm saying is, I've never been able to create a GUI app *more easily* than I can on the web. It's powerful, simple, and pretty. Anyone who says otherwise is simply too used to desktop GUIs.


Utter bollocks. Now, I know that not EVERY web 2.0 app is crap. There are a couple out there that are real gems. Same goes for some of the tools. jQuery is a beautiful idea and in practise a great way to deal with HTML-style data.

But the fact is, by and large HTML + JS produces mountains of crap.

Let's look at some "Star" Web 2.0 apps and libraries:

GMail: As yes, good old gmail. A real Web 2.0 star. Except it's not, not really. For one thing it's written using GWT so the code is actually Java behind the wheel. So much for HTML + JS. For another thing it's a stinking great beast. It takes about 5 seconds to load and downloads about 500kb of data in that time. Way to go Gmail. By comparison, Kontact for KDE4 loads in less than 1 second and provides about 5x the functionality of Gmail. Not a fair comparison you say. Well no, I guess it isn't, because Kontact is just better! Also, god forbid Google makes some changes to GWT. Oh wait, they do. Which is why Gmail breaks for weeks at a time in Opera three months or so.

VMWare 2.0: Way to go VMWare. You replace your fast, responsive GTK-based administrative tool with a slow, unresponsive web-based front-end. The difference in speed is enormous. No longer is adminstering a VM quick and easy. Now you have to wait while VMWare slogs it's way through mountains of slow JS in order to produce pop-up windows which are only slightly prettier than what they used to have. As someone else once said: Set Sail For Fail!

EXT: Possibly the most bloated, heavyweight JS library out there. Sure, it provides lots of features. Sure, you don't have to use them all. But with a maximum footprint of about 500kb for the whole thing you can rely on it giving your application it's much needed bloat. As for performance that's the real joke. Slow. Slow. Slow


Honestly, I think it's sad that the currently style of Web Development has become the paradigm for interface and application design because it sucks. Web browsers are incompatible and none of them comply to all the required standards. HTML + CSS + JS is a crappy way of developing UI-based applications and will remain so fo some time to come.

Sure, JS is a shining star that is beginning to ascend. But let's be realistic. How long will it be before the majority of users is able to experience fast, JIT-ed JS? Quite some time, I think you'll find. M$ may be losing market share but not at such a rate that ensures that by the time SquirrelFish Extreme and TraceMonkey hit mainstream that majority of users will be running browsers that use said JS engines. Nope, they'll still be using some or other version of IE with it's horrendous JS engine and standard compliance.

CSS is nice and it does have a lot of good ideas. But, as with JS the lack of standards compliance among implementing browsers makes life difficult.

HTML for it's part is just no longer suitable. Modern web pages are no longer the 1-page, formatting bare pages of yesteryear. A single HTML page for a complex modern site produces a stupidly complex DOM tree that does a wonderfully bad job of separating content from design.

My opinion on what can be done? Well, there are a couple of things...

1: Standard compliance means standards compliance. No beating about the bush. If a browser isn't standards compliant it should not be ALLOWED to be used. But how? Hard to say, but the bottom line is: Force companies to produce standards compliant browsers and force users to use standards compliant browsers.

2: Quit crippling JavaScript. If a company is unable to produced a fast, compliant JS engine (Read: M$) then they MUST allow for the use of a third-party, pluggable, standards compliant references implementation. Better yet, all browsers should just use the SAME damn JS engine by default. One of the current JS engines (SquirrelFish Extreme, Tracemonkey or V8) needs to be adopted as the engine of choice by ALL browsers. Think of it this way. Imagine of there were 5 different JRE producers ouit there, each once producing a JRE that didn't comply the JVM in the same way. Server-side Java would be a complete abortion and a hopeless wreck. That wouldn't stop it from being used. After all, if your only option is a bad one, then it's better than no options at all. But it sure would suck.

3: Retro-haul HTML. Split content from structure. Seriously, it's a good idea. Imagine your HTML document, just with no actual textual content in that HTML itself. At the most basic level, textual content for a given element can be loaded from a content repository using the id of said element. I'm sure something more complete could be developed, but the basic idea is simple. Separate content from layout. In such an environment, the application of CSS styling and JS DOM manipulations would be a hell of lot easier to work with because the page content wouldn't getting in the damn way as much. Also, while we're on HTML possibly the hugest benefit could come from just make the whole standard a whole lot more strict. Element order incorrect? Page fail! Non-unique element Ids? Page fail! And so forth. If web browsers cracked down on non-compliant pages design would go a long way. The whole soft-handling of non-compliant pages was cute back in 1994 when the web was mostly simple, hobby-ist level DIY pages but it's become a thorn at this point. Application level HTML does not benefit from soft-handling of standards non-compliance. Rather, it's to the major detriment if said applications. The result of JS DOM manipulations on a DOM that is invalid to start with are the kind of thing one just should not have to deal with.

4: Quit crippling CSS. Much the same as item 2. Just replace JS with CSS and you get the idea. Standards compliance, speed, reliability, etc...

5: Other stuff. Because I'm sure it's there. Memory usage is one thing. Pretty much all the major browsers are horrendous memory hogs. This could do with some seeing to. There's more, no doubt. I think everyone has an idea of some things which have to change.


The bottom line is this. HTML + JS + CSS at it's currently level of implementation, standards compliance and compatibility is hindering web application development. If web application development is going to grow to the level where it exceeds and outpaces application development then the underlying components had best get their shit in order real quick because the current level of quality in all three areas (HTML, JS and CSS) is overall poor and not condusive to the effective development of real-world applications.

Sure, real-world applications can be developed using the web. But at this stage the core components of web application development do not make the development of such applications as fast, safe and simple as it could be.

Something has got to give.
Image

Image

User avatar
Xanthir
My HERO!!!
Posts: 5410
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Silverlight&Moonlight

Postby Xanthir » Tue Jan 27, 2009 12:38 pm UTC

So, your post boils down to "Microsoft sucks, and some companies produce bad apps"?

I'd have to agree with you there. We just draw different conclusions from it. I've seen some absolutely beautiful apps out in the world, and I think I produce higher-quality UIs than the desktop-app devs at my company do. Gmail *does* suck in UI - it's absolutely ridiculous how non-structural that shit is, because no one cares about the actual *output*.

Now, as to your points...

1: Standard compliance means standards compliance. No beating about the bush. If a browser isn't standards compliant it should not be ALLOWED to be used. But how? Hard to say, but the bottom line is: Force companies to produce standards compliant browsers and force users to use standards compliant browsers.

For starters, that would disallow people from using *any* browser - there's not one of them that fully implements HTML4 or CSS 2.1, and those are 10 year old technologies! Did you mean a browser that grossly violates standards? Fair enough. I question, though, just how you plan to *force* people and companies to change their actions. Legal threats? Violence? Cookies and a smile?

2: Quit crippling JavaScript. If a company is unable to produced a fast, compliant JS engine (Read: M$) then they MUST allow for the use of a third-party, pluggable, standards compliant references implementation. Better yet, all browsers should just use the SAME damn JS engine by default. One of the current JS engines (SquirrelFish Extreme, Tracemonkey or V8) needs to be adopted as the engine of choice by ALL browsers. Think of it this way. Imagine of there were 5 different JRE producers ouit there, each once producing a JRE that didn't comply the JVM in the same way. Server-side Java would be a complete abortion and a hopeless wreck. That wouldn't stop it from being used. After all, if your only option is a bad one, then it's better than no options at all. But it sure would suck.

Mmm, nah. If you have a single engine, who's going to develop it? Monocultures inevitably stagnate. And again with the forcing, jeez.

3: Retro-haul HTML. Split content from structure. Seriously, it's a good idea. Imagine your HTML document, just with no actual textual content in that HTML itself. At the most basic level, textual content for a given element can be loaded from a content repository using the id of said element. I'm sure something more complete could be developed, but the basic idea is simple. Separate content from layout. In such an environment, the application of CSS styling and JS DOM manipulations would be a hell of lot easier to work with because the page content wouldn't getting in the damn way as much.

Well, that already exists, if you want it - it's called XSLT. The problem is that you have to program in XML. It's also called using a database, if you can accept that it happens on the server side. On a slightly different track, there's XBL2, which creates a shadow DOM just for CSS to work with, so you can employ source hacks galore for styling if you feel like it, but still push beautiful html over the wire.

Also, while we're on HTML possibly the hugest benefit could come from just make the whole standard a whole lot more strict. Element order incorrect? Page fail! Non-unique element Ids? Page fail! And so forth. If web browsers cracked down on non-compliant pages design would go a long way. The whole soft-handling of non-compliant pages was cute back in 1994 when the web was mostly simple, hobby-ist level DIY pages but it's become a thorn at this point. Application level HTML does not benefit from soft-handling of standards non-compliance. Rather, it's to the major detriment if said applications. The result of JS DOM manipulations on a DOM that is invalid to start with are the kind of thing one just should not have to deal with.

Again, we already have that - it's called XHTML. And it is a FAILURE. Strict error handling is a fast train to fail city on the web. Should I go through the reasons? (1) Any browser which actually turned this on (rather than only doing it for pages that ask them very nicely with sugar on top) would immediately die a painful death, because most pages on the web are invalid. Sometimes it's not their fault - they *were* produced back in 1994, and simply haven't been touched by anyone since. Most of the time, though, it's because simple mistakes were made. These are insignificant, though, because browsers have very similar error-handling mechanisms, and HTML5 is defining error-handling *very* explicitly so we can all converge on this.

Your argument is ridiculous anyway. Applications don't benefit from their own HTML being handled with kid gloves? THEN PRODUCE CORRECT HTML. It's really not hard. Problem solved! It's not like everyone else's invalid HTML will leak through and pollute your page. And regardless of invalid html or not, an invalid DOM is the result of a broken browser. Error handling should transform bad html into a good DOM. If it doesn't, you have a bug.

4: Quit crippling CSS. Much the same as item 2. Just replace JS with CSS and you get the idea. Standards compliance, speed, reliability, etc...

This is more of an issue than JS. JS engines are at least *somewhat* swappable. CSS engines are tied pretty deeply into code. You *could* swap one out, but it would probably be easier to just adopt someone else's code wholesale.

Sure, real-world applications can be developed using the web. But at this stage the core components of web application development do not make the development of such applications as fast, safe and simple as it could be.

Something has got to give.

And something is. The web is getting betterfasterstronger every day. And MS is slowly inching toward non-majority status (right now it sits around 80% of pageloads according to my browser stats).
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))


Return to “Religious Wars”

Who is online

Users browsing this forum: No registered users and 3 guests