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

41–50 of 111 posts

Re: Deno 1.14

#41

Post by lenkite »

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…

You can use Deno without TS. I use it with plain JS and the code/test cycle is much faster without typescript compilation. Basically prefer Deno for ES6 modules and the good standard library.

Re: Deno 1.14

#42

Post by WorldMaker »

oauea wrote: post #35
afiori wrote: post #32

Earlier quoted context omitted.

There is a compatibility layer but it is not complete. One of Deno's objectives is not to expose V8 internals, so node packages relying on those will be harder to port

Who doesn't love being removed even further from the platform they're running on?

Deno is striving for more unified APIs with browsers, so while they are moving away from the "platform" of internal use only V8 APIs, they are moving toward the "web platform", which seems an admirable goal to me. One of my biggest complaints for a while has been how drastically different some Node APIs are from the way any actual "web platform" APIs work in 2021 (Promises for filesystem APIs in Node are still "experimental", and meanwhile there's an actual filesystem API standardized in the "web platform" that is entirely incompatible but Promise-based). You can polyfill some of the "web platform" libraries back on top of Node in many cases, but Deno seems sensible to me in trying to better unify such things from the start.

Re: Deno 1.14

#43

Post by dgb23 »

oauea wrote: post #35
afiori wrote: post #32

Earlier quoted context omitted.

There is a compatibility layer but it is not complete. One of Deno's objectives is not to expose V8 internals, so node packages relying on those will be harder to port

Who doesn't love being removed even further from the platform they're running on?

One of Deno's value props is to have a tighter and more explicit trust model.

And this is not a obscure need. There are cloud providers who let you run JS on a specialized and restricted API.

However, there is nothing stopping you from using Node or integrating V8 and go wild with it! (In fact I would argue that this is a solid strategy for some types of projects, where you can get the best of both (static/dynamic) worlds.

Re: Deno 1.14

#44

Post by nexuist »

Does anyone know if Deno has undergone a security audit yet? I'm interested in using it as a sandbox to run user-submitted JS, and I know its permission model is powerful, but I don't know if it is formally certified (if that's even a thing) and if you can prove that there can't be some exploit that can be used to break out of the sandbox.

Re: Deno 1.14

#45

Post by WorldMaker »

qsort wrote: post #2

Only tangentially related, but what's the point of a static class block? What problem does it solve that's not covered by either the class constructor or a static const? Doesn't it introduce a weird (stateful!) computation that's hard to reason about? There's probably a use-case I'm missing, because intuitively I'd automatically classify it as bad a practice.

Another perspective on static blocks is what they replace/help migrate away from. Static blocks are one of the last pieces of the puzzle holding some projects (or at least some particularly old legacy objects in those projects) from migrating to the new class syntax. For better or worse the classic Constructor Function pattern of building objects in JS was full of static initialization code (as it was an easy thing to do in that pattern). Static blocks bring back a way to do that in class syntax while adopting the better scoping rules of class syntax, helping more projects move away from Constructor Functions to class syntax.

Re: Deno 1.14

#46

Post by kbenson »

yawaworht1978 wrote: post #21
lytedev wrote: post #19

Earlier quoted context omitted.

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.

> really curious how importing works and all.

So was I, so this is what I determined, on top of the official docs.[1]

On deno run of a script, it will download referenced imports and put them into a cache directory with a hash of the name. On a UNIX-like, this seems to be in ~/.cache/deno/deps (there's also a ~/.cache/deno/gen for the TS to JS stuff). Subsequent runs do not seem to download the scripts, but instead use the cached hashed versions. There's probably a way to blow out or overwrite the cache with newer download with a deno command, but I'm not sure what it is.

Compiling bundled the cached dependencies, so they aren't downloaded on run. Importing from local files is also possible, as noted in the docs I linked.

I'm happy to be corrected to supplemented on any of that info, I would rather know the actual way it works than persist in a slightly wrong assumption. :)

1: https://deno.land/manual@v1.11.5/examples/import_export

Re: Deno 1.14

#47

Post by andrew_ »

kroltan wrote: post #29
andrew_ wrote: post #18

Earlier quoted context omitted.

"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)

package management, scripts are quite the shift in Deno. there are tools like velociraptor and trex which help bridge the gap, but there's still a lot to learn that's much different than node-world.

Re: Deno 1.14

#48

Post by hardwaregeek »

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…

Yeah I wonder how this will work long-term. I haven't heard of an ecosystem where they successfully avoided packages. Eventually you need some way of pulling in code that's versioned and has versioned dependencies of its own. Otherwise you end up with implicit versions or rolling your own everything, both of which are less than ideal and not necessarily better than packages. Deno could keep adding stuff to its standard library but I doubt even the largest stdlib could fit all users' needs.

Re: Deno 1.14

#49

Post by NotAnOtter »

sqs wrote: post #28

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!

Checking Deno out for my next project. I'm a recent typescript convert after working on a full JS team.

The types feel soooooo good.

Re: Deno 1.14

#50

Post by Bilal_io »

kbenson wrote: post #34
sqs wrote: post #28

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!

I also tried it out recently, because I wanted to make a small utility for myself and liked the idea of it providing a single executable (and bypassing the node/NPM ecosystem for learning a JS/TS based system appealed to me). It delivered on that beautifully, as all I did is switch from running "deno run" as I was for testing to "deno compile" and it delivered to me exactly what I was looking for. A bit large at 57 M…

That's interesting.

57mb is big, but not an issue when it's for personal use.

Somewhat related, I haven't used rust, but I read that it can produce an executable including the run time for edge that is less than 1mb,. I couldn't find the source, but this article shares how an extension was reduced from 12mb to 4.5mb.

Post reply on HN