6 ms·

I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I

I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program and build it in a way that I could host it somewhere, I'd expect to have to work at it.

3np 5y ago
I think it's more that depending on your point in time, build process and environment, `import` has changed meaning every couple of years. I consider myself having deeper knowledge about JS and node than any other language, having spent more total time in it than anything else (except maybe bash). I have a clearer understanding of what import/require really does in most other languages. The flow-chart complexity and possible outcomes of what `import` really does in JS/TS are certainly greater than anything else I've encountered. (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward)
- cube2222 5y ago
  > (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward) If I understand your point correctly, then that's a non-issue since modules are here. In the go.mod file you have the current module name, and all imports of yourself will use the current repository, instead of calling the original. So you fork the repository, but keep the original name in the go.mod file, then you don't have to modify any imports.
  - 3np 5y ago
    Straight-forward these days indeed. https://golang.org/doc/modules/managing-dependencies#unpublished https://golang.org/doc/modules/managing-dependencies#unpubli... I still find the whole gopath/gomodules thing unfortunate but it is what it is at this point (and frankly that’s a bit out scope since we’re talking imports here.. if we’re talking about the state of packaging then JS absolutely has competition; e.g. https://xkcd.com/1987/ https://xkcd.com/1987/)
smt88 5y ago
Import in JavaScript is significantly more varied and complex than import in any other language I know about. There are multiple historical module systems, various official and unofficial syntaxes, and also the require keyword. It is an absolute mess. I don't know anyone who understands all of the various flavors.
- morelisp 5y ago
  On top of this, a lot of the tooling is just shit. I don't just mean it makes design decisions I disagree with (which is also true of e.g. Maven, or Bundler) or that they're lacking in niceties (e.g. every C development workflow), I mean it's just absolutely poorly implemented CADT-except-they're-actually-25-and-overcapitalized trash. Yarn blew NPM away on speed with more features and nicer developer workflow. Webpack is on major version 5 and still everyone just uses CRA rather than try to configure it by hand, but then nobody really knows how to debug CRA if something breaks. The entire babel stack is ridiculous. The dominant tools have just been so awful, for so long.
  - handrous 5y ago
    > Yarn blew NPM away on speed with more features and nicer developer workflow. I dunno if it's still true, but for years into people saying "LOL use yarn, it's a better replacement for NPM" it was still really easy to find packages that broke under Yarn because it lacked some feature or other, or was skipping some obviously-a-good-idea sanity check that NPM did and so crashed rather than proceeding after adjusting its approach, or to venture slightly off the happy path of doing "yarn install" and running into features that yarn didn't support, but NPM did. A venture into the issue tracker in that time period was enlightening, and I don't just mean the sheer count, but digging into some of the issues and why they were happening. [EDIT] in fact, in the agency I was at at the time, a kind of joke developed that a project wasn't fully underway until you'd been forced to replace Yarn with NPM.
- KptMarchewa 5y ago
  Python?
mkl 5y ago
It's holding JavaScript to its own higher standard: <script src="..."></script> is dead simple, and trivial to understand and get working. NPM, import, etc. seem mindbogglingly complex in comparison, with an enormous number of ways to do each thing, most of which require at least one build step <script> just doesn't, and enormous numbers of third party dependencies, and if you go away for a few months and come back, there are good odds things will be different and broken. Like Julia, I don't understand JS build systems and packaging etc., which no doubt contributes to the above experience, but I'm comparing to <script>, whose simplicity is almost unbeatable.
- hobofan 5y ago
  > It's holding JavaScript to its own higher standard: <script src="..."></script> is dead simple, and trivial to understand and get working. The most simple example is almost never a representative example that can be used as a standard to hold the whole language to. In the same vein, one could say: "See how easy it is to build a C program with `gcc main.c`? Why should I have to figure out how to use make?". And the answer is simple: Most projects that go beyond a toy example have much more elaborate requirements(/whishes), like "I'd like to reuse code that another person has written in the past so I don't have to do it".
  - throwaway894345 5y ago
    C also lacks a sane build system, so if you’re trying to make the point that JS isn’t so bad, comparing it with C isn’t the way to go. Consider that no other language needs a bundler with all of the weird stuff it supports. You might argue that it’s good that JS supports all of these things and that’s fine, but what you’re really saying is complexity is good which is also fine but incompatible with the “JS is no more complex than other languages” position.
    - elevader 5y ago
      Most languages also don't really have to worry about shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over that doesn't actually support the code you wrote (There are still people running old IE versions and loosing 1% of customers might be really costly at scale). I'm not saying that the current ecosystem isn't an overly complex mess but it does actually solve some problems.
mpolichette 5y ago
This ^ I feel like JS gets thrown under the bus in discussions, but no body talks about arcane file structures in Java or implicit pathing lookups which have the same kind of "historical path dependence" to why they exist as JS has for require/import. All languages have their warts and 99% of the time they're all doing the same thing just in slightly different ways.

3np 5y ago

I think it's more that depending on your point in time, build process and environment, `import` has changed meaning every couple of years. I consider myself having deeper knowledge about JS and node than any other language, having spent more total time in it than anything else (except maybe bash). I have a clearer understanding of what import/require really does in most other languages. The flow-chart complexity and possible outcomes of what `import` really does in JS/TS are certainly greater than anything else I've encountered. (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward)

cube2222 5y ago
> (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward) If I understand your point correctly, then that's a non-issue since modules are here. In the go.mod file you have the current module name, and all imports of yourself will use the current repository, instead of calling the original. So you fork the repository, but keep the original name in the go.mod file, then you don't have to modify any imports.
- 3np 5y ago
  Straight-forward these days indeed. https://golang.org/doc/modules/managing-dependencies#unpublished https://golang.org/doc/modules/managing-dependencies#unpubli... I still find the whole gopath/gomodules thing unfortunate but it is what it is at this point (and frankly that’s a bit out scope since we’re talking imports here.. if we’re talking about the state of packaging then JS absolutely has competition; e.g. https://xkcd.com/1987/ https://xkcd.com/1987/)

smt88 5y ago

Import in JavaScript is significantly more varied and complex than import in any other language I know about. There are multiple historical module systems, various official and unofficial syntaxes, and also the require keyword. It is an absolute mess. I don't know anyone who understands all of the various flavors.

morelisp 5y ago
On top of this, a lot of the tooling is just shit. I don't just mean it makes design decisions I disagree with (which is also true of e.g. Maven, or Bundler) or that they're lacking in niceties (e.g. every C development workflow), I mean it's just absolutely poorly implemented CADT-except-they're-actually-25-and-overcapitalized trash. Yarn blew NPM away on speed with more features and nicer developer workflow. Webpack is on major version 5 and still everyone just uses CRA rather than try to configure it by hand, but then nobody really knows how to debug CRA if something breaks. The entire babel stack is ridiculous. The dominant tools have just been so awful, for so long.
- handrous 5y ago
  > Yarn blew NPM away on speed with more features and nicer developer workflow. I dunno if it's still true, but for years into people saying "LOL use yarn, it's a better replacement for NPM" it was still really easy to find packages that broke under Yarn because it lacked some feature or other, or was skipping some obviously-a-good-idea sanity check that NPM did and so crashed rather than proceeding after adjusting its approach, or to venture slightly off the happy path of doing "yarn install" and running into features that yarn didn't support, but NPM did. A venture into the issue tracker in that time period was enlightening, and I don't just mean the sheer count, but digging into some of the issues and why they were happening. [EDIT] in fact, in the agency I was at at the time, a kind of joke developed that a project wasn't fully underway until you'd been forced to replace Yarn with NPM.
KptMarchewa 5y ago
Python?

mkl 5y ago

It's holding JavaScript to its own higher standard: <script src="..."></script> is dead simple, and trivial to understand and get working. NPM, import, etc. seem mindbogglingly complex in comparison, with an enormous number of ways to do each thing, most of which require at least one build step <script> just doesn't, and enormous numbers of third party dependencies, and if you go away for a few months and come back, there are good odds things will be different and broken. Like Julia, I don't understand JS build systems and packaging etc., which no doubt contributes to the above experience, but I'm comparing to <script>, whose simplicity is almost unbeatable.

hobofan 5y ago
> It's holding JavaScript to its own higher standard: <script src="..."></script> is dead simple, and trivial to understand and get working. The most simple example is almost never a representative example that can be used as a standard to hold the whole language to. In the same vein, one could say: "See how easy it is to build a C program with `gcc main.c`? Why should I have to figure out how to use make?". And the answer is simple: Most projects that go beyond a toy example have much more elaborate requirements(/whishes), like "I'd like to reuse code that another person has written in the past so I don't have to do it".
- throwaway894345 5y ago
  C also lacks a sane build system, so if you’re trying to make the point that JS isn’t so bad, comparing it with C isn’t the way to go. Consider that no other language needs a bundler with all of the weird stuff it supports. You might argue that it’s good that JS supports all of these things and that’s fine, but what you’re really saying is complexity is good which is also fine but incompatible with the “JS is no more complex than other languages” position.
  - elevader 5y ago
    Most languages also don't really have to worry about shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over that doesn't actually support the code you wrote (There are still people running old IE versions and loosing 1% of customers might be really costly at scale). I'm not saying that the current ecosystem isn't an overly complex mess but it does actually solve some problems.

mpolichette 5y ago

This ^ I feel like JS gets thrown under the bus in discussions, but no body talks about arcane file structures in Java or implicit pathing lookups which have the same kind of "historical path dependence" to why they exist as JS has for require/import. All languages have their warts and 99% of the time they're all doing the same thing just in slightly different ways.