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

91–100 of 100 posts

Re: From Node to Deno

#91

Post by Snelius »

nicoburns wrote: post #69
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.

I think the best is a TS to binary right away :)

Re: From Node to Deno

#92

Post by thelazydogsback »

What Node is missing due to it's design is parallel (not just async-on-a-single-thread) processing using either green or OS threads without the overhead of serialization to web-workers or a cluster. Last time I checked, Deno didn't have a story there.

Re: From Node to Deno

#93

Post by eloff »

jariel wrote: post #88
eloff wrote: post #84

Earlier quoted context omitted.

There are at least three big obvious reasons. 1) You need a secure sandbox for running JavaScript (e.g. You run a SaaS and you want your users to be able to customize something). NodeJS has to be sandboxed at VM level like Python, even although JavaScript was designed for this very purpose. 2) You want a TypeScript first nodejs. 3) You want isomorphic JavaScript between the browser and the server, because node does i…

None of those are 'big reasons'. Or rather, they might be 'big' for a few teams in specific areas, but they are not 'big market opportunities' not even close. The ability to go from Java+Spring OR Perl/PHP - and then have the choice to actually do JS on the server is a big deal - and that's why Node.js was a success. The sandbox is nice but I don't see it being a big opportunity just yet. 'Running your own SaaS with…

I would use it if it was npm compatible, and that does seem to be coming. Remember it's not a new language, more like Python vs IronPython. Although hopefully it will have more success.

Re: From Node to Deno

#94

Post by sramam »

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?

For most networked applications, there are two classes of permissions control - inbound and outbound.

The inbound is a run-time decision and dynamic at that - Firewalls, WAFs etc. are used for control. These are not (and probably should not) be set by the application author, but by the application operator.

The outbound however, is typically something that is designed into the application - it should be specified by the author, be available for auditing - both on first install and all subsequent changes. IMHO, this is where these whitelists shine.

For the server example you mention, whitelists don't prevent a malicious dependency from using your CPU for mining. With deno, by default, there is no way to dial-home the proof-of-work and collect the reward. Eventually, as the operator of the service, you'll notice a performance/cost problem and detect the malicious activity.

Re: From Node to Deno

#95

Post by jdxcode »

tstrimple wrote: post #85
hn_throwaway_99 wrote: post #9

Earlier quoted context omitted.

The idea that ORMs are a net-positive is definitely an open question. After 20+ years I'm certainly of the opinion they're not. I recently discovered Slonik (only for postgres, hope there is eventually a port for MySQL and others) and I'm a huge fan of the overall approach and the API. This blog post from the creator explains: https://medium.com/@gajus/stop-using-knex-js-and-earn-30-bf4...

Sometimes all you really need are simple CRUD operations against a data store for a particular app. Most ORM fill that roll quite well in my opinion. They are also great for rapid prototyping. I think where people run into problems is trying to shoehorn every data operation through the ORM layer, especially for more complicated data storage requirements. That being said, working with knex was a miserable experience.

if it's simple, why do you need to include a new dependency? Especially one as complex as an ORM?

Re: From Node to Deno

#96

Post by brlewis »

brlewis wrote: post #10
ralusek wrote: post #6

Thanks for doing this. I have a few questions regarding packages/dependencies, and TypeScript in general. I tried installing Deno, and I tried including a package, and immediately the TypeScript typechecking in my IDE (VSCode) failed, of course. The IDE doesn't know what to do with a URL as a dependency. Is this something Deno will be able to handle? The next question is that TypeScript packages I have written in the…

https://stackoverflow.com/questions/54794933/how-to-pull-typ... Looks like there's a plug-in. Can't research much now, but I hope there's something like that for emacs tide.

I think for emacs/tide I'll just be able to follow the instructions for Atom here: https://github.com/justjavac/typescript-deno-plugin

Re: From Node to Deno

#97

Post by kingdomcome50 »

recursive wrote: post #79
kingdomcome50 wrote: post #38

Earlier quoted context omitted.

I disagree with this sentiment. The use-cases for an ORM are straight-forward. It's more like asking, "which tool is best for getting this nail into this piece of wood?" What most people discover to be the greatest benefit of using an ORM is the "mapper" bit (converting tabulated data into an object graph and visa versa) and, to a lesser degree, change-tracking. Somewhat ironically, the overwhelming majority of the t…

Static type safety is one difference.

It'd be more accurate to say the illusion of type safety.

Under the hood many[0] ORMs simply construct a query similar to my example above and then convert result set of tabulated strings to the appropriate types (usually using reflection).

This means two things:

First, that the "type-safety" portions of an ORM are really located in the "mapping" code, so not really related to querying.

And second: you don't really have type safety. A database schema could change at any time and break the code even if static analysis seems to think it should work.

[0] Notable exceptions are languages that offer type providers (e.g. F#) but I digress

Re: From Node to Deno

#98

Post by kingdomcome50 »

okbake wrote: post #51
kingdomcome50 wrote: post #38

Earlier quoted context omitted.

I disagree with this sentiment. The use-cases for an ORM are straight-forward. It's more like asking, "which tool is best for getting this nail into this piece of wood?" What most people discover to be the greatest benefit of using an ORM is the "mapper" bit (converting tabulated data into an object graph and visa versa) and, to a lesser degree, change-tracking. Somewhat ironically, the overwhelming majority of the t…

A big benefit of the `users->where(...)` approach is being able to reuse and compose. An example would be conditionally adding a WHERE clause based on some parameters. Using the raw query approach you end up having to do some string concatenation versus managing the state of the some query builder object. I think that the "query builders" though are just one piece of the ORM that you mention, alongside the change-tra…

You are correct.

Interestingly, it is this exact property (composition) that creates the most common problems when using an ORM.

Composition is often at odds with optimization.

Re: From Node to Deno

#99

Post by satvikpendem »

ashkankiani wrote: post #67
satvikpendem wrote: post #65

Earlier quoted context omitted.

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.

Ah that's disappointing. i wonder if there is any work to create a JS compiler.

Re: From Node to Deno

#100

Post by recursive »

kingdomcome50 wrote: post #97
recursive wrote: post #79

Earlier quoted context omitted.

Static type safety is one difference.

It'd be more accurate to say the illusion of type safety. Under the hood many[0] ORMs simply construct a query similar to my example above and then convert result set of tabulated strings to the appropriate types (usually using reflection). This means two things: First, that the "type-safety" portions of an ORM are really located in the "mapping" code, so not really related to querying. And second: you don't really h…

This particular illusion of safety actually provides some non-zero degree of safety. For instance, it prevents trivial typos in property names.
Post reply on HN