WebScript.io: Just choose a URL and type in a script. No servers, no deployment
webscript.io
webscript.io
Other questions, what does it mean to choose a URL? Does it host a website there which runs the script? Like a subdomain? Or am I completely thinking the wrong way here?
What can I do with your service? (like 3-5 cool examples?)
BTW I don't mean to say, "meh I won't use this cause it's not instantly clear to me", it's supposed to be constructive criticism because I think making that quick elevator pitch will get you more users! :)
And that I really prefer skimming a page of text before deciding to watch a video presentation of a service.
* "Webscript brings the simplicity and power of scripting to the web" Isn't that javascript?
* Oh I see, it's a server side language. But... this just sounds like a backend language for Getting Shit Done. Which I don't disagree with, but-- oh, can you excuse me a moment while I answer the doorbell? "Oh hi Perl, hi Node, come on in..."
* I personally do say I'm unlikely to use it because it's not instantly clear to me. I'm a sysadmin by trade so I don't think I'm the target audience, but I couldn't immediately tell what I'm meant to use webscripts for.
* I hate hate HATE watching videos. I'm sure this is a very personal thing and maybe I'm the 0.1%, but I always feel like videos are a waste of my time, or simply not the best way to communicate the message. We work with keyboards to write scripts, why would I want to see a video of that?
Okay, so I watched the first 20sec of the video. That gave me the "Aha!" moment. The first thing I thought of was the way you used to have CGI hosting servers, back in the pre-PHP days, because the majority of websites were completely static.
I don't mean to come off as mean or aggressive, but I really had trouble answering the most important question (to me): What problem is Webscripts going to solve for me? That's it.
They should probably emphasize this approach IMO
http://blog.parse.com/2012/09/11/welcoming-cloud-code-to-the... https://cloudmine.me/docs/servercode
Also, I know Lua and value it very highly, so seeing it mentioned immediately focused my attention.
Thirdly, "free" "unlimited" "renewable 7-day" trial sounds great, and $5/month for persistent does too.
For example do those other services come with storage? I can't tell.
For parse, it looks like you need to install a command line application. Not useful if your desktop is Windoz.
I doubt anyone is going to be building huge applications on webscript.io (yet!) but for simple little things (aka weekend projects) it should work great.
Can I call one webscript from another, for modularisation? And will that "lengthen" the timeout effectively, too?
If yes, then still everything is sequential, there's no possibility of parallelism, yes?
Is there any kind of versioning of the code, apart from the possiblity to load from github you mentioned on the site?
No parallelism. What's the use case you have in mind? We didn't really intend for people to do anything CPU-intensive.
No, there's no versioning.
EDIT: s/called/killed, thanks
Nothing particular yet, just assessing the possibilities.
Also, would it be possible to somehow easily download the scripts? In the Terms, you state: "customer is solely responsible for backing up customer's application and customer content." It should be easy to download content from the `storage` object, but how about the code?
Also, it seems I can choose any subdomain for any script, so subdomains are not tied to user by design?
What is the meaning of the following sentence in Terms and Conditions: "Customer has, in the case of Content that includes computer code, accurately categorized and/or described the type, nature, uses and effects of the materials, whether requested to do so by Planet Rational or otherwise." Described/categorized where, to whom, in what categories? What materials?
We figure that copy/paste is a good enough way to get your scripts out, but if there's demand, it wouldn't be too hard for us to build an export.
Once you create a subdomain, you own it, but you can have whichever ones you choose. (There's no overall subdomain for a user... a user can have as many subdomains as he/she wants.)
A lawyer wrote the Terms, not me, and I probably shouldn't try to interpret them. If you want to discuss it, send us email (support@webscript.io) and we'll help.
A number of people are mentioning JavaScript. We don't have any plans yet, but we're paying attention to the feedback.
-Maybe a potential user who isn't exactly sure what this is doing for me.
* Charge whole numbers, not 4.95. No need for the confusion. Makes the service look cheap.
* Double or triple the price (to $10-15/month). $5 vs $10 is nothing to the average dev, but it halves the number of people you need to get to ramen profitable.
* Have an expensive pro plan ($99 - $299/month). With email support, etc. If nothing else, it makes the less expensive plans more attractive.
* Don't "delete" the free scripts. "Archive" them after 7 days [it's a 7-day free trial] and you can get them all back when you upgrade to pro. If someone wants to "abuse" the system by recreating their scripts every 7 days, fine.
99% of devs will be more familiar with javascript than Lua, so I'd greatly encourage supporting that.
* We'd be happy to charge more. We have nothing to go on yet but intuition, and we think $5 is the right amount.
* This is intriguing, but I think we need to find the right value to provide in order to offer something like that.
* This is actually what we do.
Also don't underestimate the value of the more expensive plan to making your $4.95 plan look cheap. A simple answer to what could be premium is contained in your terms: Make the $99/month plan suitable for use in a production environment, as web middleware or a backend, etc by relaxing restrictions and having some sort of SLA.
We think $5 is the right amount.
* Test that assumption too :). Have table 1 with free/$5, table 2 with "Free trial", $10, $199 [pro]. Track "conversion revenue" not raw conversions.
* Large customers want to know they can get help if they need it, not be stuck in the same email queue as the $5/month hobbyists :). That peace of mind is worth a few hundred a month.
* I see -- your wording on the hover tip says "deleted" (in bold) so easy to misconstrue :). If you said "archived (and reactivated when you upgrade)" I'd feel a lot more comfortable. In my head I thought "Oh, they're deleting my scripts? So I have to decide on day 6 if I want to upgrade?".
patio11's site is full of good advice for this type of thing (http://www.kalzumeus.com/2012/09/21/ramit-sethi-and-patrick-...).
I want you guys to charge more so you are more sustainable, and therefore I can rely on you [if you go away after a year, I have to painfully migrate away to a new provider, which isn't worth the $5/month price savings. An hour of a programmer's time spent in migration, and it'd be much more, is much more expensive than the service].
I genuinely dislike their pricing model. I'm of the belief that, if one elects to offer a free tier, that tier should be usable in the real world. I should be able to write something that makes use of that service. This one-week "time bomb" precludes any real application of the service, and effectively makes this tier a trial. I agree that deleting the scripts is a bad idea, and is likely to produce a few indignant developers who forgot to either subscribe or re-create their scripts.
[I think they have a referrer program and if you tell them that kybernetikos@gmail.com recommended it to you I get something, in case you're feeling generous.]
- Certainly easier to use than https://script.google.com
- How about a UI for inspecting the storage object? And why is "storage" _not_ JSON serializable?
- The whole thing gives the impression of "for disposable, not-very-important stuff". Is that deliberate?
- Specifying all the API keys and passwords for each call to an external service by hand seems a bit tedious. Automate all the things! (Maybe with a "secure" credentials object that can be filled with a separate UI?)
- Creating a new script under an existing domain deserves a dedicated UI element, it was not obvious to me that it is possible at all, at first.
I'd say we're generally for quick-and-dirty, not necessarily disposable or even not-very-important. But I may be splitting hairs here.
We've been thinking a bit about a sort of global store for credentials. I'm curious to see what people end up doing with Webscript and how often they're typing the same credentials into multiple scripts.
Thanks for pointing out the non-obviousness of creating new scripts in the same subdomain. We'll take a look.
1. What support have you for Unicode? This is Lua's Achilles heel.
2. There's an issue with json.stringify - the script
t={11, ["1"]=11}
return json.stringify(t)
{"1": 11, "1": 11}
Interesting point about json.stringify. We should take a harder look at these kinds of cases. What would you expect the output to be? In general, JSON can't represent a lot of things that Lua tables can, so I don't expect json.parse(json.stringify(T)) to always return T. That said, anywhere we can do something more sensible, we should, so thanks for this feedback (and tell us more).
json.stringify: I suggest escaping strings by some character that cannot occur in identifiers or numbers, e.g., ":". Then the above would map to { "1" = 11, ":1" = 11}.
Another question: does your mail function send mail from your server? How do you avoid users sending spam?
We don't run an SMTP server, so the email (port 25 traffic) comes from our servers but not from our SMTP server. Even still, we will probably have to limit port 25 use to avoid blacklisting. We're sorting that out.
How about representing Lua tables by arrays with an object in position 0? Then { 11, ["11']=11} would map to [{"11"=11}, 11]. The extra layer of depth is annoying, but the semantics is closer to what you want and you avoid collisions between strings and array indices.
We'll keep thinking about this, but I don't think it's sensible to try to encode {11, ["11"]=11} at all. That's neither an array nor a dictionary, and so it doesn't have a natural JSON representation. I'm inclined to make it an error, but right now we try to be generous in attempting to encode.
"A JSON text is a serialized object or array."
Now I don't know why I thought this wasn't allowed.
Flagging errors in cases with seems to be a good way to handle this kind of problematic input. It's surely better than having applications have nonsensical data if they are given peculiar input.
Our goal is to never have to cut someone off for what seems like legitimate use.
In that case, can I recommend that you determine what your costs will be and ensure that you charge, at each tier of usage, enough that you will be able to continue providing your service at a profit to these large-scale users?
Tiny! You should have tiers, and not "unlimited, but only where that means enough for a small amount of single-users"
@aaronblohowiak, just because we reserve the right to shut something down doesn't mean that we will.
We'll learn from real use what people actually do. We have our own ideas about what we expect the use cases to be, but we may be completely surprised by the popular uses. If our pricing model doesn't make sense for what people want to do with Webscript, we'll certainly adjust. Thanks for the feedback.
Out of curiosity, what encouraged you to choose Lua instead of JavaScript or another server-side language?
If we get a lot of feedback about it, we can definitely change course on this later by adding JavaScript and/or other languages.
lease.acquire('count')
local count = storage.count or 0
storage.count = count + 1
lease.release('count')
return {count=count}
This appeals to me, because I find its much easier to express myself in code. Zapier is awesome because it makes it so non-programmers can link apps up, but as a programmer I'd rather work in pseudocode* like this instead, and this still keeps me from having to run cron jobs or respond to API changes.
Very cool!
*I realize its Lua, but I mean pseudocode to where I can just say twilio.sms and that magically happens.
(I'm a founder of Webscript.)
$5/mo is cheap enough to warrant an impulse purchase, though. Good on you guys.
Maybe you should allow different languages? Lua is quite similar to JS, so you can probably port the same API to it, or other languages?
(That's my startup's other product.)
That said, my startup's other product (www.site44.com) is great for serving up content and does support custom domains. We plan to add support to Site44 for forwarding API calls to Webscript. So you could build a full HTML app with content served from Site44 and API calls handled by Webscript, all with a custom domain.
For email, we just support SMTP. You have to bring your own server and credentials. Our examples are using Amazon SES, but anything would work (e.g. SendGrid or even GMail).
Also, are you using LuaJIT?
No, we're not using LuaJIT for now.
How do you handle 'a = " "; while true do a = a .. a end'? Do you spawn individual processes with process limits? Which version of lua are you using? Why not luajit2?
It sounds like we're doing some similar things. Custom allocators are definitely the way to go to limit memory usage. We also use process-level isolation to limit the amount of execution time.
We're Lua 5.1 and not luajit2 for now for vague technical integration reasons that we may very well revisit as this takes off.
I imagine it must have to do with easy of sandboxing or something, but why Lua over Python for scripts?
Going past that, the video takes way too long. The best parts of the API are quite similar to request and express in node.js land. The website is vanilla Bootstrap with a few supported customizations to make it stand out more. There's little in it that shows that the team has the level of skills needed to write a platform.
I have to say I think that's in the eye of the beholder. What's wrong with a simple name for site, even if it has a generic meaning already?
"There's little in it that shows that the team has the level of skills needed to write a platform."
What would you want to see on the site that would show this better? Why does using Bootstrap matter, or was that an unrelated observation?
In this particular case, I feel that it's generic enough that it can be confusing/not super memorable. For those practical reasons I think this could use a better name, but I'm not going to write-off a project just because it's name is odd.
Is the demo not enough? It's paradoxical having the skill of building something that is new.