It is dominated on the server because Java, C#, Elixir, Erlang have a concurrency and parallelism story and node doesn’t.
For most scripting work it is hard to beat Python even if Python is slow.
Sometimes I think compiler and tools writing for node might be fun (boy the world needs an ISO common logic implementation that isn’t hets and Haskell) but compiler and tools writing in Java is fun too, particularly in JDK 16. (Think ‘Haskell the good parts’.)
> For most scripting work it is hard to beat Python even if Python is slow.
Apropos of nothing...
I find Python to be unreadable. I have a moderate reading issue and Python just looks like random letters to me. I actually wish I could process it as there are some very nice tools that I see people make that use Python.
With Python it is about the ecosystem. Although jupyter is second only to Excel in ‘programming model not fit to purpose’ you can get it done w/ pandas, sci-kit learn, pillow, etc. Maybe I am crazy but I think it is fun writing async clientservers in Python.
> compiler and tools writing in Java is fun too, particularly in JDK 16. (Think ‘Haskell the good parts’.)
I would love a more in-depth exploration about this part of your message, if you have some time. I didn't explore the compiler/tools ecosystem for Java for some time, would love to know the advances it got that prompted your message.
I just like it personally. For one thing you have the solid jvm runtime, ides that work, good performance, etc.
With sealed types, var, and similar features, pattern matching, it is getting better all the time in small ways.
I recently wrote a dsl in Java that lets you write a Java AST , transform it as a tree, write Java source code, compile it. It is not quite as simple as doing the same in LISP and you have to mangle names a little to unerase types, but the IDE helps you find the names.
JavaScript is a language whose flaws are well understood by experienced developers, and those flaws are massive.
I also don't particularly care for "async everything" by default. It makes your program more difficult to reason about. Rather than dealing with concurrency in a subset of your application, you now have to worry about it _everywhere_. There are only a few classes of software where the async-everything approach even makes sense.
Throw in the fact that the ecosystem is an absolute dumpster fire and you have more than enough justification.
Although JS has problems, it did already win so Node.js is useful in that sense. But async everything is nutso and requires lots of gating and checking mechanisms in order to get back to synchronous, imperative behavior which is what you normally want in a scripting language.
The setup/versioning and dependency hell issues of Node are absolutely bonkers. I work on a monrepo of 400,000 lines of code at work and I think most of the Node stuff is "just guessing" when people run it. Secret incantations that don't make any sense and have to be copy/pasted. All of Node is like this.
In what way did it "win"? People use JS because it is in the browser, do you have any data that JS won anywhere except the browser? Pretty sure it isn't even the most popular solution for web backends.
While support for multiple languages was the plan all along (the spec for the script tag mentions "text/tcl" along with javascript and vbscript)[0,1], browser makers never bothered to support other languages when javascript became the popular choice, apart from Microsoft with VBScript and Chrome with Dart, whose languages were vendor specific.
Eventually, people just compiled code written in other languages into Javascript, treating it more as an "assembly language for the web"[2] than a language directly coded in, and the script type attribute was officially deprecated from the script tag in HTML5.
Given how practically all Javascript nowadays is generated by Typescript or other compile-to-js languages, probably a stricter type system, actual integers and doubles (JS only uses floats,) maybe as often mentioned, a bigger standard library.
There probably isn't much benefit to different languages if you're just manipulating the DOM (which is probably why that model failed, having more than one language doing the exact same thing is needless extra complexity) but using the browser as an application runtime opens up the possibility of making any software written in a supported language accessible and executable from a URL.
The "JS as bytecode" model got us surprisingly far, but it was a disgusting hack, and Java applets and Flash had their day in the sun, but Webassembly is probably what's going to make the "multiple scripts in the browser" model eventually feasible.
Thinking about it there are so many angles from which one could approach it.
It could not be required to run the script. For example require the visitor has his own website and have the script interact with specified tools installed there. Or
a very limited language that disables js for security.
It could be a highly readable DSL, for example something to write interpreters in.
Or something narrow like interact with a rich text editor or data visualizations.
Lambda functions are just a back end framework tightly coupled to a cloud service, they go in the web backend bin and aren't their own thing. Javascript might be the most popular there but I doubt lambda functions makes a significant dent in the overall web backend landscape.
>I also don't particularly care for "async everything" by default.
I understand your complaint.
Just to add some historical background, Node.js creator Ryan Dahl deliberately architected it that way. He thought threads to express concurrency had flaws. (Especially for i/o tasks instead of cpu-bound tasks). An excerpt[2]:
>“Node was originally born out of this problem — how can you handle two things at the same time? Non-blocking sockets is one way. Node is more or less the idea, or exploring the idea: what if everything was non-blocking? What if you never waited for any IO to happen?”
It's interesting that around the same time, a JVM-based competitor called Vert.x adopted the same philosophy. An example discussion on HN where some favor async by default:
https://news.ycombinator.com/item?id=3928738
Couldn't agree more on async everything. Been building out a market charting and tracking application and boy oh boy has it been the biggest pain in the ass having a good amount of UI rendering be dependent on async calls.
Wish the UI components would just render regardless of whether or not an async call was finished, rather than have to write conditionals for the components to display based on returned promises, populated states/context... I've grown to really hate react these last few months
If it wasn’t for async everything your web browser would be locked up and unresponsive half the time. It’s one reason why Electron rules the roost…. Look at how often conventions GUI apps go out to lunch.
You know you can do concurrency without async calls? Async isn't a good solution for loading data in a data heavy application, game engines doesn't do it that way and they are the most data heavy applications you can find.
Game engines are not as dependent on the network as web browsers. Usually they do all the disk I/O up front, are designed to drop events if the network goes bad, drop frames instead of hang if deadlines are missed. It’s like your compiler just skips an import if it the disk is slow.
> Game engines are not as dependent on the network as web browsers
You do know that web browsers aren't implemented in Electron either and that they don't use javascript to load the resources of a web page concurrently?
You were talking about why Electron/Javascript/Node.js rules all. I'm not aware of any web browser implemented in those technologies. I know Electron is based on chromium, meaning they used a browser to implement it, but I am talking about the other way around ie implementing a browser in Electron.
Electron embeds a web browser, which is a highly complex asynchronous application which is written in C++ by one of only a handful of super high tech companies. It is notorious that efforts to make web browsers with other runtimes (e.g. Hotjava) have failed.
The web browser is async from top to bottom so it never blocks when loading possibly hundreds of resources that make up a web page. JavaScript is asynchronous so it can be embedded in the web browser, if it wasn’t it could lock the whole thing up.
I looked at what the options were for cross-platform guis written by applications programmers and they were not pretty, had serious warts, and all went out for long lunch breaks.
Pretty sure that browsers loads resources in one dedicated thread just like complicated games do. It is a solid and simple technique to implement in C++, there are many good tools to handle that. That isn't the hard part of making a browser, the hard part is implementing all the different file formats/videos, rendering and scripting engine, security etc.
You’re talking about very simple games here. Open world games are constantly streaming huge amounts of data, much more so than a browser, at much tighter timing limitations.
What more complex games do (simplified) is put file IO on one thread, network IO on another, and use async (worker threads with jobs) for the rest.
Well look at Erlang/Elixir. Async everything is fine if your language is immutable and has preemptable execution.
You just write code, and the system figures out how to break things up.
But that’s a system that was designed from the ground up to be async. In JavaScript it was added after the fact, and you as a programmer have to deliberately annotate your functions to be aware of what is and isn’t async.
"async/await" makes it very easy to reason about async stuff-- async stuff can be done in series, or it can branch off into a pyramid structure of tasks, etc.
I had the unfortunate displeasure of selecting Node for a take home interview. My simple express API was working fine when testing with Insomnia but the test suite was a convoluted pile of crap built from different npm frameworks and plugins. At the end of the time slot I had three failing tests for reasons I couldn’t figure out and and my submission was probably automatically rejected.
Oh well, I learned I never want to touch Node again.
I have a conspiracy, because nodejs is single threaded asynchronous event loop, hence it is easy to temporarily freeze the entire application by mistakenly introduce a tick anywhere in your application that is just too long what it should be, thus the closer you get to a large monolith the more likely it is that your application has reoccurring freezes.
My conspiracy theory is that this phenomenon partly created the need of microservices within the web community and by that creating entire new set of problems that needed to be solved.
Node is hated because programmers are highly opinionated (not in a negative way). Everything with huge usage gets hate, because everything has flaws and trade offs. People get forced to use it at work, sometimes to solve the wrong kinds of problems for it's strengths, which amplifies the dislike. It's the nature of the beast.
A fair point, but don't you think it sidesteps the matter at hand? Never mind that other systems have flaws, too. What are the specific reasons that Node.js itself is hated?
Perl is not a bad language. Neither is PHP. I'm using both. And to be honest - it's all about collaboration. Writing something for myself? Perl. Writing anything which will involve anyone else? PHP.
writing something that you don't mind if you hate after? PHP. Writing something that you don't mind if you hate after AND if you don't mind if you hate yourself after: Perl
I disagree. Python doesn't get anywhere near the amount of hate as Javascript. Ruby never had that level of hate. Go attracts some criticism, but it also has a lot of ardent supporters. I have extremely negative feelings about Java, but when I work on a Java project, I can't assume that everybody working with me feel the same way. Lots of people who work with Java find it tolerable or even pleasant. Javascript is like PHP; when you join a group of people working in it, you can freely shit on the language without worrying that you're going to hurt anybody's feelings, because everybody hates it. Even people who love it, hate it.
As an outsider, I see nodejs differently from js in general. I think nodejs has its flaws, in particular in the ecosystem, but general js is just garbage all the way. I think a lot of people see it this way.
That's interesting. I hate Java and actually like JS. I used to make the same assumption too, that everyone just hated Java and it was easy to hate on.
I used to apply for JS jobs, and the interview would have questions like "What do you dislike about JS?" I couldn't find much to dislike and never got those jobs. Maybe it's a sign of proficiency when you're good enough at a language to hit its limits.
I'd say the other effect is when you join projects built by experienced but non-senior people, it tends to be overengineered. Overengineering shows the ugly side of a language. Everyone assumes that this is normal behaviour for the language, when it's frequently not.
no other language had anywhere near the amount of users who were put onto it, regardless of their tastes. js is ubiquotous, node js highly present.
and unlike these other languages there s not usually one or two ways of doing things. there's so many different frameworks, build tools, countless stacks beyond measure. when someone is force converted onto node they're more likely than not to have poor footing, be unable to make the typical sloe steady grind into proficiency they would with a less diverse language like python or ruby.
Everything has flaws and trade offs, but some things have more flaws than others.
You wouldn't make this statement if to compare bogosort and quicksort, would you?
JavaScript sucks. It isn't the best choice for any problem except where you are forced to use it (the web browser). The only reason we still have it is inertia. PHP is in the same camp.
Programming languages have evolved. We know how to do better now.
I think it is liked quite a bit, but if I had to point out; 1) the ecosystem; it is rotten 2) people think JS is the old JS which had callback hell and other misery: there still is misery but less and with Typescript it is ok. But I think not as many hate it vs like it.
I totally agree with you, most arguments are obsolete at best, and ignorant at worst.
> no threads
Worker threads are a thing since Node v10.
Also, I like the single thread concurrency, it makes state management easier (since there is no race condition).
> node does not have a concurrency and parallelism story
You have sockets, http(s) (even http2), multiprocessing, readline, streams, timers, promises, JSON, etc...
They want String.capitalize()? They would complain about the implementation being bloated because it handles edge cases like other alphabets, etc...
> async makes your program more difficult to reason about
That may have been true with the callback hell before async/await. But now, it's just non-sense.
> the ecosystem is an absolute dumpster fire
Ironically, for an ecosystem based on the philosophy of "Don't reinvent the wheel", there are a lot of packages that does the same thing.
There is the leftpad fiasco, the colorette/nanocolors "scandal", the is-odd/is-even packages, ...
But as I said in this thread, this is not Node's fault, nor npm's fault. This is the developer's fault.
Cargo (rust), Mix (elixir), pip (python), they could all serve such an ecosystem.
It's up to the developer to be careful about his dependency tree. For example, if I need VueJS which depends on a specific library, I'll avoid installing another library doing the same thing.
IMO this argument isn't all or nothing. Sure, popular things are hated but Node is especially eggregious. There is more to it than "its just popular".
In my experience, the entire JS ecosystem does not respect robustness, stability, backwards compatibility, correctness, testability, and learning from other ecosystems. It continues to erode itself with emojis in the package manager, childish schzophrenia of frameworks, complete disregard for proven methodologies and extreme indifference to maintainability.
Java is used everywhere, I'd wager it is nowhere near hated as much as node or JS in general. PHP with all its flaws is also used on the web, much more than any other language except Javascript, it too gets less hate than JS/Node.
Why do you think it is hated? Seems to be one of the most popular backends right now. Personally, I dislike the lack of convention and immature library ecosystem.
Probably the worst thing is that the standard library with Node Javascript is tiny. Therefore, you have to pull in a pile of NPM packages to do pretty much anything. The package ecosystem is rather messy for the same reason - there's a mountain of tiny packages doing a few little things because somebody needed to do just a few things and didn't want to pull in some massive library that does a ton of stuff including the thing they need to do. Which then leads to a lot of bigger and more useful packages having huge dependency trees of tons of little packages, all at poorly-managed versions that usually can't be shared with any other big packages. So a program that needs, say, 3 major packages to do something useful might end up with thousands of dependencies taking up hundreds of megabytes, often with 3+ copies of the same package at different versions.
For example, I have a little webapp that I built with create-react-app with typescript and redux. Very convenient overall admittedly. It's not very big, maybe 1k lines of code total, and 3 fairly minor packages added to do various things. The node_modules folder has over a thousand items in it, and takes up 350MB. The yarn.lock file alone is half a megabyte. Ahem, what the hell? At least the built artifacts are pretty small.
This might be seen as just a problem with create-react-app. But in my experience so far, pretty much everything in the Node world does this. Seriously, has anyone managed to do something useful in the Node world without ending up with a thousand packages?
Small composable packages aren’t a bad thing IMO. It’s nice to pull things together how you want without having to reimplement the same logic multiple times. Just encapsulate smaller bits of useful code into their own mini packages
Like if there’s some string manipulation thing I need, instead of copy pasting some snippet, I can pull in the micro package that already does this
The thing is, many other modern ecosystems have these included. You don't need a pile of dependences because you are guaranteed to have the functionality you need. Of course you will still need modules for more specific things but since the most often used functionality is already there you end up with ten packages, not a hundred or more.
makes sense in some situation but people seems to forget left pad fiasco. And the small package which you say sounds good in theory but what we get is bloated things that depends on multiple semver package. And many developers don't even have a clue whats happening which algorithm it is using and thats fair if you get millions package in nested dependencies.
However in Rust I find these packages managed properly which npm should learn.
I'm going to have to disagree with that. Micropackages may seem nice at first, but they're a nightmare to manage longer-term mostly due to low-skill project management. Many such packages make breaking API changes, sometimes without obeying SemVer standards. Some are effectively abandoned, and don't get updates for regular bugs, security issues, etc. Sometimes the lone developers responsible for them may delete them in a fit of pique (left-pad anyone?). Sometimes they get taken over by malicious entities who might add obvious or subtle malware to it. I'm pretty sure all of these have happened already.
That's not even what's important though. What's important is, how can you ensure that none of these things happen to any of *your* projects dependencies? It's virtually impossible when there's a thousand of them. Are you going to audit that string manipulation micro package when you first add it, and then for every version update from now on, to ensure that nobody slipped some subtle malicious code into it? And do the same for every other micro package in your project, including all of the ones that the big ticket packages depend on?
All of this would be much less relevant if it had a more fully-featured standard library.
Every time you commit, package-lock.json is different. And when it is not, then I have 26 new vulnerabilities to be fixed by “npm audit fix”. I have zero trust in my build being reproducible, or even working one year forward.
> Every time you commit, package-lock.json is different. And when it is not, then I have 26 new vulnerabilities to be fixed by “npm audit fix”. I have zero trust in my build being reproducible, or even working one year forward.
In some of the nodejs projects I've worked, we had allu dependencies with pinned version numbers, and each week we created a ticket to track work on upgrading them. This typically involved a single commit updating package versions and running all tests. More often than not it took no work at all.
If a project just lets their dependencies change randomly and does not invest any work updating them, of course there's bound to be pain and suffering.
If your package-lock changes every commit (I'm guessing this means it changes after every `npm install`) then you might have some issues within the team in terms of consistent npm/node versions, or perhaps with the registry you're using if it isn't the public registry.
In my previous role we constantly ran into issues with the integrity hash changing which was an unfortunate side effect of both the issues I mentioned above, an Artifactory npm registry and inconsistent npm/node versions
TL;DR though, it's not normal for the package-lock to change all the time.
They may not need it now, but they choose this technology for a reason - maybe because they plan to develop it much more in the future. This does not mean they can't criticize its obvious flaws (which are a bit at odds with the "enterprise" part btw).
Usually, when you make a little project, you use the tools you know the best because you don't want to spend time coming up with something from scratch.
Also, it's a safe bet in case the project grows beyond the initial scope. You don't want to spend most of your time refactoring, do you?
Redux alone contributes a lot of boilerplate to state handling. Why is it needed? It has no benefits in small apps, it’s easy to abuse to destroy performance if a future dev isn’t cued in to the way Redux state needs to be normalised, and a React useReducer state handler is trivial to refactor to a Redux one later, if needed.
The same goes for TypeScript—how many interfaces does that app really have? Is it used in strict mode or just to type the most critical things?
I know that ecosystem fairly well, and have found it pretty effective to develop in. Compared to that, we have vanilla JS, which is okay for a thing or two, but awful to make a full SPA in. Or probably like 20 other web UI frameworks, all of which probably do the same thing as far as dependencies and have a learning curve for how to use them.
And what do we mean by "enterprise" here? The issue is the dependency chains and the maintenance issues that causes. If it was really "enterprisey", you'd think they'd do a better job of having a manageable dependency chain.
Can't agree more, after spent 3-4 years with nodejs on and off, I am not going to adopt it for any future projects.
a strong 'stdlib' is a must, no other code will pull in who-knows-what packages hundreds of MB at least. Just like javascript is badly design, so does nodejs.
Any professional java developer will tell you exactly the same thing about java.
Professional java developers use a maven file which is similar to a package.json file. And it lists dozens of dependencies.
Even though java has default collections (so does javascript by the way), most developers also want Apache Commons (which could be compared to lodash)
And by default java has no DI and IOC, so most of them will install Spring Boot. The thing is, spring boot isn't just 1 dependency. There is actually a spring boot initializer website to help developers pick their dependencies. On top of that the names of Spring dependencies change between releases, sometimes they move things around.
And about persistence. In java you would need a JDBC library for ms sql server for instance. However, there are different ms sql server jdbc libraries depending of the version of the database, and depending on the version of your JRE. And in some cases you need additional libraries to add security protocols. (e.g. "bouncy castle")
And then there's JAXB which used to be included in the java framework, but has been removed since JDK8. Talk about backwards compatibility.
And what about portability. If you want to make a setup utility or installer for your software, then often they will include a copy of the Java runtime inside the installer. After all, you can't expect users to have java pre-installed. That does mean, that every installer has a footprint of 400MB+ (~the size of a JRE).
I do a agree with you, but we should also keep in mind that there's a distinction between dependencies and dev dependencies.
Building and bundling for the web platform (where you have multiple browser, environments, users on different versions) is a real challenge and you actually want to have good tooling for this.
With NPM, you just bundle all of the tooling along with the dependencies you need for your actual app.
I think that's still a big improvement over projects where you first had to setup your dev environment in very specific ways just to get started (I remember this could even take days to get right for some projects I worked on).
Although I would really wish for a better standard library, or at least some "core NPM modules" which are officially agreed upon, promoted and security checked as an almost-standard-library.
Clearly you have a very shallow knowledge of the Node/NPM ecosystem. The very thing you mention as a downside is what empowers you to achieve the solution to the problem you want to avoid. Instead of going for the one-keystroke create-react-app, you can cherry-pick the packages you need and use that. Also packages tend to include other non-javascript files. I'd suggest you dive a bit deeper before drawing up wrong conclusions.
Node's tiny stdlib invites the question - which compile-to-JS language has the best standard library? Dart? Clojurescript? Strange how Typescript missed the opportunity to fix this.
Node has a low barrier to entry(JS), and that shows in the quality of the work. If anyone remembers QBasic, it was hated for the same reasons. It's great to grasp core concepts with, but inappropriate to build something like an ERP system. It's a toy, although a powerful one.
I don’t think it’s Node that people don’t like. It’s more the ecosystem and developers around it. An example would be people focusing more on branding and landing pages.
I don't like Node, either. Having one company and one package manager entirely control a formerly open and decentralized programming language ecosystem is a regressive step from what we had before. I also don't believe Javascript should be used as a general purpose programming language outside of the browser. I don't hate JS, but it's a very flawed language designed for a specific, niche purpose and the amount of effort put into making it "enterprise worthy" (which seems to fail spectacularly and publicly just about every week or so, in ways no other language has to deal with) is the reason the JS ecosystem is a such Lovecraftian horrorshow.
Considering its popularity, vast ecosystem, and widespread use, you can't just state that it's hated so much - that is just your impression based on few very noisy people.
>Considering its popularity, vast ecosystem, and widespread use, you can't just state that it's hated so much - that is just your impression based on few very noisy people.
I wouldn't say it's popular; it's ubiquitous. It is the only language available for development on one of the most used platforms in history: The Internet.
Also, I'd wager there's more than just a few of those very noisy people.
It's ubiquitous because it is popular. If it wasn't popular, nobody would want to use, everyone would hate it, and Evil Corp Incorporated would ride in on the Savior Horse and give everyone the remedy to javascript.
But no. Instead of all that, javascript spread beyond the browser. It's in my TV (plain html/js + Wasm), on my desktop in the form of an IDE and as a VPN (at the very least the UI part of it), on SpaceX's Dragon Capsule (which itself is in Space).
JavaScript, along with HTML are the among the few of the most scrutinized and battle tested technologies ever. Billions of QAs ranging across the whole world, ranging from completely incapable users to sophisticated teams of security engineers bash at it tirelessly and without sleep. And this thing holds.
I get it, it has the shitty parts, but it also evolves, becoming better and better. And most importantly - it's one standard. No branches, no perlisms. Just one organism evolving. It's really great when you come see it through the prejudice.
Nearly no one would use a language incompatible with Chrome or Safari. Just how would Evil Corp solve that?
JavaScript spread beyond the browser because it was the only choice in the browser. Want to use the same code in the browser and anywhere else? Want maximally fungible employees? I think those choices don't pay off many times. But JavaScript is the only choice if you do.
Languages have few security vulnerabilities. JavaScript libraries and implementations have had their share.
Evil Corp Inc. doesn't pay me, so i'm going to do their job - they figure it out. Chrome and Safari's existence and usage are not under a mandate by God. If Evil Corp Inc. comes up with the better everything, i'd be the first to try it out and possibly jump ship, because you have to be insane to use shitty tools where there is something far better out there, right?
Computing history is full of examples where compatibility was more important than developer happiness. And competing browser engines aren't allowed on iOS.
Being heavily coupled to the front-end. There's a perceived attitude that many Node devs are just front-end devs with enough back-end knowledge to be dangerous. With this is the overloading of the term "full stack".
The early perceived coupling with MongoDB didn't help.
I remember back in the late 2000's/early 2010s, there was a blogger, I think at google, who claimed that "the next programming language has already been chosen for you". In retrospect, he was clearly talking about javascript, which got a tremendous push from the big tech players despite all its obvious problems. Now we are stuck with a mess of code written in an ugly language.
Why the big guys picked javascript, I don't know. Maybe to ensure that everyone was so bogged down in dependencies, language incompatibilities and callback hell that no competitors would arise?
I'd expand on it to answer the original question more fully from my perspective: I don't actually hate node.js per se. I'm sure it's a very good javascript environment.
For me, the problem is a fundamental one: you're choosing to write javascript somewhere where you don't have to be writing javascript. I disagree on principle with doing that: friends don't let friends choose js. For me, any technical merits of the implementation and the benefits of running the same code on both server and client sides aren't important - IMO you're better off to just use a good language instead, only using as much js as is absolutely necessary.
I literally don't think I've ever seen anybody try to argue that js is a good language. I can't conceive of anybody trying to argue that such a pitiful standard library is a good idea. Why in god's name would you choose to use it server side when you could be writing something less excruciating like perl or php or assembler or brainfuck?
> Why the big guys picked javascript, I don't know.
To be fair, they never really picked it per se, it was just the only thing that was kinda-sorta standardised enough that you could write code and kinda-sorta-almost get it to run on most browsers without installing some horrible plug-in. I think a more appropriate question is why it never got replaced with something not-awful.
The larger book covers things like scripting CSS and SVGs and goes in to exhaustive detail about the language. If you subtract the smaller from the larger the resulting set is not “bad parts of JavaScript “
One person’s opinion of Python’s good parts would be equally small and any opinion would be very small compared it to the entire official documentation.
I have no personal issues with JS/Node.js except that when I was learning it there were so many different ways to create objects that it took me a while to sort out how I wanted to do it and what all the trade offs are.
For me, it's less an equation of active hate. I can actually see why some people like it, and I wouldn't want to get in anyone's way on that.
That said, I have found that the .NET ecosystem is an agreeable way to build the kind of software I need to build. I don't think my product would be infeasible in a Node.JS ecosystem, but it would certainly be more painful for reasons that are specific to our problem domain.
If I had to take a shot across the proverbial HN language war deck, I would say that dependency management is the biggest reason I would prefer to avoid Node.JS on future projects. I have a very complex .NET code base which uses 3rd party dependencies you can count on one hand. Our customers really enjoy that kind of thing.
Can’t remember where I first heard this but I think it applies here: There are two kinds of programming languages. Those people complain about and those no one uses.
EDIT: To add a more constructive comment: Don’t worry too much when people hate on a given language and don’t try to make a decision based on what tool or language people are complaining about. Every tool has its usefulness and its drawbacks.
I don't hate node, I just realized that on the server-side, by the time I added enough modules to make something work I could get better performance from a Jakarta EE application server and write far less code.
Go's standard library comes with a lot of the same batteries built in and while I write more code in Go, the compiled binary is small (good for container management) and I use less dependencies.
So that last sentence is the key. When I was writing a lot of Java, I learned to curate my dependency graph carefully. When writing in Go, I've become even more careful to only use widely-adopted packages though I'm a bit more lenient with test-only package.
I've predominately stopped using Node.js because it's dependency graph is simply unmanageable. Node.js itself provides a facade of multiprocessing as well as other niceties you'd expect to find on the server-side but to do anything substantial you either need to code it yourself or you adopt a huge dependency tree. Downstream security vulnerabilities and bugs mean you're continuously updating versions and it's not always pretty.
Now that I've adopted the write a bit more code and use fewer dependencies mentality, perhaps I should try another project in Node.js. I have to admit that Typescript (and even some of the EMCA improvements) also make it more attractive.
It was like mold that suddenly grew everywhere. Monopoly of JS in browsers translated into a big share of server-side pie too. People had all the options and they chose JS still, not a situation to be happy about if you ask me.
For a front end language designed in 2 weeks it is quite good. That we are stuck with it is kinda sad but its good enough.
If you design a tool (or DSL) you must tailor it to the problem it needs to solve. It must not be overly generic while still covering the entire scope. This is extremely hard and it usually takes a few versions for a language to get it right.
Then we take the DSL and implement it in an entirely different situation(????) Look, I can use my wrench to hammer in nails!
What to say? The nails are indeed going in. Massive structures are erected. They are structurally sound but it just doesn't look professional to people who are used to hammers. I'm going to be using a hammer until end of time. I tried holding the wrench over the nail but I just couldn't bring myself to hit it.
It wasn't designed in two weeks. The initial protype for Netscape was, but that early version of JavaScript (it was called oak at the time) is far far from its modern counterpart. This is a particularly poor take as it seems you have no idea what JavaScript actually is or how it's evolved with time. If you want a purpose built DSL then find a framework, not a language runtime.
147 comments
[ 6.6 ms ] story [ 357 ms ] thread- lots of people don't like Javascript
- lots of people don't like V8
- the guy who made Node.js (Ryan Dahl) doesn't like it either
- programmers think anything without thread support is a toy
I like Node.js, Javascript, and Ryan Dahl, and have no strong opinions on V8.
It is dominated on the server because Java, C#, Elixir, Erlang have a concurrency and parallelism story and node doesn’t.
For most scripting work it is hard to beat Python even if Python is slow.
Sometimes I think compiler and tools writing for node might be fun (boy the world needs an ISO common logic implementation that isn’t hets and Haskell) but compiler and tools writing in Java is fun too, particularly in JDK 16. (Think ‘Haskell the good parts’.)
Apropos of nothing...
I find Python to be unreadable. I have a moderate reading issue and Python just looks like random letters to me. I actually wish I could process it as there are some very nice tools that I see people make that use Python.
I would love a more in-depth exploration about this part of your message, if you have some time. I didn't explore the compiler/tools ecosystem for Java for some time, would love to know the advances it got that prompted your message.
With sealed types, var, and similar features, pattern matching, it is getting better all the time in small ways.
I recently wrote a dsl in Java that lets you write a Java AST , transform it as a tree, write Java source code, compile it. It is not quite as simple as doing the same in LISP and you have to mangle names a little to unerase types, but the IDE helps you find the names.
I also don't particularly care for "async everything" by default. It makes your program more difficult to reason about. Rather than dealing with concurrency in a subset of your application, you now have to worry about it _everywhere_. There are only a few classes of software where the async-everything approach even makes sense.
Throw in the fact that the ecosystem is an absolute dumpster fire and you have more than enough justification.
Although JS has problems, it did already win so Node.js is useful in that sense. But async everything is nutso and requires lots of gating and checking mechanisms in order to get back to synchronous, imperative behavior which is what you normally want in a scripting language.
The setup/versioning and dependency hell issues of Node are absolutely bonkers. I work on a monrepo of 400,000 lines of code at work and I think most of the Node stuff is "just guessing" when people run it. Secret incantations that don't make any sense and have to be copy/pasted. All of Node is like this.
In what way did it "win"? People use JS because it is in the browser, do you have any data that JS won anywhere except the browser? Pretty sure it isn't even the most popular solution for web backends.
Huh?
Eventually, people just compiled code written in other languages into Javascript, treating it more as an "assembly language for the web"[2] than a language directly coded in, and the script type attribute was officially deprecated from the script tag in HTML5.
[0]https://www.w3.org/TR/REC-html40/interact/scripts.html
[1]https://eager.io/blog/a-brief-history-of-weird-scripting-lan...
[2]https://www.hanselman.com/blog/javascript-is-assembly-langua...
What common problem suffers the most solved in js? Preferably something without hope for improvement.
There probably isn't much benefit to different languages if you're just manipulating the DOM (which is probably why that model failed, having more than one language doing the exact same thing is needless extra complexity) but using the browser as an application runtime opens up the possibility of making any software written in a supported language accessible and executable from a URL.
The "JS as bytecode" model got us surprisingly far, but it was a disgusting hack, and Java applets and Flash had their day in the sun, but Webassembly is probably what's going to make the "multiple scripts in the browser" model eventually feasible.
It could not be required to run the script. For example require the visitor has his own website and have the script interact with specified tools installed there. Or a very limited language that disables js for security.
It could be a highly readable DSL, for example something to write interpreters in.
Or something narrow like interact with a rich text editor or data visualizations.
Perhaps a basic game engine.
I understand your complaint.
Just to add some historical background, Node.js creator Ryan Dahl deliberately architected it that way. He thought threads to express concurrency had flaws. (Especially for i/o tasks instead of cpu-bound tasks). An excerpt[2]:
>“Node was originally born out of this problem — how can you handle two things at the same time? Non-blocking sockets is one way. Node is more or less the idea, or exploring the idea: what if everything was non-blocking? What if you never waited for any IO to happen?”
It's interesting that around the same time, a JVM-based competitor called Vert.x adopted the same philosophy. An example discussion on HN where some favor async by default: https://news.ycombinator.com/item?id=3928738
[1] https://medium.com/softup-technologies/node-js-internals-lib...
[2] https://siliconangle.com/2013/04/01/the-birth-of-node-where-...
Wish the UI components would just render regardless of whether or not an async call was finished, rather than have to write conditionals for the components to display based on returned promises, populated states/context... I've grown to really hate react these last few months
You do know that web browsers aren't implemented in Electron either and that they don't use javascript to load the resources of a web page concurrently?
You were talking about why Electron/Javascript/Node.js rules all. I'm not aware of any web browser implemented in those technologies. I know Electron is based on chromium, meaning they used a browser to implement it, but I am talking about the other way around ie implementing a browser in Electron.
Electron embeds a web browser, which is a highly complex asynchronous application which is written in C++ by one of only a handful of super high tech companies. It is notorious that efforts to make web browsers with other runtimes (e.g. Hotjava) have failed.
The web browser is async from top to bottom so it never blocks when loading possibly hundreds of resources that make up a web page. JavaScript is asynchronous so it can be embedded in the web browser, if it wasn’t it could lock the whole thing up.
I looked at what the options were for cross-platform guis written by applications programmers and they were not pretty, had serious warts, and all went out for long lunch breaks.
What more complex games do (simplified) is put file IO on one thread, network IO on another, and use async (worker threads with jobs) for the rest.
[0] - https://godotengine.org/article/why-does-godot-use-servers-a...
What's the browser got to do with it?
For every node.js server there are probably 100 CLI programs that get run by the way.
You just write code, and the system figures out how to break things up.
But that’s a system that was designed from the ground up to be async. In JavaScript it was added after the fact, and you as a programmer have to deliberately annotate your functions to be aware of what is and isn’t async.
However the OP and I, are talking about async everything as a programming methodology and not as a fundamental part of the base system.
I think its awesome :D
Oh well, I learned I never want to touch Node again.
Tests can be written properly and in a very reliable way in any platform, and a mess can be made in any platform too.
My conspiracy theory is that this phenomenon partly created the need of microservices within the web community and by that creating entire new set of problems that needed to be solved.
And in a negative way as well :-) Ask me how I feel about php.
This is, though, a very excellent point.
Negative views about PHP is completely justified :)
I used to apply for JS jobs, and the interview would have questions like "What do you dislike about JS?" I couldn't find much to dislike and never got those jobs. Maybe it's a sign of proficiency when you're good enough at a language to hit its limits.
I'd say the other effect is when you join projects built by experienced but non-senior people, it tends to be overengineered. Overengineering shows the ugly side of a language. Everyone assumes that this is normal behaviour for the language, when it's frequently not.
and unlike these other languages there s not usually one or two ways of doing things. there's so many different frameworks, build tools, countless stacks beyond measure. when someone is force converted onto node they're more likely than not to have poor footing, be unable to make the typical sloe steady grind into proficiency they would with a less diverse language like python or ruby.
- the sense that I never really can be sure where the code is executing at a glace;
- the (compared to Python) cruft-laden syntax
JSON was a win. I nearly forgive JavaScript for begetting JSON.
You wouldn't make this statement if to compare bogosort and quicksort, would you?
JavaScript sucks. It isn't the best choice for any problem except where you are forced to use it (the web browser). The only reason we still have it is inertia. PHP is in the same camp.
Programming languages have evolved. We know how to do better now.
I think this is self evident but maybe someone else will care to list some usage statistics.
Most arguments, even in this thread already, are just wrong. Obviously they have never had any experience with the Node.js ecosystem and another.
What makes them obviously wrong? To me they sound like sound arguments by people who actually use(d) it.
> node does not have a concurrency and parallelism story
> standard library is tiny
Also claims like "async makes your program more difficult to reason about" without any explanation.
I hereby claim that goroutines and mutexes make your program more difficult to reason about.
> the ecosystem is an absolute dumpster fire
I am super curious which ecosystem that person would consider better.
> no threads
Worker threads are a thing since Node v10. Also, I like the single thread concurrency, it makes state management easier (since there is no race condition).
> node does not have a concurrency and parallelism story
> standard library is tinyYou have sockets, http(s) (even http2), multiprocessing, readline, streams, timers, promises, JSON, etc...
They want String.capitalize()? They would complain about the implementation being bloated because it handles edge cases like other alphabets, etc...
> async makes your program more difficult to reason about
That may have been true with the callback hell before async/await. But now, it's just non-sense.
> the ecosystem is an absolute dumpster fire
Ironically, for an ecosystem based on the philosophy of "Don't reinvent the wheel", there are a lot of packages that does the same thing.
There is the leftpad fiasco, the colorette/nanocolors "scandal", the is-odd/is-even packages, ...
But as I said in this thread, this is not Node's fault, nor npm's fault. This is the developer's fault.
Cargo (rust), Mix (elixir), pip (python), they could all serve such an ecosystem.
It's up to the developer to be careful about his dependency tree. For example, if I need VueJS which depends on a specific library, I'll avoid installing another library doing the same thing.
In my experience, the entire JS ecosystem does not respect robustness, stability, backwards compatibility, correctness, testability, and learning from other ecosystems. It continues to erode itself with emojis in the package manager, childish schzophrenia of frameworks, complete disregard for proven methodologies and extreme indifference to maintainability.
Maybe it is just a personal preference then. I'd take Java and PHP over Javascript any day.
Doesn't PHP run like 70%+ of the web?
Do you have any evidence of that? I've written quite a few new PHP apps in my time.
For example, I have a little webapp that I built with create-react-app with typescript and redux. Very convenient overall admittedly. It's not very big, maybe 1k lines of code total, and 3 fairly minor packages added to do various things. The node_modules folder has over a thousand items in it, and takes up 350MB. The yarn.lock file alone is half a megabyte. Ahem, what the hell? At least the built artifacts are pretty small.
This might be seen as just a problem with create-react-app. But in my experience so far, pretty much everything in the Node world does this. Seriously, has anyone managed to do something useful in the Node world without ending up with a thousand packages?
Like if there’s some string manipulation thing I need, instead of copy pasting some snippet, I can pull in the micro package that already does this
However in Rust I find these packages managed properly which npm should learn.
More like "which the JS/TS developers should learn from"
npm is just a package manager, it's not its fault.
That's not even what's important though. What's important is, how can you ensure that none of these things happen to any of *your* projects dependencies? It's virtually impossible when there's a thousand of them. Are you going to audit that string manipulation micro package when you first add it, and then for every version update from now on, to ensure that nobody slipped some subtle malicious code into it? And do the same for every other micro package in your project, including all of the ones that the big ticket packages depend on?
All of this would be much less relevant if it had a more fully-featured standard library.
In some of the nodejs projects I've worked, we had allu dependencies with pinned version numbers, and each week we created a ticket to track work on upgrading them. This typically involved a single commit updating package versions and running all tests. More often than not it took no work at all.
If a project just lets their dependencies change randomly and does not invest any work updating them, of course there's bound to be pain and suffering.
In my previous role we constantly ran into issues with the integrity hash changing which was an unfortunate side effect of both the issues I mentioned above, an Artifactory npm registry and inconsistent npm/node versions
TL;DR though, it's not normal for the package-lock to change all the time.
Also, it's a safe bet in case the project grows beyond the initial scope. You don't want to spend most of your time refactoring, do you?
The same goes for TypeScript—how many interfaces does that app really have? Is it used in strict mode or just to type the most critical things?
I know that ecosystem fairly well, and have found it pretty effective to develop in. Compared to that, we have vanilla JS, which is okay for a thing or two, but awful to make a full SPA in. Or probably like 20 other web UI frameworks, all of which probably do the same thing as far as dependencies and have a learning curve for how to use them.
And what do we mean by "enterprise" here? The issue is the dependency chains and the maintenance issues that causes. If it was really "enterprisey", you'd think they'd do a better job of having a manageable dependency chain.
a strong 'stdlib' is a must, no other code will pull in who-knows-what packages hundreds of MB at least. Just like javascript is badly design, so does nodejs.
Professional java developers use a maven file which is similar to a package.json file. And it lists dozens of dependencies.
Even though java has default collections (so does javascript by the way), most developers also want Apache Commons (which could be compared to lodash)
And by default java has no DI and IOC, so most of them will install Spring Boot. The thing is, spring boot isn't just 1 dependency. There is actually a spring boot initializer website to help developers pick their dependencies. On top of that the names of Spring dependencies change between releases, sometimes they move things around.
And about persistence. In java you would need a JDBC library for ms sql server for instance. However, there are different ms sql server jdbc libraries depending of the version of the database, and depending on the version of your JRE. And in some cases you need additional libraries to add security protocols. (e.g. "bouncy castle")
And then there's JAXB which used to be included in the java framework, but has been removed since JDK8. Talk about backwards compatibility.
And what about portability. If you want to make a setup utility or installer for your software, then often they will include a copy of the Java runtime inside the installer. After all, you can't expect users to have java pre-installed. That does mean, that every installer has a footprint of 400MB+ (~the size of a JRE).
Node.js isn't that terrible now, is it?
Building and bundling for the web platform (where you have multiple browser, environments, users on different versions) is a real challenge and you actually want to have good tooling for this.
With NPM, you just bundle all of the tooling along with the dependencies you need for your actual app.
I think that's still a big improvement over projects where you first had to setup your dev environment in very specific ways just to get started (I remember this could even take days to get right for some projects I worked on).
Although I would really wish for a better standard library, or at least some "core NPM modules" which are officially agreed upon, promoted and security checked as an almost-standard-library.
Sounds like a bad choice of tools for a person who's is concerned that much about the disk size.
I wouldn't say it's popular; it's ubiquitous. It is the only language available for development on one of the most used platforms in history: The Internet.
Also, I'd wager there's more than just a few of those very noisy people.
But no. Instead of all that, javascript spread beyond the browser. It's in my TV (plain html/js + Wasm), on my desktop in the form of an IDE and as a VPN (at the very least the UI part of it), on SpaceX's Dragon Capsule (which itself is in Space).
JavaScript, along with HTML are the among the few of the most scrutinized and battle tested technologies ever. Billions of QAs ranging across the whole world, ranging from completely incapable users to sophisticated teams of security engineers bash at it tirelessly and without sleep. And this thing holds.
I get it, it has the shitty parts, but it also evolves, becoming better and better. And most importantly - it's one standard. No branches, no perlisms. Just one organism evolving. It's really great when you come see it through the prejudice.
JavaScript spread beyond the browser because it was the only choice in the browser. Want to use the same code in the browser and anywhere else? Want maximally fungible employees? I think those choices don't pay off many times. But JavaScript is the only choice if you do.
Languages have few security vulnerabilities. JavaScript libraries and implementations have had their share.
The early perceived coupling with MongoDB didn't help.
https://i.redd.it/h7nt4keyd7oy.jpg
I remember back in the late 2000's/early 2010s, there was a blogger, I think at google, who claimed that "the next programming language has already been chosen for you". In retrospect, he was clearly talking about javascript, which got a tremendous push from the big tech players despite all its obvious problems. Now we are stuck with a mess of code written in an ugly language.
Why the big guys picked javascript, I don't know. Maybe to ensure that everyone was so bogged down in dependencies, language incompatibilities and callback hell that no competitors would arise?
EDIT: It was Steve Yeggie, back in 2007: https://steve-yegge.blogspot.com/2007/02/next-big-language.h...
I'd expand on it to answer the original question more fully from my perspective: I don't actually hate node.js per se. I'm sure it's a very good javascript environment.
For me, the problem is a fundamental one: you're choosing to write javascript somewhere where you don't have to be writing javascript. I disagree on principle with doing that: friends don't let friends choose js. For me, any technical merits of the implementation and the benefits of running the same code on both server and client sides aren't important - IMO you're better off to just use a good language instead, only using as much js as is absolutely necessary.
I literally don't think I've ever seen anybody try to argue that js is a good language. I can't conceive of anybody trying to argue that such a pitiful standard library is a good idea. Why in god's name would you choose to use it server side when you could be writing something less excruciating like perl or php or assembler or brainfuck?
> Why the big guys picked javascript, I don't know.
To be fair, they never really picked it per se, it was just the only thing that was kinda-sorta standardised enough that you could write code and kinda-sorta-almost get it to run on most browsers without installing some horrible plug-in. I think a more appropriate question is why it never got replaced with something not-awful.
One person’s opinion of Python’s good parts would be equally small and any opinion would be very small compared it to the entire official documentation.
That said, I have found that the .NET ecosystem is an agreeable way to build the kind of software I need to build. I don't think my product would be infeasible in a Node.JS ecosystem, but it would certainly be more painful for reasons that are specific to our problem domain.
If I had to take a shot across the proverbial HN language war deck, I would say that dependency management is the biggest reason I would prefer to avoid Node.JS on future projects. I have a very complex .NET code base which uses 3rd party dependencies you can count on one hand. Our customers really enjoy that kind of thing.
EDIT: To add a more constructive comment: Don’t worry too much when people hate on a given language and don’t try to make a decision based on what tool or language people are complaining about. Every tool has its usefulness and its drawbacks.
Go's standard library comes with a lot of the same batteries built in and while I write more code in Go, the compiled binary is small (good for container management) and I use less dependencies.
So that last sentence is the key. When I was writing a lot of Java, I learned to curate my dependency graph carefully. When writing in Go, I've become even more careful to only use widely-adopted packages though I'm a bit more lenient with test-only package.
I've predominately stopped using Node.js because it's dependency graph is simply unmanageable. Node.js itself provides a facade of multiprocessing as well as other niceties you'd expect to find on the server-side but to do anything substantial you either need to code it yourself or you adopt a huge dependency tree. Downstream security vulnerabilities and bugs mean you're continuously updating versions and it's not always pretty.
Now that I've adopted the write a bit more code and use fewer dependencies mentality, perhaps I should try another project in Node.js. I have to admit that Typescript (and even some of the EMCA improvements) also make it more attractive.
If you design a tool (or DSL) you must tailor it to the problem it needs to solve. It must not be overly generic while still covering the entire scope. This is extremely hard and it usually takes a few versions for a language to get it right.
Then we take the DSL and implement it in an entirely different situation(????) Look, I can use my wrench to hammer in nails!
What to say? The nails are indeed going in. Massive structures are erected. They are structurally sound but it just doesn't look professional to people who are used to hammers. I'm going to be using a hammer until end of time. I tried holding the wrench over the nail but I just couldn't bring myself to hit it.
(with hammer I mean PHP)