Design Meeting 2021-09-16

[kitsonk]

• Deno 2.0 scheduled for release November 22nd
  • Agreement there is sufficient scope for a 2.0 release
  • Noted that TypeScript 4.5 should be GA'ed on the 16th
  • @ry raised a concern about how close that is to the release, but discussed that the beta and RC come well in advance to have a high confidence in the release.
• Discussion of additional scope items for 2.0.
  • We went through the list of un-triaged items as well as a few more "late additions". The results are the following items were added to the scope:
    • NotCapable error to distinguish between permissions and capabilities (Introduce a "NotCapable" error #7394)
    • Remove Deno.read() and Deno.write() (Remove "standalone" resource method from Deno namespace #12107)
    • JSON Modules (Import Assertions/JSON Modules #7623) (TypeScript 4.5 should be the last piece of the puzzle for import assertions, so...)
    • op metrics refactoring/cleanup (op metrics refactoring/cleanup #12109)
  • Action @kitsonk to help ensure that all items have issues and are assigned to an "owner"
  • Action all "owners" will be ready next week to discuss if their items are viable for Nov 22nd and if there are any risks or issues that might block it.
• Expanding the ecosystem
  • There was a long discussion on how we can help expand the ecosystem of Deno. The perceived challenges:
    • Growth of users is relatively flat
    • It is speculated a lot of users shy away because adopting Deno seems hard or is hard
    • Perception that consuming Node.js code is hard (we don't believe it is, but the perception exists)
    • Using Deno as your development platform and sharing code with Node.js is hard (we feel this is a real problem)
  • @ry proposed a few actions to drive adoption of Deno and expand the ecosystem:
    • Allow extensionless imports under a legacy flag.
    • Support bare specifiers for Node.js built-in modules.
  • @kitsonk proposed a counter proposal of:
    • Provide supported tooling to migrate a package.json to an import map and potentially other features to "convert" to a Deno-first project.
    • Add deno emit subcommand to emit a program as a set of ESM and/or CommonJS modules and a package.json for publishing to npm or other downstream consumption.
    • Complete std node/* modules
    • Consider a ruggadised polyfill for the Deno namespace to use with deno emit
  • There was a lot of discussion and debate around the extensionless imports which sort of came down to the following:
    • For: a belief that extensionless imports would allow a lot of existing TypeScript code to run under Deno and once there is a big enough headwind, they can be removed.
    • Against: a belief that extensionless imports doesn't actually solve compatibility problems, confuses users, likely will lead to huge support challenges and introduces legacy features that will exist for ever.
    • Further actions were that we needed to do analysis and discussion on this topic.
  • The biggest concern around @kitsonk proposal was the concern that people would be resistant to rewriting all their code to use extensions, even if that were automated.

[nnmrts]

This sounds great! I'm especially hyped for import assertions.

Don't know if anyone cares but here are some thoughts and suggestions about migration (tooling) and the reasons why it took me longer than it should to switch to Deno:

I, as a former Node.js fan and user, felt most comfortable adopting velociraptor to satisfy my obsession for defining "npm-like" scripts and I think vr should definitely be at least suggested, if not recommended to migrate from package.json scripts in an eventual migration guide/tool.

click here for thoughts about esm.sh (which feel obsolete after reading https://deno.land/[email protected]/npm_nodejs/cdns)

Also, https://esm.sh/ is a must-have for me coding Deno projects these days. Generally I'd look for more modern alternatives to npm modules providing a usable ESM source or just, you know, an alternative written specifically for Deno, but sometimes there just isn't one, and esm.sh really has been a gift and time-saver in those moments, because mostly I can just append the npm module name to https://esm.sh/ and add that to my import map, and everything works. This could also be integrated in some kind of migration tool.

About the perceived challenge

"It is speculated a lot of users shy away because adopting Deno seems hard or is hard"

My speculation is that for a lot of users it's not just about adopting Deno, but also about adopting Typescript. This is why I personally, at least, didn't try Deno for quite some time, because for me it felt like it's all about Typescript and plain JavaScript/Ecmascript support is just an afterthought. I know this doesn't reflect reality and sounds strange considering Typescript supports using just plain old JavaScript syntax as well, but the tooling and philosophy around it is certainly a different one, which can feel a bit overwhelming. For me at least, maybe I'm alone with that feeling.

But currently, the best thing for me about using Deno is that I know, for the most part, I'm writing frontend code that will work in browsers out of the box and does not depend on Deno itself, and backend code that will work on any PC (with Deno installed) out of the box, without building or compiling anything, with both sides using the same ecosystem, syntax, and so on. And that feeling (for me at least) after so many years using JavaScript in a node.js- and babel-dominated world, is really great. Sure, there are a million other ways to use this language and I won't deny the value bundlers and transpilers provide, but I really think the website/readme/manual/docs should emphasize this huge factor about Deno, and the fact that it follows standards that are independent of Deno. I feel like the ESM support in Deno and the whole "import modules using urls only" thing can come across to users as opinionated design choices and weird gimmicky experimental features, but they are literally the standard and how JS works in all browsers today. It's easy, it's open, and you don't need to download, install and understand 17 different bundle plugins to get it to work.

This ease of use should be the real argument/selling point for Deno. It sounds cliché but Deno, with its current philosophy, really is the last (big) tool you'll ever install as a JS dev. Sorry for the wall of text but I hope you guys will take some of it into consideration to help grow Deno even more. As always, just my perspective and opinion on things, which may be weird sometimes. 🙈

[sylc]

Regarding improving Deno adoption, IMHO fixing the following Deno windows specific bugs could help winning some windows users. (at least some of my colleagues 😄 )

• Presses of special keys are not detectable by Deno on Windows #5945
• Broken special character encoding on Windows Terminal c4spar/deno-cliffy#113 linked to windows doesn't print emojis correctly #6001

Before building something significant in Deno, I thought to start creating some custom cli programs, with interactivity. Unfortunately the Deno windows experience is not as smooth as on linux for interactive cli.
This is a barrier for entry in my workplace where windows is used as default OS, especially when node does not have these issues.
One of the feature that I love about Deno is the ease of compiling to executable for portability, compare to node. But with the windows interactivity being limited, the attractivity is reduced.

I'm not sure if my use case is widespread or it is just me.

thanks for building deno!

[wojpawlik]

• polyfill for the Deno namespace

https://github.com/fromdeno/deno.ns

• Using Deno as your development platform and sharing code with Node.js is hard

• deno emit subcommand

https://github.com/wojpawlik/deno2node or #3385

• Support bare specifiers for Node.js built-in modules.

How about implementing https://nodejs.org/api/esm.html#esm_node_imports instead?

[zandaqo]

Add deno emit subcommand to emit a program as a set of ESM and/or CommonJS modules and a package.json for publishing to npm or other downstream consumption.

I wouldn't go as far as producing CJS modules, but it would be helpful to have an option for tsc compatible output when generating ESM modules with Deno.emit. Currently, I have to post-process Deno.emit output to strip out extensions, change full url paths to relative ones, and add links to sourcemaps in order to have ESM modules consumable by Node.js and tsc.

[David-Else]

To get more users you need a high quality official YouTube channel that shows people how to do the things they want to do. It needs to have a great (paid) presenter and to have a new video at least once a week. In 2021 blog posts are not enough.

People like Mosh https://www.youtube.com/user/programmingwithmosh could be approached and paid to create courses that are given away on the channel. A full scale Deno propaganda drive is needed to drive up adoption, it will pay for itself in the end with new Deno Deploy users I am sure.

[Conaclos]

Allow extensionless imports

Node makes mandatory the use of extensions in its ESM land.
From my viewpoint, extension-less imports for ESM was an error introduced by TypeScript. TypeScript is slowly adding options to fix that. TypeScript 4.5 introduces a new module resolution "node12". I'm more in favor of a tool to convert existing projects.

Using Deno as your development platform and sharing code with Node.js is hard (we feel this is a real problem)

Yes, it is in my personal experience. And this is the main reason why I did not switched yet to Deno as dev platform. The most hard thing is to generate TypeScript declaration files from a Deno project. The use of ts extension for imports makes it impossible to use TSC to output declaration files. This could definitevly help if deno emit could do that. For now, if I want to use Deno, I need to use both deno2node and esbuild (I use the latter for generating a commonjs bundle). This reduces the appeal of Deno because I need other tools...

In my personal experience, Deno is an appealing ecosystem for developing libraries and applications: the integrated code formatter, linter, test framework, and bundler are great! However the test framework and the bundler are still young. For instance, the test coverage cli fails when import-maps are used. Furthermore, the bundler is really minimalist: I cannot bundle my library without bundling its external dependencies, I cannot generate TypeScript Declaration files.

[vwkd]

Exponential growth looks like constant growth in the beginning. In other words, the typical S-curve of adoption will become apparent only later.

It would be a monumental mistake to now compromise on the things you have set out to fix just because you feel like that adoption is too slow. E.g. "Support bare specifiers for Node.js built-in modules.", etc. You would throw away your entire value proposition. Should Tesla have compromised on their goals and changed to hybrid in 2013 after struggling for 10 years (or even now if you still doubt their success)? They wouldn't be where they are today.

I assume these ideas originate out of fear since with a commercial Deno Company things got more serious than a hobby project. Take a deep breath! Things will work out. Browser compatibility is your biggest asset which your competitor can’t match.

Instead of evolving your product backwards, evolve it forwards. Yet another lesson from Tesla's playbook. Don't backtrack to implement all past mistakes of your competitors, instead evolve at maximum speed forwards such that your competitors can't match you even if they tried.

I see a bright future ahead for Deno.