Prediction: Microsoft will be buying Deno. Screencap this.
The Deno Company
281–290 of 446 posts
Re: The Deno Company
#282Earlier quoted context omitted.
> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think th…
Answered in https://deno.land/manual@v1.8.2/linking_to_external_code#but... Also: Nobody prevents you from using a package manager anyway. Just because you can use urls in imports doesn't mean you have to. But it is very convenient that deno downloads exactly the code that is imported. A package manager will always just throw everything at you. Some packages in node.js try to fix this by splitting the project into su…
Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package?
Also, from your link:
"In Node this is done by checking node_modules into source control. In Deno this is done by pointing $DENO_DIR to some project-local directory at runtime, and similarly checking that into source control:"
I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production.
Is it possible to do this in deno today? I don't really get that sense.
Re: The Deno Company
#283A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…
Those still are all trivial in the "too little too late" sense.
URL-based imports are already something you can do in package.json if you really thought that was great. Top-level await really is trivial. The permissions system does very little for you since they are process-level permissions when I'm scared of transitive dep attacks. Typescript in Node is good and Deno has to catch up in tooling.
If Deno was where it is today but like 8 years ago, it would have made a splash. Now it just looks like someone made a few creature comforts to Node.
Re: The Deno Company
#284> Of the myriad ways to program computers, scripting languages are the most effortless and practical variety. Of these, the web browser scripting language (JavaScript) is the fastest, most popular, and the only one with an industrial standardization process. I haven't fully investigated in a few years, but isn't it still true that LuaJIT is is faster than V8 JavaScript? The last I saw it was outperforming V8 by a lot…
Probably the benchamark you saw was just a iteration of any math calc. In real programs V8 js is orders of magnitude faster than LuaJit https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
fyi as-it-says — Lua 5.4.2 — not LuaJIT
Re: The Deno Company
#285A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…
- AFAIK - it still compiles into normal JS nor does the TS team work on deno (hope I am wrong) so it's not really FCC as most would think - this doesn't make sense, its bad API design and shoe horning in a completely different paradigm is not a good idea, it should have moved somewhere less familiar and more oriented to the environment (I know that sounds weird but giving a quick answer, there are better solutions an…
While I also think url based imports are a weird idea, it might just stem from the fact that I haven’t used it much, it might be wonderful, who knows.
But what I’d like to question is why the idea of parsing everything is considered bad. Semver itself, while miles ahead of what came before, is still just lies we tell the compiler.
You can never actually rely on the fact that a miner fix will not be a breaking change and the like.
Rich Hicky had a great talk on the subject of imports and breakage, and the conclusion that I agree with was to actually load and check every function in all the libraries you use, so that if there is an incompatible change you will not be none the wiser.
I’m glad people are trying to experiment here, as package management is far from a solved problem and issues with it cause sweat, tears and blood to most devs during their careers.
Re: The Deno Company
#286Earlier quoted context omitted.
We most certainly did not, TypeScript is and continues to be a primary concern for us and we plan on continuing to support it as a first-class citizen of the ecosystem
Is Deno still going for TS runtime? > Deno is a runtime for JavaScript and TypeScript that is based on the V8 JavaScript engine and the Rust programming language.
Insofar as we take `.ts` files seamlessly yes -- though to be clear, one does not simply "run" TypeScript. There are no runtimes for TypeScript directly (there's AssemblyScript that _looks_ like TypeScript, but isn't exactly TypeScript)
We've simply incorporated the type-checking and transpiling steps into the deno cli, making it super simple to get going, no config needed.
Re: The Deno Company
#287Nice to see! How do they plan to monetize? I either became blind or missed it somehow. The article does say how they DON'T plan on monetize: "Rest assured that Deno will remain MIT licensed. For Deno to grow and be maximally useful, it must remain permissively free. We don’t believe the “open core” business model is right for a programming platform like Deno." There are some hints though: "If you watch our conference…
I know this isn't the SV-approach to things but maybe they intend to offer consulting services for those looking for some expertise with the ecosystem, bill hours, and retire in their 50s as millionaires instead of billionaires. This might be surprising, but not everyone is looking to be a unicorn.
The article says they "raised 4.9 million dollars of seed capital" so I expect their investors will want a decent return over the next few years.
Re: The Deno Company
#288A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…
Those still are all trivial in the "too little too late" sense. URL-based imports are already something you can do in package.json if you really thought that was great. Top-level await really is trivial. The permissions system does very little for you since they are process-level permissions when I'm scared of transitive dep attacks. Typescript in Node is good and Deno has to catch up in tooling. If Deno was where it…
top-level await isn't really trivial implementation or action wise. But as a feature it seems obvious until you step into all the edge cases it can create.
Re: The Deno Company
#289A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…
- AFAIK - it still compiles into normal JS nor does the TS team work on deno (hope I am wrong) so it's not really FCC as most would think - this doesn't make sense, its bad API design and shoe horning in a completely different paradigm is not a good idea, it should have moved somewhere less familiar and more oriented to the environment (I know that sounds weird but giving a quick answer, there are better solutions an…
- I've had the typescript compiler do WEIRD errors on me, depending on configuration, a zero configuration, no brain environment is a godsent
- it makes a ton of sense if you don't want to maintain two different versions of the same library. With WASM there is zero need for Node native modules anymore, so there is no need to have platform specific idiosyncrasies that go beyond Web APS's. Is the fact that it's called "window" a favourite of mine? Certainly not, but when you try to get a library running that you really need, that was originally written for the browser or vice versa, you don't care what the thing is called, as long as it's backwards compatible.
- defense in depth, multiple sandboxes are better than one
- this has to do with the window point, it's a lot easier to make code cross platform compatible if you only have to reference publicly accessible http endpoints
- maybe that's not interesting for you, but I've had to deliver command line tools as binary, and I'm super duper happy that I could do so in JS, the security I gain from controlling the runtime version is also much better than what I'd get from that being the users responsibility, besides that fact that not knowing exactly which runtime your code is gonna end up on is also a big source of security vulnerabilities
-
Re: The Deno Company
#290Earlier quoted context omitted.
Those still are all trivial in the "too little too late" sense. URL-based imports are already something you can do in package.json if you really thought that was great. Top-level await really is trivial. The permissions system does very little for you since they are process-level permissions when I'm scared of transitive dep attacks. Typescript in Node is good and Deno has to catch up in tooling. If Deno was where it…
top-level await isn't really trivial implementation or action wise. But as a feature it seems obvious until you step into all the edge cases it can create.
It's cute for scripts. Otherwise there's the trivial top-level wrapper runProgram.catch(console.error) entry point. It's just not a detail that does much to sell Deno.
Though I admit it's not that fun for me to come in here to poopoo Deno.