Coffeehouse Thread

58 posts

Deadkit?

Back to Forum: Coffeehouse
  • exoteric

    , elmer wrote

    *snip*

    Actually, I believe they sacked him.

    http://www.riagenic.com/archives/960

    Interesting blog post! - Thanks for sharing. The unofficial Blink FAQ looks like aprils fools though.

  • evildictait​or

    , PopeDai wrote

    On the contrary, it is Silverlight that sucks:.the web is meant to be an open platform, accessible to all, regardless of device, platform or browser. Plugins are dead. XSS is a server-side issue, not an issue with HTML itself. HTML5 <video> works fine for streaming: YouTube uses it, as does Apple, to great effect. I'm personally opposed to DRM, especially on video (because cryptographically DRM doesn't work because Bob and Charles are the same person), but HTML5's working group is looking to make HTML5 support DRM video without actually providing it. And object orientation has what to do with HTML exactly?

    This is the true straw-man argument. Let me take it apart bit by bit.

    1. Silverlight and "openness" / "standards" are not opposites.

    All of the APIs for Silverlight were public, and Moonlight (Mono's implementation of Silverlight) was a clear demonstration that the core framework of Silverlight could - and was - implemented in an open "standards" way.

    Indeed - Silverlight benefits from the same key feature that .NET does -- it is unambiguous, meaning that when presented with a Silverlight "document" a browser will present an exact representation of what the developer wanted. There's no quirks mode, there's no ambiguities in the grammar and there's transparent backwards compatibility, and this leads to a better web, because it means that instead of every developer needing to test their application against every browser (which is hard), and browser vendors needing to test their browser against every website (which is even harder) - the browser vendors only need to test that they correctly implement the Silverlight API.

    For website developers - it's even easier. If it works on my machine - it'll work on yours - a benefit not shared before or since on the Internet cutting days off development and testing of new web applications.

    2. Silverlight is actually more accessible than HTML

    A common misconception about Silverlight versus HTML is that HTML is somehow "accessible" in a way that Silverlight isn't. This is simply not true. In fact, unlike HTML, Silverlight exposes all of the accessibility options that are available in Windows in a way that allows scriptable and extensible accessibility for partially sighted end-users.

    For most applications (since most applications never supported accessibility), Silverlight just used sensible defaults - which actually are exactly the same as in HTML. That's why you could tab your way through different controls on the form, and why Silverlight apps could be "read" by screen readers.

    In fact, Silverlight being XAML based meant that the entire website was transparently zoomable without breaking all of the elements and padding as you zoom. You didn't need a different website for customers on 800x600 versus 1024x768. You just scale the whole website, and Silverlight managed the scaling.

    3. XSS is a document issue - not a server side issue

    It is a lie to suggest that XSS is somehow a "server side" issue. XSS is a document generation issue. XSS occurs anywhere where documents are generated from text.

    My view is that XSS and SQL injection are design flaws in the language itself. C++ doesn't have C++ injection vulnerabilities. It's been a while since I saw a C# code injection vulnerability. It's rare to see someone screw up with MongoDB. So why are XSS and SQLi everywhere on the Internet?

    The answer is because they are so often dynamically generated from strings, instead of requiring templating with parameters (indeed, this is how you solve SQLi in the general case).

    Silverlight solved XSS in the same way that parameterized SQL fixed SQL injections. It said the document is a prepared object, and you fill in the gaps with elements - you never generate your Silverlight on the server by gluing attacker controled strings together.

    In HTML, your document is whatever HTML is spat out the end of your PHP or ASP console program living on the server. If you forget to escape your input, *boom* - XSS.

    In Silverlight, attacker controlled data never stopped being data. You took the data, and you put it in the data slot (like .Text) of an element. You never needed to escape it. You never needed to think about it - because gluing attacker controlled strings together, dumping them directly into your application and having them execute as code in the context of your application was never an option.

    4. HTML5 video sucks fine for streaming video compared with Silverlight

    Unless you need DRM. Or adaptive streaming. Or live streaming. So BBC iPlayer and Netflix and Lovefilm and Hulu-plus and ESPN and, let's face it, pretty much everyone who use video on the web except YouTube are automatically excluded from HTML5 web.

    So how does Netflix use to stream your high-quality, adaptive-streaming DRMed video direct to your browser?

    Silverlight.

    How do you stream the Superbowl to tens of millions of browsers live with adaptive streaming?

    Silverlight.

    You might object to DRM on principle (sure, whatever, loads of people do), but that doesn't stop the fact that if you want to stream movies legally, you have to put up with DRM. It's not optional. Disney would rather nobody stream their latest and greatest movie than allow it to stream sans-DRM.

    To that end, I put forward the (admittedly controversial) opinion that I frankly don't care about DRM, but I do rather care about being able to stream from Netflix and Hulu Plus. And if HTML5 doesn't support Hulu Plus and Netflix - then it's doing something wrong.

    5. What has HTML got to do with object orientation?

    Nothing, sadly. But the answer should be everything.

    Programming is advanced when we can move beyond the bottom rung of the stack and abstract our way out of the swamp. I don't want to deal with divs and spans, thank you very much, I'd like to deal with docking panels and code-editor controls and rate-adaptive video streaming boxes.

    HTML encourages bad applications, because it discourages code-reuse.

     

     

    This is the story of how Silverlight fixed the web, and Sinofsky killed it.

    Silverlight was a shining gem - a architectural palace from which serious coders could write code that stood above the rest of the web.

    It was a place where streaming media was powerful, encrypted and adaptive. A place where graphics were smooth and hardware accelerated by default. Where shifts between pages were transitions, not "page loading" pauses - and where security came without thinking, rather than requiring repeated and expensive pentests to get right.

    It was a place where people coded components that could be used on lots of sites. Where element widths were pixel perfect, and the same on all browsers, and where code was debuggable to developers - even if the crash occurred on a client machine - without revealing the source code to all and sundry on the Internet who might want a peek at your company's IPR.

    Sinofsky bulldozed that palace. so we're back to where we were. Every page starts at the bottom - a pile of divs and spans spat out by a PHP or ASP.Net console program, trying desperately to reach it's head out of the mire of browser incompatibility long enough for the user to not notice the glaring security omissions and cobbled together unzoomable sh1ttiness that is the web today.

    If HTML5 does well, it might one day be a shadow of what Silverlight was three years ago.

    In the meantime, I hope they put Sinofsky's badge on a spike, as a reminder to others who commit crimes against common sense.

  • PopeDai

    I won't start a Mattus-style thread - clearly we have ideological differences about things that cannot be resolved in a thread - but I'll quickly say a few things:

    • Silverlight may be open, but it's "open" the same way that Win32 or PDF are open: the specification is still controlled by a single corporate entity, it isn't truly open the way HTML and the web is. Even if Microsoft gave ECMA even the trademark rights to Silverlight the future direction of the platform will be dictated by Microsoft and not the community as a whole.
    • By "accessible" I mean the same content works on a finger-input smartphone with a tiny screen, to a mouse-driven 30" 2560x1440 behemoth desktop. DPI-independent scaling is only part of the solution, a Silverlight application is still going to have tiny checkboxes, fixed-size textboxes, and scrollbars and the runtime is not in a position to re-flow or reformat a document for a different device the way it can for HTML/CSS. This is why the web wasn't built on PDF or HyperStack, even though both support hypertext. (of course, HTML is inherently accessible, but I won't argue this point because you can easily make inaccessible websites).
    • As for video: the other sites are pragmatists: not everyone has a HTML5-video capable browser, and only WebKit browsers are really capable of live streaming of adaptive video (which you can actually do without any third-party components or plugins, but only WebKit can do it right now). I think that eventually, 3-5 years from now, Flash for Video will be dead when HTML5 <video> DRM support takes off.
    • Thank you for the insight in SQL Injection and XSS - I never thought of applications that way.

    I'll add that another barrier to Silverlight's web dominance is tooling: Silverlight files are essentially binary, you need special tools to make something. You cannot quickly make something like a "hello world" with simple tools like only a text editor in under 30 seconds. Instead you really need Blend or Visual Studio or one of Mono's tools - this is hardly something your 12 yearold tinkerer can experiment with (this is also why I think F12 tools should be more prominent in every web browser).

    Similar arguments to the ones you're making could be applied to Java <applets> from the late-1990s, and look what happened to Java in the end.

    (I also find it a bit ironic that myself, as an MS FTE is opposed to Silverlight, and you're the outside who thinks it's the best thing ever Wink )

  • evildictait​or

    , PopeDai wrote

    Silverlight may be open, but it's "open" the same way that Win32 or PDF are open: the specification is still controlled by a single corporate entity, it isn't truly open the way HTML and the web is. Even if Microsoft gave ECMA even the trademark rights to Silverlight the future direction of the platform will be dictated by Microsoft and not the community as a whole.

    The exact same thing is true with HTML.

    Firstly, the community doesn't decide what goes into HTML - the HTML standards body does. And Microsoft is part of that body. So if I'm Netflix, my opinions still don't hold as much weight as to the future of HTML as Microsoft's.

    Secondly, if Microsoft were to control the language and the specification - that doesn't mean that they do so in a vacuum. C# has clearly shown that Microsoft is able and capable of making a mature, popular language that is backwards compatible, unambiguous, openly discussed, community driven, focused and unfragmented with a clear vision for devleopers who make use of the platform across a number of different implementations such as Mono and the .NET framework.

    In contrast, HTML5 has failed on each and every one of those grounds. It's decision making process was partisan, politically driven, remains ambiguous, is not normative, and as you yourself admit, websites work differently in Webkit to Trident to Firefox to whatever.

    By "accessible" I mean the same content works on a finger-input smartphone with a tiny screen, to a mouse-driven 30" 2560x1440 behemoth desktop. DPI-independent scaling is only part of the solution, a Silverlight application is still going to have tiny checkboxes, fixed-size textboxes, and scrollbars and the runtime is not in a position to re-flow or reformat a document for a different device the way it can for HTML/CSS. This is why the web wasn't built on PDF or HyperStack, even though both support hypertext. (of course, HTML is inherently accessible, but I won't argue this point because you can easily make inaccessible websites).

    HTML websites don't scale from a finger-input smartphone with a tiny screen to a mouse-drive 30" 2560x1440 behemoth desktop without being carefully designed and scripted to do so. Silverlight applications give you DPI scaling for free, but if you want, your application can rescale or relayout depending on resolution, number of input fields or whatever.

    Silverlight applications absolutely could (and did) reflow content depending on the size of the container, so I won't even give you that. The comparison to PDF is completely void, since Silverlight wasn't (and wasn't trying to be) a document description language. It was trying to be an application.

    In fact - in that regard, HTML is much closer to PDF. It was designed to be a document description language (like PDF), and was never designed to be an application description language (like Silverlight).

    And finally - Silverlight was multitouch in 2010, a couple of months before Firefox became multitouch.

    As for video: the other sites are pragmatists: not everyone has a HTML5-video capable browser, and only WebKit browsers are really capable of live streaming of adaptive video (which you can actually do without any third-party components or plugins, but only WebKit can do it right now).

     

    If only Webkit can do it, how can we be claiming to be talking about the open web? The fact that WebKit runs your application differently to other browsers is part of the problem

    The functionality and style of my application on the desktop and in Silverlight is limited only by my imagination and my ability to code. In HTML it is constantly hampered by the inability of browsers to decide which features of HTML5 they would like to implement today. Does your browser have a JSON.parse? What does alert("") do? Is margin part of the width of a property? Make me a div that is 100% of the size of the container, minus 100 pixels without using javascript or tables.

    In Silverlight, if it works on my machine, it works on all machines. Because Silverlight is unambiguous. If it hadn't come with adaptive streaming out of the box, you could just implement it if you're smart enough.

    In HTML they've wasted time introducing tags that have no meaning (<output>, <section>), adding tags that we're not interested in (<progress>) and failing to implement tags we need (<video> with DRM, templating, a binary encoded javascript for efficient transfer and JITting optimised to be spat out of the backend of a compiler, better exception handling / reporting, the ability to disable grammar ambiguities for broken HTML etc).

    I think that eventually, 3-5 years from now, Flash for Video will be dead when HTML5 <video> DRM support takes off.

    Silverlight had DRM video in 2008. If HTML5 has DRM video natively in 3-5 years, that puts it a full decade behind Silverlight in terms of a basic and non-negotiable feature from several of the most popular and most important sites on the Internet.

    .

    I'll add that another barrier to Silverlight's web dominance is tooling: Silverlight files are essentially binary, you need special tools to make something. You cannot quickly make something like a "hello world" with simple tools like only a text editor in under 30 seconds. Instead you really need Blend or Visual Studio or one of Mono's tools - this is hardly something your 12 yearold tinkerer can experiment with (this is also why I think F12 tools should be more prominent in every web browser).

    See - I think the exact opposite. Silverlight's biggest feature was it's tooling. Sure, you can't write a Silverlight application in notepad, but who in their right mind thinks that notepad is a serious development tool?

    Silverlight is a powerful application for serious coders, and as such it had the full support of the enormously powerful Visual Studio - and for those that didn't want to pay, Visual Studio Express was free.

    By having powerful tools, Silverlight application developers got intellisense, strong typing support, integrated help, one-key testing, a hugely powerful integrated debugger, compile-time optimisations of their code, the full power of static analysis, and syntax highlighting.

    Sure, it's not notepad. But we don't write C++ in notepad, and that hasn't stopped it being the biggest, most popular, and most powerful native programming language in use by application designers on the desktop. Why should we expect web-application developers to make do with a basic text-editor with no features to churn out quality websites?

    Similar arguments to the ones you're making could be applied to Java <applets> from the late-1990s, and look what happened to Java in the end.

    No. Nobody ever said Java was good. Unlike Silverlight, the GUI was inconsistent across OSes and browsers, it was slow to load, and wasn't built to be secure from the ground up. It died a death because Flash killed it. Flash wasn't great, but it solved lots of the problems that Java did. And Silverlight would very likely have killed Flash if Microsoft had played their cards more sensibly.

    (I also find it a bit ironic that myself, as an MS FTE is opposed to Silverlight, and you're the outside who thinks it's the best thing ever)

    Maybe. I just find it disappointing that I spend so much time going to conferences, speaking with clever people and securing applications knowing that so many of the problems with the web are problems we solved five years ago, and killed six months ago.

    It's yet another great example of Microsoft making an awesome product, and then getting confused with the strategy of what to do with it, failing to market it properly, and then killing it prematurely.

    Microsoft executives need to get a grip. Microsoft is not short of clever employees or great products. But they really suck at making good use of them.

    Silverlight wasn't perfect, but it fixed lots of the problems on the web and it turned it from an amateur-hour bunch of crappy scripts into a hosting platform for powerful, serious applications previously only found on the desktop.

  • Bass

    I don't really understand why Google would do this, seems stupid from both a business and technology perspective.

    I think there is probably some political reason hidden here involving a falling out between the Apple and Google Webkit developers, or something political higher up between the companies (who of course also happen to be bitter competitors, so wouldn't be difficult).

  • figuerres

    , PopeDai wrote

    I won't start a Mattus-style thread - clearly we have ideological differences about things that cannot be resolved in a thread - but I'll quickly say a few things:

    • Silverlight may be open, but it's "open" the same way that Win32 or PDF are open: the specification is still controlled by a single corporate entity, it isn't truly open the way HTML and the web is. Even if Microsoft gave ECMA even the trademark rights to Silverlight the future direction of the platform will be dictated by Microsoft and not the community as a whole.
    • By "accessible" I mean the same content works on a finger-input smartphone with a tiny screen, to a mouse-driven 30" 2560x1440 behemoth desktop. DPI-independent scaling is only part of the solution, a Silverlight application is still going to have tiny checkboxes, fixed-size textboxes, and scrollbars and the runtime is not in a position to re-flow or reformat a document for a different device the way it can for HTML/CSS. This is why the web wasn't built on PDF or HyperStack, even though both support hypertext. (of course, HTML is inherently accessible, but I won't argue this point because you can easily make inaccessible websites).
    • As for video: the other sites are pragmatists: not everyone has a HTML5-video capable browser, and only WebKit browsers are really capable of live streaming of adaptive video (which you can actually do without any third-party components or plugins, but only WebKit can do it right now). I think that eventually, 3-5 years from now, Flash for Video will be dead when HTML5 <video> DRM support takes off.
    • Thank you for the insight in SQL Injection and XSS - I never thought of applications that way.

    I'll add that another barrier to Silverlight's web dominance is tooling: Silverlight files are essentially binary, you need special tools to make something. You cannot quickly make something like a "hello world" with simple tools like only a text editor in under 30 seconds. Instead you really need Blend or Visual Studio or one of Mono's tools - this is hardly something your 12 yearold tinkerer can experiment with (this is also why I think F12 tools should be more prominent in every web browser).

    Similar arguments to the ones you're making could be applied to Java <applets> from the late-1990s, and look what happened to Java in the end.

    (I also find it a bit ironic that myself, as an MS FTE is opposed to Silverlight, and you're the outside who thinks it's the best thing ever Wink )

     

    just to chime in here: Pope I am very much with what evil says on html and Silverlight.

    the call to stop working on a web / Silverlight system was like killing the baby for crying... it's just wrong on so  many levels....  

    honestly HTML as a standard is soo very retarded and abused and misused.... yeah we have it everywhere but that does not make it right.  it just means that computer science and IT shops and standards groups have given us a steaming pile to live with and if we do not replace it with something better we will have to keep living with that pile.

    is Silverlight right now the uber answer, no.  but it's a very interesting place to start making that better place....

    so we take the spec and the tooling and we drop the name .... why not do it?

    binary ?  well what is flash ?  what is a video ? they are all binary formats we live with.

    if all you want is a page that says "Hello" sure use html.... that is not what we are talking about.

    we are talking about LOB, CRM, and all that other stuff that business want on the net but they also want stuff that to do it with html gets just crazy.....

    I have seen some stuff where a company has created a point of sale system in html but to make it work they run a web server on the client to talk to the POS hardware..... WTF????  you have hardware interfaces that you can talk to locally with a client app and do the job and not need a web server in the store to work but cause it's cool to say you are html based they are doing it with all manner of crude hackish tricks .... it's a misuse of html and client server.  but they think it's cool

     

  • exoteric

    , Bass wrote

    I don't really understand why Google would do this, seems stupid from both a business and technology perspective.

    Why not? There is a good description here:

    http://www.chromium.org/blink/developer-faq

    And questions answered here:

  • Bass

    Microsoft was trying to promote Silverlight for years and it fizzled just fine without anyone's help. While Silverlight has a bunch of notable technical advantages over HTML, it also has a number of disadvantages (PopeDai summarizes very eloquently). The disadvantages proved fatal for the browser plugin's prospects.

  • Bass

    , exoteric wrote

    *snip*

    Why not? There is a good description here:

    http://www.chromium.org/blink/developer-faq

    And questions answered here:

     

    Because now you have two separate teams duplicating the work of each other. To what end, to theoretically squeeze some vague amount of extra performance from one of the fastest rendering engines already? The kind of high powered developers that write stuff like Webkit don't grow on trees.

  • elmer

    @Bass:More likely that Google feel they do the grunt work and their competition (i.e. Apple) benefits from it. Split it between core engine and Chrome enhancements, and you can reduce the number of free-kicks that you hand your competitors.

  • figuerres

    , Bass wrote

    Microsoft was trying to promote Silverlight for years and it fizzled just fine without anyone's help. While Silverlight has a bunch of notable technical advantages over HTML, it also has a number of disadvantages (PopeDai summarizes very eloquently). The disadvantages proved fatal for the browser plugin's prospects.

    where and when it died had a lot to do with when and where Microsoft started to kill it.

    as a new tech it needed time for corporate customers to fell safe adopting it, just when that was starting to happen Microsoft started saying things and doing things that made everyone suspect that Microsoft did not want to put any more into the tech and wanted to push developers in other directions.  that is what killed it.

    if MS had not delivered the mixed messages and delivered the updates that never came out....

    and yes, at one point they did state that they had an update planned for Mac OS that would hook into the Mac to allow better Mac /  Silverlight apps, that would have been in the last version they did on Mac but the features got cut due to them halting the work. 

    Silverlight would never have been a "replacement for html"  it could have been an "option"  to use when you want to do things that html is not the right tooling for.

    folks can ignore this all day long and it still is true that there are things that could be done better by not using html and all it's bits of cruft.

    the idea that html / css / JavaScript are the only thing you need and the only way to work on applications on the internet is just silly and not needed.

  • Bass

    , elmer wrote

    @Bass:More likely that Google feel they do the grunt work and their competition (i.e. Apple) benefits from it. Split it between core engine and Chrome enhancements, and you can reduce the number of free-kicks that you hand your competitors.

    That might have been the case if Apple contributes nothing to Webkit, but they contribute a great deal as well. So Google benefits from Apple's work and Apple benefits from Google's work. There are many other companies that contribute to Webkit as well. Google was basically have to duplicate all of their work as their rendering engine diverges.

    I can understand doing this if there was some really fundamentally broken thing about Webkit but I don't see it. Maybe it is hard to run every iframe in its own process but gimme a break, that's getting excessive there with the process separation. Why not run every element in its own process? Processes are free right? Perplexed Even if this is some kind of killer feature of Blink, don't you think losing all that extra development effort is worth the tradeoff? I don't think so.

  • Charles

    Seems it's more about focusing effort on standards evolution versus de facto standards. That said, certainly the latter informs the former.

    Excluding the nefarious, it's not a bad idea to hide webkit-specific prefixes, bundling up nonstandard extensions to the standard in a single about: configuration. That said, one has to assume that this is the webkit variant where Google will focus all of its engineering attention. It will then compete against all other variants. After a while, what will webkit mean?

    Will be interesting to watch and should add more vigor to the competition.
    C

  • PopeDai

    , Charles wrote

    After a while, what will webkit mean?

    It means that Blink will be to WebKit what WebKit is to KHTML.

    KHTML is still being maintained, and code is regularly ported from WebKit back into KHTML. I imagine WebKit will still press-on. Remember that Apple did huge things to WebKit to advance their own agenda, mostly in ways that enable WebKit to be used to create aesthetic and fluid user-experiences - whereas Google's main motivation seems to be performance. Considering Apple's solution to poor performance seems to be to throw more hardware at a problem I think this is where we'll start to see differences.

  • cbae

    , PopeDai wrote

    *snip*

    It means that Blink will be to WebKit what WebKit is to KHTML.

    KHTML is still being maintained, and code is regularly ported from WebKit back into KHTML.

    *snip*

    But what kind of new features originating from KHTML continue to be ported into WebKit? If nothing new from KHTML is worth porting into WebKit while new features of WebKit are being ported back into KHTML, then KHTML really is just a perpetual, previous-version snapshot of WebKit.

    As somebody who doesn't consider closed-source software the bane of computing, I personally like the idea of open source products having some measure of "reinventing the wheel" as well having to compete with each other as much as is the case with closed source products. However, I don't understand how a dyed-in-the-wool proponent of open source can think what happened here is a good thing.

    *snip*

    Remember that Apple did huge things to WebKit to advance their own agenda, mostly in ways that enable WebKit to be used to create aesthetic and fluid user-experiences - whereas Google's main motivation seems to be performance.

    *snip*

    How much innovation in the area of aesthetics and "fluid user-experiences" have been added to WebKit by Apple since Google essentially took over all of the performance innovations? It seems to me performance has a lot to do with "fluid user-experiences" anyway.

    Open source projects need *somebody* to push an agenda, or these projects die on the vine. WebKit no longer has anybody to push an agenda.

  • elmer
  • Richard.Hein

    A Short Translation from Bullshit to English of Selected Portions of the Google Chrome Blink Developer FAQ http://prng.net/blink-faq.html Doesn't it also seem to coincidental that the news that IE11 has WebKit support on it just came out before this announcement?

  • PopeDai

    , Richard.Hein wrote

    The news that IE11 has WebKit support on it just came out before this announcement?

    Que?

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.