> Why vibe code with a language that has human convenience and ergonomics in view?

Because you would not be able to audit the code if you don't (you'll be terribly slow to read and understand the inner flows correctly and that's if these aren't so bad that would do you some brain damage).

Dang, AI is pushing us all to become managers.

The reports about our death were greatly exaggerated.

Well we need like successful technological disruptions like in 7 dimensions before this can be scale and ROI positive.

Dang. I won't be able to sleep tonight

The feeling of the hang up is so satisfying. An important piece of UX.

Plus the sound through the handset sounds like nostalgia!

Just on bad rule could more than double the cost. Or even put your project completely out of any feasibility region

What's the use case?

There's typically a pretty big difference between an interpreter meant to be embeddable and one that's not. Trying to embed V8 and keep up with V8 API changes would be a huge amount of work. I could see myself using something like this instead of Lua for some projects where V8 would be too much.

My first thought was that this could be interesting for yt-dlp?

Likely similar to something like https://github.com/mlua-rs/mlua - but wanting to execute javascript (instead of lua, and no static libs?) in the context of native rust.

The alternative might be https://github.com/denoland/rusty_v8 but without needing C++ V8.

(this is the first I'm hearing of Boa)

Correct me if I'm wrong, mlua is a set of bindings to interact with the Lua C API via FFI, not necessarily a Rust implementation.

It (mlua) would be more similar to rusty_v8.

indeed, not pure rust / requires vendored lib, but i thought it might help explain the potential use case

Bun and Deno are in totally different spaces to Boa IMO. Looks like Boa is comparable to QuickJS in the small embedded engine space.

Well the first two are runtimes built on top of JavaScriptCore and V8, respectively. So we're definitely in a different space.

QuickJS/QuickJS-NG might be a better comparison, but I think they are limited in specification conformance or at least selective in specification conformance in favor of remaining in a single file and fast. For instance, I'm not entirely sure whether they will be supporting Temporal once it goes Stage 4 because of the size of the feature, and I don't think they support Intl. But I also can't speak for QuickJS.

Doesn't matter, they were more exciting and relevant for Devs.

Seems pretty relevant- are JS Conf folks notoriously anti-rust or something?

It was a notoriously rust heavy talk, I genuinely loved it.

JavaScript scripting by users inside frameworks / applications built in other languages. Similar to https://github.com/dop251/goja for Go or https://github.com/sebastienros/jint for .NET

There is a Rust based browser project ongoing that can use this (if its not already).

No autosaving. That's the wrong way to try to be minimalist.

Yea, that’s something that stuck out to me as well. Seems like auto save and version control could be done in a minimalist manner whist improving QOL

I really enjoyed using CherryTree on top of Git with automatic commit and sync. Getting readable diffs (via using XML as an output format) is meaningful.

Thanks!

Smalltalk is among the top most ergonomic ways to model concepts in a computer (capacity to model essential complexity) because the CPU got abstracted and compacted in the VM.

But destiny made CPUs win and now we're using AI to chew their accidental complexity for us.

The irony many of us used to joke about COBOL, and now we are entering book sized prompts into a little chat window.

Haahahah true! Well put.