This message was deleted.

Really cool Ivan! Can you share a bit about your tech stack, and what do you think are the big challenges about the project?

Thanks! I'm doing prototypes in CoffeeScript and Electron, but I'm designing things with portability in mind. The first audience for this tool is the artists on my team, and they're all on Mac, so I'll probably build a native Mac version (not Electron) for them once I'm happy with the design. It's just faster for me to prototype in CoffeeScript. Big challenges: • Time rewinding, which could be implemented in a handful of different ways, each with pluses and minuses. I haven't decided which approach to take yet, and feel like the best answer will be a hybrid, which will be highly complex to design and implement. More detail on that in this blog post: https://ivanish.ca/hest-time-travel/ • GUI: I'm aiming for a tremendous amount of richness, on par with something like Ableton Live or Modo. That takes a huge time investment. Small challenges, what I'm working on now: • I need new way to organize objects in the scene that allows nesting/grouping, and allows for function composition. • I need to decide on a visual metaphor for the idea of things being ordered. For instance, to allow positional arguments to functions, or building ordered lists. • The current prototype is a fork of an unfinished fork of a mostly-working previous prototype, so there's a lot of half-implemented ideas I either need to remove or finish. So that's what I'm doing first.

Thanks for the answers. A couple more questions: Is the goal to have an internal tool for your company, or are you planning to release a more general-purpose tool? Will you open source the tool?

which features would the MVP have? what would be achievable with those features?

@Daniel Garcia — Internal tool for our (expert-user) artists first, then an open source release of some sort. Then on top of that I'll build a closed-source highly domain-specific tool for our internal (non-techy) subject matter experts, and finally we'll probably sell that DSL to clients.

I was about to say that you should make this 3D from the start! 😄

The UX I'm going for is that you'll do most of your coding on a 2d plane, and the depth axis will be used for dynamic navigation — so things in 2d will stay where you put them, but planes of depth will come and go sort of like editor windows or tabs. The benefit of using depth for navigation, rather than (say) tabs, is that I want to be able to do the Ted Nelson thing of physically showing every connection. There should be no path that execution follows that can't be rendered as a path with data flowing along it. Even if you don't always see those connections, the editor needs to ability to draw them so that you can physically follow the execution.

I find electron very ponderous, how do you like CoffeeScript and why did you choose it over TypeScript?

I've been using CoffeeScript for longer than TypeScript has existed. So, when TS emerged, I looked at what it offered and felt that CS was still the better fit for how I work. Electron lets me prototype atop the browser platform, with unprompted access to the filesystem. I have a very aggressive autosave/autoload system in my prototypes, so that I don't lose any state when cold-reloading the app.

How is electron defeating the security restrictions of the browser? If you write plain JS code, you are not permitted to save to an arbitrary file on the user's HD, nor to read it back later. This is why so many people use Node.JS, etc.; what trick are they doing? Is it via browser extension or plug-in?

Simplifying a bit, Electron is a Node process that spawns a browser process. You can pass data between them via a secure API, or (what I'm doing, for prototyping) make the node process directly callable from the web process.

So people have to install Node in order to run the program. The whole point of the web browser is zero install, I wouldn't want to use something big like Electron. But i understand why other people wouldn't mind. I am trying to have as few dependencies as possible. I may just store everything in the cloud.

You need node to compile the Hest prototypes I'm making — but they're closed source for now, so it's not a concern. I'd like to keep the Hest core small enough that it's easy to port/reimplement — the current prototype is only 2k lines of CoffeeScript, and I think it won't get too much bigger than that. I plan to make a native Mac app (written in Swift) for my coworkers, a web version (backed by a server for persistence) for my clients, and some sort of open source version. But that's all way down the road.