Show HN: G-Script – Visual Scripting for the Web

Hi all, I'm a PM by day who taught themselves to code over COVID. One of the things I enjoyed during that process was learning how to make basic games in Unreal Engine using Blueprints. I found visual scripting was such an intuitive way to express what I call "mid-tier complexity" logic and I felt there really wasn't a great equivalent for the web - so I built one over the last few months and this is my MVP.

Tools like Zapier etc are great and easy to use, but they're heavily limited when it comes to expressing any kind of complex logic or trying to follow coding principles like DRY.

On the other end of the spectrum, serverless setups like Cloudflare workers or Firebase functions give you all the power of code, but there's atleast 20-30 minutes of additional overhead involved in just getting the things live.

G-Script is designed to land exactly in the middle of these two options. It's "Lower level" than tools like Zapier and supports most of the code-level primitives you NEED in order to express logic.

Examples being: - Conditional Logic - Loops - Static Typing - Objects & Arrays - Version Control - Reusable logic/functions

On the flip side, it's much less friction that writing an actual serverless function, both up-front and ongoing.

Examples: - You don't need to know "Code", just how to express your logic visually. - No need to manage even basic deployments or use a CLI, it's all done via a UI. - Every Workflow is a seperate little microservice with it's own URL that you can call via HTTP. - The super simple version control system makes it easy to role back to earlier versions of a workflow if you break something, or make changes to your logic without impacting what executes and the Workflow URL until you're ready to deploy your final iteration.

Show HN: G-Script – Visual Scripting for the Web
g-script.io

Yeah something like an enterprise tier would definitely be something I'd look at if it gets any traction. The initial market is hobbyists, automation-hackers, and IT folks that just need something to glue together Webhooks and API's etc.

I've made sure to build it in such a way that it can be super easily extended to support multi-user accounts and things like groupings of Workflows etc. You'll notice that all workflow URL's currently include /default/ in the path, the idea being that 'default' could one day be a category/group title without breaking old workflows url's.

Edit: Oh and thank you for taking a look!

Yeah so this is an interesting point - it's not designed to be an integration tool, it's designed to be an automation tool - hence each workflow just has a HTTP endpoint and returns whatever your workflows output is to whatever called the endpoint.

It can also make API calls itself as part of the workflow if you want it to send data or retrieve data from other sources.

Think of it less like something like Zapier which is designed for piping data from A to B, and more like user-friendly wrapper for something like Express.js to make it more consumable to people who: A) Can't code, or B) Don't want to have to spend 30 mins spinning up a serverless instance to hook some webhooks and API's together.

That last point is particularly important when combined with the fact that Workflows can be imported into each other effectively like "Functions" so you can reuse blocks of logic.

The fundamental "atomic use-case" is Product A which has Webhooks, and Product B that has an API. You want to get the data from Product A's webhook, mutate it, update it, maybe cross-reference it with Product C, and then push it into Product B. This kind of logic is prohibitively complex with tools like Zapier (and also quite expensive for an individual), and often legacy tools don't enjoy any of the benefits of tools like Zapier anyway because they don't have native connectors for them.

Appreciate the feedback re: the messaging - I agree that the distinction between this and something like IFTTT/Zapier is important to communicate.

Not really TBH - Enso is more of a ETL pipeline & IDE IMO. Most of what you do in Enso you need to write as code, it just stores those code blocks as nodes on a graph.

It's fundamentally a different problem it's trying to solve. One is a data pipeline, the other is more of a HTTP Utility Belt. Enso also hasn't published what their SaaS product is going to cost, but I suspect it will be enough that you'll want to be expensing it to your workplace.

The idea behind the G-Script pricing is that it's cheap enough that people will just pay for it personally because it's cheap enough that you won't really notice it.

Super cool! I was similarly inspired by UE and built a node-based editor into my in-browser DAW project (https://wavtool.com/).

It really is an excellent interface paradigm. I expected it to be daunting to first-timers but user feedback has been alarmingly positive. Many beginners find this more intuitive than the standard sequential list of effects, because the node-based interface reminds them of guitar pedalboards and home theatre systems.