Readit NewsDeleted Comment
crowlKats commented on Tsdocs.dev: Type docs for any JavaScript library tsdocs.dev... · Posted by u/webartisan
Cool, fwiw I didn't know about the general use and I use deno heavily, here's a comparison of Three.js:
Deno Doc: https://doc.deno.land/https://esm.sh/v135/@types/three@0.159...
TSDocs.dev: https://tsdocs.dev/docs/three/0.159.0/modules.html
The search UX and documentation UI of TSDocs is better. The availability of Deno is better atm.
Though TSDocs was speedier and a better flow when it was working.
yes, the doc.deno.land is relatively outdated and uses an old system. our static generator via the doc subcommand and registry are the newer systems
crowlKats commented on Tsdocs.dev: Type docs for any JavaScript library tsdocs.dev... · Posted by u/webartisan
Author here:
I created this because I found myself peeping inside type declaration files too often, and the only way to do that was by installing the package first.
tsdocs.dev helps you check the API surface of a good number of JS libraries and their past versions — usually a quick search away.
There's something powerful about speed and being able to answer questions in seconds that usually take minutes.
edit: The server might be overloaded with requests as we prime up our caches, but do visit back after HN's done hugging us to death.
You can show your support and help cover a part of server costs if this (or bundlephobia.com) saved you time.
Hey, Leo from Deno here.
We recently released a static HTML documentation generator via our `deno doc` subcommand.
We also have a similar system for our registry (here an example: https://deno.land/std@0.209.0/http/mod.ts?s=Server).
But we have an outdated system for general use, which is similar to what you have built: https://doc.deno.land/.
Did you know about this, and did you want to built your own system regardless, or did you not know about it and would this have been something you would have used instead of creating your own system?
Excited for the improvements, some big wins there!
But surprised to see so many removals in the Changes section to what seems to be a minor version of a 1.x release. Nothing that hurts me personally, altho not Semantic Versioning and cautions shaky ground to build on?
There are no removals in the CLI, and std is considered unstable, and due to that has different versioning that is still in 0.x
> We know there's been a lot of chatter recently about runtime speed.
For reference: https://news.ycombinator.com/item?id=32457587
Btw, I like where it's going but I find it quite sad that there is no official linux ARM64 support yet - which means I can't try to use it on AWS lambda for example.
ARM64 builds are something that has been getting investigated. The biggest problem is that github doesnt provide any ARM64 runners, so workarounds around that are necessary
As a non-user of Deno, I’m curious, how do people tend to manage dependency version centralisation in Deno? I suppose this will apply to existing Deno as well as npm imports. I can just see you ending up having to change “import express from "npm:express@5";” from 5 to 6 in lots of places when the next major version comes out.
When contemplating how I might do it, I came up with centralised reexport, a file deps.ts containing:
export express from "npm:express@5";
So then I looked up the docs and found https://deno.land/manual/linking_to_external_code#it-seems-u... and was amused to find the same solution, even down to the file name “deps.ts”!
Is this how people tend to work with Deno?
I see it also supports import maps, https://deno.land/manual/linking_to_external_code/import_map..., which could readily solve the problem too. Do people use that?
deps.ts is currently the most common way, however new projects like fresh use import maps. the problem with importmaps is they are not composable, as such, using an importmap for a library is usually bad as said importmap is not picked up and used, so the end-user would have to add their own importmap with entries compatible for the library (this is what fresh does: it generates an importmap with entries it needs). due to this problem, deps.ts is the most common solution, however I do hope that composability issue with importmaps will change.
> Up to 10ms CPU time per request
So less than 17 minutes of CPU time per day - not a lot, but also not nothing.. But at 10ms per request, what would one use it for? Just server-side rendering for something simple?
proper applications as well. example is the https://deno.land website has an average CPU time of 6ms. CPU time means it doesnt include any IO bound operations, so ie doing a fetch request wont really contribute to the CPU time.
With Slint [1] we're working on a framework which allow to make a desktop GUI in Javascript/Typescript, without bringing a browser/webview. Currently, we do it by using binaries through napi-rs so we can bring in a window using the platform native API. And then we do some hack to merge the event loops.
But if Deno supports bringing up a window directly, this means we can just ship wasm instead of native binary for all platform. And also I hope event loop integration will be simplified.
Although we'd also need more API than just showing a window (mouse and keyboard input, accessibility, popup window, system tray, ...)
[1] https://slint.dev
Edit: I got excited a bit too early. The WebGPU feature doesn't include the API to launch a Window. One still need to rely on an extra library binary.