[HN Gopher] Deno 1.27
___________________________________________________________________
Deno 1.27
Author : Mikkel-T
Score : 156 points
Date : 2022-10-27 18:00 UTC (5 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| andrewmcwatters wrote:
| I'm curious how strongly Deno matters to the developers in this
| space. Honestly, I just don't care. I really, really don't care.
| When Node.js succeeded PHP in industrial practice, it was enough
| then to get me to move since everyone had already jumped onboard
| quickly.
|
| Now, it's gotta take a LOT for me to want to move. I'm already
| too productive with Linux, Nginx, MySQL, and Node.js w/ Express,
| and React on the front-end. I have little to no reason to try
| anything out.
|
| On a similar note, while people are switching from Webpack to
| Turbopack, I'm kicking back writing actual product features with
| a near buildless process. Because I simply don't care. I use the
| "Run JSX Preprocessor" straight out of the docs as I work and
| commit the output.
|
| Screwing around with switching back and forth and changing build
| configurations every few years reminds me of when back in the day
| people would supercustomize their desktop environments instead of
| just accepting them as they are.
|
| Is anyone really working up a sweat over security theatre like
| passing in args to flip permissions flags?
|
| Could you imagine how ridiculous that would sound in literally
| any other programming environment? That you can't trust your own
| software and its dependencies--that YOU built?
| stjo wrote:
| It seems to be down for me and for some reason the domain is not
| indexed by the web archive.
| alberth wrote:
| Dumb question: which appears most promising? Deno, Just-JS or
| Bun?
|
| (Genuine question. Not trolling)
| bastawhiz wrote:
| I think they all serve different use cases. I'm not sure I
| could say one is more promising than another, because they're
| _all_ promising, and I don't see them as being in direct
| competition with each other.
| agumonkey wrote:
| the three, after they merge into one :)
| Petersipoi wrote:
| While I suspect you're joking.. this doesn't seem likely
| given that all 3 are written in different languages
| brundolf wrote:
| From the little I've read about just-js, I'm not sure it's even
| trying to be a competitor with the others for their main use-
| cases
|
| I think Deno has the strongest overall vision, and it's a
| vision I really want to see become the new default
|
| Bun is compelling with its blistering pace and its ruthless
| dedication to performance, compatibility, and Just Works user
| experience. However, it's still very new and missing a lot of
| key features, and subjectively it just feels too "chaotic" for
| my tastes. They're designing it as they go, as fast as they
| can, but it feels like a wild ride. I'm not sure the creator
| even knows exactly where it'll end up, and in general it seems
| to prioritize "does everything you'd like it to right now" over
| "lay a new, better foundation for how the JS ecosystem works,
| unburdened by the historical baggage of Node"
|
| Two very different mindsets; it'll be really interesting to see
| which one wins. Personally I'm rooting for Deno, but I think
| each of them is pushing the other one to be better.
| sramam wrote:
| > unburdened by the historical baggage of Node
|
| Is this even possible anymore?
|
| Deno made a valiant attempt, but with every release, the best
| received update seems to be the node/npm compatibility.
| brundolf wrote:
| I see NPM compatibility as a temporary stopgap. They tried
| to make a hard break all at once, and then Bun made it
| clear that no, actually people still really want access to
| that existing ecosystem for now.
|
| But _new_ code written for Deno starts out on that better
| foundation without CommonJS, several different module-
| resolution algorithms, manual transpilation, competing
| linting and testing standards, etc etc. They just need to
| bridge the gap in the meantime, until Deno 's own ecosystem
| gets more filled out. That's the dream anyway.
| lucideer wrote:
| What's interesting though is that the compatibility effort
| seems to be on all sides. Deno has acted somewhat like a
| forcing function - I think a lot of Node folk want to move
| away from CommonJS in general (even staying within the NPM
| ecosystem) & having multiple targets for modules you write
| has given that effort some good pushes.
|
| A simple example of this in my mind is the node: prefix
| added to CommonJS functions in NodeJS. This has some
| perf/caching advantages, which may have been the main
| driver, but also introducing a protocol prefix to module
| strings happens to improve extensibility/flexibility/compat
| across the ecosystem - there are transpilers that change
| e.g. import to require() or vice-versa, so extra context in
| module strings is helpful there. Deno's npm: prefix has a
| similar effect (it would be cool if this made it into Node
| someday - having control over module locator strategy at
| import granularity seems interesting; it would certainly
| make a lot of bundler hacks currently in use for things
| like CSS/etc. simpler)
| [deleted]
| ilrwbwrkhv wrote:
| Bun is the most excited I have ever been in the JavaScript
| ecosystem.
| [deleted]
| qwertox wrote:
| Your question taught me that Just-JS and Bun exist. Thanks for
| asking.
| hardwaregeek wrote:
| imo just-js and bun are too early to tell. They're in that
| stage where they're cool and people talk about them, but they
| haven't gotten to that stage where there's adoption and
| therefore real criticism. Basically bun/just-js are being
| judged on their potential, while Deno is starting to be judged
| on its reality.
| mattwad wrote:
| My guess is none of them will ever replace Node.js, but they
| will all help shift the momentum of Node.js to be faster,
| better support for Typescript, etc. Similar to how folks
| created io.js at one point and that eventually got merged back
| into Node.js.
|
| Deno seems like to offer a better dev experience, and because
| it's created by Dahl it's the only one I take seriously as an
| alternative.
| stephen wrote:
| My on-the-sidelines take is:
|
| Bun seems most promising to me, because it's chasing amazing
| performance _and_ widespread adoption.
|
| Like Just-JS has amazing performance [1], but the author is
| "just" (a very amazing/talented) benchmark hacker and not
| necessarily trying/wanting to put in the effort to have "a node
| replacement" and/or extend his Techempower-specific
| optimizations into APIs/libraries that would affect the
| performance day-to-day business apps (which I don't blame him
| for).
|
| Deno is kinda :shrug: b/c its original "great security" pitch
| doesn't really matter to anyone who runs in containers.
|
| [1]: https://github.com/just-js/just.billywhizz.io/issues/3
| kitsonk wrote:
| The author of Just-JS is working on Deno as well.
| jmarneweck wrote:
| https://archive.vn/wxmIG
| Pr0ject217 wrote:
| Nice! Time to upgrade.
| flockonus wrote:
| Excited for the improvements, some big wins there! But surprised
| to see so many removals in the Changes section to what seems to
| be a minor version of a 1.x release. Nothing that hurts me
| personally, altho not Semantic Versioning and cautions shaky
| ground to build on?
| crowlKats wrote:
| There are no removals in the CLI, and std is considered
| unstable, and due to that has different versioning that is
| still in 0.x
| rickstanley wrote:
| The video on the page doesn't have controls and I have Firefox
| block autoplay; fortunately, I can just right click and select
| play from context menu.
|
| Just giving notice.
| halfmatthalfcat wrote:
| As a Jetbrains user, somewhat annoying to see everything in VS
| Code.
| JLCarveth wrote:
| An editor is an editor, why on earth would it bother you that
| someone uses a different editor than you?
| randomguy0 wrote:
| Is this Jeopardy? Your question is essentially answered by
| his original comment.
| JLCarveth wrote:
| Pardon? I am asking OP why he's _annoyed_ that the post
| mentions VSCode. It 's not normal to be annoyed at the mere
| mention of a text editor.
|
| You should work on 1. your reading comprehension, and 2.
| making relevant comments to the discussion at hand.
| randomguy0 wrote:
| Yeah, sure. Maybe heed your own advice.
| antihipocrat wrote:
| They're not annoyed that the post mentions VSCode.
| They're annoyed that, from their experience, only VSCode
| is being supported.
| kitsonk wrote:
| VSCode is the only integration that the Deno core team
| maintains and develops. A rough poll indicates that about
| 80% of Deno users use vscode.
|
| JetBrains/WebStorm now utilises the Deno language server
| directly (the same one that the VSCode integration uses)
| but they control how features are expressed in their
| client and when they deliver them, something the core
| team can't directly control.
|
| So for various reasons, VSCode ends up being the focus.
| lucacasonato wrote:
| Our editor integration is completely editor agnostic. Deno
| implements the Language Server Protocol [1], which essentially
| all editors support. Because of this the new inlay hints
| feature, is supported on all editors that support inlay hints
| and use our LSP integration. The Jetbrains integration for Deno
| uses our LSP, but I don't know if they support inlay hints yet.
|
| You can find docs on using Deno LSP with other editors here:
| https://deno.land/manual/getting_started/setup_your_environm...
|
| [1]: https://microsoft.github.io/language-server-protocol/
| JLCarveth wrote:
| I've been using Deno on neovim and it's been a breeze
| nerdponx wrote:
| Maybe this is a weird question, but how does Deno compare to Node
| when it comes to the various "languages that compile to JS"? For
| example Purescript, Fable, Elm, etc. does everything mostly just
| work, or should one stick to Node for those?
| [deleted]
| Yahivin wrote:
| No real support, just a placeholder on their roadmap:
| https://github.com/denoland/deno/issues/1739
| Tomuus wrote:
| Things mostly just work. Remember Node.js is mostly APIs on top
| of JS the language. If those tools compile to JS in the
| browser, they can compile to Deno. Deno is a more stabdards-
| based runtime than Node, it's closer to how the browser works.
| rcoder wrote:
| For languages that can emit clean ESM JavaScript source and
| don't depend on special tooling or runtime support you can
| totally drop the generated JS files into a Deno project and
| import them.
|
| ...but you're even _more_ on your own w.r.t. bugs,
| compatibility issues, and the basic assumption that everything
| will be running inside Node, and therefore trivially able to
| access e.g. `npx` or various scripting+automation tools.
|
| Your best bet today is to run Node in your development
| environment, then use the generated code in a Deno service/CLI
| wrapper/etc. It's clunky, but you can get there.
| jeffhwang wrote:
| Appreciate the improvements to npm compatibility. Does anyone
| have a sense of how close Deno is their estimate that 80-90% of
| npm packages would be working? I think they said this was what
| they were hoping for back in August.
| e63f67dd-065b wrote:
| > RBTree has been removed from the collections module in favor of
| RedBlackTree.
|
| > direction has been removed from the collections module in favor
| of Direction.
|
| > CSVStream has been removed from the encoding module in favor of
| CsvStream
|
| Hmm I smell an interesting story here. If it's renaming for the
| sake of renaming then that's kinda dumb and breaks backwards
| compat for no reason, but presumably there's a better reason
| somewhere?
| KyleJune wrote:
| At least for the ones related to trees, it's just a renaming.
| Below is a link to the PR. When I initially implemented these
| trees, I chose the names BSTree and RBTree to keep the names
| short. I'm guessing the person that proposed renaming them did
| so to make it more obvious what they are.
|
| https://github.com/denoland/deno_std/pull/2400
|
| The standard library is separate from the runtime. It wouldn't
| break backward compatibility if you were to update. For
| example, if you were importing RBTree and upgraded Deno to the
| latest release, it would keep working just fine. You would only
| really need to switch to using RedBlackTree instead if there
| was a change made to it that you wanted.
|
| I think the only time you would need to update your standard
| module imports to be able to use newer versions of the Deno
| runtime would be if the standard module was depending on
| runtime APIs that have a breaking change.
| kitsonk wrote:
| std library is still considered "unstable" and the sub modules
| contained in there tend to have their own lifecycle as well.
| There has been effort to try to mature std to get to a stable
| version, which means cleaning up lots of things that would
| detract from long term maintainability.
| simlevesque wrote:
| Node.js before v1 (maybe even until v4) was like this. It took
| like 5 years.
| [deleted]
| rubenfiszel wrote:
| We bet big on deno with Windmill (OSS platform to turn scripts
| into internal UI and workflows) [1][2] and are extremely pleased.
| The language design choices and the performances/caching
| strategies are a perfect match for building a distributed
| workflow runtime at scale. However, the compatibility with npm
| was the most requested feature. Before the compatibility mode
| with npm was released, we were about to build a completely
| separate mode of execution based on node. This solves it very
| elegantly.
|
| Also super excited about the lsp improvements. I believe we are
| the only project to have a webeditor that features lsp
| integration with deno in the web (to test, go on [3], New Script
| -> Next, it works really well). It's very pleasant to work with
| and make the webeditor experience match closely a local dev
| setup. We are super excited about the improvements and I am about
| to try tonight if we can have the inline hints work with monaco.
| As we are fully open-source, one can see how we are able to pull
| it off [4][5].
|
| [1]: https://windmill.dev
|
| [2]: https://github.com/windmill-labs/windmill
|
| [3]: https://app.windmill.dev
|
| [4]: https://github.com/windmill-
| labs/windmill/blob/main/frontend...
|
| [5]: https://github.com/windmill-
| labs/windmill/blob/main/lsp/pyls...
| triyambakam wrote:
| I'm an eager and early adopter of Deno. I however look forward to
| ecosystem improvements, and the interop with npm is helpful. I
| was working on a side project recently that was a simple CRUD app
| and I just ended up going with Express on Node after fighting
| with Oak on Deno for a few days. It was still in the way enough
| to slow down the rapid fire development process that happens when
| you're still figuring out an idea.
| shafyy wrote:
| I'm also dipping my toes in Deno (with Fresh) for a side
| project. Just curious, what were the blockers you came across
| with Oak?
| kitsonk wrote:
| Yeah, I would be interested to understand what challenges you
| had with oak too.
| JoyrexJ9 wrote:
| Yeah NH gives a warped lens on how ready these runtimes &
| frameworks are for real work. Threads about Deno and Bun pop up
| almost weekly, yet in my experience they remain a long, LONG
| way from the stable (and admittedly stale) experience we have
| with Node and NPM
| encryptluks2 wrote:
| I don't know that they are made to.
|
| Npm packages already do too much, with package.json being
| used to run scripts that have permission to do nefarious
| tasks to relying on C libraries.
|
| If I were to use Deno it would be with the understanding that
| I'd need to find dependencies that are generic and
| standard... Not expect everything from npm to work by
| default.
|
| If I used either I'd specifically look for dependencies that
| are standard enough to not matter or
| [deleted]
| d4mi3n wrote:
| Better IDE support is huge. I know a lot of devs who liked the
| idea of Deno but weren't in a position to dump a lot of their
| development tooling to pick it up, so this effectively removes a
| big barrier to adoption for a lot of folks.
|
| Excited to see how well Deno's security features pan out under
| broader, real-world usage.
| MuffinFlavored wrote:
| > I know a lot of devs who liked the idea of Deno but weren't
| in a position to dump a lot of their development tooling to
| pick it up
|
| if VS Code already supports TypeScript, what is missing?
| brundolf wrote:
| Deno has its own language server, unfortunately. This is
| necessary because of a few key aspects of Deno code that are
| incompatible with the regular TypeScript support, and it
| means Deno's editor integration is often a step behind
| mainline TypeScript
| d4mi3n wrote:
| The ability to infer types from NPM packages. If you have
| existing codebases with non-trivial apps, reworking all your
| dependencies makes the prospect of picking up Deno a non-
| starter.
|
| My understanding is prior to this release the Deno LSP didn't
| have visibility into types from packages originating from
| NPM.
|
| Compatibility issues likely still exist, but I suspect the
| scope of work for an MVP substitution of Node for Deno is in
| the realm of possibility now when it wasn't before.
| dopeboy wrote:
| As a side note, this comment in itself is interesting. We are
| seeing tighter integration between frameworks and IDEs, almost
| a reversion back to early visual studio days. Will be
| interesting to see how each nudge the other.
| tomtheelder wrote:
| The coupling here is actually extremely loose. It's based
| around implementing an LSP server, which is editor/IDE
| agnostic. It trades depth of integration for breadth of
| support. I think it's the total opposite of the old days!
| Cupprum wrote:
| I really like the irony of this. The creator of node is fighting
| node now. Good jobs guys! You are doing nice job with deno.
| intellectronica wrote:
| Link to cached blog post:
| https://readwise.io/reader/shared/01ggdaqh2rr2my3qc5rzw09kpw
___________________________________________________________________
(page generated 2022-10-27 23:01 UTC)