4 ms·

I agree that the C family has some similar problems but I think you're missing part of what makes Javascript uniquely frustrating. Javascript is deployed in ma

I agree that the C family has some similar problems but I think you're missing part of what makes Javascript uniquely frustrating. 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.

greggman3 4y ago
I get it's frustrating but ... do you expect any Lua to run in every environment Lua is used in? AFAICT no 2 Lua's are alike and nearly ever use of it has it's own APIs and quirks. I have the same issue with C. You can find some C that will run anywhere. You can also find lots of C that is platform specific and unless you're an expert you'll be just as frustrated trying to get it to run on a different platform. Seems the same to me.
- aeturnum 4y ago
  > do you expect any Lua to run in every environment Lua is used in? 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.
lolinder 4y ago
Hello world in JS doesn't require WebPack in any environment. This JS file will run just fine in both the browser, node, deno, whatever: 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".

greggman3 4y ago

I get it's frustrating but ... do you expect any Lua to run in every environment Lua is used in? AFAICT no 2 Lua's are alike and nearly ever use of it has it's own APIs and quirks. I have the same issue with C. You can find some C that will run anywhere. You can also find lots of C that is platform specific and unless you're an expert you'll be just as frustrated trying to get it to run on a different platform. Seems the same to me.

aeturnum 4y ago
> do you expect any Lua to run in every environment Lua is used in? 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.

lolinder 4y ago

Hello world in JS doesn't require WebPack in any environment. This JS file will run just fine in both the browser, node, deno, whatever: 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".