Deno Cron

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.

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

[3]: https://github.com/denoland/dnt

[4]: https://github.com/denoland/vscode_deno/issues/895

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.

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!