December 2, 2018 at 12:11 pm #15651
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?December 2, 2018 at 4:13 pm #15652
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.December 2, 2018 at 7:11 pm #15654
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:
(Main page -> Issues -> New Issue.)December 2, 2018 at 11:33 pm #15655
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.December 3, 2018 at 8:23 am #15656
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.)December 3, 2018 at 10:55 am #15657
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)
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.
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.December 3, 2018 at 1:52 pm #15658
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!December 3, 2018 at 2:29 pm #15659
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.December 3, 2018 at 3:05 pm #15660
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.December 3, 2018 at 7:06 pm #15662
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.