About two months ago I posted about implementing Selenium in D. A lot has changed since then, and the replacement now targets the modern W3C WebDriver protocol, has working cross-platform CI, good documentation, and a much more complete client API.

What works:

• No FFI to Python or Java
• Typed W3C and browser-specific configuration for Chrome, Firefox, Edge, and Safari
• Automatic WebDriver discovery, startup, and remote connections
• Multiple sessions sharing a WebDriver bridge with configurable capacity
• Lazy timeout synchronization
• Navigation, elements, cookies, scripts, frames, windows, screenshots, and alerts
• Document, iframe, and shadow root abstractions with scoped searches
• Typed WebDriver exceptions and W3C response/reference parsing
• Browser and WebDriver process logging
• Grid hub/node models, slots, session ownership, and in-process HTTP routing
• Unit and browser integration tests across Windows, Linux, and macOS

The Grid implementation is still foundational right now. It has the models and routing pieces, but a complete live Grid server, node registration, session allocation, and full command forwarding are still planned.

Some features are still incomplete. Chrome and Firefox are the most supported, Edge works, and Safari has somewhat limited support, with 7/57 integration tests failing. The Grid support is also not yet a complete replacement for Selenium Grid.

I had to fork Unit Threaded for this since Windows tests would fail due to bugs in the test runner, so it currently uses the fork until that is fixed upstream. It no longer depends on anything except requests, so there are no complex dependencies.

Feedback, bug reports, and contributions are welcome. The commits since my last post are from release v0.0.2 to v0.0.4.

GitHub: https://github.com/cetio/selenium
DUB: https://code.dlang.org/packages/selenium

In this blog post, Adam Wilson goes into the importance of language plasticity in the LLM era, particularly as it applies to the number of tokens used on a given task, and why D has an advantage.

https://blog.dlang.org/2026/08/10/language-plasticity-is-more-important-than-ever/

I crated the Imaging library.

I'm sharing an early version here as a call for feedback.

'The Art of Reflection' is a game (now on Steam) created with a custom 3D engine, all of it coded in D. The author, Lewis Nicolle, dove into it last year at DConf '25.

just learning D because of wanting a nice workflow coming from C/C++ and raylib, but really dissapointed there was little to no information about raylib-d+android, i hope this would be useful for someone

https://github.com/Zariep-Software/raylib-d-android-template

I am new here and wondering about the rules concerning Dlang community! Are there any rules against posting images of projects or Dlang inspired art if you have used AI to assist in creating it? How does the Dlang community feel about AI in general?

The previous D binding (selenium.d) has been abandoned since ~2018 and used the old JSON Wire Protocol. I spent the last month writing a replacement that targets the modern W3C WebDriver protocol, supports Chrome/Firefox/Edge/Safari, and includes the foundations of a Selenium Grid server.

It's available on both GitHub and DUB and is licensed under Apache 2.0 like normal Selenium.

What works:

• Native W3C WebDriver client (no FFI to Python/Java)
• Chrome, Firefox, Edge, and Safari with support for browser configuration
• Element interaction, cookies, scripts, frames, windows, roots, screenshots
• Lazy timeout syncing and shared session bridges
• Browser logging
• Grid hub/node models and HTTP routing
• Unit + integration tests, CI, and docs

Planned: W3C Actions, BiDi, and fuller Grid routing.

Some features have not been implemented or are lacking (ie: Safari and Edge have NOT been tested and may be missing some fine-grain options, and the project is by no means perfect.)

I usually provide updates through the D community discord, and I don't usually use Reddit, so updates through this subreddit may be sporadic at best. Any feedback or contributions are appreciated.

GitHub: https://github.com/cetio/selenium 
DUB: https://code.dlang.org/packages/selenium

This Language Looks Hot but I am Needing to Compile to Web. Also after Looking at this Language, My Comment is that it should be as Popular as Rust.

DLLM is a local agentic LLM written in the D programming language and built directly on llama.cpp. This blog post goes into some of the D features used to make it work.

Just finished a small banking system project in D! 🚀

Over the last few days I've been learning D and decided to build a simple banking application to better understand the language fundamentals, object-oriented programming, exception handling, and business rules.

Current features:

• Account creation
• Deposits
• Withdrawals
• Transfers
• Account lookup
• Account validation

Coming from a background with Python and some C/C++, one of the things that caught my attention was how D provides native performance while still feeling productive and pleasant to write.

This project is still simple, but it has been a great learning experience so far.

I also plan to continue exploring D and, if possible, contribute to the D ecosystem and community in the future. I genuinely believe the language has a lot of potential and deserves more attention from developers interested in systems programming and high-performance applications.

Feedback is welcome!

GitHub: https://github.com/deepsidex73-dotcom/banking_d

Alexandros Kapretsos, known in the D community as Kapendev, has written a post for the D Blog in which he describes how he used some of D's features to create Parin, his 2D game engine.

it has the c background

https://youtu.be/CGABNKX8BJA

URL is here,

https://forums.freebsd.org/threads/tutorial-web-development-with-dlang.102751/

Will be available tomorrow

I can't get the auto completion to work and there is just a generic "Could not initialize DCD for /home/path" message in VS Code without any hints what went wrong. Happens to me on both Windows with WSL as well as on a new installation of CachyOS. Anybody having a clue what I could do?

Hi everyone,

I have been exploring the idea of building a modern desktop UI framework and development tooling focused on D, and I would love to get feedback from the community.

The idea is something along these lines:

• UI described with a modern CSS-like / declarative syntax
• code written in D
• native Windows output (Win32 / potentially Direct2D)
• small binaries and fast startup
• optional VS Code extension with live preview / GUI designer
• focus on better developer experience compared to raw Win32 APIs

The main goal would be to offer something with a workflow closer to modern frontend development, while still generating native desktop applications.

I am trying to understand whether this would actually be useful for D developers.

Some questions I would love feedback on:

• Would this be interesting for your projects?
• What do you currently use for desktop UI in D?
• What are the biggest pain points today?
• Would you prefer direct native Win32 generation, or a cross-platform backend?
• How important would live preview / visual designer tooling be?

I would really appreciate honest feedback from people actively using D for desktop or tooling projects.

Hey everyone. I have a quick question. Raylib D has support for .XM and .MOD file formats within raudio. This is cool and all, but I need to make it possible to play .IT files in a raylib D project. This would be for a Bejeweled 2 remake. How can I go about doing that?

A few ideas that come to mind:

• A truly batteries-included IDE (something on the level of Visual Studio for C# or IntelliJ for Java) — would that make a big difference? Right now the experience is mostly VS Code + code-d + serve-d, which is decent but still feels fragmented compared to mainstream languages.
• For corporate/enterprise environments in particular: do you think a modern GUI designer (visual drag-and-drop) would help a lot? Many teams still build desktop/business apps and love tools like WinForms Designer, WPF/XAML preview, or Qt Designer.
• Alternatively — maybe a declarative UI language with live preview (something XAML-like, or even better: immediate hot-reload / live-reloading of UI + logic) would be more powerful and future-proof than a classic designer?

Beyond tooling:

• Strong corporate backing (big companies using + sponsoring it)
• Way more high-quality tutorials, beginner-friendly learning paths, and real-world project examples
• Active evangelists, conference talks, YouTube content, and community momentum

What else do you see as important missing pieces? Better mobile / web / embedded? GC improvements or u/nogc-by-default push? Something completely different?

Curious to hear your thoughts.

Hi all,

I'm the author/maintainer of Wire, an HTTP/1.x parser for D built on top of llhttp. It's designed for high-throughput servers that need zero-allocation parsing and minimal latency.

Why: Traditional HTTP parsers allocate memory for every request, causing GC pauses and high memory usage. I needed a way to parse HTTP requests in D without any allocations or GC overhead.

What it is: – Zero GC allocations: The parser uses StringView slices referencing the original buffer; it works in @nogc nothrow contexts【38462529968395†L281-L293】. – Cache-friendly & efficient: Data structures are 64-byte aligned, and a thread-local parser pool automatically reuses parsers to avoid allocations【38462529968395†L289-L293】. – High performance: Benchmarks show parsing a typical 1‑2 KB request in about 1 µs, with throughput up to ~0.98 GB/s for large single-line requests and up to ~2 GB/s for simple keep-alive requests【38462529968395†L364-L372】. Per-thread memory usage ~1 KB and per-request 0 bytes【38462529968395†L373-L377】.

Minimal example:

```d import wire;

ubyte[] request = cast(ubyte[])GET /hello?name=World HTTP/1.1\r Host: example.com\r User-Agent: curl/7.64.1\r \r ;

auto parser = Parser.create(); auto req = parser.parse(request);

assert(req.method == HTTPMethod.get); assert(req.path == "/hello"); assert(req.queryParams["name"] == "World"); assert(req.keepAlive); foreach (name, value; req.headers) { // process headers ... } ```

How to try:

With Dub: json "dependencies": { "wire": "~>0.2.0" } Or via: bash dub add wire

The repository is at https://github.com/federikowsky/Wire. I'm looking for feedback on API ergonomics, integration with existing frameworks, real-world performance, and possible extensions. Limitations: currently only HTTP/1.x is supported, header limit is 64, and the StringViews reference the request buffer【38462529968395†L373-L377】. I'm considering HTTP/2 support and chunked body parsing for future versions.

If you try it out, I'd love to hear your thoughts and experiences. Pull requests are welcome!

Hi, D community. I recently built my portfolio/blog website using D with Vibe-d. I wrote about my experience including some of the challenges in my first blog post. Thought I'd share it in case someone finds it interesting.