deno_std VS turbo

For reference (for the issues you mentioned): 1. This issue was opened almost immediately to solve the weird .only function not working https://github.com/denoland/deno_std/issues/2979 2. That looks weird to me, will get back to you on this one since it should work I think 3. Generally polluting the global namespace isn't great, but because we're only polluting the namespace of a module (and we choose what parts to import), I personally find it quite freeing. I entirely understand how that might feel awkward. 4. you CAN specifying only writing to certain directories! --allow-write=/path/to/dir would allow that!

At least for the ones related to trees, it's just a renaming. Below is a link to the PR. When I initially implemented these trees, I chose the names BSTree and RBTree to keep the names short. I'm guessing the person that proposed renaming them did so to make it more obvious what they are.

https://github.com/denoland/deno_std/pull/2400

The standard library is separate from the runtime. It wouldn't break backward compatibility if you were to update. For example, if you were importing RBTree and upgraded Deno to the latest release, it would keep working just fine. You would only really need to switch to using RedBlackTree instead if there was a change made to it that you wanted.

I think the only time you would need to update your standard module imports to be able to use newer versions of the Deno runtime if the standard module were depending on runtime APIs that have a breaking change.

It is like Demo deprecating fs.exists().[1]

[1]https://github.com/denoland/deno_std/discussions/2102

This was fun to read through.

I would need to profile the code, but the startup time being bad for Deno seems like maybe a combination of the code in here being unoptimized:

https://github.com/denoland/deno_std/blob/0ce558fec1a1beeda3...

(Ex. Lots of temporaries)

And usage of the readFileSync+TextDecoder API instead of readTextFile (which is also a docs issue since it's suggests the first one). It seems the code loads the 100MB into memory, then converts to another 100MB of utf8, then parses with that inefficient csv decoder. The rust and go versions look to be doing stream/incremental processing instead.

But it there's some talk to reconsider it

Sorry to hear that. I want to provide expect API in deno_std in the future: https://github.com/denoland/deno_std/issues/1779

I just migrated the module to Deno and rewrote the test cases using the Deno test runner. Also contributed a bug fix to the test runner that I encountered during the migration. An npm version is still available and automatically generated from the Deno code via a small bash script (rewriting imports, adding an index.ts, etc.).

Much of Node.js is written in C, yet it's still called Node.js.

Deno has some JavaScript/TypeScript in it. On GitHub https://github.com/denoland/deno is 22.8% JavaScript and 13.2% TypeScript, and https://github.com/denoland/deno_std is 68.2% JavaScript and 31.6% TypeScript.

So to me it's misleading about the name, but not about what Deno is written in.

I also recommend checking out the docs for Stimulus and Turbo to familiarise yourself with all their features and the APIs used in this series.

https://github.com/hotwired/turbo

Turbo 8 remove typescript without using JSDOC

Experiment using Turbo to drive front-end behavior: "Turbo 7.2.0 (currently in beta) allows you to define your own Stream actions which can be any JS code you want. By combining a custom Stream action or two with web components, you can essentially drive reactive frontend behavior from the backend stupidly easily. Loooove it! 😍 […] For a turnkey example, you could check out https://github.com/hopsoft/turbo_ready " —Jared White on The Spicy Web Discord

This handles disconnection (as could be done by any destructive change to the DOM, like navigating with Turbo or htmx, I'm not even talking about using the element in a JavaScript-heavy web app) but not reconnection though, and we've exited early from the connectedCallback to avoid initializing the element twice, so this change actually broke our component in these situations where it's moved around, or stashed and then reinserted. To fix that, we need to always call addSparkles in connectedCallback, so move all the rest into an if, that's actually as simple as that… except that when the user prefers reduced motion, sparkles are never removed, so they keep piling in each time the element is connected again. One way to handle that, without introducing our housekeeping of individual timers, is to just remove all sparkles on disconnection. Either that or conditionally add them in connectedCallback if either we're initializing the element (including attaching the shadow DOM) or the user doesn't prefer reduced motion. The difference between both approaches is in whether we want the small animation when the sparkles appear (and appearing at new random locations). I went with the latter.

If you think you have seen enough Rails magic, you are mistaken my friend. Rails have a new trick up its sleeve: Hotwire. And with the magical Turbo tool that comes with it, you can create modern, interactive web applications with minimal, or sometimes no JavaScript at all, providing users with an incredibly smooth experience.

There is also Turbo and the frameworks who adopt them, Ruby on Rails, PHP Symphony and possibly others that solves the same issue in the same manner as HTMX. And the choice for HTMX is only a personal taste in this, but you should definitely learn about this, this is as cool as HTMX!

Most controversially, the Turbo framework dropped TypeScript support altogether after assessing that strong typing was the culprit behind poor developer experience.

Turbo[0] has been solving this for years. Quite the contrary, front-end frameworks have started to think "sending JSON is good, but actually sending HTML could be great!".

DHH's presentation[1] during Rails World 2023 is quite interesting in that regard, I recommend you give it a go (start around minute 16). I am actually very excited with his vision of the web.

[0] https://turbo.hotwired.dev/