(Creating a new thread instead of using "Help System with Chromium Embedded component")

IMHO Silverlight is dying because Java is the winner over C#, due to Android systems outselling any other OS architecture.

Hence WebASM - that seems to be based on Java - might be successful in pushing the idea of allowing for precompiled byte code embedded in HTML.

Regarding fpc/Lazarus, it obviously would be a huge benefit if on top of fpc's WebAdmin support, the LCL would provide decent support for an appropriate WidgetType that allows to simply cross-compile a "usual" Lazarus project to be runnable in a browser.

The "WEB-LCL"code would need to access the Browser's "GUI" infrastructure using the appropriate API (supposedly defined as a part of the WebASM specs), in a way as compatible as possible to the other WidgetTypes (such as "Win32" or "GTK2").

Of course a "WEB-LCL" and "WEB-RTL" (dynamic Web-linkable) WEBASM files needs to be provided on a server and the project resources need to be embedded somehow.

As a further extension, "in depth" support for communicating (using WebSocket) between the parts of a dual-issue application, one part running in native code on the Server "behind" the WebServer, one part running in the browser, would be very appropriate. (Doing a single "application" and seamlessly distributing it in that way had always been a promise of Silverlight's.)

This is a great opportunity to beat Embarcadero :-):-):-)

Michael (just dreaming)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161109/eba40aa9/attachment.html>

[...] Hence WebASM - that seems to be based on Java - might be successful in pushing the idea of allowing for precompiled byte code embedded in HTML.

WebAsm WebAssembly.

WebAsm is "A processor for text-based documents (most notably, HTML)".

WebAssembly is a subset of JavaScript with some additions, optimized for compiling languages like C/C++/Java to JavaSript. Some browser vendors said they are working on it.

[...]

Mattias

Thanks for clarification.

see -> https://hacks.mozilla.org/2016/03/a-webassembly-milestone/

-Michael

-> https://hacks.mozilla.org/2016/10/webassembly-browser-preview/ :

-Michael

If you mean based on java as in it compiles to a virtual machine like thing, actually this was more of a pascal thing, and oberon thing, than Java - java stole the idea from the UCSD-Pascal system, ancient. I wrote about this long ago... And, I could be wrong but I think java also stole from Oberon. i.e. when people credit Java for the idea of JVM, what they really should be crediting is UCSD Pascal, and then Oberon which succeeded it... Oberon is 1990's and maybe late 80's technology, UCSD pascal is ancient. But I'm nit picking.

I'm partial to Marco V.'s post on the lazarus forum I linked.. I think maybe porting lazarus to web assembly might just result in all sorts of kludges. Maybe best to start from scratch. But as I said I'm partial: not fully decided.

I thought the idea of web assembly was not to compile to javascript, but to compile to byte code..

We already have tons of tools that compile to javascript, so what would be the difference between those tools and web assembly..

i.e. I thought ( could be mistaken ) that web assembly put little chunks of assembly like code in your HTML. Almost like assembly language but higher level.

Does it really compile just to plain javascript? I thought the idea was to actually create a new assembly like instruction language and not use javascript language

[...] I thought the idea of web assembly was not to compile to javascript, but to compile to byte code..

Yes, Javascript compatible bytecode. Keep in mind that the vendors are still experimenting. So it is not yet clear when it will be ready and how the end product will work on the various browsers.

Mattias

Mattias Gaertner wrote

So it is not yet clear when it will be ready and how the end product will work on the various browsers.

Mozilla promises "March 2017". Any information on other brands ?

I only found "Microsoft says it is close to shipping the browser preview of WebAssembly on Microsoft Edge and ChakraCore" -> https://mspoweruser.com/microsoft-edge-get-webassembly-browser-preview-soon/

-Michael

Lars wrote

Maybe best to start from scratch.

Regarding the Lazarus paradigm "write once, compile and run everywhere", IMHO not a good idea.

-Michael

The issue is you are working in a sandbox. Lazarus is designed to take control of the computer using all the dangerous things without any sandbox, such as being able to delete and write to pretty much any file you want that has the correct permissions in place. A sandbox is much more specialized to develop for, because you may only be able to access certain directory with limited files....

So you could modify lazarus to work with this sandbox restriction, but, might be easier to design from scratch. ...

I understand the desire to just take existing LCL app and port it to the web browser, but that's a pipe dream, because browsers will be in sandboxes that just don't work like client applications on Ms Windows, BSD/Linux.

Another option is just to use a separate widget set and see how that works, such as fpGUI widget. But I guess that means you can't as easily take an existing app and port it.

Not really.
Of course it's obvious that stuff like file access can't be done in the virtual machine (or maybe it only can be done if the browser's parameters are set to allow to do so, which supposedly normally is not given).

The real (pipe) dream is a behavior similar to the "pipe dream" Silverlight promised for C#:
Take a C# application that can run on a desktop (or any mobile device) and add certain definitions to the project (source code and/or project settings) and with this split the application in a part that runs on the server (behind the Web Server) and another part that runs in the browser. The communication between the parts is done automatically by the infrastructure. Here file access etc (usually) will be desired at the server site and not in the "sandbox".

Of course this is a far goal, but a more manual way, having the programmer move the "browser" part in it's own units compilable to WebAssmbly and runnable in the "Sandbox", and to add code to call the communication functionality would be a decent step.

Another option is just to use a separate widget set and see how that works, such as fpGUI widget. But I guess that means you can't as easily take an existing app and port it.

Of course this would be a decent *additional* option (as FireMonkey is with Delphi XE), but the "Lazarus" way would be to allow the user to go on using the GUI builder (s)he is trained to use in the best possible way.

I just found that Lazarus now shows "Restriction" notes for all element used in the GUI builder to take account for different possible targets (WidgetTypes). Once this feature is decently supported a check for "sandbox-runability" can be provided.

-Michael