2025 JavaScript subsets for custom embedding use‐cases

WEH 2025 - JavaScript subsets for custom embedding use-cases

• GitHub issue: https://github.com/Igalia/webengineshackfest/issues/48
• URL: https://meet.jit.si/WEH2025-JS-embedding

Talk about possible subsets of JS, that would "break" existing code but might be a good tradeoff for some environments.

Aapo's proposals:

• No Array holes and indexes descriptors

Justin: Deno has a lot of things that are not used. If you ask anyone in the room people might come up with many things that can be removed. But how much is the value to use a non-standard subset. For example if I use React does that mean I need to use a version of React? Would that be constrained to people who don't use anything from the ecosystem? At that point why not just remove them from the language?

Aapo: my understanding is that browsers will never remove anything. Probably when people create an Array(100) with holes they don't realize they're creating a security risk.

Justin: What about a mode with warnings? Andreu: How about just making holey arrays 10x slower (laughs)

Andreu: I noticed if you have a then method on the prototype you could enter into the iteration. What if we don't allow monkey patching prototypes Aapo shows slide about strict objects

Justin: the subset should capture the richness of the Web. Why isn't strict more common? In JSC there are so many paths that are for non-strict mode. Joyee: related to that question, people don't use ESM enough on the Web, because ESM is strict by default

Aapo: delete - TypeScript also disallows checking whether something exists by accessing it. Would throw on Get miss give us anything? Justin: Have you heard about HotJS (HopJS)? If you have sealed classes you can compile AOT. Very good performance.

Joyee: what about just no prototype access? Many new JS developers are no longer even aware of the existence of prototype anymore and just use classes now.

Aapo: how about no return trick from constructor, any one aware of the history of this Joyee: not sure about the history but it might be related to the pattern of construction without new pre ES6 Joyee: implemented the private fields + return from constructor. Thought "who's going to to use this" and got told some framework use this. So maybe not as rare on the framework level.

Aapo: anyone uses setprototype of Joyee: some pre-ES6 code I maintain does it since they can't use extend Andreu: Deno has some code doing this for tests Phillip: Spidermonkey glue code uses this but that might not be the embedded use case

Justin: how difficult would it be to polyfill on top of it? TypeScript is a great example. It can choose the subset it compiles to. But the overhead of the polyfill may be too much. How much wiggle room do we have on embedded devices.

Aapo: language feature flags Justin: how do you ensure compliance? Maybe crash if it's not compliant. Does it need runtime semantics? Aapo: we can say, subset compliant runtimes don't have these globals. Static analysis can find them. It would be weird if it's just a runtime crash. Justin: thinking more about the case where the engine implements it even though the subset doesn't use it. then it is technicaly lying about what it doesn't support. then some code might still get away with using it even though it's in the subset. That fragments the ecosystem. Is there a cheap way for the engines to say, it really doesn't support weakref for real. Aapo: "no use weakref"? ?: are people already doing this feature flag? Joyee: remember the --harmony flags, which once caused issues in ES6 days when individual flags were removed and people ran into tricky bugs. Having multiple feature flags interact with each other can be a challenge. aapo: I think feature flag should be a compile time thing, not runtime.

Phillip: ..said that they imporved performance by .. by removing proxies (?) aapo: I also don't like proxies