[HN Gopher] Deno on MDN
___________________________________________________________________
Deno on MDN
Author : searchableguy
Score : 412 points
Date : 2021-08-23 10:57 UTC (12 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| staticelf wrote:
| That is great, good work you guys!
| [deleted]
| andrewmcwatters wrote:
| Imagine building a business and putting years of labor into a
| suite of intellectual property which makes you hundreds of
| thousands of dollars then they guy who built what your business
| runs on came out with something new to replace it and said hey
| now you can import using URLs and by default have access to
| nothing unless you ask for it.
|
| OK?
|
| Reminds me of how Rome is doing.
|
| You can't reinvent this stuff over and over again and ignore that
| at the end of the day there are people who use this stuff to make
| money. Node.js is already good enough.
|
| I think if people end up using Deno it'll be because of things
| people need to use that you can't get or polyfill into Node.js
| today.
|
| But it won't be because of new behaviors.
| danr4 wrote:
| _You can't reinvent this stuff over and over again and ignore
| that at the end of the day there are people who use this stuff
| to make money._
|
| Another way to say that: You _can 't_ build _new_ awesome free
| stuff because other people already use your _old_ awesome free
| stuff to make money.
|
| Sounds ridiculous.
|
| They can and should keep making new stuff, for the next
| generation of people and apps, whether to use it or not is an
| individual/organizational choice.
| andrewmcwatters wrote:
| If I told you I'm giving you an annual $600,000 budget to
| build a small team and write software, and you chose Deno and
| had to reinvent JavaScript libraries that already existed for
| years, I'd fire you for being negligent with funds.
|
| What you're saying sounds ridiculous.
| TechBro8615 wrote:
| Stop building new stuff?
| stepbeek wrote:
| This is really cool! Can anyone explain why deno has made it to
| MDN but node.js has not?
| earthboundkid wrote:
| Because Node is the new IE.
| jamil7 wrote:
| I believe it's because Node.js has never made an effort to
| implement web APIs nor has it been a goal of the project.
|
| Edit: as others have pointed out, APIs that are implemented in
| Node.js are listed on MDN.
| lucideer wrote:
| Worth noting, informationally, it is a goal of the Node.js
| project to implement web APIs. Deno is just way ahead as it
| doesn't have to worry about backward compat: it's a much
| tougher challenge for the Node.js guys, but they are working
| on it.
| mirekrusin wrote:
| nodejs is there as well, ie. [0]. Maybe it's missing for apis
| they don't provide? ie. fetch [1] does not list nodejs.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| [1] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
| [deleted]
| opheliate wrote:
| Node is on a number of MDN pages (e.g: [0]). I think it's just
| APIs that Deno supports and Node doesn't (e.g: fetch) that are
| linked here, which is why it's not in their support matrices.
|
| 0: https://developer.mozilla.org/en-US/docs/Web/API/console/log
| chrismorgan wrote:
| setTimeout is linked here, https://developer.mozilla.org/en-
| US/docs/Web/API/WindowOrWor..., and shows partial support
| (with explanations) for Node.js.
| styfle wrote:
| Also see TextEncoder or WebAssembly which shows the version
| support of Node.js and others
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/TextEncoder...
|
| https://developer.mozilla.org/en-
| US/docs/WebAssembly#browser...
| lucideer wrote:
| node is on MDN for all browser APIs it implememts, there's just
| not many of them. Deno has much higher browser compat.
|
| It's worth noting this isn't Node's fault: most Node APIs
| existed before there were browser equivalents and adding
| browser compat now is much harder for Node than for Deno which
| is starting from scratch.
| timdaub wrote:
| > Deno has much higher browser compat.
|
| Is this a fact or a personal feeling? Any links to back up
| this statement?
| lucacasonato wrote:
| This is a fact. Import maps, fetch, ESM + web import
| semantics, localstorage, WebGPU, WHATWG streams, WebCrypto.
| Deno runs the shared web platform test suite:
| https://deno.co/wptfyi. You can also just look on MDN now
| and see which APIs are implemented in Deno compared to Node
| :-)
| timdaub wrote:
| Is import maps considered an accepted proposal [1]?
|
| What's the point of implementing APIs like WebGPU and
| localstorage in a non-browser environment? I get WHATWG
| streams, esm, fetch and WebCrypro though.
|
| - 1: https://github.com/WICG/import-maps
| vorticalbox wrote:
| Local storage let's you save state across process
| restarts and session storage let's you share data across
| worker threads
|
| You could save the state of a discord bot across restarts
| for example.
| norman784 wrote:
| About webgpu
|
| > The WebGPU API gives developers a low level, high
| performance, cross architecture way to program GPU
| hardware from JavaScript.
|
| > GPUs allow programmers to make some numerical
| algorithms highly parallel. This is useful beyond
| rendering graphics and games. Effective use of GPUs in
| Machine Learning has enabled more complex neural networks
|
| - https://deno.com/blog/v1.8#experimental-support-for-
| the-webg...
| tehbeard wrote:
| Implementing WebGPU allows you to make use of GPU
| resources on the server (from rendering to more compute
| focused)
|
| Localstorage is admittedly a bit niche, but works well as
| a way to bypass the need to get generic read/write
| permissions for the filesystem for a config file. (Deno
| implements a permission model similar to the web where
| you start with nothing and must request / have pre-
| granted access to resources like
| files/network/env/subprocess, and this access can be
| granular to specific files/directories/host+port combos)
| lucideer wrote:
| The sibling commenter covered the list well. To go into a
| little extra context on the reasoning:
|
| fetch: Browser fetch didn't exist when NodeJS introduced
| its http built-ins. Many NodeJS libs are built on top of
| http built-ins, so replacing them would be a nightmare.
| Adding browser fetch on top of the existing http built-ins
| would similarly just give NodeJS a massive API surface area
| with cconfusingly duplicated functionality.
|
| ESM + web import semantics: NodeJS was part of the
| "commonjs" movement that _invented_ Javascript module
| importing. Module imports are an incredibly complex problem
| and hard to get right. Browsers took the hard-learned
| lessons from commonjs & nodejs and redesigned better
| modern APIs. NodeJS has been slowly trying to add support
| for the much improved browser web import semantics, but
| doing so while maintaining backward compatibility with
| their radically different commonjs APIs is a nightmarish
| challenge (they're working on it though, progress is good).
|
| WHATWG streams: similar story to the import/commonjs
| situation. NodeJS basically "invented" streams in JS, and
| the WHATWG API is a newer design based on NodeJS lessons.
|
| WebCrypto: Sibling comment is incorrect here actually:
| NodeJS & Deno both support this[0]
|
| [0] https://developer.mozilla.org/en-US/docs/Web/API/Crypto
| timdaub wrote:
| I use esm in nodejs >= 14 since roughly 6 months and I'm
| almost back to where I was with CommonJS. Problems that I
| have:
|
| - ESM modules are challenging to mock or monkeypatch
|
| - I feel like the ESM implementation is more "magic" than
| require. I definitely would say I understood require
| better.
|
| - Many esm features are still behind flags e.g. importing
| a .json file.
|
| I'd guess that by the time Deno gets really good, Nodejs
| achieved same level of compatibility.
| lucideer wrote:
| > _ESM modules are challenging to mock_
|
| > _I definitely would say I understood require better_
|
| ESM modules are in many ways "harder" to use than
| commonjs, but I think this comes down to something
| slightly intangible but very similar to the static-typing
| -vs- duck-typing discussion (duck-typing is more
| obviously intuitive and quick-to-do-what-you want, but
| static-typing has more wide-reaching architectural
| benefits for scaling projects).
|
| CommonJS is a more "intuitive" design: what you might
| expect someone to design first-time-around. ESM is a more
| thought-through design: the initial "hurdles" to its use
| bring long-term benefits.
|
| > _ESM modules are challenging to [...] monkeypatch_
|
| This seems like a feature though
|
| > _I feel like the ESM implementation is more "magic"
| than require_
|
| How so? I'd say I feel the opposite.
|
| > _importing a .json file_
|
| Is this supported by browsers or is it a NodeJS
| extension?
| lucacasonato wrote:
| > Is this supported by browsers or is it a NodeJS
| extension?
|
| This is a node extension. It is coming to browsers in
| form of import assertions. See
| https://github.com/tc39/proposal-import-assertions
| lucideer wrote:
| Oh, good to know! I hadn't heard this.
|
| Just for anyone tracking progress, the actual feature
| proposal is here: https://github.com/tc39/proposal-json-
| modules - the assertions proposal is just a security
| check on top of such modules.
| oauea wrote:
| Can someone "sell me" on Deno? I'm still not sure why I should be
| interested in this versus for example NodeJS. Most of the
| features it lists seem rather dubious.
|
| > Secure by default. No file, network, or environment access,
| unless explicitly enabled.
|
| Great, but we're talking about server software so the first thing
| any project is going to do is enable all of that. And it's not
| like you can trust this on the server, you'd still need to
| sandbox to process if you truly want isolation.
|
| > Supports TypeScript out of the box.
|
| Okay so it's coupled to Microsoft's take on Javascript. What
| about Flow or any of the other compiles-to-Javascript languages?
| What's wrong with using Babel with sourcemaps?
|
| > Ships only a single executable file.
|
| I guess that could be convenient but I'm struggling to think of a
| situation where installing node has ever been a problem.
|
| > Has built-in utilities like a dependency inspector (deno info)
| and a code formatter (deno fmt).
|
| Is this not the job of the package manager? Or does deno force
| you to use itself as the package manager? Will that not just
| bring about another npm situation in a few years?
|
| I feel like I'm clearly missing something with how excited
| everyone is about deno, but I have no idea what it is.
| ecmascript wrote:
| Honestly for me it is:
|
| - Follows the ecmascript standard and supports browser apis
|
| - No npm, no Microsoft lock-in
|
| - So far, no political bs like node has had
| FaisalAbid wrote:
| Is Deno ready for production?
|
| What limitations have you run into?
| lucacasonato wrote:
| https://news.ycombinator.com/item?id=28131876
| ecmascript wrote:
| > Is Deno ready for production?
|
| Yes.
|
| > What limitations have you run into?
|
| Libraries that exist for node that can't easily be ported
| over that don't yet exist for Deno. But that is basically
| it. In the beginning it was a bit hard to keep up with the
| rapid changes as well but that seems like a positve thing
| anyway.
| croes wrote:
| No deno native MS SQL support
| chovybizzass wrote:
| Most of the 3rd party modules have been abandoned.
| dmitriid wrote:
| > No npm
|
| You still need packages
|
| > no Microsoft lock-in
|
| Does Deno implement its own TypeScript compiler? Even if it
| does, it's entirely at the mercy of Microsoft who are the
| only ones who develop Typescript specs.
| ecmascript wrote:
| > You still need packages
|
| Yes but with ES modules you can just import them straight
| into the code and there is really no need for a package
| manager.
|
| > Does Deno implement its own TypeScript compiler? Even if
| it does, it's entirely at the mercy of Microsoft who are
| the only ones who develop Typescript specs.
|
| This may be somewhat true. However I am not using
| typescript so I am not really sure about this.
|
| My point is not really tied to the language typescript
| which I am sure will continue just fine. What I am much
| more worried about is all the packages hosted on npm. At
| any time Microsoft could do something to restrict it in
| ways I can't control. Highly unlikely that something
| extreme will happen perhaps, but I don't trust Microsoft
| enough.
|
| For example, I could easily see them forcing everyone to
| use github for node packages in the future etc.
| dmitriid wrote:
| > you can just import them straight into the code
|
| "Just import them". From where?
|
| > What I am much more worried about is all the packages
| hosted on npm. At any time Microsoft could do something
|
| So, how does deno help?
| ecmascript wrote:
| From anywhere on the internet.
|
| > So, how does deno help?
|
| By decentralizing the package hosting.
| sieve wrote:
| > You still need packages
|
| Which you import just like you would in a browser.
|
| > Does Deno implement its own TypeScript compiler?
|
| Deno is a JS engine that aims for maximum compatibility
| with browsers.
|
| While not exactly a second class citizen, losing Typescript
| (if it comes to that) is something the platform can
| survive. Ryan is on record saying that adding Typescript
| support at a very early stage was probably a mistake.[1]
|
| [1] https://www.youtube.com/watch?v=vBd4tPUBUQo
| dmitriid wrote:
| > Which you import just like you would in a browser.
|
| Import them from where?
|
| Also, if I have more than 10 packages, it makes sense to
| bundle them
|
| > While not exactly a second class citizen, losing
| Typescript (if it comes to that) is something the
| platform can survive.
|
| That is not what I asked/pointed out
| sieve wrote:
| > Import them from where?
|
| A url. The files are cached. You can always explicitly
| vendor dependencies and use relative imports (or import
| maps) if you don't want to rely on random urls.
|
| > Also, if I have more than 10 packages, it makes sense
| to bundle them
|
| And Deno has a built-in bundler.
| andrew_ wrote:
| The more I learn about how it imports external/third-party code
| [1] the more I like it. It's got none of the hangups of NPM. No
| package.json nonsense (there are great script runners if you
| need them), and no cruft when importing external code (e.g. no
| need for yarnclean). The registry they do maintain is unique
| and immutable, which I was not sold on until I had this
| discussion [2]. I do still think they need some more guidance
| around how that works, and some contingencies in the event of
| bad actors, but it's just as good as NPM's registry imho.
| Native TS is a nice convenience for projects which call for it,
| and compiling is much more streamlined than bolting it onto a
| project yourself. It's worth noting that it does support plain
| JS, just the ESM flavor. And last but not least is the stdlib,
| which roughly aims to prevent the need for a million one-line
| packages spread out across the registry. Network throughput
| performance is impressive to say the least, and with leveraging
| Rust I can only see that getting better. The more I learn about
| Deno the more that I'm liking it.
|
| [1] https://deno.land/manual/linking_to_external_code [2]
| https://github.com/denoland/deno/discussions/11809#discussio...
| nightpool wrote:
| I was just having this discussion with a friend of mine this
| morning. How is this not the exact same mistake Go made when
| it was released in 2015? They spent years and years walking
| back the issues that "go get" had in favor of a real, actual
| package manager. I know Deno encourages users to use
| versioned imports, which works around some of the bigger
| problems that Go had, but creates a lot more problems in
| terms of upgrading transitive dependencies. How is this a
| step forward?
| silasdavis wrote:
| Yes, it seems like a very similar mistake to me: https://gi
| thub.com/denoland/deno/issues/4574#issuecomment-62...
| whateveracct wrote:
| Ignoring hard problems for short-term gains is an easy way
| to get market share.
| lucacasonato wrote:
| We don't ignore these problems. We find web compatible
| ways to solve them. If you had done just about 3 seconds
| of research before posting, you would have noticed we
| have support for import maps[1]. These elegantly solve
| the issue in a way that also works in the browser. No
| node_modules needed :-)
|
| [1]: https://deno.land/manual@v1.13.1/linking_to_external
| _code/im...
| whateveracct wrote:
| That looks like the output of a package manager (like a
| cabal freeze file), but if that's all you got then you
| don't have a package manager yet.
| andrew_ wrote:
| projects like `trex` [1] take the heavy lifting out of
| the equation, and are nicely compatible with a lockfile.
| This may feel familiar, even somewhat similar, but after
| using it for a short time I state with confidence that
| it's not a package manager. This paradigm is enjoyable.
|
| [1] https://nicedoc.io/crewdevio/Trex
| spankalee wrote:
| Import maps are great if you know all the mappings you
| want to make.
|
| That requires that you know every way that conceptually
| the same packages are imported in the entire transitive
| module graph, which is hard enough on its own, but also
| requires crawling the whole live module graph to discover
| all the imports. I don't see how this isn't just npm-but-
| worse.
| whateveracct wrote:
| It'll eventually evolve into npm-but-different once Deno
| gains more adoption and its users learn they need a real
| package manager. And the cycle continues.
| spankalee wrote:
| It's quite a bit worse than npm.
|
| Without bare module specifiers (like `import {html} from
| 'lit-html'`) to act as an abstraction over location you have
| to import directly from a URL, but what URL? Packages either
| have to be self-hosted, or very often npm packages are loaded
| via CDNs. There are several CDNs that host the same packages
| (unpkg, Skypack, jspm, jsDelivr/esm.run) so there's no single
| canonical URL to load anything from and each module that
| loads a package could load from a different CDN, or simply
| load a slightly different but compatible version, causing
| multiple copies of the packages to be loaded.
|
| There's a huge benefit to abstracting over package names, and
| Deno mostly throws it all away. It does support import maps,
| but you'd need tooling that doesn't fully exist yet to crawl
| and dedupe a module graph and at that point it'd basically be
| npm but a lot slower with no registry to use for metadata.
| andrew_ wrote:
| > It's quite a bit worse than npm.
|
| That's a rather subjective take.
|
| The rest of your comment can be fulfilled by `trex`
| https://nicedoc.io/crewdevio/Trex. Perhaps it's been a
| while since you took a good look at how the ecosystem has
| evolved. I just started giving Deno a hard look last week
| and I've already found answers for needs like this.
| spankalee wrote:
| Aren't most takes on here subjective? I don't think we
| label most posts with "Only my opinion, but..." event
| though that applies to almost everything here. Anyway...
|
| Trex doesn't do anything about transitive dependencies
| and package deduplication, what my critique is about.
| ramesh31 wrote:
| >Okay so it's coupled to Microsoft's take on Javascript. What
| about Flow or any of the other compiles-to-Javascript
| languages? What's wrong with using Babel with sourcemaps?
|
| This is kind of like saying "Oh it supports Javascript? So
| now I'm tied to Netscape's take on browser scripting?" at
| this point. Typescript has won the JS compiler wars and
| become the defacto standard for the community.
| [deleted]
| spankalee wrote:
| Which slightly incompatible version of TypeScript though?
|
| edit to add: I'm serious. JavaScript tries very hard to not
| have backward breaking changes. TypeScript does have
| breaking changes at about ever minor release. The
| TypeScript team manages the project as a versioned tool,
| not as a distributed environment like the web. afaik, Deno
| hasn't really solved this problem, so there's a chance your
| code breaks when Deno upgrades its TypeScript version.
| oatmealsnap wrote:
| That's always a concern, though. Node has breaking
| changes, too.
| Vinnl wrote:
| It's a somewhat relevant concern, but also less so
| because breaking changes in TypeScript are usually
| semantic (type-checking) ones and most of the times make
| it error on bugs (i.e. code that hopefully isn't in your
| codebase already, and if it is, you'll want to take it
| out). Deno doesn't do type checking, it just strips
| TypeScript's type annotations, which they're far more
| careful about breaking.
|
| Even so, they could limit such breakage to major Deno
| versions with other breaking changes, if necessary. Not
| sure if they do.
| DanielVZ wrote:
| > Great, but we're talking about server software so the first
| thing any project is going to do is enable all of that. And
| it's not like you can trust this on the server, you'd still
| need to sandbox to process if you truly want isolation.
|
| Except that we aren't talking about server software. Node is a
| js runtime environment, and it is being used for other things
| like scripts and CLIs.
|
| > I guess that could be convenient but I'm struggling to think
| of a situation where installing node has ever been a problem.
|
| There are a ton of CLIs made with node that need to be
| installed globally. As someone that never uses node this
| feature would help me keep my binaries explicitly and tidily
| under `~/.local/bin`.
| jfbaro wrote:
| For me the main selling points are:
|
| - Security; - More suitable for Serverless deployment (like
| running a full server on V8 Isolates) - Cloud Workers and
| Fastly (0ms cold starts)... check this out ->
| https://deno.com/blog/deploy-beta1 - Embraces Typescript as a
| first class citizen.
| forrestthewoods wrote:
| It was made by the creator of NodeJS and fixes many issues he
| considers to be mistakes. Do you like NodeJS? This is NodeJS
| 2.0.
| hn_throwaway_99 wrote:
| I've seen the original Dahl post about his mistakes with
| NodeJS, and why he wanted to do Deno, and to be frank, I'm
| not convinced.
|
| It's not that I disagree with Dahl on most of his recognized
| mistakes (though some I do, most especially that a
| standardized, embedded packaging system was a mistake,
| despite the legions of warts of NPM), it's that most of these
| mistakes feel like little nits or one-time costs that just
| don't bother me at all in the Node world.
|
| I mean, it feels like the _best_ thing going for Deno is out-
| of-the-box TypeScript support, but with Node it 's trivial to
| have a template project that integrates all this for you,
| then it's 1-and-done. Perhaps the other thing I like about
| Deno is it separates the standard library into its own
| package instead of being part of the Deno-runtime version,
| but again, this difference is definitely not enough to make
| me switch.
| andrewmcwatters wrote:
| Deno feels like past the peak technology to me. You've got
| years and years of labor put into the Node.js ecosystem,
| and then the guy comes out with something that totally
| drops all of that for some gimmick features.
|
| Could you not just build a URL loader and cache for
| importing in Node.js? Could sandboxing not just be a flag
| in Node.js? Do you really need TypeScript built in?
|
| I'm not going to throw years of my and other's work away
| for some gimmicks. It's just a bad investment.
| snarfy wrote:
| npm is hot garbage. If it fixes npm I'm all for it.
| kriz9 wrote:
| I am struggling to understand how Deno is supposed to do
| that. To me it seems like they are re-inventing the
| package.json What is the difference ? https://deno.land/manua
| l@v1.13.1/examples/manage_dependencie...
| koolhaas wrote:
| I would say, it doesn't really fix npm. It has its own
| centralized npm repo, called deno land, and it's own
| package.json, called deps.ts.
|
| Because it can accept any URL as a dep in the source files,
| you can in theory do some cuter, weirder things with it. But
| security wise I'd argue arbitrary URLs, for critical, high
| traffic deps, are harder to fix when bad things happen,
| without centralized control.
| iainmerrick wrote:
| This something I really don't understand about Deno. I feel
| like I must be missing something.
|
| How do I pin the versions of my dependencies? i.e. where is
| the package lock file?
|
| If the idea is that every source file will specify the
| version it wants of every dependency, that seems
| unmanageable. Or if every source file just imports the
| latest version of its deps, how do I get reproducible
| builds?
|
| I _want_ a lockfile with an explicit manual step to update
| dependencies. "npm ci" seems to work well. I don't see how
| Deno improves on it, quite the reverse.
|
| _Edit to add:_ hmm, there are some docs here that look
| relevant: https://deno.land/manual/linking_to_external_code
| /integrity_... But this reads as "if you really want
| package integrity, here are some awkward commands you can
| run to do it". I strongly feel this should be the _default_
| behaviour that the tools should steer you towards. And in
| the examples on this page, the source code does link to
| specific library versions; I have a hard time accepting
| that that's a good idea, except possibly for major
| versions.
| mekkkkkk wrote:
| If you want to use locked version deps from VCS you point
| to a specific tag, not a branch IIRC.
| wperron wrote:
| yeah, it's a bit awkward and you have to dig through the
| docs to find it. We're thinking about making it the
| default behavior.
| iainmerrick wrote:
| Please do! I think that would be a big win.
|
| The package integrity and import maps sections of the
| docs look like they do everything that's needed, they
| just look fiddly to use correctly.
|
| Maybe it just wants something as simple as an optional
| .denorc at the root of your project to set the default
| flags?
| wperron wrote:
| deno.land/x is _not_ a central registry. It's something we
| maintain as a convenience to the community, but we actually
| go to great lengths to make sure it doesn't receive
| preferential treatment from the CLI. Importing modules from
| nest.land, skypack.dev, esm.sh or jspm.io is common in the
| ecosystem and is something we're looking to keep
| encouraging.
|
| It's also pretty easy to vendor in your dependencies so
| that they don't move between the time you commit and the
| time your server starts. We also support lock files so you
| don't _have_ to vendor your deps too. Versioning is up to
| the server you import from, but typically you'd put version
| in the URL somewhere (ideally a pinned version).
|
| Security-wise, There are other articles out there that
| detail this but it's not fundamentally less secure than
| importing from npm as you're still pulling a JavaScript
| file from the internet in both cases. The cool thing here
| with URLs is that it's pretty easy to audit and create an
| allowlist of known-good and trusted servers to import from
| in your org.
|
| As for vulnerability reporting & patching; I think we're
| still lacking a good vulnerability database, that much is
| true, but fixing deeply integrated deps that have
| vulnerabilities is pretty easy using import maps really.
| koolhaas wrote:
| Thanks for the response. And thank you for clarifying
| that there is a larger ecosystem of package repositories,
| and that Deno does not give preferential treatment to
| any. In theory npm can do the same, but of course there
| is official support and community gravitational pull
| around a single service.
|
| I agree there is nothing fundamentally less secure in
| general, but what you don't get is being able to
| standardize around security for dev account protection,
| policies around immutability, DNS stuff, and some other
| centralized security measures. Neither are bullet proof,
| but there are some things you can't protect against with
| random URLs.
|
| I'd argue URLs are fine until you get massive use of a
| single package and it weaves itself into a complex
| dependency tree across multiple other critical projects.
| Then you worry about the what if's.
| wperron wrote:
| > I'd argue URLs are fine until you get massive use of a
| single package and it weaves itself into a complex
| dependency tree across multiple other critical projects.
| Then you worry about the what if's.
|
| This is already an issue with npm. My personal take on
| this is that at that point that dependency should be
| vendored as much as possible but obviously it's hard to
| fight the existing inertia on this one. Also worth noting
| that the [std lib][1] is an attempt at a pragmatic
| solution to the problem where these foundational packages
| that are seemingly used by every framework out there
| essentially converges to the standard lib. I agree it's
| not perfect at the moment but it's a start.
|
| [1]: https://deno.land/std
| hn_throwaway_99 wrote:
| I disagree npm is hot garbage. I'd say it's more like
| "smoldering garbage".
|
| Point being it most definitely _was_ hot garbage, but I feel
| like most of the biggest pain points have been fixed. Not all
| of them, and the history of being hot garbage certainly rears
| its head every now and then, but for the most part npm just
| works for me these days and I don 't have complaints.
| Already__Taken wrote:
| Deno looks great to glue together CICD work
| tills13 wrote:
| > Okay so it's coupled to Microsoft's take on Javascript
|
| I think your bias is showing.
| handrous wrote:
| > > Secure by default. No file, network, or environment access,
| unless explicitly enabled.
|
| > Great, but we're talking about server software so the first
| thing any project is going to do is enable all of that. And
| it's not like you can trust this on the server, you'd still
| need to sandbox to process if you truly want isolation.
|
| See below re: static builds, but they're making decisions that
| render Deno much more useful for cross-platform desktop
| distribution ("what do you mean, cross platform scripts are
| already easy to distribute" LOL I mean cross-platform
| _including Windows_ ) than Node, or most other scripting
| languages, for that matter.
|
| > > Supports TypeScript out of the box.
|
| > Okay so it's coupled to Microsoft's take on Javascript. What
| about Flow or any of the other compiles-to-Javascript
| languages? What's wrong with using Babel with sourcemaps?
|
| Having it built in means your JS build Jenga tower can be a
| little shorter, which is great, because the JS build ecosystem
| is batshit crazy. TypeScript's the right horse to back because
| it's become a de facto standard already--its tooling is much
| better than Flow, for one thing, and a lot of people seem to
| prefer its style. It's a better choice than other compile-to-JS
| languages because it's _very_ close to vanilla Javascript, to
| the point that you can tell it to compile to JS that looks
| hand-written and clearly maps to what you wrote in the TS (this
| is because its compilation process is mostly just stripping out
| all the TS stuff). To adopt something like Elm would be to ask
| developers to develop a completely different language, not just
| JS-with-static-types. Why static types built-in at all? It can
| allow for good advances in tooling and performance that wouldn
| 't be available without it.
|
| > > Ships only a single executable file.
|
| > I guess that could be convenient but I'm struggling to think
| of a situation where installing node has ever been a problem.
|
| This is, to be blunt, fucking wonderful if you're distributing
| to both Unixy operating systems and Windows, especially if you
| don't have tight administrative control over all machines
| involved. Vendoring in stuff like your script runtime is
| brilliant for preventing all kinds of problems, and if it's a
| single static binary or (even better) produces static bins that
| bundle your script, too, then that's very easy to do. Besides,
| dealing with NPM (or any other language package manager--pip,
| etc, they're all a pain in the ass when it comes to
| distribution) on the user end sucks, so you're going to want to
| bundle _everything_ up in one file anyway, one way or another,
| if you can.
|
| > > Has built-in utilities like a dependency inspector (deno
| info) and a code formatter (deno fmt).
|
| > Is this not the job of the package manager? Or does deno
| force you to use itself as the package manager? Will that not
| just bring about another npm situation in a few years?
|
| This is one thing Go got very right. Building in the basic
| tools is the right thing to do.
| the_mitsuhiko wrote:
| Why do you need to be sold on Deno?
| jjice wrote:
| I imagine the parent is confused as to why people care about
| Deno since it gets a decent bit if coverage on HN.
| the_mitsuhiko wrote:
| It's a different question why something is popular on
| hackernews or why someone should use something. Deno is
| interesting and worth paying attention to, that does not
| mean someone should be sold on it or build something with
| it (yet?).
| spiderice wrote:
| But clearly people are using it. GGGP is asking why
| people are choosing it. It's a very straight forward
| conversation and I feel like you're nitpicking word
| choices.
| the_mitsuhiko wrote:
| I don't see this as a good faith conversation. It's one
| thing to ask why people are using something, another
| thing entirely is to get people to convince one to use
| it. Particularly when the post already starts with a few
| statements of not liking it.
| oauea wrote:
| It's just an idiom[1]:
|
| > To be confident in or convinced about something's
| viability, veracity, etc., often to the point of being
| enthusiastically supportive of it.
|
| People on HN seem excited about it. I wanted to learn why,
| and have received a lot of great responses!
|
| [1] https://idioms.thefreedictionary.com/be+sold+on+something
| mattlondon wrote:
| 1 - it is not just server software, but general purpose usage.
|
| 2 - personally I don't see why you'd want to use anything other
| than Typescript right now. It certainly feels like TypeScript
| has "won" and is now the defacto standard for anyone doing any
| kind of work in the JS-ecosystem. That of course may change in
| the future of course, but today it feels like TS is where its
| at.
|
| 3 - I've experienced a lot of annoyance shipping around huge
| node_modules/ directories, just to get a CLI app working. Sure
| these are not "problems", but it is a pain to have to compress
| up hundreds of thousands of files and then decompress again
| rather than just moving around one executable.
|
| 4 - deno is the "package manager", if you can call it that. You
| explicitly state the imports & versions you need in your code
| as import statements, and the deno runtiem handles sourcing the
| files for you transparently. So either from a cache, or at
| first run it will try and go out onto the network (internet or
| proxied IIRC) to get them for you.
| franciscop wrote:
| [deleted comment]
| andrew_ wrote:
| This is something often overlooked by fans of typing. On
| the surface it may appear to some as being strongly typed,
| but it's a mirage [1] and frequently requires a lot more
| lifting, e.g. writing specific typings to work around
| shortcomings, just to make the types play nice together.
| That's not a feature of a strongly typed language, it's a
| feature of statically type-checked languages or schemas.
|
| I still use TypeScript, and I understand the benefits, but
| I'm not always a fan and will write plain JS when it fits
| better than TS.
|
| [1] https://news.ycombinator.com/item?id=15090561
| manigandham wrote:
| All typing is a mirage, enforced at various levels by
| various tools, whether that's a compiler during the build
| or a VM during runtime.
|
| Everything gets compiled down to the same machine code in
| the end.
| twooster wrote:
| I've seen this take so many times an I simply don't get
| it. The notion that TypeScript can't be (some form of)
| strongly-typed because Javascript is (some form of)
| weakly-typed is just silly. CPUs are entirely weakly
| typed in this sense and this doesn't impact the typings
| of languages built on top.
|
| JavaScript is strongly typed in the sense that every
| value has a well-defined type. It's weak in the sense
| that it has implicit conversion between types in a lot of
| cases, but it's not as though those conversions don't
| follow particular rules if you know the types.
|
| TypeScript gives you accurate static typing on top of
| that, so long as you don't use `any` as an escape.
| Arguably, `JSON.parse` returning `any` is the 1-million
| dollar mistake of TypeScript, because it leads a lot of
| people to think that they get automatic runtime
| typechecking for free, which they obviously don't, which
| leads to comments about how bad/slippery TypeScript is
| stemming from their misunderstanding.
|
| In my experience, you only need to work around typings in
| TypeScript when you're dealing with some absurdly
| designed API that only made sense in the super-flexible
| world of olden-days JavaScript, or perhaps if you're
| doing some meta-programming, generating class definitions
| on the fly or such.
| andrew_ wrote:
| > I've seen this take so many times an I simply don't get
| it.
|
| That may sincerely be, because how it feels as you're
| using it doesn't align with the objective truths of how
| it behaves. The definition of a strongly typed language
| has been well-cemented for some time. TypeScript does not
| completely align with that definition, thus it cannot be
| considered truly strongly typed.
| wruza wrote:
| _The definition of a strongly typed language has been
| well-cemented for some time_
|
| What is it? Is e.g. C++ strongly typed in that sense?
| k__ wrote:
| I didn't like TypeScript when writing frontend only code,
| because the the iteration speed is just so fast in the
| browser.
|
| But when I started using it for backend and infra, the
| iteration speed is much slower, so even TS only saves a
| few % of deploys, it's still a noticeable amount of
| absolute time.
| handrous wrote:
| Typescript is miraculously productive on the front-end as
| soon as you've got people writing at different "layers"--
| someone writing a frontend library, someone else handling
| state and actions, someone writing components for re-use,
| someone making it look pretty and using those components.
| You can be sitting right next to someone using code you
| wrote but rarely need to discuss it because the types
| communicate everything so damn well.
| Otek wrote:
| It's no more, or less future-proof. And as much as counting
| productivity of a programmer in LOC doesn't make any sense,
| your take on typescript does not either. It's extra
| security that matters. Typescript just prevents you from
| shooting your foot off (btw. show me, even small program,
| where Typescipt added 50% LOC)
| [deleted]
| thatwasunusual wrote:
| > personally I don't see why you'd want to use anything other
| than Typescript right now.
|
| Ditto. It's also important to remember that TS transpiles to
| JS, so you're not locked in in that sense.
|
| (I've actually seens TS-to-JS-transpiled code that is much
| better than code that was written in/as JS in the first
| place.)
| Otek wrote:
| 1. yeah but mostly node is used as a server software. Python
| is much better as 'general purpose' right now 3. ????? Why
| would you ship with node_modules? ALWAYS use npm install. If
| you don't trust npm, the use something like CodeArtifact, but
| oh my, don't compress dependencies.
| IggleSniggle wrote:
| 1. I don't buy that python is necessarily much better as
| general purpose. It has a lot of great libraries for some
| specific things, but its performance is worse and its type
| story isn't nearly as good as TypeScript's.
|
| 3. I have a few internal CLIs for use in scenarios that
| don't have npm available by default. It's very nice to be
| able to ship a single runtime and not have the folks
| downstream from me need to worry about node version + npm
| version + package installs from untrusty sources, etc. I
| can do that work so they don't need to, and give them a
| single runtime. I happen to not use Deno at the moment, but
| it's an appealing feature. Python has a comparable problem:
| I run into issues with some frequency around python
| versions and python environments. There are solutions, yes,
| but there are also scenarios where you want to bring your
| own dependencies.
|
| I haven't used CodeArtifact, but is it something you can
| deploy on-premise?
| megous wrote:
| Why ship node_modules? Because you want to ship the
| complete app. At least rsync comes to the rescue for quick
| deploy of 10000 tiny files remotely.
| throwaway894345 wrote:
| > Python is much better as 'general purpose' right now
|
| Python has lots of its own problems. Specifically, its type
| system, performance, and package management are all awful.
|
| > Why would you ship with node_modules? ALWAYS use npm
| install. If you don't trust npm, the use something like
| CodeArtifact, but oh my, don't compress dependencies.
|
| You've certainly convinced me that Deno's single binary
| deployment is a useful feature.
| schwartzworld wrote:
| > yeah but mostly node is used as a server software.
|
| As a frontend dev, I use node tooling every day that has
| nothing to do with server code.
|
| > Python is much better as 'general purpose'
|
| Node is just fine for general purpose. I use it for shell
| scripting without any difficulty. Working with async in JS
| is a dream compared to most languages, and although I
| rarely use dependencies, when you need `em, node has a
| great ecosystem.
|
| That said, I am 100% sold on Deno. Secure by default might
| not matter for server code that is going to have a couple
| of instances of it running, but the need to enable explicit
| flags for insecure APIs means that people who don't know
| how (or care) to read the code can use your program knowing
| that it literally can't access their filesystem or
| whatever.
|
| Beyond that, Deno uses Promises for async. Node was built
| before promises and many APIs rely on callbacks vs
| promises. It also has the ability to compile to an
| executable.
|
| But the number one for me is that the APIs mirror the
| browser APIs. This makes it much easier to extend frontend
| knowledge to building my own tooling.
| vagrantJin wrote:
| > feels like TS is where its at.
|
| Yes. It seems the majority of engineering decisions are
| tighly coupled to this expression right there. Future be
| damned because a Medium.com ex-FAANG said _TS is where it 's
| at_
|
| Bless them and the hype train, woe to developers 5 years from
| now.
| rglover wrote:
| > personally I don't see why you'd want to use anything other
| than Typescript right now
|
| A desire to not have IP coupled to Microsoft and a desire to
| put the burden/discipline on the self to ensure clean API
| design versus using TypeScript as a crutch to do it for you.
| In my experience, writing JavaScript code that's conscious of
| types/inputs/etc. is far easier (and more productive) than
| maintaining a TS codebase and all the trimmings that come
| with it (i.e., dependency on build tools, frameworks, etc). A
| lot of hidden costs.
| jolux wrote:
| How is TypeScript a crutch for API design?
| rglover wrote:
| API meaning data API/structure, not a public/restful API.
| manigandham wrote:
| How are you conscious of types without any tooling? And if
| you use tooling, then what's the difference?
| rglover wrote:
| When you design your API/write functions, you just ask
| "what is the type in play here (e.g., a string, int,
| etc)?" and then consider what--if any--issues that may
| cause and write code against it.
|
| For example, JavaScript default args are really helpful
| for avoiding type errors:
|
| const nameString = (name = {}) => { return `${name.first}
| ${name.last}`; };
|
| Here, because I set a default expected type (technically
| speaking), I get back an empty string without runtime
| errors. If I get an empty string during dev in my UI, I
| know to go handle the case, or, write a test to call my
| attention to the problem (often unnecessary because the
| "bug" is a design issue).
| yuretz wrote:
| > I get back an empty string without runtime errors. If I
| get an empty string during dev in my UI, I know to go
| handle the case,
|
| Well, in your example, with default params, you get back
| an "undefined undefined", not an empty string, so even
| simple code is sometimes easy to get wrong. Proper amount
| of typing actually helps a lot to avoid it.
| rglover wrote:
| IMO, same thing. If I see that, I'm going to know what to
| fix. Still not a sell that I need to add in TypeScript. I
| get the _why_ , but it's often overkill.
| mattlondon wrote:
| ...or just use typescript and get red squiggles in your
| IDE (...or when compiling if not using and IDE) and you
| don't have to go manually check your UI or write a unit
| test to make sure you provided the right type. Your
| approach sounds totally unscalable beyond a small project
| to me - you can't go manually eye ball your entire UI on
| every change.
|
| Just let the computer handle this trivia and concentrate
| your efforts on adding value I say. Sure it takes an hour
| or two to set up the tooling, but once you are up and
| running there is no overhead (unless you consider
| defining types an overhead). Compiles take a fraction of
| a second and the browser has usually already reloaded
| itself before you've even physically moved your eyes over
| to the other monitor
| imbnwa wrote:
| Not to mention the Typescript parser can be configured to
| parse JSDoc comments for compiling an index.d.ts file for
| external users if need be
| jmondi wrote:
| basically you just described dynamic languages here. We
| know why and how to program in a dynamic language. We
| don't want that though. People that are using TypeScript
| are using it for the static typing.
| [deleted]
| rglover wrote:
| Yes? And I understand why you want to use it, I'm just
| saying that it's not always necessary (i.e., some of the
| dogma around it is unwarranted).
| fulafel wrote:
| > personally I don't see why you'd want to use anything other
| than Typescript right now. It certainly feels like TypeScript
| has "won" and is now the defacto standard for anyone doing
| any kind of work in the JS-ecosystem.
|
| There are a bunch of nice languages featuring good FP support
| that compile to JS that are have viable sized developer
| communities and longer histories than TS. For example
| ReasonML, ClojureScript, Flow and Elm. Then you have the
| bunch of languages that compile to asm.js or WebAssembly. Not
| to mention the majority of Node and FE developers who
| continue to use JS.
| llimos wrote:
| > Not to mention the majority of Node and FE developers who
| continue to use JS.
|
| I don't think this is true any more. According to
| https://2020.stateofjs.com/en-US/technologies/javascript-
| fla... 78% of JS devs actively use TypeScript
| elondaits wrote:
| I have used TS in the past and want to use it more in the
| future, so I'm probably counted in that 78%... but for
| the vast majority of projects I'm not using it. Based on
| most comments, questions, examples in lib code, etc. I'd
| say that the number of people using TS is waaaay less
| than 78%.
| nightpool wrote:
| I've never used TypeScript. I've also never heard of this
| survey before, and I certainly didn't fill it out. I
| don't think these two facts are unrelated--according to
| their data, the vast plurality (48%, almost a majority)
| of the people who filled out that survey did so because
| they were on the mailing list for it. It's by no means a
| random or representative sample of the community. People
| who are more interested in surveys & new technology and
| are more likely to sign up to answer future surveys.
|
| Meanwhile, the StackOverflow 2020 survey, which reached
| twice as many JS developers (54k vs 23k), saw that only
| half of JS developers reported using TypeScript. (not
| counting any developers that reported using TS but _not_
| JS, which would drive the percentage further down). Again
| though--people who are more likely to fill out random
| surveys are going to be more plugged in to new
| technologies and more likely to adopt them.
|
| I've never used Typescript, and I don't plan to. I don't
| care about static typing. It's nice occasionally, but I
| don't find that the structural problems I need to solve
| day to day when working on large codebases are the sorts
| best solved by static typing. When working on hobby
| projects, I don't use JS compilers at all, the set of JS
| supported by modern browsers is already very expressive
| and iterating very quickly.
| norman784 wrote:
| I'm curious on how you manage large code bases without
| some kind of static typing and other checks that
| typescript provides, like object properties, etc.
|
| Personally I find hard and scary to change things in js
| and being confident that it would work without breaking
| anything, with typescript I have that, some function
| rename, change parameter type, add/remove/rename object
| fields etc.
|
| I found a couple of times when migrating some files to
| typescript misspelled names that would be hard to catch
| and passed the code reviews, that's and easy task for the
| computer but harder for the developers, also using tools
| that makes your code reviews easy its great.
| manigandham wrote:
| It supports typescript, but you're not required to use it.
| zarzavat wrote:
| Reason, ClojureScript are separate languages with their own
| computation models and conventions. They are designed to
| have their own ecosystems rather than integrate smoothly
| with the JS ecosystem.
|
| TypeScript integrates with the JS ecosystem, often major JS
| libraries include typescript definitions in the box, or are
| even written in typescript.
|
| Flow has been obsolete for a while now (yes I said it).
| fulafel wrote:
| I only have experience with ClojureScript, there the npm
| ecosystem support is good thanks to recentish
| improvements, at least for consuming, and we routinely
| use libraries from there. Usually encapsulated by some
| ClojureScript shim to keep functional interfaces (and
| kebab case!).
| Vinnl wrote:
| ClojureScript (and the other mentioned languages) really
| are in a different category than TypeScript. You can
| think of TypeScript as a linter for JavaScript that you
| help by adding some annotations to your JS, rather than
| an entirely different language. Deno merely strips those
| annotations for you before executing the remaining
| JavaScript.
| fulafel wrote:
| The TS language semantics would seem to preclude a
| stripping based implementation, no? Eg generics seem to
| be a whole new area of semantics [1].
|
| I agree that TS is closer to JS than ClojureScript is,
| but it seems to me to be its own compiled language with
| code generation targeting JS.
|
| [1] https://www.typescriptlang.org/docs/handbook/2/generi
| cs.html
| [deleted]
| greghuels wrote:
| It doesn't have to be server software. I created a cli tool
| with Deno so that it could run as a standalone binary. It runs
| a lot faster than if it were built with node and any user
| without node installed could still run it.
| skywal_l wrote:
| It's standalone in a sense you end up with a single
| executable, but deno is embedded with your code. A `hello
| world` example is more than 50MB stripped.
|
| The command to do that is called `compile` but its a bit of
| misnomer, it does not compile a free standing executable with
| your code but basically creates an executable wrapper around
| `./deno yourcode.ts`.
| kbenson wrote:
| That's not really different than how most scripting
| languages provide compile or application delivery features
| (whether built in or through a module). You're right that
| it isn't actually "compiling" as most people would expect
| that to mean in a programming context, but given that
| packaging into a single executable is generally what
| they're actually looking for, that's usually an acceptable
| distinction.
|
| What I wonder is how big hello world is for a statically
| linked packaged dene application, and if it's easy to
| produce those (assuming 50MB is for linked binary). That's
| probably more useful in a lot of cases if it's not wildly
| larger.
| skywal_l wrote:
| /tmp$ mkdir test /tmp$ cd test /tmp/test$
| curl -sOL https://github.com/denoland/deno/releases/downl
| oad/v1.13.1/deno-x86_64-unknown-linux-gnu.zip
| /tmp/test$ unzip deno-x86_64-unknown-linux-gnu.zip
| Archive: deno-x86_64-unknown-linux-gnu.zip
| inflating: deno /tmp/test$ cat > test.ts
| console.log('Hello, World!'); /tmp/test$ ./deno
| compile test.ts Check file:///tmp/test/test.ts
| Bundle file:///tmp/test/test.ts Compile
| file:///tmp/test/test.ts Emit test
| /tmp/test$ ls -lh total 198M -rwxr-xr-x 1
| user user 83M aout 16 23:52 deno -rw-rw-r-- 1
| user user 32M aout 23 19:12 deno-x86_64-unknown-linux-
| gnu.zip -rwxrwxrwx 1 user user 83M aout 23 19:13
| test -rw-rw-r-- 1 user user 30 aout 23 19:13
| test.ts /tmp/test$ ./test Hello, World!
| kbenson wrote:
| So, it's still linked against glibc and libgcc from what
| I can see almost all the following are from glibc):
| $ ldd deno linux-vdso.so.1
| (0x00007fff3fbeb000) libdl.so.2 =>
| /lib64/libdl.so.2 (0x00007efd30939000)
| libgcc_s.so.1 => /lib64/libgcc_s.so.1
| (0x00007efd30721000) librt.so.1 =>
| /lib64/librt.so.1 (0x00007efd30519000)
| libpthread.so.0 => /lib64/libpthread.so.0
| (0x00007efd302f9000) libm.so.6 =>
| /lib64/libm.so.6 (0x00007efd2ff77000)
| libc.so.6 => /lib64/libc.so.6 (0x00007efd2fbb2000)
| /lib64/ld-linux-x86-64.so.2 (0x00007efd34593000)
|
| But honestly, that's pretty minimal. Just over 80 MB for
| the base to not have much in the way of dependencies
| seems pretty good. And given that library extensions are
| supposed to mostly be done in Rust (if that hasn't
| changed), those are statically linked by default as well,
| so that will hopefully cut down on accidentally
| introducing dependencies from the system it's built on
| also.
| jamil7 wrote:
| I haven't worked with JS for a while so I'm not really up to
| speed on modern Deno and Node but can't you also package a
| node cli tool as a binary? Also how can Deno run a lot
| faster? I would imagine it at least suffering from a startup
| time hit due to the TS compiler. Maybe someone can explain?
| [deleted]
| wperron wrote:
| Transpiling TS to JS on startup does incur a cold start
| penalty, you can minimize it by using the `--no-check`
| option to transpile with SWC instead of TSC but it's still
| there. On subsequent runs though, it'll start up instantly
| because the JS is cached locally after transpiling (you can
| even trigger this step yourself with `deno cache`)
|
| Beyond that, you still have the v8 engine running the JS,
| so yeah in most cases performance will be pretty much what
| you can expect from Node _except_ with regards to anything
| that reaches out of the sandbox (like filesystem or network
| access). These APIs are handled completely differently
| outside of v8, with Deno relying on a lot of Rust packages,
| and Promise-based APIs all the way down. For the builtin
| HTTP server for example you can expect higher throughput
| from Deno. Tail latencies also tend to be better with Deno.
|
| You're not immediately going to get "blazing fast, native
| speeds" but you can get some nice optimizations.
| jamil7 wrote:
| > These APIs are handled completely differently outside
| of v8, with Deno relying on a lot of Rust packages
|
| Very cool, thanks for the detailed answer.
| guptaneil wrote:
| I get the feeling it's just meant to be a nicer development
| experience by including more out of the box. I tried it briefly
| and was impressed by how easy it was, it felt like I was in
| another language's ecosystem rather than the complex duct tape
| approach JS has become infamous for. I think as it matures, it
| will help increase productivity and decrease complexity for new
| projects.
|
| There's not a reason you'd migrate an existing node project to
| deno, but if you're starting something new, why not use the
| nicer environment?
|
| FWIW, deno is also built by Ryan Dahl, the original creator of
| node, so I think of deno as more like a rewrite of node rather
| than a competitor.
| SkyMarshal wrote:
| > Secure by default. No file, network, or environment access,
| unless explicitly enabled.
|
| > Supports TypeScript out of the box.
|
| > Ships only a single executable file.
|
| > Has built-in utilities like a dependency inspector (deno
| info) and a code formatter (deno fmt).
|
| Taken all together instead of individually, Deno is clearly
| designed to produce more secure and maintainable codebases than
| NodeJS over longer periods of time and team turnover. All of
| these "by default" additions better ensure a common, high-
| standard baseline for any arbitrary Deno codebase over any
| period of time.
|
| Individual developers often tend to focus on _" how does this
| help me/improve my workflow right now?"_, instead of thinking
| like a CTO and focusing on _" how does this technology make our
| IT systems more robust to long-term maintenance, developer
| turnover, and security threats?"_.
|
| Secure by default means you shift security from the developer
| team into the framework. Say your original security-focused
| developer team attritions over time, and due to a software
| engineer shortage you're forced to hire less experienced or
| less security-oriented folks.
|
| Even if you end up with a new team more oriented to "move-fast-
| and-break-things" than secure-by-design/correct-by-
| construction, your framework still provides a minimum security
| baseline they can't intentionally or accidentally violate.
|
| That works in reverse too - say you're a new startup that can't
| afford to hire the best of the best yet. If you choose a
| secure-by-default framework like Deno, you're getting security
| and correctness from the framework for free, rather than having
| to pay a premium for developer talent capable of that.
|
| Typescript instead of Babel means that all Deno codebases
| everywhere will use the same language, one that provides better
| correctness and security guarantees than most Babel options.
|
| Built-in dependency-inspector simply makes that function more
| available and apparent to developers. Maybe useful for new
| entry-level folks, not so much for more experienced ones.
|
| And I thought the value of a built-in code-formatter was
| demonstrated by Go with gofmt - all Go codebases everywhere are
| formatted the same way, making it easier for Go devs to get up
| to speed with a new codebase.
|
| One of things that used to really annoy me about both Rails and
| Nodejs was how they were not secure-by-default and left certain
| security details/holes to be implemented/fixed on an ad-hoc
| basis on every new project by individial dev teams.
|
| But the whole point of a framework is to provide common
| solutions to such common problems that all projects incur, so
| the dev team can focus on the custom and creative parts of the
| app, the value-added parts, the competitive edge. It's great to
| see Deno and others doing this.
| zerkten wrote:
| >> Secure by default. No file, network, or environment access,
| unless explicitly enabled.
|
| > Great, but we're talking about server software so the first
| thing any project is going > to do is enable all of that. And
| it's not like you can trust this on the server, you'd > still
| need to sandbox to process if you truly want isolation.
|
| These are not intended to be quick fixes for the masses nor
| replace sandboxes. They contribute to strength in depth and
| frustrate attackers looking to make pivots. I'd recommend
| taking some time to consider the threat models that these
| measures are align to.
|
| There is evidence that making changes like this contributes to
| the overall security of an ecosystem. You have a smaller
| percentage of people who will go ahead and do the wrong thing
| initially (if you support them with proper guidance), but it's
| only over time that you have projects based on the platform.
| More importantly, a change is being made that can sustain a
| culture of security over the long-term.
|
| When you have to maintain systems that aren't built on
| platforms with support for measures like these it becomes
| difficult to retrofit any meaningful level of security, or
| there is too much obfuscation in the system to justify
| improving it without rewriting it. Here you can see that the
| original implementers have enabled privileges unnecessarily and
| there is a clear angle of attack. Along the way you can also
| revert all other kinds of bad practices and hacks that previous
| developers implemented (random calls to external services you
| don't expect, loading configs from disk that should be loaded
| another way, etc.) These are not uncommon experiences when
| technology gets into the hands of the mainstream.
| boardwaalk wrote:
| I think it probably makes more sense if you're in the Node
| universe (and Dahl created the thing). If your window for the
| state of the art is... the range of what Node and its immediate
| surroundings can do, then Deno probably seems like a marked
| improvement. While people (well, me) look from the outside and
| think: This is how far you moved on a clean slate? Then you
| consider waiting for the ecosystem to mature (considering the
| mess the JavaScript has been and has only recently been slowing
| down) and go, "Ehh."
|
| I don't mean to denigrate; Node and Deno (already) are far
| bigger success stories than I'll ever have.
| Jenk wrote:
| Perhaps an alternative way to sell this might be that Deno is
| authored by the original author of node. He introduced Deno at
| a talk "What I regret about Node.js" and presented Deno as the
| product of his lessons.
| lucideer wrote:
| > _the first thing any project is going to do is enable all of
| that_
|
| I'm sure many (most) will but the point is that for those who
| do care about security, Deno offers them the option of running
| their server app with such features selectively enabled
| according to need.
|
| > _it 's coupled to Microsoft's take on Javascript_
|
| Deno supports Javascript too so there's no tight coupling here.
| It's also a second well-supported widely-used independent
| implementation of microsoft's syntax, which is no hard
| guarantee of anything but bodes well if vendor lock-in is a
| concern.
|
| > _What about Flow_
|
| Flow is significantly less popular so this decision seems
| understandable. I cannot see Deno being as popular as it is now
| if they had opted for Flow.
|
| Also, while Flow has some advantages, it's a lot less
| expressive and most reviews of both prefer TS for quite well-
| argued objective reasons.
|
| > _What 's wrong with using Babel with sourcemaps?_
|
| Given the complaint about coupling just two sentences previous
| to this one, this makes your comment seem quite disingenuous.
| Are you serious???
|
| > _Will that not just bring about another npm situation in a
| few years?_
|
| It might but your goalposts seem to be moving. Are you saying
| this makes it worse than npm somehow?
| sieve wrote:
| Deno has replaced shell scripts and Java in a lot of places for
| me.
|
| My reasons:
|
| - Types: I simply cannot program without them. Typescript is
| great.
|
| - Single executable: Write programs that run the same on
| Linux/Windows without forcing the user to download the entire
| universe like other runtime environments.
|
| - Built-in bundler: Write front-end code in Typescript and use
| a single command to bundle all dependencies.
|
| Native JSON support in cli applications is not something you
| can appreciate if you haven't dealt with the pain surrounding
| it on the Java side.
| toastal wrote:
| > Types
|
| There are so many better options if you want a good type
| system (Elm, PureScript, Rescript, GHCjs, Scala.js, and many
| more). TypeScript is unsound, and necessarily by it's design,
| it has to take on weird issues to maintain compatibility with
| JavaScript (null/undefined, can run effect anywhere, a lot of
| codebases are filled with any types). Heck, TypeScript
| doesn't even come with ADTs and proper pattern matching.
| sieve wrote:
| > There are so many better options if you want a good type
| system
|
| I am looking for basic type checking to prevent me from
| doing stupid things and catching bugs at "compiletime"
| instead of runtime.
|
| Typescript interfaces with their structural typing do the
| job just fine.
|
| I think people are underestimating the power of ecosystem.
| I use JS daily. Deno allows me to use it on the server as
| well without doing crazy things.
|
| You have been able to do something similar in Java for a
| very long time with Mozilla Rhino (and now GraalJs) but
| without the same level of comfort and convenience.
| shadofx wrote:
| So TypeScript is designed for the internet, and languages
| with good type systems are not.
| nightpool wrote:
| This has nothing to do with the GP's comment, which was
| about local scripting (replacing "shell scripts and
| Java")
| irq-1 wrote:
| Similarly: https://www.assemblyscript.org/
|
| > A TypeScript-like language for WebAssembly.
|
| > AssemblyScript targets WebAssembly's feature set
| specifically, giving developers low-level control over
| their code.
|
| > Being a variant of TypeScript makes it easy to compile to
| WebAssembly without learning a new language.
|
| > Integrates with the existing Web ecosystem - no heavy
| toolchains to set up. Simply npm install it!
| iaml wrote:
| > TypeScript doesn't even come with ADTs
|
| You still can use them [0].
|
| > proper pattern matching
|
| [1] is pretty good.
|
| [0] https://itnext.io/practical-introduction-to-algebraic-
| dataty...
|
| [1] https://github.com/gvergnaud/ts-pattern
| toastal wrote:
| They need to be first-class. Not means the ergonomics
| aren't great and it won't be the developer default
| because it requires a library. It's not good enough
| considering how fundamental these two are in many
| languages (it's even in Java now)
| IshKebab wrote:
| Typescript definitely has some flaws but it also has some
| _really_ powerful features that aren 't found in any other
| type systems, like the ones you listed.
|
| And in any case I don't think anyone is really saying "Use
| Deno because it has static type annotations". It's "Use
| Deno because it has static type annotations _and_ is fast
| _and_ easy to deploy _and_ has a huge ecosystem _and_ doesn
| 't require a project setup file to use third party
| libraries _and_ ... "
| lpcvoid wrote:
| This sounds like something you can get with other languages
| which compile to native x86_64 or arm or whatever - specially
| the single executable concept is ages old and predates the
| entire internet. Why use js, which is slow?
| innocenat wrote:
| This just don't make sense. People do scripting in sh,
| bash, python, etc all the time. Why not js?
| [deleted]
| sieve wrote:
| There is always something that doesn't fit either the use
| case or the aesthetic sense.
|
| > Why use js,
|
| For someone working with JS on the front end, the ability
| to not only use the same language, but also the same
| libraries/modules/functions is very valuable.
|
| > which is slow?
|
| Not that slow, once a JS engine takes over.
| clipradiowallet wrote:
| > Deno has replaced shell scripts and Java in a lot of places
| for me.
|
| > - Single executable: Write programs that run the same on
| Linux/Windows without forcing the user to download the entire
| universe like other runtime environments.
|
| OK, I understand your comment wrt Java, but with
| shellscripts? What universe are you downloading?
|
| For that matter - your 3 listed reasons make a very argument
| for "a normal compiled language". Consider an older/popular
| one...C++. It's _very_ typed, compiled to a single
| executable, and "bundling" is "linking"(you can do it any
| way you like, including staticly linking all your deps).
|
| If I understand your comment, are you saying that previously
| you wrote software 2 ways: shellscripts and Java. You
| replaced them with...any entirely new interpreted
| language(JS)?
|
| I'm not denigrating JS/deno/node/whatever, I'm pointing out
| your 3 reasons are built in features to any compiled language
| in the last 40 years.
| sieve wrote:
| > wrt Java
|
| Not just Java. Python, Ruby, Node etc suffer from the same
| problem. And I am talking as an end-user here.
|
| I once downloaded something based on one runtime which then
| proceeded to download another runtime which it needed to
| run one little script. There are programs out there that
| have node/npm as a dependency.[1] People are crazy.
|
| > your 3 listed reasons make a very argument for "a normal
| compiled language"
|
| One of my hobbies involves writing compilers and
| parsers.[2][3] I have tried a lot of "normal" languages and
| have stuck to Java (in spite of its excessive verbosity)
| for work reasons. Some languages I cannot tolerate for
| aesthetic reasons.
|
| For now, there is no alternative to TypeScript.
|
| > you wrote software 2 ways: shellscripts and Java. You
| replaced them with...any entirely new interpreted
| language(JS)
|
| I used to run a mixed-environment (Windows + Linux) and a
| lot of glue code that drove other software had to be
| written twice (sh/bash + cmd/bat) before WSL came along.
| That problem has disappeared.
|
| I also used to write a lot of tools (servers and cli apps)
| in Java. Some of those I have moved over TypeScript-on-
| Deno.
|
| > I'm not denigrating JS/deno/node/whatever
|
| I used to look down on JS a decade or so back. My
| experience with Rhino and now Deno changed that. There is a
| lot of stuff I do now which I simply would not do if I have
| to fire up an entire Java project to do.
|
| [1] https://archlinux.org/packages/community/x86_64/nodejs/
|
| [2] https://github.com/s-i-e-v-e/ut
|
| [3] https://github.com/s-i-e-v-e/sxml
| whimsicalism wrote:
| > OK, I understand your comment wrt Java, but with
| shellscripts? What universe are you downloading?
|
| Are shell scripts cross-compatible if you haven't installed
| WSL?
| clipradiowallet wrote:
| WSL? Are you asking...is software for one operating
| system able to run on another operating system without
| installing a compatibility layer(if it exists)? If so,
| the answer is "no, of course not".
| whimsicalism wrote:
| > - Single executable: Write programs that run the same
| on Linux/Windows without forcing the user to download the
| entire universe like other runtime environments.
|
| So how is this statement wrong for shell scripts? You
| can't write a shell script that "runs the same on
| Linux/Windows without forcing the user to download a
| runtime" because you can't write a shell script that runs
| on Linux/Windows.
| specialist wrote:
| Using Java for shell scripts (using a shebang) is on my todo
| list. IIRC, there's a GraalVM or Truffle or something
| interpreter that'd work.
| tinco wrote:
| I've now done two small web services in Deno, both are in
| production serving very small amounts of requests (i.e. tens
| per week scale).
|
| The thing that attracted me to Deno is that it promises to be a
| more integrated Typescript experience on the backend while
| still leveraging a lot of value from the Node ecosystem. I've
| already forced my coworkers to use Typescript, so having better
| integrated tooling is just a big plus.
|
| That's when compared to Node.JS. When compared to other
| frameworks, I'll just say it's nice that all developers on my
| teams know Typescript, so they can all contribute when
| necessary. In absolute terms, I think Node.JS is the dumbest
| thing to ever happen in IT history, and I hope something like
| that never happens again. That Deno puts a small bandaid over
| that open wound in my heart is nice.
| WanderPanda wrote:
| > I think Node.JS is the dumbest thing to ever happen in IT
| history
|
| Did you already forget about PHP? :p
| whimsicalism wrote:
| Honestly what world are you living in where Flow is even
| remotely relevant in 2021?
| fabiospampinato wrote:
| I think you should look at it the other way around, assuming
| you are already using a mature version of Deno it most probably
| wouldn't make sense to switch to something like NodeJS:
|
| - Why using CommonJS over standard ESM modules?
|
| - Why using a package manager like NPM? Browsers don't have
| package managers, my code can run on the client without
| something like NPM, why should it be any different on the
| server?
|
| - Why having callback-based APIs in a world of promises and
| async/await?
|
| - Why having node-only APIs when today standardized browser
| equivalents exists?
|
| - For better or for worse as far as I'm concerned TypeScript is
| the de-facto successor of JavaScript, especially if you need to
| work on big codebases. Flow is irrelevant outside of Facebook.
| If something better pops up Deno could adopt that too or you
| could just compile that to JS yourself and Deno would work with
| it already. As things stand currently other compile-to-JS
| languages are way less important than TS.
|
| - Servers aren't the only kind of application that can be
| written on top of Deno, why on earth would I want eslint to be
| able to have access to the network or spawn child processes? Or
| even have global read/write access to my whole disk? Deno's
| model is a much better default than Node's from a security
| perspective. You can't even install something from NPM with
| reasonable certainty that that won't nuke your computer.
|
| Essentially switching from Node to Deno may not seem like an
| obvious improvement, but it is in many ways, switching from
| Deno to Node has only drawbacks basically, if you don't
| consider Node's advantage in ecosystem size I can't imagine why
| anybody would switch from Deno to Node in the future.
| spankalee wrote:
| Browsers generally are running code that came from a package
| manager these days. But devs expect to run a file server for
| their browser code. Do Deno devs need to expect to run a
| separate file server for their Deno code?
| flowerlad wrote:
| See comparison here: https://deno.land/manual#comparison-to-
| nodejs
|
| The big one for me is, ability to use async/await instead of
| supplying callback methods.
| daffl wrote:
| One thing that I think is often overlooked when it comes to
| Deno is how the combination of secure defaults, web API
| compatibility and the dependency loading system can essentially
| eliminate the need for actual deployment builds and containers
| making it a great candidate for a truly open source and non-
| proprietary serverless platform.
|
| Especially in combination with content addressed file systems
| like IPFS (which gives you additional features like built-in
| checksums, immutability, de-duplication and storage resilience)
| you can have a Deno instance running and as the deployment step
| simply send it a file hash or URL to execute (of course with
| the appropriate security precautions like a signature or
| encryption on top). I built a prototype to see how it could
| work and a full Deno app deployment to my own VPS took less
| than 2 seconds. No git pushes, no container build pipelines, no
| proprietary cloud services.
| eyelidlessness wrote:
| I had a very similar reaction at first (the exception being
| first class TypeScript support). I've since come around to
| being very interested in Deno and curious to use/support it
| more. Here's what's brought me there:
|
| - As I've adopted ESM, I've found Node's ESM support difficult
| to deal with. Deno being ESM by default is a huge improvement,
| and makes portability to other environments much easier.
|
| - Similarly, Deno's default deferral to existing JS/browser
| standards helps portability immensely.
|
| - TypeScript isn't just supported, it's _very fast_! Much
| faster than solutions like ts-node. Not limited /incomplete
| like current esbuild-based ESM loaders (though I'm actively
| working on solving that for Node).
|
| - Async APIs are all Promise-based. No legacy
| sync/callback/promisify.
|
| - Import maps allow complete flexibility with dependencies: you
| can use NPM or another package manager if you really want. You
| can customize package management however you prefer. You can
| completely sidestep NPM audit hell.
|
| - The standard library is good actually! And it's ESM so it's
| immutable by default.
|
| - Quite a lot of stuff that requires build tooling (eg
| isomorphic web) is not needed server-side at all. But I was
| curious about your questions about Babel/Flow and it looks like
| there are APIs that allow you to customize compilation if you
| need to.
| TechBro8615 wrote:
| The module stuff is what has me looking at it. We've got a
| bunch of Node services that are relatively small and single
| purpose. Using tsnode, adding a build step, tinkering with
| ESM/CommonJS to work within the monorepo TS project reference
| graph... it feels like a huge PITA with mostly unnecessary
| overhead.
|
| Basically... we're a "TypeScript native" project from day
| zero... so why do we need to be weighed down with all this
| cruft from historical JS ecosystem decisions? I'm planning to
| try swapping one of these services to Deno to see how much
| easier it is.
| dane-pgp wrote:
| > Will that not just bring about another npm situation in a few
| years?
|
| Speaking of which, I was wondering if it has an equivalent for
| "npm audit", and I've found a project which provides some of
| that capability:
|
| https://deno.land/x/audit@1.0.0
|
| Rather than rely on a single source of truth for audits, it
| seems to rely on developers specifying a location which is
| trusted to make audit reports about their modules.
|
| That's a slightly different trust model, but it's better than
| nothing and at least prevents the controversial false positives
| problem of "npm audit":
|
| https://news.ycombinator.com/item?id=27761334
| jmuguy wrote:
| I don't know why but I had to read this blog post about six times
| before I realized that its about Deno being added to the
| compatibility chart (far right in example) shown on MDN.
| avinassh wrote:
| I noticed something odd.
|
| The image on the post is this - https://deno.com/deno-on-
| mdn/table.png
|
| This is the image used in og meta tags - https://deno.com/deno-
| on-mdn/header.png but this one includes a visual cue and it
| becomes immediately clear that Deno is added to the chart
| jmuguy wrote:
| I need something for Monday mornings that shows me the
| content of the OG tags on articles so my lizard brain has an
| easier time.
| binarynate wrote:
| I'm a long-time Node user but decided to use Deno for a personal
| project and found that it's is a pleasure to work with. Some
| highlights: - TypeScript works out-of-the-box
| without configuration - includes modern browser APIs like
| fetch() without needing to import additional dependencies -
| The Deno-specific APIs (like Deno.readTextFile()[0]) are Promise-
| based and have intuitive interfaces - The Deno standard
| library[1] reduces the need for 3rd party dependencies, since it
| covers a lot of cases where one would be needed
|
| I haven't yet used Deno in a commercial product, but I believe I
| will in the future because Deno seems ready for primetime.
| [0]https://doc.deno.land/builtin/stable#Deno.readTextFile
| [1]https://deno.land/manual/standard_library
| timdaub wrote:
| > - The Deno-specific APIs (like Deno.readTextFile()[0]) are
| Promise-based and have intuitive interfaces
|
| require("fs").readFileSync("hello.txt").toString() // toString
| because it's a buffer by default
| yberreby wrote:
| A Promise-based API doesn't block the event loop, but a
| synchronous one like fs.readFileSync does. Their usage might
| look similar but their semantics differ vastly.
| timdaub wrote:
| Fair enough. OP was talking about intuitive non-blocking
| APIs and I just considered "intuitive".
| steve_adams_86 wrote:
| Do you know if Deno chose to use strings instead of buffers to
| be more consistent with the browser? I know buffers can be
| faster, but overall I like that readTextFile is returning a
| string here. I suspect most use-cases ultimately want to handle
| the output as a string.
| Keithamus wrote:
| Deno uses uint8array (pretty much Nodes Buffers (Node Buffers
| subclass UInt8Array these days)) for almost all methods. For
| example Deno comes with `Deno.readFile` which returns a
| Promise<UInt8Array>, but they include the special case
| Deno.readTextFile because of how common it is to convert the
| contents to a string.
| [deleted]
| [deleted]
| paulddraper wrote:
| The fundamental advantage of TypeScript (vs other languages
| like Scala.js) was that it could easily leverage the entire
| Node.js (EDIT: JavaScript) ecosystem and vice versa in a very
| smooth way.
|
| Deno goes in the wrong direction. It's a TS fanboy invention in
| search of a problem.
|
| And I say that as a TypeScript fanboy.
| JoeyJoJoJr wrote:
| There is still a lot of friction using Typescript for just
| about any Nodejs project. Things have definitely improved,
| but it is still a far cry compared to first class language
| support.
|
| I'm curious what you think is the right direction Deno should
| have taken.
| tristan957 wrote:
| TS by itself is a great language even without the JS support.
| The Node ecosystem has a lot of shortcomings which Deno aims
| to solve. I disagree with your assertion that Deno is a
| fanboy invention in search of a problem. If the creator of
| Node, started Deno, then obviously there is some merit to his
| thought process.
| paulddraper wrote:
| > TS by itself is a great language even without the JS
| support.
|
| Hardly. TS would have 1% of the adoption without JS.
|
| > creator of Node, started Deno
|
| Kudos for Dahl for his practical, very successful project
| Node.js.
| [deleted]
| dfabulich wrote:
| > The Deno-specific APIs (like Deno.readTextFile()[0]) are
| Promise-based and have intuitive interfaces
|
| FYI, Node has Promise-based APIs for all filesystem APIs. Node
| also supports ES modules that use top-level await.
|
| If you create a file `test.mjs` and put this in it, it'll work:
| import {readFile} from 'fs/promises'; console.log(await
| readFile('foo.txt', 'utf8'));
|
| https://nodejs.org/api/fs.html#fs_filehandle_readfile_option...
| binarynate wrote:
| Thanks--I didn't know about fs/promises
___________________________________________________________________
(page generated 2021-08-23 23:02 UTC)