This could be interesting.

http://webassembly.org/

--
Chris Holland
[Team Elevate]

Chris Holland wrote:

> This could be interesting.
>
> http://webassembly.org/

One to watch, but I hope that Tim does all the hard work for us. I guess our ideal would be EWB outputting two forms, one wasm and one as current, and the HTML would load the best one for the browser.

It would be good to have some input on the future of WebBuilder - not sure I care much for the server side idea that is currently a target. Of course I'm perhaps not the target market for it either...

--

Matthew Jones

Matthew,

<< One to watch, but I hope that Tim does all the hard work for us.>>

Of course.  I've been waiting for WASM for some time now, in hopes that it helps reduce the emitted size of EWB applications.  In case you're wondering, that's one of the main reasons why I've kind of stalled on EWB recently - I'm still trying to figure out some changes to the architecture that cuts down on the emitted code size.

<< It would be good to have some input on the future of WebBuilder - not sure I care much for the server side idea that is currently a target. Of course I'm perhaps not the target market for it either... >>

What I discussed is an attempt to a) target implementations where the usage is more "page-oriented" or "document-oriented", and b) deal with the above by splitting out the usage into two separate areas of concern.  In such a case, you would use "traditional" EWB for apps that become more like plugins on an existing page.  In other words, using traditional EWB more like Silverlight.  But, the key here is that the whole stack from front to back would use the same Object Pascal implementation, and the back-end would be scripted so that you could roll out changes very quickly without requiring a restart of the web server.

Tim Young
Elevate Software
www.elevatesoft.com