I think it's quite interesting to see that originally node.js was presented as a bloat-free alternative to "enterprise languages" like Java, C# or even Python or Ruby. A lot of complexity was subsequently added in an ad-hoc way which has resulted in (for example) a package management system that's wildly out of control.
It's very popular of course, so I'm definitely not arguing that metric. However, the stuff that was originally called examples of tooling that exhibits unneeded bloat and complexity (Maven) is now reimplemented in Javascript, but poorly (npm).
Can anyone explain why he called Dart a complete failure? https://youtu.be/M3BM9TB-8yA?t=19m55s ps: I am a junior developer. I am taking up Dart to learn Mobile apps development using Flutter.
I'm on the Dart team (but I don't speak for the entire team here). Dart had two initial goals: 1. Get a native Dart VM into Chrome and eventually other browsers. 2. Get a significant number of client-side web developers that were using JavaScript to move to Dart. It's probably not obvious, but these goals are in tension with each other. In order to motivate adding a giant new VM to a browser, you need to make the lan…
How would you characterize the positioning of Dart with respect to Go? Dart is for client-side, Go is for server-side? I'm also curious if you see having separate languages for these roles as desirable or just incidental.
This was one of the more interesting software talks I've listened to recently. I like that it was very real - there are serious, serious problems with Node.js, and the fact that even the creator acknowledges these problems caught my attention. I'm also a long-time user of Dart, so when he brought that up, and compared TypeScript to its shortcomings, I definitely agreed. That being said, even with the Deno project, I'…
> performance and security from running JavaScript outside of a browser. I'm just now building a node app to filter point clouds, so lots of number crunching. In two days I've got something in javascript that's faster than the C++ solution I've been working on for a week. Mostly because javascript/node makes it trivial to parallelize file IO while doing work in the main thread. This app reads 13 million points from 1…
> (File reads were cached by OS and/or disk due to repeated testing, but file writes probably not)
Unless you flush the pages manually, your dirty pages (written files) live on long after your process died. Depending on system and configuration, minutes or even hours can pass before they are flushed to disk.
Interesting that he's unsure about Go. Would be nice to hear about why. One huge strength about Node (&Deno) is having the same language and tools on the front end and back end. Its a huge benefit to have a team on one language, even if it might not be the optimal choice. I'm not sure if that is the problem he had with Go though.
I've never understood why this is a benefit when the one language is - let's say - suboptimal in many ways. The interfaces between server- and client-side code should be well-defined and language-independent. You don't want the same people writing both, because it's harder to check that your API is working to spec if it doesn't get fully independent testing. There's also a lot of useful server-side optimisation and s…
You don't see how having to know only one language, is easier/faster than having to know two languages? A lot of people are doing both front and backend work. Often times it's a single person running the show. I'll tell you right now I use node for ALL my web projects, because I only have to focus on a single language. When I wear every hat managing the domain, server, databases, mail, user questions, and everything else involved in running a modern web app, one less thing to learn sounds great.
Having worked with Maven, Gradle, Ruby Gems, Pip and the non-existing Go package management I must say I actually really like the Node / NPM combo. I guess artists are their own worst critics. edit: forgot Scala's SBT, admittedly a builder using Maven repo's but still an excellent example of how bad UX in this area can get.
You'll find much harsher critics of Node/NPM in these parts!
I thought Ryan did a great job of explaining his regrets without giving the impression that Node was a "mistake", is "inferior", or anything so drastic.
It's interesting to hear him say that npm and node_modules are regrets since lots of complaints about Go packaging from people new to Go ask for something similar...
Yeah I was surprised about node_modules as well. I think that's actually a killer feature (that we don't need $NODE_PATH or virtualenv or similar)!
He talks about not to add in features you think would be “cute” because they are always a mistake.. Then a few minutes later says “I thought being able to specify URLs in import statements would be cute..” Uhh...Houston, we have a problem with this one.
I dunno, importing from a url seems really smart and practical to me. It divorces the run-time (Deno) from a package manager (like npm). I wonder how it handles dependencies though.
My head can't wrap itself around: import { test } from " https://unpkg.com/deno_testing@0.0.5/testing.ts" There is so many issues with that I don't even no where to begin.
Actually, I can’t think of a single issue that npm doesn’t also have. Possible issues: - trust Not an issue since if you trust an author’s packages on npmjs you should also trust them from unpkg, github, etc... (Aka there is no trust in npm land except trust in the author) - Versioning Put the version in the url instead of some json, same difference. - Lack of ^ for automatic upgrades That’s a feature. Avoids the nee…
I'm glad to hear he (and the Node community in general) has come back around to promises. I remember the very early version of Node.js that had them (looks like they were added in v0.1.0 and removed in v0.1.30), although they weren't true chainable promises we have now.
I find it really bizarre that Node still doesn't have full promisified built-in libraries. It's not like it'd break existing APIs.