45 ms·
Things I Regret About Node.js [video]
- dergachev 8y agoI first read this as "Things I regret about Node.js by Roald Dahl" and was instantly intrigued!
- genjipress 8y ago"Things I Regret About Java," By Roald Dahl, author of "Charlie And The Class Factory"
- modzu 8y agocan somebody downvoting the comment above kindly explain why?
- bshimmin 8y agoOne-line jokes are generally not well-received on HN unless they are so exceptionally amusing and original that they are beyond reproach. The standard rationale for this - which can make HN seem very dry and humourless at times - is that people want to avoid HN becoming like Reddit.
- modzu 8y agothanks for answering. but thanks to the parent comment i learned about a new (albiet widely recognized) author. thats useful because we all come to hn to learn things. i suspect most downvoters probably dont even understand the reference and just see a joke qua joke. boo.
- whatsstolat 8y agoInteresting its strange to hear that someone hasn't heard of Roald but that's a generational and nationality bias.
- chris_wot 8y agoWell, don't feel you can't read his children's books. They are incredibly entertaining. Try reading The Twits without laughing... very difficult!
- hboon 8y agoI don't know how entertaining they are for adults, but I enjoyed reading Boy and Going Solo when I was younger.
- cafard 8y agoI encountered them probably in my 40s, but did find them enjoyable.
- nsomaru 8y ago"Boy", collection of short stories including "Henry Sugar"
- sdfsdfdsfgs 8y agoHackers don't like fun. They are serious and important people.
- mromanuk 8y agoI was thinking, watching the video "Ryan should fork it, or start over"... until he revealed it: https://github.com/ry/deno https://github.com/ry/deno :)
- sametmax 8y agoMy head can't wrap itself around: import { test } from "https://unpkg.com/deno_testing@0.0.5/testing.ts" 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.
- dylrich 8y agoHis arguments for it seemed reasonable - would love to hear your criticisms
- freditup 8y agoNot OP, but a couple guesses off the top of my head: * It becomes a more painful process to upgrade dependencies (have to find/replace across your codebase). * Many versions of the same library get pulled in. If you depend on package@1.5.3 and a dependency of yours depends on package@1.5.4, that's twice the dependency size as compared to both just using 1.5.4. This matters more in the case of web app bundle size though than running local programs.
- t-sauer 8y agoYou could have an entry file for your dependencies (let's say dependencies.ts) and reexport everything from there. When you have to update, you only have to upgrade it in the entry file and you can avoid multiple versions.
- wereHamster 8y agoHm, how about we call that file package.json?
- amelius 8y agoTL;DR, from quickly browsing through it: He mostly regrets the way Promises work (edit: that the async programming APIs don't work with them), security/sandboxing, and the module system. Then he introduces "Deno", a successor which is under construction and which will fix all these problems. It exposes a language based on TypeScript. Internally, some parts of Deno are written in GoLang.
- k__ 8y agoHe regrets not including promises early on.
- emehrkay 8y agoInteresting that he had promises in node that early. Maybe if he kept them, the community wouldn’t had standardized on two space indents Edit: so two space indents weren’t a consequence of “callback hell” ?
- abiox 8y agoi could see nested callbacks favoring two spaces, but overall it's not a style unique to javascript. for example, a lot of ruby i've seen (admittedly it's been a while) used two spaces, and i don't recall it being any more prone to deeply nested code than other languages. that said js code tends to be rendered in a variety of other places like browser dev tools, which may influence this as well.
- jessaustin 8y agoAfter getting used to 2 spaces in js I try to use them everywhere now. Except python, which obviously must be 4 spaces...
- misiti3780 8y agoi have always really enjoyed listen to ryan speak. he seems very humble for all of his accomplishments.
- k__ 8y agoYes. He seems like he doesn't care much about the success of Node.js. It was just a cool project and he moved on to the next cool thing.
- curun1r 8y agoAgree completely. Although one of the more interesting "talks" I ever heard him give was a discussion on promises. I was lucky enough to be in (the ridiculously long) line behind him waiting for food at NodeConf in 2012 and he and an engineer from Microsoft had a pretty spirited discussion that explored the subject in way more depth than I had previously thought possible. Ironically, given that he now considers the removal of promises to be a mistake, it was the engineer from Microsoft who took the pro-promises side of that argument.
- tlrobinson 8y ago> it was the engineer from Microsoft who took the pro-promises side of that argument JavaScript's async/await is essentially taken from C# (with "promises" instead of "tasks"), so that could explain it.
- StreamBright 8y agoMaybe it is just me but Javascript is not my favourite dynamic language. Given project like ReasonML and other languages that have type inference prototyping is not harder than without types. Is it a valid argument that it slows you down? Not sure.
- k__ 8y agoSeems like he prefers TypeScript because it's a super set of JavaScript. He also mentions he only knew MS made it, but not who specifically, which lets his choice sound more profound.
- sebringj 8y agoI was not happy having to do TypeScript on a project thinking in your point about slowing you down which initially is completely true if you are forced to tslint it to hell. However, I've done a 180 in that TypeScript is very nice when you relax the tslinter and you sprinkle it on as you go which gives you that extra feeling of being auto-guarded when its just more practical but without getting in your way which is exactly what Ryan was saying in his Deno approach. I've saved loads of run-time errors from VSCode knowing types ahead of time for example.
- acemarke 8y agoCould you summarize what settings you used for the TS compiler and tslint for that "sprinkle it on but keep it out of the way" approach?
- sebringj 8y agoBasically you turn off as many settings as possible that make things impractical. Its more of how you work, not a catch-all. I have VSCode and installed a supporting library to work with it. Basically it tells me what's wrong and how to disabled it as well. I either inline disable it or go to the specific tslint rule and disable globally. It is most difficult when you have to use another person's biolerplate that was built without typescript AND tslint is turned all the way up.
- 8y ago
- jaequery 8y agomuch respect to ryan for coming out like this. i used to think that he might have thought node was the bee’s knees and that callbacks and promises were sent from the gods. glad to hear him confirm what a lot of js devs are feeling right now with the wretchedness of the js callbacks, promises, and generators. there is a better way and im glad he is trying to do something about it.
- tlrobinson 8y agoPromises (with async/await) aren't so bad. He explicitly says he regrets taking promises out of early versions of Node.js.
- Guillaume86 8y agoHe looked pretty ok with async/await (which uses Promises under the hood), one of the advertised features of his new project is top level await.
- spankalee 8y agoWhich is unfortunate. Top-level await is a very bad footgun and should almost never be used.
- tlrobinson 8y agoCan you elaborate? It seems useful for simple scripts and REPLs, at least.
- lostctown 8y agoIt is useful for those things. I implemented a fairly involved scripting system that we now use inside all of our server instances. Each script in the system is an entry file mapping to an alias command and the entry file is invoked from the top level. To get the benefits of async/await, we write the logic of each entry script under main = async () => do_logic(), and call it at the end of the file as main(). I just don't see how this workaround is the correct solution. Just saying that's it's generally a bad idea is not enough for me. At some point there will come a time when you want to treat a file as a function, and when that day comes you will want async/await at the top level.
- thosakwe 8y agoThis 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'm not so sure what can come in terms of performance and security from running JavaScript outside of a browser. The choice of V8 also raises concerns for me about build systems. He mentioned the failing of GYP, but anything using the same build toolchain as Chromium always introduces a wealth of complexity for anyone building said software, as not only do you need Google-specific build tools, but also very specific configuration including Python. It will be interesting to see what comes in the future. If it were up to me (which I guess it isn't), I'd probably prioritize portability/less complex builds, built-in FFI, a flat module system, and optimizing calls to C from JS.
- mschuetz 8y ago> 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 1400 files (~200mb), filters all points within a clip region, and writes the 12 million resulting points in a 300MB file, all in 1.6 seconds. (File reads were cached by OS and/or disk due to repeated testing, but file writes probably not) My personal conclussion is that javascript can rival or even exceed the performance of C++, not because it's inherently faster, it's obviously not, but because it makes it much easier to write fast code. For the highest possible performance you'll defenitely want to use C++ but sometimes you'll have to spend multiple times the work to get there.
- chrisco255 8y agoRight, V8 works great at optimizing JS and it handles streams great. Productivity is one of the most important factors to think about when building software systems since human time is much more expensive than CPU cycles. That's why Node.js works great.
- davidy123 8y agoThe first post in this issue has a summary of some performance problems with node.js: https://github.com/ry/deno/issues/162 https://github.com/ry/deno/issues/162 Though, it's posted in a confrontational way so the conversation deteriorates.
- Touche 8y agoNo, that thread is everything that is wrong with open source.
- davidy123 8y agoI don't think your comment is clear at all. Do you mean the "community" or (arbitrary) toolsets of open source?
- deleted 8y ago[deleted]
- Touche 8y agoThe community. Specifically that someone thought it was appropriate to post an issue shitting on someone's old project in that person's new project's issue tracker.
- davidy123 8y agoThe original post could have been constructive. It's at least a good possibility that a new thing can be developed based on criticism of an old thing, and some of the author's points were just building on what Dahl said, so it could have been a useful discussion. I don't agree with another comment in this thread that it's easy to (succinctly and with depth) point out what's wrong. The person who initially responded to the issue could have included these possibilities rather than playing full-on cop. These systems are still largely organic. But the original poster's replies are hostile and in light of the "radio silence" request mentioned later in the thread, it wasn't ultimately a good post.
- 8y ago
- VeejayRampay 8y ago"And then there were people adding modules. I thought to myself, this projet is done now. So wrong." Seriously why are we as a community still entertaining those outlandish statements and attitudes? If you heard that sentence as a non-tech person, you'd swear modules is a computer virus or something, that it's so inherently bad that it's not even worth discussing. Props to Ryan for his amazing work, but come on let's try to be civil and respectful here.
- abiox 8y agoi'm not sure what you mean by "outlandish statements and attitudes". when he said "this project is done now" my takeaway was that he didn't anticipate the popularity of node. and "so wrong" was him acknowledging that he was very obviously mistaken.
- sonofaplum 8y agoThats not what he meant. He was not saying "People are adding modules, modules are bad, this project is ruined, [modules are] so wrong." He was saying, "People are creating modules, people are building on top of my work, this project is COMPLETE. [I was] so wrong."
- bluesroo 8y agoI'm glad you elaborated on this because I also interpreted it as an overly negative attitude towards modules. He was definitely a little nervous while talking!
- VeejayRampay 8y agoAh my bad, completely misunderstood what he was saying. Thanks for providing context.
- sebringj 8y agoWhy I admire Ryan is "I shouldn't just complain without giving a solution..." and he gave a solution, more than once. I have done this on a no-one-cares scale but it really is better to do yourself when you can. Also, Ryan has some sharp sarcastic wit which is pretty fun to watch on this talk.
- ahmetkun 8y agoYou can see the same sarcastic wit in this talk too: https://www.youtube.com/watch?v=jo_B4LTHi3I https://www.youtube.com/watch?v=jo_B4LTHi3I It's still my favorite tech talk, very fun to watch.
- draw_down 8y agoI thought that was nice too, but I wish we as an industry placed a little more value on simply admitting that something is bad or suboptimal. You're not supposed to "complain" or "be negative", which I think is unfortunate in lots of ways.
- sebringj 8y agoYah I get that. I remember at my work, I said something negative about how we were sending out emails that they looked like they were from 1990. I got a lot of backlash for complaining but next day gave them a modern solution and bam, they were super happy. Maybe its just human nature but providing something to fix it rather than just being unhappy alone is more powerful.
- elliotec 8y agoBut people do complain and be negative without offering solutions by far most of the time. And there is not much value in that anyway.
- nodesocket 8y agoWe've missed you Ryan. :-)
- snek 8y agotl;dr converted ts dev talks about how he screwed over the node.js ecosystem and how everyone should therefore use his shiny new project instead :/
- coldtea 8y agoHe didn't just "screw it" -- he also created it.
- rb808 8y agoInteresting 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.
- faitswulff 8y agoThe repo itself says it's "Segfaulty," which is far less likely in safe Rust, for example. Perhaps that's why he mentioned it as a candidate. Regardless, it sounds like he was doing a lot of work in Go, so perhaps it was just the too that was closest to hand for him when he decided to build the prototype.
- curun1r 8y agoIt might have to do with the overhead of calling into C/C++. Since a project like deno will have to do a lot of interfacing with V8, a language like Rust wouldn't have the overhead of cgo when dealing with the embedded VM. Also, while go routines are one of the strengths of go, they don't necessarily play well with concurrency constructs in other languages. Since a project like deno will probably be keeping Node's single-threaded, evented model of concurrency and using libuv (also a C interface), that basically means avoiding go routines. To your point, though, you'd still use basically the same language on the server and client, since deno runs typescript and typescript can compile to run in a browser. The Go side would take the place of Node's native modules, which currently have a C++ interface.
- zemo 8y agothe point of Go is to have one language that's the best of both dynamic and static languages. the point of Rust is to be safe and fast. if you're building an infrastructure where you're externalizing the dynamic language runtime, such that there's always a host and a guest language, Go isn't necessarily optimized to act as a host language in that context. Rust is, at the expense of being arguably more tedious to program.
- pknopf 8y ago
- uqimerioni 8y agoWTF slide brought be here. In the world where Python and Ruby exist - calling javascript best dynamic language is nothing but heresy.
- deleted 8y ago[deleted]
- rictic 8y agoI like all three languages. I spend most of my time with JS because it runs in the browser with no overhead, and it has the highest quality VMs.
- Scarbutt 8y agoI think you are taking it too seriously.
- always_good 8y agoHow? Javascript has a lot going for it from async-everything to conveniences like destructuring. And it works in the browser and has things like Typescript. I have to find good reasons to use another dynamically-typed language over Javascript.
- LargeWu 8y agoI would argue async-everything the biggest hassle with Javascript. Most of the time, I need things to run synchronously. Do this thing, then do that thing based on the result of the first thing. The need for async is the exception. So what we end up doing is expending extra effort forcing all the async stuff to run synchronously when that should be the default case.
- emilsedgh 8y agoWith the callback methods it was really a hassle. With async/await is so nice now. await step1() await step2() That's it.
- pvsukale3 8y agoCan anyone explain why he called Dart a complete failure? https://youtu.be/M3BM9TB-8yA?t=19m55s 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.
- jenscow 8y agoFUD. He's a fan of JS, and probably has no experience with Dart.
- thosakwe 8y agoI wouldn't say Dart is a failure at all. That being said, the Dart project has long abandoned the goal of replacing JavaScript in the browser, and instead provides a VM, Flutter, and a to-JS compiler. Many people do not know this, and have written the language off entirely. Hence a lot of the negative reaction to Flutter. (Though, if I'm quite honest, this is a bit off-topic from the OP)
- hajile 8y agoDon't forget that dart now has an AOT compiler and is strongly typed. It is close to Java in performance in a lot of stuff (faster in some). Syntactically, Swift is almost identical (dart being older) aside from GC vs ref counting. I think it has more of a future in the Java managed language area (but with better typing, better syntax, and first class functions with closures)
- Scarbutt 8y agoFlutter is relatively new compared to when Dart was created, Dart initial goal was to be a language for web programming, outside of google, I think almost everyone agrees it failed at that. They have change their mind many times about the design/future of the language, the churn is still experienced today, see Dart 2.0 (not released as stable yet), which some would say its a new language from Dart 1.0.
- TheDong 8y agoIn terms of mindshare, ecosystem, and real usage, it's a failure (when compared to popular languages). Regardless of how good a language it is, typescript fits in a similar space and is much more popular, has a more vibrant ecosystem, and is easier to migrate to.
- davidw 8y agoSome kind soul want to do a summary? I got through "uh hey, uh so" and remembered why I don't do videos.
- billbrown 8y agoHere is his PDF of slides - http://tinyclouds.org/jsconf2018.pdf http://tinyclouds.org/jsconf2018.pdf
- pookeh 8y agoI watched on 1.5x speed.
- d0m 8y agoTry "right-arrow" (you can keep it pressed). Sounds stupid but it used to be an issue for me and now I can watch lengthy videos in a minute, a bit like how one can go through a book quickly by flipping pages and going back to the interesting bits.
- iamleppert 8y agoHe 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.
- girvo 8y agoI do believe that’s on purpose...
- dgreensp 8y agoHaha! Ryan may not have been the best person to design a novel package manager, and while he has some insight into his mistakes the first time around, he still may not be. Neither am I; call me if you need a compiler or a GUI. Everybody has a different set of areas where they have gone deep and developed good instincts.
- bronson 8y agoYehuda! Calling Yehuda!
- toobadsosad 8y agoIsaac S. created NPM based on a Yahoo! internal package manager.
- jonny_eh 8y agoI 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.
- pknopf 8y agoIt sounded as if he just wants everyone to use Parcel. Even then, you would use npm/yarn to get your dependencies before bundling. It sounds like he doesn't want me runtime to handle dependencies at all. You can always reference urls with version numbers present in them.
- dxhdr 8y agoI don't understand the rationale behind using V8 for server code. Yes V8 is a general purpose JavaScript engine but ultimately all of the performance trade-offs and design decisions are made with browsers as the optimization target. It sounds like Ryan is still interested in making V8 work so I have to ask: why do you want to be writing server code on a client browser engine?
- sametmax 8y agoBecause that's the best existing engine (even with Zilla nicely catching up), with dozen of genius and millions of dollars dedicated to it since the beginning and for the next years to come. Why do you think JS became so much faster compared to the anemic octopus is was before ? And can you imagine the perf of Ruby or Python if a 10th of those resources were allocated to those ?
- azylman 8y agoIt'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...
- k__ 8y agoI think the package system consists of many parts. Some parts of npm are much better than with most package systems, some really suck. Maybe if npm weren't included so deeply into Node, it would make something like Yarn emerge sooner and replace npm without much hassle.
- jessaustin 8y agoyarn just seems like a set of incremental improvements over npm? Which is great, we're all for improvements. However, the vehement complaints I've seen about npm [0] make it seem that nothing short of a complete re-architecture could be tolerated. yarn does not seem to be that. I don't agree with those complaints, but I do agree with you that "some parts" are really good. node really figured out the right search strategy for an unscoped import. (e.g. "require 'foo';" rather than "require './bar/foo';") Just look for a directory with the name "node_modules". If you don't find it, go up one directory and try again. So simple! So predictable! So complete! It works so well, all manner of "left-pad" abominations can be supported. Any other system should think very carefully before using a different import search strategy. [0] with the exception of those related to path depth: I think those are resolved now? I wouldn't know because I stay on an OS that doesn't go out of its way to frustrate me.
- k__ 8y agoWell, since npm was the de facto default, it had enough time to catch up, I guess.
- geocar 8y agoYeah 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)!
- krmmalik 8y agoGreat talk. I have missed Ryan and im not even a developer. I just love his mind. He always demonstrates a lot of purity of thought in many ways. By the way, was i the only person to notice that “Deno” is an amalgamation of “Node”?
- bitsoda 8y ago*anagram
- quickthrower2 8y agoAlso an anagram of "Done"
- tnolet 8y agoHaving 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.
- jonny_eh 8y agoYou'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.
- allover 8y ago> You'll find much harsher critics of Node/NPM in these parts! They're ill-informed. GPP is correct that, for example pip is fundamentally inferior to npm [1], and those that insist on throwing shade at npm on HN should be corrected. They're wrong, and insulting a sound, well maintained project, without basis. [1] https://github.com/pypa/pip/issues/988 https://github.com/pypa/pip/issues/988
- kbenson 8y ago> those that insist on throwing shade at npm on HN should be corrected. Preferrably by giving them better ammunition, since I do see NPM as substandard in quite a few ways, which is inexcusable when there do exist examples to learn from (whether it be a positive or negative influence). First, it helps to clarify whether we are talking about npm the client or NPM the repository and ecosystem. Client issues are generally easily resolved, just use a different client. For npm, this could be yarn. For cpan, this could be cpanm, or cpanplus, etc. If it's indeed the repository we are talking about, there are some obvious things that could be done to greatly improve it the NPM module ecosystem. For example, how about automating module tests against different versions of Node to determine whether it's in a good running status now for the current and prior interpreter versions, on the platforms it can be run on? [1] How about a prior version, in case you're trying to figure out if the version you're on has a known problem on the platform combo you're running on? [2] Or perhaps you want to know what the documentation and module structure looked like for a module a long time ago, like20 published versions and over a decade ago, because sometimes you run across old code? [3] Or as an author, the ability to upload a version, even for testing, and getting an automated report a couple days later about how well it runs on that entire version/architecture matrix with any problems you might want to look into? In case you didn't notice the trend, I'm talking about CPAN here, which has been in existence for over two decades, and many of the features I've noted have been around for at least half that time. All in and for a language that most JS devs probably think isn't in use anymore, and on encountering a professional Perl developer would probably think they just encountered a unicorn or dinosaur. Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. Given the current popularity of JS and the massive corporate interest and sponsership, I frankly find the current situation somewhat disgusting. The only thing keeping JS from having an amazing module ecosystem is ambition. Sure, NPM might be a sound, well maintained project (points I think are debatable), but it could be so much more, and that's what we should be talking about, not almost annual fuckups[4] they seem content with dealing with. 1: http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 2: http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 3: https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/lib/DBIx/Class.pm https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/... 4: https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=false&dateRange=all&type=story https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=f...
- bitwize 8y ago"And JavaScript is a the best dynamic language." [sic] Uhhh, Ryan, there's this thing called Lisp...
- tlrobinson 8y agoI'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.
- jonny_eh 8y agoI find it really bizarre that Node still doesn't have full promisified built-in libraries. It's not like it'd break existing APIs.
- dvlsg 8y agoI think they're testing natively provided promise APIs with the fs module. https://github.com/nodejs/node/pull/18297 https://github.com/nodejs/node/pull/18297 It's of course not a full promisification of every built in, but it looks like theyre at least trying it out.
- tlrobinson 8y agoNode 10 has fs, at least: require("fs").promises.readdir(".").then(console.log)
- jonny_eh 8y agoWhy not just: require("fs").readdir(".").then(console.log)
- tlrobinson 8y agoThat's the legacy callback version. In practice you'd probably do: const fs = require("fs").promises; // ... fs.readdir(".").then(console.log);
- kjeetgill 8y agoAh, thats pretty nice. The previous example was pretty janky but I didn't foresee it being used like this. Eyes opened.
- royjacobs 8y agoI 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).
- cpeterso 8y agoThat's a good example of the Innovator's Dilemma: the enterprise incumbent is unseated by some "crappy" lightweight solution that is easier to get up to speed and solves enough of the problem. The complexity, accidental and essential, comes later.
- weberc2 8y agoNevertheless, people who need a lightweight language are always able to find one because there is always a new language at that point in its lifecycle. Further, there are languages like Go which seem to be determined to remain easy to get up and running, and don't seem likely to change anytime soon (for better or worse).
- cpeterso 8y agoIt will be interesting to see if some new language eventually seeks to disrupt Go by "out Go'ing" Go, returning to its approachable roots. (Amusingly, my iPhone autocorrect replaced "roots" with "Russ". Russ Cox is an engineer who works on Go. :)
- royjacobs 8y agoYes, this is exactly what's happening. Existing tools are seen as too complex because people don't seem to be realizing that the complexity is not accidental, but necessary. I'm not trying to say that Java has no accidental complexity of course, I don't want to open that can of worms :)
- deleted 8y ago[deleted]
- VikingCoder 8y agoWhy msg.proto? Why not json? This seems like an odd dependency to me, and it seems like it adds no value.
- pknopf 8y agoPerformance.
- VikingCoder 8y agoThat seems highly unlikely. I'm going off of what I've seen myself, and what I've seen in the xi editor: https://github.com/google/xi-editor https://github.com/google/xi-editor "The protocol for front-end / back-end communication, as well as between the back-end and plug-ins, is based on simple JSON messages. I considered binary formats, but the actual improvement in performance would be completely in the noise. Using JSON considerably lowers friction for developing plug-ins, as it’s available out of the box for most modern languages, and there are plenty of the libraries available for the other ones."
- dwetterau 8y agoDoes the xi editor use a JSON transport layer for all syscalls though? Low-friction interfaces for developers are great but I'm not sure I agree with the comparison here.
- VikingCoder 8y agoYes, it does. The frontend and the backend only speak JSON.
- inimino 8y ago"Performance" in a text editor means latency, and it's not going to matter there when the text editor also has to edit the text, update the display, etc. "Performance" in a server also means throughput. There's a reason why protobufs exist and it is all about performance (and type safety which is related) and there's no way JSON serialize/deserialize overhead, in both directions every time, is going to be a good choice here.
- ebbv 8y agoRyan rightly warns about adding “cute” and unnecessary features to projects. Then he goes and adds the “Load module directly from a URL” feature with all its complexity to Deno. Ryan; kill that feature now. It’s not needed. It’s just cute.
- pan69 8y agoI've said it before and I say it again; NodeJS is an infrastructure component, not a general purpose application runtime environment. I totally recognise the IO problem in our connected world and NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS. In essence (and in my humble opinion) NodeJS is basically a programmable socket server and it's main feature is "websockets". Writing software applications in NodeJS is the most awkward experience due to it's async nature. Business logic is inherently sync, not async. Most of NodeJS's existence has been trying to find an elegant solution to make this async behaviour look like it's sync, from callbacks, to promises and now actual language features added to JavaScript itself (async/await). The problem with Javascript on the server is not Javascript, but the runtime in which it's executed. I think it would be interesting to have an sync version of NodeJS that acts more like traditional Ruby and Python next to the async variant that we currently have. Both types could then be used along side each other, each solving the problem for which it is best suited.
- gcommer 8y agohttps://github.com/laverdet/node-fibers https://github.com/laverdet/node-fibers Is a project that enables writing code this way. It's used, for example, in webdriver.io so that you can write synchronous test code that transparently (ie, without `await`) calls out to async helpers.
- tree_of_item 8y agoThis is a solved problem. async/await makes your async code look sync. This is a strange thing to focus on IMO.
- always_good 8y agoI'd say your intel is far out of date. Async-everything + async/await makes Node more elegant than the same programs in Ruby/Python. Even little things like "make these two database requests in parallel and wait on them both" or "process these urls but only have 8 requests in flight at a time."
- 8y ago
- tannhaeuser 8y agoLet's not forget node.js wasn't created in a vacuum but was based on CommonJS (module format and std lib) also implemented by TeaJs/v8cgi, Helma, and many others [1]. In fact, server-side JavaScript was a thing as early as 1999 or before (Netscape Server). That it's based on a highly portable language also used on the browser is what made it attractive over alternatives for me back in 2012 or so. [1]: https://en.wikipedia.org/wiki/List_of_server-side_JavaScript_implementations https://en.wikipedia.org/wiki/List_of_server-side_JavaScript...
- breatheoften 8y agoWhy would deno implement “download on first encounter” for its module system ...? Would you ever want this vs an explicit “build” step that downloaded all the required resources ahead of time ...? Does deno walk the program source and download everything that could be required upfront or do the resource loading on demand as it’s executed ...?
- breatheoften 8y agoI think it would be a real shame if the module system design made it impossible to statically enumerate all the module's reachable from a program entry-point without executing the program ...
- danschumann 8y agoI still remember the first time I saw his node.js release video- changed my life.
- rmrfrmrf 8y agoTBH I felt like a lot of this could have been resolved if he stayed involved with the community and opened issues with the relevant repos. Seems pretty classless to rage quit the community, brag about how much better Go is, then mark your return at a JS conference by shitting on Node and hard-forking the server-side JS community.
- arenaninja 8y agoOne takeaway from this is how Microsoft is killing it currently: * Much-beloved TypeScript * Much-beloved VSCode * Much-beloved GitHub If they hire Ryan to flesh out his vision for deno we'd probably need a new acronym, MAFANG On a more serious note, I wonder if deno could support a lower level construct like Observables. As much as Promises are perceived to be an improvement over callbacks, they still have major flaws (only one of which is mentioned in this talk), this is something that Observables can address
- pjmlp 8y ago* Much-beloved Ubuntu Just leaving it here, given Azure Sphere and WSL.
- darzu 8y agoNitpick, but Azure Sphere doesn't use Ubuntu.
- pjmlp 8y agoTrue, it runs Microsoft's own distribution highly customized for the security context of Sphere. My suggestion is just the distribution I would expect Microsoft to acquire, if they would decide to go shopping instead of pursuing their own.
- the_af 8y agoDoes anyone remember the joke/hoax, back in the old days, of the alleged Microsoft Linux distro? :D (Of course, this was in the age of the Halloween Documents and the "Linux is cancer" mindset [0], back when Microsoft was a very different business). [0] https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/ https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_...
- davedx 8y agoTypeScript has async/await built-in, and Deno has top-level await too. Promises won't be necessary most of the time.
- matchagaucho 8y agoHe buried the lede. The talk highlights some regrets, but the most interesting part is a discussion about a new framework he's building based on Go and TypeScript: deno https://github.com/ry/deno https://github.com/ry/deno
- logicallee 8y agoHere is an amazing quote from a different interview: https://www.mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/ https://www.mappingthejourney.com/single-post/2017/08/31/epi... Apparently these days, "Ryan: Yeah, I think it’s… for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go" !!
- z3t4 8y agoFor security I make Apparmor profiles for each script. I think the module system and NPM is what made Node.JS popular. And personally I like function passing style aka. callbacks, Promises and async/await looks more terse but is actually more complicated and prone to errors. I also don't like that TypeScript extend the JavaScript language and ads a compilation step to it, it's much better to add doctype like comments and you would get the best of both worlds, although I don't think type-checking is needed if you already do testing. For me static typing is mainly for performance, like in Dart, you can't simple make JavaScript more performant without it. With TypeScript you have "performance optimization" but without the performance benefit. If your code needs type annotations for others to understand what it does you need to use better names. The type annotations are for the compiler. Auto-complete and parameter hinting can be done via inference. And public parameters and methods should have documentation.
- qaq 8y agoDeno looks very promising
- chriswarbo 8y agoIt's nice to see some recognition of the idea that interpreters are safe by default (excluding infinite loops/OOM), and we can avoid many security concerns (access to files/network/etc.) by simply not including that functionality in the interpreter (unless opted in via a startup parameter, as described). I'm also a fan of using env vars for configuration and locating dependencies, as mentioned in the talk. Much simpler and easily extensible compared to e.g. vendored directories (requires messing with the contents of the source directory, which requires write access and breaks hashes, etc.), hard-coded system paths like /usr or ~/.some-default-location (causes conflicts when running multiple incompatible versions), etc. A simple env var of paths, e.g. colon-separated, maybe with some sane quoting convention, can be used for all of those if desired, whilst making it super easy to extend-with or restrict-to any other location(s) instead. It's also trivial to "bake in" an env var to an application, just call `PACKAGE_PATH=foo:bar my_app` rather than `my_app` (or make a one-line wrapper script). I agree with others that importing from URLs seems like a bad idea: network I/O is one of the least reliable actions we can take, which would make importing far more complicated than necessary (what if we're offline? should we follow redirects? should we check for proxy settings? how should we report errors? etc.). All of this complexity and the inescapable problems of network failures are completely avoidable by just downloading things up-front. Package managers/build tools can fetch whatever they like (URLs, git repos, etc.), however they like (with proxies, caches, etc.), to wherever they like (one big cache, project-specific vendor dirs, whatever), and just stick the resulting directory (possibly of symlinks) in the program's environment (e.g. via a wrapper script, as above).
- tome 8y ago> I'm also a fan of using env vars for configuration and locating dependencies O please just let things be configured by a single JSON value, built from smaller JSON values if necessary.
- chriswarbo 8y agoSure thing. How do you get such a JSON value into an application though? What I'm saying is to use env vars. You could put your JSON straight into an env var, or if you want a persistent JSON file on disk then put the path to that file in an env var.
- inimino 8y agoIt's wild to see this after having been around in the early days of Node, and now having also moved most of my attention to Go as well. Ryan has always had, IMHO, excellent taste and good instincts and guts to make things simpler. A lot of the accidental complexity in our industry persists simply because people tolerate it, and it's great to see that he hasn't lost his fire in that area. Looking forward to see more about Deno. The point about promises was an interesting one for me personally since I was one of the people at the time who argued in whatever small way for taking promises out, in the hopes that the language community would come up with something better. I have mixed opinions on the topic now, but it's interesting to speculate about what might have been. The Node.js ecosystem was weakened by having different ways of handling the async question, and by a lot of developers not knowing the best practices in using callbacks effectively and leading to "callback hell", which is totally unnecessary. It's possible that having promises baked into an early Node would have constrained or even fragmented what we ended up with in the language, and that would have been worse. I'm still a little disappointed that we didn't end up with anything more elegant than promises in the language itself. It's interesting to compare package management in Node and Go. NPM got the early adoption and became the de-facto package manager at a time when JS had no such thing. In Go, the package manager question has been unsettled for a much longer time and there are more chances to experiment. Package management is simply difficult, and it seems impossible to design a good programming language and resolve the package management questions at the same time. It's sad to see some of the criticism against NPM... it's much easier to criticize than to build a better system.
- partycoder 8y agoDeno is not a good idea and Ryan Dahl should just let node.js developers moving to Go continue doing just that. Go is a well designed language that is productive, has a very tolerable learning curve, good documentation and does not need a JavaScript facade. If kids in the 80s without the Internet could learn programming, you can learn Go in 2018. Expect another video in 10 years: Things I regret about Deno, probably having advice very similar to this.