Deno is Coming

the nodejs community is about to get flipped on its head because on May 13th Dino the dinosaur is coming now there's been a lot of confusion around whether Dino is actually a dinosaur or something else like a Loch Ness monster and I'm here to tell you first that he's obviously a dinosaur if you see the Loch Ness monster he is dark he is black and Dino is white he knows definitely a dinosaur so I just wanted to clear that up before we get started so I know half of you have no idea what the heck I'm talking about so we're going to start off with just a quick intro into what Dino actually is and then we're gonna get into the juicier part where we're gonna talk about what I actually think about Dino and the effects it's gonna have on the nodejs community all right so Dino is a secure runtime for both typescript and JavaScript but I can't just like to think of it as nodejs with some different rules and the guy that made no js' Ryan Dahl also is making Dino and the idea was he made no GS but as he made that code in the design decisions on how he structured everything was from a long time ago and so when he looks back on right now he's like oh my code is disgusting and that makes sense that happens to every single programmer but the problem is not every programmer has their code run on like 12 billion people's computers every day and so the problem now is he can't really fix nodejs because they all rely on legacy compatibility etc etc so what he's doing instead is he creating a whole new thing with like all the bright things and you know improvements that he learned that he wish he could put in node so that's some context for you now let's get into nodejs and Dino what are the differences or at least some of the big ones so the first thing is Dino is secure by default and what that means in practice is if I run a Dino program it's not gonna have any permissions by default and so when I run something that tries to access say the network or my file system that's going to error out unless I explicitly give it permission by passing in a flag to the CEO I compare this with a node where if I just run a node program it can do whatever it wants and it has permissions to do everything this is important because a lot of times you're not actually running just your own code if you install an NPM package or running a CLI from somewhere else you didn't write that code you don't know what's in that code so theoretically it could do anything at once on your computer and so Dino restricts that and so it's secure next the way Dino decided to build its API for kind of the standard functions that you use is they try to be compatible with the browser and so they have things like fetch and set interval and set timeout and a whole bunch of other stuff that is actually from the browser and that works the same way as the browser the nice thing about this is now if you know the browser functions and our front-end engineer a lot of your knowledge carries over to Dino and you can use that and vice versa if I know Dino and the functions involved in that I can use those in the browser and so you can share knowledge back and forth which is just very convenient next they have a ton of stuff that's just built into Dino and they have standards so just to name a few of them they have a test runner they have a file watcher they have a bundler and there's a ton of other stuff that they just have baked in and so you have no demon and jest and webpack just kind of mashed in there and you don't have to install all these different tools to get your code working there's two advantages to this approach one everyone's gonna be using the same tooling so if I'm using Dino and you're using Dino we're both using the same bundler and then secondly usually these tools will integrate nicely together sometimes when we have two unrelated tools that we need to mesh in the same ecosystem it gets a little ugly but theoretically if Dino knows about the bundler and the file watcher it can do things that mesh together quite nicely and the biggest change of all is they're getting rid of node modules package.json and NPM so if you want to use somebody else's code you no longer use those things instead they put their code on a place that just serves files and then in Dino you just say I want to import to this URL and you can just import code directly from a URL now and the rationale behind this is number one node modules and Paget ace on the entire thing is one bloated right there's a bunch of other stuff in packages on besides just your dependencies and secondly that hopes traction is quite unnecessary and in addition to that we're using NPM as a central place where we all download packages so the idea is now I can just point to really any server that hosts a file and I can use that for my code also related to this when you import from URLs or from just local files you need to now include the file extension so a node right now you can just leave that off or you can do stuff like not include the word slash index at the end and it will infer these things so now they're getting rid of that and the idea behind that is it's very ambiguous you don't know if they meant slash index dot JSP you meant tsx all these extensions that the resolver has the guests on basically it's just gone we know exactly what file you mean to reference and there's a bunch of other stuff that Dino does but these are the major points and didn't wanna make this too much an introduction or a comprehensive one anyway into Dino because there's a lot to it and to go check out Dino dot land if you're more interested in that stuff because what I want to get to is kind of my thoughts on it and what this means for nodejs ok so I'm actually quite surprised after learning more about Dino that for myself when I'm looking at what it offers I'm kind of indifferent for a lot of the things like don't get me wrong like I think they're very positive but at the same time in the current system of how nodejs works I'm not suffering too bad like who I was going to rate my developer experience with nodejs maybe I give it like somewhere around here right and when I heard about Dino I was like wow that sounds kind of life-changing and there's so much hype around it I felt like you know was gonna be like this for the developer experience but then when I learned more about it and everything it had to offer I actually kind of got like less excited about it and I kind of feel like nodejs is here and Dino's like here it's a step up from node but it doesn't feel like a giant leap ahead and I think one of the main reasons I'm feeling this way is there's not like a super sexy feature to flex or show off to my friends who are still using nodejs like what am I supposed to do and I'm supposed to be like yo bro you see that import statement yeah you jelly that has a file extension at the end zero ambiguity no he's just going to look at maybe like us so I don't think that what and I don't think this would be a big deal I don't think you always need like sexy features if I could just swap no doubt for Dino if it was just a swap easy to do thing then yeah I'm fine with that but the problem is I think there's going to be a lot of friction with the way that Dino handles third-party modules there are a ton of NPM packages right now which are incompatible with Dino for one reason or another either they're using require syntax and module that exports or they're using a patch of JSON file to handle dependencies and they're not including file extensions when they're importing stuff or they're just using an API or a function that is specific to node J s and because they don't work in Dino because you know is not supporting that right now it's kind of awkward no it does sound like there are some workarounds to get some existing NPM packages to work and Dino so one of these things is called JSP m and not allow you to convert common J's format into es M which will work better with Dino but the thing is as a developer I don't want to care about these things like I don't want to go look up my package and see hmm my package is not compatible with Dino because of x y&z reasons so in that case I need to go use this workaround to get it to work I don't want to even think about that stuff instead Dino should just handle all this stuff for me like especially because they like built-in tooling they should have a tool where I can tell it hey I want this NPM package or I want to use this in my code and then what it will do is it'll try converting automatically the entire tree of dependencies because remember it's not just that package I need like switched over to Dino I need all of its dependencies switched over to Dino as well so the tool will try to do that and underneath the hood it can do whatever it wants to try to figure out what workarounds it needs to get it to work with Dino's module system and I don't even have to think about that stuff and maybe in some cases it's not possible to automatically do this sort of thing and no that's totally fine just throw an error like hey sorry can automatically handle this in those cases then we're gonna have to just manly pour it over those libraries which again kind of sucks I don't know how many cases is gonna come up for but like we have that exact same Lane and it feels like we're just taking the exact same code and then just like switching up a few imports to get to work it just feels weird to have to do that I'm thinking the NPM packages that just have nothing to do with nodejs are gonna be the easiest to automatically switch over and make it compatible with Dino right now but the ones that need nodejs api's their functions are gonna be a little bit harder because right now Dino does not have compatibility with node so when that comes because they are working on it then I think it'll be very possible to have packages that work in both node.js and Dino and people don't need to think about that sort of thing I think that is the ideal future where I can just write an NPM package and I don't have to think whether this is going to be used in node or if it's gonna be used in Dino now I did see a project with similar intentions called Dino Fi and it was more aimed at a library off theirs though or you could make your MPM package compatible with Dino but I'm not really a fan of that approach because I think it'll cause a lot of turning the no GS ecosystem if all these library authors now have to start supporting Dino as well as like an output instead I think it'd be really nice if Dino can handle that and Dino just like sucks in the NPM package and then handles it and I just have no idea what's gonna happen with these node.js packages which are not written necessarily in JavaScript they're written in C++ like for example the Sharpe library which you can handle images I really like this one I use this in my projects I'm not really sure how this works in a Dino world if it's easy to pull that in or if they're gonna have to do a lot of work on the library authors and to get this to work with Dino so I'm not sure if we're just gonna lose these things and they're gonna need to be re-implemented in Dino land but either way there's just not that many NPM packages like that so if Dino can make it dead simple for developers to include like 90% of NPM packages I think Dino is gonna get real popular but as things stand I think Dino is gonna have some trouble just converting people over from nodejs like here's what I imagine happening so you go up to your boss and you're like hey can we use Dino for our next project and he's gonna be like mmm about this why should we use this and then you inform him that's gonna be more secure and we can kind of set the permissions that our program runs under in which case he counters by saying you know what for this project we're just gonna turn on all permissions anyway you then inform him that it has a much nicer API and is compatible with the browser your boss looks at you and then says mmm what's an API at this point you're kind of regretting opening your mouth but either way you trudge through and try your best to explain it to them needless to say he doesn't quite get convinced that it's all that important so you go on to tell them about the module system in DINO and let them know that all you have to do is point at a year route to get other people's code there is no unnecessary abstraction and I also can put file extensions that way there is zero ambiguity your boss replies hmm these URLs and file extensions just kind of look ugly in the imports and how does this help our kpi's at this point you know you've blundered and you're about to be put in checkmate as soon as you tell him about how you actually need to pour it over some modules just to get them compatible with you know so they're giving your boss a checkmate you surrender you don't give them that satisfaction and you just grudgingly tell him that ya know GS is gonna be fine for the next project unfortunately for you your boss wasn't very happy with your attitude and next thing you know you're being placed on a legacy angular code base and this leads to a spiraling deep depression and eventually just become a care farmer but this is just my two cents on D no I think it has a ton of potential and I am sure the internals of Dino are just like a thousand times cleaner and better than node and with some right decisions from the Dino team I see it replacing a lot of nodejs usage now for myself until Dino has kind of some stuff in place they'll automatically handle and PM modules and I don't even have to worry or think or sweat about these sort of things I'm not really gonna migrate anything over to Dino or spend too much time with it I do think it's going to kind of nice to build like one-off utilities or little scripts I think it's just gonna be a nicer environment than node but other than that that is kind of how I plan to use Dino for the time being you

Channel: Ben Awad

Views: 161,471

Keywords:

Id: P6cInhvnX9E

Length: 13min 48sec (828 seconds)

Published: Fri May 08 2020