211–220 of 446 posts
Earlier quoted context omitted.
Wasn't a TypeScript runtime the original Deno selling point? Didn't the project have to pivot away from that?
No. Nothing has changed about Typescript support since 1.0. It is just as well supported as JS. We never removed support...
Earlier quoted context omitted.
No we didn't?! Where did you get this info from? Deno is made to work with TypeScript out of the box. The Deno Standard Library is written in TypeScript: https://deno.land/std . Most userland modules are TypeScript too.
Wasn't a TypeScript runtime the original Deno selling point? Didn't the project have to pivot away from that?
Earlier quoted context omitted.
> Or if it just exists because JavaScript developers don’t want to learn something new. It's probably a big reason. But if you think about it from the other angle... you don't want to learn Javascript, which would be new to you :-)
Touché. I will admit I am resistant to learning JS. Part of this is that it seems like no one actually "likes" to program in it, they just have to because it is so ubiquitous. But I guess that just goes back to the Bjarne Stroustrup quote: "There are two kinds of programming languages: The ones people complain about and the ones nobody uses."
JS has warts, undoubtedly so. But I try to approach it like I would Clojure and it makes the experience much better for me. I think JS has the bones of a Lisp if you're willing to look for them. Sure it doesn't have macros or decent conditional expressions or immutability but using something like Ramda gets you some of the way there. And there are proposals for pattern matching and immutable data structures though they are fairly far off.
I think JS is at its worst when people try to code it as poor version of Java or C#. I have a bit of a love hate relationship with Typescript for this reason. Some aspects of its type system are great like being able to make a union out of anything, I wish OCaml had that. But I think denying Javascript's inherent dynamic nature is a mistake.
Overall I've learned to ignore its worst parts and just focus on what made it good from the start, being a weird cousin of Scheme that runs in the browser.
The leading app framework for that is Nextjs and I hope the Rauch Capital investment sígnals Vercel will be supporting Deno.
Anyone know?
In my opinion, the best part of node is (or was) that it didn't adhere to the browser APIs. That brought in some fresh air, and gave us buffers, native bindings, streams etc.
Earlier quoted context omitted.
No we didn't?! Where did you get this info from? Deno is made to work with TypeScript out of the box. The Deno Standard Library is written in TypeScript: https://deno.land/std . Most userland modules are TypeScript too.
Wasn't a TypeScript runtime the original Deno selling point? Didn't the project have to pivot away from that?
>>> Our investors are Dan Scholnick from Four Rivers Ventures, Guillermo from Rauch Capital, Lee Jacobs from Long Journey Ventures, the Mozilla Corporation, Shasta Ventures, and our long-time collaborator Ben Noordhuis. Why is the Mozilla Corporation an investor in a Chrome based technology startup ?
Well, Deno is using Rust extensively and V8 is the only "Chrome" part.
And all Servo developers according to: https://paulrouget.com/bye_mozilla.html
Earlier quoted context omitted.
I've only dipped my toes in the water with Deno, but it solves a few pain points I've felt with Node. Direct deps via url vs npm as middleman, a standard library (thank goodness!), and single binary distribution. Types are great too, but these other things would be enough for me.
> a standard library (thank goodness!) What's a "standard" for you? Whatever definition, I think it implies there are > 1 implementations of it. Node.js is based on CommonJS APIs, an initiative lead and implemented by earlier server-side JavaScript (SSJS) runtimes at the time such as v8cgi/TeaJs, Helma, etc. until Node.js dominated SSJS around 2011. Remember, SSJS is as old as the hills, starting 1996/7 with Netscape…
Really what I mean by 'standard' in this context is a batteries-included experience for most day-to-day programming problems.
I can appreciate the minimalist view where every project selects a core set of libraries for the given challenge. On the other hand, a core set of libraries that are good enough for most things just reduces decision fatigue, and makes it easier to just code.