A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.html 22KB

  1. <!doctype html><!-- This is a valid HTML5 document. -->
  2. <!-- Screen readers, SEO, extensions and so on. -->
  3. <html lang="fr">
  4. <!-- Has to be within the first 1024 bytes, hence before the <title>
  5. See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
  6. <meta charset="utf-8">
  7. <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
  8. <!-- The viewport meta is quite crowded and we are responsible for that.
  9. See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
  10. <meta name="viewport" content="width=device-width,initial-scale=1">
  11. <!-- Required to make a valid HTML5 document. -->
  12. <title>Deno is a Browser for Code (archive) — David Larlet</title>
  13. <!-- Generated from https://realfavicongenerator.net/ such a mess. -->
  14. <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
  15. <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
  16. <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
  17. <link rel="manifest" href="/static/david/icons2/site.webmanifest">
  18. <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
  19. <link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
  20. <meta name="msapplication-TileColor" content="#f0f0ea">
  21. <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
  22. <meta name="theme-color" content="#f0f0ea">
  23. <!-- Documented, feel free to shoot an email. -->
  24. <link rel="stylesheet" href="/static/david/css/style_2020-04-25.css">
  25. <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
  26. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
  27. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
  28. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
  29. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  30. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  31. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  32. <meta name="robots" content="noindex, nofollow">
  33. <meta content="origin-when-cross-origin" name="referrer">
  34. <!-- Canonical URL for SEO purposes -->
  35. <link rel="canonical" href="https://kitsonkelly.com/posts/deno-is-a-browser-for-code/">
  36. <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">
  37. <article>
  38. <h1>Deno is a Browser for Code</h1>
  39. <h2><a href="https://kitsonkelly.com/posts/deno-is-a-browser-for-code/">Source originale du contenu</a></h2>
  40. <p>I started contributing to Deno soon after Ry made the prototype visible in
  41. May 2018. The most frequent question that people have is “where is the package
  42. manager?” which often times isn’t even in the form of a question. It is
  43. statements like “I thought Deno took security seriously, and just downloading
  44. resources off the internet is insecure.” or “How can I possibly manage my
  45. dependencies?”</p>
  46. <p>In my opinion, we need to shift our mental model. Lots of folks take the
  47. ubiquity of package managers and centralized code registries as a requirement
  48. to have a package manager and a centralized code registries. Because they exist
  49. doesn’t mean they are required. They came into existence because they solved
  50. problems in a particular way, and we have just accepted them as the only way to
  51. solve that problem. I would argue that isn’t true.</p>
  52. <h2 id="browsers">Browsers</h2>
  53. <p>In order to publish a website, we don’t login to a central Google server, and
  54. upload our website to the registry. Then if someone wants to view our website,
  55. they use a command line tool, which adds an entry to our <code>browser.json</code> file on
  56. our local machine and goes and fetches the whole website, plus any other
  57. websites that the one website links to to our local <code>websites</code> directory before
  58. we then fire up our browser to actually look at the website. That would be
  59. insane, right? So why accept that model for running code?</p>
  60. <p>The Deno CLI works like a browser, but for code. You import a URL in the code
  61. and Deno will go and fetch that code and cache it locally, just like a browser.
  62. Also, like a browser, your code runs in a sandbox, which has zero trust of the
  63. code you are running, irrespective of the source. You, the person invoking the
  64. code, get to tell that code what it can and can’t do, externally. Also, like a
  65. browser, code can ask you permission to do things, which you can choose to grant
  66. or deny.</p>
  67. <p>The HTTP protocol provides everything that is needed to provide information
  68. about the code, and Deno tries to fully leverage that protocol, without having
  69. to create a new protocol.</p>
  70. <h2 id="discovering-code">Discovering code</h2>
  71. <p>The first thing to think about is that, like a browser, the Deno CLI doesn’t
  72. want to have any opinions about what code you run. It lays out the rules of how
  73. code is fetched, and how it sandboxes itself from the machine it runs on. In my
  74. opinion, that is as much of an opinion a runtime should have.</p>
  75. <p>In the Node.js/npm ecosystem, we have conflated the management of code on our
  76. local machine, with a centralized registry of code to help facilitate discovery.
  77. In my opinion, both have really bad flaws.</p>
  78. <p>Back in the early days of the internet, we experimented with npm type of
  79. discoverability. You would go add your website to Yahoo! under the right
  80. categorization and people would come along, maybe use the search function, but
  81. it was all structured based on the opinions of those providing the content, not
  82. really based on optimizing for the needs of the consumer. Eventually along came
  83. Google. Why did Google win? Because it was useful. It indexed websites in a
  84. way that matched simple expressions of need (search terms) with the most
  85. relevant web pages that met that need, looking at multiple factors, including
  86. meta data provided the content provider as one factor in the mix.</p>
  87. <p>While we don’t have that model quite yet for code for Deno, it is a model that
  88. works. In addition, we use Google because it solves problems for us, instead of
  89. being told “you must use Google”, as well as there are also other viable
  90. alternatives to Google.</p>
  91. <p>I got into a bit of a debate with Laurie Voss on twitter, someone who knows a
  92. fair deal about the npm ecosystem I would say. He argued that Deno needed a
  93. package manager, and this blog post is a longer winded version of the thoughts
  94. I wanted to express, but Laurie raised a very valid point.</p>
  95. <p>GitHub has become the home for open source code, because it was useful and
  96. solved problems, and built on top of the <em>de facto</em> source code versioning tool,
  97. git. From the Deno CLI perspective, there should be no technical restrictions
  98. to where you source code from, it is up to the wider eco-system to create and
  99. evolve ways to make code for Deno discoverable, probably in innovative ways that
  100. could never have been conceived by those of us creating the CLI.</p>
  101. <h2 id="repeatable-builds">Repeatable builds</h2>
  102. <p>In the npm eco-system, this became a problem. Because of the heavy reliance on
  103. semantic versioning, and the complex dependency graphs that tend to come from
  104. the Node.js/npm eco-system, having a repeatable build became a real problem.
  105. Yarn introduced the concept of lock files, of which npm followed suit.</p>
  106. <p>My personal feeling is it was a bit of the tail wagging the dog, in that the
  107. behaviours of developers in the eco-system created a problem that then needed
  108. an imperfect solution to fix it. Any of us that have lived with the eco-system
  109. for a long time know that the fix to a lot of issues is
  110. <code>rm -rf node_modules package-lock.json &amp;&amp; npm install</code>.</p>
  111. <p><img src="https://memegenerator.net/img/instances/75583685/have-you-tried-rm-rf-node-modules-npm-install.jpg" alt=""/></p>
  112. <p>That being said, Deno has two solutions for that. First, is that Deno caches
  113. modules. That cache can be checked into your source control, and the
  114. <code>--cached-only</code> flag will ensure that there is not attempts to retrieve remote
  115. modules. The <code>DENO_DIR</code> environment variable can be used to specify where the
  116. cache is located to provide further flexibility.</p>
  117. <p>Second, Deno supports lock files. <code>--lock lock.json --lock-write</code> would write
  118. out a lock file with hashes of all the dependencies for a given workload. This
  119. would be used to validate future runs when the <code>--lock lock.json</code> is used.</p>
  120. <p>There are also a couple other commands that make managing repeatable builds.
  121. <code>deno cache</code> would resolve all the dependencies for a supplied module and
  122. populate the Deno cache. <code>deno bundle</code> can be used to generate a single file
  123. “build” of a workload which all the dependencies are resolved and included in
  124. that file, so only that single file is needed for future <code>deno run</code> commands.</p>
  125. <h2 id="trusting-code">Trusting code</h2>
  126. <p>This is another area where I think we have a skewed mental model. For whatever
  127. reason, we put trust in code that is in a centralized registry. We don’t even
  128. think about it. Not only that, we trust that that code has fully vetted all of
  129. its dependencies and that those are to be trusted to. We do a quick search and
  130. type in <code>npm install some-random-package</code> and think “This is Fine!” I argue the
  131. rich npm package eco-system has lulled is into a sense of complacency.</p>
  132. <p>To compensate for this laxness and complacency, we implement security monitoring
  133. software in our tool chains, to analyse our dependencies and the thousands upon
  134. thousand lines of code to let us know that maybe some of the code is
  135. exploitable. Corporations setup private registries to host packages that might
  136. be vetted slightly more than the single public registry.</p>
  137. <p>It feels like there is an elephant in the room here. The best strategy is we
  138. shouldn’t trust any code. Once we have that established, then opening it back
  139. up becomes a little be easier. But we are lying to ourselves if we think a
  140. package manager and a centralised registry solve this problem, or even
  141. substantially help with this problem. In fact, I argue they make use let our
  142. guards down. “Well it is on npm, if it were bad for me, surely someone would
  143. take it down.”</p>
  144. <p>Deno in this aspect isn’t quite as done as I think it should be, but it is
  145. starting from a good position. It has zero trust at startup, and provides
  146. fairly fine grained permissions. One of the things I personally dislike is that
  147. there is the <code>-A</code> flag, which is basically saying “oh yeah allow everything”
  148. which is such an easy thing for a frustrated developer to do instead of figuring
  149. out what they really need.</p>
  150. <p>It is also hard to break down those permissions, to say “this code can do this,
  151. but this other code over here can’t” or when code prompts to escalate privileges
  152. where is that code coming from. Hopefully we can figure out an easy to use
  153. mechanism coupled with something that would be effective and performant at
  154. runtime to try to solve those challenges.</p>
  155. <p>A recent change though, which is a good one, in my opinion, is that Deno no
  156. longer allows you to downgrade your imports. If something is imported from
  157. <code>https://</code> then it can only import from other <code>https://</code> locations. This
  158. follows the browser model of not being able to downgrade transport. I still
  159. think longer term it would be good to kill off any remote imports that aren’t
  160. over <code>https://</code>, much like Service Workers require HTTPS, so we will see what
  161. the future holds.</p>
  162. <h2 id="dependency-management">Dependency management</h2>
  163. <p>I think we need to talk frankly about dependencies in the npm ecosystem. To be
  164. honest, it is broken. An ecosystem that enables
  165. <a href="https://github.com/juliangruber/isarray/blob/master/index.js" target="_blank">5 lines of code</a>
  166. to be downloaded and installed
  167. <a href="https://www.npmjs.com/package/isarray" target="_blank"><em>30 million</em> times a week</a> for code that
  168. has been in every browser for the last 9 years and never was needed in Node.js
  169. is a broken ecosystem. This one example, the actual code is 132 bytes, but the
  170. package size is 3.4kb. The runnable code is 3.8% of the package size. “This is
  171. Fine!”</p>
  172. <p>My opinion is that there are several factors involved in this. A big part of it
  173. is that we have the model inverted, which I talked about Deno being a browser
  174. for code. The problem is that this backwards model has infected how we create
  175. websites. While we don’t have a central registry, when we build a website,
  176. we download all the code we depend up and bake it into something that we load
  177. up on a server, and then each user downloads a bunch of code to their local
  178. machine. Some evidence is that only around 10% of that code that is downloaded
  179. is unique to that site or web application, the rest is all that code we are
  180. downloading to our development workstation and bundling up. This model being
  181. broken are some of the problems solutions like
  182. <a href="https://www.snowpack.dev/" target="_blank">Snowpack</a> are trying to solve.</p>
  183. <p>Another significant problem is that our dependencies are not coupled with our
  184. code. We put dependencies in our <code>package.json</code> but if our code actually uses
  185. that code or not is totally decoupled. While our code expresses what we are
  186. using out of that other code, it is very loosely coupled to the version of that
  187. code. That is contained in the <code>package.json</code>, though it has the biggest impact
  188. on the code we write, because it is the code that is actually consuming the
  189. dependent code.</p>
  190. <p>This leads us to the Deno model, which I like to call <em>Deps-in-JS</em>, since all
  191. the cool kids are doing <em>*-in-JS</em> things. Explicitly stating our external
  192. dependencies as URLs means that the code depends upon the other code is concise
  193. and clear, and our code and dependencies are tightly coupled together. If you
  194. want to see that dependency graph, you simply need to use <code>deno info</code> with a
  195. local or remote module:</p>
  196. <pre><code class="language-shell">$ deno info https://deno.land/x/oak/examples/server.ts
  197. local: $deno/deps/https/deno.land/d355242ae8430f3116c34165bdae5c156dca21aeef521e45acb51fcd21c9f724
  198. type: TypeScript
  199. compiled: $deno/gen/https/deno.land/x/oak/examples/server.ts.js
  200. map: $deno/gen/https/deno.land/x/oak/examples/server.ts.js.map
  201. deps:
  202. https://deno.land/x/oak/examples/server.ts
  203. ├── https://deno.land/std@0.53.0/fmt/colors.ts
  204. └─┬ https://deno.land/x/oak/mod.ts
  205. ├─┬ https://deno.land/x/oak/application.ts
  206. │ ├─┬ https://deno.land/x/oak/context.ts
  207. │ │ ├── https://deno.land/x/oak/cookies.ts
  208. │ │ ├─┬ https://deno.land/x/oak/httpError.ts
  209. │ │ │ └─┬ https://deno.land/x/oak/deps.ts
  210. │ │ │ ├── https://deno.land/std@0.53.0/hash/sha256.ts
  211. │ │ │ ├─┬ https://deno.land/std@0.53.0/http/server.ts
  212. │ │ │ │ ├── https://deno.land/std@0.53.0/encoding/utf8.ts
  213. │ │ │ │ ├─┬ https://deno.land/std@0.53.0/io/bufio.ts
  214. │ │ │ │ │ ├─┬ https://deno.land/std@0.53.0/io/util.ts
  215. --snip--
  216. </code></pre>
  217. <p>Deno has no strong opinions around “versions” of code. A URL is a URL is a URL.
  218. While Deno requires an appropriate media type in order to understand how to
  219. treat code, all the “opinions” about what code to serve up is left up to the
  220. web server. A server can implement semantic versioning to its hearts content,
  221. or do any sort of “magical” mapping of URLs to resources it wants. Deno doesn’t
  222. care. For example <code>https://deno.land/x/</code> is effectively nothing but a URL
  223. redirect server, where it rewrites URLs to include a git commit-ish reference
  224. in the redirected URL. So <code>https://deno.land/x/oak@v4.0.0/mod.ts</code> becomes
  225. <code>https://raw.githubusercontent.com/oakserver/oak/v4.0.0/mod.ts</code>, which GitHub
  226. serves up a nice versioned module.</p>
  227. <p>Of course spreading “versioned” remote URLs throughout your codebase doesn’t
  228. make a lot of sense, so don’t do that. The great thing about the dependencies
  229. just being code though is that you can structure them any way you want to. A
  230. common convention is to use a <code>deps.ts</code> which re-exports all the dependencies
  231. you might want. Take a look at the one for
  232. <a href="https://deno.land/x/oak@v4.0.0/deps.ts" target="_blank">oak server</a>:</p>
  233. <pre><code class="language-ts">// Copyright 2018-2020 the oak authors. All rights reserved. MIT license.
  234. // This file contains the external dependencies that oak depends upon
  235. // `std` dependencies
  236. export { HmacSha256 } from "https://deno.land/std@0.51.0/hash/sha256.ts";
  237. export {
  238. Response,
  239. serve,
  240. Server,
  241. ServerRequest,
  242. serveTLS,
  243. } from "https://deno.land/std@0.51.0/http/server.ts";
  244. export {
  245. Status,
  247. } from "https://deno.land/std@0.51.0/http/http_status.ts";
  248. export {
  249. Cookies,
  250. Cookie,
  251. setCookie,
  252. getCookies,
  253. delCookie,
  254. } from "https://deno.land/std@0.51.0/http/cookie.ts";
  255. export {
  256. basename,
  257. extname,
  258. join,
  259. isAbsolute,
  260. normalize,
  261. parse,
  262. resolve,
  263. sep,
  264. } from "https://deno.land/std@0.51.0/path/mod.ts";
  265. export { assert } from "https://deno.land/std@0.51.0/testing/asserts.ts";
  266. // 3rd party dependencies
  267. export {
  268. contentType,
  269. lookup,
  270. } from "https://deno.land/x/media_types@v2.3.1/mod.ts";
  271. </code></pre>
  272. <p>I created oak server and maintained for 18 months through about 40 releases of
  273. Deno and the Deno <code>std</code> library, including moving of <code>media_types</code> from internal
  274. to oak, out to the <code>std</code> library, to only have it be “ejected” from the <code>std</code>
  275. library to be its own thing. Not once did I think to myself “hey, I need a
  276. package manager to manage this for me”.</p>
  277. <p>One of the benefits of TypeScript is that you can get comprehensive validation
  278. of compatibility of your code with other code. If your dependencies are “raw”
  279. TypeScript written for Deno, this is great, but let’s say that you want to take
  280. advantage of pre-processing of the TypeScript to JavaScript, but still have the
  281. ability to consume that remote code safely. Deno supports a couple different
  282. ways to allow that to happen, but the most seamless is the support for the
  283. <code>X-TypeScript-Types</code> header. This header indicates to Deno where a types file
  284. is located which can be used when type checking the JavaScript file that you
  285. are depending upon. <a href="https://pika.dev/cdn" target="_blank">Pika CDN</a> supports this. Any
  286. packages that are available on the CDN that have types associated with them will
  287. serve up that header and Deno will also fetch those types and use that when
  288. type checking the file.</p>
  289. <p>All this being said, there may still be a need to “remap” a remote (or local)
  290. dependency to what is expressed in the code. In this case, the unstable
  291. implementation of <a href="https://github.com/WICG/import-maps" target="_blank">import-maps</a> can be
  292. used. It is a proposal specification that is part of the W3C incubator where
  293. browser standards come out of. It allows a map to be provided which will map
  294. a particular dependency in code to another resource, be it a local file or a
  295. remote module.</p>
  296. <p>We had it implemented in Deno for an extended period of time, as we had really
  297. hoped that it would become adopted widely. Sadly, it was only an
  298. <a href="https://chromestatus.com/feature/5315286962012160" target="_blank">origin trial in Chrome</a> and
  299. hasn’t gotten wider adoption yet. This led us to putting it behind the
  300. <code>--unstable</code> flag for Deno 1.0. My personal opinion is that it is still a big
  301. risk of being a dead end, and should be avoided.</p>
  302. <h2 id="but-but-but">But, but, but…</h2>
  303. <p>I suspect a lot of people are still coming with a list of objections to the
  304. model that Deno has. I think the strategy Deno has tried to take, which I am
  305. very aligned to, is to deal with real problems when they arise. A lot of the
  306. objections I hear are from people who are new to Deno, who haven’t worked with
  307. it, who haven’t tried to understand that there might be a different way.</p>
  308. <p>All that being said, if we collectively run into a problem and there is a
  309. compelling need to change something in the Deno CLI, I am confident that it will
  310. happen, but a lot of problems simply don’t exist, or there are other ways to
  311. solve them that don’t require your runtime to have strong opinions or be coupled
  312. to an external programme to manage your code.</p>
  313. <p>So my challenge to you is, flirt a bit with not having a package manager or
  314. a centralised package repository and see how it goes. You might never go back!</p>
  315. </article>
  316. <hr>
  317. <footer>
  318. <p>
  319. <a href="/david/" title="Aller à l’accueil">🏠</a> •
  320. <a href="/david/log/" title="Accès au flux RSS">🤖</a> •
  321. <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
  322. <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
  323. <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
  324. </p>
  325. </footer>
  326. <script src="/static/david/js/instantpage-3.0.0.min.js" type="module" defer></script>
  327. </body>
  328. </html>