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.
For me Nim hits the sweet spot since 2.0 moved to ARC/ORC. All the benefits of GC for programming but it's much easier to control allocations and memory when desired. Plus I can run it as a script or compile to JS. I'd put Swift in a similar category too. Not compiling to JS but that it gives good control over memory while being automated via its ARC.
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.
Agreed, its just his idiosyncratic styled language for doing so. Like I said in another comment, using it for any other purpose feels like using Unreal Engine for anything but 3d first person shooters. You're going to have a bad time if you're making a 2d mobile-first puzzler. And that's why I don't see it gaining much traction (probably in the neighborhood of gdscript, haxe, or verse).
If you are making custom game engines, Jai has some conveniences (especially if you don't use any libraries or care about docs, ecosystem, community, etc). And if you really like "roll your own" with a dash of "everyone thinks I'm nuts but I'm just that much smarter", its perfect. Its one step above "I wrote my own scripting language".
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?
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.
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.
So what? Even if most people don't need to write low-ish level code, the fact remains that there are also many people who do (notably for this discussion, game devs). Should a language not exist to make their lives better just because it's not relevant to people doing a web service?
You should look into Jai’s metaprogramming features, which are ahead of everything else out there. Zig is really the only language exploring some of the same concepts with comptime, but doesn’t even come close.
Yeah I wrote some metaprogramming stuff, but to me it felt like run a python script and use python AST to manip the program. Its basically just a program that runs and has hooks into the compiler steps and the code.
This left me feeling like "I wish I had decorators and annotations" from other languages, not a way to write arbitrary compile-time code. The use case for that is so rare, and kludgy, that I don't think its worth it.
Now it did shine with basic hygenic macros, which felt useful and solid. Its basically how C macros should have been done originally (a function that emits code at compile time). However conventions like $Code where a bit jank imo, again felt like using someone's home-spun scripting language, rather than a well thought out solid design, versus something like Rust's Syn.
I know Jon Blow hates "design by committee", as he is so much smarter than others, but honestly a lot of this felt like listening to any sane reviewers would catch this stuff. I mean really basic stuff like #cast which reads like a compile-time macro/pragma, but its actually a runtime cast? Or mixing casing conventions, underscores or not, etc. Names of modules are all over the place, it just feels like one dude trying to make a half-baked lang over a long period while being distracted doing 20 other things.
What can i do in Jai i cant in, say Zig? I have never use Jai so im curious. I really how Haxe does metaprogramming, its incredibly powerfull. But not sure how Jai compares.
In Haxe i can pretty much do anything, run code, generate code, i even built an openapi doc on compile time just from types.
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.
> that is probably 10% of a PL if you want it to do something people will actually use
I think this is really understating the challenge of generating machine code that is competitive in terms of size, performance, etc. with state-of-the-art compilers. I'll be the first to agree that it's far from the only (or even the biggest) difficulty in PL, but it remains a huge chunk of engineering work. The interesting part of this experiment is how much of that work, as a percentage of the work of building a programming language, is now given to you for free, for a language that is indeed mostly ‘just a syntax wrapper over C-like functionality’.
(Of course, a big part of ‘people will actually use’ is nothing to do with the language at all, but the next twenty years of building an ecosystem and community buy-in.)
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++.
My first car was a hand-me-down van from my dad. It was big and akward, but I mostly used it for regular car things, and it was kinda bad and difficult at those, but I could manage.
The fact that it did the things I wanted it to (barely), while allowing me to ignore 90% of the design intent behind it shows it was designed in an opinionated way, just not in the way I cared.
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.
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.
Famously, as with many other things in computer science, writing a toy programming language that can compute Fibonacci is doable in a couple of hours, but writing a usable programming language that needs to stand up to real programs for users is typically somewhere between a decade and a lifetime of work.
If he'd announced the language twelve years ago and then not touched it again until a few months ago I'd believe you. But there's plenty of documented evidence that he's been spending a bunch of time on it, and (allegedly) even using it in his commercial projects.
Not to say that he's been working on it full-time for 12 years, of course, but even allowing for part-time work that's far beyond the initial ‘easier than The Witness’ premise.
> usable programming language that needs to stand up to real programs for users is typically somewhere between a decade and a lifetime of work.
Still no. Wildly incorrect. There are many, many languages that were developed and deployed in production in significantly less time, including C, C#, JS, Python, Perl, PHP, Ruby, Lua, basically any real-world language other than Rust was being used seriously in 1~2 years of development. C was written in 1972 and by 1973 an operating system was rewritten in it already.
Maybe you mean it takes a decade to develop a language where literally everything is provided for the user already and all they have to do is copypaste and smush together 1000 dependencies? If your metric is a child-friendly language like Javascript-with-npm, sure, it will take a decade to complete a full ecosystem. But getting a language to a point where it's seriously usable for people who are actually willing to write their own code, is really, truly not that hard.
I think that used to be true when systems were simpler and expectations were lower. But the expected standard of modern languages has come a long way. And I'm not just talking about libraries: performance, safety (strong static type systems are one can of worms, GC and other runtime checks are another), and even syntax design are things that state-of-the-art languages spend years iterating on before they're considered ‘usable’.
Some other more recent data points:
Go was designed at Google (one of the biggest software development entities of our times, with input from existing PL luminaries) in 2007, released in 2009, and officially considered 1.0 in 2012, five years later;
Clojure was started in 2005 (there were two other attempts to build similar languages dating back to 2003, but let's charitably omit them) and hit 1.0 in 2009;
Zig has been going for about 11 years and hasn't hit 1.0 yet.
Rust's nine-year record (2006–2015) is on the longer side, but not a huge outlier.
Of course, this is just the time to 1.0; I think in practice languages tending to iterate a lot before becoming mainstream (which is a weak proxy for general usability, but at least should work in one direction). Rust today has come a long way from 1.0, for example, as has Go. Definitely the ecosystems at 1.0 releases tend to remain noticeably underpowered, and even if you want to ignore libraries for a language it's harder to justify excluding other tools that make it easier to work with the language on your own or with other people to build real-world software, like editor support, debuggers, documentation, or package managers.
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.
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.
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.
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.
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.
I forgot it was such a small budget, it's indeed important to keep in mind how much could be done with little memory. Although I'd argue it was possible with a language that allowed you to control memory very precisely. With javascript garbage collector, I couldn't stand seeing memory ramp up every frame due to threejs internals or my own js code, and every few frame a major GC may or may not lead to a frame drop.
> advanced reprojection for increasing FPS that takes into account the depth buffer
Ah got it. I completely forgot that webxr of course needs to create textures to see through, so it indeed needs to know which graphic api is used. Thank you for the links, I'll have to study them.
Same haha, it’s annoying to have those occasional frame hitches that are predictable but essentially unsolvable with three.js just cause GC causes them. and even the memory heap just feeling like a inscrutable black box and not even going down in size when one’s app is barely supposed to use any.
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.
I know it's imgur.com, and it used to load fine from the UK. I was just making the point that we can all make mistakes and that common tools have edge cases we may not be aware of.
Apologies accepted. And thank you for mentioning the issue, it should now be fixed, so the website should load for you now.
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.
For me Nim hits the sweet spot since 2.0 moved to ARC/ORC. All the benefits of GC for programming but it's much easier to control allocations and memory when desired. Plus I can run it as a script or compile to JS. I'd put Swift in a similar category too. Not compiling to JS but that it gives good control over memory while being automated via its ARC.
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.
Disagreed. C with syntax conveniences is what most people need.
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.
Agreed, its just his idiosyncratic styled language for doing so. Like I said in another comment, using it for any other purpose feels like using Unreal Engine for anything but 3d first person shooters. You're going to have a bad time if you're making a 2d mobile-first puzzler. And that's why I don't see it gaining much traction (probably in the neighborhood of gdscript, haxe, or verse).
If you are making custom game engines, Jai has some conveniences (especially if you don't use any libraries or care about docs, ecosystem, community, etc). And if you really like "roll your own" with a dash of "everyone thinks I'm nuts but I'm just that much smarter", its perfect. Its one step above "I wrote my own scripting language".
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?
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.
please. think about it a little more.
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.
We already have plenty of great languages for those use cases.
So what? Even if most people don't need to write low-ish level code, the fact remains that there are also many people who do (notably for this discussion, game devs). Should a language not exist to make their lives better just because it's not relevant to people doing a web service?
You should look into Jai’s metaprogramming features, which are ahead of everything else out there. Zig is really the only language exploring some of the same concepts with comptime, but doesn’t even come close.
Yeah I wrote some metaprogramming stuff, but to me it felt like run a python script and use python AST to manip the program. Its basically just a program that runs and has hooks into the compiler steps and the code.
This left me feeling like "I wish I had decorators and annotations" from other languages, not a way to write arbitrary compile-time code. The use case for that is so rare, and kludgy, that I don't think its worth it.
Now it did shine with basic hygenic macros, which felt useful and solid. Its basically how C macros should have been done originally (a function that emits code at compile time). However conventions like $Code where a bit jank imo, again felt like using someone's home-spun scripting language, rather than a well thought out solid design, versus something like Rust's Syn.
I know Jon Blow hates "design by committee", as he is so much smarter than others, but honestly a lot of this felt like listening to any sane reviewers would catch this stuff. I mean really basic stuff like #cast which reads like a compile-time macro/pragma, but its actually a runtime cast? Or mixing casing conventions, underscores or not, etc. Names of modules are all over the place, it just feels like one dude trying to make a half-baked lang over a long period while being distracted doing 20 other things.
What can i do in Jai i cant in, say Zig? I have never use Jai so im curious. I really how Haxe does metaprogramming, its incredibly powerfull. But not sure how Jai compares.
In Haxe i can pretty much do anything, run code, generate code, i even built an openapi doc on compile time just from types.
[dead]
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.
[dead]
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.
> that is probably 10% of a PL if you want it to do something people will actually use
I think this is really understating the challenge of generating machine code that is competitive in terms of size, performance, etc. with state-of-the-art compilers. I'll be the first to agree that it's far from the only (or even the biggest) difficulty in PL, but it remains a huge chunk of engineering work. The interesting part of this experiment is how much of that work, as a percentage of the work of building a programming language, is now given to you for free, for a language that is indeed mostly ‘just a syntax wrapper over C-like functionality’.
(Of course, a big part of ‘people will actually use’ is nothing to do with the language at all, but the next twenty years of building an ecosystem and community buy-in.)
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++.
> C++ on the other hand is highly opinionated, [...]
> A lot of the C++ community doesn't use these features
That they even have the possibility shows how un-opinionated C++ is.
My first car was a hand-me-down van from my dad. It was big and akward, but I mostly used it for regular car things, and it was kinda bad and difficult at those, but I could manage.
The fact that it did the things I wanted it to (barely), while allowing me to ignore 90% of the design intent behind it shows it was designed in an opinionated way, just not in the way I cared.
Same goes for 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.
https://youtu.be/TH9VCN6UkyQ
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.
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.
Famously, as with many other things in computer science, writing a toy programming language that can compute Fibonacci is doable in a couple of hours, but writing a usable programming language that needs to stand up to real programs for users is typically somewhere between a decade and a lifetime of work.
If he'd announced the language twelve years ago and then not touched it again until a few months ago I'd believe you. But there's plenty of documented evidence that he's been spending a bunch of time on it, and (allegedly) even using it in his commercial projects.
Not to say that he's been working on it full-time for 12 years, of course, but even allowing for part-time work that's far beyond the initial ‘easier than The Witness’ premise.
> usable programming language that needs to stand up to real programs for users is typically somewhere between a decade and a lifetime of work.
Still no. Wildly incorrect. There are many, many languages that were developed and deployed in production in significantly less time, including C, C#, JS, Python, Perl, PHP, Ruby, Lua, basically any real-world language other than Rust was being used seriously in 1~2 years of development. C was written in 1972 and by 1973 an operating system was rewritten in it already.
Maybe you mean it takes a decade to develop a language where literally everything is provided for the user already and all they have to do is copypaste and smush together 1000 dependencies? If your metric is a child-friendly language like Javascript-with-npm, sure, it will take a decade to complete a full ecosystem. But getting a language to a point where it's seriously usable for people who are actually willing to write their own code, is really, truly not that hard.
I think that used to be true when systems were simpler and expectations were lower. But the expected standard of modern languages has come a long way. And I'm not just talking about libraries: performance, safety (strong static type systems are one can of worms, GC and other runtime checks are another), and even syntax design are things that state-of-the-art languages spend years iterating on before they're considered ‘usable’.
Some other more recent data points:
Go was designed at Google (one of the biggest software development entities of our times, with input from existing PL luminaries) in 2007, released in 2009, and officially considered 1.0 in 2012, five years later;
Clojure was started in 2005 (there were two other attempts to build similar languages dating back to 2003, but let's charitably omit them) and hit 1.0 in 2009;
Zig has been going for about 11 years and hasn't hit 1.0 yet.
Rust's nine-year record (2006–2015) is on the longer side, but not a huge outlier.
Of course, this is just the time to 1.0; I think in practice languages tending to iterate a lot before becoming mainstream (which is a weak proxy for general usability, but at least should work in one direction). Rust today has come a long way from 1.0, for example, as has Go. Definitely the ecosystems at 1.0 releases tend to remain noticeably underpowered, and even if you want to ignore libraries for a language it's harder to justify excluding other tools that make it easier to work with the language on your own or with other people to build real-world software, like editor support, debuggers, documentation, or package managers.
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.
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.
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.
I'm not asking him to open source anything. I've given up any illusions that that would be happening ~10 years ago.
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.
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.
Mostly a note, but the game was released 2 weeks ago. We'll see how well it sells, but it seems to be getting good reviews on Steam so far.
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.
This is a recap of the reasons that led me to bite the bullet and rewrite an engine I used to sell and ship commercial projects.
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?
- Also, how feasible is WebXR support?
Polygonjs Maker here.
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.
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.
Sounds good!
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.
> gta san andreas at 32mb ram
I forgot it was such a small budget, it's indeed important to keep in mind how much could be done with little memory. Although I'd argue it was possible with a language that allowed you to control memory very precisely. With javascript garbage collector, I couldn't stand seeing memory ramp up every frame due to threejs internals or my own js code, and every few frame a major GC may or may not lead to a frame drop.
> advanced reprojection for increasing FPS that takes into account the depth buffer
Ah got it. I completely forgot that webxr of course needs to create textures to see through, so it indeed needs to know which graphic api is used. Thank you for the links, I'll have to study them.
Same haha, it’s annoying to have those occasional frame hitches that are predictable but essentially unsolvable with three.js just cause GC causes them. and even the memory heap just feeling like a inscrutable black box and not even going down in size when one’s app is barely supposed to use any.
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?
It's closed to the public at the moment, so I don't think you will be able to find much.
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/
Thanks!
The closest thing would be the book that Ivo Balbaert is writing and that's available here: https://github.com/Ivo-Balbaert/The_Way_to_Jai
this is also good: https://github.com/Jai-Community/Jai-Community-Library/wiki
Thanks!
I got a 406 Not Acceptable because this website doesn't like my browser.
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.
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.
Less hate would be good too.
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.
I know it's imgur.com, and it used to load fine from the UK. I was just making the point that we can all make mistakes and that common tools have edge cases we may not be aware of.
Apologies accepted. And thank you for mentioning the issue, it should now be fixed, so the website should load for you now.