It was really cool to listen to! He took it with a lot of grace. I have a lot of respect for this guy and the way he handled this talk. Very enjoyable and enlightening.
Interestingly most creators of a language they will mention their flaws and what they think could have been done better - with age comes wisdom and simplicity.
Damn... My whole life I was surrounded by people which doing nothing and act like they invent electricity. And here is the guy who invent best technology of last decade (IMHO), and still remain shy. I need to know more about hem, hes my new hero
Very often you'll find that all these things are created by massively introverted people who hate public speaking and prefer to stay behind their screens.
14:55 "What I've come to learn now that I'm aging is that whenever you're designing a program, there's things that you think might be cute to add in. You always regret those. If they are unnecessary and simply cute, don't do them." 21:17 "I think it would be cute if you just import via where the source code came from."
Yes, but it's a different meaning of "cute". Bad Cute means adding extra complexity which might make things slightly easier for a few people. But at 21:17 he was talking about removing the complications he'd added to resolution of `require` paths.
Yea, well. People are lazy, and writing that long URL to the resource is not gonna fly. I know people would eventually write NPM or YARN (RNYA?? :D) for deno. Also, if it uses TypeScript the the definition files would have to also be downloaded... pointing to a single file won't fly. Unless it supports "import" of said file.
DENO 1. Parcel build included 2. TypeScript 3. No NPM installs and management 4. Single Executable File 5. IO / Write Optional 6. ESM Modules 7. V8 based on GN instead of GYP 8. Protobuf 9. Non JS Parts i.e BTS are handled with GO Lang instead of C++ ( still in progress) what more can you ask from Ryan, even when node is great. Really, expecting Deno to shine
Will it use js just like node.js or to use deno I have to use typescript ! I know this seems like dumb question because I have started to learn to code in js in the last 23 days and currently learning node.js
Use Rust instead of Golang? Rust is a bit faster at runtime, incomparably more expressive and way safer. Fun fact: Golang never made it into kernel code, while Rust is already supported (although actual use of Rust in the kernel will take a few years).
@@piyushaggarwal5207, for me, the whole list looks not like cons but pros or actually the advantages of the whole concept where Node.js got its success.
0:50 Love the casual "I created Node..." background summary :D Its also admirable how he takes credit for some of these 'regrets' without attempting to generalize or finger-point.
Big fan of Ryan Dahl. I think he was too nervous during this talk (because it has been years since he gave a public talk and also because he was presenting another technology and tensed thinking how people would react to this) I'm glad that he is back.
agree, also always people will disagree with him on few points, people he work with, so obviously there will be debates about few things etc. Seeing a massive amount of people in front of you, not knowing if someone is gonna agree with you, i agree can be nervous fosho
I like how he says - "If they are unnessesary and simply cute: don't do them" and then "I think it would be cute if you just import via where the source code came from"
What a legend. 2 years later, Deno goes 1.0. Edit (Jun 2023): I have been using Deno Fresh + Deno Deploy for personal projects and couldn't be happier with this stack.
"My other talk wasn't ready so this is just a make up talk.." 20 minutes later "So i was writing up this talk and it seemed kind of negative.. so i decided to write a replacement for node" Potentially hilarious bit of history if this ends up taking off.
Now I'm waiting for part two: 20 Things I Regret About Deno. I bet importing from URL will be issue #1. Also serialization for system calls looks like unnecessary overhead.
True. Serialization for system calls created unnecessary overhead and was removed See: en.wikipedia.org/wiki/Deno_(software)#:~:text=FlatBuffers%20were%20finally%20removed%5B15%5D%20after%20publishing%20benchmarks%20that%20measured%20a%20significant%20overhead%20of%20serialization%20in%20April%202019.%5B16%5D
It was refreshing to see Ryan speak up about node's drawbacks since, okay, for pragmatic reasons, they can't all just be flipped around today without dependencies all going bonkers, and yet still. Here and there, you see things that seem just wrong and it's nice to know you're not crazy. Promises are a big thing for me since IO performance, as a core goal of node, should offer a good way to write it - and promises, the concept that Javascript, as a language, has adopted because it's a good way of doing things, are excellent. Node, as a huge Javascript champion in the industry, would be great embracing it. "callback hell" is a commonly known problem and Promises are an elegant fix with exception semantics coming through cleanly and everything just working out.
Node and Deno are both monosyllabic. But, yes, they share the same alphabetic characters. Glad he didn't use more than four -- might've been a huge brain-tease for ya. His next version will be done.
I suppose it could be pronounced that way ... I had it in my head as "den-o" but since neither provides an established word in the English language, I'll stick with both Node and Done being monosyllabic as is "deno" (in my head anyway).
I have been a javascript developer since a few months , now . i have stopped coding in PHP , or any other languague because of the beauty of javascript. as i can write a software for desktop/server/mobile/web with just one languague. i never had so many fun in making my ideas and creativity come to life with my code. Man there is nothing to regret about NODE.js , it is the best thing to have happened. We are all fine with the issues, with softwares there is always something you know , as long as we use just one languague to code everything we do :)
Ryan is very humble and the amount of things he got right is incredible. That being said... The package.json/node modules thing is something I've felt for quite awhile, nice to hear someone else say it. Node module system is overly complex is the wrong ways and too simplistic in the wrong places. There's far better established ways of linking etc.
It's nice because Ryan said about the failure of Dart and this video is 2 years old now. A lot of things changed, like, now we have flutter and Dart comes to the discussion table again as a greate language to write cross-plataform applications, and we have an implementation of Angular with Dart.
Thanks for a great talk Ryan (and JSConf) , this is valuable thoughts and insights also on the abstract level for me as a developer even though I'm not a node.js developer. As other have already said, don't regret what you did - hindsight will always be there to teach us what to think about next time =) Keep it up!
It proves nothing is perfect there can always be a scope of improvement in any design.. We should accept our mistakes and learn from them to make even better design
Very interesting approach about the regrets of Node architecture implementation in the point of view of the one who was part of the initial concept of this so loved tool by us all.
I love this talk. It demonstrates that Dhal is a humble and intelligent guy who is looking critically at the biggest achievement of his life (so far) and how it compares to competing technologies. Compare that to how Bjarne Stroustrup talks about C++ and everything that isn't C++. All Bjarne does is give excuses for the myriad bad decisions in C++'s design and talks down to everyone who isn't using it or who doesn't think it is perfect.
Cool. Wishlist for next go-round: * imports with checksums (is that in deno already/yet?) to make sure you download the same file I did when collaborating. * Clojurescript support instead of / in addition to Typescript, as it’s more compatible with my favored methodology (but I’m reluctant to drag it in as an additional dependency yet on my own) - TS solves problems I don’t have, and I avoid writing classes, rather than higher order functions passing around short lived / locally scoped property lists. I don’t want hundreds of files / classes with thousands upon thousands of global symbols. * Rust, perhaps, rather than just Go, for writing native calls out?
Es una persona respetable y muy honesta al aceptar que cometió errores en nodejs, ahora entiendo que Deno seria su reivindicación, con el uso de typescript, esperemos se haga popular su uso
I agree that Promises should have been there earlier, but I don’t see it as a huge problem nowadays. New code is using async/await, and for legacy code it is easily possible to build async-wrappers with just a few lines.
The question is, what prevents making a new version of NodeJs that solves all these flows and "issues"? Like why is he talking about this being unfixable?
As he said, these problems just turned into "features" of node itself. A lot of software is already built upon these "problems", reverting them could throw a lot of software overboard.
Interesting talk, but I'm skeptical about taking library & dependency management from one nexus of doom (package.json) and distributing it throughout your codebase, as deno seems to want to. Does this mean that if I want to upgrade version, I need to search for every single file that's requiring it, and update the URL? Seems like the cure is worse than the disease, if so.
Peter Ingraham You can easily get around that by having a single file where you declare your dependencies in variables. And import that instead. That way you only ever change one file.
Yea totally agree ... introducing urls I believe is even more ugly and added complexity for no reason. If one give some thought and remains deligent about semversioning etc inside your package you wont have to worry about the issues he mentioned. I think of it as my source of truth for packages.
"What I've come to learn now that I'm ageing is that , when you are designing a program; there is things that you think might be cute to add in. You will always regret those, if they are unnecessary and simply cute; don't add them!" - Ryan Dahl
He is wrong in that "you cannot omit the ".js" in a script tag src attribute" -- you can, and the `src` attribute denotes a _URL_ of a _resource_, the user agent makes no assumptions about "file extensions" -- it simply requests the resource at the specified URL, per HTTP. The only thing that matters is the media type of the resource -- for ES6 modules it has to be "application/javascript" if memory serves (and there may be other valid media types for modules). URLs are only related to file extensions because you can include something like ".js" or ".ts" (Deno) but it honestly shouldn't matter to a script/module loader because the URL specification is what defines URLs, while the retrieval method would be decided by the protocol (scheme) embedded in the URL, and the type, to repeat this again, of the module, is decided by the _media type of the resource retrieved by the URL, if applicable like with HTTP. Of course, with the "file" scheme, you can parse extension in the URL, but for HTTP it's the wrong thing to do unless you have decided to reject URLs not ending with some ".js" or what have you.
I love node. I used it to build a game server basically from scratch, right down to a custom packet protocol and individual 0's and 1's. It had everything I needed for a true backwoods, ground-up project of enormous scope. It makes programming fun, intuitive, elegant, and fast. If I had to use C#, I would have clawed my eyes out. Thanks man. Don't beat yourself up too much
There should really be a way to pin dependencies. Fixing it on first download is not enough, since that doesn't validate the dependency, and you may still get different versions on different machines.
The biggest problem with NodeJS (for me) are utterly broken streams. Somehow Ryan didn't even mention them. On the GitHub repo, though, he says he's considering async iterators. Hopefully they'll adress this problem in Deno until it's too late again.
Doc Regrets of Ryan Dahl 1. Not sticking with Promises Ryan added and remove Promises from Node. Node.js has many async APIs due to this 2. Security 3. Build system (node-gyp) 4. package.json 5. node_modules 6. Require require("module") without extension `.js` 7j. index.js
the original idea of compiling dart to js is essentially dead for reasons on the other hand hummingbird is probably the best thing they could have done, and might just kill electron in a decade or so if everything goes well (seriously fuck electron)
There is a lot of negativity over his own achievements, personally i think he has done a fantastic job, i love the JavaScript ecosystem, its probably one of my favorites :)
After seeing what happened with Angular 1 and django, I've decided to stop using frameworks all together. I'm now developing everything using the native languages features directly and creating my own abstractions and libraries based on each individual case. I not only got so much better developing, but also I now have the security that my work won't depend on the fate of a new technology that hasn't being put thru the test of time, or worst.. it was an experiment of a talented young individual or company.
