BASIC programs producing playable web pages good enough?

Inspired by another topic (here) I would like to know if anyone has experience with BASIC programs that compiles the code into an html-file playable online so that the player can save and restore to the browser or their own pc. The speed should be decent so an Infocom-like parser should be close to instant.

I have just learned about “Run BASIC” but there might be others and I don’t know the limitations.


BASIC and HTML are really different things. You could generate HTML pages from any programming language, but the salient part is, what would those HTML pages look like and why not just build them by hand (or use Twine)?


Thanks @DavidC, I have now changed the title to be more accurate.

I believe I could build a pretty good parser in BASIC but I know nothing about html or webpages.

I may also use the wrong words here but here is what I read about Run BASIC:

"Since Run BASIC is designed to let you get a lot done with a minimum of code it generates the necessary HTML code for you." (info: Pdf on Run BASIC )

Would the parser be in basic? It has to run on the web page, in the browser. I would expect you BASIC program to compile into JavaScript, and the parser would be in that - in which case you are better starting from JavaScript.

You could have a standalone program running BASIC, and it could include a window that works like a web page, handling HTML pages. Quest 5 does this a little bit, though most of it is in C#.

1 Like

uhm… I think there’s a major misunderstanding.

Basic, even those of 8-bit micros, has a very strong, if not excellent, string handling & manipulation instructions & functions (whose is why there’s many BASIC IF from 1980s…) and, on paper, BASIC’s string manipulation indeed can be used for building HTML markup output, to be feed straight to a browser. all is needed, is having enough CPU horsepower and memory (esp. strings aerea, where I suspect is where 8-bit BASICs can fail) for handling both at least a verb-noun parser for the input and static HTML for output.

so, is redundant to say that a BASIC dialect is designed for HTML code generation, because practically all BASIC dialect is intrinsically capable of generating HTML, or, generalisating, text markups. (a$=b$+c$+d$… if b$ and C$ are the opening and closing marks/tags and c$ the text between the marks/tags… heck, I can even wrote a BASIC script for generating my “scrolls of styles”…)

Best regards from Italy,
dott. Piergiorgio.


I read the RunBASIC docs. It’s interesting and I see where you’re going with this, but my 30 years experience playing and writing tools for Interactive Fiction tells me this would be a one off experiment.

No one else is likely to ever use this technology because Twine already does this and is pretty damn good at it. Inform does this in a different way, but can also emit games runnable in a browser. And no one uses BASIC much at all anymore. There are just infinitely better tools.

And writing a decent parser and world model isn’t the tea party you think it is, which is where most of your time will be spent.

So as always I have two thoughts for platform builders.

  1. This will be hard and you’re unlikely to get much support from others.
  2. I love your passion and this does seem like an awesome experiment.

If you do want positive feedback, you’ll need to build a useable system AND an interesting game to show its capabilities.

But I’ll cheer you on from the sidelines. It does sound like a neat experiment.


Hi Pixie,

Yes, the parser is made in Basic.

I know you are very strong in JavaScript but to me, JavaScript is a lot harder than Basic which I learned when I was a kid. So I am using Basic because to me and probably several of people with my background, this is a lot easier.

Hi Piergiorgio,

Maybe but I don’t want to spend time learning JavaScript when I already know Basic. I want the program to “translate” the code in Basic to a web page. But thanks anyway :slight_smile:

Hi DavidC, thanks for cheering!

You’re right that only few people are still using BASIC but it seems that there are still a few people in the IF community who are interested.

For instance, this topic was inspired by the topic by @TomTAP, which I link to in the first post, and in IFComp last year Jim MacBrayne did very well with his BASIC game The Alchemist, despite that it was only available on Windows. His system could easily have been ported to RunBasic I suppose and everyone could have played it.

These are just examples. Many in my generation find BASIC very easy to understand

Another example is that I would like to port Eamon Deluxe (written and BASIC) so it can be played in a web page. It is possible to run DOS-box in a web page but save and restore isn’t going to work. These are just examples that BASIC still can be useful in the IF community even though I know we are minority.

If you can get it to work in the browser - and I would check that right from the start - then go for it. Far easier to use a language you already know.


One problem with “Run BASIC” is that, as far as I can tell from a relatively cursory look, it requires a server to run; not just to host files, but to do the actual processing. So, for a game to be playable on the web, the author would have to run a server continuously, or buy space (including processing power) on a server where the admins allow the installation of Run BASIC; for example That would be more or less similar to the way the ADRIFT Web Runner works.

A better solution would be something where the processing takes place purely client-side, within the players’ browsers, so that you only need to host the HTML + JS files somewhere, and the server on which they are hosted doesn’t need to do any special work, nor have any special software installed. So essentially, as mentioned above, a BASIC to JavaScript transpiler would be good.

I just stumbled upon this, which sounds like it might fit the bill:

Here are some code examples, click on the small play button to see what they do: SpiderApp


You’re right about RunBasic needing hosting. That could be a no-go. Also SpiderBasic does look interesting, although it appears to be a modern procedural dialect.

Another idea occurred to me randomly, which is:

Write your basic for a 80’s micro (choose your favourite), then run a web-based JavaScript emulator?


Yes, that’s where my mind went—if your BASIC can run reasonably quickly by a microcomputer from the 80s, it should run blazing-fast in a client-side JavaScript interpreter on any modern system.

I’m certain people have done this for various classic BASICs, for the purpose of emulating old programs. But you can also probably find “modernized” forms of those which lift the memory limits and add some new commands to take advantage of modern processing power. I’m sure more people have written interpreters in JS than have built full transpilers.


I know you don’t want to learn JavaScript, but if you ever change your mind, here’s my two cents:

JavaScript is indeed different than Basic, but it has the advantage that it does not really force you to learn Object Oriented Programming, unlike many other languages. You can pretty much get away without it. You can also use global variables just fine and code in a very Basic kind of way. It’s not necessarily idiomatic JS, but who cares. In fact that is how I wrote my first JS programs after growing up with Basic. Maybe that makes the transition appear a bit less daunting? (Unless you are coming from one of those weird Basic dialects that have OOP tacked on already …)


Good point about the server. Running examples and then disconnecting internet connection showed that RunBasic requires internet connection whereas SpiderBasic does not.

This looks VERY promising and the price seems reasonable. There seems to be a read file command, hopefully also a write file command so people can save their game and come back later.


Would be fine if it had the following requirements:

  1. Enough speed
  2. Enough RAM
  3. File access AFTER shutting down browser and returning
  4. Decent code editor

About 1 - enough speed: Emulators bring down speed a lot and not compiling code before running it does too. This is a huge problem on old micros: They don’t compile the code, they just run it. further more, The Vice emulator on warp speed allows me to run e.g. C64 emulator at around 5MHz which is far from the 2GHz of my pc. Most likely much to slow for an advanced parser.
About 2- Enough RAM: Perhaps an Amiga emulator with extended RAM would have enough RAM…
About 3 - File access: The player must be able to shut down his pc and return from a saved file. A problem with most emulators embedded in a web page i guess.
About 4 - Decent code editor: This certainly excludes C64/128 but perhaps not Amiga and Atari ST - never tried programming on those.

Sounds interesting - never heard of that before. That could make emulators a decent alternative. Again, we should avoid the “server-method” so that the emulator uses the player’s computing power, not the host’s computing power and works if internet connection is lost.

You have some good points. Maybe some day I will try but not at the moment.

1 Like

not to restart ancient flames, but personally I find the Commodore editing the most advanced of its age (was basically unchanged since the PET of 1977-8 vintage…), even with a sort of markup language; all one needs to be careful is keeping track of the quote mode…

Best regards from Italy,

Considering its age you are probably right. But you could only have about 26 lines of text and 40 columns so it was hard to get an overview.

But i’m sure som c64 enthusiasts have made an external editor which can launch the program directly onto a c64 or something like that. It is my impression that the c64 is the most cared for 8-bit machine worldwide though the Spectrum seems to dominate in IF circles.