njoyablpnting's comments

Clearance jobs will be some of the highest targets for automation. For one, the US government has already shown a willingness to work with AI companies in the most sensitive fields. Also, sandboxing is getting to the point where if you know what you're doing it's no more risky than relying on another human. The obvious benefit of not needing to worry about an LLM being a Chinese spy is just too good to not optimize.

I'm using my own fork of https://github.com/motion-canvas/motion-canvas

It's not really designed for the animation code to be dynamically changed on the fly, but I've hacked together this feature in my fork.

> Interestingly I have the exact opposite experience, I've reported issues both in the WebCodecs specification and the Chromium implementation, in all cases they were fixed within weeks. Simply though reports on public bug trackers and it wasn't really a major issue in any instance.

That's fair, they are responsive most of the time. I do have one major rendering issue in particular I've been waiting on with no movement for months, so I might be biased.

> We're doing SOTA quality video rendering with WebCodecs + Chromium with millions of videos produced daily, or near SOTA if you consider subpixel AA a requirement for text. In general for pixel perfection of text, especially across different browsers and operating systems, you can't just use text elements in DOM or in canvas context, instead text needs to be rasterized to vector shapes and rendered as such. Honestly not sure about potential jittering when animating text, but we've never had any complaints about anything regarding text animations and users are very often comparing our video exports with videos produced in Adobe AE or similar.

So you use a library that takes in text and vectorizes it to canvas shapes? That could work in theory, do you have a demo of this?

> On Remotion, yeah, not sure it's the right fit, but honestly the sheer capability of models at writing code these days has surprised me.

Just to clarify I still think code-driven graphics is the correct approach, but in my case I opted for a different library with a more powerful imperative API.

> Also noticed they have an experimental client-side rendering version built on mediabunny

Yes, I've tried it out, it was a non-starter for me because it only supports canvas-based components, and Remotion didn't seem to have good support for text on canvas because they rely on HTML for most of that.

> On WebCodecs, there are a fair set of challenges, but we wanted to take the bet

Totally understand the appeal and immediacy of a browser app, I was lured in by that too. For what it's worth I've reported showstopping WebCodecs issues in Chromium and there's basically no indication they'll get fixed on a predictable timeline.

Another issue I ran into that I just remembered is animating text on canvas. It's basically impossible to get pixel-perfect anti-aliased text animation using a canvas. I would have to dig up the exact details but it was something to do with how browsers handle sub-pixel positioning for canvas text, so there was always some jitter when animating. This coupled with the aforementioned WebCodecs issues led me to conclude that professional-quality video rendering is not currently possible in the browser environment. Aliasing, jitter and artifacts are immediately perceptible and are the type of thing that users have zero tolerance for (speaking from experience).

This is not meant to be discouraging in any way, I've just been very deep into this rabbithole and there are some very nasty well-hidden pitfalls.

Very well-executed version of this. I think this is the right interface for video editing going into the future.

I've spent a bit of time on something related, AI-generating motion graphics videos from code, also editable/renderable in-browser. Here's a few things I ran into:

- I see you mentioned being aware of Remotion in another comment, in my experience Remotion is not the right tool for adding motion graphics to what you're building. There's a few reasons for this, but basically declarative markup is not a great language for motion graphics beyond anything very basic. Also, in-browser rendering is only going to work with canvas-based components. I also wasn't a huge fan of their license.

- WebCodecs may not be as reliable as you think. I've verified several issues where I get a different output across browsers and operating systems, and even different permutations of flags, browser and OS. Is there a reason why your tool needs to be browser-based?

> I tell the AI what I want, walk away from my computer for four hours, and come back to find the work done. Done well, done better than I would have done it myself, with no corrections needed.

I use Opus 4.6 all day long and this is not my experience at all. Maybe if you're writing standard CRUD apps or other projects well-represented in the training data. Anyone who has written "real" software knows that it's lots of iterating, ambiguity and shifting/opposing requirements.

The article seems to be written in order to feed into some combination of hype/anxiety. If the author wants to make a more compelling case for their stance I would suggest they build and deploy some of this software they're supposedly getting the LLM to perfectly create.

Yes, it's a very useful tool, but these sort of technically-light puff pieces are pretty tiresome and reflect poorly on the people who author and promote them. Also, didn't this guy previously make up some benchmarks that turned out to be bogus? https://www.reddit.com/r/LocalLLaMA/comments/1fd75nm/out_of_...

This is super cool! Would love to see how you hooked up Ruff and ty.

Just curious, why not use Pygame?

Scratch abstracts away a ton of stuff to allow the student to focus on logical building blocks that mirror the mental model one might have when writing a real program. I'm wondering if keeping a lot of those abstractions when transitioning to text programming is educationally useful?

For example, it might not be clear that @on_forever is really just a loop, etc. One thing I've noticed when teaching beginners is that when you introduce a library/framework at the same time as a language, they start to form a model of the language that often wrongly includes parts of the library.

This is why I think Pygame is so useful for education, it sits at just the right level of abstraction for learning. In Pygame, your game loop is just a loop, handling input is just conditions in your loop, etc.

Regarding rewriting the AST to avoid async/await, do you have some experience or evidence to suggest that these should be abstracted out? I can see an argument for both sides, so just wondering how exactly you arrived at that decision.

Also, I tried a program with an infinite loop and the UI became unresponsive and I had to close the page. This indicates to me it's running on the main browser thread. Kids (and sometimes senior engineers) write infinite loops occasionally, so I highly recommend executing the user's code in a worker to prevent the harsh experience of losing your work suddenly.

Here's a plugin that he commissioned that you can play with: https://gitlab.com/then-try-this/samplebrain

It's hard to overstate the influence RDJ has had on modern music. Maybe even more impressive than his ability to develop multiple compelling distinct styles is the way he has taken existing niches, completely mastered them and then pushed the boundaries all over again.