5 ms·
Firefox have also chosen not to implement it, right? Indeed, my impression was that Firefox were far more against the whole thing than Chrome, who did implement
by MrJohz 3y ago
Firefox have also chosen not to implement it, right? Indeed, my impression was that Firefox were far more against the whole thing than Chrome, who did implement TCO but then removed it for various reasons.
My impression is that this is less an issue with any particular implementor, and more with the feature not being fully thought through at the beginning. A lot of the browsers (including the Edge team at the time) ended up running into issues, on top of the UX/explanatory problems. That's why there was the alternative proposal for explicit tail calls, but those didn't go anywhere.
- pjmlp 3y agoFirefox no longer matters, hence why I left it out.
- trashburger 3y agoSpiderMonkey is still used in over 2% of the browser market share, and is used in non-Firefox applications too. I'd say it matters.
- pjmlp 3y agoSadly it doesn't, in many places being so low means the project acceptance matrix for target browsers no longer needs to contemplate Firefox.
- zelphirkalt 3y agoUsually though when people make shit websites or products, needlessly not adhering to browser standards that would easily work in basically all modern browsers, because they cannot be bothered or don't have a clue what they are doing.
- ncruces 3y ago1. Complain about market dominance. 2. Any 2% of the market doesn't matter. 3. …
- hajile 3y agoThey said it was too hard, but now they’re adding it because of wasm, so their objection doesn’t matter.
- kannanvijayan 3y agoI left the spidermonkey team a while back but was there when this issue came up and I was strongly against implementing support for it. For me it wasn’t about it being “too hard” (implementation difficulty wouldn’t have been that bad actually). It was more that it forced the implementation to elide stack frames whenever calls occurred in tail position. That’s a semantic change to program behaviour. And one that messed with the expectations of developers. I would have been fine with some explicit syntax for invoking that behaviour, but it seems the standards process that got it approved never really consulted developers or implementors. Do you know why the standard committee rejected adding explicit syntax for tail returns and instead went the route of declaring that all calls in tail position must lead to stack elision? I never really bothered to find out. Also is spidermonkey now adding TCO to JS because of wasm, or are they adding TCO to wasm?
- pjmlp 3y agoMost likely because FP languages that have as part of the language specification don't have special syntax for it, it just works, and the debuggers are able to provide a good debugging experience. The only FP languages that require explicit syntax, target the JVM, which lacks the support.
- kannanvijayan 3y agoIt wouldn't just work for javascript and the way it's used, though. It modifies semantics in a way that would affect the behaviour of existing programs in production environments. It would break things that currently work, and it would break tooling that currently works. Common tooling for production error tracking (e.g. Sentry) would be greatly affected by such a behavioural change. Functional languages "just work" with those semantics because those expectations were set up ahead of time, and tooling and developer expectations were molded around them. But JS isn't one of those languages. The tooling and developer expectations, and gargantuan amounts of existing code, has been written with the expectation that calls create stack frames. > The only FP languages that require explicit syntax, target the JVM, which lacks the support. Support could be added to the JVM just the same as the JSVM though - via a spec change. And just as with the JSVMs, it would be a semantic change that would alter the behaviour of existing programs in ways that would break existing tooling and make developers lives worse. It's why both of them resist it.