Earlier quoted context omitted.
Heck yeah
Was does a TS runtime means anyway? Doesn't checking types at run time rather than at compile time a pure loss?
right. "typescript runtime" is nonsense.
The Deno Company
381–390 of 446 posts
Re: The Deno Company
#382Earlier quoted context omitted.
It will be the ultimate irony if, 20 years down the line, Deno is still around, but solely as a de facto standard / cross-platform WebAssembly execution engine.
Why would that be ironic? It's essentially the route Java is taking with graal/truffle - allowing heterogeneous mix of languages to be compiled and optimized. Why not allow typescript to use Fortran numeric libraries via wasm?
JavaScript in Deno doesn't itself run on top of WebAssembly, so this isn't really quite like Graal. If you use Deno to run wasm, all the JS bits are basically ignored. It's a bit like using a web renderer solely for .
Re: The Deno Company
#383Earlier quoted context omitted.
Speaking for myself, I have already learned JavaScript - I just don't want to have to use it.
With WebAssembly, now you don’t have to. You do need a JS shim to load the WebAssembly, but after that, pick your favorite source language that can target wasm.
WebAssembly holds a lot of promise for sure, but the interface with the outside world still has to go through JS for now for anything non-trivial. I really do hope that this will change soon.
Re: The Deno Company
#384Earlier quoted context omitted.
How does this business model survive Amazon AWS making a blog post, "Here's a template to run your deno code on Lambda!"? They'll never beat AWS on costs in the long term. They can burn VC cash to stay afloat and try I guess.
They can always get acquired by Amazon first.
It wouldn't surprise me if that's the eventual end goal. Amazon is looking for good Rust talent too from what I've read.
Re: The Deno Company
#385Earlier quoted context omitted.
> Most of the packages on NPM are complete garbage And don't do anything. I'm amazed by how often I read the source for a package I'm interested in, only to find it's about 10 or 20 lines of code. The convenience of adding a package means that if you're not sure how to do something, you can easily just add a package to do it rather than figuring out how to do it yourself. A lot of the time, you can just read the sour…
So if you need that package in your 10 projects, do you copy those 20 lines of code in your 10 projects? Yikes. Then what happens when it requires a change? Do you make the change in all your projects? Double yikes. When it becomes 30 lines, do you still copy/paste those 30 lines in all your projects? Do you also copy/paste the tests related to those 30 lines in all your projects? ... Having reusable code wrapped int…
Or you create a library which contains a collection of 10-20 line of code modules and share it among your projects.
Re: The Deno Company
#386A 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…
Thanks, I agree 100%. Perhaps I'm getting unnecessarily cocky in my old age, but this really does feel like other cases I've seen in the past where people (including the original founder) want "a clean slate", because of course there are warts and lessons learned from the original implementation, but the cost of workarounds for those warts is actually lower than the cost of switching to an entirely new competing technology for most people. Going back to the original list:
- Typescript as a first class citizen: Agreed, it's not hard to get TS set up in Node, and it's a "one and done" cost.
- An actual `window` global with familiar browser APIs: I've never needed or wanted this, though I could see how the server-side rendering crowd could benefit, but I still have to believe there would by necessity be enough difference between the browser-based window that implementing SSR is still non-trivial.
- Sandboxing w/ permissions: I honestly think this is going to be useless. As you stated, if you're really running untrusted code better to rely on process permissions. This actually reminds me of many of the overly complicated security/permissions architecture in the Java SecurityManager stuff that I rarely if ever actually saw being used.
- URL-based imports (no need for NPM): NPM certainly has its warts, but I think a lot of Deno supporters woefully underestimate how most server-side JS developers love having a single primary global package repo.
- Bundling into self-contained binaries: Again, this is nice, but also gets a "Meh, I don't really care" from me.
- Things like top-level-await which Node.js still treats as experimental: Once you learn how to do an IIFE who really cares?
- Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks): Again, a minor nice-to-have, especially with Util.promisify.
Re: The Deno Company
#387Earlier quoted context omitted.
And yet we've never seen anyone beat Amazon yet. Look at how much the PaaS area has churned over the last 10 years. Giants that stuck around like Docker are completely deflated and near worthless compared to their initial values and expectations. The smart ones like Heroku got out when the getting was good.
> And yet we've never seen anyone beat Amazon yet. That largely depends on your definitions of "beat" and "win". There are plenty of software infrastructure firms out there that Amazon has yet to smash into the ground. Nature seems to think (and I agree) simply existing is winning.
Please give examples. I would like to learn more about it (even if subjective)
Re: The Deno Company
#388Earlier quoted context omitted.
URL-based imports aren't less secure. They just make an existing attack vector more obvious. Is NPM really keeping you safe? What happens if a package maintainer is compromised and the attacker adds malicious code? The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits
a note for many: yarn v2 provides '0-config' fully cachable dependencies (zips in lfs). This makes it possible to fully vet dependencies and enforce change approval and analysis in CI/CD.
I didn't know about that regarding yarn 2. Is there a good link to read about this? I did a search for yarn 2 and didn't find that immediately.
Re: The Deno Company
#389> Of these, the web browser scripting language (JavaScript) is the fastest, most popular, and the only one with an industrial standardization process
Haha, this made me laugh hard, stopped reading
Re: The Deno Company
#390Earlier quoted context omitted.
Many companies would just never touch an AGPL package, and while there are other languages out there with commercial licenses (e.g. Delphi), those are not nearly as mainstream as the open & freely available ones. Deno is competing against Node.js, which is MIT-licensed. Deno is arguably better, but it would have to be _so much better_ to get people to even give it a second look if it was commercial.
That's why you dual license, which is significantly more approachable. "This is AGPL/GPL unless you pay $200/month per developer seat" is a common licensing scheme for frameworks, people aren't scared by it.
> This is AGPL/GPL unless you pay $200/month per developer seat" is a common licensing scheme for frameworks, people aren't scared by it
Really ? I can think of QT - but that's such a huge body of work with some very specific use cases in which it doesn't really have competition (aside from DOM based shell for UI maybe, but that has it's own problems and is often a hassle to get working).
In this case Node is established, Deno is going to have an up hill battle to gain that mindshare on equal footing, adding a licensing restriction would probably kill it off the ground.