> 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.
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.
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".
With Node, not only is it optional, it's a third party dependency.
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
Really? That's your defense of both not having type-checking AND not having optional type-checking builtin?
All common languages implementations, other than Node with JS, either have type-checking or have optional type-checking builtin.
Node and JS stand alone by having no type-checking, nor having optional type-checking builtin.
Node is uniquely low-quality in this respect.
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.
> Seriously though: modern JS ecosystem is not a "language" or a "framework". It's a kernel.
That's not how it's pitched.
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.
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.
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.
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.
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.
Applications by and large do, but when you're writing a library you want to at least start without the usual bs.
JSDoc for type information works great as a crutch in this initial period.
EDIT: ok, now I recalled that I use Node's built-in test runner for tests. But I still don't have a package.json as well as any dependencies.
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.
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...
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.
You run prettier though? How do you download and run it - it seems to require Node.
But then again, 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
what happens if your project has tens or even hundreds files, how do you get that to client without any sort of bundler?
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’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.
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.
Bundle with packup: https://packup.deno.dev/
It's a critique of the JavaScript ecosystem.
We just covered this.
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.
Where subtree constitutes ~90% or more of the ecosystem.
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.
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)?
> you're expecting me to argue with you
Nope.
I wrote why, and you definitely literally ignored what I wrote.
> Who are you quoting (and what is it even supposed to mean, besides)?
I'm very shortly representing what you wrote. So it's for you to answer what this means.
> Nope
Yup. Otherwise you wouldn't resort to bad analogies.
Anyway. This is going nowhere.
Adieu.
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:
> Yup [you are expecting me to argue with you]