This topic contains 9 replies, has 7 voices, and was last updated by 
Ethernaut
4 months, 2 weeks ago.
-
Posts
-
I read the latest news update and maybe hopefully I just don’t get it.
Is Monkey2 going wasm/html5 only?
My old self that kust did this for fun wouuld have picked wasm only and I would have loved it. But now I am trying to get food on the plate from my programming.
So I need to know exactly what will happen to Android and iOS support now?
I think it was mentioned that ios and android will continue to be supported but the main goal is to get the html5/wasm target working perfectly with less of a build time.
I would note this line, too:
I do plan to continue supporting monkey2 on other targets, and will continue to do so for as long as people keep posting issues at github
So get yourself a Github account if you don’t already have one! Mark’s done plenty of fixes for me and it’s easy to report them via:
https://github.com/blitz-research/monkey2/issues
(Main page -> Issues -> New Issue.)
My two cents:
There are other solutions out there that allow JS on desktop and mobile (Electron, etc.), and one of their biggest selling points tends to be that they are an “easy” 100% multi platform, without requiring complicated setups (different compilers, etc) for each platform. The exact same code just runs on a different “player”, so to speak, on each platform.
Those solutions are currently very popular with apps . Go to https://electronjs.org, scroll down to see a bunch of “heavy hitters” like Skype, Slack, GitHub Desktop, VS Code, etc. To me this seems to validate this type of technology, at least for Desktop apps. And some (most? all?) of those aren’t even WASM yet, they’re just straight JS, and still seem to perform really well.
So I don’t see why going WASM would cut platforms off Monkey3 (If that’s the name), if anything it would make it easier to support more, since there’s technically only one target, instead of a plethora of moving targets. I don’t know which “player” solution Mark has in mind, though, I hope it’s something he won’t try to maintain himself.
The biggest question remaining is performance, but as far as games are concerned, WASM could run at half speed compared to compiled c++ and you would probably still be using less than 10% of the cpu, so… not really a problem, I think?
Cheers.
Oh, god no! Desktop web apps are universally AWFUL! And they have to ship with a hundred MB of web browser each time — slow, buggy, terrible “custom” interfaces in every case. No no no!
More seriously, I think the core native stuff maybe isn’t that much for Mark to maintain, at least relative to the std/mojo modules, and they’re all in .mx2 code, so perhaps the C/C++ support isn’t really the larger part of the work. Certainly most of the stuff I’ve reported and had fixed was in the .mx2 realm.
This is the only way I can imagine Mark can commit to supporting the non-wasm platforms, as otherwise nothing’s changed in terms of workload!
(He said, cluelessly.)
From what I understand this transition will happen only in the VM part.
(Unless I talk about rubbish -> The only who can explain this properly is Mark)Let’s say that you want to avoid compilations-recompilations so you need a VM, what would you choose? In essence we talk about these technologies: CustomImplementation / Python / V8Javascript / DotNet / Java / Lua.
If you take such a programming language and strip away all of the language-syntax-framework-libraries-parser then the only thing that will be left is the VM (nodejs actually runs on V8 VM). Then you can throw whatever instructions there and have them executed.
https://webassembly.org/docs/non-web/
https://v8.dev/So in essence more or less you all know what goes for all of these programming language VMs, but webassembly has been proven to actually work (actually is the one that achieved “ProgrammingLanguageSingularity” -> eg: compile a g++ program from a Linux environment running in your browser and download it and run it on your Ubuntu desktop).
Such examples make webassembly a safe choice.
Whilst I agree that making web apps actually work is a good idea. I’m definitely with My Bunny: web based apps are terrible – period!
Wasm might be the executable of the future but if we’re talking about the situation as it is right now then we still need true native code, and we will for a couple of more years..
The quality of the user experience would otherwise go down too much, and the marketplace is not ready for it.
Sure some things could be done but that would downgrade Monkey into some kind of Authorware.
Nice wasm players should emerge at some point, if wasm has some success. All the crossplaform work would be done by the player’s devs at that point. The fact that you have to reload each time is a big problem, but can be avoided.
I’ll probably still go on the native way for some time anyway. I love mx2 because I can use any C libs and almost any C++ libs. And that’s where open source is the most accessible.Sorry for the confusion, I didn’t mean to imply that Monkey WASM and Electron apps would be the same thing. I believe a Monkey WASM app would still feel like a Monkey app as far as the end user is concerned, while Electron apps are essentially web pages running locally, with an html+css interface, etc.
What I was trying to point out is that both things would share one benefit, which is easy portability, and I believe that answers the original question – Will it run on Android and IOS?
You must be logged in to reply to this topic.