4 ms·
I’m really strongly rooting for Deno. I’m even implementing my current passion-project on it (https://github.com/brundonsmith/bagel https://github.com/brundonsm
by brundolf 5y ago
I’m really strongly rooting for Deno. I’m even implementing my current passion-project on it (https://github.com/brundonsmith/bagel https://github.com/brundonsmith/bagel). But I have a couple of significant (but solvable!) criticisms, if anybody on the team is here.
1) The documentation for the standard APIs is extremely wanting. The main, and weirdest, problem is that it seems almost impossible for search engines to index (or at least DDG). I can search for very very specific things, and still get kicked to the home page and have to manually navigate to the part I’m looking for (and the navigation is also pretty difficult; I often can’t find the thing at all and have to rely completely on editor hover-overs for documentation). It can also be confusing- some things like certain standard APIs appear to have multiple conflicting reference-manuals? And it can be hard to know which one is current or correct. Even getting past all the obfuscation, the docs are just ok. They often leave out deeper details (this last part is less of a problem and more understandable, this being a young project).
2) The VSCode extension still needs work. It’s usable, and better than nothing, and it’s better than it used to be, but (ordered from most to least significant):
- When I open certain files - usually bundles or something; maybe files outside of the project directory? - the language server crashes over and over and over, each time popping the terminal back up to show the output and distracting from what I’m trying to look at. This doesn’t happen with my normal, in-project Deno files at least.
- It doesn’t have auto-import as you’re typing like normal TypeScript does; you can auto-import by clicking the lightbulb, so I assume it’s a relatively short hop to plug that in. Makes a significant difference in flow.
- It chokes on absolute import-paths in Windows. Thinks they’re malformed remote URLs.
- It has caching issues sometimes. I’ll change some type in one file and other files won’t get the updated type until I close and re-open them, or sometimes the whole editor. This is uncommon so it’s not a huge deal.
I list these criticisms because I want to see Deno succeed. Switching from using TypeScript on Node (with the build steps/configuration, ad-hoc testing and linting, and Node’s pathological legacy APIs) to Deno was a huge quality of life improvement, even with all these problems. Brought to its full potential, I think Deno could be a revolution.
- ravenstine 5y agoYeah, I've seen worst API documentation, but their docs site is needlessly weird. Documentation is something that should be solved by now. No project needs whatever custom thing Deno uses. I don't get it. Leaving out details, for the most part, is the right approach for now, I think. Only Node/JavaScript veterans should probably be using Deno for the time being. But I definitely hope Deno can eventually take over and make Node obsolete. > 2) The VSCode extension still needs work. It’s usable, and better than nothing, and it’s better than it used to be, but (ordered from most to least significant) At this point, I've kind of given up on VS Code language/runtime extensions in general. Virtually none of them work with the slightest variation in toolchain configuration, whether it's C++ or Typescript or even ESLint. You're lucky if they don't slow the heck down over time. Import paths are the worst! Somehow that's something I inevitably run into, again, no matter the language. I kinda want to blow all this stuff up and start over. Maybe Deno is a part of that equation. haha
- jay_kyburz 5y agoThe API doc page crashes my iPad. I can't even open it.