• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Interest Check: RetroScript

flexo

Well-known member
Had this idea for a while so over this weekend I've managed to write a quick-and-dirty proof of concept for it - but I want to make sure that there is at least some interest in either helping me develop this or developing apps using this – or if you think my programming privileges should be taken away for even suggesting such an idea.

Elevator pitch:

While programming for older computers can be challenging but fun, sometimes you just want to make an omelet without first having to build a farm and raising the chickens for the eggs yourself. Writing a Toolbox app is pretty hard - you have to basically do everything yourself.

Imagine instead of writing hundreds of lines of code to display a window with a button, you can just do this:

JavaScript:
var my_window = new RSWindow(500, 200);
my_window.title = "Hello world from JS!";
my_window.center();

var my_button = new RSButton(10, 10, 100, 20);
my_button.text = "Click me!";
my_button.on("click", function(e) {
     alert("Thanks for clicking me!");
});
my_window.add(my_button);
my_button.show();

my_window.show();

That's RetroScript: a dialect of JavaScript used to create apps. As an added bonus, this app can work in any platform with the runtime supplied - imagine being able to run the exact same code on a Macintosh SE and a brand new M2 MacBook.

There would be several ways of running a RetroScript app:
  1. Packaged: Your code + RetroScript runtime is packed into a single executable. Perfect for distribution.
  2. Using the "RetroScript Runtime" application
    • Locally: Double-click a RetroScript file and the runtime app launches, running the app. Perfect for developing/debugging personal apps.
    • Remotely: Enter a URL and the Runtime fetches and runs the app. Perfect for network apps.
Of course, apps would be significantly slower than native code (esp. on older 68k Macs, might not even be worth it?) – but we might get a bunch of brand new apps written for classic MacOS. Since most web APIs nowadays use JSON, writing web-enabled apps would be trivial after networking capability is added.

I've already written a proof of concept using Retro68 + Duktape, so the first code example provided (sans control callbacks) actually works:

Screenshot 2023-05-28 at 11.52.31 PM.png
Let me know what you think - if there is enough interest I'll push this as far as I can before cleaning it up and putting it on Github.
 

3lectr1cPPC

Well-known member
Oh I absolutely LOVE THIS IDEA!!!
I’ve already got a bit of experience in JavaScript so as long as you put up a bit of documentation I’ll bet I could write some basic programs for our macs. Would be a lot of fun and absolutely something I could see myself getting in to!
Main thing would be performance - I’m not expecting it to run well on a 68000 but would a fast 030 or better be able to handle it?

Anyways, absolutely interested.
 

flexo

Well-known member
Glad to hear!

Main thing would be performance - I’m not expecting it to run well on a 68000 but would a fast 030 or better be able to handle it?
Great question - I know that duktape is designed/can be configured to run on very low end systems / microcontrollers, I guess it would be dependent on the overhead of my code. I'm no C++ expert so initially it might be extremely slow before someone optimizes it.

---

A few more ideas / questions popped up in my head while showering – any feedback on these would also be welcome so I can scope this better.

No HTML: Absolutely no support for creating windows/controls using HTML like Electron. Maybe some very limited BBCode-ish formatting in textarea control so you can create scrolling content though?

Form Editor / JSON: It could get really annoying trying to design windows using code only. Maybe a form editor that creates a JSON that can be used to create the window instead? (No WIND resources so we can be cross-platform!)

Duktape: I do like using Duktape as it's pretty easy to integrate – but if anyone else knows an alternative that might perform better, please let me know! (Duktape also doesn't support keywords like 'let' or 'const' nor supports Promises, AFAIK.)

HTTPS / SSL: This is getting less and less trivial to implement by day – and I'm not sure how I can do it or if it's even worth implementing. I'm not a fan of HTTPS-to-HTTP proxies so native support would be great but probably won't be initially there. Again, suggestions welcome.

Images: GIF and JPEG could be supported using Quicktime – but I don't want to make Quicktime a requirement. LodePNG is a fantastic PNG library - that might be how we implement images, supporting PNG only?

Sounds: Absolutely no idea.

Hardware access: Do we need things like reading from / writing to serial ports? Might be a overkill, I think.

Modules / Libraries: Can of worms that I think we should avoid.
 

3lectr1cPPC

Well-known member
How similar would the capabilities of something like this be to HyperCard? Don’t know much about it other than that it’s also a scripting language that can create simple stuff.
 

flexo

Well-known member
How similar would the capabilities of something like this be to HyperCard? Don’t know much about it other than that it’s also a scripting language that can create simple stuff.
Not familiar with HyperCard – but I do know it (a) didn't support a lot - including color graphics - without extensions (b) the syntax of HyperTalk(?) is extremely unique, which might be off-putting to some (including myself, to be honest) (c) it was more like a database with scripting rather than a software development platform, if not mistaken. Again, I'm not familiar so might be completely wrong about these. If I'm correct though, I would say this would be as if not more powerful once we pass some milestones.
 

3lectr1cPPC

Well-known member
Right. Well I’m definitely looking forward to seeing where this project goes! Keep us updated for sure.
 

Phipli

Well-known member
You're both underestimating and misunderstanding Hypercard. It was excellent and not just a database with black and white pictures. Apple used it for internal rapid prototyping, software was often initially made in HyperCard, then compiled to an application from the Stack, and only written in more conventional ways later if needed.

I've made serial and ADB interface box sequencers in Hypercard. One of the FPU emulators commonly used back in the day was made in HyperCard... Myst was made in HyperCard.


Don't confuse "easy to start learning" with "primitive and limited".


I strongly suggest you have a few hours playing with it. Make an animation, or a music sequencer, or just throw together a little applet for managing your disk images. It does File I/O, sends apple events, sound, serial (with an addon) and some colour and quicktime video tools came with the last version, and were available for older versions.

Its also extremely extendable with a plugin format that became a standard in classic mac development environments.
 

sfiera

Well-known member
What are some examples of apps that you think this would be suited for? I think the best approach would be to decide on the apps, and work back from there to figure out what the essential features are.

The proposal reminds me of GetDown Classic (but of course that already exists).
 

Crutch

Well-known member
I am always excited to see anyone build new dev tools for vintage Macs!

To some extent though I think this is a solved problem: have you seen SuperCard? https://www.macintoshrepository.org/1875-supercard-1-x
It was basically HyperCard++ and included full color support, ability to build a double-clickable application, multiple windows, full ToolBox access, etc. (SuperCard was removed from the Garden in the distant past for reasons unknown to me but is still available at this link and elsewhere)

SuperTalk, their flavor of HyperTalk, may be unique but it’s extremely easy to learn and totally visual from a UI design standpoint.

Or AppMaker for a different take on this (this one lets you rapidly build/prototype a GUI, then generate the relevant source code and write all the callbacks yourself in C/C++ to implement your app’s actual functionality) https://macintoshgarden.org/apps/appmaker-15

ProtoTyper also worth a look perhaps.
 

oldmacuser

Well-known member
Looking forward to see where this project is going! Also I am going to start looking into the HyperCard HyperTalk as phipli suggested. What would be the best version to play around with 68k macs like SE & SE/30.
 

Phipli

Well-known member
Looking forward to see where this project is going! Also I am going to start looking into the HyperCard HyperTalk as phipli suggested. What would be the best version to play around with 68k macs like SE & SE/30.
I'd say 2.1 or later really. If you have the disk space and System 7.x, I'd just go with 2.4 to be honest.

This might be bad advice, but I'm not a pro.
 

flexo

Well-known member
Great to see interest! I've managed to get it running on a PB1400 and might actually release a prototype later today / tomorrow.

To clear things up and to answer a few questions:

Maybe I've worded the initial post badly: the purpose of this is not to create a rapid development environment – there is RealBasic, et al for that.

It's to create small, cross-platform applets using a relatively known programming language with built-in support for web standards like JSON and PNG.

And when I mean applets, I mean things like maybe a tool that checks the weather online, a Wordle clone or a small chat client – I don't think you should try to build a web browser or an office suite using this. Not saying that would be impossible, just saying it would be very inefficient & slow.
 

flexo

Well-known member
Prototype 1 is here!

Sorry for the delay – I wanted to make sure it's at least somewhat usable before releasing it. In addition to the runtime itself, it comes with three example scripts you can use and edit with SimpleText. Launch the RetroScript app then select a script to run it.

Please keep in mind that this is literally less than 2 weeks of work. It does not support ~90% of the things I would like it to eventually support, it does not run on System 6 yet and it could not be less optimized – both in terms of speed and RAM usage. I'm not even doing proper memory management, so expect a lot of problems.

I got it running (barely) on my PowerBook 1400 running System 7.5.3 - anything newer than this should definitely work. I would really suggest a G3 machine at this point, to be honest.

Very little has been implemented so far – if it's not on one of the example scripts, there is a 99.99% chance it hasn't been implemented.

I would love to hear feedback - especially on the syntax and whether or not you could actually get it running on your hardware.

Another prototype or two and once the code is not as embarrassing I'll be putting it on Github.
 

Attachments

  • RetroScript-Proto1.sit
    212.6 KB · Views: 1
Last edited:

flexo

Well-known member
Running it on MacOS 9, I found two bugs related to the Canvas and Timer code. Should be fixed now.
 

Attachments

  • RetroScript-Proto2.sit
    212 KB · Views: 0

rplacd

Well-known member
Wahey, how long do apps take to start up? I remember compiling Duktape into a console app, and waiting slightly more than half a minute for things to load... I think a loading screen would ahve made it better.
 
Top