Show HN: G-Script – Visual Scripting for the Web (g-script.io)
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.
32 comments
[ 3.1 ms ] story [ 74.2 ms ] threadI'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!
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.
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.
>FirebaseError: Firebase: Exceeded daily quota for email sign-in. (auth/quota-exceeded).
Well... this is why I dropped on HN where people are a bit more forgiving =)
Edit: You know what would be lovely... if Firebase told ME that I'd hit that rate-limit rather than only telling you haha.
No email, not notification in the portal, just failing silently into the night...
Anyway - should be fixed now.
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.
- React as the core of the UI, with direct DOM manipulation and canvas stuff whenever the React lifecycle is too slow. - WebAssembly for any audio logic that happens at least once per sample - Lookup tables for almost all math that happens at least once per sample and is more complicated than multiplication - Use Web Audio as an interface layer, but do everything else manually. (Web Audio tries to help a lot of ways but often winds up making things worse)
If you're curious about anything specific I'd be happy to talk!
It's pretty efficient, a great fun way to write logic and I believe it's the future in a way too.
However, are you sure that you can scale with only 5$ for the "unlimited" plan?
I can imagine large bodies of JSON having to be parsed, could clog up quite a lot. Example: 33kb bodies, that would be +30GB of data exchange at 1M requests.
The current thinking is that the $5 tier would end up having a small set of "fair use" restrictions on it for things like max request payload, max workflow execution time, etc. Payload size is the big one, I'm less worried about execution time as the underlying engine that executes the logic is all Async & non-blocking so it's pretty efficient.
I want to have a very clear line though between the allowances that are restricted to encourage a higher price-point (workflows, node's, executions), vs the one's that are there to ensure things don't explode.
The benchmark goal would be for raw compute to equate to <10% of total revenue, which I'm confident is very achievable with some sensible restrictions that still allow 99.9% of use-cases.
At this early stage, I'd probably say that anyone who's processing 1M requests with 33kb bodies each prooobably isn't my initial target customer haha.
It's hard to weigh conversion numbers vs heavy usage, a low price like this will certainly help adopt new users and in large numbers. It might even make it worth tolerating the (few) heavy users.
Or you put it in cloudflare workers, which can parse 1.5MB of JSON within 50ms CPU-time and call it a day (10M requests/5$).
The idea being that for a lot of "productivity SaaS apps", one of the biggest friction points is the pain of having to expense the subscription on a corporate card or get it reimbursed via your work - so a $5 price basically side-steps that by being cheap enough that people will just say "fuck it" and pay for it themselves because it saves them an hour a month.
I kinda have a theory that anything over $10 a month and people start to go "hmmm do I really need this?" where as less than $10 a month and people will just impulse buy.
All that being said... price is definitely something I'd experiment with once I validate there's actually real demand.
Or are there really companies that are so lax with security and sanity that they would tolerate their developer hooking in random SaaS services into the companies workflows without vetting.
IMO it's a lot easier to use than NR (I've played around with NR quite a bit), which is the biggest difference in my opinion. Obviously you don't have to host it, which is a big plus. But the interface is also just a lot more user-friendly and intuitive.
Passing data from one node to another in NR is not super intuitive, and you can't easily visualise data flow coming from multiple sources and then converging into a single node.
As far as I'm aware, NR also doesn't have any kind of Type system - Types in G-Script help to lower the learning curve because it's a bit like building a PC... if the cable fits in the port, there's a pretty good chance it will atleast work and not explode.
NR does support "code reuse" too, but again it's just not super intuitive and user-friendly. To be clear, there's nothing G-Script does that hasn't been done before, but IMO it's packages in a very user-friendly format and priced very competitively.
I'm looking to add super simple Auth, Testing, and Data Persistence over the next few weeks, which I think will accentuate that usability gap even more.
Nice implementation and kudos for having modules capabilities from the start.
1. Simplicity - both of those things you mention are painstakingly unintuitive if you want to do something fairly complex.
2. Price - Power Automate gets stupidly expensive at any kind of scale, the base plan is only $15 a month, but its capped at 5000 executions. Similarly, OutSystems gets REALLY expensive pretty quickly once you get over the smallest size plan.
Naturally it is a matter of which market one cares about.
If shader nodes are anything to go by, it results in the equivalent of 5 lines of code taking up a full screen of incomprehensible boxes and lines.
A pretty bad trade-off, but I guess non-programmers can't really use anything else. Code is scary! /s