craftyjs
Deprecate older browsers?
Right now we support relatively old versions of browsers such as IE9. But there are newer features in ES6 that might be nice to use.
As an example, there are several places where we could use Sets instead of objects, perhaps with a performance gain. (This was prompted specifically by looking at how we handle spatial searches; right now we use a new object each time to check for dupes, but a Set object would be a more natural fit, and is easier to reuse from search to search.)
Essentially this would mean removing support for IE9+10, as well as older versions of the android browser, before Android switched to just using Chrome. I believe most people using Firefox, Chrome or Safari will be on recent enough versions that it's not an issue.
I'm not sure.
Crafty's support for older browsers is one of the distinguished features among the vast variety of available JS game engines.
Crafty doesn't need to abandon older browsers. There are transpilers available (like Babel) which transform ES6 into ES5 compliant code if the browser does not support it. Keep in mind that the transformed code has awful performance, but works. e.g. babel for sets. So code would still work on older browsers, just slower.
You know that I've been fiddling with more drastic approaches to get considerable performance boosts, like TypeScript or C++ -> emscripten -> asm / WebAssembly. Haven't been completely satisfied with either: TS wouldn't give an order of magnitude better performance. C++ is in my opinion a difficult language with many intrinsics and not suited for open source development, since things can break pretty easily.
As of recent, rust can compile to asm / WASM, but it's still in its infancy. It's a systems programming language with strict compile-time checks, that would enable safe contributions. I've read about upcoming changes to emscripten that could lead to further problems, so it's still questionable if that project will take off.
Crafty doesn't need to abandon older browsers. There are transpilers available (like Babel) which transform ES6 into ES5 compliant code if the browser does not support it.
True, we could also simply supply separate builds of crafty for older browsers using such transpilers, if the generated code had a perf impact in modern ones.
You know that I've been fiddling with more drastic approaches to get considerable performance boosts, like TypeScript or C++ -> emscripten -> asm / WebAssembly.
I initially thought that moving our SAT solver to asm.js or wasm would be fairly straightforward, but after looking into it a month or two ago it didn't look hopeful. The main problem I saw was that the SAT solver operates on arrays of data representing polygons, but you can't pass in non-value types to libraries defined with asm.js. Something like a SAT solver would then have to operate on arrays that live in it's own "heap".
Something like the spatial-map implementation might almost be easier to work with, since it can easily own its own data structures -- x/y/w/h and the object ids are all simple numbers that could be passed in directly.
As of recent, rust can compile to asm / WASM,
I'd looked into that earlier, and it sounded like it was still pretty tricky to get the compiler to emit a library for integration with existing js code. :(
Here's a jsperf benchmark between our existing way of deduping result lists, and using Set.
Essentially it's a bit faster to use Set, but I think the real win would be removing the creation of a temporary object, since GC still tends to be a large performance problem for javascript games.
In #1189 I updated our jshint rules to allow es6. So the next release of Crafty will drop support for older browsers by default (though I'll look into providing a version built with Babel for older browsers.)