Show HN: G-Script – Visual Scripting for the Web(g-script.io)
g-script.io
Show HN: G-Script – Visual Scripting for the Web
https://g-script.io/
32 comments
I don't get it from your web page. What can I connect? Slack, Github, other APIs (like Zapier) -- or is it meant for running code on an existing page (automate front end)? I on purpose did not read your description above so I can give you feedback on the more important piece, your web page.
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.
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.
Your web page does very little to explain what it does. Before listing its features, you need a secion on what it is. I could list features like "large", "grey", "slow", "heavy" but without first saying "it's a large mammal", those features make little sense.
It would be really useful to see a real example of a use-case. Is there one available?
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.
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.
Cool, what techniques did you use to create this amazing work?
Haha thanks! The big things:
- 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!
- 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!
This looks great, reminds me of Yahoo pipes!
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.
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.
Yeah you raise totally valid points here.
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.
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.
I don't doubt that you'll be able to cover it on the large whole, since only a fraction of users would parse JSON bodies that large, however, those heavy users will probably use a large portion of the resources.
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$).
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$).
> You don't need to know "Code", just how to express your logic visually
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
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
Yeah I totally get your point - there's also an efficiency dividend in terms of the fact that it's not JUST code you have to write when you do use code. Even if you're just pushing something to an edge function etc, it's still probably 10-20 mins to create an environment to run that code inside of.
Looks like you got the hug of death
>FirebaseError: Firebase: Exceeded daily quota for email sign-in. (auth/quota-exceeded).
>FirebaseError: Firebase: Exceeded daily quota for email sign-in. (auth/quota-exceeded).
Ooof... yeah ok that needs a look (thank you for letting me know).
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.
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.
Nice, clean, very reasonable pricing. Maybe you should add an enterprise tier for people who want to buy a bunch of licenses without wanting to generate 10-100 purchase orders. Otherwise, no notes. Best of luck!
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!
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!
This is nice! As someone who has dived into Unreal Engine and learned Blueprint, I realize the power Visual programming brings to the table.
It's pretty efficient, a great fun way to write logic and I believe it's the future in a way too.
It's pretty efficient, a great fun way to write logic and I believe it's the future in a way too.
Totally agree - the original idea was basically "I wish I could build a little microservice to handle some automation tasks, but do it with UE Blueprints rather than having to actually deploy some code somewhere".
I suggest looking at other products for visual programming Web Applications like OutSystems, or PowerApps.
Nice implementation and kudos for having modules capabilities from the start.
Nice implementation and kudos for having modules capabilities from the start.
Two main differentiators:
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.
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.
I guess I am biased in what those tools can achieve, given the kind of projects I work on.
Naturally it is a matter of which market one cares about.
Naturally it is a matter of which market one cares about.
How does it compare to Node Red? https://nodered.org
Great question! Being totally honest, the core idea was basically something along the lines of "What would you get if Unreal Engine Blueprints and Node Red (NR) had a baby, and then you made it available as a $5 SaaS app".
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.
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.
Thanks for the comprehensive answer!
Piggybacking on this: How does it compare to https://n8n.io/?
Had the same idea for a while, cool that you launched! I would double/triple the price though
This is an interesting take - the idea behind the pricing is to be so low that people will pay for it themselves rather than trying to get their workplace to pay for it.
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.
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.
That sounds like a great way to get yourself fired quickly!
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.
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.
So like Enso but you can't switch it to a code view or paste code if you wanted?
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.
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.
Thanks for clearing it up
Not sure exactly what this is supposed to do.
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.