You might be interested in this thread which shows Construct out-performing GameMaker with an independent benchmark that's more focused on the overall engine. Small and simple benchmarks ought to be doable in the free edition of Construct, so you shouldn't need to purchase to run some benchmarks.
There are a few options already for integrating code and events, such as callFunction to jump from JS to event sheet, and script blocks/actions to jump from event sheets back to JS. What would better integration look like to you?
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.
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.