Windows 8 metro versus Java and other plugins...

[opinali]

So it seems that Windows 8's new "Metro" user environment will make IE plugin-free. Any attempt to use plugins like Flash, Java, Silverlight or anything else, will bring the user to the "old-style" (as in Windows 7) desktop, which will be seen as a severe experience degradation for users who prefer the new environment.

I am not as much plugin-hater as some people; in my Android smartphone, I certainly appreciate the support for Flash, for simple practical purposes - the rare website that uses some Flash and has no mobile-optimized version or native Android app. And yeah, my karma be damned but Flash works well enough for me (admittedly on a nice hardware - Tegra2, dual-core Droid X2, rooted & debloated, Flash updated to 10.3).

Still, I love the idea of a plugin-free world, if only for the security improvement. (Including avoidance of trash like "security plugins" mandated by online banking sites...) But this is not really fair if we consider modern browsers that run plugins in separate and low-privilege processes, plus enhanced plugin technology like Google's (Pepper and NaCl / PNaCl), plus plugins for runtimes that are managed and have their own sandboxing and security mechanisms and are sufficiently well patched (candidates: Java, Flash, Silverlight - yes none of them are perfect, they all add some to the attack surface, but the ever-growing browser is already a huge attack surface, there's no single week going without new security bugs being found in every major browser so I don't think the "three big" plugins would make things significantly worse).

There's already people betting that Microsoft will have to back away and maybe, put an option to allow plugins in Metro mode even if not active by default. I know for sure, that corporations are writing new apps with things like Flash, by the thousands. Everybody complains that the corporate world is still dragging its feet with old versions of IE, remarkably the much reviled IE6; but if you think that ActiveX code for IE6 is holding back the web, this is nothing compared to how much stuff depends on Flash. A plugin-free IE10+ will be adopted in corporate world by 2020 with some optimism...

What about the <applet> tag? This is not part of HTML5 anymore, but it's part of previous versions even if deprecated. This should give Java applets special privileges, at least if Metro-mode-IE will support pre-HTML5 markup (and sure as hell it must, for a long time still). I'm too lazy to install the Win8 beta just to check this, would anybody report if <applet> works in Metro/IE? Just curious, I guess it doesn't...

Even in HTML5, there's the <object> tag which is supported and not even deprecated. Will Microsoft break the spec and declare that this feature of HTML5 is not supported in Metro mode?

What about Java WebStart, maybe the deployment toolkit can be adapted to detect Metro and not depend on <object>, I guess the only fundamental need is the ability to download a JNLP file and launch the associated program? Will Metro restrict such launching too?

Both Oracle and Adobe are working on their Plan B for the eventual dominance of HTML5, with new tooling that convert their stuff in plain HTML5. In Oracle's case, there is hope for JavaFX 2.0 if its Web Runtime turns out to be good (it's not yet included in the public beta so I have no idea). There is no similar hope though for old-style, AWT/Swing applets or JAWS apps that will not benefit from a similar Web Runtime.

By the way, the JavaFX Web Runtime (WRT) will be a very interesting test for the claim that Javascript & HTML5 can be fast enough and powerful enough to build any application, competing at least with Java/Silverlight/Flash if not with native apps. Summarizing, the WRT will have a pure-web implementation of the JavaFX frameworks (animation, controls, graphics etc.), I guess using canvas or WebGL and Javascript; and the application code will be (perhaps partially) converted to Javascript code. So, supposing that this WRT is well designed and implemented - and that's a core part of the v2.0 reboot plan so I guess they carefully redesigned the whole thing to make the WRT possible - then if it turns out to be much less efficient than the conventional runtime, this will be strong evidence that the mantra "HTML5/Javascript is fast enough" is bullshit. Let's wait and see.

In another interesting development, Google's technologies like PNaCl and Dart can be powerful enablers for anything that generates Javascript code, from GWT to Adobe's and Oracle's  tools. Dart is supposed to be much more efficient than Javascript, and also, the Java language will probably be much closer to Dart than it is to Javascript (less sure about AS3...); and I'm sure Oracle and Adobe can write new compilers that emit Dart code instead of Javascript code. Or even, PNaCl code. So if these Google technologies succeed, they can benefit other platforms too. We will still be able to run other browsers in Win8.

[Chris Adamson]

Good points about <applet> and <object>, although would it be spec-
compliant to simply parse and ignore them? It's not like every
browser today supports applets (for example, does Opera for the Wii
have a JVM?).

One thing that stood out to me in the MSDN blog justifying the move -
https://blogs.msdn.com/b/b8/archive/2011/09/14/metro-style-browsing-and-plug-in-free-html5.aspx
- was this sentence:

"There’s a steep drop-off in plug-in usage after Flash, with one
control used on 2% of sites and a small collection of controls used on
between 0.5% and 0.75% of sites."

What plug-in do you suppose is the 2%? Java? Silverlight? Something
else? If applets were used on 2% of sites, I'd consider that
surprisingly high. Even 0.5 (1 out of every 200 sites) seems high.
But if not Java or Silverlight, what else could the 2% plug-in be?

--Chris

[Casper Bang]

Purely from an architectural perspective, I like the notion of plugins. They work fairly well in most other places than MSIE (NetBeans, Forefox, Chrome...) both as a means for controlling features/capabilities and partial upgrades/versioning. Maybe they've been convinced by looking at Google's ChromeOS (no native apps) and/or Apple's Safari (almost no plugins), but if that is Microsoft's weapon against bloatware, it sounds more like a kidney removal than an appendix removal. 

[James Ward]

Could be Shockwave. I think quite a few web based games still use it. But I think Applets actually makes more sense. I still encounter applets somewhat often for 3D stuff.

-James

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Casper Bang]

On Friday, September 16, 2011 12:47:23 PM UTC+2, Chris Adamson wrote:

What plug-in do you suppose is the 2%?  Java? Silverlight? Something
else?  If applets were used on 2% of sites, I'd consider that
surprisingly high.  Even 0.5 (1 out of every 200 sites) seems high.
But if not Java or Silverlight, what else could the 2% plug-in be?

I tried to investigate this 3 years ago, when Sun came out with the JavaFX stuff which used the (then deprecated for 9 years) applet tag:

http://blog.bangbits.com/2008/08/myth-java-widely-used-on-web.html

[Fabrizio Giudici]

On 09/16/2011 12:47 PM, Chris Adamson wrote:
> Good points about<applet> and<object>, although would it be spec-
> compliant to simply parse and ignore them? It's not like every
> browser today supports applets (for example, does Opera for the Wii
> have a JVM?).
>
> One thing that stood out to me in the MSDN blog justifying the move -
> https://blogs.msdn.com/b/b8/archive/2011/09/14/metro-style-browsing-and-plug-in-free-html5.aspx
> - was this sentence:
>

The real reason is Microsoft pathetically trying to exclude competitors
and competing technologies, trying to impose HTML5 for everything. Then,
maybe HTML5 for Windows 8 metro will "slightly" differ from plain
standard HTML5 as they did for Java, of course only with the purpose of
"supporting Windows 8 more efficiently".

BTW, will Silverlight be included in Windows 8 metro? I've read
something around, but it wasn't very clear.

It will be interesting to see the move in the Dart perspective. If
Google wants to push Dart to all browsers, they need to install a
plugin, I suppose.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Fabrizio Giudici]

> appendix removal. --

In any case, this is a symptom of the bipolar syndrome our software
world suffers from. There are periods in which everything should be
"pluggable and modular". Then, all of a sudden, plugins become shit.
This has been repeated and is being repeated for many other pieces.

BTW, of course I agree with the above quote by Casper.

,--

[Vince O'Sullivan]

On Sep 16, 12:01 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> The real reason is Microsoft pathetically trying to exclude competitors
> and competing technologies, trying to impose HTML5 for everything.

So, historically, Microsoft were bastards for playing fast and loose
with HTML standards; and now, they're bastards for complying with HTML
standards?

[Fabrizio Giudici]

On 09/16/2011 01:27 PM, Vince O'Sullivan wrote:
> So, historically, Microsoft were bastards for playing fast and loose
> with HTML standards; and now, they're bastards for complying with HTML
> standards?

Read entirely my previous statement...

[opinali]

Good point... now, there is a rationale for that, as the applications that are initially designed to benefit from plugins become bigger and more complete, so plugins are increasingly seen as something that causes more problems than benefits: not well maintained, not immediately updated to be compatible with the latest application, unsafe, harder for new users etc. But the right solution for this is that the plugin interface should become more strict, so only "better" plugins are allowed to install or load. We see this for example in the evolution of browsers and IDEs, and it works well. For browsers, I would consider fair to require that the next generation strongly enforces managed code. Native plugins should be allowed but only with extra cumbersome, scary installation steps. A good model is Firefox with its plugins (native) and XUL-based extensions (managed). Google Chrome is also moving in the same direction, it will eventually favor NaCl-based plugins. For Microsoft, maybe they could enable Metro/IE plugins to be written in .NET managed code - this should be a pretty obvious move if Microsoft really bets and believes in .NET.

A+
Osvaldo

[Karsten Silz]

On Friday, September 16, 2011 2:50:05 AM UTC+2, opinali wrote:

So it seems that Windows 8's new "Metro" user environment will make IE plugin-free. Any attempt to use plugins like Flash, Java, Silverlight or anything else, will bring the user to the "old-style" (as in Windows 7) desktop, which will be seen as a severe experience degradation for users who prefer the new environment.

I'm glad that Microsoft goes HTML5 only. To me, a browser plugin is something that extends the browsers capability, like showing you your unread Gmail count, allowing you to save a page quickly to Evernote or Instapaper or make the structure of the content available for developers (like Firebug).

Flash, Java and Silverlight always replaced the browser - they were different runtimes and had their own languages and libraries and UI elements and OS integration and so forth. They all could run outside the browser, but they mainly needed the browser as a delivery vehicle.

Noticed another thing that these "plugins" all share? They are driven either by a single company (Flash, Silverlight) or by a committee that represents a considerable part of the industry, but still not all the big players (Java). In contrast, the W3C has pretty much everybody in the software industry on board. Software designed by committee is probably always worse than software designed by great companies alone, but HTML5 as the plumbing of the Internet is too important to hand over to a single company by itself.

Of course, HTML5 can't do as much Flash / Flex can, for instance. But there still is value in having a technology that delivers a base level of functionality across all PCs, smartphones, tablets (though the app still has to adopt to the different UI constraints).

Adobe recognized this move to HTML5 themselves. They now position Flex for enterprise applications and as a mobile cross-plattform tool (mostly for games, I'd assume, since "native" Flex UIs typically just feel equally out of place everywhere), leaving "consumer PC applications" to HTML5 only. And their video streaming server now supports streaming to iOS as well. We'll probably never know why, but I guess that Apple's refusal to support Flash in the iPad and the huge success of the iPad were the tipping point.

 

[Karsten Silz]

On Friday, September 16, 2011 1:01:13 PM UTC+2, fabrizio.giudici wrote:

The real reason is Microsoft pathetically trying to exclude competitors
and competing technologies, trying to impose HTML5 for everything.

They also exclude their own technology - Silverlight doesn't run in Metro IE either. And since when is shipping a proprietary technology like Flash better than shipping standards like HTML5? With Windows 8, each important mobile platform (Android, iOS, Windows 8) follows the same pattern: native apps with an app store and HTML5. To me, that's a win.

 

Then, maybe HTML5 for Windows 8 metro will "slightly" differ from plain
standard HTML5 as they did for Java, of course only with the purpose of
"supporting Windows 8 more efficiently".

This could happen, but Microsoft has much less power than it had five years ago:

• More smartphones are being sold than PCs these days, and only 1-5% of them have IE. People browse a whole lot less on smartphones than on PCs, though.
• On the PC side, IE has less than 50% marketshare in Europe and probably less than 70% in all other regions.
• By the time the first competitive Windows tablet arrive in Q3/2012, consumers may already spend more money on tablets than on PCs (in H1/2012 in Germany, consumer spending was one third on tablets and two thirds on PC). And Metro is a consumer pitch - it will take years until enterprises move to Windows 8 (Windows 7 just surpassed ten-year-old XP in enterprise usage), and even then they can switch of Metro altogether to focus on their legacy apps.  

[opinali]

Very interesting point; and it's easy to jump to the agreement that plugins should only extend, not replace the standard web platforms.

Even in that case, there's a problem if a browser supports no extensibility at all, and its built-in extension mechanisms are not good enough. For one thing, its Javascript engine is the single code execution facility and it's not good enough for everybody and will never be; it's a pretty poor candidate for a "Universal VM".

But I can also see a lot of hypocrisy in this web-versus-plugins debate. Many next-generation "pure web" apps are dropping most of the HTML/DOM, instead they just open a big hole in the document and render the entire UI using the canvas or WebGL.  All content for the app comes in Ajax calls so no markup for that either.  Really, how is this different than opening a hole that will contain a Java, Flash or Silverlight app?  These plugins have integration APIs to pass events, data, control the external DOM if there's any etc.  So the single important difference is that one option is a current W3C standard, and others are not. And even this difference can be blurred, e.g. <applet> was once a HTML tag, and things like WebGL are not yet ratified standard so using them right now is almost as "evil" as using Flash.

You mention Firebug. Firebug is implemented with Mozilla's proprietary extension mechanism, including XUL. This stuff is not a W3C standard, and it's not supported by any other browser, company or platform.  All the standards-hugging hippies that hate Flash/Java/Silverlight, have no problem with Mozilla's extension system which is just as "evil" by the same definition.

A+
Osvaldo

[Fabrizio Giudici]

On 09/17/2011 02:10 PM, Karsten Silz wrote:
>
>
> Noticed another thing that these "plugins" all share? They are driven
> either by a single company (Flash, Silverlight) or by a committee that
> represents a considerable part of the industry, but still not all the
> big players (Java). In contrast, the W3C has pretty much everybody in
> the software industry on board. Software designed by committee is
> probably always worse than software designed by great companies alone,
> but HTML5 as the plumbing of the Internet is too important to hand
> over to a single company by itself.

Indeed I'm very sceptical, precisely for the reason you mentioned. While
Java, Flash / Flex, and at this point it's clear that we have to add
Silverlight to the picture, have failed to be pervasive, still they
delivered (and are delivering) something, in their niches. In contrast,
the W3C-like model so far has not been able even to deliver compatible
ways to render HTML or CSS. For what I can tell at the moment, HTML 5 is
the acknowledging that HTML failed so far. There's the promise to have
it working in future, but I'll believe when I see it. And let's recall
that we get nowhere with HTML alone; JavaScript is a fundamental part,
but AFAIK W3C and the EcmaScript committee were never able to cooperate,
and perhaps we're going to see Google break the equilibrium with Dart.
As far as I can see, the web is still a very messy place, as it has been
like that since when somebody had the bad idea to use it to deliver
applications rather than documents, just because it was pervasive.

--

[mbien]

i am wondering how long it will take until we will install "plugins"
in the browser cache via standardised HTMLX features without talking
to the OS or Browser directly. You can already see heavy usage of "do
you want to allow this website to store stuff on your harddisk"
messages in HTML5 demos.

regards,
-michael

[Karsten Silz]

On Saturday, September 17, 2011 5:26:57 PM UTC+2, opinali wrote:

For one thing, its Javascript engine is the single code execution facility and it's not good enough for everybody and will never be; it's a pretty poor candidate for a "Universal VM".

Well, Javascript's the only thing we have in all browsers, so we have to get along with it for the time being. 

But I can also see a lot of hypocrisy in this web-versus-plugins debate. Many next-generation "pure web" apps are dropping most of the HTML/DOM, instead they just open a big hole in the document and render the entire UI using the canvas or WebGL.  All content for the app comes in Ajax calls so no markup for that either.  Really, how is this different than opening a hole that will contain a Java, Flash or Silverlight app?

In a nutshell and oversimplified: The web applications that behave as you describe use an industry standard runtime, Flash/Silverlight/Java do not.

  

You mention Firebug. Firebug is implemented with Mozilla's proprietary extension mechanism, including XUL. This stuff is not a W3C standard, and it's not supported by any other browser, company or platform.  All the standards-hugging hippies that hate Flash/Java/Silverlight, have no problem with Mozilla's extension system which is just as "evil" by the same definition.

All browser plugins are proprietary because there's no standard for plugins across browsers. And I doubt there ever will be - look how the Java IDE plugin standard fared (hint: poorly). Again, Flash/Silverlight/Java plugins create a different runtime within the browser, that's what makes them different from Firebug.  

[Karsten Silz]

On Saturday, September 17, 2011 3:24:43 PM UTC+2, fabrizio.giudici wrote:

For what I can tell at the moment, HTML 5 is
the acknowledging that HTML failed so far.

I would say HTML5 is the acknowledgement that HTML is used for what it wasn't designed for - running applications and delivering sophisticated context.

 

As far as I can see, the web is still a very messy place, as it has been
like that since when somebody had the bad idea to use it to deliver
applications rather than documents, just because it was pervasive.

I assume that the web will always be a messy place. Defining a runtime without a strict compatibility test and having multiple implementations is just asking for trouble. I mean look at Android - all major Android phones supposedly pass Google's compatibility tests, yet applications sometimes just won't run (didn't you even experience that with your own app?). So to paraphrase Winston Churchill: The W3C is the worst way of defining HTML except all those other ways that have been tried from time to time.

[opinali]

On Monday, September 19, 2011 2:48:40 AM UTC-4, Karsten Silz wrote:

But I can also see a lot of hypocrisy in this web-versus-plugins debate. Many next-generation "pure web" apps are dropping most of the HTML/DOM, instead they just open a big hole in the document and render the entire UI using the canvas or WebGL.  All content for the app comes in Ajax calls so no markup for that either.  Really, how is this different than opening a hole that will contain a Java, Flash or Silverlight app?

In a nutshell and oversimplified: The web applications that behave as you describe use an industry standard runtime, Flash/Silverlight/Java do not.

Almost agreed. The first fine detail is that these so-called standard web apps, often use runtime features that are not universally [well] supported, or in some cases not even yet ratified as standards (like WebGL today).

The second, much bigger thing is, the competing runtimes have some standards and/or OSS credentials of their own: Java's JSRs and OpenJDK; Silverlight's ECMA specs and Mono/Moonlight; even Flash's Open Screen and Tamarin. I know, many of these have limitations or issues (e.g. Java's field-of-use problem), but the W3C is far from flawless either - we can spend all day long debating the relative merits of each standards group, or open source license, or the actual involvement and diversity of the community [you used the term "industry standard"; this is basically synonym for Java at least in the back-end]. I don't think the "open web" would come out as a clearly and significantly superior choice to all others. For one thing, the web is still vastly dominated by the influence of a very small number of major players. This is true for any big platform, as a consequence that only a very few independent implementations can exist... still, a standards group like the W3C doesn't change the fact that a handful of big companies will decide basically everything.
 

  

You mention Firebug. Firebug is implemented with Mozilla's proprietary extension mechanism, including XUL. This stuff is not a W3C standard, and it's not supported by any other browser, company or platform.  All the standards-hugging hippies that hate Flash/Java/Silverlight, have no problem with Mozilla's extension system which is just as "evil" by the same definition.

All browser plugins are proprietary because there's no standard for plugins across browsers. And I doubt there ever will be - look how the Java IDE plugin standard fared (hint: poorly). Again, Flash/Silverlight/Java plugins create a different runtime within the browser, that's what makes them different from Firebug.  

This is not really true: XUL certainly qualifies as a "different runtime". it's true that it shares a lot of the core browser runtime (Javascript/DOM/CSS), but it also includes the XUL metadata, uses browser-proprietary APIs including XPCOM, etc. Many XUL extensions don't even work primarily with browser's documents, they work on the chrome which is a completely proprietary component. I'd only agree that XUL is better integrated to the standard runtime, but that's just implementation detail as long as other plugin technologies will also allow full control of the browser's document.

[Karsten Silz]

On Tuesday, September 20, 2011 4:18:13 PM UTC+2, opinali wrote:

Almost agreed. The first fine detail is that these so-called standard web apps, often use runtime features that are not universally [well] supported, or in some cases not even yet ratified as standards (like WebGL today).

 

Agreed. 

The second, much bigger thing is, the competing runtimes have some standards and/or OSS credentials of their own: Java's JSRs and OpenJDK; Silverlight's ECMA specs and Mono/Moonlight; even Flash's Open Screen and Tamarin. I know, many of these have limitations or issues (e.g. Java's field-of-use problem), but the W3C is far from flawless either - we can spend all day long debating the relative merits of each standards group, or open source license, or the actual involvement and diversity of the community [you used the term "industry standard"; this is basically synonym for Java at least in the back-end]. I don't think the "open web" would come out as a clearly and significantly superior choice to all others.

 

From my perspective, HTML5 is the only "standard" with the three companies behind it that matter in phones, tablets and PCs: Microsoft, Google and Apple (in that order, I think). I just hope - you'll never know - that neither of these three tries an "embrace & extend" strategy with HTML.   

[Karsten Silz]

On Tuesday, September 20, 2011 4:18:13 PM UTC+2, opinali wrote:

You mention Firebug. Firebug is implemented with Mozilla's proprietary extension mechanism, including XUL. This stuff is not a W3C standard, and it's not supported by any other browser, company or platform.  All the standards-hugging hippies that hate Flash/Java/Silverlight, have no problem with Mozilla's extension system which is just as "evil" by the same definition.

All browser plugins are proprietary because there's no standard for plugins across browsers. And I doubt there ever will be - look how the Java IDE plugin standard fared (hint: poorly). Again, Flash/Silverlight/Java plugins create a different runtime within the browser, that's what makes them different from Firebug.  

This is not really true: XUL certainly qualifies as a "different runtime". it's true that it shares a lot of the core browser runtime (Javascript/DOM/CSS), but it also includes the XUL metadata, uses browser-proprietary APIs including XPCOM, etc. Many XUL extensions don't even work primarily with browser's documents, they work on the chrome which is a completely proprietary component. I'd only agree that XUL is better integrated to the standard runtime, but that's just implementation detail as long as other plugin technologies will also allow full control of the browser's document.

Ok, so Firebug was a bad example and really has a different runtime underneath. So I take back Firebug and use Chrome / Safari plugins only as examples of extending the browser.