Yes, you can call to the JavaScript like that to avoid code injection. It's a good implementation, and it looks like it also recursively reconstructs the JS object into an AHK object. That's good for some reasons, but also can be very slow. When I'm ready for the 1.0 release of cJson I suspect it may be faster than that snippet. And, as mentioned, simple JS implementations only parse--a serializer will take additional code and will be slow compared to the cJson implementation. Then there's the problems relating to nulls and booleans losing their type information.
Working independently, I've built a library that addresses some of those problems, available
here, but it's slower than cJson will be and still depends on Internet Explorer.
JSMN cannot be compiled for AHK using any of the existing MCode implementations. You're welcome to try. If you manage it I'll grovel for your secrets haha. I may be able to steal the compiled code from the AutoIt script there, but I'd caution against borrowing random machine code. Supposing I did (ignoring copyright violations), I'd also be unable to effectively modify it to add support for nonstandard extensions like inline comments (planned for cJson).
We're building an entirely new MCode stack for AHK, of which cJson is the first project utilizing it. This new MCode stack actually could compile JSMN for use by AHK, but only in 64-bit right now. JSMN doesn't generate native objects, limiting the usefulness of the library, and any code to convert its output to AHK objects will very likely have more overhead than cJson doing it natively (at the 1.0 release).
Eventually, we want to provide a custom COM object, implemented by embedded MCode, that will provide real key hashing, no "magic" key values that can break AHK like _NewEnum, and integration with cJson that will provide near-instant parsing and serializing. This is not planned for the 1.0 release, but when it comes it will make all other implementations look like snails in comparison while still addressing problems like type hinting and unwieldy foreign interfaces.
No 32-bit support, which may still eventually happen, is a small enough price to pay for most use cases especially now. Windows 11 will no longer support 32-bit processors (though will keep the 32 bit compatibility layer). Very few legacy AHK libraries have not been ported to 64 bit. I may be mistaken, but as I recall even 32-bit MS Office provides 64-bit COM objects. I think time spent trying to maintain 32-bit compatibility in new software may be just as well spent updating old code for 64-bit compatibility. If it's a deal breaker for you, you can always swap out the JSON module with something else.