crowlKats

apologies, this is inaccurate currently, will get things updated

could you try again? it should be available now (no need to update deno CLI)

it actually does: its not part of the WebGPU API directly itself, but its separate: https://deno.com/blog/v1.40#webgpu-windowing--bring-your-own...

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

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/[email protected]/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?

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

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

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.

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.

The wording in that blogpost might be a bit off, here it is more in-depth: https://deno.com/blog/netlify-edge-functions-on-deno-deploy

Netlify is using Deploy

The M1 builds are made manually by us, as github doesnt provide any runners. the same problem does apply for linux arm, however we don't have any arm linux systems any one of the members use; and building on a pi is a no-go, as that can take 70+ minutes, so that would make our release cycle a lot more complicated. Either way, we are investigating potential possibilities besides waiting for github to have runners available

No, Netlify actually uses Deno to some degree: https://www.netlify.com/blog/announcing-serverless-compute-w...

> It is using silly naming conventions in filenames as an alternative to specifying routes. eg /users/[name].tsx for /users/:name

Its a convention also used by Next.js, so it is just sticking to existing conventions.

> There is no documentation about the islands or how they are implemented.

Documentation is still only partial & incomplete.

> It says there is no build step but there has to be one because v8 runs JavaScript not TypeScript

This is a module for Deno, which does that under the hood, it isnt something a deno user would have to be concerned with.

a deno.dev subdomain is provided to all deno deploy projects (https://deno.com/deploy)

https://deno.land/install.sh is a redirect to https://deno.land/x/install.sh, which is treated as any /x/ (community) module. These modules are immutable clones of github tags (in this case, https://github.com/denoland/deno_install/). If someone would manage to breach the AWS S3 buckets that we use for module storage, it wouldn't be just a problem for installation of the deno CLI, but a problem for any module on the registry.

I wouldnt say an iframe and this are in any way shape or form comparable. this is a "full-fledged" website.

> except that if node.land or crux.land go down, you've lost your reproducibility.

Dependencies are cached. This is no different from if npm would go down.

> The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step

Given that this seems interesting to you, it seems you haven't heard of Deno (https://deno.land). It is not related to node in terms of environment, its a new completely separate runtime.

In regards to your node example, this is fairly different: the dependency pulled in from deno.land is a wrapper around the built-in http server, which does various error handling for you and simplifies the usage. The router isnt a simple switch statement either; its a URLPattern (the web's version of path-to-regexp) based minimal router. Campring these to the node built-ins isnt exactly a fair comparison I would say.

Also on top of this, with node you need a configuration to get typescript working, then you need a package.json, etc etc.

Deno uses tokio instead of libuv. Deno comes with a large amount of tooling built-in: formatting, testing, linting, documentation, and other

Yes, there is the unstable plugin system that can be used for that

For people seeking a solution, one can use deno_dom, which implements various DOM related APIs, including DOMParser, which lets you parse XML

The problem is that the blogpost added videos, which made cloudflare trigger and think that all the .ts files we distrubte are MPEG Transport Stream files, which would violate CF's ToS on streaming.

There is also Google's Dawn implementation