7 ms·

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, pack

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.

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.