Hi,

Is there something planned in this matter for FPC?

I was reading about the new Firefox making WebAssembly publicly available ("On Tuesday Firefox 52 became the first browser to support WebAssembly
<https://www.bleepingcomputer.com/news/software/mozilla-releases-firefox-52-the-first-browser-to-support-webassembly/>") [1] .

Thanks.

[1]
https://developers.slashdot.org/story/17/03/11/1627245/will-webassembly-replace-javascript

Karoly Balogh (Charlie/SGR) is working on this, and as far as I know has already some degree of success. There is a bounty for initial webassembly support..

Michael.

Michael Van Canneyt wrote

Karoly Balogh (Charlie/SGR) is working on this, and as far as I know has already some degree of success.

The Silverlight killer meets the C# killer :)

-Michael

Hi,

Well, "degree of success" is relative, I have added WASM target to the compiler so it even made it output 1 single
instruction... :)

It's based largely on gutted JVM codegenerator code, although since WebAssembly itself is still a moving target, many things are still uncertain. There's also the problem, that despite it's name, WebAssembly is not really an assembly format, but just a stack based bytecode (much like JVM), and the official textual representation is not yet accepted, plus the reference compiler LLVM outputs something entirely different to the semi-official textual formats. And these official textual formats are quite painful for the traditional structured compiler layers like FPC has.

But the LLVM-style output would be good, but it's undocumented, and as they say it will go away, and LLVM will output the binary bytecode directly... (Which is stupid IMO, but hey, a comittee decided, so it must be right.)

Also, any "assembler" or toolchain is still in its infancy. (I made both binaryen and wabt segfault in several funny ways already.) So I wouldn't expect fast results with this whole target. But I will keep working on it as time allows, so "eventually"... Of course if someone thinks he can proceed faster and wants to jump in, it's very welcomed.

It's now committed to the webassembly branch in FPC SVN, the compiler itself should build at least as "wasm" target, but don't expect much.

Charlie

Karoly Balogh wrote

Well, "degree of success" is relative, ...

Anyway, it's great to know that you are watching the proceedings regarding WebAssembly, and already did some effort to get started !!!!

Just for enhancing your motivation :-) (of course this issue is more like a project related to the Lazarus or mse designers, but you are going to pave the way) :

IMHO this will be a great method to create (pure Pascal) applications that are split in a server based part and a browser based part.

A very desirable way to do so would be to use a GUI based IDE (such as Lazarus or mse) to create and test an application running locally, and then define "split points" and use some kind of standard communication protocol (i. e. rpc) library to split it up appropriately - just with some definitions, without really writing any additional code.

While the perfect splitting points of course depend on the application you are doing, one "simple" way would be to provide a server based application with a browser based remote GUI. (This might usually be called "Rich Internet Application".)

I know that mse features a tool called "ifi" to convert a normal "local" application into a remote-controlled application with a remote GUI. Here, the GUI part is an application created by mse/fpc, and able to connect to any backend application done with "ifi". Building on top of "ifi" it might be possible do have the "ifi-Browser" run in a Web-Browser using WebAssembly. ms like a very viable goal to me.

-Michael

Hi,

[1] .

Just because of curiosity: since Firefox 52 apparently boasts (to be the first browser with) WebAssembly support -
- i know, i know, just because one vendor claims it, it doesn't mean anything yet - -maybe something concrete could be derived from that fact? Even if it's just a 'how do they do it' style of fact.

(in the press release they say something about Emscripten being the reference implementation, if that helps)

-L.
(rs,ianad)

To all who received my previous message through mailing list: please disregard. posted without reading thoroughly. apologies.

-L.

Daniel Gaspary wrote

WebAssembly <https://www.bleepingcomputer.com/news/software/mozilla-releases-firefox-52-the-first-browser-to-support-webassembly/>")

I love how they say multiple times in the video:

"... and completely secure."

Umm, didn't they say the exact same thing about Java Applets, Flash, Silverlight etc. :) I guess time will tell, but if history is anything to go buy, security issues *will* pop up.

Saying all that, I really respect Mozilla for what they have done regarding the web. Firefox is the only browser I ever use.

Regards,
Graeme

Karoly Balogh wrote

It's now committed to the webassembly branch in FPC SVN, the compiler itself should build at least as "wasm" target, but don't expect much.

Thanks for the update Charlie. Lets just say you are a brave man in my eyes to tackle something like that. :) I wish you all the best with the ,
Graeme

Daniel Gaspary wrote

I was reading about the new Firefox making WebAssembly publicly available ("On Tuesday Firefox 52 became the first browser to support WebAssembly

My system (FreeBSD) is compiling Firefox 52 in the background as we speak. I’m very curious to see how the Zen Garden demo runs here.

https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html

I’ll be pleasantly surprised if it works - after all, so many browser features often only work for OSX and Windows, even though the browser and web is supposed to be “cross-platform”. I’ll report back later. ;-)

Regards,
Graeme

Graeme Geldenhuys wrote

I’ll be pleasantly surprised if it works - after all, so many browser features often only work for OSX and Windows, even though the browser and web is supposed to be “cross-platform”. I’ll report back later. ;-)

And I am pleasantly surprised! :) That demo worked perfectly on my system. Sound, animation, graphics all silky smooth. Impressive indeed.

Regards,
Graeme

Graeme Geldenhuys wrote

Umm, didn't they say the exact same thing about Java Applets,

No idea

Flash,

While it's depreciated right now it did last for a long time and was _very_ useful.

Silverlight

While technically it did look nice, it was a single-company thingy and doomed as this company did not succeed with taking over on the mobile market.

etc. :)

As Microsoft, Google, and Mozilla had been in the boat it looked a lot more promising.

I guess time will tell, but if history is anything to go buy, security issues *will* pop up.

Hopefully they did consider this in the textbook

-Michael

Hi,

Yes, but it is important to know there's a difference with Java Applets, Flash and Silverlight - WebAssembly is not a plugin. It runs in the same VM which runs everything Javascript in the browser. So the browser vendors have full control on the code which runs there.

Also, WebAssembly is a descendant of asm.js, which was basically striped down Javascript with some integer/pointer type tagging. As far as I know, the main problem with JS from a computing point of view, that it handles all numbers as floats for "simplicity", but with some code in other languages, this can have real side effects (for example some integers cannot be exactly expressed as floats, which means slight differences in computation results accumulate over time, etc), and it's much slower on most CPUs. This is why I'm a bit relucant to accept High Level language translators to JS - there could be too many sideeffects hidden in any algorithm, just because of this one thing.

This is the main problem asm.js, and now WebAssembly is addressing. It can work with the same integer and float types the hardware underneath is using, and can avoid all the float handling and various range/index etc checks. This is what provides the performance part. And obvously a lot of other "shortcuts" to work around JS language requirements, which another language might not need.

And it fits in the process, how they gradually opened up the underlying hardware to the browser. Another great example is WebGL, which is also a very thin layer on top of the hardware, to skip through the billion "who cares about that" CSS and JS canvas layers, and go directly to the GPU, to get some decent performance...

So all in all, despite its problems, it's still the best effort to provide some sane bytecode standard for the web. (If a web bytecode can be anywhere near sane, that is.)

Charlie

The ECMAScript standard uses 64-bit double-precision floating point numbers, and a double-precision floating point value can represent absolute integer values up to of less than or equal to 2^53, without any loss of accuracy, since an IEEE 754 64 bit double-precision floating point number has a mantissa with a size of 52 bits (plus 1 bit implied).

On Thu, Mar 16, 2017 at 2:07 PM, Karoly Balogh (Charlie/SGR) <

[...] Also, WebAssembly is a descendant of asm.js,

Maybe historically. Technically asm.js is higher lvl than webassembly.

JS uses Double, which can express integers correctly from -$10000000000000 to $fffffffffffff.
That should be enough for most browser programs, don't you think?

[...] So all in all, despite its [webassembly] problems, it's still the best effort to provide some sane bytecode standard for the web. (If a web bytecode can be anywhere near sane, that is.)

+1

Mattias

Karoly Balogh wrote

Yes, but it is important to know there's a difference with Java Applets, Flash and Silverlight - WebAssembly is not a plugin. It runs in the same VM which runs everything Javascript in the browser. So the browser vendors have full control on the code which runs there.

And this brings me to my next worry. As far as I understand, WebAssembly is C (for now - other languages to follow) compiled into WebAssembly bytecode. So now we have C code with all its pointer access, buffer overflow issues etc running in the web browser space - at least Java Applets were a lot safer in that regards, and Java Applets require explicit signed executables and granted permission by the end-user (per app, per domain etc). WebAssembly just runs - no questions asked.

Then we have the issue of code being obfuscated when compiled into bytecode. So now it is even harder to detect malicious code.

The more I look at this, the more of a nightmare (security wise) WebAssembly looks. Now we will have a cross-platform incubator for malicious viruses, free to run in the web browser space, access to low-level hardware, and all without explicit asking for or being granted permission to run (ie: like Java Applets).

It seems I am not alone in thinking this way. Just read the comments posted at the link listed in the first message of this thread.

Regards,
Graeme

Hi,

No, to be honest, I don't think so. I already tracked down bugs in native client side software caused by this, because of stupid NodeJS backends. Because someone thought it will be "good enough". It wasn't. Not to mention the cases I got "NaN" string as value in an integer field, but that's just JS in general for fun.

Although NodeJS wasn't running in the browser, admittedly. But I think the more complex apps you bring to the web, on top of JS, the more such issues will appear, and the harder it will be to track it down.

Bottom line: It's not good enough if you want to guarantee the same results as on other platforms, for all integer arithmetics with all standard types, including 64bit ones. Which is a must for any self respecting multiplatform compiler, IMO. (There are ways to do it nevertheless even w/o WebAssembly, but with a clear performance hit.)

But I guess this is drifting away from the WebAssembly target itself, so we should continue on fpc-other. :)

Charlie

Hi,

Yes. Much like your average Javascript snipet. But even if it's compiled from C (or Pascal, eventually... :P), it doesn't mean it can just poke pointers whereever it feels like, there are several protection layers between the bytecode and the native code, the JIT engine itself, the browser, and the OS. Also, most browsers run most pages in isolation anyway. I agree though that some kind of code signing would be benefical.

Also, the major problem with Java and other plugins security faults were, that the organizations behind them moved with glacial speed, and sometimes (Flash, Silverlight) they were even closed source, which made it impossible for browser vendors to act quickly and patch things up. None of this is true for WebAssembly.

Then we have the issue of code being obfuscated when compiled into bytecode. So now it is even harder to detect malicious code.

There are already decompiler tools for WebAssembly, which translate the bytecode back into the AST or even some JS-alike syntax. It's not that much less human readable, than a deobfuscated JS code, which someone ran through an obfuscator before, IMO.

It seems I am not alone in thinking this way. Just read the comments posted at the link listed in the first message of this thread.

I think there's still a master switch to disable this in the browsers. I'm sure there'll be tricky attacks, but these happen with normal JS anyway. But I don't think it'll be such a disaster as people predict. (And I'm usually quite pessimistic about such things.)

Charlie

Karoly Balogh wrote

I think there's still a master switch to disable this in the browsers.

So far Firefox 52 has none. Not in the Preferences, and not in about:config either.

But yeah, it is early days, so hopefully security will tighten up in the near future.

Regards,
Graeme

It should be opposite. Start with very tight security, and loosen up if deemed safe...

Michael.

Hello,

about:config

javascript.options.wasm;true/false

Michael Van Canneyt wrote

It should be opposite. Start with very tight security, and loosen up if deemed safe...

Yes, that definitely is a much better way to go.

Regards,
Graeme

José Mejuto wrote

about:config javascript.options.wasm;true/false

Thanks for correcting me, my bad. I search for "assembly", "webassembly" and also looked under "security.*"

Regards,
Graeme

is this a takeoff from the movie AVATAR where they go up to choose their flying lizard creature?

Well I used to think 32 bit integers were good enough for everyone, but now I wish that all our integers went on to infinity, as some clever person probably wants to create some program you never dreamed of that will hit the integer limit...

But for dumb things like web stores, blogs... Yes.

For some physics simulation that is a massive number cruncher "no integer is ever big enough"...

The way is already paved.

In fact, there is an alternate approach, transpiling pascal to Javascript.

It's much farther ahead than the webassembly target, already produces programs running in the browser and the first web-based components are already being developed using this approach.

Michael.

Hi,

I believe these will be complimentary solutions in the end, one will be better for certain things than the other, with a lot of overlap, of course. I think the transpiler might be better for developing unique front-end solutions in Pascal for the web, the WebAssembly compiler might be better to bring existing large chunks of code to run on the web, with minimal modifications, and for performance critical things.

But only time will tell. :)

Charlie

Fully agreed, and the "unique front-end solutions in Pascal for the web" is the intended target.

Michael.

And I am pleasantly surprised! :) That demo worked perfectly on my system. Sound, animation, graphics all silky smooth. Impressive indeed.

If running a 3 year old iOS Demo in a browser when we have seen Unreal Tournament 3 being playable there 4 years ago is impressive is debatable. For me the impressive thing is that FireFox with WebAssembly manages to show the same performance as Chrome without it. Having them run side by side both fullscreen I can see no performance the JS side is doing so little that it hardly matters (as it should be, when doing WebGL you want to do as much on the GPU as possible). First benchmarks indicate that there isn't much of a performance increase with the current WebAssembly implementation over pure JS anyway. The benefit is that you can 'run C code' in the browser and that's currently it. Having a WebAssembly target for FPC would surely be nice (more options) but hardly a game changer currently. In my little experience with WebGL the JS performance was never that big of a problem but getting lots of data into the browser without the transfer being super slow or the browser consuming alot more memory than it should.

R.

Reimar Grabowski wrote

Perhaps the JS side is doing so little that it hardly matters (as it should be, when doing WebGL you want to do as much on the GPU as possible).

A very good point. It was probably all down to WebGL (ie: your GPU) doing all the work.

Regards,
Graeme

What is the role of those components ?

Reading this thread I was thinking would be nice (easier to work) ) to have access to browser components via a fpc lib.

Something like fcl-browser-facilities (terrible name, I know), where you could simple calls to DOM parts.

Whether this is already in fcl-js, sorry, I didn't knew about it..

You'll design a web app in the lazarus IDE (or Delphi IDE, for that matter). The app will be compiled to Javascript.

Current thinking is that that there will be 2 "modes":
- "Free" Mode, where the CSS will determine the actual runtime look. The IDE will just create the DOM structure.
- "Exact" mode, where the app will look in the browser as it looks in the IDE. the necessary CSS will be generated for this.
In both modes of course the IDE and object inspector will be used to create event handlers and whatnot in Pascal...

But this is all still under heavy development.

Michael.

Forgot to say that there will of course be some classes to manipulate the .

Michael Van Canneyt wrote

Forgot to say that there will of course be some classes to manipulate the you, Michael.

Sounds Great !

Should be independent of compiling it to Java script or to Web Assembly (provided decent "Widgets" are provided/usable with WebAssembly: I don't know anything about those).

(Is this not more like an issue for the Lazarus community, as they are supposed to provide "Widget Type" settings for such targets ? )

-Michael

Reimar Grabowski wrote

First benchmarks indicate that there isn't much of a performance increase with the current WebAssembly implementation over pure JS anyway.

A "decent" Framework will compile both to machine code in an "ahead of time" manner, so simple close loops should result in very similar performance.

The compiler creating WebAssembly can introduce decent optimization. So performance will depend on the Compiler-

Hand written Java Script might be good or bad so performance will depend on the author.

It will be interesting to compare the result of the two fpc compilers, when available :)

-Michael

It did not work on my old Tecra 9 Windows 7 Laptop with about 3GB memory

Why run webgl through javascript if you could just make something like a flash plugin object (like youtube videos) that plays opengl scenes using some native format similar to how flash uses SWF files, or whatever?

I think there was some opengl plugin object, but can't remember...

It seems like almost the web browser is trying to become Emacs, everything and the kitchen sink, though...

If it includes opengl or webgl, and video players, and.. everything under the sun.. it makes me wonder whether we should really not be going back to exe's again... I.e. if you want to download a opengl application, you just download an exe/elf program instead of running it in the web browser ;-)

Still, web browser (abuse syndrome) apps are cool.

Why run webgl through javascript if you could just make something like a

flash plugin object (like youtube videos) that plays opengl scenes using some native format similar to how flash uses SWF files, or whatever?

Because the point is not to need some strange, obscure plugin that works only on a subset of the platforms the browser supports when the script engine of the browser is powerful enough to do it itself.

Regards,
Sven

Pada Sabtu, 18 Maret 2017 0:54, Michael Van Canneyt menulis:

You'll design a web app in the lazarus IDE (or Delphi IDE, for that matter). The app will be compiled to Javascript.

Current thinking is that that there will be 2 "modes":
- "Free" Mode, where the CSS will determine the actual runtime look.   The IDE will just create the DOM structure.
- "Exact" mode, where the app will look in the browser as it looks in the IDE.   the necessary CSS will be generated for this.

In both modes of course the IDE and object inspector will be used to create event handlers and whatnot in Pascal…

But this is all still under heavy development.

Seriously? Where can we try or test this? This is really a great news! It reminds me of Morfik. :) Hope the development will continue.
Regards,

–Mr Bee

Morfik has been, since day 1, the inspiration for this.

Hope the development will continue.

It is.
The compiler is progressing well. Language is pretty much complete on a D7 level. Currently work is done on implementing RTTI.

Michael.

Pada Kamis, 13 April 2017 13:22, Michael Van Canneyt menulis:

Seriously? Where can we try or test this? This is really a great news! It reminds me of Morfik. :)

Morfik has been, since day 1, the inspiration for this.

I knew it! ^_^

Hope the development will continue.

It is. The compiler is progressing well. Language is pretty much complete ona D7 level. Currently work is done on implementing RTTI.

O, c'mon Michael… please release it. Even if it isn't fully ready, as beta or preview or whatever. We'd like to try it out! I can't wait to test it. :) Regards,
–Mr Bee

Why run webgl through javascript if you could just make something like a flash plugin object

We once did a decent application using Pascal at the server and Flash (Action Script) at the client site. Works very nicely. But Action Script is Adobe propriety and even Adobe says that Flash is depreciated. So at the moment HTML5 and Java script is the way to go, but WebAssembly should recreate Action Script versatility performance in a more "Standard" way.

-Michael

Michael Schnell wrote

So at the moment HTML5 and Java script is the way to go, but WebAssembly should recreate Action Script versatility performance in a more "Standard" way.

I hate Java Script and use NoScript to block it.
I can't understand why scripting is needed for a web page.

Once I could do even my home banking without scripting but meanwhile scripting spreads over all the internet. For security reasons this is a desaster and
I never found anything useful with scripting.

The most annoying thing with scripting is, that you potentially download arbitrary code with every click.
A browser should only display information but never execute arbitrary code from a web site.

Simple: to improve the user experience.
Things like google calendar would be impossible without it.

Michael.

Why is it scripting needed to display a calendar?

I am not against improving HTML but allowing arbitrary code on a web site is of no use (for the user) IMO.
It's just a security hole.

Code can be executed on the server if needed.
On the clients only what the HTML-language provides shoud be allowed. And executing arbitrary code should not be part of this language.

To display a popup menu, for example.

Or completion when typing in an edit: when you invite someone, it's handy when calendar suggests the contact name.

Michael.

Michael Van Canneyt wrote

> Why is it scripting needed to display a calendar? To display a popup menu, for example. Or completion when typing in an edit: when you invite someone, it's handy when calendar suggests the contact name.

I doubt that you can do this only when allowing the execution of arbitrary code (although I don't know very much about current HTML standards).

In the end Scripting is like downloading executable files with each and every click on a web page.
I do not want this.
I want to keep control about what is executed on my computer.

So you are running an open source OS ?

Michael.

Michael Van Canneyt wrote

> I want to keep control about what is executed on my computer. So you are running an open source OS ?

Unfortunately not (yet).
I am working on getting rid of windows
but some programs not available on Linux
prevented me from doing this step for now.

Nevertheless, the point is not to just run
open source programs (and OS's).
I install a new OS very seldom
and these OS's are under public observation.
We know quite a lot about Windows and what it is doing in the background so I am no so much concerned about it (yet). I disabled updates so I don't get unexpected changes in the background. And I use Win 7 and 8.1 but not 10.

Same applies to programs.
I cannot wade through all the code even if it's open source. I have to rely on the fact that popular programs are under public ovservation and that unexpected behaviour will be known soon.

For web pages this is totally different.
With scripting you install and run completely unknown code hundreds of times a day. An infected or otherwise malicious web page will not become visible at once because they can change very often and there are many of them.
Therefor I use NoScript to prevent me from such code. 90% of these web pages using scripting are crap anyway. Scripting is mainly used to annoy the user with add popups etc.

Serious web pages don't need scripting IMO.
They should provide information and that is possible without it.

On Apr 14, 2017, at 7:26 PM, Jürgen Hestermann wrote: I doubt that you can do this only when allowing the execution of arbitrary code (although I don't know very much about current HTML standards).

I think you’re confusing Java for JavaScript. JavaScript doesn’t allow execution of arbitrary code and as far as I know it’s still the only language that can manipulate the DOM on the browser to perform actions on the client side like changing the properties of HTML elements.

Regards,
Ryan Joseph

Ryan Joseph wrote

I think you’re confusing Java for JavaScript. JavaScript doesn’t allow execution of arbitrary code and as far as I know it’s still the only language that can manipulate the DOM on the browser to perform actions on the client side like changing the properties of HTML elements.

Well, it's not exactly the same as running native programs but nearby. For example, see https://www.veracode.com/security/javascript-security .

Jürgen Hestermann wrote

I can't understand why scripting is needed for a web page.

Regarding the discussion here, the term is "Rich Internet Application" ("RIA") -> https://en.wikipedia.org/wiki/Rich_Internet_application

Here, a server based application (e.g. done in Pascal / fpc / Lazarus) shows a GUI within a browser. The connection between the Browser and the program being done via a standard HTTP server.

-Michael

Jürgen Hestermann wrote

Why is it scripting needed to display a calendar?

Most obviously: (OK. I do know that there is a timed reload instruction in HTML, that I malevolently ignore in this post, but it would be a PITA to use same in a more complex example, as it would reload everything instead of updating e.g. just a single number, as often needed in a RIA GUI.)

You keep the Browser Window open and at midnight the sheet for the new day should automatically be displayed.

HTTP/HTML can't do that, It's strictly unidirectional request->answer. (Which in fact is completely silly, but we need to live with that).

So Java script can do the necessary polling.

-Michael

Michael Van Canneyt wrote

> Why is it scripting needed to display a calendar? To display a popup menu, for example.

But apparently you don’t need JavaScript for that either. Here is a blog post (dated 5 years ago) where the person proved just that - you can use HTML and CSS alone to accomplish popup menus and modal dialogs without JavaScript. ;-) Web developers just chose not to do so. Makes you wonder what else is possible (we all know Web Developers like to take shortcuts and live by copy-and-paste coding styles).

Popup windows without JavaScript
http://eichefam.net/2011/12/21/popup-windows-without-javascript/

Regards,
Graeme

Jürgen Hestermann wrote

I hate Java Script and use NoScript to block it.

You don't need a browser add-on for that. Simply go to (Firefox) about:config and search for JavaScript. Double click the "javascript.enabled" preference and it will toggle between enabled true/false. There used to be days (years ago) when this setting was directly available in the Preferences dialog. Good old times. ;-)

Regards,
Graeme

Jürgen Hestermann wrote

Therefor I use NoScript to prevent me from such code. 90% of these web pages using scripting are crap anyway.

It's also nice to see how fast web pages load if no JavaScript is enabled (magnitudes faster). Also most web Ads stop working too. A nice bonus. :)

Regards,
Graeme

That was only possible after CSS had been 'updated' to include some dynamic effects.

And CSS will not help you for example with autocompletion in an edit box.

The people fighting javascript in the browser are fighting a reargard battle. It will only get worse. As long as there is no acceptable alternative for the browser, this will continue to worsen...

Michael.

Michael Van Canneyt wrote

The people fighting javascript in the browser are fighting a reargard battle. It will only get worse.

Indeed, I was simply pointing out that _some_ functionality is possible without JavaScript, but the majority of what we consider "the standard web" seems to require JavaScript - if you like it or not.

Regards,
Graeme

But NoScript has comfortable functions do allow scripting for certain web pages or even only parts of them
in case I am forced to use scripting on "special" cases. I can do a white-listing this way.
It seems that about:config cannot distinguish between special web pages.

Why run webgl through javascript if you could just make something like a flash plugin object (like youtube videos) that plays opengl scenes using some native format similar to how flash uses SWF files, or whatever?

First of all you don't run anything through anything. Web/OpenGL (ES) are in effect just a bunch of commands sent to the driver. It is not really impacted by the language from where you call it. It is just a graphics library Second OpenGL scenes are not played, they are interactive. Third people don't want to deal with (buggy) plugins they want sh!t that just works across browsers.

It seems like almost the web browser is trying to become Emacs, everything and the kitchen sink, though...

Maybe, but "direct" (yeah I know it's not really direct, that's what Vulcan is for) access to your graphics card inside the browser is IMHO a nice feature.

If it includes opengl or webgl, and video players

That's what your graphics card/chip gives you even on low end systems like the pi out of the box, so why not expose this inside the browser?

under the sun.. it makes me wonder whether we should really not be going back to exe's again... I.e. if you want to download a opengl application, you just download an exe/elf program instead of running it in the web browser ;-)

Only that the stuff in the browser seldom is what you call an OpenGL application (whatever that term means) and as noted above people are not going to download apps for stuff like this. Examples:

https://arachne.dainst.org/3d?id=2
http://www.chaostoperfection.com/
http://www.zamaniproject.org/index.php/ethiopia-3d-model-of-medhane-alem.html http://cabinetdecuriosites3d.mnhn.fr/fr/content/cro-magnon-1-homo-sapiens http://vcg.isti.cnr.it/3dhop/demos/capsella/index_capsella.html

R.

Btw, all the links above will infect your computer with all kinds of nasty malware. Clicking them will kill every first-born egyptian child, etc You have been warned, so go there on your own risk