I feel like there was this rush of excitement when it first came out, and that's mellowed to a steady stream of updates and some sustained low-medium interest. It seems like everybody's following it from the sidelines, waiting to see what happens. That's my situation at least.
I'd love a world where I can write everything in TypeScript with minimal building hassle, but I'm curious to what degree that's panning out in industry.
In particular, we've been using it to replace some bash and Ruby scripts we had.
It's probably similar performance to Node, all the heavy lifting is done outside v8 (just like it would be in Node). The JS environment is largely just accepting HTTP requests, doing a bunch of logic, handing off instructions to lower level image manipulation libraries, and then streaming the response back to users.
Can't give too much details (mostly because I'm not directly working on it), but the ability to run in a constrained sandbox and the ability to easily do go style imports from github is seriously useful for our use case.
Don't know how it's going to pan out, but from a high level deno seems to be very well designed. I'm looking forward to see the various niches in which people use it.
It’s like some odd version of list-making (many people get a kick out of compulsively making these detailed lists).
It used to be that you think very carefully about how to keep a function simple, but Typescript is bringing out this dark side in people that allows them to just define 15 argument functions, so long as is has a nice exhaustive Type.
Sometimes you have to save people from themselves. I’ll stay hyperbolic and say in several years time, we will all be drowning in type-inflated code bases. JavaScript people always find a way to make things hard.
You get this tight coupling of code and editor/IDE with Typescript that I didn't see coming. The benefits from the coupling are very real and probably outweigh the costs, but there is a price to be paid.
It means that you have to manually go line by line through new code in your editor instead of scanning only with your eyes. It also makes reviewing the code anywhere else harder -- GitHub, etc. This is made more painful when types are necessary to understanding code, but the types are found in a file far away.
But this is coming from someone who sometimes gets nostalgic for the days of printing out code, moving over to a big empty desk with pen in hand. Then going back to the terminal to make those changes.
I also have seen ballooning function signatures that would have otherwise resulting in refactoring to an options object or otherwise refactoring.
Don’t even get me started on that. It seems, now more than ever, we need another ‘JavaScript the Good Parts: 2021 Update’. A lot has been introduced in the last decade, and not all of it should be used to the degree we are using them.
I just don’t know who has the credibility to pull it off at this moment.
This could maybe also be a pre-commit git hook transformation so that you could see how type changes propagate.
The essential feature must be that the compiler overwrites them often and that they must be informative only.
If browsers actually spoke a strongly typed functional language a la ML/Haskell natively we'd probably switch in a heartbeat. But otherwise it's either vanilla js (no jsx either, simply htm) or Rust compiled to WASM.
And we'd advocate for its removal because it incurs opportunity costs. The deno team is small enough as is, and we don't think that TS is a selling point for it. The great tooling it provides is however so we'd rather see more of that.
As for the type system itself: it is bolted on, yes, and I don't think that's a weakness. Flow tried to be a JS type system that wasn't bolted-on, and it was horrible to use because it was constantly fighting against the base language and all of its idioms. TypeScript is empathetic to JavaScript programmers: it knows things will never be perfect, so it gives you the tools to make them really quite good but gets out of your way when it reaches its limits. I think this is a wonderful thing and a huge driver of its success.
Don't let perfect be the enemy of good.
I think you're hugely underselling the value that deno provides as a tool and attribute too much virtue to TS.
Maybe the advertisement for deno had it backwards. If people knew how much better it is than node, it'd gain significantly more traction. Instead they just think it's "that typescript" thing and ignore it. If deno dies it's probably because of that typescript shadow, not despite of it.
I don't know what planet you're living on but this is completely backwards from everything I've seen people say online.
> You act as if the typescript compiler and source-maps suddenly stopped working once they're out of the core.
I know that I personally don't bother using TS for Node projects until they reach a certain size. I'd love to use it for every tiny script, but the overhead of setting up a tsconfig, figuring out where the build files will go, adding them to the gitignore if there is one, combining the build step and the run step into a little script for development, etc, just tips the equation. On top of that, I can't really ship TS on NPM because that assumes everyone downstream will be willing to do the same config + build process.
Deno solves all of this by making TS a first-class citizen. That's huge.
JS is the smallest common denominator for that tooling. If people want typescript support they can run the compiler themselves. TS is the odd feature that's there because Ryan likes it, but why favour TS over Reason for example?
I'd rather see good WASI support and a more finegrained sandboxing model, and have the community take care of transpilers.
I’m not currently advocating for supporting Deno on my professional projects. But this isn’t for lack of interest, it’s just lower priority than other changes I want to make first. I absolutely want to switch when I can justify it, if for no other reason than fast TypeScript ESM without a build/transformation step.
1: https://twitter.com/n_moore/status/1423672410486755332?s=21
Edit: forgot link
Deno brings two main things that seem undeniably critical & without peer:
1. Fantastic rust integration. Node has neon & napi-rs, but neither of these present as rust-first & readily available extension point, to replicate what node did: be the incredibly super successful bridge between the native platform & the javascript language. Whatever success Rust has will strengthen & alloy Deno's position.
2. Unparalleled web platform support. Always bet on the web. The web is everywhere, it's platform is excellent & healthy & robust, some last cracks of missing capabilities are being filled in. Deno presents as a possible server-side desktop-side web environment in a way nothing else does. Whatever success the web has will strengthen & alloy Deno's position.
Fretting about where in the adoption curve something is is uninteresting to me, a geek. I would rather focus on the thing, know it, assess it's potential, see others assessments, & make my own projections of usability & adoption, than look about for signs. Hopefully the brilliant things will have their due day.
Adoption isn't irrelevant, because it determines things like ecosystem maturity, long-term support, etc. I wouldn't feel comfortable recommending that my company build a critical new system on a technology until I feel confident that it has a future. So I'm just trying to get a read on where we are with that when it comes to Deno.