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

From Node to Deno

dev.to

Post reply on HN
Print view View original

61–70 of 100 posts

Re: From Node to Deno

#61

Post by hn_throwaway_99 »

adrianhel wrote: post #24
hn_throwaway_99 wrote: post #15

Earlier quoted context omitted.

I just think that at the end of the day, for any moderately complex system under non-trivial load, the idea that you want to "hide the complexity of SQL" from the service developer is an absolutely flawed premise.

I agree. But I do like query builders (Knex for Node). I still write and think in SQL, but don't have to write queries as strings.

> I still write and think in SQL, but don't have to write queries as strings.

Why is that a benefit though? Why would I rather learn some custom query builder-specific DSL when SQL is at least mostly standardized pretty much everywhere. The use of template strings in JS can get rid of all the problems of just plain string concatenation for SQL (e.g. it can prevent SQL injection, enable safe dynamic queries, etc.)

Re: From Node to Deno

#62

Post by nitsky »

truth_seeker wrote: post #48
nitsky wrote: post #42

Earlier quoted context omitted.

Regarding point 3, Deno's APIs use language features that were unavailable when node was written, including promises and async iterators. That is a big improvement IMO.

You can easily PROMISIFY the low level callback style NodeJS SDK APIs using in-built utilities. https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_... It was introduced in NodeJS 8.x release. The latest LTS version is 12.x

Promisifying makes the node APIs more convenient, but you still do not have the ability to provide back-pressure. See the link below:

https://deno.land/v1#promises-all-the-way-down

Re: From Node to Deno

#63

Post by zamadatix »

hn_throwaway_99 wrote: post #58
sramam wrote: post #44

Earlier quoted context omitted.

Permissions are a whitelist. While the grant is a blanket grant to a program and all dependencies, typically, a well behaved program will seek a limited scope of permissions. Like " https://my-program.com" , " https://preferred-analytics.com" etc. This prevents dependencies from using call back locations that are outside the permitted list, preventing much of the nefarious activity they can dream up. If a dependency…

> Importantly, the user is explicitly aware of these & controls it in an absolute sense, at run time. I mean, I guess I see value there for the use case of "I want to download a script to run locally on my machine" type of thing, but for the most common use of Node, i.e. I'm running a server process, does this really even matter?

I think the most common use of Node might actually be Electron if you go by number of users.

Re: From Node to Deno

#64

Post by truth_seeker »

nitsky wrote: post #62
truth_seeker wrote: post #48

Earlier quoted context omitted.

You can easily PROMISIFY the low level callback style NodeJS SDK APIs using in-built utilities. https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_... It was introduced in NodeJS 8.x release. The latest LTS version is 12.x

Promisifying makes the node APIs more convenient, but you still do not have the ability to provide back-pressure. See the link below: https://deno.land/v1#promises-all-the-way-down

There are definitely few things which are done in different way in Deno as part of re-design.

But that does not mean NodeJS does not take care of it or at least provide the some API to tackle that issue.

In this case, Stream interface API in NodeJS are the solution to the problem. They help you build layer over native EventEmitter interface or rather strictly speaking they help extend it.

This links might be helpful for you.

Backpressuring in Streams - https://nodejs.org/es/docs/guides/backpressuring-in-streams/

Official Docs on Stream API - https://github.com/nodejs/node/blob/master/doc/api/stream.md

Note that HTTP server in NodeJS already implements it.

Re: From Node to Deno

#65

Post by satvikpendem »

xkapastel wrote: post #16
hn_throwaway_99 wrote: post #12

I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" fo…

This is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do: SUBCOMMANDS: bundle Bundle module and dependencies into single file cache Cache the dependencies completions Generat…

Static compilation of JS into a binary is also being worked on (albeit slowly) with `deno compile`[0]. This is the feature I'm most looking forward to personally, goodbye JS slowness.

[0] https://github.com/denoland/deno/issues/986

Re: From Node to Deno

#66

Post by littlestymaar »

hn_throwaway_99 wrote: post #25
xkapastel wrote: post #16

Earlier quoted context omitted.

This is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do: SUBCOMMANDS: bundle Bundle module and dependencies into single file cache Cache the dependencies completions Generat…

Totally agree with all that, but I also think it's one of those things that most devs hit the pain point for once, and then have a standard template project they use for everything going forward. I.e. I have all my webpack/tsc/eslint/prettier/jest boilerplate set up once, so now it's not really an issue for me. I also think this is a problem area where the Romejs project is taking a better approach: simplify and fix…

> Totally agree with all that, but I also think it's one of those things that most devs hit the pain point for once, and then have a standard template project they use for everything going forward. I.e. I have all my webpack/tsc/eslint/prettier/jest boilerplate set up once, so now it's not really an issue for me.

Stop using JS for a year, and come back only to discover that half of the tools you were using back then is at best obsolete or even deprecated and unmaintained, or that their API changed so much in a major version that you can't recognize it (see the Babel6 — AKA Babel Vista— update).

And since you're not only using these tools but also their integration to your favorite editor, you cannot stick on the old version for long, unless you stop upgrading your editor altogether).

Re: From Node to Deno

#67

Post by ashkankiani »

satvikpendem wrote: post #65
xkapastel wrote: post #16

Earlier quoted context omitted.

This is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do: SUBCOMMANDS: bundle Bundle module and dependencies into single file cache Cache the dependencies completions Generat…

Static compilation of JS into a binary is also being worked on (albeit slowly) with `deno compile`[0]. This is the feature I'm most looking forward to personally, goodbye JS slowness. [0] https://github.com/denoland/deno/issues/986

It's not going to be static compilation or give any sort of speedup. That's just a bundling command basically.

Re: From Node to Deno

#68

Post by dzonga »

and the great migration begins. but when you look at other backend ecosystems e.g php, ruby on rails they're still getting shit done. even though people might say those languages/frameworks might be slow or insecure. stability is what's lacking in the JS ecosystem. glad I do my backends in flask now

Re: From Node to Deno

#69

Post by nicoburns »

hn_throwaway_99 wrote: post #12

I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" fo…

I'm not seeing enough in Deno that would tempt me to drop compatibility with the Node ecosystem. What I really want is actual Node.js with native TypeScript support.

Re: From Node to Deno

#70

Post by jariel »

xkapastel wrote: post #16
hn_throwaway_99 wrote: post #12

I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" fo…

This is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do: SUBCOMMANDS: bundle Bundle module and dependencies into single file cache Cache the dependencies completions Generat…

None of those are very important.

When node appeared, it was a 'huge thing' because you could run JS consistently on the server-side, with some kind of packaging scheme.

Most of the things you listed aren't going to be useful to most, even when they are, they are small things that can be managed otherwise. Though admittedly, everyone will runt into at least one of those issues.

For a large, complex deployment, there's no obvious reason at all to shift to Deno.

We'll have to wait and see how it works out for those who want to try it for fun.

Post reply on HN