thoughts on wrappers

This post was originally going to be on another thread, but I went off track so I decided to post a topic in the open topics for it, so ladies and gentlemen, shall we begin?

I think the chrome audio issue was a sort of honest mistake from scirra (using a beta feature of chrome in a good chunck of versions), but even then I still think relying on chromium devellopers not breaking things is an issue.

With node webkit, you have even more things to consider than in a browser, and same goes for all wrappers out there.

The problem IMHO is that while those wrappers sort of work, they are still just an ease of distribution: Most of them don't have a big advantage compared to the browser themselves except from their "appearence" (not sure how to call that). Crosswalk suffer the same problem compared to chrome for android, and cocoonJS is ... cocoonJS, not really much to say, and awesomium was just not up to the competition.

Node webkit is a part of C2, as it is distributed with it, but it is like free advertising for node webkit that is hurting scirra more than it helps it, at first it could be done without the need to be implemented with C2, you can still do it yourself, only the node webkit plugin justify its presence, and even then, it could have been just a third party or optionnal plugin.

At first glance from my side, if I am correct, C2 was shipping with some third party wrapper for mobile only, because due to html5 performances on mobile at the time, it wasn t possible to say "mobile compatible", heck even on desktop it was not clear since webGL was not implemented in all main browsers (chrome only?).

Today I fell like those wrappers are not needed, I know, they are needed in a way, since there is no good platform to sell html5 games, but it is funny how people at first were (and still are) saying that html5 and browsers is not good enough for "real games" while it is currently the "better" version in C2 performances wise (unless there are weird forced limitations).

In fact, it is not that they are not needed, it is that they shouldn't had been shipped with the software itself in the first place (again, my 2 cents), since you should be able to convert them on your side, I think there are html5 wrappers outside of C2 compatible with what C2 produces, sure they may not work, but I feel like a non working wrapper not included is still better than a non working wrapper included (I remember someone trying to do a wrapper based on firefox, not sure how that went, I think it was working, but I do not remember of the licensing), some will say that everything is based on a third party (windows, the hardware itself, etc..), which is true, but we are adding yet another third party over that, no, it is even worse, we add multiple third parties that are concurential and even worse, not really working as they should (node webkit on other OSes needs some tweaking, cocoonJS is..dammit it is cocoonJS, it has been broken long enough for the name to speak by itself, crosswalk is trying, but nothing prevents that to fail us someday, phonegap actually call directly a browser inside the device so devices will advance, the phonegap export should become better...if it does not break, but I am more confident on browser compatibility than on third party compatibility, since that is for browsers that C2 was intended to work, ejecta I do not know, and html5 itself is working quite well as long as browser's betas feature are not used in stable versions for too long).

As for a solution, I do not know, scirra cannot just make a wrapper from scratch, they could base it on something I guess, since it is too late to retract now, a native exporter could be nice but really hard to maintain correctly, I would say the wrapper not third party based of an existing wrapper would be fine enough, since scirra would have control over it, but again all of this is just my opinion.

If you have an opinion on the subject, you can reply ^^

I think the chrome audio issue was a sort of honest mistake from scirra (using a beta feature of chrome in a good chunck of versions), but even then I still think relying on chromium devellopers not breaking things is an issue.

You have to count the good in with the bad, though. Yes the proprietary chrome audio api was an issue, but many other things were not (such as webGL, which eventually got adopted in IE and Android).

Also WebRTC was implemented right on time, if scirra had chosen to implement multiplayer early, with the first draft of websockets (which included UDP) or DataChannels, we'd have a problem today, but fortunately Ashley chose wisely.

With node webkit [...] Crosswalk [...] cocoonJS [...] awesomium

Yeah, wrappers have dropped the ball recently. CocoonJS appears to be the only game-oriented wrapper, I think webkit is geared towards application developers, otherwise they'd cut many unnecessary things to reduce the overhead.

Intel apparently worked out better, though.

you should be able to convert them on your side

You are able to convert c2 projects to work with many wrappers, but it's a bit of a pain. Many users have done so in the past. Construct's exporters just abstract away the conversion process.

we are adding yet another third party over that,

I absolutely get (and agree with) what you're saying, but keep in mind the intention is never to leave those wrappers permanently. Ashley is intent on cutting every proprietary or third-party tech possible (jQuery used to be a c2 dependency).

The problem is that, outside the browser, our options suck. The sudden appearance of HTML5 exporters on competitors (MMF, GM, Unity, etc) won't change much, since those competitors have their own native exporters as well, which in turn tends to make HTML5 a second-class citizen.

We all know the solution: make a first-party native exporter. But as Ashley stated multiple times before, that's not going to happen: maintaining multiple codebases is exponentially more difficult, and will slow down development a lot (and fast iterations are one of the major selling points! I don't think there's a single person in the forums unhappy with the pace of development at Scirra). If we had a bigger userbase, a commercial exporter could be viable - the XML format is pretty easy to work with, even if it has its issues - although past actions by Scirra have shown they don't exactly welcome this approach. Keep in mind a native exporter would break all plugins, requiring them to be written in said exporter's language (a garbage requirement IMHO).

Personally, I'd like to see development move in the opposite direction: move the editor itself from C# to HTML5, so we could extend it a bit more easily. The same arguments apply in support of my thinking: less dependency on third parties, less vendor lock-in, multiplatform support, better consistency between edittime and runtime. Note that I'm not talking about a browser-IDE or cloud-editor like Impactjs' Weltmeister, but a full-on desktop javascript-based application such as Brackets.