I know there’s a new version of the XojoWeb framework coming out.
Xojo hasn’t announced any details other than its coming. With all the SPA (Single Page Application) frameworks out there (React, Angular, Vue) I feel like Xojo would be behind to release something that is pretty much all ServerSide code and not ClientSide code running in the browser. I also understand the complexities of trying to get the Xojo framework ported over to completely run in the browser - that undertaking would be huge… but as I continue to learn about the evolving WebFramework and as I see that all the major browsers now support WebAssembly I was wondering about the viability of getting a Xojo application to run as a WebAssembly in the browser. (?)
WebAssembly (.wasm) files are significantly faster and more efficient. I just watched a demo where they animated 3D models on a webpage using javascript and then showed it running in WebAssembly. As they added more and more models, the javascript killed the frame-rate and performed poorly while with WebAssembly performed smooth with hundreds of moving models.
I’m not super technical on the compiler/linter/intepreter way of how Xojo works. I know they can compile down to LLVM. But just curious what kind of an undertaking it would take for Xojo to support this and if its something feasible. There does appear to be some support for LLVM -> WebAssembly stuff out there.
Granted this doesn’t really address the issues of responsive design etc… for the webframework, but definitely seems like it might be a way to get Xojo code to compile for the browser and then the HTML can just call into the “wasm” files compiled by Xojo.
This topic is mostly intended to be directed around the feasibility and thoughts about Xojo implementing WebAssembly
WebAssembly currently cannot manage the DOM and only supports integers and floats. It is not very practical beyond tech demos or graphically intense operations. It would be very difficult to use it for any type of traditional web app as the bridge between JS and WebAssembly is slow and complex (converting all strings and complex objects into integers and back and having to talk to JS for any DOM manipulation).
Even though it can’t manage the DOM, the Javascript can. As long as the Javascript can call and get the response back from wasm, that response can imbed instruction on what to do with the DOM. I watched a demo of C# code compiling and running as a wasm, it’s all still experimental and under development but definitely has value. (Check out Blazor if you’re curious)
And while I agree that WebAssemly is complex. It is definitely not slow. It is insanely fast, even with converting the types to sending them in and out of the wasm
[quote=377836:@Brock Nash]I know there’s a new version of the XojoWeb framework coming out.
Xojo hasn’t announced any details other than its coming. [/quote]
You’ll be at XDC right? We’ll be talking about this at 11am on Wednesday
Some of the obstacles have not changed from day 1. Think about all of the things that the Xojo framework does that’s not user code… database access is a great example. We can’t just “compile” that into javascript because it requires TCP sockets, access to the database server and synchronous requests… all things that don’t come easily with the code being run on the browser.
Yeah, I definitely understand that. That’s why I’m keeping a fair amount of skepticism with what we’ll all get. Personally, I would rather have two apps. An API Console application for all the ServerSide code. And then a completely ClientSide application for everything else.
Been also learning a lot about HTTP2 and how it streams all the content and speeds up page loads. I can’t recall if that is something Xojo does, can, or will support? Its also cool how it can stop sending a file midstream if the user says they have it already, and then moves to streaming the next resource. It removes the need for bundling but minification is still important.
I honestly don’t expect to see much of anything along the lines of client side code. The things I’m more realistically hoping for are responsive design, better style support, better DOM manipulation. With interops coming for desktop, I would LOVE to see interops work with TypeDefinitionFiles for the web. Just import a Javascript library and its TypeDefinitionFile and then be able to build the scripts right inside of XOJO to send them to the browser.
I did something similar with my JQuery library:
But making it was a ton of work, having a generic way to generate these libraries based of a standard would be HUGE to opening up the web framework.
The reality is that Xojo isn’t a big enough company nor is the user-base large enough for everything we need to be baked in. So implementing things like interops, library generation based on Swagger docs or TypeDefinitionFiles is key to increasing productivity and adoption.
Regardless I’m very interested in seeing what the Xojo team has put together.
I’m sure there will be a lively discussion on this forum as soon as XDC starts. You can probably search on this forum for previous XDC threads. It’s always an exciting and fun time
I’m in session at this conference and they’re now showing off xamarin running as WebAssembly in the browser. It definitely feels like this is the way of the future. That’s now two frameworks at this conference showing off this technology.
On break, I talked to the guys running the session here and they said that essentially you can pass callbacks into the wasms that can then manipulate the DOM but that native DOM manipulation is getting spec’d into WebAssembly right now. Obviously the two frameworks I mention will take care of rendering for you, which is exactly Xojo could do.
That bridge is fairly expensive as all strings/JSON/etc have to be converted to integers.
I am not saying WebAssembly is bad - I am a big fan of it. It is just not near the point yet where it can be largely consumed by generic web application builders like Xojo. It will only be used in very specific scenarios for now until DOM support is added and the JS bridge performance is increased.
