Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.14

deno.com

Post reply on HN
Print view View original

21–30 of 111 posts

Re: Deno 1.14

#21

Post by yawaworht1978 »

lytedev wrote: post #19
yawaworht1978 wrote: post #16

Earlier quoted context omitted.

I have 2 projects all in node, using express. Is there an easy way to migrate it? What happens to all the imported modules and dependencies? Can I still use express in Deno the same way?

Probably not, but Deno has Oak, which is Express-like and the combination of those two will get you close. But most node libs are not compatible and similarly node projects.

Thanks for that,Oh dear, I was secretly hoping for something as easy as a new package.json. A quick look around, I found this: Opine attempts to solve this by completely porting ExpressJS over to TypeScript in Deno, making changes only where the Deno APIs dramatically differ from Node.

Will give it a try, really curious how importing works and all.

Re: Deno 1.14

#22

Post by IggleSniggle »

maga wrote: post #12
lucacasonato wrote: post #7

Earlier quoted context omitted.

Please open an issue on denoland/deno_lint with examples so we can make the diagnostic messages more useful.

Thanks, I usually do, but in this case they are typescript issues and have tickets in the ts repo. For example, constructor signature for mixins requires `any` type that conflicts with `no-explicit-any` rule. In another case, `object` cannot be replaced with `Record ` when used with conditional types to mean "any non-primitive value".

This comment right here is enough for me to become suddenly much less keen on Deno.

If you're somebody who wants to make their ts as close to provable as possible, but also be able to handle dynamic / generative content, then you run into issues of this nature all the time with (for example) linter settings that think they know typescript better than you do, but fail to recognize that there is literally no other way to express some type-concept in typescript without using a larger feature set.

Re: Deno 1.14

#24

Post by IggleSniggle »

priansh wrote: post #17
rubyist5eva wrote: post #13

Anyone using Deno in production? Would love to hear how it's going for your team.

We tried it for a couple months, it was basically a huge hassle getting our stuff to work especially anything that has bindings to CPP (any of the node gyp packages). Also felt like we were putting in a lot more effort to try to get packages with docs for node to work similarly in deno, and weren’t really feeling any value from using deno over node. If you’re a hobbyist or an academic or starting a totally new projec…

I agree with this entirely. I would absolutely use deno to teach js/ts. I would absolutely use deno in a hobby project. I would absolutely use deno if my requirements were such that I wanted to minimize js dependencies.

Re: Deno 1.14

#25

Post by lucacasonato »

IggleSniggle wrote: post #22
maga wrote: post #12

Earlier quoted context omitted.

Thanks, I usually do, but in this case they are typescript issues and have tickets in the ts repo. For example, constructor signature for mixins requires `any` type that conflicts with `no-explicit-any` rule. In another case, `object` cannot be replaced with `Record ` when used with conditional types to mean "any non-primitive value".

This comment right here is enough for me to become suddenly much less keen on Deno. If you're somebody who wants to make their ts as close to provable as possible, but also be able to handle dynamic / generative content, then you run into issues of this nature all the time with (for example) linter settings that think they know typescript better than you do, but fail to recognize that there is literally no other way…

// deno-lint-ignore no-explicit-any

Re: Deno 1.14

#26

Post by lucacasonato »

siscia wrote: post #10

How it is the zero-copy ArrayBuffer transfer function implemented?

ArrayBuffers are just views on underlying memory owned by the thread a V8 isolate is running on. (Each worker runs on a separate thread, each with its own V8 isolate). When we transfer an ArrayBuffer, we detach the underlying memory from the isolate in the sending thread, and move ownership of the memory area to the receiving thread, where a new JS ArrayBuffer object is created that points to that memory area.

TLDR: The memory is never moved, the pointers to it are just detached from one isolate, and instead passed to another.

Re: Deno 1.14

#28

Post by sqs »

I tried out Deno last weekend for a fun little hack project (syncing a local Markdown file to a formatted Google Doc), and it was awesome.

Writing TypeScript code for Deno feels a lot like writing Go (which is a very good thing to me):

- opinionated build/fmt/deps

- well-designed stdlib

- no need for scaffolding files (.eslintrc, babel.config.js, jest.config.js, mocha.opts, etc.)

If that sounds good to you, try Deno!

Re: Deno 1.14

#29

Post by kroltan »

andrew_ wrote: post #18
yawaworht1978 wrote: post #16

Earlier quoted context omitted.

I have 2 projects all in node, using express. Is there an easy way to migrate it? What happens to all the imported modules and dependencies? Can I still use express in Deno the same way?

"Easy" is highly subjective. If you're proficient at picking up new architecture paradigms for familiar languages, you're adept with ESM syntax, and refactoring is a skill; then you might consider it easy. It's a paradigm shift, so there's always going to be some friction in migration. For your express needs, check out Oak https://deno.land/x/oak@v9.0.0

Could you clarify what is the paradigm shift? Static types? (If so I agree, but using Node does not imply not using TS)

Re: Deno 1.14

#30

Post by brundolf »

andrew_ wrote: post #18
yawaworht1978 wrote: post #16

Earlier quoted context omitted.

I have 2 projects all in node, using express. Is there an easy way to migrate it? What happens to all the imported modules and dependencies? Can I still use express in Deno the same way?

"Easy" is highly subjective. If you're proficient at picking up new architecture paradigms for familiar languages, you're adept with ESM syntax, and refactoring is a skill; then you might consider it easy. It's a paradigm shift, so there's always going to be some friction in migration. For your express needs, check out Oak https://deno.land/x/oak@v9.0.0

I wouldn't call it a paradigm shift in terms of the code itself. The main thing is that it's a completely different set of system APIs that have to be targeted (by you or by the libraries you use). That means a lot of changes wherever those are involved, but they should mostly be straightforward changes (of course YMMV if you're having to use a new library/framework instead of just the new system APIs)
Post reply on HN