My comment on Jai is that it is a language with some conveniences, but ultimately no strong reason to favor it. Similar to zig, odin, and others, its basically just C with some syntax conveniences.
It has some design choices that I appreciated at first, but are really strongly suited to a particular way of writing games, and I wouldn't call it general purpose (those same design choices are very limiting in other domains).
I do appreciate compiler speed, but ultimately I bounced off of it because the slight improvement in syntax doesn't justify losing massive tooling, libraries, docs, support, etc.
The language is also quite quirky in its conventions, which I think is due to Jon Blow's style, but which can feel quite odd to anyone who has a wider breadth of programming (than just custom game engines).
Also of course, any contributions or suggestions are met with the typical JB politeness and charm :)
All the flaws people mention here, are simply because you just don't get what a genius he is, those are actually features!
> Similar to zig, odin, and others, its basically just C with some syntax conveniences.
Extremely reductive and untrue. As someone who still writes/deals with C daily, there is room for a successor that still attempts to be a thin wrapper around an abstract CPU. The C type system and preprocessor has some glaring flaws that are not fixable in a backwards compatible way.
Yeah I'm sure there are some people who just want C with better syntax and faster compile times, for them I think it could be fine (assuming they don't need well tested 3rd party libs, an ecosystem, documentation, portability, or robust tooling).
I just meant as my general purpose goto language, I couldn't add to the roster. C++ is already filling that niche for me (except with all the aforementioned benefits), python for scripts, C# for a solid GC lang, there's just no place for a scrappy quirky lang with lots of sharp edges and no value propostion.
I'm just not sure why you would choose _this_ language for those needs. There are like 10 new langs that are all trying to be "the next C" and they all kinda suck (Jai included). I dunno, for me none of them had the same kind of feeling that you get from the really top-tier languages, they all felt like "we took C and solved these annoyances" not "we had a fundamentally new vision".
Yeah, I find that a lack of a GC means that I don't reach for these languages unless I have a reason to think I really need that level of performance, you lose too many conveniences, the perf gains are usually not worth the investment of thinking through memory ownership. The only language of this class that I regularly use is D, in that lang I can remove all the GC parts for things that do have such perf reqs while reusing most of my GC code, but the things I can do with GC end up being really concise and easy to read, while still being faster than the equivalent python :shrug:.
To be fair to Jai, Odin and Zig, there are definitely software libraries/applications that the world would benefit from having, where this level of performance is basically required. The standard tends to be C++ these days (Rust is rapidly gaining ground, but it's still inconvenient in cases where you frequently need to abstract under the allocator), and I think everyone is looking for a way to not have to write c++ for this stuff.
Interesting. I feel similarly but use Rust since I don't really have to think about GC or non GC, I use it more as a modern StandardML or OCaml but with much better performance.
There is a contingent of people that truly believe this, and I feel like that is what is motivating a lot of these "better C" languages. For me, those languages always leave me realizing I need to implement my own v-tables in 2026.
God help you if you are doing multi-threaded with closures and callbacks, web programming, something high level like ML, etc. I feel like the thesis statement of Jai starts with "Ok, so lets assume most programmers are trying to program custom game engines...". True for a very limited set of people, but makes it very painful to use generally.
Its the same feeling you get trying to use Unreal for anything except 3D first person shooters. Its possible, it just doesn't feel very good, and you start to see all the quirky assumptions of the framework.
I think you are confused maybe, Jai is made by a game developer, to make video games. Whatever exists in the language is there primarily to help video game developers make video games.
At no point did Jon Blow make the claim that Jai would be a good language to do web development with. It is a low level system language, if you are making something that requires low level systems language features then you will probably like Jai.
I don't want syntax conveniences, I want fewer footguns. C has so many ways to trip you up that aren't inherent to its domain. Are any of these new languages better in that regard?
it is true you dont want to trip you up by the language you use, but look what people actually use the languages, not by theory.
almost nobody writes the high performant code directly, usually they just call some libraries that do the job instead. if you are the library writers, then sure, that's a different matter (but people have been doing it forever using c/c++), but for people who use the libraries to write the code, they don't care about any of that.
many people rather pick python, lua, ruby to write applications, even games, despite the low performance of the scripting language, but they don't care. and if it is only the scripting aspect of the whole framework (implemented in C++) then the speed lost is even less.
heck, even for rust, the core libraries always need unsafe blocks, despite they do not recommend user code to use them. it is the same story everywhere. the hard part will be write by more experienced people (and with more effort), the typical users just write domain logic instead.
so, for most people, they indeed need simpler languages with lot of syntactic sugars for better developing experiences.
Somewhat, in terms of macro munging vs actual templates and other conveniences yes, however its still very possible to have unsafe memory operations and to accidentally create unexpected behavior. They have their own footguns in some ways, for example Jai's use of arenas can be tricky in more complex programs (e.g. you stored a value with a reference or array, the arena expired). Great for games, bad for most normal code.
Hence why I say, if you are doing complex / multi-threaded code, good luck to you.
This is why the GC and memory safe languages have mostly taken over. They have even more ergonomic syntax, and none of the footguns. You can still do all the normal pointer casting / abuse type stuff in most of these languages too.
JB's original claim, at least as I understood it, was that with LLVM and the like language tooling is now good enough that anybody can quickly whip up a language to their personal tastes with no PL background, and therefore the hurdle of novelty and generality required for a language to justify its existence is drastically lower than it has been in times past. It's a shame, but having his personal language be in closed beta twelve years later is pretty strong evidence against that thesis in a couple of different ways.
AFAIK, the language is and was used in JB's projects.
JB is just very picky about when he wants people to see things.
He doesn't want outside voices influencing him and he still has some things he wants to think through. Doing that mostly solo takes time - it's not like the PL is the only thing he has been doing
If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I would like you to elaborate on how still being in closed beta is an argument against the thesis. To me it just looks like avoiding feature-requests, nitpicks and community interactions for a product he doesn't even want to sell.
I'd agree more except that as far as I know (I'll admit I've not been following the development that closely) he's been significantly building it in public on Twitch. So he's happy to spend time sharing it with the public, and has been from the start; it's just taken a long time to get it to a usable state.
> If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I think we're firmly in agreement here, except that IMO the default for software that's not for public consumption is to throw it over the wall, put the source up on GitHub or something, and not bother with documentation, explanation, or interaction. A carefully curated closed beta is kind of the opposite of that. If anything he's spending more time promoting it than I would expect.
The whole "LLVM has made programming langs easy" is a joke, unless your language is just a syntax wrapper over C-like functionality (so those saying such things are kind of telling on themselves).
Having really sophisticated memory management, type checking, semantics, safety guarantees, etc. is not at all trivial. The only part that has gotten easier is syntax => AST => machine code, but that is probably 10% of a PL if you want it to do something people will actually use.
Of course Jai "is fast" (meaning it has none of those things), so obviously LLVM is 90% of the work (just translating AST into LLVM calls). Yes, you can do this with AI in an afternoon, no its not useful to anyone. The real work of making a usable, interesting, useful language is not diminished, and it has little to do with the syntax => AST => LLVM part of the compiler.
Said another way, no one is choosing C, C++, Python, or Java because they are "easy ways to get generate machine code". They choose them because they have: superior semantics (design, memory management, portability etc), 3rd party libraries, frameworks, debuggers, ecosystem, documentation, support, standard library, etc.
Blow's claim was that C++ sucks and that an alternative better suited for gamedev should be created. It's not like he's had good things to say about LLVM.
My understanding is that thinks C++ sucks period (an uncontroversial opinion even among C++ devs).
His reasoning was that C was a pretty minimalist language introducing structured control flow and little else, yet it's flexibility and neutrality has allowed people to explore lots of approaches.
C++ on the other hand is highly opinionated, and a lot of its opinions are considered wrong or at least controversial (template metaprogramming, RAII, exceptions, diamond inheritance, just to name a few).
A lot of the C++ community doesn't use these features (for example Chrome, LLVM have exceptions turned off).
Jai on the other hand goes heavily into typed AST macros (along with a reasonably powerful type inference enigne), a very powerful extension of the language, that this language has gotten right - the feeling you get when looking at the docs is 'well, duh it obviously has to be done like this' - considering how long it took devs to arrive at this system suggests this is far less an obvious task than it looks like.
Other than this, what the language offers over C isn't much - it shares Odin's 'context' idea that you can inject an allocator or logger function and have your methods use that - which is kind of the point imo.
Blow, as outspoken and controversial a figure he is; seems to have designed a pretty unopiniated language - something designed for master programmers (like ones he has worked with in the games industry, who worked mostly in C) to express themselves, rather than a set of 'correct' opinions the language imposes on you.
Imo it's a shame it took so long to release, as I'm p. sure Jai would've been much more influential 2-3 decades ago or more, and would've had a good chance to dethrone C++.
LLVM doesn't have to be great for its existence to make PL dev a lot easier. Codegen used to be a real pain.
The interesting part to me was always that he didn't justify Jai very much. He didn't assert that anybody else would want to use it, or that it would be universally better than C++. His claim was that he didn't need to: building a language is now so quick that he can make a language just for him, just because he feels like it. Everybody can have their own language frontend.
In fact reading between the lines of that video a bit, I think he might believe that general-purpose languages are poorly suited to his use because they're focused on solving other people's problems. But that's just me extrapolating.
I have been developing my language+runtime for the past few months, using LLMs, and would like to see someone whip one up quickly, using LLMs, particularly with no PL background.
This has been my hobby for nearly two decades and it is not so easy because there are hundreds of edge cases that must be considered even if the LLM writes all the code.
It's evidence of no such thing. It categorically does not take 12 years to write a language from scratch, or anything remotely close to that, so the only thing that Blow taking 12 years to write a language is evidence of is that Blow chose not to prioritise language development very highly over doing anything else with his time for 12 years. Javascript was famously developed by one person in 10 days. Writing a language and compiler is a common semester project for students, ie. people who have no idea what they're doing.
Eh? It is not his duty to public his language. It is not like publish the language is the end of story, you need to deal with the flood of feedback, that not always from good wills. The drama could cause him to lost time, effort and motivation, and hinder his game dev process.
It is pretty understandable he needs to hold back before he releases his new game, or even more.
If he raises interest in the language by saying it will be open source (which he did), I think it's fair for people to dismiss the language until he does actually open source it.
Putting stakes into a language that will essentially be DOA, like the author does seems like a crazy decision.
Yeah, even when the choice itself might be exempt from critique, stating one thing and then doing another surely isn't. Misleading posturing which can't be proven to be dishonesty but is impossible to differentiate from it seems surprisingly common for reasons I can't wrap my head around.
This happened years ago with the V programming language making a bunch of claims about the existing feature set that were not accurate and future roadmap that did not at all reflect how things went down, and it was all very bizarre and seemingly avoidable if the developer were truly committed to communicating better.
Another development process this reminds me of is the development by modders to port Oblivion to the Skyrim engine. After maybe a decade, the developers made a huge deal at the end of 2024 that they were going to finally release by the end of 2025 and made a lot of noise about it, but by the fall when no more details had been announced, someone asked in Discord about it and the lead developer directly said that it was not going to happen, with an announcement that it was "delayed" to 2026 not getting made until after people posted screenshots of this. We're now in October of 2026 and it's not clear it will be out this year, but trying to give feedback on the communication gets construed shouted down with exhortations to "let them cook". As far as I can tell, a large number of people seem to think that a suggestion that it's fine for the developers to just not keep announcing when things will be done so that they can take as much time as they want without confusing people is synonymous with telling them they need to release immediately.
you are not wrong. but like I said it is entirely his choice, which is also reasonable considering the budget Order of the Sinking Star already burned (I heard it was at AA level already)
it is not like he can get the funding via opensourcing the language to cover the development. what he and his company needs is the game to finish and release and get enough profit to cover all the expense. making a new engine is already risky enough.
you just can't ask a man to ruin his whole career/life because it benefits you.
While it is not open sourced yet (to be honest it is not as important as you think, many programming languages are mostly implemened by a dozen people, even a single creator is not rare) it is not like he forbids anyone to ask for being beta testers, just like the blog writer.
I’d love to try this out. But the SDK can’t be used unless one first signs up to Jai beta?
Had few other questions:
- Is the dev environment still web first or is that a secondary target?
- One of the best things about three.hs is the extremely fast feedback look with HMR where if setup properly you can code see changes reflected in your running app without a refresh or losing state within a second. Is something like that feasible here?
- How complete is the PBR support?
- Lightprobes or lightprobe grid supported? I know that’s just mostly material/shader related code so shouldn’t be impossible to add based on a project’s requirements.
- I didn’t see support for skeleton meshes in the examples either, is that possible?
Yes, the SDK being limited to jai beta is absolutely not something I'm happy about. I was hoping it would be public by the time polygon v2 was ready, but of course that was a gamble. Now the rumor is that it will be in 2027, so this is hopefully just a matter of waiting a bit more time. So I completely appreciate presenting Polygon like this isn't ideal.
But depending on what projects you have in mind, the node-based editor is already quite flexible. Feel free to let me know what you're thinking of building and I can tell you what you could try.
To your questions:
- Is the dev environment still web first or is that a secondary target?: I personally mostly dev in native, do most of the work and tests there, and then do final checks in wasm/js. Most of the projects I deliver using it still are web-based, so this target remains as solid as I can make it.
- [...]see changes reflected in your running app without a refresh or losing state within a second: I used to rely on that, but as projects scale grew, I always found that state would become stale in ways I did not understand, so I stopped chasing that. And when working in native against the SDK, re-compiling a project takes about 1-2seconds, so I have not needed to make this work as smoothly as in js. But I could look into it. And when you scaffold a SDK project, the wasm is reloaded without a page reload, but I think your app state my still need vuejs or react to handle that. In short: not fully sure, but it's most likely possible.
- How complete is the PBR support?: You can use env maps. The materials of imported GLTF are decent (see example: https://polygonjs.com/gui/gltf_import). Several things are still missing like clearcoat, and maybe others I am not fully aware of. There are advanced features like order-independent-transparency, volume rendering, raymarching.
- Lightprobes or lightprobe grid supported?: no light probes at the moment. I want to look into it. And I'm evaluating/experimenting with various GI solutions, which may vary depending if you're rendering polygons, SDF or voxels.
- I didn’t see support for skeleton meshes: There is none yet, but that's definitely on my roadmap.
- Also, how feasible is WebXR support?: not implemented yet, but also high on my roadmap.
Thank you for the reply! I will be keeping an eye out.
Just to preface, I’m the developer of an nsfw bdsm game that’s getting some traction. That might not be something you’d be interested in supporting. But it is built using three.js webgl, its is VR-first but optimized enough for even iphones (memory wise to avoid crashing) with very high quality 3d models and physics. It’s also got a story/narrative/dialogue system with multiple worlds/stages. And everything is done in such a way to not spike memory usage even as different stages and parts of the story with hundreds of audio files, animations load over the web with pre-emptive caching.
It’s very hard to ensure memory usage stays low and make the right trade offs for browsers like Safari that don’t give you too much insight into it. Not to mention the limits of webgl for reducing gpu and cpu time which I’m currently also constrained by in terms of scale.
I’ve been considering migrating to babylon lite as webgpu webxr is nearly ready and already out for devices like vision pro, and it’s the only framework that in my testing actually reliably compares to threejs webgl renderer (threejs webgpu and og babylon are way behind).
But all in all having complete control over the memory seems amazing.
And regarding HMR, yeah it does require careful setup with r3f/react and obv has edge cases. But as my game’s story has increased to be hours long, it is quite handy to able to not wait for majority of changes as reloads which themselves can take a few seconds etc.
If you’re interested in chatting more, I can share the project with you if give me an email or another private avenue.
If you want to know when/if I realise any of those features, I send a newsletter every friday with what's new: https://polygonjs.com/newsletter
And the type of project you're describing isn't my personal interest, so no need to share it with me. But I'm curious about tools you've used to control memory with just javascript. I know there are extensions or browser flags you can toggle on, but those still seemed cumbersome. That was one of the main reason that motivated the rewrite, and I find it a relief that I can now detect memory leaks in the test suite, or have an easy way to have arenas (and arenas of arenas) so many objects can be freed/recycled very quickly.
So if you have a good way to control/manage memory in js, I'd be curious to hear.
And you mention "webgpu webxr" as if those worked together, but isn't webxr completely decorrelated from the render api? Or do you mean threejs implementation where those might be intertwined? I assumed webxr would work equally well under webgl or webgpu, since my understanding is that it mostly provides camera projection matrices and ray hit functions. But it could be that my knowledge is out of date, since I haven't touched webxr in the last 2 years.
> But as my game’s story has increased to be hours long
For those situations, on most projects I work on, I create a specific control node, which allows changing the state to predefined scenarii, or saving your current state. This requires the SDK for now unfortunately. But this can then be used with or without the editor, and allows you to quickly change from one state to a completely different one with 1 click or hotkey. I found that's the kind of technique that replaced hot reload for me. This made sure that only the state is updated, which limits the chance of bugs due to side-effects. Now that I write this, I realise this needs a proper documentation, I'll work on that.
Yeah so I have no sophisticated tools, just guessed calculations done mostly at run time (add up how much do gpu compressed textures should take for a model, mesh+blendshape memory estimates, other data structures). And obv for audio and animations just ensuring what’s not needed is never in memory and just knowing how much the biggest ones cost. To come up with an estimate of an upper bound and obv with lots of testing. ios safari doesn’t even publicly expose how much memory usage is allowed to a tab (and it changes) so really the final test is that stuff stops crashing. But my testing put the crash window between 500mb-1gb on an iphone pro. over 1gb usually guarantees a crash. Not really enough to make a proper game by today’s standards but hey they shipped gta san andreas at 32mb ram on ps2 so I’m sure I can push things further.
To answer your webxr webgpu question, no, it still doesn’t mostly work. If you’re interested in reading up on it:
Webxr webgpu attempts iirc some advanced reprojection for increasing FPS that takes into account the depth buffer. And vision pro at least today has some nausea inducing bugs around that for at least the official immersive web examples hosted on github.io. so its better if a depth texture isn’t supplied today. the fallback reprojection works better more smoothly.
For the story stuff, I have similar things setup in my project to essentially reload the game at a certain point in the story but still I personally find HMR to be much faster wherever possible.
Is there a manual for Jai, or some info on how it compares with other languages? I find it hard to find resources on it - there's no Wikipedia page, and my web searches list some videos and random github projects?
Which means this website doesn't even know how HTTP 4xx codes work (406 is about content negotiation) and is also being rather pathetically pedantic about user agents.
So, to you polygonjs.com, I say, 469 Go Fuck Yourself.
Very happy to fix any issue with the website but your link only shows "Content not available in your region", so I propose you to be less pedantic about regions.
Just so you know, Imgur the public image host is what bans certain regions for whatever reason, it's not the uploader's fault and they likely didn't even know you wouldn't be able to view that link.
That's an imgur.com link mate, it's a rather well known image host. I don't run it. I'm surprised you're not aware of it.
Let me give you the full text of the message I got:
> 406 Not Acceptable
> Your browser is not supported. Please update your browser to continue.
My browser is fine, it's built off Chromium like many are, but apparently the UA makes your website say no. Your website should stop doing that, it's pointless.
> Less hate would be good too
My apologies, but I'm rather sick and tired of websites that impose arbitrary restrictions because I'm not using official Google Chrome.
There's absolutely no reason to do UA filtering in 2026.
And using a 406 response incorrectly and ostentatiously so, triggers my nerd rage. Read the RFC about what 406 means. It does not mean what you're using it for.
And I definitely do not need to update my browser.
I'm not sure why you thought it necessary to filter on UAs, but come on, it's the 2020s, it's not like the bad old days of "only renders in IE5 or Netscape 2.0".
If I have to fake my UA to read your webpage, that's just useless friction that negatively impacts your reach. I don't understand why you'd do this.
It has some design choices that I appreciated at first, but are really strongly suited to a particular way of writing games, and I wouldn't call it general purpose (those same design choices are very limiting in other domains).
I do appreciate compiler speed, but ultimately I bounced off of it because the slight improvement in syntax doesn't justify losing massive tooling, libraries, docs, support, etc.
The language is also quite quirky in its conventions, which I think is due to Jon Blow's style, but which can feel quite odd to anyone who has a wider breadth of programming (than just custom game engines).
Also of course, any contributions or suggestions are met with the typical JB politeness and charm :)
All the flaws people mention here, are simply because you just don't get what a genius he is, those are actually features!
Extremely reductive and untrue. As someone who still writes/deals with C daily, there is room for a successor that still attempts to be a thin wrapper around an abstract CPU. The C type system and preprocessor has some glaring flaws that are not fixable in a backwards compatible way.
I just meant as my general purpose goto language, I couldn't add to the roster. C++ is already filling that niche for me (except with all the aforementioned benefits), python for scripts, C# for a solid GC lang, there's just no place for a scrappy quirky lang with lots of sharp edges and no value propostion.
I'm just not sure why you would choose _this_ language for those needs. There are like 10 new langs that are all trying to be "the next C" and they all kinda suck (Jai included). I dunno, for me none of them had the same kind of feeling that you get from the really top-tier languages, they all felt like "we took C and solved these annoyances" not "we had a fundamentally new vision".
To be fair to Jai, Odin and Zig, there are definitely software libraries/applications that the world would benefit from having, where this level of performance is basically required. The standard tends to be C++ these days (Rust is rapidly gaining ground, but it's still inconvenient in cases where you frequently need to abstract under the allocator), and I think everyone is looking for a way to not have to write c++ for this stuff.
God help you if you are doing multi-threaded with closures and callbacks, web programming, something high level like ML, etc. I feel like the thesis statement of Jai starts with "Ok, so lets assume most programmers are trying to program custom game engines...". True for a very limited set of people, but makes it very painful to use generally.
Its the same feeling you get trying to use Unreal for anything except 3D first person shooters. Its possible, it just doesn't feel very good, and you start to see all the quirky assumptions of the framework.
At no point did Jon Blow make the claim that Jai would be a good language to do web development with. It is a low level system language, if you are making something that requires low level systems language features then you will probably like Jai.
it is true you dont want to trip you up by the language you use, but look what people actually use the languages, not by theory.
almost nobody writes the high performant code directly, usually they just call some libraries that do the job instead. if you are the library writers, then sure, that's a different matter (but people have been doing it forever using c/c++), but for people who use the libraries to write the code, they don't care about any of that.
many people rather pick python, lua, ruby to write applications, even games, despite the low performance of the scripting language, but they don't care. and if it is only the scripting aspect of the whole framework (implemented in C++) then the speed lost is even less.
heck, even for rust, the core libraries always need unsafe blocks, despite they do not recommend user code to use them. it is the same story everywhere. the hard part will be write by more experienced people (and with more effort), the typical users just write domain logic instead.
so, for most people, they indeed need simpler languages with lot of syntactic sugars for better developing experiences.
Hence why I say, if you are doing complex / multi-threaded code, good luck to you.
This is why the GC and memory safe languages have mostly taken over. They have even more ergonomic syntax, and none of the footguns. You can still do all the normal pointer casting / abuse type stuff in most of these languages too.
If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I would like you to elaborate on how still being in closed beta is an argument against the thesis. To me it just looks like avoiding feature-requests, nitpicks and community interactions for a product he doesn't even want to sell.
> If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I think we're firmly in agreement here, except that IMO the default for software that's not for public consumption is to throw it over the wall, put the source up on GitHub or something, and not bother with documentation, explanation, or interaction. A carefully curated closed beta is kind of the opposite of that. If anything he's spending more time promoting it than I would expect.
Having really sophisticated memory management, type checking, semantics, safety guarantees, etc. is not at all trivial. The only part that has gotten easier is syntax => AST => machine code, but that is probably 10% of a PL if you want it to do something people will actually use.
Of course Jai "is fast" (meaning it has none of those things), so obviously LLVM is 90% of the work (just translating AST into LLVM calls). Yes, you can do this with AI in an afternoon, no its not useful to anyone. The real work of making a usable, interesting, useful language is not diminished, and it has little to do with the syntax => AST => LLVM part of the compiler.
Said another way, no one is choosing C, C++, Python, or Java because they are "easy ways to get generate machine code". They choose them because they have: superior semantics (design, memory management, portability etc), 3rd party libraries, frameworks, debuggers, ecosystem, documentation, support, standard library, etc.
His reasoning was that C was a pretty minimalist language introducing structured control flow and little else, yet it's flexibility and neutrality has allowed people to explore lots of approaches.
C++ on the other hand is highly opinionated, and a lot of its opinions are considered wrong or at least controversial (template metaprogramming, RAII, exceptions, diamond inheritance, just to name a few).
A lot of the C++ community doesn't use these features (for example Chrome, LLVM have exceptions turned off).
Jai on the other hand goes heavily into typed AST macros (along with a reasonably powerful type inference enigne), a very powerful extension of the language, that this language has gotten right - the feeling you get when looking at the docs is 'well, duh it obviously has to be done like this' - considering how long it took devs to arrive at this system suggests this is far less an obvious task than it looks like.
Other than this, what the language offers over C isn't much - it shares Odin's 'context' idea that you can inject an allocator or logger function and have your methods use that - which is kind of the point imo.
Blow, as outspoken and controversial a figure he is; seems to have designed a pretty unopiniated language - something designed for master programmers (like ones he has worked with in the games industry, who worked mostly in C) to express themselves, rather than a set of 'correct' opinions the language imposes on you.
Imo it's a shame it took so long to release, as I'm p. sure Jai would've been much more influential 2-3 decades ago or more, and would've had a good chance to dethrone C++.
The interesting part to me was always that he didn't justify Jai very much. He didn't assert that anybody else would want to use it, or that it would be universally better than C++. His claim was that he didn't need to: building a language is now so quick that he can make a language just for him, just because he feels like it. Everybody can have their own language frontend.
https://youtu.be/TH9VCN6UkyQ
This has been my hobby for nearly two decades and it is not so easy because there are hundreds of edge cases that must be considered even if the LLM writes all the code.
It is pretty understandable he needs to hold back before he releases his new game, or even more.
Putting stakes into a language that will essentially be DOA, like the author does seems like a crazy decision.
This happened years ago with the V programming language making a bunch of claims about the existing feature set that were not accurate and future roadmap that did not at all reflect how things went down, and it was all very bizarre and seemingly avoidable if the developer were truly committed to communicating better.
Another development process this reminds me of is the development by modders to port Oblivion to the Skyrim engine. After maybe a decade, the developers made a huge deal at the end of 2024 that they were going to finally release by the end of 2025 and made a lot of noise about it, but by the fall when no more details had been announced, someone asked in Discord about it and the lead developer directly said that it was not going to happen, with an announcement that it was "delayed" to 2026 not getting made until after people posted screenshots of this. We're now in October of 2026 and it's not clear it will be out this year, but trying to give feedback on the communication gets construed shouted down with exhortations to "let them cook". As far as I can tell, a large number of people seem to think that a suggestion that it's fine for the developers to just not keep announcing when things will be done so that they can take as much time as they want without confusing people is synonymous with telling them they need to release immediately.
it is not like he can get the funding via opensourcing the language to cover the development. what he and his company needs is the game to finish and release and get enough profit to cover all the expense. making a new engine is already risky enough.
you just can't ask a man to ruin his whole career/life because it benefits you.
I'm just cautioning other people to put any stakes into a language that's from its organizational bones doomed to fail for any outside party.
Had few other questions:
- Is the dev environment still web first or is that a secondary target?
- One of the best things about three.hs is the extremely fast feedback look with HMR where if setup properly you can code see changes reflected in your running app without a refresh or losing state within a second. Is something like that feasible here?
- How complete is the PBR support? - Lightprobes or lightprobe grid supported? I know that’s just mostly material/shader related code so shouldn’t be impossible to add based on a project’s requirements.
- I didn’t see support for skeleton meshes in the examples either, is that possible?
- Also, how feasible is WebXR support?
Thanks a lot for your questions.
Yes, the SDK being limited to jai beta is absolutely not something I'm happy about. I was hoping it would be public by the time polygon v2 was ready, but of course that was a gamble. Now the rumor is that it will be in 2027, so this is hopefully just a matter of waiting a bit more time. So I completely appreciate presenting Polygon like this isn't ideal.
But depending on what projects you have in mind, the node-based editor is already quite flexible. Feel free to let me know what you're thinking of building and I can tell you what you could try.
To your questions:
- Is the dev environment still web first or is that a secondary target?: I personally mostly dev in native, do most of the work and tests there, and then do final checks in wasm/js. Most of the projects I deliver using it still are web-based, so this target remains as solid as I can make it.
- [...]see changes reflected in your running app without a refresh or losing state within a second: I used to rely on that, but as projects scale grew, I always found that state would become stale in ways I did not understand, so I stopped chasing that. And when working in native against the SDK, re-compiling a project takes about 1-2seconds, so I have not needed to make this work as smoothly as in js. But I could look into it. And when you scaffold a SDK project, the wasm is reloaded without a page reload, but I think your app state my still need vuejs or react to handle that. In short: not fully sure, but it's most likely possible.
- How complete is the PBR support?: You can use env maps. The materials of imported GLTF are decent (see example: https://polygonjs.com/gui/gltf_import). Several things are still missing like clearcoat, and maybe others I am not fully aware of. There are advanced features like order-independent-transparency, volume rendering, raymarching.
- Lightprobes or lightprobe grid supported?: no light probes at the moment. I want to look into it. And I'm evaluating/experimenting with various GI solutions, which may vary depending if you're rendering polygons, SDF or voxels.
- I didn’t see support for skeleton meshes: There is none yet, but that's definitely on my roadmap.
- Also, how feasible is WebXR support?: not implemented yet, but also high on my roadmap.
Just to preface, I’m the developer of an nsfw bdsm game that’s getting some traction. That might not be something you’d be interested in supporting. But it is built using three.js webgl, its is VR-first but optimized enough for even iphones (memory wise to avoid crashing) with very high quality 3d models and physics. It’s also got a story/narrative/dialogue system with multiple worlds/stages. And everything is done in such a way to not spike memory usage even as different stages and parts of the story with hundreds of audio files, animations load over the web with pre-emptive caching.
It’s very hard to ensure memory usage stays low and make the right trade offs for browsers like Safari that don’t give you too much insight into it. Not to mention the limits of webgl for reducing gpu and cpu time which I’m currently also constrained by in terms of scale.
I’ve been considering migrating to babylon lite as webgpu webxr is nearly ready and already out for devices like vision pro, and it’s the only framework that in my testing actually reliably compares to threejs webgl renderer (threejs webgpu and og babylon are way behind).
But all in all having complete control over the memory seems amazing.
And regarding HMR, yeah it does require careful setup with r3f/react and obv has edge cases. But as my game’s story has increased to be hours long, it is quite handy to able to not wait for majority of changes as reloads which themselves can take a few seconds etc.
If you’re interested in chatting more, I can share the project with you if give me an email or another private avenue.
And the type of project you're describing isn't my personal interest, so no need to share it with me. But I'm curious about tools you've used to control memory with just javascript. I know there are extensions or browser flags you can toggle on, but those still seemed cumbersome. That was one of the main reason that motivated the rewrite, and I find it a relief that I can now detect memory leaks in the test suite, or have an easy way to have arenas (and arenas of arenas) so many objects can be freed/recycled very quickly.
So if you have a good way to control/manage memory in js, I'd be curious to hear.
And you mention "webgpu webxr" as if those worked together, but isn't webxr completely decorrelated from the render api? Or do you mean threejs implementation where those might be intertwined? I assumed webxr would work equally well under webgl or webgpu, since my understanding is that it mostly provides camera projection matrices and ray hit functions. But it could be that my knowledge is out of date, since I haven't touched webxr in the last 2 years.
> But as my game’s story has increased to be hours long
For those situations, on most projects I work on, I create a specific control node, which allows changing the state to predefined scenarii, or saving your current state. This requires the SDK for now unfortunately. But this can then be used with or without the editor, and allows you to quickly change from one state to a completely different one with 1 click or hotkey. I found that's the kind of technique that replaced hot reload for me. This made sure that only the state is updated, which limits the chance of bugs due to side-effects. Now that I write this, I realise this needs a proper documentation, I'll work on that.
Yeah so I have no sophisticated tools, just guessed calculations done mostly at run time (add up how much do gpu compressed textures should take for a model, mesh+blendshape memory estimates, other data structures). And obv for audio and animations just ensuring what’s not needed is never in memory and just knowing how much the biggest ones cost. To come up with an estimate of an upper bound and obv with lots of testing. ios safari doesn’t even publicly expose how much memory usage is allowed to a tab (and it changes) so really the final test is that stuff stops crashing. But my testing put the crash window between 500mb-1gb on an iphone pro. over 1gb usually guarantees a crash. Not really enough to make a proper game by today’s standards but hey they shipped gta san andreas at 32mb ram on ps2 so I’m sure I can push things further.
To answer your webxr webgpu question, no, it still doesn’t mostly work. If you’re interested in reading up on it:
https://github.com/immersive-web/WebXR-WebGPU-Binding/blob/m...
Post by a Chrome dev: https://toji.dev/2025/03/03/experimenting-with-webgpu-in-web...
Webxr webgpu attempts iirc some advanced reprojection for increasing FPS that takes into account the depth buffer. And vision pro at least today has some nausea inducing bugs around that for at least the official immersive web examples hosted on github.io. so its better if a depth texture isn’t supplied today. the fallback reprojection works better more smoothly.
For the story stuff, I have similar things setup in my project to essentially reload the game at a certain point in the story but still I personally find HMR to be much faster wherever possible.
this is also good: https://github.com/Jai-Community/Jai-Community-Library/wiki
https://github.com/Jai-Community/Encyclopedia-of-Jai-Example...
https://github.com/Ivo-Balbaert/The_Way_to_Jai/
https://imgur.com/a/uF2CxfT
Which means this website doesn't even know how HTTP 4xx codes work (406 is about content negotiation) and is also being rather pathetically pedantic about user agents.
So, to you polygonjs.com, I say, 469 Go Fuck Yourself.
Less hate would be good too.
Let me give you the full text of the message I got:
> 406 Not Acceptable
> Your browser is not supported. Please update your browser to continue.
My browser is fine, it's built off Chromium like many are, but apparently the UA makes your website say no. Your website should stop doing that, it's pointless.
> Less hate would be good too
My apologies, but I'm rather sick and tired of websites that impose arbitrary restrictions because I'm not using official Google Chrome.
There's absolutely no reason to do UA filtering in 2026.
And using a 406 response incorrectly and ostentatiously so, triggers my nerd rage. Read the RFC about what 406 means. It does not mean what you're using it for.
And I definitely do not need to update my browser.
I'm not sure why you thought it necessary to filter on UAs, but come on, it's the 2020s, it's not like the bad old days of "only renders in IE5 or Netscape 2.0".
If I have to fake my UA to read your webpage, that's just useless friction that negatively impacts your reach. I don't understand why you'd do this.