Hi just had a look at every comment you've made and every starter page on your site. I'm still lost and don't understand what this is, even though I see some people are already understanding and using your product, which is baffling me more.
I think I'm missing where your product runs and who is running what and why they are running a curl command, and if I'd have to make changes in my application to support this.
A general conceptual diagram on your site would go a long way.
Sincere apologies for that. We’ll make sure to fix this up asap and include a diagram as you suggested as well. Happy to give you a ping as soon as we did!
The example at the top of the docs pages still doesn't help me understand what your product does. It also doesn't work, it just returns: {"message":"access token is not valid for this request"}
I'm guessing that's because I need to get a valid access token to run the example? Well then you'd better say that, and tell me how to do it, or even better don't require it for your first example to work.
I tried going into the "Advanced Guide". It had a handy first link that linked me to "Hello world in scriptable". That sent me back to the first page of the docs, with the example that doesn't work. At this point, I'm stuck and out, sorry.
Thanks mate, that feedback is really valuable. We definitely need to sharpen our message and guidance there quite a bit. In a nutshell, Scriptable allows you to provide your users with a code escape hatch, for everything your product doesn't support natively yet. For Shopify this might be a function that calculates a custom discount (https://shopify.dev/docs/apps/discounts/experience), while for something like Framer (see example here: https://www.framer.com/learn/how-to-work-with-real-dynamic-d...) it might be to integrate and fetch data from a 3rd party API. There are countless other examples (Auth0 for instance), which provide something similar to their users to bridge gaps. We also use it within our own product to build some custom components, like providing restricted access to a Tesla, Alarm System, Philips Hue System, etc. Here are two examples of that: https://www.youtube.com/watch?v=JG1ApkFQ5xU .. https://www.youtube.com/watch?v=H6Lf-n3WYh8
Apologies again for doing a poorly job of getting the message across. We're currently working on revamping our landing page, docs and general onboarding story.
Exciting product. You should describe some common problems people have, and show us how you could use Scriptable to solve them. That's a nice and "easy" way to showcase a service IMHO.
No worries mate. The examples don't have to be ground-breaking or even relevant (for me), but clear so I can see how I can apply Scriptable.dev to solve my specific problems.
And, since you target developers, add as much info as you have. Don't skip messy stuff like "how to authenticate" or similar.
It sounds like this is providing a sandboxed wasm runtime as a service is that right?
I think in this case the landing page is lacking in technical details to the point where it’s hard to understand what the product actually is. I like the general idea of firecracker as a service and sandboxed code as a service though.
Even the webhook example doesn’t really show where scriptable fits in, I think what you’re trying to say is that the customer can write some code to integrate the product with their slack and then the service will call the customer’s code in a sandboxed environment which is how the customer can extend the product right?
You're 100% on the money here. One way to use it is to fire off user-provided scripts tied to certain events in your product, similar to webhooks. But it's also flexible and quick enough to make your product extendable in terms of UI. It's 100% deploy-less (and stateless) as well, meaning you can just through whatever code at it, and it will quickly evaluate and respond with the result.
The comment does make the high level clear, but it's still confusing a level down. For example, your copy suggests I can use it to allow customers to write scripts that execute based on events from my application. But what's the interface for them? Is there a UI to add/manage/monitor scripts? Is there some multi-tenant concept that keeps each of my customers isolated from another? If not, what's the value add over just using something like Cloudflare Workers for this?
Thanks mate. The difference is that you wouldn't really want to simply copy code from your customers/3rd parties for a couple of reasons:
Missing out-of-the-box security/sandboxing, the time it takes to deploy and (cold) startup time.
With Scriptable, you don't need to worry about any of that. And there’s nothing for you to provision or maintain apart from saving the user-provided scripts in your database.
Hah, hey mate! Just walking by the office on George St.
You’re totally right. This is pretty much “Forge as a Service” for others to use in their products as well :) In fact, we propably wouldn’t have build it (again) if we could have used Forge. I’m glad we did though, as it suits us actually much better, e.g. by being completely deployless.
I'm still very sore with Atlassian for their decision to close down Hipchat. Maybe Slack was beating Hipchat in the popularity stakes, but I spent a huge amount of time at a previous job building integrations (or whatever they were called) which would, for instance, allow colleagues to setup a new client project (Google Drive directories and files, Assembla project management stuff, Trello tracking for the project etc, etc) with a simple `/build project-name client-name` comment in a Hipchat room and then, one day ... all of it gone!
I really wish the devs of this new shiny the best with their endeavours ... but that wound still smarts!
Sorry to hear this. I truly can relate. Hipchat/Stride was one of the very first products at Atlassian that adopted our cross-product service and components for attachment and link handling, even before Confluence, Jira and Bitbucket if I recall correctly.
I've been using Scriptable to develop a Discord Bot integration for our Questmate task and I think it's a very powerful and flexible solution for creating custom integrations.
Wow, now I remember. That was one of the first usages of Questscript (which is powered by Scriptable) we saw when just added it. Thanks for your trust and support!
I have had a similar-ish idea floating in my head for a while, which is a library + executor + editor UI for per-app scripting capabilities.
Something that would let people write out basic automation workflows to respond to events, similar to what Zapier or Salesforce offers to its users.
There are, of course, halting problem-style issues. I _think_ you could paper over some of that at the description level. But really you want the right kind of hooks into the actual system. A scripting tool that is just "oh but you just hit the API" is way less nice than bespoke components for your own system.
And with event systems you have the usual event propogation issues of accidentally causing a massive fan-out of events from some action and causing your sysetm to fall over.
But this is really something that someone could write out as a component for other systems and make a lot of business SaaS's automation floors way better.
You really do want to offer _something_ to users, though. The users that can write Javascript... well, Zapier lets you write Javascript. Hell, Google Cloud Platform lets you write Javascript in little script blobs, complete with Google Docs-level concurrency. This is a bit weak compared to that.
100%. This is literally what we’re working on next right now. We just had to start somewhere and with the thing that enables us to do all the other things. We have developed quite a bit of that already inside our own product (e.g. account linking, an editor + live preview, a UI rendering layer, pre-defined connectors, etc) and are in the process of extracting and productizing this, so it’s all part of Scriptable and it’s broader vision (Extendable)… We refer to these things as the batteries we’re missing right now :)
Not to hijack OP's thread, but what you describe is what our end-state plan is for G-script (https://g-script.io/), the underling tooling is literally implementable as ~10 lines of Javascript (5 to implement the back-end "engine", 5 to render the front-end editor).
The idea being that any SaaS app could basically bolt it in and then add trigger events that match to their apps business events/entities and allow user to extend the core business logic with their own "Scripts".
You are unfortunately not alone and we’re about to fix this. Not sure what you mean with “ProductHunt Product”. Can you elaborate? We haven’t done our ProductHunt Lunch yet. Will
certainly defer now a bit until we fixed or messaging/positioning.
Ha! We just implemented this for our own product. We ended up using Lambdas to be able to achieve this, w/ async rendering of custom Liquid templates for each account.
Congrats mate, that's awesome! Did you create a separate AWS account for that to separate from the rest of your stack? How did you achieve isolation for each script? V8 isolates or dedicated Lambda per script? Any other challanges you ran into? We're really keen to learn from others doing similar things.
Your corporate memphis girl splash-art is holding a puzzle piece that can clearly never fit. The subtle negative implications of that really sat with me.
The pricing modes are confusing - I've seen it at other websites too, is this some kind of trend?!
The issue: when I choose "yearly" subscription, the page still shows price per month. So you're about to charge me every month? Despite I chosen to pay yearly. And where's the "2 months free" if I end up paying monthly??
Your starter pack costs:
$79/m (in "yearly" subscription) - so $79*12 = $948
(or $79*10 ??? because of the "2 months free")
$99/m - so $99*12 = $1188
$1188 - $948 = $240 - so it's actually more than "2 months free".
It's super confusing and I leave immediately no matter how badly I just wanted to buy it.
41 comments
[ 0.19 ms ] story [ 76.8 ms ] threadI think I'm missing where your product runs and who is running what and why they are running a curl command, and if I'd have to make changes in my application to support this.
A general conceptual diagram on your site would go a long way.
I have no idea what your product does.
The example at the top of the docs pages still doesn't help me understand what your product does. It also doesn't work, it just returns: {"message":"access token is not valid for this request"}
I'm guessing that's because I need to get a valid access token to run the example? Well then you'd better say that, and tell me how to do it, or even better don't require it for your first example to work.
I tried going into the "Advanced Guide". It had a handy first link that linked me to "Hello world in scriptable". That sent me back to the first page of the docs, with the example that doesn't work. At this point, I'm stuck and out, sorry.
Apologies again for doing a poorly job of getting the message across. We're currently working on revamping our landing page, docs and general onboarding story.
And, since you target developers, add as much info as you have. Don't skip messy stuff like "how to authenticate" or similar.
Good luck!
I think in this case the landing page is lacking in technical details to the point where it’s hard to understand what the product actually is. I like the general idea of firecracker as a service and sandboxed code as a service though.
Even the webhook example doesn’t really show where scriptable fits in, I think what you’re trying to say is that the customer can write some code to integrate the product with their slack and then the service will call the customer’s code in a sandboxed environment which is how the customer can extend the product right?
Why isn't this in the first paragraph of the introduction on your website?
Missing out-of-the-box security/sandboxing, the time it takes to deploy and (cold) startup time.
With Scriptable, you don't need to worry about any of that. And there’s nothing for you to provision or maintain apart from saving the user-provided scripts in your database.
https://apps.apple.com/us/app/scriptable/id1405459188
I use this to schedule notifications, create widgets (e.g. to show AQI from PurpleAir), and do quick text processing automation.
https://developer.atlassian.com/platform/forge/
You’re totally right. This is pretty much “Forge as a Service” for others to use in their products as well :) In fact, we propably wouldn’t have build it (again) if we could have used Forge. I’m glad we did though, as it suits us actually much better, e.g. by being completely deployless.
I really wish the devs of this new shiny the best with their endeavours ... but that wound still smarts!
Something that would let people write out basic automation workflows to respond to events, similar to what Zapier or Salesforce offers to its users.
There are, of course, halting problem-style issues. I _think_ you could paper over some of that at the description level. But really you want the right kind of hooks into the actual system. A scripting tool that is just "oh but you just hit the API" is way less nice than bespoke components for your own system.
And with event systems you have the usual event propogation issues of accidentally causing a massive fan-out of events from some action and causing your sysetm to fall over.
But this is really something that someone could write out as a component for other systems and make a lot of business SaaS's automation floors way better.
You really do want to offer _something_ to users, though. The users that can write Javascript... well, Zapier lets you write Javascript. Hell, Google Cloud Platform lets you write Javascript in little script blobs, complete with Google Docs-level concurrency. This is a bit weak compared to that.
The idea being that any SaaS app could basically bolt it in and then add trigger events that match to their apps business events/entities and allow user to extend the core business logic with their own "Scripts".
Raised eyebrows is an understatement
The issue: when I choose "yearly" subscription, the page still shows price per month. So you're about to charge me every month? Despite I chosen to pay yearly. And where's the "2 months free" if I end up paying monthly??
Your starter pack costs:
$79/m (in "yearly" subscription) - so $79*12 = $948
(or $79*10 ??? because of the "2 months free")
$99/m - so $99*12 = $1188
$1188 - $948 = $240 - so it's actually more than "2 months free".
It's super confusing and I leave immediately no matter how badly I just wanted to buy it.