Web Pages Via Forth

Forth. You either love it or you hate it. If you have struggled to work on tiny microcontrollers, you probably are in the first camp. After all, bringing up a minimal Forth system is pretty simple and requires very little resources on the CPU. Once you have such an environment it is then easy to extend Forth in Forth. [Remko] decided he wanted to build a Forth compiler that uses WebAssembly and runs in your browser. Why? We’ve learned not to think about that question too much.

The world has changed a lot since the first introduction of the WorldWideWeb browser in 1990. What started out as a way to show text documents over the network has become — for better or worse — an application platform. JavaScript won the browser scripting language wars and security concerns pretty much killed Java applets and Flash. But JavaScript isn’t always fast. Sure, there are ways to do just in time compiling, such as Google’s V8 engine. But that compile step takes time, too. Enter WebAssembly (or Wasm).

Just as a C programmer might write certain parts of her code in assembler for performance, a JavaScript developer can build speed-critical code in Wasm. Wasm defines a text format and a binary format that is easy for the browser to digest and execute. The Forth compiler uses mostly the text format with some JavaScript for a few functions. Of course, a lot of it is also written in Forth.

If you hate Forth, you’ve probably already quit reading by now. We’ve enjoyed using Forth on the BluePill which makes for a dirt cheap development system. We’ve also seen Forth in JavaScript before. It would be fun to benchmark the JavaScript and Wasm versions and see how Wasm fares.

15 thoughts on “Web Pages Via Forth

  1. There are so many plugin compiled languages for a browser now.

    There are also some interpreters and VMs as well.

    JavaScript itself is slow, chunky and resource hungry for the asynchronous tasks we see more of in modern web apps.

    LUA is probably a better browser plugin language as it’s elegant for asynchronous tasks and if you have some experience with JavaScript then LUA is not that hard to learn.

    LUA is a little like Lisp in some regards as even the data structures can first class. That is a function can be data and data can be a function.

    LUA has a lot of nice surprises about what you “can do” as opposed to other languages that have nasty surprises about what you “can’t do”.

    1. “JavaScript itself is slow, chunky and resource hungry for the asynchronous tasks we see more of in modern web apps”

      The problem isn’t Javascript, which is actually incredibly fast for a scripting language. What makes it slow is that simple-looking web pages often include multiple huge libraries and drag in megabytes of fonts, GIFs, etc. If you could snap your fingers and change history so that Netscape pushed Lua instead of javascript, most web apps would still be slow.

        1. That depends on who you talk to.

          In the case of JavaScript – older people remember the pain of the browser wars and JavaScript that would only run in the browser you wrote the code in until extensive modification. There were no libraries commonly used then. It was custom code.

          JavaScript is much more cross browser compatible now so younger people are more comfortable with it.

          Also everything JavaScript now uses a libraries so younger coders have a much better organized and sensible code namespace and that makes things easier as well.

          I can’t comment on Java today as I haven’t used it for a long time but the most common complaint I hear about Java can be summarized by the following pseudocode –

          While (1)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.