181–190 of 245 posts
I'm not so familiar with web development and don't quite understand where this fits in. I know I can run JS in my browser. I know I can run JS on a web server using node.js. I know I can compile Typescript to JS. So how does Deno fit in and what is the added value? Not trying to be negative, just curious.
Earlier quoted context omitted.
Indeed. I remember that, I have been using node since the very early days, and switched to it for precisely that reason--that I could use the same language through my web application. Nevertheless, when we did get those modern web API, Node was slow to change or adapt them, although, it's doing its best now. In case of Deno, I hope they just stick to following the standards and changing with them. They might not, I c…
Overall this is true. And beyond that the TypeScript team is heavily involved in TC39, and quite a lot of TC39 proposals are specifically designed to be enhanced by TS. That said... There are a few longstanding incompatibilities/footguns. And they’re likely to remain due to widespread use, even though most are controversial. Off the top of my head: - access control annotations (`private` which is compile time only vs…
I'd love to use deno, but I really don't understand the point deno's module/package system. The standard practice of deps.ts/dev_deps.ts as described in the docs[1] just seems absolutely asinine to me. Importing everything into one scope and then re-exporting from one file just seems like an awful hack. What do you do if two libraries have functions with the same name? Do you namespace them yourself, or export an obj…
If dependencies are imports from URLs, how does one audit their dependencies? If a server gets hacked those TS can be replaced with malicious versions. In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release. Does demo generate some type of file that keeps a hash of all downloaded imports to verify against the next time tho…
This is only true as long as you trust NPM. If they were hacked or taken over by a malicious actor, packages could be modified unbeknownst to you.
Does the single executable distribution change anything? node/python/google-chrome are all single executable programs as far as the users are concerned.
I'd love to use deno, but I really don't understand the point deno's module/package system. The standard practice of deps.ts/dev_deps.ts as described in the docs[1] just seems absolutely asinine to me. Importing everything into one scope and then re-exporting from one file just seems like an awful hack. What do you do if two libraries have functions with the same name? Do you namespace them yourself, or export an obj…
The issue is that JavaScript (by extension TypeScript) doesn't have the concept of folders. You can only import a single file per import statement. Developers create "barrel" files that allow them to re-export all of the important stuff in a folder externally. This allows for namespacing // foo/index.ts export * from './foobar' // main.ts import * as foo from './foo/index' new foo.Foobar() Or use destructured imports…
It would be much easier if it was one namespace like in Node.js require. eg. var Foo = await requires("foo", {fs: "/home/user"})
Node.js modules are pretty much perfect besides the security flaws.
I'm not so familiar with web development and don't quite understand where this fits in. I know I can run JS in my browser. I know I can run JS on a web server using node.js. I know I can compile Typescript to JS. So how does Deno fit in and what is the added value? Not trying to be negative, just curious.
I also had that question in my mind until I tried deno a couple of weeks ago. There are a few great things I've discovered that IMO makes it a great alternative to node.js:
- Deno + std library has a lot of batteries included. Have you tried creating a web browser project with node.js recently? Just adding a few basic dependecies to compile and bundle your code will leave you with node_modules having hundreds of other dependencies. With recent cases of malware slipping into npm dependencies tree, I'm a bit fearful of starting a new project and infecting my computer (not too crazy imagining that one of the developers of those hundreds of deps will be careless with their SSH keys). "deno bundle" basically solves that for me.
- I can't think of a reason why I would not use typescript these days. Not having to install tsc or create a tsconfig.json is a killer feature for me. Not to mention compiling ts with Deno feels really fast (maybe because they don't have to load the whole typescript compiler into the JS VM on every run?).
- As a consequence of Deno's fast startup + tsc support + great standard library + automatic dependency download, I've found a vastly superior alternative to python for writing quick and dirty scripts for automating various tasks. So for me Deno is not just for writing servers, it is also for using typescript as a script language for automating my desktop and server workflows.
These are just a few things that stand out for me, there's certainty more to Deno than it may initially appear.
Just realized that de-no is reverse of no-de
Earlier quoted context omitted.
Their companion CDN (and namesake umbrella parent company) is also a first class part of Snowpack. However using CDNs in the browser has some big trade offs. Besides obvious concerns sending any data to consolidated third parties, it’s actually a performance detriment now that browsers are caching per origin. Used to be, using a CDN got you more likely cache hits and better perf on N+1 requests. Now you definitely do…
There has always been an extra DNS lookup wirh a CDN. Thats even the point of the CDN since based on where you are, you will be served from a location as physically close to you as possible. Where did you get the information from that CDNs arent as good as they used to be?
For scenarios that were previously popular like using the jQuery CDN, you won't get the benefit of the user having jQuery in their cache from another website. You will however still get the proximity benefit you describe. CDNs are obviously still quite useful, just not for getting cache hits on popular libraries.
https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
Earlier quoted context omitted.
it seems like libraries can't use import maps though, right? the final binary can provide that flag, but is there a way for library dependencies to specify their own import maps? the spec [1] has support for scoping, but I didn't see a way to integrate that with the Deno loader. [1] https://github.com/WICG/import-maps#scoping-examples
Yeah, libraries can't use import maps because import maps are not extensible