I couldn't disagree more. JavaScript started out that way but today (really the past 6+ years) it's used in identical use cases as Python in addition to being embedded into web browsers.

> If you start trying to include things like file i/o in the base language, you're never going to satisfy all the very different requirements of code running in a browser vs. running on a server.

You don't need to. Provide the basic capabilities that all languages provide, restrict what isn't possible when it's embedded into an environment. Keep it simple.

> If file I/O had been standardised years ago, with API designed by server programmers the browser would be saddled with lousy synchronous stuff that hangs the browser UI, opens up a thousand security issues, and bloats the language with stuff that's pointless for purposes that aren't web browsers or servers.

This is very unfair. What's "years ago"? The asynchronous patterns used in JavaScript date back to well over a decade ago and JavaScript wasn't really used elsewhere until node.js. I'm not sure I would consider any standard APIs as "bloat" either. This just looks like a baseless attack.

> Finally the biggest and best reason to not do this is that, once you put something in javascript (or a web browser for that matter), you can never ever take it out no matter how badly designed it is, without breaking something.

Same goes for all programming languages and their standard libraries. This is why you target specific versions. This is a solved problem.

> Javascript and the web is an open platform. not a closed platform.

So is Python. C++. C#. etc.