I love HTML Canvas. I even wrote a book about it once. Canvas is good drawing API and it runs everywhere. However, despite the magic that is the Canvas API, it can still be tricky to use when it interacts with CSS. I often have people ask me how to make their canvas fill the screen, or resize with the window, or to have a fixed aspect ratio but still scale to fit inside the window without overlap. All of these require understanding some internal details about how Canvas works. So let’s dive in.
I’ve been teaching my nephew to code for the past few years and we did a game jam together over the winter break. He said to me: “Uncle Josh, you sure can code fast.” I reminded him that I’ve been programming for 30+ years, and one day he’ll be even better than I am.
In the last couple of years I’ve seen a lot of lamenting about the browser mono-culture. I even wrote about it myself. Some complains focus on how complicated the web specs have become. So big that only a few companies can implement a browser from scratch. I think these complaints are misplaced. Even if the web platform didn’t have such a large API surface it still wouldn’t matter. You can’t build a large scale browser with large marketshare. The browser market would still be a monoculture. You can't solve a business problem with a technology solution. I also don't think that replacing the web with something smaller like Gemini is the answer.
I've been working for a while on some new ideas around the future of programming, but I haven't done a great job of sharing these with the world. It's not science if you don't publish your results, so here we go.
How can you draw a filled rectangle fast? By making it not slow! Great if you are using a GPU to accelerate rectangle drawing for you, but what if you are doing it oldskool with an in memory frame-buffer? You'd probably write some code like this:
Yeah, it’s been a while, but not forgotten! In between moving homes and jobs and pets I found to do a new release of my IdealOS prototype. And not just a new release, but an actual full rewrite! Let’s take a look at what’s new in IdealOS Mark 6!
It is often mentioned in Hacker News comments and the Twitters that it’s a tragedy that the web ecosystem is now dependent one only three renderers: Chromium, WebKit, and Gecko. Every time a new browser is announced I see comments like:
After a few weeks of work I’ve been able to get Tetris to boot and play. I can also run Dr Mario to enter the play screen but all of the pieces are hidden for some reason.
A week or so ago I ran across a video called The Ultimate Gameboy Talk, and indeed it was. Inspired by the simplicity and elegance of the original Gameboy, I decided to try my hand at building an emulator. A week later I have this:
I have long loved my series of TV streaming Roku devices. The UI isn’t as fancy as the Apple TV, but it’s very stable, very responsive, and far easier to use than Apple’s insane remote. Historically the Roku SDK was really only targeted at streaming TV apps (which makes sense), but there wasn’t a way to write games or other high performance apps using anything but Roku’s own BrightScript SDK. However, about a month ago Roku announced the Independent Developer Kit that lets anyone build and side load apps onto their own Roku’s using C++ and OpenGL. I was thrilled but bummed that you have to run the SDK on Linux. However, it’s just some command line scripts, so maybe we could run it in a Docker container. After a little experimenation I figured out how. Let's dig in.
In many of my projects I need to parse something, usually a text based language. Sometimes it's inline docs. Sometimes it's a custom DSL for generating code. And sometimes it's markdown files. My goto tool for this type of work is OhmJS, an open source parser language for JavaScript based on PEGs.
It's been a whole lot of work to get to Mark 4 of Ideal OS. My real goal for this sprint was to have something that at least visually looks like a real operating system. What do you think?
As I mentioned before I’ve gone back to working on the bottom half of Ideal OS. So far I’ve got a messaging protocol, a central server, a few tiny apps, and three different display server implementations. The version I’m calling Mark 3 looks like this:
I've paused my work on Filament for a while to go back and do some more research into low level graphics for IdealOS. As part of that I wanted to emulate a Raspberry Pi on my Mac. The short version is: yes it can be done but it's useless for graphics.
I'm happy to announce Filament 0.4. If the previous release was about new language features, this one is about apis and docs. A language isn't useful if you don't have APIs to do stuff with.
I’ve been working a lot on new graphics apis, and new examples to exercise those apis. Things like turtle graphics, which are great for learning recursive functions, and image pixel processing, which are super fun and closer to Raytracing and GPU shaders than you might realize. However, along the way, I’ve discovered some missing features that have forced me to make some tough decisions. Today let’s talk about conditionals, jumps, and lambdas.
Filament is the humanist programming langauge I've been working on. Filament's focus is entirely on computational thinking and improving the way we use PLs, not on the implementation or performance. It is for thinking about problems, not producing software artifacts. It should be easy enough for children to use, but powerful enough for domain experts. Think of it as Mathematica for kids, scientists, and artists.