> 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".
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
Again, that's not Node. It's JavaScript. You experience the same typing issues in any environment which runs JS (browser, embedded system, etc.).
If you want a good type system then you need to change languages and treat JavaScript as a compilation target. That's what most "JavaScript" professionals have been doing for years. Install the TypeScript compiler and a single dependency to give you Node-specific types and you're set
All other operating systems implementations have GUI, and Linux doesn't.
Seriously though: modern JS ecosystem is not a "language" or a "framework". It's a kernel. You can choose your own language, whether it's Typescript, Coffescript, Purescript, Clojurescript, Reason or one of it's sublings, Elm, or pure JS. Of course, like with Linux, this can be a good or a bad thing for different users and circumstances: personally, I like Linux, but I don't want to handle all of this complexity on my own desktop.
And just like with Linux, you have to choose your own implementations for everything: testing library, strings, dates, templating library, state management, web server, etc.
If you're comparing the barebones Node and vanilla JS to other languages and frameworks, you're not making a valid comparison. You can't pretend that something is inferior just because it's modular.
> You "two other", right? I've used many that didn't have a GUI.
Good point, however, I don't think it makes the analogy invalid. You can replace "GUI" with "init system" or any other thing that separates OS kernel from a full-fledged OS.
> That's not how it's pitched.
There's truth in it. However, I think that the problem here is that we might have different expectations of what a "language" is. For some, it should be a complete package with all libraries and tools built-in — like go or Python. Racket even comes with it's own standard IDE. For other languages, like C, not even standard library is something expected, it's very basic and it's implementations are platform-specific.
Yes, if you take the basic Node, it will not have Typescript included. And for a developer that comes from a different background modifying your "language/framework" is something so weird and out of the ordinary that you don't really do that often. So you might inclined to judge Node ecosystem by your habits, but that's a mistake.
Just as with leftpad, developers from other ecosystems were in shock to find out how many small dependencies does a typical Node project have — because including a dependency is an expensive thing in their experience! But with Node, it's not. I can build and run a typical Node project with hundreds dependencies ~10 minutes after I clone a repo, but it takes me a few hours to configure the right version of Python, requirements and native C/C++ libraries for any significantly complex Python project that has a lot less.
So, instead of comparing the "type checking" out of the box, compare two reasonably sized projects after a year of active development by 5-10 person teams. And from my personal experience, a modern Typescript project would eliminate a lot more failure conditions at compile time than any other mainstream language.
That's ironic, because as a fullstack developer, I don't want to touch Go exactly because of it's lacking type system and how it manages dependencies.
Typescript has the best type system among modern mainstream languages, and although you're right that Node is not well suited for CPU intensive applications, the most part of backend work is IO bound, where async/await works perfectly — waiting for reply from the bd looks and works much more natural than with Go's primitives.
Typescript type system is both powerful and lacking, and with a syntax that is horrendous to do anything complex. It gets even worse than regex in the "write-only" direction. And you can do black magic but at the same time very basic things are still not possible.
I would argue that the Python type system is actually better because you can build on it with regular Python instead of typescript weirdness and because you can use it at runtime. The fact that typescript does not support any kind of reflection makes it very limited for a script language. Rust type system on the other hand is also limited in refection but it is not a scripting language so it's more acceptable, and at least it integrates very nicely with features such as pattern matching and control float which you don't have in TS.
TS also has a way too complex option list which is becoming nearly as annoying as ESLint to configure, with basic safety disabled by default and rules that are just annoying and add no safety whatsoever in the "strictest" config.
Can you please provide examples of what do you consider "write-only" types? Because so far what you've described is the exact opposite of my experience as a Typescript developer.
As far as reflection goes, I see how it could be useful with other languages with less powerful type systems, for example, to build a deserialiser. But with Typescript's type inference I just never felt the need to reach for a crutch when I can use a proper solution.
> Typescript has the best type system among modern mainstream languages,
I wouldn't call something the best when it's disabled by default, even after considering the fact that it's neither part of the language nor the platform, and needs multiple dependencies in order to run, at which point it has worse type-checking than every other language.
> No typing, requiring a couple of dependencies just to get poor, half-assed typing that doesn't really work anyway.
I'm not sure when this experience was. I've used TypeScript for years. About 5 years back it was okay, but it was very hit-or-miss for a given library to have types.
Today, I haven't had that problem. Every library I use has _great_ types, and many libraries are even written in TypeScript.
Anyway, all I'm saying is that you might want to give it a second change. TypeScript and the ecosystem has greatly improved. I hate working without static typing (Python, JS, and Ruby are pain), but TypeScript is really quite great.
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.
> 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".
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.
> 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.
I have no idea what point you are trying to make here. Firefox—not Netscape—has been a JS-driven app since its very first day of existence. (Netscape Navigator 6.x, which has nothing to do with Netscape of the early-to-mid 90s, is the same way—but that's beside the point: I said Firefox, and that's what we're talking about.)
> 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).
I don't know what Firefox's build system looks like now, but at the time that Node debuted (2009), Firefox 3 was the latest release, with Firefox 4 development underway. It did have (and always had) a pretty gnarly build system made of shell scripts, Perl, autotools, et cetera... the same as almost anything that involved reliably compiling a large project with C/C++ across many distros (not to mention other platforms), which was the entire reason behind it. The use of JavaScript, however, had nothing to do with that; there were no JS bundlers. You brought symbols in scope by adding a script element. You still can.
This is also how WebKit's inspector is written to this day, last I checked (~6 months ago or so).
> JS was notoriously designed and implemented in a rush
Again, no idea what point you're trying to make here. JavaScript was done in a rush. It's also thoughtfully designed—certainly more than it gets credit for—and more than other languages that had more time (and less of an excuse). And it remains pretty nice, popular misconceptions notwithstanding (and not helped by self-loathing/self-sabotaging developers from the GitHub era like the author of the submitted article).
> 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.
Hard to cover this succinctly given how much weird stuff is packed in here.
Hundreds of thousands of lines of code of higher quality (and subject to harsher requirements) than the Node fanclub has ever produced is proof that JS scales.
Testing is a basic engineering concern and common across the industry and across all languages. It's a completely orthogonal issue.
Lint as much as you like if that's what you want. Neither Node nor the Node way of development are in any sense a requirement.
For having source code "split [...] over many files", whether you use Node or not (or follow their fads) is neither here nor there...
> 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.
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 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.
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!
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.
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.
They absolutely do, and I honestly get annoyed when ECMAScript gets misnamed. If you're putting a virtual machine with pseudocode into my browser, I want your applet gone.
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.
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.
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.
> Aside from that, do you have anything meaningful to say about the points actually raised?
You didn't raise points. You went off on a rant by completely dismissing the tongue-in-cheek article about tooling issues in the frontend space as something about "node-only".
All the points the author raised are:
- about frontend aka client-side
- about javascript ecosystem
And this ecosystem is ubiquitous. Much more ubiquitous than "no, this is not frontend, I do client-side and I don't use it".
> 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"
See? This is not a point. This is argument by analogy. You're pretending that this analogy is valid (it isn't) and you're expecting me to argue with you.
I wrote a perfectly lucid response which you ignored completely. Your choosing to ignore it, or to read it as if it means something other than what it does, does not mean that I don't have a point (wat).
> Much more ubiquitous than "no, this is not frontend, I do client-side and I don't use it".
Who are you quoting (and what is it even supposed to mean, besides)?
No, you aren't—and the point at which you are attempting to explain what it is that I really meant or was thinking (explaining me... to me) is the point at which you have stumbled upon a strong indicator that you have lost the plot. Viz:
> 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.