If the graphics driver is the problem, a native engine will still run in to issues with that. It could even crash or glitch even worse. Unfortunately drivers are notoriously poor quality. Changing to different technologies isn't a silver bullet that fixes everything.
We've done a ton of work to optimise event blocks already - I've written some past blogs covering work done on that (e.g. compiling expressions to JS). We've done so much that it's probably quite difficult to make any significant further improvements.
The blog post covers several major disadvantages of using a custom programming language. The benefits of JavaScript are so big I think it's clear it outweighs any benefits there may be of a custom language.
I'm not sure why you seem think this is some kind of gotcha - I know console support is missing in Construct and that our choice to focus on HTML5 is a reason that it's difficult to support consoles. My point is just there are actually plenty of people out there who are focused on other platforms like mobile, and aren't planning on publishing to console. For example how many Android game designers do you think are thinking of porting their work to Xbox One? I doubt it's many, as it's such a different form factor and market. Console support may be very important to some, but it isn't everything to everyone. And it's not like the fact it's missing negates all the benefits of JavaScript pointed out in this post for people who publish to those platforms.
Construct does excel at the no-programming block system and that's a big focus of the product. But part of the point of adding JavaScript coding is to expand the scope of the product to include programming. And the point of the post is to highlight that if you're interested in that, JavaScript has many strengths that make it a great choice.
Do you have any actual benchmarks? The benchmark in the post shows JavaScript outperforming YYC, which uses native code, by over 5x.
Lots of people - and increasing numbers - do use JavaScript coding in Construct. And while there isn't built-in console support in Construct, lots of people publish to other platforms like Android, iOS, web, desktop apps and so on. There's a much more diverse usage out there than you seem to suggest, and we'd like more people to know about the strengths of Construct!
WebView2 is shipped with Windows 11, so the extra download won't be necessary in future. The auto-updating browsers/webviews hasn't really proven to be a big problem on the web or on other platforms like Android, so I wouldn't expect that to be a significant issue with WebView2 either.
I agree Construct has lots of other benefits! This post only focuses on the programming languages. We may be doing more to highlight other Construct benefits in future.
Like any platform NW.js has some bugs but usually they get fixed in updates. And if you stay on the same version, nothing actually changes so it shouldn't suddenly break overnight. Are there any active issues with the latest NW.js version?
I'd point out the new Windows WebView2 exporter is just ~650kb for a zipped empty project - even smaller than GameMaker. Also the cross-platform inconsistencies were about whether things work the same across platforms - JS may have its quirks, but at least they're exactly the same on all platforms so they don't become porting hurdles.
Relying on third-parties is basically unavoidable with modern software, as I mentioned in this comment.
We recently introduced the new Windows WebView2 and macOS WKWebView export options providing lightweight alternatives for desktop publishing - particularly relevant to people who had complained about the size of NW.js in the past. As for consoles, it's difficult for us to act on that unless console makers add support for HTML5 games - but there are third-party porting services out there.
Using third-party software is simply unavoidable with modern software development. Changing technologies still won't completely solve that. For example with native engines graphics driver issues can be far more problematic - and graphics card vendors are almost impossible to communicate with. If there's a public bug tracker, at least there's a viable route to getting something fixed - and we routinely do file issues on behalf of user issues and follow them up. Lots of bugs do get fixed this way. Some might slip through the cracks but as ever, changing technology is not a silver bullet that will solve everything.
What's actually wrong with using third-party tools? No technology is perfect, everything has its quirks, but in general they work out great. And if there's no significant downsides, it's a great way to speed up development. With tools like Cordova, you're still getting much faster performance with JavaScript, so there are big wins too. And Construct provides services like the mobile app build service that help make it easier to publish to Android without needing to install and configure loads of developer SDKs.
Edit: I'd add the whole reason JavaScript has so many benefits, is because we rely on third parties to provide the programming language. The point of the post is that if we made our own programming language it would likely have several major pitfalls. So there's big upsides to relying on third-party tools too.
The blog post includes both a JavaScript and event block based version of the performance benchmark. You can try them both out yourself.
The plugin is fully documented, including with setup instructions in the Mobile Advert manual entry. Please note however the instructions will shortly be updated for the latest SDK updates.
Member since 21 May, 2007
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.