deno-arm64 VS modglot

I haven't specifically tested it but it _should_ be supported. I don't have easy access to graviton instances at this moment, but I've previously used https://github.com/LukeChannings/deno-arm64 with great success.

As long as your ARM OS is 64-bit, Deno should function properly. 32-bit _might_ be supported, but TBH we don't do any testing of those configurations as far as I'm aware.

I made an arm64 image for silverbullet, based on the hard work of this guy.

There are still no RPi builds as far as I am aware, which is a shame as there are now Mac silicon builds so not sure what the hold up is. I do wonder if there are.more Raspberry Pi's out there than M1/M2 Macs :)

Someone is doing the builds here - been using them and seem ok: https://github.com/LukeChannings/deno-arm64

I started a small hobby project. First with TypeScript and Modern Web Dev Server (https://modern-web.dev/guides/dev-server/getting-started/). I don't want bundling and for a while life was good. But then I had some npm packages that didn't support EcmaScript modules. I found a workaround but suddenly I lost motivation. I then thought, okay, perhaps time to change to Deno.

Half a year later I changed to vanilla Rust, trunk, Webassembly and some JavaScript glue code and suddenly a lot of things got easier. Of course as a Rust programmer it is easy for me. But I am also a JavaScript programmer.

This is just anecdotal but it really seems to me that the JavaScript ecosystem is so deeply flawed to burn out people. Let me list two main points which are broken:

- Types are wonky. TypeScript does a huge work to "fix" JavaScript and I love TypeScript. But TypeScript cannot fix the soundness holes in JavaScript. There will be always things that don't work out of the box.

- The missing dependency story. Node introduced CommonJS, but it didn't work on browsers. Browser just added objects to the browser's Window object. Later there are EcmaScript modules but too late. I wrote a hacky polyglot which does both UMD and EcmaScript modules, but I feel the polyglot to be brittle. https://github.com/nalply/modglot

I am still thinking about it, but I feel JavaScript could go the way of PHP. Still important, but too much a mess to be taken seriously. Perhaps in about ten years. I don't know.

One problem I encountered with ESM TypeScript development on the browser without bundling: many Node packages aren't set up for that.

You might ask why without bundling?

Sometimes you just want to start something simple on the browser and compile to JavaScript on the fly.

I tried the dev server from Modern Web [0], and I liked it. I program in TypeScript and the browser reloads whenever I save a file. Of course I could set up a bundler and for a small program waiting times are negligible. But I hate bundlers. I know it's irrational, but nowadays I program for fun so I think I should have the choice to reject bundlers.

This fails for many Node dependencies. There is a conflict between CommonJS and ESM. I am not 100% sure that what I want to achieve is impossible without forking dependencies and making a small change.

I even found a way to have a CommonJs and ESM polyglot, but this hack is extremely ugly, so my intellectual curiosity is satisfied. I named the hack modglot [1]. I don't think this is a good idea and I don't understand enough to propose something. I am somewhat dejected about the current state of TypeScript development for the browser and paused development.

Now I am programming in Rust again just for fun, but if I return to TypeScript, probably I will try out Deno.

[0]: https://modern-web.dev/guides/dev-server/getting-started/

[1]: https://github.com/nalply/modglot