I learned Javascript and I’m thankful to js. Now, I can finally learn a low level language. I used it as a tool to learn to code and That’s where I want to draw the line.
You can actually compile deno to a self contained executable with "deno compile". But that feature is unstable and I think that npm support will soon be coming to that feature
Eh, while all the compat stuff is available for the npm modules, they’re not available in your code, aka you’ll never have to use module.exports/require and such.
1:04 Is this a good thing? Where do you store (serializible) project metadata in deno codebases? While `package.json` can become an unwieldy dumping ground for unrelated keys, it also provides a place to store serializible data which would be all over the codebase otherwise. How does deno scope local and global packages without `node_modules`?
You're comment actually made me think quite a bit. Some really good questions you're asking here. After digging around a bit, I think the answer is yes, it's a good thing that package.json is gone. And no, I don't think you can install modules globally/locally for deno, since that's not how deno works. I also can't think of a scenario where globally/locally installed modules are more sensible than deno's default sandboxing with setting explicit permissions when required, but am happy to change my mind, if you have one :). I could probably not explain it better than Ryan Dahl does himself in the talk he gave on why Deno came to exist in the first place: ua-cam.com/video/M3BM9TB-8yA/v-deo.html
babel has a standalone package that does runtime transpilation, meaning you can write JSX/TS/SCSS and the transpilation step will happen after DOM load, directly in the browser.
@@1000percent1000 I know but the original commenter does not want to introduce a JavaScript runtime environment with proper bundlers and transpilers so it's always an option.
No just export all your dependencies in a deps.ts file and then use it in any of your project files That's how a standard deno project looks like, ofc they don't use import in every file with a URL that long Just make a central deps file exporting all the dependcies
I wonder what's the best way to manage package versions in deno. If you use the package more than once and wish to change its version, you have to change it across the whole app. I've seen some ideas with declaring a single file that imports a versioned package and reexports it for the app. I've also seen some native way to keep track of versions in importMap, though I've had trouble providing types for packages that don't ship with them. Any idea?
@@vintprox what was also bothering me a bit is that one of the selling points of deno (even mentioned in this video) is that it doesn't need a package.json file. In my eyes, importMap is pretty much the same package.json file...
I don’t like seeing npm written in the source code. I would’ve liked to have a config file that would point to the npm registry url instead. Sort of what gradle does. Maybe could’ve leveraged import maps for that.
If we can already import packages from any registry using import maps, then why have they added the “npm:” import to deno? Seems redundant unless there’s some npm-specific reason for not using import maps. Why should deno make an exception for npm?
Seems like the way to go to me. Although the desire to call it "package.ts" is a little bit strong... at that point you kind of lose the "advantage" of not having a package.json
Great and all that you can specify package using links inline but the reason we have a package-lock.json. What happens when I want reproducable builds?
This is great to hear but I don't think I'll be switching anytime soon because it doesn't really have the community & ecosystem Node has. At least not yet.
I already switched, as soon as Deno 1.0 launched, and I'm definitely NOT coming back to insecure node. The security model in Deno is just that important.
So. If I use Lodash functions in multiple files in my project I either have to omit the version and hope the latest doesn't break stuff or set the version in every import and then update each and every import if I want to upgrade Lodash? (You can replace Lodash with any other 3rd-party library if you don't like Lodash.)
Could say the same about creating a backend with node, being with express or even Nest, no gains with tons of extra work. And where do you see the extra work from this video ?
@@fltfathin Ryan literally announced deno by apologizing for strange packaging patterns. Let's review. He said that Isaac created package.json, but he (Ryan) designed `require` around it. Making it mandatory. He said that he regretted how node_modules is resolved. Then finally, the point that "index.js" became the default entrypoint.
I think Ryan was dead wrong about being upset about node_modules being local and vendored-by-default. It's a very good pattern. I can't stand using pip because I need extra tools to isolate my dependencies. Tell me the last time you used python with more than two dependencies that you didn't reach for a virtual environment.
@@codeman99-dev when working with JVM languages, gradle does this too by containing the cached deps in the .gradle folder, honestly don't see what is so wrong about node_modules, the package.json is definitely something that could use some work though
it is cached locally, otherwise it wouldn't be called a cache. It is just not cached within the project root but rather to a global directory somewhere in your PC. That being said, you can get a node-like node_modules by executing the commands with --node-modules-dir
All I need is to figure out a central way to update all packages used in deno without need to go to every file. Package json might be overused, but it still serves as a central location to manage app dependencies.
@@crowlkats whoops you’re right, but If I’m not mistaken the formatting that deno does come with a default of 2 spaces (and I just found that a bit cursed)
I doubt it solves peer-dependencies problem and I am already tired of reverting package updates because of TS compilation errors. I'll give it a pass unless someone can prove Deno can handle a large Nuxt app and monorepo.
Would honestly be using deno a lot more if they had backwards compatibility planned as bun does... Having to port a project to a new runtime altogether is painful, and a lot of packages do not really support deno well.
Deno also has a built in test runner and a testing framework that is pretty good straight out of the box. It also has the linter built into it and the lsp server too. I'm loving this a heck ton over node js which I never touched because it was ugly from the beginning imo Deno's imports however are trash because obviously it's hard to see what's being imported from a single place. Yes import maps are there but there's no enforcement to only allow imports from the map. It is very well possible to import things outside of the import map
Yeah I like deno's imports but I don't like the idea of having to copy and paste the exact same import everywhere in my code, especially with version limits
My experience with deno is really bad. I wanted to use it with firebase admin package. Even though I tried to setup it under the guidance of people from the discord server, i couldn't manage to set it up. They also couldn't help about this. So i ended up with netlify functions which is pretty easy if you compare with deno.
Way does every new JS engine have to do everything different? I don't like how there are so many packaging schemas that aren't interoperable. And I don't talk about the packages itself or their availability (although imo npm support _should_ always be included). If all of these engines do the same thing in the end (running my stupidly bad JS) why can't make my project for one engine and then run it with another. Currently, you have to have Deno installed to run a project written for Deno. You have to have bun installed to run a project written for bun. In Java, every SDK/JDK will take every project; in Python, PyPy will at least try to run your code (and probably succeeds if it's a simple script). I don't think the package.json is a bad thing and Deno and bun should at least have a fallback to support it. Else, they will probably never be used more than Node. IMO, having a file describing third-party dependencies for a project using them is an absolute must-have. pom.xml exist, requirements.txt exist and even for some C/C++ projects a README exists, telling you which libs to install first. BTW: Could you maybe do a video about Node, bun and Deno? Like for which use case which engine to choose, how good is the speedup in "real" applications (not benchmarks) and how and if it's possible to "convert" projects for another engine.
the convenience of node makes it incredibly difficult for me to ever consider switching. this is a 3min video to show us how to accomplish the equivalent of "npm install x"
@@lunafoxfire Just like the guy above you clearly missed the point of the video, it's not about the fact that you don't need to install but about the fact that deno is now compatible with npm packages. Your smartness is indeed incredible.
I mean do you really think that Deno is only addressing one missing feature ? The developer behind it is the creator of Node for your information, he's just been addressing the flaws of his previous work.
Deno is fast and more mature. If you want the reasons just look out at the flaws the creator of Deno, who is also the creator of node, is trying to fix.
It's definitely interesting but considering there's no place to define installed packaged besides imports themselves I'd imagine auto-imports wouldn't be possible...nor can I get over thr syntax of the type directive 🤮
The problem with deno npm support that it does not work properly as expected. You will struggle and suffer. The only application for deno is microservice, with low level abstractions. Do not ever think about wring a monolith with
I mean same for node, if you want a monolith you use Rails, Django, Laravel, Phoenix, Spring or whatever, which are battle tested fully featured framework that don't require you to import tons of (sometimes half backed) dependencies to build your backend. The closest popular option Node has to that is Nest I guess, which is nowhere close to the ones quoted above
Proton works really nicely, and it's not steamOS but just Linux, given some limitations like non compatible anti cheats etc, you're obviously exaggerating. And If you're a Dev and can't follow 3 instructions on proton DB then that's problematic, it's easier than your basic 3 liners "get started" for any npm package.
As soon as I saw you import Express without even installing it I knew it was over❤
I learned Javascript and I’m thankful to js. Now, I can finally learn a low level language. I used it as a tool to learn to code and That’s where I want to draw the line.
Deno: "I have become the very thing I swore to destroy"
@@Joso997 no! Not even close!! Ignorant!!!!
Deno is awesome! I use it whenever I can
You can actually compile deno to a self contained executable with "deno compile".
But that feature is unstable and I think that npm support will soon be coming to that feature
They said that in the video
It produces a huge binary, but sure it's there if you want it.
Yay Deno, thanks for the video :)
Thanks for the awesome content!
and the start of deno becoming the same kind of mess as node begins, with native and npm packages mingling together
I think nodejs is kinda inevitable at this point. Try running away, and it circle back to it.
And so a new js runtime shall be born to right all wrongs, again
There's no way to fix this JS mess.
I sometimes gets the childish thought why not design a language with pros of JS and remove the cons.
@@jitxhere like people haven't done that already
Eh, while all the compat stuff is available for the npm modules, they’re not available in your code, aka you’ll never have to use module.exports/require and such.
1:04
Is this a good thing? Where do you store (serializible) project metadata in deno codebases? While `package.json` can become an unwieldy dumping ground for unrelated keys, it also provides a place to store serializible data which would be all over the codebase otherwise.
How does deno scope local and global packages without `node_modules`?
You're comment actually made me think quite a bit. Some really good questions you're asking here.
After digging around a bit, I think the answer is yes, it's a good thing that package.json is gone. And no, I don't think you can install modules globally/locally for deno, since that's not how deno works. I also can't think of a scenario where globally/locally installed modules are more sensible than deno's default sandboxing with setting explicit permissions when required, but am happy to change my mind, if you have one :).
I could probably not explain it better than Ryan Dahl does himself in the talk he gave on why Deno came to exist in the first place:
ua-cam.com/video/M3BM9TB-8yA/v-deo.html
Dino is taking so much space 🎉
I like to use Vite because it supports scss files right in the head of html. But Vite loses support for scss files when using Deno.
babel has a standalone package that does runtime transpilation, meaning you can write JSX/TS/SCSS and the transpilation step will happen after DOM load, directly in the browser.
@@charlesm.2604 great even more overhead for the end user, i get what your point is but that is not a drop in replacement for Vite in most situations
@@charlesm.2604 sounds horrible
@@1000percent1000 I know but the original commenter does not want to introduce a JavaScript runtime environment with proper bundlers and transpilers so it's always an option.
@@paradiseexpress3639 It is what it is
Never heard of Deno, I might need to check it out.
Thanks for that caveat. Relay, only the de rigeur graphql library, happens to be one of those non-esm libraries that don't work with freshjs
Great! I'll hang around a few more years and see if it's worth transitioning to Deno for any production use.
I use it on my main project for some features. it works well. :D
I was just about to ask if Deno is still alive. I got my answer :D
So, here is a problem. If you are using a NPM package in 20 different files, you need to change the version number every time in all of the files?
No just export all your dependencies in a deps.ts file and then use it in any of your project files
That's how a standard deno project looks like, ofc they don't use import in every file with a URL that long
Just make a central deps file exporting all the dependcies
@@ashishbhushan7837 So it's basically asking you to create your own package.json
Nope just a typescript/javascript file with some
`export {foo} from "bar"`
statements that's it👍
@@ashishbhushan7837yeah but that is literally package.json though, just a diff syntax
Only it's not mandatory and you need a way in any language to maintain all your packages. Don't we?
I hope Deno will be popular soon, its just much better. The natural Problem of a huge echosystem world is that inovations is very slow
Time to switch my side projects to deno ❤️
The sequel to framework hell, runtime hell.
@@fayenotfaye Can even combine for classic `m * n` problem!
Now I am convinced JS is cursed
Based on the trend of the comments, you probably should have covered import maps in this video.
I wonder what's the best way to manage package versions in deno. If you use the package more than once and wish to change its version, you have to change it across the whole app. I've seen some ideas with declaring a single file that imports a versioned package and reexports it for the app. I've also seen some native way to keep track of versions in importMap, though I've had trouble providing types for packages that don't ship with them. Any idea?
I would suggest import maps
It’s literally in the Deno docs. Import maps.
@@richardrapstine9014 any idea about the packages with missing types?
@@vincaslt That's fair point... As long as I observe, there is no import map aliasing for @deno-types comments, which is a shame.
@@vintprox what was also bothering me a bit is that one of the selling points of deno (even mentioned in this video) is that it doesn't need a package.json file.
In my eyes, importMap is pretty much the same package.json file...
Really cool progress, but I'm still gonna wait before switching.
Got burned switching build tools way too much in the past.
I don’t like seeing npm written in the source code. I would’ve liked to have a config file that would point to the npm registry url instead. Sort of what gradle does. Maybe could’ve leveraged import maps for that.
You can already do that in import maps in Deno!
Import maps are already a thing in Deno. They even have a handy little tutorial on them.
If we can already import packages from any registry using import maps, then why have they added the “npm:” import to deno? Seems redundant unless there’s some npm-specific reason for not using import maps. Why should deno make an exception for npm?
@@vikingthedude because npm is so popular
Now this is pretty cool
What would happen if you use multiple versions of the same lib in your app?
Wouldn’t you have to specify the version like everywhere? Or can you just have a “consts” faux package.json file that imports the types?
Seems like the way to go to me. Although the desire to call it "package.ts" is a little bit strong... at that point you kind of lose the "advantage" of not having a package.json
You can either use a deps.ts file or an import map. Deno also has a deno.lock file
Having a package json is kinda nice though to see what something is using
If i was at a gunpoint and had to choose a javascript backend probably deno would be it!
Great and all that you can specify package using links inline but the reason we have a package-lock.json. What happens when I want reproducable builds?
every fireship video starts with the tools the new package offers . every fireship video ends with a diss on JS
How and where do you authenticate against private npm repo?
But what about lockfiles?
Probably there's a way to fix it, but we'll need to specify the package version on every file that we import the dependence?
Very good
I wonder what the difference between bun and deno
Please talk about fuseopen and fuse programming language, thanks
what about elixir programming language?
I recently installed rustc and cargo and it's a c++ killer
Does deno have any meaningful support in the cloud?
This is great to hear but I don't think I'll be switching anytime soon because it doesn't really have the community & ecosystem Node has. At least not yet.
I already switched, as soon as Deno 1.0 launched, and I'm definitely NOT coming back to insecure node. The security model in Deno is just that important.
And deno deploy is absolutely magnificent
Nice!
It is better of pnpm?
Where are the packages installed then?
So Deno + Google Cloud Run or Lambdas works better or worse than node?, given the caching of the libraries.
can i use it on lambda?
So. If I use Lodash functions in multiple files in my project I either have to omit the version and hope the latest doesn't break stuff or set the version in every import and then update each and every import if I want to upgrade Lodash? (You can replace Lodash with any other 3rd-party library if you don't like Lodash.)
Does Deno let you set permission per-NPM-package yet? Or do the permission still apply to your entire program?
Am I supposed to rebuild everything with deno now?
1:38 the server is running on port 6969, and the browser is connected to port 4000? magic!!
It's using reverse proxy by default, it's actually magic! Except the ports are always randomized...
so much extra work for such little gain lol
Could say the same about creating a backend with node, being with express or even Nest, no gains with tons of extra work.
And where do you see the extra work from this video ?
deno is becoming that one thing it swore to destroy
Pretty sure npm wasn't part of nodejs in the beginning hence the awful choices on packaging.
@@fltfathin Ryan literally announced deno by apologizing for strange packaging patterns.
Let's review.
He said that Isaac created package.json, but he (Ryan) designed `require` around it. Making it mandatory.
He said that he regretted how node_modules is resolved.
Then finally, the point that "index.js" became the default entrypoint.
I think Ryan was dead wrong about being upset about node_modules being local and vendored-by-default. It's a very good pattern. I can't stand using pip because I need extra tools to isolate my dependencies.
Tell me the last time you used python with more than two dependencies that you didn't reach for a virtual environment.
@@codeman99-dev when working with JVM languages, gradle does this too by containing the cached deps in the .gradle folder, honestly don't see what is so wrong about node_modules, the package.json is definitely something that could use some work though
I think C# dotnet has the best package system(nuget) along with Rust cargo. It's a pleasure to work with
seems like a lot of excess work for what? minor speed boost. do you even get huge perf benefits with their backwards compatbility?
bun is a sizable speed boost. deno is similar if not slightly slower than node. I dont think performance improvement is part of deno's mission
can it like, cache the packages locally at least? My internet access is unreliable, so I don't know if this always-online approach is for me
it is cached locally, otherwise it wouldn't be called a cache. It is just not cached within the project root but rather to a global directory somewhere in your PC. That being said, you can get a node-like node_modules by executing the commands with --node-modules-dir
How to deploy sveltekit project to firebase and host
more deno content!!
All I need is to figure out a central way to update all packages used in deno without need to go to every file. Package json might be overused, but it still serves as a central location to manage app dependencies.
~~If only we had a central point to manage configs~~
export express in a file maybe
what about bun?
Firebase zooming in on "Enable Deno linting?", and just selecting "no" is kinda funny 0:49
linting doesnt have to do with formatting.
@@crowlkats whoops you’re right, but If I’m not mistaken the formatting that deno does come with a default of 2 spaces (and I just found that a bit cursed)
tbh npm packages are usually also have git repos, people can just use the github repos and etc
Make a deno crash course pls
Does npm import support for import map?
Nice
How about size of executables? Is it any small?
Deno still uses V8 so it won’t be small since V8 will be included
@@vin5718 There is not much point to it then, we have nexe in nodejs which is kinda same.
"no Juan understands me" --Señor Developer
The thumbnail is a crack up
nice
"no package.json" file bruh, how do you even keep track of dependencies thats installed
each package has a package.json that defines deps.
nice nice port
Next video: Deno vs Bun
Could you do a rust+deno vs. zig+bun detailed comparison and evaluation? Thanks.
Certain packages dont work tho
I've kept an eye on Deno for my team but until we have Angular and Cypress support we are are SOL
Bro use port 6969, He is one of mines
i like node
"Port of your choice". I like your choice, though. 😂
Seems to be npm with extra steps
Smells like cop-out, am I right?
I doubt it solves peer-dependencies problem and I am already tired of reverting package updates because of TS compilation errors.
I'll give it a pass unless someone can prove Deno can handle a large Nuxt app and monorepo.
Upd: Second
First🎉🎉🎉
Would honestly be using deno a lot more if they had backwards compatibility planned as bun does... Having to port a project to a new runtime altogether is painful, and a lot of packages do not really support deno well.
Deno also has a built in test runner and a testing framework that is pretty good straight out of the box.
It also has the linter built into it and the lsp server too.
I'm loving this a heck ton over node js which I never touched because it was ugly from the beginning imo
Deno's imports however are trash because obviously it's hard to see what's being imported from a single place. Yes import maps are there but there's no enforcement to only allow imports from the map. It is very well possible to import things outside of the import map
thanks, same impression with imports, bit confusing at first
Yeah I like deno's imports but I don't like the idea of having to copy and paste the exact same import everywhere in my code, especially with version limits
Deno looks great, but am I the only one to find package.json helpful?
Just use golang
Yeah it looks like a big loop... Unless I don't really understand this..
Cool. Now we can keep our projects in the cloud without worrying about syncing thousands of unused modules. … less I’m misunderstanding this here.
My experience with deno is really bad. I wanted to use it with firebase admin package. Even though I tried to setup it under the guidance of people from the discord server, i couldn't manage to set it up. They also couldn't help about this. So i ended up with netlify functions which is pretty easy if you compare with deno.
Way does every new JS engine have to do everything different? I don't like how there are so many packaging schemas that aren't interoperable. And I don't talk about the packages itself or their availability (although imo npm support _should_ always be included).
If all of these engines do the same thing in the end (running my stupidly bad JS) why can't make my project for one engine and then run it with another. Currently, you have to have Deno installed to run a project written for Deno. You have to have bun installed to run a project written for bun.
In Java, every SDK/JDK will take every project; in Python, PyPy will at least try to run your code (and probably succeeds if it's a simple script).
I don't think the package.json is a bad thing and Deno and bun should at least have a fallback to support it. Else, they will probably never be used more than Node. IMO, having a file describing third-party dependencies for a project using them is an absolute must-have. pom.xml exist, requirements.txt exist and even for some C/C++ projects a README exists, telling you which libs to install first.
BTW: Could you maybe do a video about Node, bun and Deno? Like for which use case which engine to choose, how good is the speedup in "real" applications (not benchmarks) and how and if it's possible to "convert" projects for another engine.
Fucking hell, this is how Node should have handled it all along
the convenience of node makes it incredibly difficult for me to ever consider switching. this is a 3min video to show us how to accomplish the equivalent of "npm install x"
0:58 achieves the install and import in a single line. In node you have to npm install and then go into your file to import.
@@ShadoFXPerino wow. amazing. revolutionary. incredible.
also totally pointless.
@@lunafoxfire Just like the guy above you clearly missed the point of the video, it's not about the fact that you don't need to install but about the fact that deno is now compatible with npm packages.
Your smartness is indeed incredible.
Almost there
Wow. I’m gonna start using deno for my backend scripts that perform actions on the DB. Hopefully it has postgresql support.
0:28 which is why people shouldn't code a whole framework to address a single missing feature of an existing framework...
I mean do you really think that Deno is only addressing one missing feature ?
The developer behind it is the creator of Node for your information, he's just been addressing the flaws of his previous work.
Not bad, but still I don't see any reason to use Deno. Bun has huge advantage of being fast. Deno does not.
Deno is fast and more mature. If you want the reasons just look out at the flaws the creator of Deno, who is also the creator of node, is trying to fix.
It's definitely interesting but considering there's no place to define installed packaged besides imports themselves I'd imagine auto-imports wouldn't be possible...nor can I get over thr syntax of the type directive 🤮
you can use an import map to define your dependencies.
Comments as code? We've come full circle with 00's Java
so.... deno or bun
Don’t need Node? No Node nerd need? Need Node? No!? ∗Nods∗
Missing local package is just a huge no from me. Deno will never replace anything just because of that. Staying in its nitch.
I am not sure I understand what you mean. could you clarify?
The problem with deno npm support that it does not work properly as expected. You will struggle and suffer. The only application for deno is microservice, with low level abstractions. Do not ever think about wring a monolith with
I mean same for node, if you want a monolith you use Rails, Django, Laravel, Phoenix, Spring or whatever, which are battle tested fully featured framework that don't require you to import tons of (sometimes half backed) dependencies to build your backend.
The closest popular option Node has to that is Nest I guess, which is nowhere close to the ones quoted above
Deno "supporting" npm is like SteamOS "supporting" Windows games: it... kinda works ... Sometimes ... If you tweak them ... And you are lucky
Proton works really nicely, and it's not steamOS but just Linux, given some limitations like non compatible anti cheats etc, you're obviously exaggerating.
And If you're a Dev and can't follow 3 instructions on proton DB then that's problematic, it's easier than your basic 3 liners "get started" for any npm package.