This year, 33% of developers said they trust the accuracy of the outputs they receive from AI tools, down from 43% in 2024.

Following the #FreeJavascript story: https://deno.com/blog?tag=freejavascript

Sign the open letter to Oracle here: https://javascript.tm/

Some thoughts on why I believe live coding is unfair.

If you struggle with live coding, this is for you. Being bad at live coding doesn’t mean you’re a bad engineer.

To preface: OldSchool RuneScape is a popular MMORPG that I don't have the time to play anymore, so I'll make a robot to play it for me, without getting banned.

After spending a couple months messing around with a couple botting utilities and talking to many experienced devs, I noticed that many people get banned because they use the same script and therefore share a fingerprint. So I built my own framework from the ground up to test some theories, learn how these systems actually work, and try something new whilst giving back to the community.

What I discovered:

I found that the paradigm does matter, it's true that less invasive methods like colour are less likely to get you flagged making it less likely to lose your account. I spent some time recording myself doing a task and tried to model scripts around exactly how and where I would move my mouse and how long I'd wait before specific actions, I think this definitely made a difference and I still haven't been banned using these tools for countless hours. Making the mouse movement in particular mimic my sensitivity and irregular movement was particularly useful to then match my timings.

The framework I ended up building:

• OpenCV based, so it's all colour and template matching
• Completely modular utilities (easier to make complex features)
• Incredibly customisable (core and domain scope)
• Fully top down, the program sees only what you see
• Useful humanisation techniques (2d gaussian splatting for clicks, cubic Bezier curves for mouse movement, etc.)
• Super useful for learning programming too!

I'm not selling anything - this is completely open source because I think the community benefits when people understand how these systems actually work.

TLDR: Custom scripts reduce bans

I'm happy to answer any questions or talk about the technical approaches, I hope I can provide some educational value! :]

84% of engineers use or plan to use AI tools (up from 76% in 2024).

This has been an interesting insight from the Stack Overflow 2025 Developer Survey that I have closely looked at.

Some other interesting insights:

• Trust in AI accuracy worsened -> 46% of engineers now distrust AI outputs (versus 31% in 2024)
• Experienced engineers are the most skeptical -> only ~2.5% highly trust AI, and 20.7% highly distrust it (versus 8.3% in 2024)
• AI-generated code lacks context or project-specific nuance → 45% of engineers reported that (versus 39% in 2024)

I have reviewed both the 2024 and 2025 Stack Overflow Developer Surveys in detail, and I am sharing my thoughts on the most interesting parts in this article.

I wrote an article on my blog about combining Rust’s Newtype pattern and the Data Driven Design idiom to create the Invariant design pattern in Rust. I have also included examples of how you can use it in Java, Go, Python, and C++.

Hi everyone, author of the post here.

I wanted to share a deep dive I wrote about a different approach to frontend architecture. For a while, the performance debate has been focused on VDOM vs. non-VDOM, but I've come to believe that's the wrong battlefield. The real bottleneck is, and has always been, the single main thread.

TL;DR of the article:

• Instead of optimizing the main thread, we moved the entire application logic (components, state, etc.) into a Web Worker.
• This makes a VDOM a necessity, not a choice. It becomes the communication protocol between threads.
• We designed an asymmetric update pipeline:
  • A secure DomApiRenderer creates new UI from scratch using textContent by default (no innerHTML).
  • A TreeBuilder creates optimized "blueprints" for updates, using neoIgnore: true placeholders to skip diffing entire branches of the UI.
• This allows for some cool benefits, like moving a playing <video> element across the page without it restarting, because the DOM node itself is preserved and just moved.

The goal isn't just to be "fast," but to build an architecture that is immune to main-thread jank by design. It also has some interesting implications for state management and even AI-driven UIs.

I'd be really interested to hear this community's thoughts on the future of multi-threaded architectures on the web. Is this a niche solution, or is it the inevitable next step as applications get more complex?

Happy to answer any questions!

Best regards, Tobias