Deno Cron
deno.com
deno.com
1. Services like this cron with Dyno Deploy or Vercel where the cloud things are abstracted away for you.
2. I have no data to back it up but it seems like JVM is experience a bit of a comeback with a few companies adopting Kotlin for backend and, also subjectively, talk about Elixir has increased here on Hacker News (we've all seen that table that shows how the Erlang VM is cron/background jobs/logging service/KV store all rolled into one). And if those are not the trends I feel like they should be.
Both of those are very appealing to me as a team lead. Honestly, I have never been a fan of managing services in AWS/GCP/etc - the setup overhead rarely seemed to outweigh the pros, at least until some heavy amount of data start moving around. I might be stating the obvious - less work is definitely better, but pretty much every company I have consulted for in the last few years had a (crappy) bespoke cloud setup that was a massive time sink.
> it seems like JVM is experience a bit of a comeback with a few companies adopting Kotlin for backend
JVM 21 adding virtual threads, and Spring Boot 3.2 using them with one line of config is huge. We can now write simple code that looks blocking and let the runtime handle it instead of writing async function/await everywhere. Personally I'm loving Spring Boot 3.2 with Kotlin, especially for the fact that I can bundle scheduled jobs, API, and frontend all in one place for my indie projects. Plus the JVM world of devs seems to have a somewhat decent appreciation of how to make web services that aren't rife with unnecessary coupling.
The bad? There is a legendary amount of cargo-culting blog posts and questionable advice around Spring Boot, often for older versions.
We need more well rounded people that also fundamentally understand how their code is executing on the backend so performance and cost can be optimized.
Make nice spaghetti and it sticks to the wall effortlessly. Make bad spaghetti and it takes 4 people and a dozen rolls of duct tape to get it up there.
I really don't know where the bullshit coming from. Often it looks like every single person is fighting for their lives against it, and yet it keeps growing.
But it's mostly dictated by overarching decisions that constrain both how it runs and how it's made (AKA, outside somewhere). Of course, there exist people on both sides that create problems all by themselves, but those are always easy to solve.
While annoying, there's often a good reason behind those if you can drill down to the engineers that asked for that rule.
Just as an example, it's easy to provide a single HA solution at the infrastructure tier... provided the infra people can make a few assumptions about your app (stateless, can handle multiple copies running at once, etc). It's virtually impossible to build HA that makes no assumptions, and it's incredibly burdensome to support 85 different HA implementations with varying sets of assumptions.
It makes business sense to have infra do the HA instead of each developer team, and that means restrictions on how apps are built and run.
What you're experiencing is the platform-ization of a bunch of aspects of the app.
Making nice spaghetti usually consists of finding the rules, finding the people who made them, and then grabbing them and asking "what does it take for this app to be in prod 15 minutes after we push the last commit?". It sounds like it will be a lot of people because there's a lot of rules, but there's usually like a half-dozen teams that make all the rules.
It will likely force you to build differently than you would have, but it will also mean that you're more likely to have 0 friction and you're more likely to get help with the friction you do encounter.
There's some complexity coming from better usability requirements, but again, it only explains a small part of it. There's something from the even-driven nature of the web never actually making inroads into our toolset (any toolset people actually use), that's a larger one, but again, it was 20-and-many years ago, it can't explain a constant creep-in.
Instead, since the 10's all the large innovations on software development seem to be about standardizing the complexity, and separating it so you can offshore. And yet, every time one of those gets adopted, the complexity creeps in.
I don't think I agree. Complexity--many parts, opposes "simple"--is part of the job; I'm pretty comfortable reasoning at the product layer (I've done devrel and product management) and working down to the cloud or bare metal (sometimes you find yourself wielding strace and wondering what mistakes got you here). Granted, that I have a handle on that complexity is part of why I'm a staff/principal engineer: to do that, and to help others who haven't achieved that level of understanding yet.
But by trying to remove complexity, IME you invariably introduce complication--relative difficulty in comprehending a given part, opposes "uncomplicated"--and that's where the demons lie. You give "the spaghetti maker" a nice, perfectly spherical pasta extruder; the amount of complication introduced by attempting to insulate the person on that side of the house only introduces problems for the other, who in turn must introduce complication to maintain it. That itself in turn introduces new constraints to the guy who just wants to turn the crank on the spaghetti maker and now his world reintroduces the complexity the initial perfectly-spherical-tool tried to remove.
Better, instead, to embrace that there are multiple moving parts that themselves are allowed to be uncomplicated, and work from there. Some complication is inevitable and irreducible, but if you don't treat each part of your system as being on an island, you can manage it and put it where it has the least impact.
There's also some sort of balance that needs to be struck. As a 'web developer'... to be 'well balanced', I need to understand (or dig in to) the minutia of:
* JS build tools, syntax, oddities, versions, and be able to troubleshoot these in a variety of environment (works locally with these architectures, and runs on production, but the CI pipeline changed to accommodate someone else and now I have to unstuck all this).
* SQL - I need to understand the implications and nuance of various indexing strategies because... hey, PG 14 changed and now our caching approach needs tuning. Should I be using b-tree indices, or something else? Should my indices be clustered? How do I manage replication and backups? And I need to understand the tradeoffs of ORMs vs hand-rolled, vs stored procedures, time-series databases, performance impact of views and materialization. And security.
* Application level - I need to understand various aspects of security at the application layer, and balance security vs usability vs accessibility vs performance vs feedback from various program/product managers and end users. Oh, and I need to be able to troubleshoot the application in a variety of contexts. Oh... and mobile. I need to be conversant and 'well rounded' in various flavors of mobile development (hybrid vs native vs whatever).
* System updates - what? I'm still on JDK 11? WTF? Why aren't you on the current versions? We need to update pronto, because there's too many security issues we'll get dinged on!
* UI - I need to be a CSS master, and if I'm not already on the tailwind bandwagon, I risk losing my job. Or... at least, I'll fall behind as I try to incorporate the new tailwind UI work the new person did because they couldn't be bothered to learn bootstrap 5. And... accessibility - need to be an expert in that.
* Deployment - hey, I now need to be able to understand multiple deployment approaches and processes, be fluent in docker/k8s and various tools, be able to troubleshoot these self-sufficiently. Doesn't matter if these are necessarily the right tools for the situation - someone else dictated this and lobbying for anything else means you're afraid to learn new things.
And... I should be cheery and helpful and positive about all of this being my responsibility. Because when I ask for folks from another team to help, I get told I need to 'own' the project, and I can't just 'throw it over the wall' and expect someone else to do something for me. If I push back on anything, I risk getting labelled "old" and "a dinosaur" and "afraid of change" and "unwilling to learn new things".
tldr - if you actually have teams of people with related yet diverse skills, consider letting each play to their strengths, help support them in their strengths, and organize around everyone doing what they're best at. The 'well rounded' thing has its limits.
- setup cloud cron job
- setup pubsub channel
- create pubsub subscription
- add environment variables specifying the subscription
- make all that work in terraform and run migrations
And that process is different for every cloud provider.
Some projects seems to be pulling “ops” functionality into a new monolith that is also the languages native environment (deno, vercel)
Still all Linux at the hardware layer and oodles of scripting language state, HTML/CSS. The web is a bloated mess after the “throw spaghetti at wall to try and gain market advantage, boost engagement” efforts of the last 10-12 years
MBAs ran software engineering as if machines were squirting soup into cans.
App/mobile and web developers are stretched beyond belief as it comes to skills expected of them. This handbook gives a reasonable overview of the scope of a front-end developer:
https://thoughtworksinc.github.io/front-end-handbook/en/
Yet it's still incomplete, most of the cloud stuff isn't even included.
We're over-asking people. Take Spotify. Has an army of quite decent engineers. They had to actually build a homegrown platform to shield developers from the ops tooling madness. The average developer struggles to understand just git. Even senior ones do.
Front-end developers were a joke 20 years ago. Not taken very serious, not "real" developers. Now it's one of the most complicated programming jobs there are. You have to know...everything.
As for performance, there I do agree that a programmer has a responsibility.
I’d also argue that if a senior developer does not have control over their VCS, they should rethink their title.
These are tools in a toolbox - you don’t need to be an expert in all of them, but seniority requires, at a minimum, proficiency.
EDIT: FWIW, I don't value titles like "senior" and never took them to be meaningful.
In my opinion (for whatever that's worth!), no (although I would say VCS in general, not git specifically). I personally consider being able to properly version control your code to be a critical skill when it comes to development - regardless of your place on the stack. YMMV.
> FWIW, I don't value titles like "senior" and never took them to be meaningful.
I don't necessarily disagree with regard to the current state of the industry, however as a proponent of development having more professional standards I still believe that we should be attempting to find some common ground on the standards of proficiency and mentorship.
For the simple reason that on most teams, there's no other person.
The breadth of my frontend career has only kept expanding over the last 10 years, it's definitely harder than when I started.
I'm getting old and I feel overwhelmed by the creep of "stuff" that I need to know. For me, it used to be UNIX + C + bash shell was enough to survive. My only defence is to write a small Wiki page for each category of "stuff". After a year on the job, I have built an organic encyclopedia that I can quickly search to remind me about "stuff" that I use infrequently.
And, to be fair, holy shit is modern web programming complicated. I am consistently amazed by the results on a wide variety of platforms.
EDIT
Wow, the link that you shared is amazing. Very well written. Thank you to share.
Think of how much is asked from other white collar professions such as law and medicine.
Performance (in particular cold start time) is better than most other similar cloud faas products. Dev ergonomics also.
If you need something more, sure go ahead and use another tool. But very many use cases will be well served by deploy in its current state.
I agree with the sentiment, but to me it’s a shame this even qualifies as abstraction in the first place. Periodic execution of a function is extremely basic and already exists in almost every programming environment. If this needs to be a service (instead of a library call), there is something deeply wrong elsewhere, imo. We all laughed about leftpad, but at least that was native code and not “as-a-service”, dependent on networking and proprietary code on someone else’s machine.
I have nothing against Deno in particular, and I’m also not saying this is easy from an implementation perspective (due to complexity elsewhere). I’m just surprised that trivial features – from an end-user perspective – justify such a ruckus.
That said, there will be a time when your SaaS costs more than managing infra.
Periodic execution is surprisingly complicated. What happens when your node is down when it was supposed to execute and then comes back up? What happens around timezone changes and leap years? What does this thing do if a run takes so long that the previous run is still going? How do you get logs/notifications if it fails?
"Best effort" periodic execution is super easy, where you try to make a thing happen every period but it's okay if it doesn't happen as long as it does happen at some point in the near future (i.e. periodic clean up jobs, or maybe batch emails).
There's also a salient argument that you shouldn't run things inside the same process/VM if you can avoid it. It'd be a real shame if the production app went down because the cleanup cronjob went haywire and choked out the CPU.
But for exactly the reasons you outline, scheduling jobs is one of the few things where i would be eager to use some reliable, observable, carefully-engineered service.
If you want at-least-once scheduling you’d probably use a library that writes a last-completed time to your db.
> What happens around timezone changes and leap years?
For wall-time scheduling you’d need to handle it, yes. Why would a service be better than a library though?
> What does this thing do if a run takes so long that the previous run is still going?
I think we’d need either another db entry or simply prevent overlap directly in the library.
> How do you get logs/notifications if it fails?
Same way as other things in your app that fails I guess. Perhaps logging a critical event?
If you’re talking about external health monitoring then yes, you’d need to have a separate service by definition, preferably with a completely different provider/host.
- [0] Quantum, quite simple and supports cron syntax.
- [1] Oban, which is a job runner, requires a DB, but also supports periodic jobs with a cron syntax.
(probably others but that's the ones I've used)
It doesn't scale, organizationally speaking. Logic? write it in app code sure. How it's triggered or runs? Probably don't go near that. Use your job scheduler (CRON) or cloud infra to do it. Your operations team can port it, scale it, and cost optimize it without breaking a sweat.
If more sysadmin / DevOps are hired to help they are going to roast your development team if they can't actually help you. Elixir may be able to glide by some of this given how flexible its process model is - but it's not good general advice.
> We have no dedicated devops person
I understand that not every startup can afford an extra person for infra-heavy tasks, but this should not be surprising. Any tool which looks like an abstraction to you might get complex by time, and steal your time. The cloud was supposed to fix some of these, look where we are now.
This is theoretically even easier than that. Yay for a spectrum of options!
We've just been sold lies that pushed us to buy expensive clouds - and are not that much simpler than good old tools
But for the specific problem of "I wanna execute some code on a regular schedule, but I want it to be production-ready", Deno Cron does seem much quicker and lighter than provisioning a host, setting up health checks, setting up remote access controls for new devs, etc.
There are obviously many people who would find it very easy to do all the "server-work" I'm describing. I am not one of them! This service looks awesome to me.
I just `ssh` into prod and `git pull` and either `docker compose up` or `kubectl apply` or `terraform apply` or `helm update` or `argocd sync`
Unlike other people I don't think you need to hire someone directly. I do devops freelancing so you could hire someone like me. Or look online for various people that do it. I mean if its a toy app without many customers then who cares, but once you start scaling infrastructure gets to me more and more important.
Its well known how to deploy. Its easy to deploy. The footguns are vigorously and thoroughly documented. The frameworks (Symfony, Laravel) are good. They all have a solution for X (be it queues, async work, cron jobs etc) and they have turn key deploy solutions favored by their respective communities.
Its honestly one of the easiest languages to deploy with nowadays, in my estimation. Rivaled only by C# / F# or platforms like Deno Deploy or Cloudflare workers. Sometimes the most boring / mature thing is the best thing.
Part of that shift is that prior to the cloud, the development environment and production environments were very similar. By that I mean if a programmer could set up his debian / redhat laptop from the command line, then it wasn't a big jump to set up a server running debian / redhat in a production environment.
But no one in their right mind runs k8s on their laptop just to support VSCode and a compiler. Worse they could not run AWS/GCP because they are proprietary, insanely large, complex and forever changing. I'm pretty sure becoming an expert engineer in those environments is a full time job. The end result is a new class of engineers have arisen that look after the production side, and the developers just throw their code over the wall once it's tested.
I'm sure the cloud providers love this, as they have created a cohort of engineers that have invested years in learning their product, now have their wages dependent on that product being used within their organisation, and a total monopoly over that product because it can never be reproduced by anyone else. But for the industry as a whole, it looks to be a backward step. Once the problem expands beyond what a single human mind can cope with, you need teams. The communication overhead of a team means they don't have a hope of being as productive as a single person.
The share amount of complexity introduced by these proprietary cloud frameworks looks to be unnecessary. Most of it smells like technical debit created by organic growth together with an insistence on backward compatibility (don't want to give those locked in customers an excuse to move). And desktop OS's are (Debian / Windows / ...) are insecure by design, at least when compared to their phone brethren. And, their phone brethren look somewhat like cloud designs now, Phones have isolated apps with private data areas. The apps communicate via channels provided by the OS, and the availability of those channels is controlled by permissions assigned by the user. In the cloud we isolated things for performance as they could run on distance machines, whereas in a personal device we did it for security. But the end result looks similar.
So maybe one day we will end up where we started, with a developer environment looking like the cloud we deploy too. I fear I'm too old to experience if / when it does happen, but it does seem like something we should aspire to.
Sounds like you’d like to use a PaaS provider.
Heroku/Render/Fly/etc.
I know that displaying artwork is not the point of the article, but please, at least make it believable when you look at it for more than one second.
I thought it was awesome, even though it was pretty obviously AI-generated for the reasons you stated.
Namely, I ran this example.
let s = 0, r = 0;
Deno.cron("Add second", "* * * * *", async () => {
console.log(`Add second ${s++}`);
});
Deno.serve(async (_req) => {
return new Response(`Seconds Running: ${s} / Number of requests: ${r++}`);
})
So, effectively, it seems that Deno.Cron clones the JS context but any changes done to that context will not be reflected in the Deno.serve. And, if that's the case, why don't handle Cron jobs in a different flow rather than mixing them with Deno.serve? (I think it can lead to unintended side-effects)
I'd love if someone from the Deno team could provide more context here, maybe I missed something?
I just wish there it was more obvious that you are really inheriting a fresh state somehow. Maybe only `const` should be allowed at the top-level? That still wouldn't handle objects really, but it'd be better than nothing.
I’m all for making access to cloud services easier, but this screams product development not language development.
The only way I could see someone being confused about this is if they thought Deno Deploy was just a single VM running a single instance their code.
The runtime shouldn’t allow you to mutate variables in a parent scope. It probably shouldn’t allow any shared context at all. Because it isn’t actually doing that.
Everything should be passed into the cron function as an argument. It seems like this should be more like the interaction with web workers where those clearly execute in their own context.
What you're proposing alters the semantics of JavaScript-the-language, which is outside the scope of the Deno project. Pretty much everyone is already in the habit of avoiding variables in the global scope. Why should they go to the trouble of redefining the semantics of JavaScript for something that is already widely understood?
And yes, PHP's behavior is surprising too. Unless we're doing scratch PHP without any classes or frameworks, any temporary variables become non-intuitive.
The blog post touts this as a feature to reduce the amount of code to get up and running, but a library would accomplish the same thing. A first-party library could even directly integrate with Deno Deploy in the same way that this appears to.
Why pollute the runtime with something unrelated?
Because money.
They are venture funded and need to show some kind of path to profitability.
So: - What happens if the process where you called the job crashes? - What happens if the entire application crashes? - What happens if two threads/processes schedule the same job? - Should jobs be stored in memory? On disk? In a db?
Are all sort of interesting questions. Presumably the Deno runtime deals with this in a way that's opaque to the user, but that using "a library" does not, especially in a language like Javascript where processes/jobs are not really first-class.
But why not include any kind of schedule specifier that is a bit less cryptic and error prone? Is it really so much code?
Maybe someone has a package already that can wrap this or output a schedule from a human readable description or something. Maybe something like `human-to-cron`.
$schedule->call(new DeleteRecentUsers)->daily();
$schedule->job(new Heartbeat)->everyFiveMinutes();
$schedule->exec('node /home/forge/script.js')->lastDayOfMonth('15:00');
$schedule->command('foo')
->weekdays()
->hourly()
->timezone('America/Chicago')
->between('8:00', '17:00');
$schedule->command('emails:send')
->hourly()
->days([Schedule::SUNDAY, Schedule::WEDNESDAY]);
For example:
- Prefixing everything with "on" adds noise. It's debatably intuitive enough as it is.
- Demanding timezone arguments on these methods also adds noise. More often than not you just want to use system default noise since it is such an important thing that you want to control at a higher level anyway.
- It can be okay to allow edge/confusing states if the tradeoff is to keep implementation simpler. One can always rely on unit tests to keep expectations in check.
> When a new production deployment of your project is created, an ephemeral V8 isolate is used to evaluate your project’s top-level scope and to discover any Deno.cron definitions. A global cron scheduler is then updated with your project’s latest cron definitions, which includes updates to your existing crons, new crons, and deleted crons.
Having cron jobs defined in the code itself just feels weird. I get the convenience of doing things "in one place", but it's such an orthogonal concept. But I suppose combining things is part of the allure of deno any way.
Now that aside, the Flavor Flav dinosaur is the best thing I've seen all week.
There are probably some benefits of using the Deno.cron syntax for some functions, and benefits of using a config file for others, but acting like the only other option is "put it in a completely seperate codebase" doesn't make any sense to me.
Just as an example, if you have 8 nodes or whatever, your cronjob is going to get updated when the first one is deployed, not the last. The other nodes may or may not support that cronjob until they get the update.
Going the other direction, if you have to roll back a single node for whatever reason, now you have conflicting cronjob versions.
I typically want those rollouts to be separate so that I can handle failures in the app deployment before I update the cronjob.
This isn't quite that but close.
From my experience there 5 main components for larger scale system.
- Request server
- database
- queue
- background worker
- offline batch jobs
I feel like so far serverless has the first 3 fairly well developed but the last two are still underdeveloped.
But maybe I'm just not aware of other solutions?
The only issue is for background jobs you need to design it in such way to not run in to timeouts.
Which makes it slightly more complex then just having a single executable running periodically.
There is also https://www.defer.run/ which run your code on their infra and don't have timeouts. But they only support node/bun at the moment.
Currently, to get beyond the ~5 min limit per step, you'd need to deploy to something non-serverless like Fly.io, Render, or your own instance running Express.js or similar.
[1] https://github.com/bacalhau-project/bacalhau
Disclosure: I confounded Bacalhau
I took a quick look through the docs and from what I understand you can just submit docker containers to be run on a cluster. The default one is a public cluster. In some way it seems similar to Google Borg.
What I don't understand though is do you have to pay? Who provides the compute?
Maybe possible to build a vercel type service on top of the private cluster where people can just submit their code?
One tangentially related is I'm looking for somewhere to just run a python script once a day.
I'll see if I can do that with windmill.
Seems like that would be a good fit for Airplane's Schedules: https://www.airplane.dev/schedules.
It's pretty much as straightforward as deploying your Python script (and any dependencies with requirements.txt) and setting up your schedule for when you want it to run!
- workflow system
I can see from comments like vvpan's that there is a fatigue around managing services in AWS/GCP/etc, but I have gone very much in the other direction in the last few years towards bare metal servers managed with NixOS. I feel much more confident in handling scheduled jobs on bare metal with Systemd timers than tying myself even deeper into a specific language+deployment solution ecosystem.
Crazy API design!
Edit: seems like there is a WIP typed API but I still have no idea why you would lead with the terrible one...
Timezones would be nice, "This helps avoid issues with time zones which observe daylight saving time." But it also causes issues with daylight saving time. I can't run something at 9 in the morning, I need to run it 1-2 hours before-hand, calculate the offset, and then queue a run 1-2 hours later. Or I can run 2 crons and have one or the other die early. Point being, all solutions become very hacky very fast.
It would be nice if an object was passed to the handler that had a targetDate for the ideal start time would be, so runs can be easily labeled and separated.
Yes I could round the Date.now() to the last minute, however, if Deploy ever goes over the minute boundary, that's all kaput.
In a similar vein: Systemd timers have some nice features, AccuracySec/RandomizedDelaySec/FixedRandomDelay, some options similar to that would be nice (of course, with minute resolution instead) (and of course, fixed delay can be pre-calculated, but it would be nice to just say 30m and have deno runtime manage that for me)
https://www.freedesktop.org/software/systemd/man/latest/syst...
Would be really awesome if this could be used to offload long lived jobs from the request.
Defer.run is building this for vercel and it’s really cool.
I just needed to limit how fast the http requests went.
I guess I could do this with the delay and calculate how long it would need to wait.
I spent a day or two migrating a TypeScript project [-1] over to Deno from NodeJS. Here's what I had to do:
* Change all of my local imports to something that would work with Deno. That meant appending `.ts` or `index.ts` for folders, except in some cases where Deno requires `.js`
* Modify my monorepo to play nice with Deno -- an import map does this easily. Deno has documentation around import maps, but I had to figure out the solution myself. Also, import maps are currently broken in JetBrains IDEs.
* Change my NPM imports to something that would work with Deno. The most straightforward thing to do was just change `import "foo"` to `import "npm:foo"`, but this felt hacky so eventually I used https://esm.sh, which worked for some packages but not others.
* Figure out how to get Lodash working with TypeScript. It's not simple. [0]
* Use a hack to get typeorm with sqlite working. [1]
* Try out `deno compile`, only to determine that it somehow works differently than `deno run`. My project simply wouldn't work with `deno compile`, probably because my project has some system dependencies that don't get properly linked/included.
* Setup my scripts to properly lint my project. Deno has formatting/linting built-in, but it's split across many commands with different usages. For example, I can run `deno fmt` to format my entire project, but I have to give Deno a path to run `check` or `lint`, e.g. `deno check src/index.ts `
* Patch a third-party library that was setting an HTTP header to `null`. NodeJS handles this case just fine, but Deno throws an error [2].
* Attempt to build my UI (astro + react) with Deno. It seems some people have gotten this partially working, but I gave up and stayed on NodeJS for building my UI. This led to me:
* Using dnt [3] to build a Deno package for consumption with NodeJS/npm frontend. This was actually surprisingly simple; kudos to the author of the dnt library.
After all of that work, I finally was able to use Deno in my project. It was really cool! Unfortunately, both VS Code and IntelliJ with Deno are essentially unusable [4]. Or, at least, unacceptably slow compared to what I had with NodeJS.
[-1]: https://github.com/shepherdjerred/glitter-boys/tree/sj/deno
[0]: https://stackoverflow.com/a/66073607
[1]: https://github.com/typeorm/typeorm/issues/6123#issuecomment-...
[2]: https://github.com/Sansossio/twisted/issues/97
sure you can build and deploy something simply. the pain is felt when you try and actually use it on a real production app on a bigger codebase in a team. exactly as you wrote. the non-obvious but complete productivity-killing rough edges
https://github.com/denoland/deno/issues/21389 https://github.com/denoland/vscode_deno/issues/895
other fixes are being discussed.
Overall, no issues or complaints. It's always a bit odd coming from npm/node into something like Deno, but the differences are really trivial. I believe Deno has become much more compatible with Node since I really had to update the project, so the differences are probably even smaller now.
Node/Deno/Bun/etc. + npm sounds super straightforward (and it is at first). But I've thought for years that it's far easier to be productive on the backend on .NET in Visual Studio, since it's simpler to design, deliver, and maintain infrastructure.
Some developers are moving over to macOS with Rider + Visual Studio Code combo nowadays.
System level cron needs that feature built in because you're just telling it a command to run, and you're limited in how you deal with error and output handling of that command. That's not a problem when you're in the language you're using to define the action. Just catch your errors, or grab all STDOUT/STDERR with some solution and do with it what you want on success or error.
System cron is simple, by design, because as a DSL there's a benefit to not complicating it. If you're already in Javascript/Typescript, a lot of the benefits of that are mitigated by the benefits of having much more control over exactly how it functions in every care.
As an example of this, there's a bunch of cron "helpers" to deal with the shortcomings of cron's simplistic approach, such as those in moreutils[1].
P.S. Personally I wouldn't have even called this implementation cron and use the cron syntax for it, since that just makes people assume cron usage and the cron scheduling format is not an asset if you're already in a language where you could just pass in a structure with the specific fields you want set by name.
1: https://rentes.github.io/unix/utilities/2015/07/27/moreutils...