The key is, can it re-use all those npm modules? otherwise the ecosystem is too large to take on these days.
Deno 1.0
541–550 of 598 posts
Re: Deno 1.0
#542Earlier quoted context omitted.
Allow me to provide an extremely relevant example (medium sized code base). About 100 python files, each one approximately 500-1000 lines long. Imagine in each one of these files, there are 10 unique imports. If they are URLs (with version encoded in the URL): - How are you going to pin the dependencies? - How do you know 100 files are using the same exact version of the library? - How are you going to refactor depen…
The Deno docs recommend creating a deps.ts file for your project (and it could be shared among multiple projects), which exports all your dependencies. Then in your application code, instead of importing from the long and unwieldy external URL, import everything from deps.ts, e.g.: // deps.ts export { assert, assertEquals, assertStrContains, } from "https://deno.land/std/testing/asserts.ts"; And then, in your applica…
This was my first instinct about how I'd go about this as well. I actually do something similar when working with node modules from npm.
Let's say I needed a `leftpad` lib from npm - it would be imported and re-exported from `./lib/leftpad.js` and my codebase would import leftpad from `./lib`, not by its npm package name. If / when a better (faster, more secure, whatever) lib named `padleft` appears I would just import the other one in `./lib/leftpad.js` and be done. If it had incompatible API (say, reversed order of arguments) I would wrap it in a function that accepts the original order and calls padleft with the arguments reversed so I wouldn't have to refactor imports and calls in multiple places across the project.
Re: Deno 1.0
#543This is interesting. Can you ship the Deno runtime with your runtime code? That's the thing that kills me about Javascript; having to assume the consumer has a runtime setup.
Compiling to a single binary is on the roadmap, but was dropped from 1.0
Great, thx, I'll definitely be keeping an eye on this project!
Re: Deno 1.0
#544Earlier quoted context omitted.
setTimeout is non-standard JavaScript too but I bet your code base has multiple instances of its usage.
Is it? It's on every browser I know.
Re: Deno 1.0
#545Installed and run the REPL deno, hit TAB twice there is nothing, node REPL give you auto-complete but there seems no for deno, not beginner friendly unfortunately.
Re: Deno 1.0
#546> TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch. This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex. One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be com…
v8 has the ability to snapshot a program just after it loads, but before it executes. If you snapshot after doing some kind of warmup, to trigger the right optimisations, you get something that should fire up ready to go, which is probably the main problem - the compiler being repeatedly invoked and parsed from javascript and compiled on the fly.
Re: Deno 1.0
#547Earlier quoted context omitted.
A better solution is something like https://vfsforgit.org/
That's not necessarily better. For one thing, it doesn't support Linux yet. For another, afaik, Azure DevOps is the only git hosting service that supports it. Even if it was better supported, I wouldn't want to start using it just so I can include all my dependencies in git. Of course if you are using something like vfs for git anyway, then increasing the repo size is less of an issue. It still feels wrong to me thou…
Yeah, I'm not really advocating the use of GVFS specifically, but what I am saying is that once you've lived in a world where all your dependencies are in your repo you won't want to go back, and that Git should improve their support for large repos (in addition to checking in all our dependencies, we should be able to check in all our static assets).
Re: Deno 1.0
#548I like what Deno is selling. URL like import path is great, I don't know why people are dismissing it. It is easy to get up-and-running quickly. Looks like my personal law/rule is in effect again: The harsher HN critics are, the more successful the product will be. I have no doubt Deno will be successful.
My concern is what happens when popular-library.io goes down or gets hacked? Or how about attack vectors like DNS poisoning? or government-based firewalls? I know there's this[1], but somehow I still feel uneasy because the web is so fragile and ephemeral... At the very least I would like to have the standard library offline... [1] https://github.com/denoland/deno/blob/master/docs/linking_to...
> what happens when popular-library.io goes down or gets hacked?
What is anyone going to do about it? Anything has a chance of getting hacked or goes down just when you need it, be it GitHub, npmjs.org...
Blaming the tool for not having a protection against DNS poisoning is a bit far fetched.
Re: Deno 1.0
#549I like what Deno is selling. URL like import path is great, I don't know why people are dismissing it. It is easy to get up-and-running quickly. Looks like my personal law/rule is in effect again: The harsher HN critics are, the more successful the product will be. I have no doubt Deno will be successful.
This seems to be the case, yes. It's like the critics unconsciously know it's better, and that is where their energy comes from.
More like "There can't be a better stuff than what I'm accustomed to and like" feel.
Re: Deno 1.0
#550I briefly looked over this project when this link first popped up and didnt think much of it, but then i was surprised to see this huge surge in votes. I dont do much in the javascript and related world - can someone explain what in particular about this project has generated such interest? Even after reading the top comments, I feel like im missing the bigger pitcure.