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

11–20 of 100 posts

Re: From Node to Deno

#11

Post by aralroca »

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…

For VSCode there is recommended this:

* https://marketplace.visualstudio.com/items?itemName=axetroy....

Re: From Node to Deno

#12

Post by hn_throwaway_99 »

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" for years IMO (lock files mess, signed code mess, etc.) but I feel most of those pain points have largely been addressed.

I downloaded Deno and tried it out, but at this point I'm just left thinking it doesn't really add anything for me that I need.

Re: From Node to Deno

#13

Post by derision »

hn_throwaway_99 wrote: post #9
milutinovici wrote: post #3

The one big thing missing is an ORM. And making those things is notoriously difficult. Hopefully something will turn up

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...

I've used a number of ORMs in the past and have not had a great experience, but recently have been using Eloquent with laravel and it's really great

Re: From Node to Deno

#14

Post by seanwilson »

hn_throwaway_99 wrote: post #9
milutinovici wrote: post #3

The one big thing missing is an ORM. And making those things is notoriously difficult. Hopefully something will turn up

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...

> The idea that ORMs are a net-positive is definitely an open question.

If it's still being debated, isn't that a good indication that there's no perfect solution for every use case?

ORMs are likely more straightforward when you know you're not going to need to do anything advanced, but get in the way when you need fine grained control for example.

Re: From Node to Deno

#15

Post by hn_throwaway_99 »

derision wrote: post #13
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...

I've used a number of ORMs in the past and have not had a great experience, but recently have been using Eloquent with laravel and it's really great

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.

Re: From Node to Deno

#16

Post by xkapastel »

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    Generate shell completions     
        doc            Show documentation for a module                                         
        eval           Eval script                       
        fmt            Format source files                                       
        help           Prints this message or the help of the given subcommand(s)
        info           Show info about cache or info related to source file
        install        Install script as an executable
        repl           Read Eval Print Loop
        run            Run a program given a filename or url to the module
        test           Run tests
        types          Print runtime TypeScript declarations
        upgrade        Upgrade deno executable to given version
What would it take to get Node to do all of that? Which documentation tool would you choose, and how would you configure it? Testing? Bundling? Formatting?

Re: From Node to Deno

#17

Post by macintux »

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 can say that the word “sandbox” immediately raises the interest level among security folk.

Re: From Node to Deno

#18

Post by bkanber »

hn_throwaway_99 wrote: post #15
derision wrote: post #13

Earlier quoted context omitted.

I've used a number of ORMs in the past and have not had a great experience, but recently have been using Eloquent with laravel and it's really great

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 disagree. I've used many ORMs in my ~20 years, and I've architected and designed several hugely complex systems under non-trivial load.

There are really two things I want to put out there:

1) My opinion is that about 90% of your standard, day-to-day queries work just fine in a good ORM. The developer _should_ know enough about the DB schema and SQL to handle the other 10%. (In our 10 y/o enterprise software, the only queries we really drop down into SQL for are complex windowed reporting queries.)

2) Eloquent ORM is... different. It's probably the best I've seen. I wish it existed in other languages. Sequelize, which may be the "best" in the JS ecosystem, doesn't hold a candle to Eloquent, IMO.

Re: From Node to Deno

#19

Post by hn_throwaway_99 »

seanwilson wrote: post #14
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...

> The idea that ORMs are a net-positive is definitely an open question. If it's still being debated, isn't that a good indication that there's no perfect solution for every use case? ORMs are likely more straightforward when you know you're not going to need to do anything advanced, but get in the way when you need fine grained control for example.

I definitely agree there is no perfect solution for every use case. What I think is a mistake, however, is using a technology that makes stuff easier when you are small and have little load, but then become absolute burdens once you become successful and need to scale. I've worked on many a project where the ORM became the primary piece of "tech debt" that was hindering productivity.

I contrast that with technologies that are easy to use when you're small, but then let you layer additional pieces on later when you need to scale, without needing to redo everything.

Re: From Node to Deno

#20

Post by ashtonkem »

hn_throwaway_99 wrote: post #9
milutinovici wrote: post #3

The one big thing missing is an ORM. And making those things is notoriously difficult. Hopefully something will turn up

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...

While I agree that there are certainly places where ORMs are net negative for the developer, for a language ecosystem having one is net positive.

Lots of app developers need simple and easy to setup database access so that they can focus on the parts of their app that matters. Not having an ORM means that a decent chunk of them will move on to another language/ecosystem that has the libraries they want.

Post reply on HN