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

51–60 of 100 posts

Re: From Node to Deno

#51

Post by okbake »

kingdomcome50 wrote: post #38
seanwilson wrote: post #23

Earlier quoted context omitted.

I guess I mean it's never going to be answered because there is no short answer. It's like asking: what's the best programming language?

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-tracking, data mapping, etc. Having a decent query builder that isn't abstracting away too much of the underlying sql (essentially just mapping 1-to-1) plus data mapping are the sweet spot for me personally.

Re: From Node to Deno

#52

Post by BenoitEssiambre »

ljackman wrote: post #33

It looks like a good evolutionary improvement over Node.js. However, I have a concern about its security claims. Perhaps someone on the project can allay these concerns. My brief skimming of its site indicates that its security model is based around the ability to disable, say, network access for whole Deno programs. However, does it allow starting up with network access, allowing a subset of the program to handle it…

Also, "promise first" seems to be premature to me. You could have simpler, more stateless async/await without promises: https://www.npmjs.com/package/casync

Re: From Node to Deno

#53

Post by cozuya »

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…

It will succeed if it handily wins side by side benchmarks, its that simple.

Re: From Node to Deno

#54

Post by vipshek »

harikb wrote: post #32
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…

If anyone remembers, this is similar to the “Turbo Gears” vs “Django” of Python world. Turbo Gears allowed me to choose the best of each component - but pretty soon one ends up having to upgrade or migrate to the new-best-sub-component on a weeekly/monthly basis. django helped avoided a lot of headache by defaulting a decent, but not necessarily the best tool, and sort of “won” in the end. For some reason, we continu…

This strikes me a similar to a dynamic at the level of entire corporations and industries—commodification/modularization on one end, wholeness/integration on the other: https://stratechery.com/2015/netflix-and-the-conservation-of...

Re: From Node to Deno

#55

Post by oweiler »

cozuya wrote: post #53
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…

It will succeed if it handily wins side by side benchmarks, its that simple.

I doubt it. For a lot of use cases node is fast enough.

Re: From Node to Deno

#56

Post by mcintyre1994 »

truth_seeker wrote: post #27

Few things comes to my mind if you are moving from NodeJS to Deno: 1. Deno lacks the library eco system which is required to build a production level app today. I am not saying it cant be done. Just think of the different third party service integration modern application has to do, their maintainance and testing by individual vendors or open source contributors ! Blogs mentions few DB driver libraries, i highly doub…

There's no way it's going to match everything, but regarding number 1 - it does look like you can drop in some node modules. A small example, but one that surprised me - React works. So you can do React with SSR with nothing else, eg. this demo is a pretty refreshing one to see how few moving pieces there are. https://github.com/brianleroux/arc-example-deno-ssr . It's just imported as `import { React, ReactDOM } from 'https://unpkg.com/es-react'`

Re: From Node to Deno

#57

Post by hn_throwaway_99 »

Ciantic wrote: post #39
hn_throwaway_99 wrote: post #25

Earlier quoted context omitted.

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…

> I have all my webpack/tsc/eslint/prettier/jest boilerplate set up once, so now it's not really an issue for me. For any given nut in that stack, there is hundreds of different iterations. Even if you can manage that, it changes between projects and people. It is horrible mess if you think about it from company point of view. Everyone who comes to new team, has some own quirks and ideas about that stack, which just…

Again, I totally agree with everything you've said, but if that's the primary problem (which, when it comes to Node/JS dev, I think it probably is), then the solution should focus on that, i.e. fix the toolchain a la RomeJS, rather than create an entirely new runtime.

Re: From Node to Deno

#58

Post by hn_throwaway_99 »

sramam wrote: post #44
ljackman wrote: post #33

It looks like a good evolutionary improvement over Node.js. However, I have a concern about its security claims. Perhaps someone on the project can allay these concerns. My brief skimming of its site indicates that its security model is based around the ability to disable, say, network access for whole Deno programs. However, does it allow starting up with network access, allowing a subset of the program to handle it…

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?

Re: From Node to Deno

#59

Post by hn_throwaway_99 »

ljackman wrote: post #45
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…

The whitelisting looks great. Even with the remaining concerns I raised in the other comment, the ability to whitelist only allowed domains for network connections is a massive step up security-wise, even if they are allowed for the entire program (until revoked globally).

I'm not an expert on this in any sense, but would it be possible to add this into Node at the OS level, e.g. make use of network namespaces to restrict outbound network access?

Re: From Node to Deno

#60

Post by truth_seeker »

mcintyre1994 wrote: post #56
truth_seeker wrote: post #27

Few things comes to my mind if you are moving from NodeJS to Deno: 1. Deno lacks the library eco system which is required to build a production level app today. I am not saying it cant be done. Just think of the different third party service integration modern application has to do, their maintainance and testing by individual vendors or open source contributors ! Blogs mentions few DB driver libraries, i highly doub…

There's no way it's going to match everything, but regarding number 1 - it does look like you can drop in some node modules. A small example, but one that surprised me - React works. So you can do React with SSR with nothing else, eg. this demo is a pretty refreshing one to see how few moving pieces there are. https://github.com/brianleroux/arc-example-deno-ssr . It's just imported as `import { React, ReactDOM } from…

By no means i am demotivating anyone. I have just enumerated the minimum possible evaluation criteria and current state of development. This is what i often do at my workplace as an Architect.

If someone is eager to try out new possibilities in Deno and their application use cases intersect well with what Deno has to offer, then by all means it's a good decision.

Post reply on HN