3 ms·

I started a small hobby project. First with TypeScript and Modern Web Dev Server (https://modern-web.dev/guides/dev-server/getting-started/ https://modern-web.d

I started a small hobby project. First with TypeScript and Modern Web Dev Server (https://modern-web.dev/guides/dev-server/getting-started/ 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 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.

WuxiFingerHold 3y ago
> I then thought, okay, perhaps time to change to Deno. What was wrong with Deno? I've done a small Rust backend (Axum) at work, so I'm ok at Rust, not really good, but ok, but I find the mental overhead not worth it. There was once a dream about "A smaller Rust" (I think withoutboats wrote a blog post some years ago). Unfortunately, we only have Go with all it's footguns or .NET Core, which I find still to convoluted (once you've lived without classes you don't want to go back). I think Typescript with deno comes closest in terms of typesafety, tooling, good enough performance and memory safety (GC and single threaded).
- _nalply 3y ago
  I never tried Deno, Rust was first.
- sam_bristow 3y ago
  https://without.boats/blog/notes-on-a-smaller-rust/ https://without.boats/blog/notes-on-a-smaller-rust/ And the follow-up: https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/
  - _nalply 3y ago
    Yeah, Rust is very complex. But I am lucky that I had several years time to learn Rust, and let me tell you: as long you don't use async, nightly nor unsafe, Rust becomes manageable, at least for me. This said, I see another big problem of Rust. I think a lot of the complexity stems from Rust does not having a real language for compile-time. I sometimes dream of a scripting language similar to Rust which has as output Rust HIR, wasm or llvm IR. This scripting language implicitly quotes all code and that quoted code gets compiled. But if you don't quote, that code executes and is able to do all the things the Rust compiler does today (monomorphizing, desugaring, effects, state machine generation, etc.). Perhaps Rust wouldn't be as stuck as today, because more people would be able to innovate in creating more well encapsulated compile-time structures. A standard library module would implement generics by monomorphizing, another one module would implement async desugaring, and so on. I also think, this scripting language have simple core primitives and use managed memory. Because it creates tailored intermediate code, in the end we would have a zero-cost native implementation. Of course, to be honest, one downside is that compile-times could be very bad... Just a dream of mine, probably a pipe dream, but whatever, I had fun thinking out loud here.

WuxiFingerHold 3y ago

> I then thought, okay, perhaps time to change to Deno. What was wrong with Deno? I've done a small Rust backend (Axum) at work, so I'm ok at Rust, not really good, but ok, but I find the mental overhead not worth it. There was once a dream about "A smaller Rust" (I think withoutboats wrote a blog post some years ago). Unfortunately, we only have Go with all it's footguns or .NET Core, which I find still to convoluted (once you've lived without classes you don't want to go back). I think Typescript with deno comes closest in terms of typesafety, tooling, good enough performance and memory safety (GC and single threaded).

_nalply 3y ago
I never tried Deno, Rust was first.
sam_bristow 3y ago
https://without.boats/blog/notes-on-a-smaller-rust/ https://without.boats/blog/notes-on-a-smaller-rust/ And the follow-up: https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/
- _nalply 3y ago
  Yeah, Rust is very complex. But I am lucky that I had several years time to learn Rust, and let me tell you: as long you don't use async, nightly nor unsafe, Rust becomes manageable, at least for me. This said, I see another big problem of Rust. I think a lot of the complexity stems from Rust does not having a real language for compile-time. I sometimes dream of a scripting language similar to Rust which has as output Rust HIR, wasm or llvm IR. This scripting language implicitly quotes all code and that quoted code gets compiled. But if you don't quote, that code executes and is able to do all the things the Rust compiler does today (monomorphizing, desugaring, effects, state machine generation, etc.). Perhaps Rust wouldn't be as stuck as today, because more people would be able to innovate in creating more well encapsulated compile-time structures. A standard library module would implement generics by monomorphizing, another one module would implement async desugaring, and so on. I also think, this scripting language have simple core primitives and use managed memory. Because it creates tailored intermediate code, in the end we would have a zero-cost native implementation. Of course, to be honest, one downside is that compile-times could be very bad... Just a dream of mine, probably a pipe dream, but whatever, I had fun thinking out loud here.