7 ms·

This is yet another case of people saying "JavaScript" when they mean "a bunch of Node ecosystem junk". Right out of the gate: > It’s time for your test. You

by cxr 3y ago

This is yet another case of people saying "JavaScript" when they mean "a bunch of Node ecosystem junk". Right out of the gate: > It’s time for your test. You are sitting in front of a computer. The test is simple: you have to open a package.json file and read it. And it continues in that vein. For all the stuff mentioned, there's actually almost nothing that has anything to do with JS per se.

dfsafklsjv 3y ago
Try writing any JS without a bundler that uses package.json. I mean really, try it. Until ECMA codifies a package manager or bundler in the official specs, package.json is de facto part of JS.
- chrisco255 3y ago
  > opens dev tools > types `console.log("this is impossible without a package.json")` To my astonishment, it worked, without a package.json file. I definitely prefer using npm for any non-trivial front end, but let's be real: JS is an integral part of the web stack. You can even inline JS inside a <script> tag on an HTML file. It's not that hard.
  - floydnoel 3y ago
    I do sometimes wonder how many of the critics have only ever worked on Angular frontends and such. The frontend for my little site https://bongo.to https://bongo.to doesn't use Node or NPM at all. Just a script tag, like you said. It's very simple and easy to use JS this way, and I wish people would learn to do this before learning how to write a SPA in the framework du jour.
    - philipwhiuk 3y ago
      `` You run prettier though? How do you download and run it - it seems to require Node.
      - floydnoel 3y ago
        you can run it with the `npx` command if you didn't want to install it. another way, which is the one I'm using here, is via the VSCode plugin. enabling the "format on save" option with prettier as the default formatter will format any file it can, which is very handy!
- jaggederest 3y ago
  You know we used to write javascript before JSON existed, right? Let alone node and package managers.
- qudat 3y ago
  Deno. Write code in TS. Built in linter and formatter. Bundle with packup: https://packup.deno.dev/ https://packup.deno.dev/
- cxr 3y ago
  > Try writing any JS without a bundler that uses package.json. I have, and I continue to. It's not hard. To give one example: Firefox, a serious desktop application by any measure, was written in JS from the very beginning. (Yes, really. A combination of JS and C++, at least—and, nowadays, Rust, too; not unlike the way that Emacs is written in Lisp, where that means a combination of Lisp around its C core.) That's hundreds of thousands of lines of JS we're talking about, and it predates Node and all of the bundler/package.json stuff that you are implicitly arguing is somehow unavoidable. Firefox is an existence proof that that's not true (and also happens to be a higher quality app than anything I've ever seen the Node community offer as example to serve as testaments to their methodology, including anything to do with Electron, which cribs the same Greenspun, Emacs-style architecture that's behind Firefox). I worked on the JS docs on developer.mozilla.org in the early days of the site. (Also before Node ever existed.) I did this because I wanted people to understand JS. It's a much nicer—and more thoughtfully designed—language than it gets credit for. It pains me, therefore, when I see people refer things as JS when what they should be saying is "stuff associated with the kind of software of dubious quality that developers who decided to rally around NPM have been putting out into the world for the last decade—and more often than not actually goes against the natural grain and spirit of the language".
  - idoubtit 3y ago
    > I have, and I continue to. It's not hard. I also write JavaScript code without NodeJS and package.json. It's not hard when the code is simple. But it doesn't scale. For a complex code, I want a linter, I want automated tests and coverage, I want to split the source code over many files... NodeJS is the standard requirement for all of these. > Firefox, a serious desktop application by any measure, was written in JS from the very beginning. (Yes, really. A combination of JS and C++, at least At the very beginning, this web browser started under the name "Netscape", and JavaScript didn't exist yet. Mozilla forked out of Netscape in 1998, and there was little JS in the source code at this time. > it predates Node and all of the bundler/package.json stuff that you are implicitly arguing is somehow unavoidable. Firefox doesn't use the standard bundlers of the Node ecosystem, but it's because it has its own build systems and bundlers. It's a beast that needs 30GB of disk to compile, with a custom build system written in shell, Perl and mostly Python, with many tests systems (including for "mochitest" JS code). For instance, among the dozen of linters that Firefox uses, there is eslint, which a normal JS project would install through a package.json. > JS. It's a much nicer—and more thoughtfully designed—language than it gets credit for. JS was notoriously designed and implemented in a rush, because Netscape was under pressure from Microsoft. It also suffered from legal constraints that block the adoption of some Java concepts. Once LiveScript/JavaScript was born, its evolution was chaotic since the browsers war prevented any consistent progress of the language. After it settled, Ecmascript did enhance the language at a fast pace, but it cannot fix the many inconsistencies and design flaws.
- irrational 3y ago
  I’ve done it since the mid-1990s. It really isn’t that hard.
- Cyberdog 3y ago
  I’ve been writing JS my entire career and never wrote a package.json file. I’m not sure what tool would even use it. But then again, I’m a happy, sane person who only writes client-side JS.
  - troupo 3y ago
    > I’m a happy, sane person who only writes client-side JS. I've never written backend javascript. I've used and fought all the tools mentioned
  - leshenka 3y ago
    how do you manage large projects? what happens if your project has tens or even hundreds files, how do you get that to client without any sort of bundler?
    - cxr 3y ago
      Here's what the person you're responding to said: > I’ve been writing JS my entire career and never wrote a package.json And you replied: > how do you get that to client without any sort of bundler? Please connect the dots for me.
    - Cyberdog 3y ago
      Why would the project have hundreds of JS files? Usually I might have something like main.js which handles universal page elements like the search bar in a site-wide navbar, then, if necessary, a few this-specific-page.js files which handles elements which are specific to this page or site section. If any libraries are needed, try first to just link them in using CDNJS or the like, so no need to store them locally or bundle them in our own scripts - I know there are downsides to relying on external CDNs for such things but in practice it just works. Easy peasy. But first, I try to avoid using JavaScript in the first place when not strictly necessary. This means server-side rendering as much as possible rather than doing the glacial "load an almost entirely blank page, load giant JS blobs, then load the page content via AJAX and hope that nothing goes wrong in that process, sorry slow connection users, non-standard browser users, and search engine bots" approach which thankfully is finally starting to see some pushback.
- mattlondon 3y ago
  You can use modules directly in the browser and it will load them in fine. You don't need to use a package manager do to that: https://byexample.xyz/javascript/ECMAScript2015/modules/#directly-using-modules-in-html https://byexample.xyz/javascript/ECMAScript2015/modules/#dir... I have never used a package.json file in my 10+ year writing javascript & typescript. We don't have nodejs installed on our workstations or servers. A lot of work has gone into that build chain, and I have no idea what it is doing (apart from something something bazel & monorepo) but it works. At home I use Deno and it is a joy.
qup 3y ago
Right, the ecosystem is not a valid critique of the language, got it.
- deleted 3y ago
  [deleted]
ncr100 3y ago
If that fries your pickle, whenever anybody says JavaScript, I think they really mean ECMAscript.
- Freedom2 3y ago
  [flagged]
  - jrajav 3y ago
    None of these semantics actually exist. Javascript is the language, and it was released as an implementation first, then a standards body worked on a specification for it. For various reasons (bickering, trademark), the specification was called ECMAScript. ECMAScript is the specification for Javascript. That's it. There's nothing clever to be had here, it's just odd historical trivia.
    - deleted 3y ago
      [deleted]
    - simonbw 3y ago
      I'd just like to point out that the parent is a variant on the GNU/Linux copypasta: https://stallman-copypasta.github.io/ https://stallman-copypasta.github.io/
      - zeven7 3y ago
        I'll allow it. Downvote removed
      - floydnoel 3y ago
        [flagged]
  - ncr100 3y ago
    I always thought, inaccurately, that Javascript was simply the 'navigator' object and a few other objects, glued into the namespace. I did not know that it was standardized, though .. duh .. it would have to be I now realize. TY for the interesting comment @Freedom2, it's informative for me.
paulddraper 3y ago
Um yes. It's a critique of the JavaScript ecosystem.
- cxr 3y ago
  > the JavaScript ecosystem We just covered this.
  - paulddraper 3y ago
    What tools/package managers/linters do you consider part of the JavaScript ecosystem?
    - cxr 3y ago
      There's nothing mentioned in the submitted article that isn't part of "the JavaScript ecosystem"—because everything it mentions is the product of the outgrowth of Node, NPM... and that subtree exists within the JS ecosystem. But to narrowly focus on that subtree and say it's "a critique of the JavaScript ecosystem" is like visiting McDonald's and passing off your experience as a meaningful critique of the ritual of ordering food and eating it, or writing an angry blog post about the chicanery of some nincompoop your cousin knows while implying that this is what you should expect when you interact with anyone else named "Steve". It's a shameless generalization that's both stupid and unnecessary. If you have a grievance against The Node Way of software development and you want to air it publicly, then have enough of a sense of awareness that that's what you're doing—and say as much when you do it.
      - troupo 3y ago
        > because everything it mentions is the product of the outgrowth of Node, NPM... and that subtree exists within the JS ecosystem. Where subtree constitutes ~90% or more of the ecosystem.
        cxr 3y ago
        Yeah? Have you measured it? Aside from that, do you have anything meaningful to say about the points actually raised? Let's take your claim as a given. If it were 2003 instead of 2023 and people kept bringing up, say, problems with Windows but refused to speak about them in those terms—instead insisting on framing with a generalization about "computers"—would that have been acceptable on the basis that 90+% of the world is using Windows? It plainly wouldn't have, and that's true for a case where we actually know that we were dealing with numbers of 90% or more, and not just lazy attempts at retorts that are fired from the hip and by a reasonable guess probably won't actually hold up under scrutiny, anyway.
shepherdjerred 3y ago
About what percentage of JavaScript developers don't use NodeJS? You are right that JavaScript !== NodeJS, but the majority of people would understand what the author meant. It wouldn't hurt the author to be a bit more precise, but they aren't really wrong either.
- lelanthran 3y ago
  > About what percentage of JavaScript developers don't use NodeJS? I'm always surprised by developers who prefer to use Node on the backend. I used Node for a small project. Never again. No typing, requiring a couple of dependencies just to get poor, half-assed typing that doesn't really work anyway. Poor dependency management, although this is probably not the fault of the tool, it's the fault of a poor ecosystem dominated by junk. A primitive execution model, requiring hacks around hacks to get around the fact that the execution model is based on single-thread async execution. Speaking of execution, slow execution too. Limited IDE help (due to lack of typing). Difficult debugging tooling. No standardisation of anything. The people using Node know that there's alternatives like Go, and yet they still patch on band-aid after band-aid and engage in drama. Using Node for the backend is a special kind of hell. I don't even like Go all that much, but it's a world of difference having strong static typing, nice dependency management, good tooling, simple debugging, no setup costs. Someone upthread made the point about how they might burn a day just setting up a new Node project. A new Go project might take a few minutes from inception to "hello world".
  - mcluck 3y ago
    Poor typing isn't a Node issue, it's a JavaScript issue. Use TypeScript, install @types/node, and you're ready to go. The rest of what you say is true. Although I actually do enjoy using Node for quick one-off scripts and small dev tools
    - lelanthran 3y ago
      My complaumtnis that typing shouldn't be optional. With Node, not only is it optional, it's a third party dependency.

by cxr 3y ago

dfsafklsjv 3y ago

Try writing any JS without a bundler that uses package.json. I mean really, try it. Until ECMA codifies a package manager or bundler in the official specs, package.json is de facto part of JS.

chrisco255 3y ago
> opens dev tools > types `console.log("this is impossible without a package.json")` To my astonishment, it worked, without a package.json file. I definitely prefer using npm for any non-trivial front end, but let's be real: JS is an integral part of the web stack. You can even inline JS inside a <script> tag on an HTML file. It's not that hard.
- floydnoel 3y ago
  I do sometimes wonder how many of the critics have only ever worked on Angular frontends and such. The frontend for my little site https://bongo.to https://bongo.to doesn't use Node or NPM at all. Just a script tag, like you said. It's very simple and easy to use JS this way, and I wish people would learn to do this before learning how to write a SPA in the framework du jour.
  - philipwhiuk 3y ago
    `` You run prettier though? How do you download and run it - it seems to require Node.
    - floydnoel 3y ago
      you can run it with the `npx` command if you didn't want to install it. another way, which is the one I'm using here, is via the VSCode plugin. enabling the "format on save" option with prettier as the default formatter will format any file it can, which is very handy!
jaggederest 3y ago
You know we used to write javascript before JSON existed, right? Let alone node and package managers.
qudat 3y ago
Deno. Write code in TS. Built in linter and formatter. Bundle with packup: https://packup.deno.dev/ https://packup.deno.dev/
cxr 3y ago
> Try writing any JS without a bundler that uses package.json. I have, and I continue to. It's not hard. To give one example: Firefox, a serious desktop application by any measure, was written in JS from the very beginning. (Yes, really. A combination of JS and C++, at least—and, nowadays, Rust, too; not unlike the way that Emacs is written in Lisp, where that means a combination of Lisp around its C core.) That's hundreds of thousands of lines of JS we're talking about, and it predates Node and all of the bundler/package.json stuff that you are implicitly arguing is somehow unavoidable. Firefox is an existence proof that that's not true (and also happens to be a higher quality app than anything I've ever seen the Node community offer as example to serve as testaments to their methodology, including anything to do with Electron, which cribs the same Greenspun, Emacs-style architecture that's behind Firefox). I worked on the JS docs on developer.mozilla.org in the early days of the site. (Also before Node ever existed.) I did this because I wanted people to understand JS. It's a much nicer—and more thoughtfully designed—language than it gets credit for. It pains me, therefore, when I see people refer things as JS when what they should be saying is "stuff associated with the kind of software of dubious quality that developers who decided to rally around NPM have been putting out into the world for the last decade—and more often than not actually goes against the natural grain and spirit of the language".
- idoubtit 3y ago
  > I have, and I continue to. It's not hard. I also write JavaScript code without NodeJS and package.json. It's not hard when the code is simple. But it doesn't scale. For a complex code, I want a linter, I want automated tests and coverage, I want to split the source code over many files... NodeJS is the standard requirement for all of these. > Firefox, a serious desktop application by any measure, was written in JS from the very beginning. (Yes, really. A combination of JS and C++, at least At the very beginning, this web browser started under the name "Netscape", and JavaScript didn't exist yet. Mozilla forked out of Netscape in 1998, and there was little JS in the source code at this time. > it predates Node and all of the bundler/package.json stuff that you are implicitly arguing is somehow unavoidable. Firefox doesn't use the standard bundlers of the Node ecosystem, but it's because it has its own build systems and bundlers. It's a beast that needs 30GB of disk to compile, with a custom build system written in shell, Perl and mostly Python, with many tests systems (including for "mochitest" JS code). For instance, among the dozen of linters that Firefox uses, there is eslint, which a normal JS project would install through a package.json. > JS. It's a much nicer—and more thoughtfully designed—language than it gets credit for. JS was notoriously designed and implemented in a rush, because Netscape was under pressure from Microsoft. It also suffered from legal constraints that block the adoption of some Java concepts. Once LiveScript/JavaScript was born, its evolution was chaotic since the browsers war prevented any consistent progress of the language. After it settled, Ecmascript did enhance the language at a fast pace, but it cannot fix the many inconsistencies and design flaws.
irrational 3y ago
I’ve done it since the mid-1990s. It really isn’t that hard.
Cyberdog 3y ago
I’ve been writing JS my entire career and never wrote a package.json file. I’m not sure what tool would even use it. But then again, I’m a happy, sane person who only writes client-side JS.
- troupo 3y ago
  > I’m a happy, sane person who only writes client-side JS. I've never written backend javascript. I've used and fought all the tools mentioned
- leshenka 3y ago
  how do you manage large projects? what happens if your project has tens or even hundreds files, how do you get that to client without any sort of bundler?
  - cxr 3y ago
    Here's what the person you're responding to said: > I’ve been writing JS my entire career and never wrote a package.json And you replied: > how do you get that to client without any sort of bundler? Please connect the dots for me.
  - Cyberdog 3y ago
    Why would the project have hundreds of JS files? Usually I might have something like main.js which handles universal page elements like the search bar in a site-wide navbar, then, if necessary, a few this-specific-page.js files which handles elements which are specific to this page or site section. If any libraries are needed, try first to just link them in using CDNJS or the like, so no need to store them locally or bundle them in our own scripts - I know there are downsides to relying on external CDNs for such things but in practice it just works. Easy peasy. But first, I try to avoid using JavaScript in the first place when not strictly necessary. This means server-side rendering as much as possible rather than doing the glacial "load an almost entirely blank page, load giant JS blobs, then load the page content via AJAX and hope that nothing goes wrong in that process, sorry slow connection users, non-standard browser users, and search engine bots" approach which thankfully is finally starting to see some pushback.
mattlondon 3y ago
You can use modules directly in the browser and it will load them in fine. You don't need to use a package manager do to that: https://byexample.xyz/javascript/ECMAScript2015/modules/#directly-using-modules-in-html https://byexample.xyz/javascript/ECMAScript2015/modules/#dir... I have never used a package.json file in my 10+ year writing javascript & typescript. We don't have nodejs installed on our workstations or servers. A lot of work has gone into that build chain, and I have no idea what it is doing (apart from something something bazel & monorepo) but it works. At home I use Deno and it is a joy.

qup 3y ago

Right, the ecosystem is not a valid critique of the language, got it.

deleted 3y ago
[deleted]

ncr100 3y ago

If that fries your pickle, whenever anybody says JavaScript, I think they really mean ECMAscript.

Freedom2 3y ago
[flagged]
- jrajav 3y ago
  None of these semantics actually exist. Javascript is the language, and it was released as an implementation first, then a standards body worked on a specification for it. For various reasons (bickering, trademark), the specification was called ECMAScript. ECMAScript is the specification for Javascript. That's it. There's nothing clever to be had here, it's just odd historical trivia.
  - deleted 3y ago
    [deleted]
  - simonbw 3y ago
    I'd just like to point out that the parent is a variant on the GNU/Linux copypasta: https://stallman-copypasta.github.io/ https://stallman-copypasta.github.io/
    - zeven7 3y ago
      I'll allow it. Downvote removed
    - floydnoel 3y ago
      [flagged]
- ncr100 3y ago
  I always thought, inaccurately, that Javascript was simply the 'navigator' object and a few other objects, glued into the namespace. I did not know that it was standardized, though .. duh .. it would have to be I now realize. TY for the interesting comment @Freedom2, it's informative for me.

paulddraper 3y ago

Um yes. It's a critique of the JavaScript ecosystem.

cxr 3y ago
> the JavaScript ecosystem We just covered this.
- paulddraper 3y ago
  What tools/package managers/linters do you consider part of the JavaScript ecosystem?
  - cxr 3y ago
    There's nothing mentioned in the submitted article that isn't part of "the JavaScript ecosystem"—because everything it mentions is the product of the outgrowth of Node, NPM... and that subtree exists within the JS ecosystem. But to narrowly focus on that subtree and say it's "a critique of the JavaScript ecosystem" is like visiting McDonald's and passing off your experience as a meaningful critique of the ritual of ordering food and eating it, or writing an angry blog post about the chicanery of some nincompoop your cousin knows while implying that this is what you should expect when you interact with anyone else named "Steve". It's a shameless generalization that's both stupid and unnecessary. If you have a grievance against The Node Way of software development and you want to air it publicly, then have enough of a sense of awareness that that's what you're doing—and say as much when you do it.
    - troupo 3y ago
      > because everything it mentions is the product of the outgrowth of Node, NPM... and that subtree exists within the JS ecosystem. Where subtree constitutes ~90% or more of the ecosystem.
      - cxr 3y ago
        Yeah? Have you measured it? Aside from that, do you have anything meaningful to say about the points actually raised? Let's take your claim as a given. If it were 2003 instead of 2023 and people kept bringing up, say, problems with Windows but refused to speak about them in those terms—instead insisting on framing with a generalization about "computers"—would that have been acceptable on the basis that 90+% of the world is using Windows? It plainly wouldn't have, and that's true for a case where we actually know that we were dealing with numbers of 90% or more, and not just lazy attempts at retorts that are fired from the hip and by a reasonable guess probably won't actually hold up under scrutiny, anyway.

shepherdjerred 3y ago

About what percentage of JavaScript developers don't use NodeJS? You are right that JavaScript !== NodeJS, but the majority of people would understand what the author meant. It wouldn't hurt the author to be a bit more precise, but they aren't really wrong either.

lelanthran 3y ago
> About what percentage of JavaScript developers don't use NodeJS? I'm always surprised by developers who prefer to use Node on the backend. I used Node for a small project. Never again. No typing, requiring a couple of dependencies just to get poor, half-assed typing that doesn't really work anyway. Poor dependency management, although this is probably not the fault of the tool, it's the fault of a poor ecosystem dominated by junk. A primitive execution model, requiring hacks around hacks to get around the fact that the execution model is based on single-thread async execution. Speaking of execution, slow execution too. Limited IDE help (due to lack of typing). Difficult debugging tooling. No standardisation of anything. The people using Node know that there's alternatives like Go, and yet they still patch on band-aid after band-aid and engage in drama. Using Node for the backend is a special kind of hell. I don't even like Go all that much, but it's a world of difference having strong static typing, nice dependency management, good tooling, simple debugging, no setup costs. Someone upthread made the point about how they might burn a day just setting up a new Node project. A new Go project might take a few minutes from inception to "hello world".
- mcluck 3y ago
  Poor typing isn't a Node issue, it's a JavaScript issue. Use TypeScript, install @types/node, and you're ready to go. The rest of what you say is true. Although I actually do enjoy using Node for quick one-off scripts and small dev tools
  - lelanthran 3y ago
    My complaumtnis that typing shouldn't be optional. With Node, not only is it optional, it's a third party dependency.