Deno 1.0

The initial thing is the fear "whoa, that is hella insecure!" which, I agree NPM is basically the same problem... although, with NPM - Git system, you can 1. fork a version and use that version (which you can do with this, just host different url) or two you can freeze version you are using and theoretically only update after checking stuff out (I guess you would have to do the same with host different url, seems more difficult process)

Also NPM basically makes a local cache of the files you will be importing, I guess the first time you run your program it must get the files and then caching keeps them from updating until the resource updates? Maybe I'm missing something and it isn't like that but if it is like that I find that weird because you are arbitrarily adding extra performance overhead to parts of your system as code loads and sees it needs to get a resource that has updated? I guess what would end up happening is versioning would be in the url and an expires header set a long time in the future, like you might do with static assets now, but Deno doesn't require that, it will be an outgrowth of this import from url system. Will there be situations where someone has done the caching poorly, or set the header badly or whatever and you are loading a resource too often? I would expect so, anyway I guess there will have to be testing of Deno's caching https://www.mnot.net/blog/2017/03/16/browser-caching

Finally, in NPM's system if a module I'm importing is a little bit weird I can always just go into the folder quickly and start debugging and maybe fixing the code, and then when I've got things working the way I think they should with changes do an actual fork pull-request, or just fork and use my fork of the code, or if it turns out as it often does that I've misunderstood something revert my changes to their code and go fix my code instead. I can of course still achieve the same effect with Deno but the workflow would have to be different and I think would end up being more convoluted, at least in the beginning.

These are the initial worries that I get when seeing import from some url. I suppose someone has already thought these things through and I'm unnecessarily worried so if that someone is you (the reader of this long post) you can maybe assuage my worries.

This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex.

One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be compiled down web assembly and have llvm spit out a highly optimized binary. This not only benefits demo, but the rest of the internet.

TSC has done some great architectural changes in the past like doing mostly functional code, rather than lots of classes.

The target we should be aiming for is a powerful typed language like typescript that complies very quickly to webasshmbly that can run in guaranteed sandbox environments.