exactly! why would anyone try to develop a game with a hybrid tool especially when performance is a consideration. you have to right tool for the job and he should have thought it out a bit more.
I came across these quirks too at a prior job while using Cordova as well - I'm largely convinced that these sort of hybrid tools are just not good enough. I haven't used alternatives like React Native, NativeScript, etc. - those sound a lot more fundamentally sound than Cordova/PhoneGap/etc. since they aren't leveraging a WebView to do everything, although I have heard complaints about those as well.
It would be nice if these platforms use just one language, but unfortunately I doubt Apple would ever play nice there. It costs companies a lot more money to maintain separate codebases or resort to subpar solutions...or just go iOS first/only, which is an insidious consequence.
Language doesn't necessarily matter, at this point you can use C or C++ and many other things for iOS.
The system libraries and interface paradigms are completely different. You'll never have a write once run anywhere thing. Games can come the closest since they generally have their own completely custom UI is, but there still bits that need to match each platform.
He developed it in PhoneGap and didn't release the Android version? :(
I've heard a full engine like Unity is a lot better for designing games across mobile platforms. I've heard cross platform mobile development is a pain, but if you're going to do it, use the right too for the job. Don't develop a shopping app in a game engine and don't try to implement a game engine in something meant for a shopping app.
Personally, after playing around with all kinds of game engines and frameworks, I always go back to Unity. It has a lot of warts and issues, but for me it's the most productive way to focus on actually creating games.
Have you tried SpriteKit? I chose SpriteKit with Swift for my first game and like it quite a lot, but I keep wondering if it was a good choice to limit myself to iOS.
What I'm interested in mostly is if I at least got a significant performance gain from chosing SpriteKit over Unity.
I'm not sure about the performance differences, but there was a different reason that kept me away from switching to Unity. I've built a couple games in SpriteKit doing it entirely programmatically in code and realized Unity is not setup to work that way at all. If you have experience using SpriteKit Scene Editor then you might not be bothered by that, but I was. Instead of Unity I'm using MonoGame now since it is meant to build the game using just code and I find it was a lot easier to jump into using my existing knowledge from SpriteKit
> So I added a few more entities to the world. Suddenly, it was running at around 30 FPS. Yikes.
If your framework can't do simple OpenGL draw call batching, it's unsuitable for games. I'm not a huge fan of Unity (though it'll be a lot better when their version of C# is finally updated), but it's probably the best thing available for cross-platform game development.
This is worth repeating; use the right tool for the job. Phone gap is actually pretty great for the scenario where you need a simpler info screen app to be cross platform from day one. I made a personal app that way and it worked out great. The author sort of conflates Phonegap being bad for games for Phonegap being bad for apps in general. I think a lot of smaller companies would be better of going the hybrid route for things like food ordering or boutique shopping, etc. but there is this serious bias against it that I think 9 out of 10 times is more tribal/religious than for actual technical limitations.
> there is this serious bias against it that I think 9 out of 10 times is more tribal/religious than for actual technical limitations
I always feel like it's the opposite. People who haven't tried it themselves will say to use Cordova for everything, but once you start you notice the performance issues right away.
It's frustrating because a lot of freelance jobs I see are asking for Cordova experts, and it's pretty obvious they're going to end up with a shitty app. But, no one is going to tell them that. They'll spend all their money getting a Cordova app made, and then look for a native developer when they realize how bad it is and have no money left.
For background, I was learning JS development, and was really excited about Cordova. I thought Moore's law had finally put web based mobile apps (mostly) on par with native. But it's just not true, and I don't think it will be for a long time. I wish people would be more honest in their documentation about the limitations of things.
Agreed, when I first heard about PhoneGap it sounded amazing, then I tried and the performance hit is just too great, even for simple apps. Maybe in the future it'll be better, but not yet.
This reasoning has been a bust for many years. As hardware specs go up, so doES the native UI become more demanding. Compare iOS 6 to iOS 10, from translucency to animation complexity to text rendering complexity. Now take web technologies and try to emulate the same complexity - it becomes more and more prohibiting. If anything, it gets worse and worse, not better.
>People who haven't tried it themselves will say to use Cordova for everything, but once you start you notice the performance issues right away.
I've developed a half dozen apps in Ionic Framework, and they all operate at a silky smooth 60FPS. I don't end up with performance issues because I'm:
* Using CSS for animations
* Not using JQuery for things you should never use JQuery for in 2016 because they're too slow on mobile
* Not piling on tons of verbose frameworks to accomplish every little thing and therefore slowing down the JavaScript engine as it ends up with multiple megabytes of code
* Limiting asset sizes so we don't overrun mobile memory limits
* Generally optimizing the code so that I'm not wasting time or creating 16 intermediate arrays in every data conversion/manipulation because the functional approach looks so pretty
I understand you were "just learning JS development." It may actually (ironically) take more of an expert to get good performance out of Cordova than it does to produce a decent native app.
But everything I did above should also be standard practice for creating any web pages, since otherwise performance will in fact be crap on mobile. So it's really just web development best practices.
No, it's not that there are limitations in Cordova. It's that writing web pages for mobile is harder than for desktop, but that when you do it right, it makes for a good app experience as well.
Not to mention React Native and NativeScript, which will get you full speed on mobile with native controls.
I'll be a little more detailed. What I tried to do was make a game using Phaser. I didn't get past creating the loading and menu scenes before I starting noticing really bad sluggishness when first loading, etc. If you let it sit for 10 seconds then things mostly smooth out, but you still have the frame rate randomly drop, etc. I had done so little there was nothing to optimize, it was just the barebones to get something on the screen. And I didn't even try it on mobile, this was using my desktop/laptop.
Also, I hadn't heard of Framework7 mentioned in another comment, so I checked it out. The demo apps I tried (http://framework7.io/apps/) have issues on mobile. I just feel like it's unfair to new developers who are going to invest a lot of time before they figure out hybrid apps have issues. I know people want to market/highlight how great their framework is, but it causes us all grief. We should be more upfront about what works well (CRUD apps), and what doesn't (games, animations, custom UI).
I don't know enough about React Native to comment.
In that example they are animating the "left" prop, which won't be hardware accelerated. Using "transform: translateX" will allow the animation to be hardware accelerated.
Run it on mobile. On my Nexus 6 it stays pretty smooth around 10-15k bunnies, sometimes more. I've seen it glitch as thousands of new bunnies are added at once, but in a well-written game you'd create a "bunny pool" and pre-create all of them so that you could add them without as much overhead.
It's actually a bit jerky on Firefox on my "ultra low power" laptop, despite having a recent Intel i7 CPU, but Chrome is smooth up to 10K bunnies. On my gaming computer, heh, I can go over 100K bunnies without it dropping below 60FPS. That's a lot of sprites, period.
At some point I'll probably port my game from Phaser to PIXI. Like I said, I'm stuck using a browser for at least part of my game. If I were creating a 2d game that didn't require a browser, I'd probably use something else: Unity, maybe, or I'd look around at the other 2d and 3d engines out there to see what's available. I also have an existing 2d engine that I might bring up to date.
In your sample on w3schools, I ran some profiling, and it's firing off dozens of JavaScript callbacks per second, doing who-knows-what. Analyics, probably? Also, as mikewhy pointed out in a sibling comment, transform:translateX() gives you hardware acceleration. Otherwise it has to rebuild the DOM on Every Single Frame. I pulled the code to a local server without the w3schools extra cruft and it was much better, but still not perfect. Converting to using tranform:translateX() made it silky smooth.
The problem is that JS perf is so much worse on Android, and adding insult to injury, the single threaded perf of the very fastest Android devices are less than half an iPhone 7. Worse still, Apple devices get upgraded aggressively, whereas Android devices don't, so the long tail of very old very slow devices (mobile devices age in dog years) is enormous. Sad but true.
For me, with the only PhoneGap app I've worked on, there were required extensive bridge code to Native APIs, anyway. So adding in the webview components just meant having a mess of different languages/frameworks in the codebase where I don't think it would've required very much native code anyway.
Is there a good meta-compiler solution targeting native APIs across mobile platforms that people are using lately?
> Is there a good meta-compiler solution targeting native APIs across mobile platforms that people are using lately?
I guess I just don't see why everyone is so dead set on trying to find a way to not make native applications. No matter how long this goes on, no matter how much more advanced these library seem to get, native apps always feel and work better.
I understand you don't want to do a complete rewrite for each platform, but I'm not sure that trade-off is worth it for the quality of apps you tend to get out of these middleware solutions.
Well, personally I'm not dead set on non-native code, just thinking of ways to make something "cross platform" this is close enough to native code to make other team members comfortable. Personally, I'm the type to just write native code first as I believe it skips lots of the quirky situations as mentioned in the post. So I completely agree.
I just don't think many people realize just how many people are actually sensitive to issues of non-native apps, they just couldn't name or put their finger on what the problem was.
Frankly I'm about to give up on Google because of their AMP pages and how terrible they work on an iPhone. It's to the point where I can't use half the search results. All because they decided to make it act non-native and implement their own special behavior in I-frames on their website.
I have tried to grasp PhoneGap/Cordova many times and the thing just doesn't make sense to me. Seeking a pet project to try React Native whose concept seems saner.
If it helps anyone: if using Cordova/Phonegap on Android devices, include the Crosswalk Webview, especially if you plan on supporting anything below Android 4.4. Either as a dependency or static - the former keeps your app slim (but unfortunately yet another dependency you cannot fully control), the latter adds 44MB to your apk-size but offers you full control over the experience.
Has anyone tried Xamarin for building mobile apps? Not Xamarin Forms but the lower level tool kit? It sounds pretty good on paper. At work the only negative I heard from one team who tried it is it added too much bloat. But that might just be their coding...
MonoGame is rough code with a rough build system and a lot of strange behavior. Frequently undocumented, too. I would suggest investigating FNA (a significant fork of MonoGame used in 40+ shipped titles) instead; I have had my tangles with its primary developer but the code quality is significantly improved and it's really worth your time. Doesn't support the PS4, but you can code to the XNA baseline and then hack around MonoGame for the PS4 later.
I've tried PhoneGap and Cordova wih Polymer and my biggest gripe is that even the most basic of mobile UI gestures have no good analogue. For example to emulate swiping between tabs on a ViewPager, you have to implement hundreds of dirty lines of code in JavaScript to catch touch events and decide how they should behave, and hope you emulate the native experience. None of the tabbed interfaces of any of these frameworks have it built-in.
Then you inevitably have to deal with Safari's stupid rubber-band scrolling, which causes the titlebar of your app to scroll if dragged. Then when you disable that scrolling you're forced to implement your own scrollbar from scratch and emulate the Safari rubber band on the parts you actually want to scroll.
Pull-to-refresh? Good luck implementing it in a way that feels like a native app.
Building all that in JavaScript is possible, and with the help of CSS3 and WebGL it's often possible to get FPS on par with native apps, but emulating a native-feel UI in JavaScript is more work than just developing twice for Android and iOS. And you usually end up with so much JavaScript bloat and DOM hell that it takes forever to load on 3G or slower connections.
Seriously, can someone just give us <GridViewPager>..</GridViewPager>, <ViewPager>..</ViewPager>, <ListView>..</ListView> or something like that, with everything included, including touch gestures, and make it "feel" exactly like iOS or Android depending on the OS it is loaded on, matching the respective fonts, elasticity coefficients, gesture thresholds, and everything else, no questions asked?
Agreed, they've done a really great job and pushed it to the limits. Unfortunately they do not have support for even simple gestures, so the parent comment still applies -- afaict it's not possible with WebViews currently.
JavaScript lets you listen for multi touch events just fine with touch starts, ends, and moves, and lets you keep track of each finger separately. What gestures would it not be possible to implement with that?
The browser has a bunch of behaviors that get in the way. The Ionic team could speak better to what is preventing them from implementing these gestures, or you could browse their issues to get an idea too: https://github.com/driftyco/ionic/issues?utf8=%E2%9C%93&q=ge...
10 open, 40 closed issues related to gestures in v2. It has not yet reached release stage, but already good enough to start the development of the new apps.
Do they have a ViewPager? A DrawerLayout? Swipable rows in lists (eg: to delete an item)?
Also v2 is not the best thing to point to because it's very new and I don't think many people are using it compared with v1. And closed issues don't necessarily mean fixed, eg: https://github.com/driftyco/ionic/issues/9052 -- I believe all WebView based apps suffer from the problem described in this issue.
You're never going to get smooth scrolling if you need to hit the UI thread for every touch event. The platform UI frameworks use background threads for scrolling, directly in the OS compositor.
Thanks. I assumed iOS was like Windows. Although Windows also has scroller controls that you create on the UI thread but delegate the actual event handling to the compositor.
A compositor can only do scrolling if the app is written with a retained mode API. The low-level APIs in Windows are immediate mode, whether GDI or Direct2D.
For most of time, ScrollWindow / ScrollWindowEx was how you scrolled. It doesn't know what to draw in the invalidated region because it's an immediate mode API.
In Direct2D you can use e.g. a translation to get the renderer to draw a bigger bitmap in a different section of the window, but you need to render the bigger bitmap (i.e. assemble your own retained mode). There's no free lunch.
This is not strictly correct. CoreAnimation does it's work in a background thread, so the mechanical work of scrolling pixels is not done on the UI thread unless you are doing custom drawing. Under the covers its a texture so the scrolling is really just translation.
If you want to be pedantic, this isn't quite right either. CoreAnimation does some work on the main thread to encode layer properties and send them to the render server, which is in another process, not another thread.
The important part isn't the amount of work it takes to render, it's that event handling is serialized with all the other stuff happening on the main thread.
I'm currently using NativeScript and react-native for app development and I have to comment because items like <ListView> [1] and Grid-Layouts [2] can be done using both technologies which use native rendering and achieve 60 FPS.
They both have listeners for common UI gestures. If you're building a normal app (no video game) with some forms, list views and maybe some diagrams, just use those. They give you a native experience and you don't have to build it for each platform - we're currently not in the state of "write once, run everywhere", but we're close.
It's really easy to get started, please read about those if you're not satisfied with the current level of Cordova and Web apps.
I used Framework7 for a PWA (Progressive Web App) and it has a very lean learning curve if you already know web stuff and it was very easy to integrate e.g. Chartjs, so if you don't like react or NativeScript's XML you can also use HTML and plain Javascript, although the iOS 10 change is a bit troubling. I don't have any problems like a scrolling titlebar with it. Try and see if it fits your use case.
This app has nude images but I solved the "stupid rubber-band scrolling problem" be setting the <html> and <body> tags to fixed position.[1] I just wanted to share an example of this working in the wild and I only discovered it last week. I'm using Angular Material Design with a <md-content> tag which has overflow: auto and position: relative. This creates a scrolling bar inside of the fixed position body. It also creates some pretty weird side effects because HTMLElement.offsetTop remains static so none of the smooth scrolling JavaScript libraries work, so I had to role my own with a scrollToTop method.[2] I think it is because HTMLElement.offsetTop is computed relative to the parent which is fixed.
When it comes to scrolling two images they are jigging because the browser is handling the repainting instead of passing it off to the graphics card or chip. The only way to have smooth scrolling is to use translateX or translateY.
(Note: I don't know what I'm talking about and honest I just don't care.)
I'd you're doing games, you might try experimenting with Haxe - it compiles down to native, and doesn't does use web views. As a plus, you can generate versions for other targets (Windows, html, Linux, etc.)
Kha ( http://kha.tech/ ) is close enough to metal and can be compiled to almost every mainstream platform (iOS, Android, HTML5, Windows, macOS, Linux, Flash and even Unity) .
I felt the same kind of hesitation getting into Swift and C#. But last summer I finally set a 6 hr/wk schedule to learn the meat and potatoes of 2D game development using both, just to better understand what's out there.
I learned a lot. But the most interesting lesson was that learning new tools was easier than I expected it to be. XCode and Unity, along with a lot of great tutorials and example code made it fairly painless. The hardest part was pushing past the expectation that learning a new language would be time consuming and difficult.
The most useful lesson I learned was to embrace new tools sooner. I think there's a natural gravitation towards using a language/tool because that's what you know. Of course we don't all have the luxury of the same amount of free time to learn new things, but I think you'd really surprise yourself, like I have, at just how much you can learn.
> The most useful lesson I learned was to embrace new tools sooner.
Is that really your take-away? If anything, your story reads like one can safely hold out on learning new tools, given how quickly and easily one becomes productive with them.
Of course, that reasoning does not apply to things outside your comfort zone. If game development was new to you, then I won't argue that the time spent learning was not well-spent.
I was a huge gamer but I've never made a game before. Not that I made anything too special. I made a breakout clone on swift and a 2d space shooter roguelike in unity.
I more meant, instead of using the tools you know, don't be afraid to invest sooner in the tools that are right for the job.
This seems less like an indictment of PhoneGap, it's more of a warning not to build games in JavaScript.
Had the author used an appropriate tool for making games--a game framework like Unity--they wouldn't have run into all of these performance problems and it would've still been cross platform. Hell, Unity even has a JavaScript-esque scripting language if you're so set on learning only one language (although it's vastly inferior to C#)
As far as I know, Crossy Road is built with Unity and it often skips many frames on my iPhone 5s. I'm not sure how Unity works, but it also felt like garbage collection - a single, long hang every few minutes of playing the game.
(Maybe things have improved, this was when the game was pretty new.)
Never experienced frame lag with Crossy Roads, and I played it a bit. Something like this _can_ happen with Unity, but if it happens it's 99,99% bad programming, and not the engine's fault, unless you do graphically extensive things, which Crossy Roads certainly didn't.
Use the right tool for the right task. Using the wrong tool for the task does not mean that there is something wrong with the tool.
You want to develop graphic intensive games using a single code base without learning native iOS or Android app development? You could probably do that with open source platforms like Gideros (there are good commercial alternatives too). Since iOS can't run LuaJIT, in particularly resource hungry games you might have no option but to code in native.
A few years ago I developed a game for both Android and iOS using Cordova and was very happy with the results. It was a Scrabble clone against the CPU with nice animations and no one could tell it was not native. I knew it was way below what the web view could handle so I wasn't surprised it succeeded. I'd have never tried it in the first place with a 3D game or a game with many entities and hope to get 50fps.
I also use Cordova to get native looking apps (not games) by using Framework7 (http://framework7.io) - I'd like to see how many users would really notice the difference (I'd guess about the same amount of people who would complain about mp3's not giving a good enough quality for the music they listen to)
I do agree that Cordova apps will probably continue be treated like second class citizens (and perhaps worse) mainly because I assume it runs mostly against the interests of Apple and also Google who would prefer you invested your time getting locked in to their specific platform...
Frankly, because I didn't want to learn Angular when I first encountered Ionic. Ionic might be great though, it's just that I have no experience with it yet to say one way the other.
I had similar concern, but after trying F7 switched to Ionic 2 and learned Angular 2: F7 architecture isn't flexible enough and it's not production ready overall.
It only takes one look at the transparent navigation bar or popup or non-spring transition animation to notice something is "off". Further looking, things like inconsistent margins across devices, non-standard controls, etc. give it away on a fundamental level. This kind of disrespect for your users' ability to notice crap is what I dislike most about lazy cross-platfom developers. At least have the decency to admit your are churning a technologically and experience-wise sub-par product for this and that reason, but that almost never happens. It's always the "no one notices this" nonsense.
Disrespecting your users has very little to do with the tool you use and everything to do with how you use it. One can also be pedantic/fanatic about going by the book to the letter in order to conform with every one of the platform UI's "laws" and still generate a crappy application due to lack of insight on what will be intuitive or useful to the end user. No - a sub-par product will mostly have a sub-par developer responsible. Quality and craftsmanship will come across no matter what technology you decide to use. That's not to say that a good developer couldn't produce an even more polished experience with native programming, but as mentioned before, I doubt the difference is noticeable enough for many applications to justify the dramatic increase in learning curve and maintenance.
Can anyone say what the easiest development platform is to use to write a 2D game that uses code instead of a GUI, has tutorials that don't expect that you know the language/API/environment that well, and is free to use?
I've looked at several, but either I can't develop for iOS/Android for free (beyond the charges to get setup as a developer by required by Apple, Google, etc.) or the barrier to entry always kills my time, then I go onto something else. LÖVE https://love2d.org/ was the only one I actually got anything playable with, but Lua/LÖVE was a little finicky and got frustrating. I want to be up and running and deploying to an emulator with something interesting in no more than 30 minutes, and I don't care how blocky it looks.
Years ago I wrote homebrew games, so I'm not new to concepts required, but I don't want anything too complex.
> the iOS 10 beta introduced some new behavior where WebKit ignores the user-scalable viewport meta property. This "feature" is supposed to be for accessibility reasons; anyone should be able to pinch to zoom any web page. That's fine and all, but this would completely and totally break most webview-based apps.
This. I don't read a lot of outcry over this for unknown reasons. It baffles me. Apple essentially broke all web based apps and not many people seem to care.
They never saw it as the future. Jobs just didn't want to give up control and they didn't want to release the real API too early as it was probably in serious flux.
I'm sure if web apps worked Jobs would hav been happy to leave it there. He was against iTunes on Windows, the move that made the iPod what it was.
It was in a flux. Dig back to look at the then remove brine headers to see the mess that the API was. It improved significantly for the official / iphoneos 2.0 release.
That's because users are actually happy with the fact that they can now read websites with readable text size instead of being locked into whatever the 20/20 eyesight designer thought they should read.
It was a huge problem and this made life easier for a lot of users, significantly more than there are webapp users affected by this out there.
I think this is something where webpages people open in safari and web-technology based apps people install as a little icon on their phone should probably be treated differently. I have run into unintended zooming as an app usability disaster as well.
Why isn't it nasty that you can't pinch to zoom in all apps? What makes web sites which declare they have been laid out for a small screen just like an app different?
Part of the answer is that the App Store review process checks for sufficient text size. Web pages aren't subject to this process, and so are more likely to have overly small text. Certainly that's been my experience as a user.
I'm with millstone. I've never had that issue with an actual app.
Maybe that's because of app review, maybe it's the system defaults, it just isn't an issue.
I don't think I ever had an issue with a webpage that seemed purposful. It always seemed to be something they were trying to do for the desktop (perhaps not a great idea there) that was a disaster on mobile. Or maybe they tested on an iPad and when the screen is 4" instead of 10" it's unusable.
Heh, I've had the opposite experience. Generally sites that completely ignore mobile are manageable on the phone, maybe I have to scroll around a bit but its not a big deal. Mobile specific sites however seem to "break" (or at least annoy me) spectacularly and frequently.
If I press the menu and your menu takes over the entire screen, seemingly like a new page, the back button should close the menu, not navigate off your site, especially if there's no way to close the menu other than navigating to a link. Floating elements that take up 20% of an already small screen with absolutely nothing useful on them and no way to get rid of them are broken. Redirecting a non-mobile link to the home page of your mobile site instead of to the content the link actually points to is pretty common too.
In general I HATE mobile sites because they're usually less useful than the real desktop site or break things like reader mode. I'm especially FOND of sites that try to implement their own gestures thus messing up scrolling or the system gestures. That means YOU imgur.
But I've never seen an app present me with the equivalent of 3pt text by default.
Blogger is the worst example. I'm basically unable to scroll an article without it interpreting it as a swipe, sending me to a different page, and losing my progress.
Because it's an expected feature of the web that has been in every browser since at least IE 3. If anything it is nasty that you can't pinch and zoom in apps, because there's no really good reason not to have it.
That said I prefer my text smaller, have my phone at the smallest font size and rarely zoom in on text. I also wish there was a "remove the pointless whitespace" option and that other ui elements got smaller along with the text, but I'm rambling.
It's great if there is text to read. It sucks if you built an HTML5 gesture-based game and pinching just zooms you into the middle of a <canvas> showing already-blown-up pixel art.
I agree this was a necessary step, and understand apple's justified aversion to adding more options/switches for their users, but maybe the website could pop up something that asked the users for permission to make the viewport unresizable?
Why outcry? I wasn't aware of the change, but if I had been, I'd have applauded Apple. Blocking zoom on web pages was super annoying, and I'm not sure why it was allowed in the first place.
I love news sites that think a tiny window with a couple of video bobble heads commenting on something they're clueless about is content absolutely everyone must see. Whether they want to or not.
This functionality change affects web apps running within Safari. If you care about accessibility on the web, you're likely to view this as a feature rather than a bug.
If you're building a "native" app that happens to uses web views as an implementation detail, as in this article, Apple explicitly exposes a property in the WKWebView API to revert to the former behavior. See: https://developer.apple.com/reference/webkit/wkwebview/14149...
If you're just breaking into a new topic (such as game development), I find it very understandable to not want to learn a new language at the same time.
JavaScript, well, too bad it's JavaScript, but look at what you can do with it: build servers, webapps, mobile apps for Android and iOS, and desktop apps with Electron and others. Does any other language compete in this way? And then, it doesn't seem like a great choice for machine learning but, as you know, you can use it there as well...
Obviously webapps are a thing apart because browsers only support JS. But otherwise...
C++.
.Net-based languages.
JVM-based languages. (although I am not aware of any tool that works on iOS)
Hell, in most of the platforms you can use your language of choice and P/Invoke C++ components.
I once made an app with Phonegap. The performance was terrible despite months of optimisation and even a review from Big Nerd Ranch. The new Swift and Java implementations are much MUCH nicer for users - the Swift version is really responsive.
4 years ago might as well be a lifetime in Cordova/PhoneGap land. Things have changed quite dramatically, even the web APIs available alone have evolved quite a bit. We launched ionic beginning of 2014 and it wouldn't have been possible before as the browser runtime just wasn't ready.
Also everyone had to build UI from scratch before Ionic and other frameworks, and that was just crazy.
I tried to get back into PhoneGap after a two year absence. This was after the PhoneGap/Cordova split and it seemed to me like the entire ecosystem was in smoldering ruins.
Figuring out if you need to use either the PhoneGap or the Cordova binaries, and then finding correct documentation for the respective forks, was in itself a big hassle. But no more than trying to get the toolchain up and running. Holy backflipping cow was that a nightmare. I have managed to repress the details but it was something with installing NPM and then typing in magic commands and hoping some byzantine series of effects would occur correctly, which they never did.
I somehow managed to hack and slash the platform into a working configuration, only to discover that performance (for games) was still far from adequate. I'm sure it has its (non-game) uses, but the developer experience was probably the worst I have ever experienced.
If you care about 60fps performance on a single platform, then yes, Cordova isn't for you.
If your app doesn't need extreme performance, and you don't have the time to learn and develop for multiple platforms, and things like unity/kivy etc don't give you enough UI, then Cordova is suddenly much more attractive.
I think 60fps is not "extreme performance" but rather expected performance for a mobile app. Only one part of this article was about performance, anyhow.
Good spot, but that's just the video. Unfortunately most screen recorder software (at least free screen recorder software) for Android is very low frame rate.
As others have pointed out, your mistake was trying to develop a graphics-heavy game with the wrong toolset. I'm one of the devs that works on the Android and iOS apps for lichess.org and we've had a lot of success with Cordova/PhoneGap. It's allowed us to do all our development once with occassional workarounds needed for platform specific issues.
I build my current game with Cordova, and really the only major breakage i ran into with updates was iOS 9 audio changes. Patched howler, and it worked fine after that.
I realize this is anecdotal, it would be interesting to see his/her game, what was so demanding to cause performance problems. Many platforms have their quirks and SDKs that you need to learn.
I've had a lot more breaking changes with my React Native app. Opened the other day, and text boxes were overflowing their container. Didn't happen before. React Native is younger, so I find it's to be expected.
Native apps has many upsides, but also downsides. The same goes for Phonegap/Cordova. In general I'd say that games and performance-sensitive apps aren't the strength of Cordova.
But having used Cordova for several years I'd say that overall it's an excellent framework that can power large, complex apps.
I'd also wish Apple would give the web-views some more love, but overall they work really well for many things.
> Background activity such as push notifications can slow everything down for a few seconds
This is sometimes the case with native games too. I can sometimes get a few hundred millisecond warning when a text is incoming because of a sudden uptick in lag, even on an iPhone 7.
This sounds like the same old rule that has existed for the last 30 years or more. If you want to build an app that uses graphically intensive animations, build as close to the metal as possible and do not rely on layers provided by the OS.
I learned nothing from this because if I was going to build a game like he described, I would suck
it in and get down to the platform's assembly language layer which for IOS is ObjectiveC and for Android is Java.
It would be far more interesting to read a review that explores the boundary of what works well in PhoneGap and what doesn't. Clearly lots of successful apps are built in PhonegGap/Cordova. We could have the same conversations about desktop apps or server apps. Too many layers make things easier to build but impose a performance penalty. It is wise to think before you build and do some architecture and engineering before coding. Writing code is NOT engineering.
I personally would recommend developing games in C++ for both platforms. You're not going to be heavily using any of the APIs that necessitate using Obj-C or Java. It's just OpenGL ES and other low level APIs. Additionally, it's easy to port between iOS and Android and you can use a much wider variety of libraries.
Yup, you can do things that'll start getting close to the metal with Java(arrays to keep caches warm, avoid allocations). However at the end of the day it's a huge pain and you lose the portability you get with C++.
I always recommend Unity3D because the devs that would be comfortable starting in C++ with "raw" OpenGL already know their options and generally aren't looking for recommendations.
Usually when someone asks me "What should I use to make a cross-platform game", what they're really asking is "What tool can I use that won't get in the way of me making my game, that additionally allows me to target multiple platforms"
> Cross platform mobile games when you have C++ skills: Use C++ with OpenGL and share most of the code.
I would recommend MOAI - gives you the best bang for the buck, as long as you're willing to learn Lua to do all the app-layer stuff, and leave the MOAI engine to manage the performance-critical resources...
Of course the little detail here is that 50 tiny sprites apparently counts as graphically intensive.
Why do web developers constantly make the argument that Javascript is not slower than C (or Swift, or C++, or any native programming language) ? The difference is night and day, 5000% and up for simple things like drawing.
> The difference is night and day, 5000% and up for simple things like drawing.
I find that seriously doubtful, you're going to have to provide a citation if you want me to swallow that.
The relevant comparison is a single JavaScript function in Firefox looping through a static array and making WebGL calls vs. a C++ function looping through the same array and making OpenGL calls.
If the difference is 5000% or more I will donate $20 to the charity of your choice.
> The relevant comparison is a single JavaScript function in Firefox looping through a static array and making WebGL calls vs. a C++ function looping through the same array and making OpenGL calls.
...that's not how graphics benchmarking works. That would be like benchmarking a language by seeing how fast it can add up integers.
It would seem more to the point for me to compare something like a game downloaded from steam with a webpage, as that is directly comparing the user experience.
If you artificially limit the scope to something trivial, anything can work. I mean, that might be interesting for web browser developers, sure, and by all means, use it for that. But what matters is what experiences can be created by it.
WebGL has really high draw call overhead compared to native OpenGL. The rough rule of thumb is that you can do 2000% [0] the draw calls in a native app per frame than you can do in WebGL. It's not about execution performance it's about overhead of leaving JS and converting data to the format the GPU needs.
C is always going to be faster than almost anything you compare it to, of course. But the V8 interpreter is also not 5000% slower; for computationally intensive tasks it's not actually significantly slower. The problem in OP's case is that JS lacks an interface to interact with the display and render that is as "close to the metal" as their "native" counter parts. You are drawing sprites on a html canvas which is then rendered by a web view, which just not that great no matter what language you use to get there.
What I'm getting at is that it's easy to blame Javascript, but really that's not the whole picture, and if Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues.
> Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues
What would "supporting Javascript natively" mean? If you mean AOT, classic AOT (without some pretty fancy research-level PGO or something) is not a viable compilation strategy for JS.
I do agree heavily with your overall point that the JS blame is misplaced. People often forget that JS is faster than Objective-C at important things like method calls for systematic reasons.
By supporting natively I mean provide a layer of APIs that let developers interact with the phone and in particular with the display at a low level, while still writing JS; I imagine that if you could draw on the screen bypassing canvases and html views entirely it would solve most issues.
> Why do web developers constantly make the argument that Javascript is not slower than C (or Swift, or C++, or any native programming language) ? The difference is night and day, 5000% and up for simple things like drawing.
Probably because that's completely untrue, and would be irrelevant even if it were true.
If you're doing "drawing" (which in this case means blitting) on the CPU to begin with, you've already lost.
But this is beside the point. Firstly, I've been doing demos for years, so
1) it is possible, even at high resolutions
2) anything worth doing in opengl can't work in javascript for other reasons (mostly data size). And yes, you could download hundreds of megabytes worth of data files just to show an intro screen and then a few gigabytes for a game over an internet connection. I hope you have patient customers and a huge webhosting budget.
So let's be honest here : for small games, the effort of doing it with OpenGL/WebGL is not worth it. For large games it cannot be done, but for other reasons (that actually also apply to small games: 50 megabytes is incredibly oversized for a webpage, but still rather small for a game, so these problems actually overlap)
I myself feel guilty for stating this, but it actually works better to render the entire game server-side and videostream it to the client. Yes, javascript (and the web ecosystem) is that bad.
Is there no use for it ? Well, I appreciate the speed at which I can try out shaders locally. None of the niceties of javascript such as debugging or any sort of development process work, but it's still nice that you can get up & running in an hour or so.
But any reasonable game on javascript or the web platform ? Doesn't work and at this point it's so far from working it's a bad joke.
Most high end games are developed in C++ for both iOS and Android with Java and Objective-C wrappers for things such as IAP's and Game Kit/Play Games integration.
> I would suck it in and get down to the platform's assembly language layer which for IOS is ObjectiveC and for Android is Java.
That only makes sense if the graphnics performance is actually the bottleneck of your game.
99% of the games I've seen have game design as the weakest link though, and sometimes art (it's not amount of polygons on the screen — it's how beautiful those polygons are). And if you actually want to improve on your game design, the metric you have to optimize is iteration speed — and the "assembly language layer" is rarely the best for this purpose.
Your comment sounds very confused. Obj-C and Java are not "assembly language", and nobody writes games for iOS that don't use any sort of OS-level functionality. That's completely ridiculous. Especially because iOS provides multiple different APIs for high-performance graphics, such as Metal/OpenGL for 3D rendering and SpriteKit for 2D rendering.
Really the advice should just be don't use JavaScript and web technologies for mobile gaming.
247 comments
[ 3.0 ms ] story [ 283 ms ] threadThat'a a bit of a broad brush stroke, suggesting that you only build games or you think issues you ran into would apply to all app types.
> Not having to learn a new language was great, but it wasn't worth the performance hit and quirks I encountered along the way.
Couldn't you gain many of the same advantages using NativeScript or React Native? (though I think those would still be bad choices for a game)
It would be nice if these platforms use just one language, but unfortunately I doubt Apple would ever play nice there. It costs companies a lot more money to maintain separate codebases or resort to subpar solutions...or just go iOS first/only, which is an insidious consequence.
The system libraries and interface paradigms are completely different. You'll never have a write once run anywhere thing. Games can come the closest since they generally have their own completely custom UI is, but there still bits that need to match each platform.
I've heard a full engine like Unity is a lot better for designing games across mobile platforms. I've heard cross platform mobile development is a pain, but if you're going to do it, use the right too for the job. Don't develop a shopping app in a game engine and don't try to implement a game engine in something meant for a shopping app.
What I'm interested in mostly is if I at least got a significant performance gain from chosing SpriteKit over Unity.
> So I added a few more entities to the world. Suddenly, it was running at around 30 FPS. Yikes.
If your framework can't do simple OpenGL draw call batching, it's unsuitable for games. I'm not a huge fan of Unity (though it'll be a lot better when their version of C# is finally updated), but it's probably the best thing available for cross-platform game development.
I always feel like it's the opposite. People who haven't tried it themselves will say to use Cordova for everything, but once you start you notice the performance issues right away.
It's frustrating because a lot of freelance jobs I see are asking for Cordova experts, and it's pretty obvious they're going to end up with a shitty app. But, no one is going to tell them that. They'll spend all their money getting a Cordova app made, and then look for a native developer when they realize how bad it is and have no money left.
For background, I was learning JS development, and was really excited about Cordova. I thought Moore's law had finally put web based mobile apps (mostly) on par with native. But it's just not true, and I don't think it will be for a long time. I wish people would be more honest in their documentation about the limitations of things.
I've developed a half dozen apps in Ionic Framework, and they all operate at a silky smooth 60FPS. I don't end up with performance issues because I'm:
* Using CSS for animations
* Not using JQuery for things you should never use JQuery for in 2016 because they're too slow on mobile
* Not piling on tons of verbose frameworks to accomplish every little thing and therefore slowing down the JavaScript engine as it ends up with multiple megabytes of code
* Limiting asset sizes so we don't overrun mobile memory limits
* Generally optimizing the code so that I'm not wasting time or creating 16 intermediate arrays in every data conversion/manipulation because the functional approach looks so pretty
I understand you were "just learning JS development." It may actually (ironically) take more of an expert to get good performance out of Cordova than it does to produce a decent native app.
But everything I did above should also be standard practice for creating any web pages, since otherwise performance will in fact be crap on mobile. So it's really just web development best practices.
No, it's not that there are limitations in Cordova. It's that writing web pages for mobile is harder than for desktop, but that when you do it right, it makes for a good app experience as well.
Not to mention React Native and NativeScript, which will get you full speed on mobile with native controls.
I see the same thing with CSS3 animations. There's this weird jerking, even on something simple like this: http://www.w3schools.com/css/tryit.asp?filename=trycss3_anim... . When I enable the FPS meter I see drops to 30FPS.
Also, I hadn't heard of Framework7 mentioned in another comment, so I checked it out. The demo apps I tried (http://framework7.io/apps/) have issues on mobile. I just feel like it's unfair to new developers who are going to invest a lot of time before they figure out hybrid apps have issues. I know people want to market/highlight how great their framework is, but it causes us all grief. We should be more upfront about what works well (CRUD apps), and what doesn't (games, animations, custom UI).
I don't know enough about React Native to comment.
See: http://www.goodboydigital.com/pixijs/bunnymark/ -- click or touch to spawn bunnies.
Run it on mobile. On my Nexus 6 it stays pretty smooth around 10-15k bunnies, sometimes more. I've seen it glitch as thousands of new bunnies are added at once, but in a well-written game you'd create a "bunny pool" and pre-create all of them so that you could add them without as much overhead.
It's actually a bit jerky on Firefox on my "ultra low power" laptop, despite having a recent Intel i7 CPU, but Chrome is smooth up to 10K bunnies. On my gaming computer, heh, I can go over 100K bunnies without it dropping below 60FPS. That's a lot of sprites, period.
At some point I'll probably port my game from Phaser to PIXI. Like I said, I'm stuck using a browser for at least part of my game. If I were creating a 2d game that didn't require a browser, I'd probably use something else: Unity, maybe, or I'd look around at the other 2d and 3d engines out there to see what's available. I also have an existing 2d engine that I might bring up to date.
In your sample on w3schools, I ran some profiling, and it's firing off dozens of JavaScript callbacks per second, doing who-knows-what. Analyics, probably? Also, as mikewhy pointed out in a sibling comment, transform:translateX() gives you hardware acceleration. Otherwise it has to rebuild the DOM on Every Single Frame. I pulled the code to a local server without the w3schools extra cruft and it was much better, but still not perfect. Converting to using tranform:translateX() made it silky smooth.
In any case, good luck.
Is there a good meta-compiler solution targeting native APIs across mobile platforms that people are using lately?
I guess I just don't see why everyone is so dead set on trying to find a way to not make native applications. No matter how long this goes on, no matter how much more advanced these library seem to get, native apps always feel and work better.
I understand you don't want to do a complete rewrite for each platform, but I'm not sure that trade-off is worth it for the quality of apps you tend to get out of these middleware solutions.
(Games are something of an exception)
Frankly I'm about to give up on Google because of their AMP pages and how terrible they work on an iPhone. It's to the point where I can't use half the search results. All because they decided to make it act non-native and implement their own special behavior in I-frames on their website.
Then you inevitably have to deal with Safari's stupid rubber-band scrolling, which causes the titlebar of your app to scroll if dragged. Then when you disable that scrolling you're forced to implement your own scrollbar from scratch and emulate the Safari rubber band on the parts you actually want to scroll.
Pull-to-refresh? Good luck implementing it in a way that feels like a native app.
Building all that in JavaScript is possible, and with the help of CSS3 and WebGL it's often possible to get FPS on par with native apps, but emulating a native-feel UI in JavaScript is more work than just developing twice for Android and iOS. And you usually end up with so much JavaScript bloat and DOM hell that it takes forever to load on 3G or slower connections.
Seriously, can someone just give us <GridViewPager>..</GridViewPager>, <ViewPager>..</ViewPager>, <ListView>..</ListView> or something like that, with everything included, including touch gestures, and make it "feel" exactly like iOS or Android depending on the OS it is loaded on, matching the respective fonts, elasticity coefficients, gesture thresholds, and everything else, no questions asked?
10 open, 40 closed issues related to gestures in v2. It has not yet reached release stage, but already good enough to start the development of the new apps.
Also v2 is not the best thing to point to because it's very new and I don't think many people are using it compared with v1. And closed issues don't necessarily mean fixed, eg: https://github.com/driftyco/ionic/issues/9052 -- I believe all WebView based apps suffer from the problem described in this issue.
Every new technology is used initially by less people than something older. It does not say anything about it.
Regarding the issue you've mentioned, I think it can be fixed by HTML/CSS means.
For most of time, ScrollWindow / ScrollWindowEx was how you scrolled. It doesn't know what to draw in the invalidated region because it's an immediate mode API.
In Direct2D you can use e.g. a translation to get the renderer to draw a bigger bitmap in a different section of the window, but you need to render the bigger bitmap (i.e. assemble your own retained mode). There's no free lunch.
The important part isn't the amount of work it takes to render, it's that event handling is serialized with all the other stuff happening on the main thread.
I used Framework7 for a PWA (Progressive Web App) and it has a very lean learning curve if you already know web stuff and it was very easy to integrate e.g. Chartjs, so if you don't like react or NativeScript's XML you can also use HTML and plain Javascript, although the iOS 10 change is a bit troubling. I don't have any problems like a scrolling titlebar with it. Try and see if it fits your use case.
[1]: https://facebook.github.io/react-native/docs/listview.html [2]: https://docs.nativescript.org/cookbook/ui/layouts/grid-layou...
When it comes to scrolling two images they are jigging because the browser is handling the repainting instead of passing it off to the graphics card or chip. The only way to have smooth scrolling is to use translateX or translateY.
(Note: I don't know what I'm talking about and honest I just don't care.)
[1] https://github.com/adam-s/playboy-fm/blob/master/client/sass...
[2] https://github.com/adam-s/playboy-fm/blob/master/client/publ...
https://framework7.io
I learned a lot. But the most interesting lesson was that learning new tools was easier than I expected it to be. XCode and Unity, along with a lot of great tutorials and example code made it fairly painless. The hardest part was pushing past the expectation that learning a new language would be time consuming and difficult.
The most useful lesson I learned was to embrace new tools sooner. I think there's a natural gravitation towards using a language/tool because that's what you know. Of course we don't all have the luxury of the same amount of free time to learn new things, but I think you'd really surprise yourself, like I have, at just how much you can learn.
Is that really your take-away? If anything, your story reads like one can safely hold out on learning new tools, given how quickly and easily one becomes productive with them.
Of course, that reasoning does not apply to things outside your comfort zone. If game development was new to you, then I won't argue that the time spent learning was not well-spent.
I more meant, instead of using the tools you know, don't be afraid to invest sooner in the tools that are right for the job.
Had the author used an appropriate tool for making games--a game framework like Unity--they wouldn't have run into all of these performance problems and it would've still been cross platform. Hell, Unity even has a JavaScript-esque scripting language if you're so set on learning only one language (although it's vastly inferior to C#)
(Maybe things have improved, this was when the game was pretty new.)
You want to develop graphic intensive games using a single code base without learning native iOS or Android app development? You could probably do that with open source platforms like Gideros (there are good commercial alternatives too). Since iOS can't run LuaJIT, in particularly resource hungry games you might have no option but to code in native.
A few years ago I developed a game for both Android and iOS using Cordova and was very happy with the results. It was a Scrabble clone against the CPU with nice animations and no one could tell it was not native. I knew it was way below what the web view could handle so I wasn't surprised it succeeded. I'd have never tried it in the first place with a 3D game or a game with many entities and hope to get 50fps.
I also use Cordova to get native looking apps (not games) by using Framework7 (http://framework7.io) - I'd like to see how many users would really notice the difference (I'd guess about the same amount of people who would complain about mp3's not giving a good enough quality for the music they listen to)
I do agree that Cordova apps will probably continue be treated like second class citizens (and perhaps worse) mainly because I assume it runs mostly against the interests of Apple and also Google who would prefer you invested your time getting locked in to their specific platform...
Most non-dev users want to get some stuff done via apps and don't care about design details.
A lot fewer people actually care about UI minutia than you imagine.
I've looked at several, but either I can't develop for iOS/Android for free (beyond the charges to get setup as a developer by required by Apple, Google, etc.) or the barrier to entry always kills my time, then I go onto something else. LÖVE https://love2d.org/ was the only one I actually got anything playable with, but Lua/LÖVE was a little finicky and got frustrating. I want to be up and running and deploying to an emulator with something interesting in no more than 30 minutes, and I don't care how blocky it looks.
Years ago I wrote homebrew games, so I'm not new to concepts required, but I don't want anything too complex.
Otherwise I'd suggest you brush off you C skills and use SDL.
Or just tinker with Pico-8 if you want some oldskool nostalgia https://www.youtube.com/watch?v=ZuaLuMhwcc8&list=PLvUqRm2B9R...
This. I don't read a lot of outcry over this for unknown reasons. It baffles me. Apple essentially broke all web based apps and not many people seem to care.
I'm sure if web apps worked Jobs would hav been happy to leave it there. He was against iTunes on Windows, the move that made the iPod what it was.
It was a huge problem and this made life easier for a lot of users, significantly more than there are webapp users affected by this out there.
Maybe that's because of app review, maybe it's the system defaults, it just isn't an issue.
I don't think I ever had an issue with a webpage that seemed purposful. It always seemed to be something they were trying to do for the desktop (perhaps not a great idea there) that was a disaster on mobile. Or maybe they tested on an iPad and when the screen is 4" instead of 10" it's unusable.
If I press the menu and your menu takes over the entire screen, seemingly like a new page, the back button should close the menu, not navigate off your site, especially if there's no way to close the menu other than navigating to a link. Floating elements that take up 20% of an already small screen with absolutely nothing useful on them and no way to get rid of them are broken. Redirecting a non-mobile link to the home page of your mobile site instead of to the content the link actually points to is pretty common too.
But I've never seen an app present me with the equivalent of 3pt text by default.
That said I prefer my text smaller, have my phone at the smallest font size and rarely zoom in on text. I also wish there was a "remove the pointless whitespace" option and that other ui elements got smaller along with the text, but I'm rambling.
I love news sites that think a tiny window with a couple of video bobble heads commenting on something they're clueless about is content absolutely everyone must see. Whether they want to or not.
If you're building a "native" app that happens to uses web views as an implementation detail, as in this article, Apple explicitly exposes a property in the WKWebView API to revert to the former behavior. See: https://developer.apple.com/reference/webkit/wkwebview/14149...
Hell, in most of the platforms you can use your language of choice and P/Invoke C++ components.
Also everyone had to build UI from scratch before Ionic and other frameworks, and that was just crazy.
Figuring out if you need to use either the PhoneGap or the Cordova binaries, and then finding correct documentation for the respective forks, was in itself a big hassle. But no more than trying to get the toolchain up and running. Holy backflipping cow was that a nightmare. I have managed to repress the details but it was something with installing NPM and then typing in magic commands and hoping some byzantine series of effects would occur correctly, which they never did.
I somehow managed to hack and slash the platform into a working configuration, only to discover that performance (for games) was still far from adequate. I'm sure it has its (non-game) uses, but the developer experience was probably the worst I have ever experienced.
If your app doesn't need extreme performance, and you don't have the time to learn and develop for multiple platforms, and things like unity/kivy etc don't give you enough UI, then Cordova is suddenly much more attractive.
I wrote a (simple) 3d game using WebGL and released it on the Android app store using Cordova, and found the performance was pretty solid.
This might be due to Android vs iOS, WebGL vs plain HTML or something else entirely - any thoughts?
In case anyone is interested, the Android version is at https://play.google.com/store/apps/details?id=com.github.wil... and an earlier web version is at http://matt-williams.github.io/ld29/
https://play.google.com/store/apps/details?id=org.lichess.mo... https://itunes.apple.com/us/app/lichess-free-online-chess/id...
I realize this is anecdotal, it would be interesting to see his/her game, what was so demanding to cause performance problems. Many platforms have their quirks and SDKs that you need to learn.
I've had a lot more breaking changes with my React Native app. Opened the other day, and text boxes were overflowing their container. Didn't happen before. React Native is younger, so I find it's to be expected.
But having used Cordova for several years I'd say that overall it's an excellent framework that can power large, complex apps.
I'd also wish Apple would give the web-views some more love, but overall they work really well for many things.
This is sometimes the case with native games too. I can sometimes get a few hundred millisecond warning when a text is incoming because of a sudden uptick in lag, even on an iPhone 7.
I learned nothing from this because if I was going to build a game like he described, I would suck it in and get down to the platform's assembly language layer which for IOS is ObjectiveC and for Android is Java.
It would be far more interesting to read a review that explores the boundary of what works well in PhoneGap and what doesn't. Clearly lots of successful apps are built in PhonegGap/Cordova. We could have the same conversations about desktop apps or server apps. Too many layers make things easier to build but impose a performance penalty. It is wise to think before you build and do some architecture and engineering before coding. Writing code is NOT engineering.
Wouldn't Java be more portable than C++?
https://github.com/google/j2objc https://software.intel.com/en-us/multi-os-engine
Usually when someone asks me "What should I use to make a cross-platform game", what they're really asking is "What tool can I use that won't get in the way of me making my game, that additionally allows me to target multiple platforms"
I would recommend MOAI - gives you the best bang for the buck, as long as you're willing to learn Lua to do all the app-layer stuff, and leave the MOAI engine to manage the performance-critical resources...
http://getmoai.com/
Why do web developers constantly make the argument that Javascript is not slower than C (or Swift, or C++, or any native programming language) ? The difference is night and day, 5000% and up for simple things like drawing.
I find that seriously doubtful, you're going to have to provide a citation if you want me to swallow that.
The relevant comparison is a single JavaScript function in Firefox looping through a static array and making WebGL calls vs. a C++ function looping through the same array and making OpenGL calls.
If the difference is 5000% or more I will donate $20 to the charity of your choice.
...that's not how graphics benchmarking works. That would be like benchmarking a language by seeing how fast it can add up integers.
If you artificially limit the scope to something trivial, anything can work. I mean, that might be interesting for web browser developers, sure, and by all means, use it for that. But what matters is what experiences can be created by it.
The web experience for games sucks.
So you mean like most language benchmarks. :)
0 - http://floooh.github.io/2016/08/13/webgl-next.html
What I'm getting at is that it's easy to blame Javascript, but really that's not the whole picture, and if Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues.
What would "supporting Javascript natively" mean? If you mean AOT, classic AOT (without some pretty fancy research-level PGO or something) is not a viable compilation strategy for JS.
I do agree heavily with your overall point that the JS blame is misplaced. People often forget that JS is faster than Objective-C at important things like method calls for systematic reasons.
https://www.nativescript.org/
Probably because that's completely untrue, and would be irrelevant even if it were true.
If you're doing "drawing" (which in this case means blitting) on the CPU to begin with, you've already lost.
1) it is possible, even at high resolutions
2) anything worth doing in opengl can't work in javascript for other reasons (mostly data size). And yes, you could download hundreds of megabytes worth of data files just to show an intro screen and then a few gigabytes for a game over an internet connection. I hope you have patient customers and a huge webhosting budget.
So let's be honest here : for small games, the effort of doing it with OpenGL/WebGL is not worth it. For large games it cannot be done, but for other reasons (that actually also apply to small games: 50 megabytes is incredibly oversized for a webpage, but still rather small for a game, so these problems actually overlap)
I myself feel guilty for stating this, but it actually works better to render the entire game server-side and videostream it to the client. Yes, javascript (and the web ecosystem) is that bad.
Is there no use for it ? Well, I appreciate the speed at which I can try out shaders locally. None of the niceties of javascript such as debugging or any sort of development process work, but it's still nice that you can get up & running in an hour or so.
But any reasonable game on javascript or the web platform ? Doesn't work and at this point it's so far from working it's a bad joke.
That only makes sense if the graphnics performance is actually the bottleneck of your game.
99% of the games I've seen have game design as the weakest link though, and sometimes art (it's not amount of polygons on the screen — it's how beautiful those polygons are). And if you actually want to improve on your game design, the metric you have to optimize is iteration speed — and the "assembly language layer" is rarely the best for this purpose.
The assembly language layer for iOS is assembly language.
Really the advice should just be don't use JavaScript and web technologies for mobile gaming.