Deno.js in production
61–70 of 100 posts
Re: Deno.js in production
#62> ‘Deno’ (like ‘Node’ but backwards) Yeah, no. I wonder if more people just assume that to be true, heh. I kind of was expecting it, weirdly enough. Hint: "node" is "edon" backwards. Not sure if that name is taken for something Javascripty ... * goes to check * yeah, I found [1] which seems to be 4 years old, tagline "Run browser JS in the terminal". [1] https://github.com/dbkaplun/edon
"node".split("").sort.join("")
"node".split("").sort().join("")
Re: Deno.js in production
#63Earlier quoted context omitted.
This means at the level of their ability to draw in candidates, Deno interest is signal to their hiring pipeline of more quality. The consequence is their hiring pool is also that much smaller. One might say the same thing about Java v Go.
> The consequence is their hiring pool is also that much smaller. In the current market, unless you're a big company that gets flooded with applications on a daily basis, why would you ever reduce your hiring pool arbitrarily? If you're a 13-person startup with good funding, you want all the candidates you can possibly get. Excluding potentially great engineers because they've never worked with Deno doesn't make any…
However, Java vs Go would probably make a big difference in terms of hiring pool size.
Re: Deno.js in production
#64Re: Deno.js in production
#65node.js nowadays is a total disaster. I've been able to hold down the fort with turbo repo, but even then it's been a touchy strategy. I want to switch to Deno, and I'm interested in articles like this. Either that, or, because of the state of nodejs/NPM modules, and it's ever-increasing surface area of doom and resume driven development node modules, either somehow switch to deno or go back to just HTML and vanilla…
Yep, I'm feeling this right now. I was recently tasked with updating an internal node app that hadn't been touched in about 4 years and it's seriously one of the least fun things I've had to do in my nearly 10 year career. After hacking away at for it a couple weeks, I told my boss that it needs a ground-up rewrite.
The bazaar approach of Node and NPM has created an absolute hellscape to develop in.
Re: Deno.js in production
#66node.js nowadays is a total disaster. I've been able to hold down the fort with turbo repo, but even then it's been a touchy strategy. I want to switch to Deno, and I'm interested in articles like this. Either that, or, because of the state of nodejs/NPM modules, and it's ever-increasing surface area of doom and resume driven development node modules, either somehow switch to deno or go back to just HTML and vanilla…
I’ve been using Node.js pretty much daily in production for almost a decade now, and it’s never been a total disaster, not even close.
Re: Deno.js in production
#67`redis` and `ioredis` `npm` packages don't work with Deno, even with the Node compat layer (I tried). So you have to use the Deno driver for Redis. But you look up the library for this, and it's experimental: https://deno.land/x/redis@v0.25.5
Same deal with Postgres. `pg` would not compile at all. Knex also didn't work (this was an older project). I'm assuming this is because these two packages use native Node.js plugins.
I like Deno a lot, and the out of the box TypeScript support is a gamechanger, but I had a really tough time working with it and actually being productive.
Re: Deno.js in production
#68For me, a javascript developer that mainly use Node.js for work, Deno is interesting and I want to use it but the hosting part is what prohibits me from using it. In node it's easy to run production code with pm2, you can cluster it and it's super easy to configure it so that it will run one node process per available core.
With Deno, you can't do this because there is no clustering available so you kind of have to run it on single core machines to get maximum performance out of your hardware. In other words, on cloud solutions like Deno deploy or a Kubernetes cluster configured to run it on single cpu docker containers.
I am not interested in that and as long as it is that way, running Deno is unfortunately a waste of my hardware. Sure there are web workers and they are great for stuff but if my process dies for some reason I don't want that to halt the application.
Re: Deno.js in production
#69I haven't had the same success with Deno that I expected. At first, I was shocked by how good the tooling is, and I was super happy with its dependency management. All of the problems started once I started getting into actual business logic. `redis` and `ioredis` `npm` packages don't work with Deno, even with the Node compat layer (I tried). So you have to use the Deno driver for Redis. But you look up the library f…
Re: Deno.js in production
#70I haven't had the same success with Deno that I expected. At first, I was shocked by how good the tooling is, and I was super happy with its dependency management. All of the problems started once I started getting into actual business logic. `redis` and `ioredis` `npm` packages don't work with Deno, even with the Node compat layer (I tried). So you have to use the Deno driver for Redis. But you look up the library f…
On the other hand, not being able to bring all of the node.js package ecosystem along can be considered a feature.
There's a lot of crap in the node.js ecosystem, no denying it.
But there's just a lot of packages in general. Many of which are really, really well designed and good.