Xtalk in a browser, again... thoughts and issues

[tperry2x]

As Paul has stated many a time, and I'd absolutely agree - I don't see the long-term future of OXT as continuing with this engine. Far from it, and that's becoming perfectly clear when looking at the difficulties compiling it - and the many many memory errors that are flagged as being show-stoppers in the xcodeproject (mac version).

As Paul mentions, he's a bit engine-agnostic - Same here. For me as long as the engine has feature-parity (be it a web-app that you run containerised on the desktop) - so walks and talks like a normal program, but is actually more akin to using browser technologies at the core to render to screen and do the heavy-lifting.
Everything else as far as the xTalk scripting and stacks sits on top of that layer.

I was always just against the idea of having to go to https ://some-website-domain/userarea/my-stack-I-can-only-run-online because of the requirement for having it all online and having all the eggs in one basket.

However I'd say that the current basket the inherited engine is sat in looks decidedly tatty now.

If we have a comparable feature set in the web-app-engine, the idea is that you'd be none the wiser.

And there lies the issue. Developing a comparable feature set to what we currently have in our inherited engine, using web technologies, is no small task.
In fact, it's an absolutely massive task. There are some large hurdles at the moment, such as how the browser restricts the user from actually saving content out. A lot of system calls and such, to interact with the computer hardware, are also heavily restricted.

The other aspect that would put me off is engine loading times in a browser. Not so bad for everyone with good connection, but I can be sat there waiting for a minute for about 30MB to download, and seeing nothing on screen.

I wondered if it's possible to have the web-playground-oxt version load the bare-bones of what it needs (perhaps just a couple of hundred kb so it can load a basic interface, a welcome screen... just present the user with the basic tools, such as a dialog like "New stack size" - which require user input, while it loads the rest of everything else in the background. Thereby making it seem like the program is waiting for you, rather than you waiting for it.

Of course, at the moment, there's no way to load this from the SSD/HD directly as a web-app, and I'm sure that would make loading everything almost instantaneous in comparison.
Loading OXT Lite as a conventional program takes under 30 seconds even on the slow old 10.9 iMac sat in the corner here. Opening it on even a 6 year old linux pc takes approx 8 seconds, and 20 seconds in windows 11 (but less said about how slow windows 11 is on older hardware the better). Can we have under 10 second launch times for the web-OXT version I wonder?

Also wondered about how to make it feel more responsive, as there's no getting away from the fact it feels sluggish. And that's with a small subset of capabilities compared to what our inherited engine can do.

As much as I go on about inherited engine problems, developing "Create" (or whatever it is), is a huge task for LC too. The difference there is they have multiple developers to throw at the problem.

[tperry2x]

So with that all said, I'd like to try and gather various bits together here.
Perhaps I can start by asking Paul if I've got the gist of this right.

What are the current challenges?
As far as I understand them - it's

• writing to file reliably

• getting hardware properties

• in theory, setting hardware properties too is probably heavily curtailed (such as sound volume).

• There would be no shell function, so querying system properties or anything that requires shell commands is out.

I'm sure I can think of more, but this isn't meant to be a post about "things the web-containerised version can't do" - more, what are the challenges and what should I be looking into to make them work?

My other worry is what if it's decided tomorrow by all the browser creators, that a certain feature "OXTUB" (oxt using browser-tech) relies upon is now blocked. The whole IDE stops working overnight.

[tperry2x]

At the moment, this type of browser sandboxing (and lack of access to the terminal) seems like it's going to be the show stopper for a 'full-on' engine replacement.

As an example, look at Microsoft Visual Studio (Web) - they point people towards using the desktop version if they need to run shell commands. They don't even allow this, and they also make a browser (so could in theory allow that) - but doing so would open a pandora's box of security nightmares.

if you need access to a runtime to run, build, or debug your code, you want to use platform features such as a terminal, or you want to run extensions that aren't supported in the web, we recommend moving your work to the desktop application

Perhaps what we need is a cut-down (like I'd been saying before), almost Python-iDLE -esque version of OXT for the web, which can save out as oxtscript stacks. They could be runnable online in the web version, but in a very reduced subset.

I think developing a full UI for the web is going to have to come with the proviso that to do more, and access system-level functions, you'll need a desktop version of the IDE.

[richmond62]

There has to be a desktop IDE that is not dependent on an internet connexion.

[tperry2x]

Yes, this is what I mention above. It's using web technologies, but the goal would be no web connection necessary.

I'm firmly rooted in desktop-OS, but that's not to say I reject the web technologies - I just don't want to have to login and load the IDE from a server first.

Or worse still, I don't want to have to sign-up & register, then sign in each time before I can write a line of script.
That's why the first chance I got, I removed the sign in screens from the Linux and Windows version of the engine.

OXT lite uses no user telemetry tracking. The only check it ever does is to see if updates are available. Even then, it's only transmitting a version string (1.09 for example) and a build number (202411172019 for example). It does these over https, even though there's no user credentials submitted (not sending passwords or sensitive info) - but I also worry about how much information is gathered as far as telemetry goes with an online platform.

They know you need internet to use it, so if it's running in a standard browser - it's easy to transmit someone's complete search history and access the clipboard through various javascripts and dhtml. Web-apps are sometimes touted as an extra layer of security, but in actual fact, it exposes a machine to the internet and does quite the opposite.

The idea of web-apps being more secure is not the case, as you've effectively turned any app into a piece of network infrastructure that has to be considered a vulnerability until proven otherwise. Whereas, if you have isolated desktop systems, the worst that anyone can do is look over your shoulder as you type a password in.

In short, there are advantages and disadvantages to both approaches. I'm not firmly decided about which approach I'd favour, but this isn't about me: it's about what the expectation of users would be and what they perceive as the norm.

While Microsoft (with Visual Studio) and Apple (with xCode) continue to offer desktop IDEs for their programming requirements, I'm inclined to go with the desktop paradigm.

However, I can't stress how impressed I am with Paul's web-efforts - because even if that does end up being containerised as a web app, these are things we need to think about.

[tperry2x]

This also makes me think about who uses what...

Most people under about 20 years of age, would probably frown that things aren't web-based (or at the very least, don't come in mobile-app-form). Give them a laptop and they roll their eyes. Give them a desktop computer and they look at you like you've just crawled out from under a rock.

There's no getting away from the fact that proper development will involve a desktop or laptop computer of some description. So I don't think we are at the point where we have to abandon laptop or desktop use yet.

I always said that my approach would be an old-skool one, and I still make no apologies for that. However, just because I want to do that - that's neither here nor there. It's about what OTHER people (if we want to see more users and NOT see xTalk fade into obscurity), it's about what they expect.

Ultimately, why are we churning out standalones for desktops when the only people coding/scripting using those desktops are targeting web UI and mobile devices.

So this is why I think having a tablet-app version (even if that's a cut-down version of the IDE) that can save everything in livecodescript form would be good, and I may spend some time looking into this next.

Running this IDE on desktops?
As ARM macs can run iOS apps on the desktop, as if they were native apps, this would also mean that such a cut-down IDE would run on ARM macOS as well. (I say cut-down, it doesn't have to be - but initially it would be). That can then offer the best of both worlds - filesystem access and saving, while being built for handheld devices.

For Linux, there's Anbox or Waydroid, which looks promising - essentially allowing you to run the APK on a desktop or laptop linux distro - although some setup is required, this could be fashioned into an automated process.

This way, we already have an arm platform for Apple and Android devices that we can develop for. We can also target intel x32 and x64 bit platforms for android too as that's already there.

Just thought that perhaps developing via the iOS app and Android APK method might require less reinventing everything from the ground up than a containerised web-app version would.

This is all just conjecture and ideas at the moment.

[richmond62]

Well I am churning out desktop standalones because I am deploying them to computers that deliberately have no web access in my EFL school.

Web access in my school (I have 4 other computers with that) has proven a distraction in the past, and neither I, nor my staff, want to be policemen.

There are plenty of schools in plenty of countries where internet is either not available, or is too expensive for whole classrooms.

The children who attend those schools should not have to belong to some sort of educational under-class just because their school cannot provide always-on-always-fast internet.

Just to prove that internet-enabled is not always 'the thing' even if Bill Clinton thought it was . . .

I helped a few teenagers a while back with Turbo-PASCAL (felt very unTurbo to me), using several 'heaps of junk' running FreeDOS with OpenGEM.

[richmond62]

Google are talkjng about the next version of Chrome OS being Android-based.

[tperry2x]

This is the thing though, it's not about what you or I may be doing (we'd just continue to use the desktop IDE, probably until I'm old and grey(greyer)..) It's about what other people are doing and expect.

But none of what I've talked about essentially needs internet access, other than to initially install it.

[richmond62]

As Open Source is what it is, it doesn't have be about keeping anybody happy.

[tperry2x]

As Open Source is what it is, it doesn't have be about keeping anybody happy.

In that case, I'll carry on with my idea since I don't have to worry about keeping anybody happy.

[tperry2x]

Just setting up to build iOS apps in the IDE. This is quite interesting. I seem to have all the development profiles from the LC staff:

Screenshot 2024-11-20 at 19.20.00.jpg (160.89 KiB) Viewed 2954 times

[richmond62]

I seem to have all the development profiles from the LC staff

Probably because that's the 970 code.

Fraser bailed out slightly mysteriously about 4 years ago (probably because he was being very helpful to people on the LC Forums . . . ROFL).
-

Fraser.jpg (6.64 KiB) Viewed 2953 times

-
He is a senior C++ Software Engineer at IMAX.

I suspect they are not very useful, unless, or course: erm: when you click on their developer profiles all sorts of interesting and useful stuff you do not know already comes up.

[tperry2x]

Probably because that's the 970 code.

Nope. Don't forget, this is on a mac - so it's using the 9.6.3 engine and 9.6.3 IDE files.

[richmond62]

Aha: well my previous comments stand.

This is a bit odd:
-

Screenshot 2024-11-20 at 21.56.59.jpg (249.74 KiB) Viewed 2946 times

-
I cannot either make the Standalone settings stack bigger, or scroll down to the stuff at the bottom.

The main snag I can see about those profiles being there is that 'naughty' types like myself can pump out standalones pretending to be a member of the LiveCode team: so they definitely have to be removed.

[tperry2x]

Aha: well my previous comments stand.

How so?
What were your previous comments? - oh yes: Probably because that's the 970 code.
I've just said it's not. It's 9.6.3 code. (didn't come from github). It comes from the publicly available LCC 9.6.3 disk image released to the public. That's been sat there all this time.

I cannot either make the Standalone settings stack bigger, or scroll down to the stuff at the bottom.

The standalone stack is full of bugs like that from LCC 9.6.3 and I do know about this.
Click the android tab (that I fixed), then click the iOS tab.
That is on my to do list.
Before LC made the bug reporting page login-only, I did make a note of that. It's hard to remember all the bugs reported over time by users - just because there are so many.

Anyway, didn't think you cared about mobile builds?

Doesn't help that I can't see that bug page now because it's behind a login-wall, but it's another D-move by LC, which I'm getting used to expecting.

[tperry2x]

The main snag I can see about those profiles being there is that 'naughty' types like myself can pump out standalones pretending to be a member of the LiveCode team: so they definitely have to be removed.

That would be a pity wouldn't it.
Why am I doing LC's bug-fixing for them?

[richmond62]

Why am I doing LC's bug-fixing for them?

Many, many times I accused LC of running hell-for-leather for the 'next big thang' instead of taking care of a myriad of problems.

I was squished many, many times by both LC staff members and the 'party faithful' on the forums.

My accusations stand.

It is unfortunate that you have to do their dirty washing.

[tperry2x]

It is unfortunate that you have to do their dirty washing.

I find that everywhere.
A good example is the LC team leaving their full profile paths in images, which aside from being a bad move, means that these images won't load and are orphaned.
This missing image resides (did reside) at the location I've drawn a red box around. Won't load properly and is the missing image is that way in the "Project Browser"

This also shows that they were using Windows for development. Not solely macs.

[OpenXTalkPaul]

Electron (and similar) can wrap web apps in 'Native' skin which like any desktop app allows for DIRECT native access to file system (provided it's given permissions to do so), it also provides for using shell, and a lot more (like allowing us to use all of the Node.js and similar of a vast JavaScript ecosystem). I'm guessing that is basically what "LC Create Native' is.

I've already did some basic testing of wrapping OXT Playground + Emscripten engine as an Electron desktop app. Electron does make for a rather large app (150MB to 200MB) because it's basically including an entire web browser with your app.

Emscripten OXT engine is 28MB I think because it's built on older ASM.js, re-compiling it as WebAssembly could potentially cut the size of it in half. Dan's trans-piling polyglot (JS&XT) HyperCard Sim 'Engine' is around 300K and comes with nearly feature parity to HyperCard 2.4+ (the plus is support for XCMD/XFCN that came with HyperCard ), but it's very easy to modify and add to it's grammar, and it has a bit of an IDE built into it already (albeit somewhat limited and it's CSS-styled to look like HyperCard running on System 6/7). There also a few other Web based xTalk projects around on GitHub.

Even running sandbox in a web browser, it is already possible to use web APIs to do file-I/O, but it MUST be importing files must be initiated by the browser user (via either drag-drop action or an 'open file' dialog). The biggest problem with I/O is using that to import export a stack. It can create and edit stacks in its virtual filesystem (in the browser's cache) but I haven't figured out a way to get at the raw-binary data of those newly created stack files in memory so that I can export it as a stack file via web APIs. Unless it's a script-only stack in which case it's just a regular text file (the OXT playground already has a demo of export/saving a text file).

Modern Web Engines come with a lot of built-in APIs already, from which we can pull in information about the environment it's running on, such as things like checking the platform, architecture, darkmode, etc. are easy to get from these web engines which would mean less need to use the shell() anyway. Support for multi-media playing, text-to-speech, gamepad input, WebAudio, WebMIDI, SVG animations, and much more already come included with most web frameworks.