This was a Rust learner project that I worked on for a while. A canvas based game for the web written in Rust, compiled to WASM. The game is inspired by Factorio and you create belts to move parts from one machine to another, creating more complex items as you proceed through the game.
This is a web app that is chess board with all the rules implemented and support for importing and replaying games. I recently fell into the chess rabbit hole and part of it led to being curious about training a neural network to play chess. Nothing ground breaking but I realized this did require me to have a move validator and this ultimately led to Yacge because I needed to visualize the rules and validate that they were working as intended. The tool is mostly a stepping stone for the training work but I spent enough time on it to just release it as its own thing, to whom it may concern.
Langton Ant meets Genetic Algorithm meets implicit emergent gameplay meets trying to code Rust. This is my first project in Rust, something to get started with. It's an idle game. I wanted to play around with a simulation that just ran, you plug in some parameters and the ant tried to get as far as possible. Some inspiration was boxcar2d (google it) but I was ultimately not able to capture the same GA feeling for myself with this project. The result is a weird pseudo game with a subtle story line where the genetic algorithm is baked in and nobody has any clue what is actually going on. But it was fun. Written for the CLI, then exported to WASM and runnable in the browser. (That was part of the point in the first place; writing some Rust and getting it to run in the browser)
Mope is a failed attempt at creating a zero effort sound and complete type checker that targets a subset of JS. It is broken because there are some inherent problems with the current model that require a vastly different approach in some areas and because even if that gets fixed, it would still only work on a very strict subset of the language which may not be practical. Despite being broken, I got pretty far with this model and for a long time it looked very promising with very interesting problems. JS just turned out to be a bit too dynamic to be captured like this and I had to make a hard decision to cut my losses and bail on the project. Sources on https://github.com/pvdz/mope
Tenko is my last iteration of ZeParser, a fast pixel perfect spec compliant JavaScript parser in JavaScript. I spent a lot of time and effort polishing this tool and over the years had a lot of fun (and some frustrations, sure) writing this parser. It is spec compliant up to 2019 and even allows you to select intermediate spec targets, for example allowing features that were available in 2017 while disallowing newer ones. I very aggressively tried to optimize performance on this at the time. Ultimately the AST building should have been different since that is what cost more perf than anything else. But at that point I just needed to ship it and move on.
A flexbox web gui for creating css flexlayouts and exporting them to html. Mostly a quick hack to get something working for myself. Repo at https://github.com/pvdz/cssflexboxgui
I ran the JS1k competition and this was the last edition, number 11, the 10th year. I decided to stop it at 10 because it had diminishing interest and the time I had to invest into running the competition was conflicting with real world responsibilities, too much.
Xcode is a Redcode implementation for JS1k to play CoreWars, where two programs ("warriors") battle to the death. This demo features all the instructions for the ICWS'88 standard of Redcode (https://corewar.co.uk/standards/icws88.txt), a game originally from 1984 where two programs have access to 11 instructions and roughly 8000 cells of memory and have only one goal: to outlive the other program within 80.000 ticks of game time. The iterations to get to this demo can be found in this repo: https://github.com/pvdz/js1kdemo2019 and the blog post to describe the steps in detail are in https://pvdz.ee/weblog/426
This app simulates card draw in Hearthstone a bunch of times and reports how often when certain conditions are met. These conditions can be added through UI.Basically it's easier to simulate certain conditions than do the actual math because the mulligan phase messes up calculating odds. There's also the condition where player two starts with an additional card. Oh it's all a mess. So a simulator was going to be much easier to get "reliable" data. And so I wrote one. Code on https://github.com/pvdz/hs_draw_sim
I run this JS code golfing competition. It was the tenth edition of JS1k (the ninth year).
This is a finite domain constraint reduction system and solver combined. I had a lot of fun working on this project. It ultimately tries to reduce a given constraint problem down to the minimum through static analysis and then attempts to brute force a result. Many-if-not-all logic puzzles can be represented as constraint problems, which can then be solved by a solver like this one. The readme has a few examples. The source can be found on github: https://github.com/pvdz/fdq
This was a quick fuzzer I wrote to fuzzy test UglifyJS, a JavaScript minifier. I ran into an obscure bug and eventually got persuaded to write a fuzzer to help out. This fuzzer has a simple setup and can be easily adapted to any environment or any purpose and it has already led to uncovering a few UlgifyJS bugs.
I run this JS code golfing competition. It was the ninth edition of JS1k (the eight year). Most of the legwork had already been done for previous years and this year I a bit pressed for time so kept most of it the way it was. It was a good competition.
This is a simple tool to compare one logic formula to another one with logic truth tables.
This project will automatically solve any solvable Tectonic puzzles and give you all the solutions there are possible, provided it can be solved at all. It uses the finitedomain project in the back to find all valid solutions. Tectonic is a logic puzzle that is related to the more known sudoku puzzles. The solver was a fun small project to dogfood the finitedomain project with.
While working on finitedomain I encoded domains as bitwise fields. Since there was no way of counting bits fast in JS (there is now) I ended up with a large switch for it. This led me down the rabbit hole for trying to find a perfect hash for determining the number of set bits in an integer. One path had me writing a program that would try to find me this perfect hash. Ultimately it ended up being a combination of a fuzzer that hashes a set if input numbers and will try to find the optimal lookup table using genetic algorithms. While not really able to beat the existing algorithm for popcount, it is still a mesmerizing project to see at work.
A tool for writing queries to efficiently search through tokenized languages. It is language agnostic, the web example can do JS, CSS, and regular text. A goal was to make it easier to rewrite code by searching through tokens. You could see this as work that builds on experiences with Zeon (scroll down) and ZeParser. I have always maintained that for most language manipulation cases you can make do with tokens (and meta data). This project proves that point and tries to make this more accessible. Althoug in all fairness it is probably too complex to call it that.
Takes an old particle demo (pvdz.ee/project/wk) and uses a similar approach to create a 1022 byte demo. Went through some lengths to record my progress and as a result the entire golfing process can be followed by reading the commit log for the repo I setup for this. The demo isn't very fancy in particular, if you know how particles work, but the golfing part has some cool tricks.
I run this JS code golfing competition. It was the eight edition of JS1k. This year I spent two weeks on ironing out quirks with the auto-generating scripts that were responsible for regenerating the entire site. There were problems and now I can regenerate the entire website and all years with just one one button and that is great. In addition I made some changes to the boilerplate to support some commonly requested features.
This is part of work for a client. While `finitedomain` was initially a port of FD.js to CoffeeScript, I've completely refactored, cleaned up, and optimized it. Recently ported it ("back") to ES6. Still in the process of optimizing it, there is a lot of room for improvement. Finite domain solving is a black art on its own. It is the process of reducing a set of options for variables such that it satisifies all the constraints that have been defined. It's a lot of fun to streamline and improve the library and to squeeze performance out of it.
Yohoho a streamers life for me. Okay not really. Played.today was an experiment to see whether I could record and publish good "Let's play" videos of different games. I managed to do this in a streak of 100 videos (in 100 days). On top of that I recorded 200 daily runs of The Binding of Isaac since its release in november 2015. The first half was commented, the second half was not. In the end the lets play content I produced did not live up to my own expectations and I discontinued it. The isaac daily runs are fun but hardly competitive in a fair way so after doing every daily for 200 days I moved on. It was a fun experience and I learned that it is not that easy to create good content.
This was written for a client. This is a full fledged parser for regular CSS (CSS3 and a bit of CSS4) and a custom super set of CSS called GSS (which is constraint driven CSS). This was written for The Grid. It is open source. The GSS goes on top of regular CSS and the parser needs to process it right to left (whereas CSS is processed left to right) so that was an interesting experience.
A talk I did at FrontTrends '15, a frontend conference in Poland. I explain in depth how I transformed my regular and synchronous JavaScript into a streaming parser that can arbitrarily parse any amount of code and yield while it has to wait for more. Note that this was done in the middle of ES5 era and worked in any browser.
I wrote a script that transforms a full fledged JavaScript parser, ZeParser2, from "normal" synchronous parsing to a fully streaming parser. In ES5 code. Meaning the tokenizer can wait at arbitrary points while parsing and suspend the parser while it waits for more input. It can continuously parse code without running out of memory by streaming out tokens and not storing them. It's quite impressive.
VR is the future and I have explored a little by creating this "cardboard" demo. Nothing you'll drool over, basically a raycasting demo with some "cardboard" love, and a "barrel distortion" applied to it. You can load this demo in a browser, pop your phone in a cardboard holder, hook up a gamepad, and walk around. There are some debugging options to play with and screw your mind if you want.
While doing some research in VR I wrote this tool to visualize how mathematical matrix operations work. It's a simple tool with an even simpler UI (as is the norm for me) but it can help with figuring out what the result of a matrix operation is.
I was busy with learning webgl for VR purposes and decided to see how hard it was to minify a webgl demo. Turns out it's quite hard but completely different. You start working to minify shaders and how you pass on parameters and much less so the actual JS (though still a little). The position of the mouse affects the background color and the train colors. The webgl demo was actually quite fun to build.
I run this JS code golfing competition. It was the seventh edition of JS1k. The past year I had taken some flack the frameset approach I had picked for the website. So I dedcided to spend some time to rewrite it. The biggest problem was not so much getting it to work, but also porting all the old demos to the new environment. Many hacks and many reliances. Obviously managed to get it to work in the end.
A talk (in Dutch) I gave at a local meetup of Fronteers. I talked about Surfly, how it works under the hood and why it's to date still the most impressive project I've ever worked for / on.
A proof of concept project to generate code that could mimic the ES6 yield keyword in ES5 semantics. The rewrite is messy and while fairly generic, there are better and more solid tools out there. This was never meant for production anwyays, it just works. UnYield was kind of a precursor for transforming ZeParser2 to a streaming parser.
I run this JS code golfing competition. It was the sixth edition of JS1k. Previous year the admin part of the site as finally written as to make my life easier. But somewhere between competitions the host had a server problem and my caches were inadvertently wiped. No huge problem but the generation scripts were not ready for this situation so I spent a week or two writing auto-generation scripts for the entire website. In the end I was able to regenerate the entire site from automated scripts (everythign on js1k is static html).
My talk at Fronteers'13, a Frontend conference in the Netherlands. The talk is very similar to the one at JSConf. I only tried to be more clear about what was going on. Turns out I lost most of the audience within two minutes anyways, but the talk was well received regardless (in some ways even more so than at JSConf).
My talk at JSConf.us '13, a JavaScript conference in the US (this time in Florida). The talk describes the project below and explains exactly how it works. I basically write the library from scratch in a live coding demo, going step by step through the process of how it works exactly.
This library allows you to translate regular JavaScript in such a way that you can actually recompile it while it running it. Your changes are immediately picked up and shown, with state and everything preserved. The source code for this project can be found on github/pvdz/recompiler and the demo is very straightforward.
My talk at OnGameStart '13, an HTML5 gaming conference that was held in New York. This talk is about the tricks game designers and developers can use to get away with certain problems or to create certain effects. Shows the mind cannot be trusted.
I run this JS code golfing competition. It was the fifth edition of JS1k. Since the theme of last year was such a hit I tried going for something generic, again. It kind of worked. Maybe not as many submissions, the compo had plenty of them. This was also the first year where I reworked the backend, created an admin panel completely in AngularJS. Mainly to see what that was like in an actual project. There was a lot of work to get things more automated. Fun times.
This tool visualizes how Source Maps work. The Source Map spec allows you translate source code, but to have browsers map positions in translated source code back to their original positions in the original source code. This way you can debug other languages in the browser with the normal debugging tools, even when the actual code runs JS. Say CoffeeScript or maybe even Python.
Kind of the replacement for my tag literal project (below), this project reads your JavaScript source code and translates custom DOM syntax to actual JS. See the interactive demo of the tag literals project below to see how cool that would be.
This is a JS profiler slash code coverage tool that is easy to set up and use. It has no other dependencies but a decent browser. After transforming your JS to be able to track which parts are executed, it will run it and display the results in a heatmap of the source code. This all happens live, real time results. You can also work with two tabs. One tab would run the code and the other tab would show the results. v1 was a two day project so it's not exactly the cleanest code I've ever written. But v2 looks pretty good :) Note: this was long before react and all that goodness!
The Gonzales project is about parsing JavaScript as fast as possible. Anything is allowed as long as your parser does all the work and does it in JS. This was my response to comparing ZeParser to other JS parsers while ignoring the overhead each parser makes when it produces a parse tree. This project tries to level the playing field.
The successor of ZeParser. This is currently the fastest (ES5) JavaScript parser available. It is very clean and to the point. There is no parse tree and no meta information "out of the box". The parser is very easy to read and extend though, which makes it perfect to use it as a basis for whatever it is you need. It comes with a full test suit.
When 0x10c was announced I was immediately enthusiastic about the idea. When the CPU spec was released I quickly created an emulator for it. This was never really finished (just like the game wasn't, or maybe because of it). It's mainly up here for reference, and your viewing pleasure.
This demo for JS1K is an interpreter for the Whitespace language.
Wouldn't it be great to simply create DOM elements in your JS without tedious DOM syntax? So much code is required to setup something that's very simple and consise in regular HTML and CSS. Something like this was started with E4X. It also died there. So this is an experiment with a very simple API. You can use this live coding experiment to see how you could use tags as if they were regular expressions, and see what it would translate to in DOM syntax (on the right). That syntax will do exactly what you want it to do. Try it!
I run this JS code golfing competition. It was the fourth edition of JS1k. After a bit disappointing results, compared to the first, of the previous year I decided to go with a generic theme; "love". That worked, there were many submissions. I also received a redesign of the site which I (only) applied to the new competition. During this compo the backend was still crap and maintaining the competition was still a lot of manual effort.
This project was created for a workshop I did together with Kornel at FalsyValues. It was a two day workshop and we explained how to create a Mario game on the second day. This project was hacked together in about three days. Includes a simple editor that uses localstorage. I did create an extended version of this project, but that was never published.
A talk I gave at JSConf.eu '11, a JavaScript conference in Berlin. I revealed and released Zeon there. This talk goes deeper into it.
This is my first serious (ES5) JavaScript parser. It was used as the basis of Zeon (see below). Written completely in JS it runs both on the client (browser) and server (nodejs). It was succeeded by ZeParser2 (see above).
Zeon is the result of me playing around with parsing js. It is a visual static analysis tool for JavaScript / ECMAScript which completely runs on the client side. It shows you where possible problems might exist in your scripts by way of visual cues. Most JSLint warnings are supported, some type inference is built in and some minor editor bits as well.
I run this JS code golfing competition. It was the third edition of JS1k. The theme was based on the theme of JSConf.us of the same year. The subname "dysentery" was later changed to "trail". I was still running this with simple custom backend scripts. That was a lot of manual labor. Good times.
This was the second edition of JS1k. It was probably too soon after the first one and the only one that was "out of order". Regardless it had some pretty cool demos. It was the first one with a theme.
JSGoodies (js.gd) is my linkdump and personal link shortner service. I read a lot of tweets and see many interesting links pass by through twitter or other sources. This is where I dump them, in order to keep my own twitter account from being an ever bigger fire hose ;) There's no rss, but you can follow it through @jsgoodies on twitter. Whenever I post anything, it gets pushed to that account automagically.
Coercion is the source of a lot of confusion for people who are new to js. In fact, it's the source for frustration even for seasoned scripters. This tool aims to help you explain what happens behind the scenes of the js interpreter when it compares two values. It follows coercion rules as laid out in the ES5 specification.
This is the result of a hackathon. 24 hours of coding with three people. We were inspired by Syndicate (hence the name Enterprise ;). This is the game as it was when we presented it, after the hackathon.
To end the discussion of whether to add a semi-colon or not in js, I've created an ASI test. It uses my js parser and serves you a few small code examples, without any semi-colons. Can you figure out where the parser will insert a semi-colon? The test has proven to be very difficult, as was obviously intended. So whenever you land into a discussion concerning the use of semi-colons, just make them do this test to win that argument. (Note that this test usesthe very slow esparser (below), and not ZeParser (above)...)
This is an ECMAScript parser (or a JavaScript parser) written in js. While very slow, it was my first successfull attempt at writing a JS parser. It uses the original CFG (a way to specify a language) as input and validates the JS that way. It does a full exhaustive recursive parsing of the input source code and visually displays the syntax parse tree so you can learn from it. While slow, it's very valid. In fact, I still use this to verify minor syntactic edge cases to this day. For my fast parsers see the ZeParser line of parsers, above.
This is a generic CFG parser in javascript. Uses a custom syntax that's close to an actual CFG (so converting it should be easy). You can use it to turn any cfg into a digitally usable format. This is part of my ecmascript parser. The live demo (and static version) also serve as a very good ECMAScript production reference.
This is my own "submission" (I wasn't allowed to actually compete ;) for my js1k competition. It's a brainfuck interpreter. I've basically compressed the code from a small 3k script (already using relatively short notations) down to a 1k script. Used a lot of hacks for it. Be sure to read the blog post about it as well.
I run and maintain the JS1K competition. I started this competition in response to the, in my view, ridiculous rules set for the #aea10k competition. The goal is simple, create a pure js demo and keep its size under 1k. A simple shim was given and there are very little rules otherwise. There were over 700 submissions and 380 competing entries in the first year. The site contains many gems, all in 1k of JavaScript.
I like creating fractals. They are simple instructions to do something that looks very complex. The result can't even be seen in the code, only in the output. This specific fractal is the Dragon fractal, or the Jurassic Park fractal. The fractal represents the folding of paper, but the algorithm I've created never reaches the middle fold and so it spins around.
This is my first experiment using the video tag. Uses canvas and video to convert a regular video to an ASCII video. It optionally also uses web workers. A lot of optimization has gone into this project. You can upload your own video and share the results of converting your video. You can read more on the blog post or start converting your own video now.
Used to be my own DOM library. Adds syntactic sugar for manipulating the DOM and applying styles to elements in a time where jQuery was still young. Includes a fade and roll animation. It uses chaining, which allows for neat code. Would not recommend using it anymore. It is not being maintained.
A tile based engine in an era where canvas was still very new. Comes with a complete client-side tile and map editor, which saves everything to local storage. The tiles are actually img elements which was part of the experiment. You can move the actor around and the scene will start scrolling when it reaches an edge. The only place where canvas is being used is the tile editor.
Demonstration that browsers were ready for pure JS based animations (in a time where browsers were still quite slow). This demo is ported from a flash demo. Does not do anything special. Fun fact: the tree would move left-to-right in Opera when I initially released this. They fixed that eventually.
Simple demo demonstrating the parallax effect using divs. It uses divs because canvas was still very young. This was just a proof of concept for me. The demo is interactive, use your mouse.