5 ms·

Understandable frustrations but without a comparison to other major languages in the same domain its a bit moot. Is it just the Node ecosystem that has these t

Understandable frustrations but without a comparison to other major languages in the same domain its a bit moot. Is it just the Node ecosystem that has these types of problems?

antonvs 4y ago
In my experience, Node is worse than any of Java, Rust, or Haskell. I think a couple of reasons for that is that it's untyped, and not compiled. Both of those mean that basic correctness checking ends up happening on the user's machine, rather than the developer's.
- jitl 4y ago
  > not compiled Ironic you say this, since the whole blogpost is complaining about setting up compiler pipeline to target NodeJS.
  - antonvs 4y ago
    That fits in perfectly with what I was saying, I just wasn't precise enough. The issue is that Node.js source code is not compiled to a target language like native code or bytecode. As such, there's no package repository from which you can retrieve compiled packages - you're forced to deal with the same build process as the developer of the package. If that weren't the case, the compiler pipeline that the post is complaining about would be eliminated for package users. In fact, the author of this package could have avoided some of his pain by publishing a library with the compiled JS code, which would eliminate all the config of higher layers. But the JS ecosystem doesn't support making that distinction, there's no source package repo vs. compiled package repo (afaik - I don't use it more than I have to, because it all sucks.)
    - wonnage 4y ago
      I think you misunderstand... you don't have to worry about building packages at all (excluding some edge cases like native C++ extensions) when you install stuff from npm.
    - Macha 4y ago
      Note the convention in npm of using a dist/x.min.js or x.dist.js to use NPM to ship prebuilt modules (usually UMD as the ES6 world still mostly just expects you to use a build took, but e.g. Vue at one point at least had prebuilt es6 modules too).
- reirob 4y ago
  Ironically the existence of NodeJS is somewhat related to Haskell, as Stephen Diehl mentions in [1]: > As a funny historical quirk, back in 2011 there was an interview with Ryan Dahl, the creator of NodeJS, who mentioned that the perceived difficulty in writing a new IO manager for GHC was a factor in the development of a new language called NodeJS. When asked why he chose Javascript, for the project, he replied: >> Originally I didn’t. I had several failed private projects doing the same on C, Lua, and Haskell. Haskell is pretty ideal but I’m not smart enough to hack the GHC. The interview itself is in [2]. [1]: https://www.stephendiehl.com/posts/decade.html https://www.stephendiehl.com/posts/decade.html [2]: https://www.bizjournals.com/boston/inno/stories/news/2011/01/31/nodejs-interview-4-questions-with-creator-ryan.html https://www.bizjournals.com/boston/inno/stories/news/2011/01...
josteink 4y ago
Node succeeded by “simply” being plain JS on V8 with a really small standard library. Easy! No nonsense! Everyone knows this already! Unfortunately that left everything else up to the community to solve: establishing a “good” standard library, building, debugging, packaging, bundling, dealing with the Node/Browser duality in a meaningful way, creating usable network frameworks, UI frameworks and surely much more. And they’ve all ended up reinventing that 100 times (like the curse of lisp) in 200 different ways, all recursively based on Node, while standing on the shoulder of non-giants trying to solve one of the other problems mentioned above, possibly standing on the shoulder of someone else who has already tried to solve what you are trying to solve now. Calling it a clusterfuck probably isn’t sufficient, yet at the same time it seems to work, so it’s simultaneously a sort of modern day miracle. Disclaimer: have set up quite a few node build-pipelines.
- yulaow 4y ago
  Of npm (the online database of packages) I hate the fact they never forced a clear distinction between package meant to be used only in the backend with node, package meant to be used only on the fe inside a browser, and package which can be used in both. I mean just having a flag for that would be useful, simple and solve a lot of headaches
  - andrew_ 4y ago
    The beauty is that those distinctions don't exist. There are no limitations. There are also no guardrails or training wheels.
    - wizofaus 4y ago
      In what case would an npm package for talking to an external database be actually useful for a frontend project? I mean, yes, if you're only ever running the tool inside a LAN where that access exists, I suppose it's conceivable... And plenty of frontend packages that rely on storing state in the browser's window object (Redux etc.) would presumably be a bad idea to use for most backend projects, but no doubt somebody's found a way to make it work. I suppose I'm not disagreeing with you, but the GP kinda has a point too.
vbezhenar 4y ago
I don't think that Java would be different if one would want to replicate all features that author felt necessary. I'll speak for Maven as it's the most popular build tool and most straightforward. With gradle it would be worse. To build two configurations you ideally want at least two modules. So multi-module projects. Weak point for maven. Doable, but with lots of quirks. Last time I checked, to publish Java library, you would need to GPG sign it. This fact alone is a serious stuff. Pushing library to internal repository is easier. Tooling in maven is terrible. Plugins are archaic, some of those seen last commits 10 years ago. I don't even know which tools to autoformat Java code are popular nowadays. I think that most people just use their Idea to format before commit with shared style or something like that. I think it's good enough. Github bot to update dependencies and deploying demo site - I don't know, never did that, but I couldn't imagine it being easier with Java either. So Java tooling has its share of quirks. Most sane tooling I ever saw was for go, as long as you're ready to adjust your expectations and requirements to happy path. What's unique for node is huge numbers of tooling attempts. Java has Ant, Maven, Gradle. I don't think I've ever heard about anything else. Bazel may be. Well, may be Makefiles for some old beards. JavaScript guys just can't stop trying to invent new tools. And this fragments ecosystem and user base. I don't know why is that. I've never heard of alternative Rust build system, for example.
- Zardoz84 4y ago
  You know that maven have profiles that are tool to use when you need different configurations, not ?
- kaba0 4y ago
  > So multi-module projects. Weak point for maven But not for gradle. > Last time I checked, to publish Java library, you would need to GPG sign it. This fact alone is a serious stuff Why is it a problem? This is partly the reason why the Java ecosystem wasn’t hit by all the malicious package fiasco. > Github bot to update dependencies and deploying demo site Never felt a need for this, but contrary to your misrepresentation, even maven plugins have a healthy ecosystem and being part of the 3rd biggest language, I would be honestly surprised if no such plugin would exist.
ActorNightly 4y ago
Its a fundamental issue with JS and DOM. Its understandable that there needs to be a need to manipulate elements on the webpage, but the issue is that with JS, you can basically create the webpage programmatically from the ground up, but you are doing it through essentially concatenating text into html/css. Even worse, JS can actually modify itself. You can take defined functions that have definite common behavior. and overwrite them to arbitrary ones. The equivalent to a low level language like C would be writing your code with half C, half custom macros that are #defined at random places in the code libraries that you pulled in that change core C instructions, and instead of regular C code you are concatenating strings with assembly instructions that would then be put into a file and ran. No other language that I know of allows for this.

Understandable frustrations but without a comparison to other major languages in the same domain its a bit moot. Is it just the Node ecosystem that has these types of problems?

antonvs 4y ago

In my experience, Node is worse than any of Java, Rust, or Haskell. I think a couple of reasons for that is that it's untyped, and not compiled. Both of those mean that basic correctness checking ends up happening on the user's machine, rather than the developer's.

jitl 4y ago
> not compiled Ironic you say this, since the whole blogpost is complaining about setting up compiler pipeline to target NodeJS.
- antonvs 4y ago
  That fits in perfectly with what I was saying, I just wasn't precise enough. The issue is that Node.js source code is not compiled to a target language like native code or bytecode. As such, there's no package repository from which you can retrieve compiled packages - you're forced to deal with the same build process as the developer of the package. If that weren't the case, the compiler pipeline that the post is complaining about would be eliminated for package users. In fact, the author of this package could have avoided some of his pain by publishing a library with the compiled JS code, which would eliminate all the config of higher layers. But the JS ecosystem doesn't support making that distinction, there's no source package repo vs. compiled package repo (afaik - I don't use it more than I have to, because it all sucks.)
  - wonnage 4y ago
    I think you misunderstand... you don't have to worry about building packages at all (excluding some edge cases like native C++ extensions) when you install stuff from npm.
  - Macha 4y ago
    Note the convention in npm of using a dist/x.min.js or x.dist.js to use NPM to ship prebuilt modules (usually UMD as the ES6 world still mostly just expects you to use a build took, but e.g. Vue at one point at least had prebuilt es6 modules too).
reirob 4y ago
Ironically the existence of NodeJS is somewhat related to Haskell, as Stephen Diehl mentions in [1]: > As a funny historical quirk, back in 2011 there was an interview with Ryan Dahl, the creator of NodeJS, who mentioned that the perceived difficulty in writing a new IO manager for GHC was a factor in the development of a new language called NodeJS. When asked why he chose Javascript, for the project, he replied: >> Originally I didn’t. I had several failed private projects doing the same on C, Lua, and Haskell. Haskell is pretty ideal but I’m not smart enough to hack the GHC. The interview itself is in [2]. [1]: https://www.stephendiehl.com/posts/decade.html https://www.stephendiehl.com/posts/decade.html [2]: https://www.bizjournals.com/boston/inno/stories/news/2011/01/31/nodejs-interview-4-questions-with-creator-ryan.html https://www.bizjournals.com/boston/inno/stories/news/2011/01...

josteink 4y ago

Node succeeded by “simply” being plain JS on V8 with a really small standard library. Easy! No nonsense! Everyone knows this already! Unfortunately that left everything else up to the community to solve: establishing a “good” standard library, building, debugging, packaging, bundling, dealing with the Node/Browser duality in a meaningful way, creating usable network frameworks, UI frameworks and surely much more. And they’ve all ended up reinventing that 100 times (like the curse of lisp) in 200 different ways, all recursively based on Node, while standing on the shoulder of non-giants trying to solve one of the other problems mentioned above, possibly standing on the shoulder of someone else who has already tried to solve what you are trying to solve now. Calling it a clusterfuck probably isn’t sufficient, yet at the same time it seems to work, so it’s simultaneously a sort of modern day miracle. Disclaimer: have set up quite a few node build-pipelines.

yulaow 4y ago
Of npm (the online database of packages) I hate the fact they never forced a clear distinction between package meant to be used only in the backend with node, package meant to be used only on the fe inside a browser, and package which can be used in both. I mean just having a flag for that would be useful, simple and solve a lot of headaches
- andrew_ 4y ago
  The beauty is that those distinctions don't exist. There are no limitations. There are also no guardrails or training wheels.
  - wizofaus 4y ago
    In what case would an npm package for talking to an external database be actually useful for a frontend project? I mean, yes, if you're only ever running the tool inside a LAN where that access exists, I suppose it's conceivable... And plenty of frontend packages that rely on storing state in the browser's window object (Redux etc.) would presumably be a bad idea to use for most backend projects, but no doubt somebody's found a way to make it work. I suppose I'm not disagreeing with you, but the GP kinda has a point too.

vbezhenar 4y ago

I don't think that Java would be different if one would want to replicate all features that author felt necessary. I'll speak for Maven as it's the most popular build tool and most straightforward. With gradle it would be worse. To build two configurations you ideally want at least two modules. So multi-module projects. Weak point for maven. Doable, but with lots of quirks. Last time I checked, to publish Java library, you would need to GPG sign it. This fact alone is a serious stuff. Pushing library to internal repository is easier. Tooling in maven is terrible. Plugins are archaic, some of those seen last commits 10 years ago. I don't even know which tools to autoformat Java code are popular nowadays. I think that most people just use their Idea to format before commit with shared style or something like that. I think it's good enough. Github bot to update dependencies and deploying demo site - I don't know, never did that, but I couldn't imagine it being easier with Java either. So Java tooling has its share of quirks. Most sane tooling I ever saw was for go, as long as you're ready to adjust your expectations and requirements to happy path. What's unique for node is huge numbers of tooling attempts. Java has Ant, Maven, Gradle. I don't think I've ever heard about anything else. Bazel may be. Well, may be Makefiles for some old beards. JavaScript guys just can't stop trying to invent new tools. And this fragments ecosystem and user base. I don't know why is that. I've never heard of alternative Rust build system, for example.

Zardoz84 4y ago
You know that maven have profiles that are tool to use when you need different configurations, not ?
kaba0 4y ago
> So multi-module projects. Weak point for maven But not for gradle. > Last time I checked, to publish Java library, you would need to GPG sign it. This fact alone is a serious stuff Why is it a problem? This is partly the reason why the Java ecosystem wasn’t hit by all the malicious package fiasco. > Github bot to update dependencies and deploying demo site Never felt a need for this, but contrary to your misrepresentation, even maven plugins have a healthy ecosystem and being part of the 3rd biggest language, I would be honestly surprised if no such plugin would exist.

ActorNightly 4y ago

Its a fundamental issue with JS and DOM. Its understandable that there needs to be a need to manipulate elements on the webpage, but the issue is that with JS, you can basically create the webpage programmatically from the ground up, but you are doing it through essentially concatenating text into html/css. Even worse, JS can actually modify itself. You can take defined functions that have definite common behavior. and overwrite them to arbitrary ones. The equivalent to a low level language like C would be writing your code with half C, half custom macros that are #defined at random places in the code libraries that you pulled in that change core C instructions, and instead of regular C code you are concatenating strings with assembly instructions that would then be put into a file and ran. No other language that I know of allows for this.