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

21–30 of 100 posts

Re: From Node to Deno

#21

Post by pimple20 »

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.

That's not really the point of ORMs though. It's map your data objects in code to your entitled in your relational database. That it comes with a SQL builder is just a necessity in order for the mapping to be done by the ORM. You can still write raw sql with most ORMs, but then you won't get the mapping which is the point. In some cases you will need to do that and that's fine. Hiding complex SQL isn't the goal

Re: From Node to Deno

#22

Post by bkanber »

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've used lots of ORMs too. I have mostly positive experiences with them, but a lot of mixed experiences too.

However, Eloquent absolutely is a class above the rest. Honestly one of the best I've ever worked with.

Re: From Node to Deno

#23

Post by seanwilson »

hn_throwaway_99 wrote: post #19
seanwilson wrote: post #14

Earlier quoted context omitted.

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

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?

Re: From Node to Deno

#24

Post by adrianhel »

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

Re: From Node to Deno

#25

Post by hn_throwaway_99 »

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…

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 the toolchain, instead of replacing the entire runtime.

Re: From Node to Deno

#26

Post by adrianhel »

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…

It's an unstable feature, but you can use import maps with Deno.

Re: From Node to Deno

#27

Post by truth_seeker »

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 doubt they are as mature.

2. Deno's security model overly hyped at least i see it this way. In last few version of NodeJS, many security flaws have been addressed, see their changelog if you dont believe me. But most importantly, security flaws with native JS is handled by V8 which is common to both NodeJS and Deno. On top of that, most of the libraries and frameworks in NodeJS during their various releases sorted out many security issues in their code. If someone is still doubtful they can use eslint-plugins for sanity and security checks in their JS files. Adopting Typescript also helps if you cant live without types.

3. Learning curve to adopt new SDK for Socket API, File API, System call API etc. I don't think NodeJS falls short significantly anywhere, in fact it provides more and those APIs have been relatively more battle tested over the years.

4. Irrespective of using NodeJS or Deno, following a BDD/TDD practices to ensure sound test coverage of your business use logic still remain the most promising tool to make, break and refactor your codebase.

Re: From Node to Deno

#28

Post by h-cobordism »

bkanber wrote: post #18
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 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 on…

I skimmed the Eloquent docs[0] but I couldn't see anything that sets it apart from other ORMs. What makes it special?

[0]: https://laravel.com/docs/7.x/eloquent

Re: From Node to Deno

#29

Post by dingdingdang »

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…

The big deal here is security by default as enforced by the runtime (deno) itself - there is afaik none other doing anything remotely as cool anywhere. It in effect makes it super safe to run code since you have to explicitly allow the various levels of system access.

Also makes the system fundamentally unattractive to malware authors whereas installing modules via node.js is like leaving your front door open and taking a chartered holiday while hoping for the best.

Re: From Node to Deno

#30

Post by tuukkah »

k__ wrote: post #2

Desktop apps build on Electron should be a good fit for Deno, because Denos API is more like a Browser API than like the Node API.

Is there a decent browser (or other GUI framework) in Deno though? It has a wrapper for zserge/webview but I haven't used a webview in ages.
Post reply on HN