Maybe it would be a good learning exercise to fork Deno and replace TypeScript by CoffeeScript. I liked it :)
Deno 1.20
31–40 of 60 posts
Re: Deno 1.20
#32Earlier quoted context omitted.
Such as? Do you mean things in the standard library or like JS packages?
Probably both. You can't use NPM (though you can use one of those online CDN's like unpkg) and the packages you can use probably don't work, as Deno doesn't support Node's API at all. It doesn't support any Node-specific packages like 'fs' or 'crypto' either. Unless you're writing a totally new application and don't need anything (even retrospectively) from NPM, Deno probably won't work for you. As much as I like Den…
> and no compatibility with the current largest runtime
Well… the current largest runtime is web browsers and Deno has a much better story there than Node does. But agreed, it’s a long road ahead.
Re: Deno 1.20
#33What is the reality of Deno now? I remember when Deno was being developed it was promoted like how Web3 is being promoted right now. But browsing through hundreds of job posts I have not seen anyone having Deno as a requirement. Everyone wants Typescript+Node and that's about it. Size of community, enterprise use and approachability as the first framework to learn. I think these 3 factors determine the success of any…
My personal prediction is that Deno is never going to take off. It's just not a significant enough improvement over Node.js that abandoning the existing ecosystem is worth it.
Re: Deno 1.20
#34I have moved all my library development to Deno and described the experience in a blog post[1].
To summarize, the two killer features for me are Web APIs and the built-in toolchain.
I understand the skepticism other Node devs have when faced with Deno. I have been using Node since 2010, and there is hardly anything I cannot do with it (or didn't do at one point), yet Deno makes a lot of these things much simpler. My last straw was trying to run Jest tests on TS code compiled into a Node.js ESM module. I believe I spent more time figuring out workarounds for a myriad of issues in Jest+ Node+TSC chain, than it took me to switch to Deno where all of it came out of the box.
[1] https://itnext.io/moving-libraries-to-deno-the-whys-and-hows...
edit: spelling
Re: Deno 1.20
#35Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it out and writing toy programs is not giving me enough insights of how much better/faster Deno is.
Maybe someone working with a library project can answer that. Trying to replace node with deno in e.g. React + NPM project might be way too complicated. Personally I won't taking part in any node projects anymore.
The best way to start using Deno with React is to use Remix
Re: Deno 1.20
#36Earlier quoted context omitted.
I'm an existing typescript user but I just can't see a reason to use Deno. Depending on the NPM repository CDN is less worrisome than depending n different CDNs. Including all my dependencies unilaterally (aka deps.ts) seems like a patch upon a bad decision. Making the server side runtime environment pretend to be or adopt aspects of the web browser client environment seems like a misguided direction in my wisdom, be…
> I sense that Deno is primarily being pushed by developers who cut their teeth in React-based code camps who are looking for (understandably) a wave to ride into "full stack" software development. This is a really strange take. Deno isn't significantly easier to work with than Node, so it shouldn't matter much for a React code camp graduate which of those two to ride into full stack. Deno is more appealing to season…
> This is a really strange take. Deno isn't significantly easier to work with than Node, so it shouldn't matter much for a React code camp graduate which of those two to ride into full stack.
It appears you've received this as some sort of afront. Everyone looks for a wave to ride toward the future and riding a wave is not undesirable. The Node wave has broken and is coming to a rest, slowly over time. Deno is a motion to create another. That's the natural order of things and it's okay.
> Deno is more appealing to seasoned web developers, who appreciate its conformity to modern web standards, the absence of Node quirks, and a better security.
It's interesting isn't it, because I offered my thoughts as someone who could be described as a seasoned web developer - they were just not the same as yours today.
Re: Deno 1.20
#37Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it out and writing toy programs is not giving me enough insights of how much better/faster Deno is.
I've switched a few projects back and forth but I am on the more experienced side (I'm comfortable with both codebases and have 2 digit commit numbers in both projects).
My motivation for Node was that Deno's instrumentation/APM story doesn't exist which is a show stopper for many production apps and a lot of stuff was missing.
My motivation for Deno was trying out deploy (their edge computing offering) which is really cool.
Re: Deno 1.20
#38I have moved all my library development to Deno and described the experience in a blog post[1]. To summarize, the two killer features for me are Web APIs and the built-in toolchain. I understand the skepticism other Node devs have when faced with Deno. I have been using Node since 2010, and there is hardly anything I cannot do with it (or didn't do at one point), yet Deno makes a lot of these things much simpler. My…
To be fair we have most web APIs that Deno has in Node with the exception of some we probably don't want to have. Namely: stuff like URL, fetch, AbortSignal, EventTarget, BroadcastChannel and a few others.
Re: Deno 1.20
#39Earlier quoted context omitted.
> I sense that Deno is primarily being pushed by developers who cut their teeth in React-based code camps who are looking for (understandably) a wave to ride into "full stack" software development. This is a really strange take. Deno isn't significantly easier to work with than Node, so it shouldn't matter much for a React code camp graduate which of those two to ride into full stack. Deno is more appealing to season…
"This is a really strange take." No, this is the gatekeeping mentality of many people software development. It's also wrong, since Deno removes many idiosyncrasies about server-side JavaScript.
> No, this is the gatekeeping mentality of many people software development.
I sense that I've touched a nerve and I'm sorry for that. May I ask what you believe I'm gatekeeping?
> It's also wrong, since Deno removes many idiosyncrasies about server-side JavaScript.
Could you offer some examples, so that I can learn?
I would agree with your statement that Deno removes idiosyncrasies of server-side JavaScript, but that's when viewed from a front-end-first perspective (ie. the predominant and perfectly reasonable perspective of code camp graduates that I've worked with).
Re: Deno 1.20
#40What is the reality of Deno now? I remember when Deno was being developed it was promoted like how Web3 is being promoted right now. But browsing through hundreds of job posts I have not seen anyone having Deno as a requirement. Everyone wants Typescript+Node and that's about it. Size of community, enterprise use and approachability as the first framework to learn. I think these 3 factors determine the success of any…
Deno is betting on edge computing to explode and offers a good offering (Deno Deploy) in that space leveraging how it has a smaller API and faster startup times than Node.
It also thinks that edge computing is a good space to leverage the myriad of web APIs it supports + there are certain workloads that it does better than Node (like single executable)