I do not, but again - I think "I should be able to run any version of a language in any place" is not related to "it is strangely hard to run a given Javascript file."
I actually think Lua is a great example for comparison that illustrates the point! Different Luas support different features, but the basics (import statements, etc) are syntactically valid (and singular) in all of them. If you try to import a library that doesn't exist in the version you've embedded, you will get an import error. In Javascript - there are multiple import systems for different ecosystems. Getting an import error might mean you need to install the library, it might mean you're using the wrong convention, it might mean that the version of the library has a compilation error....etc. Javascript does not really help you resolve this.
What this means is that there's a clean separation between environment and language. If your Lua deploy supports all the features your script uses, you are good - there are no "families" of Lua script that use different conventions for importing libraries or interop or whatever. A given piece of Javascript, however, has an arbitrary number of deployment-specific setup actions that require pretty advanced ecosystem knowledge to identify.
Like, look back at the errors listed in the article. There's nothing "wrong" with the restrictions, but the language ecosystem does an unusually bad job of helping you understand and navigate them. Like, you can have two or three different import mechanisms for different environments...but if you want to do that you should be more helpful in pointing out when you're using the wrong one.
console.log("Hello, World")
There's absolutely nothing to stop you or anyone else from writing a JS file, importing it into an HTML file, and hosting both on GitHub pages. With ES modules you can now split your code into different files that import each other, and it all just works. No build step, no webpack, just JS files behind a server of some kind.Meanwhile, if you're interested in using someone else's code, the CDNs are all still there. Vue, JQuery, lodash, and many other libraries are available for import directly into your HTML file.
A lot of people in this thread are conflating "all the tutorials tell beginners to do things the hard way" with "JavaScript is now a harder language to get started with than it once was".
Javascript is deployed in many different environments and you need to learn not just how to include a library in each environment, but also how to interact with that library. Also unlike C or other languages - Javascript has a hard time warning you about when you've imported something the wrong way. C can at least tell you "this does not link" (so it was found but is binary incompatible) - in my experience if you copy and paste a node import line in the browser the browser will just say "this does not make sense to me." C gives more breadcrumbs.
I also think that once you get outside the C-likes, the story is universally better. For all of its packaging flaws, it's easy to get python packages for development.
Every time I want to make something in Javascript I'm frustrated all over again by how I need to know details about the Javascript ecosystem that I have no way of knowing at this stage (like: getting to hello world can require a working knowledge of WebPack). It's just no where near that bad other places.