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?
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 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
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.
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.