It's not immediately clear what this service does. Sure, I could watch the whole 5 minute video but I'd rather get an idea first :) So I wtched the first 15 seconds, which answered my first question: what kind of script? (answer: it's LUA scripts).
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.
I'd like to add my +1 to this, I felt pretty much all of those sentiments.
* "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.
I'm one of Webscript's founders, and I was pleasantly surprised to see this here. We just launched this morning, and I'm happy to answer any questions.
* 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.
I am in agreement about the inclusion of JS. It's a much more widespread and accessible language. However, I disagree on the price suggestion. $15 is a non-trivial amount and, it seems as though this service offers a slight convenience, not any sort of major, unique or ground-breaking functionality. I might pay $5 for this– or, maybe not– but I almost certainly won't pay $15 for such a service. (I might be in the minority as to how much I'd be willing to spend for this, especially considering I'm in dire financial straits. Despite that, I still feel as though $15 would exceed the amount of value that most people could reasonably wring from this 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.
* No prob :). The beauty of the web is experimentation. Use VisualWebsiteOptimizer.com and run some quick A/B tests with two pricing tables [one at 4.95, another with $5].
* 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?".
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].
What you want to avoid with this sort of AB testing is the same person seeing multiple prices. The easiest, decently close approximation is just to split the page served by geocoded IP. The regions should be split randomly up-front.
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.
I currently pay $5 per month for a vps with unlimited traffic on which I run a node js server. I might possibly pay 5$ for this service, but certainly no more for applications that aren't going to have >10k users.
vpscheap.net They have plans starting from 2$ a month, but I need more RAM than that plan has. I think that $60 per year is exactly right for what I need, and they will let you pay a year up front if you want - it would make an excellent Christmas present for anyone geekily inclined.
[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.]
I'm interested in what you are doing here. What is your ideal customer? What should they expect from the platform and what do you expect it to be used for?
-Maybe a potential user who isn't exactly sure what this is doing for me.
Most of the sandboxing just comes from using embedded Lua and only whitelisting a small number of functions. We also do a little process-level isolation to prevent runaway processes.
Nice, It would be awesome if one could get full capability of a programming language. I have been planning to build something like this but was stuck because of the sandboxing issue.
Hm; to me personally, one advantage is that I immediately understand the idea and usage method of their service, while reading the links you provided I can't grasp what they're trying to communicate, unfortunately.
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.
I agree - the simplicity of the service is great. Can immediately see what it does.
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.
You can make HTTP requests, so you can call another script from your script, but the calls are synchronous and won't increase your timeout, so the original script will still get killed after ten seconds.
No parallelism. What's the use case you have in mind? We didn't really intend for people to do anything CPU-intensive.
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.
Amazing! I just want to add my vote for javascript support. I am already invested in javascript for client and server development that having a javascript scripting engine like this would be heaven. Again, great job!
- 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.
There is actually UI for inspecting storage. As long as you have no more than 20 keys stored, it shows up on the left-hand side of the page, but you have to refresh the page to get the latest. My excuse for this not being discoverable and automatic: we just launched today. :-)
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.
Thanks. We don't do anything special to help or hinder Lua's handling of Unicode. In general, Lua strings store bytes. This is handy when dealing with something like file uploads, but it's not always what you want for other text encodings. If you have any suggestions for what we should do (or what we should document), I'd love to hear them.
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).
Unicode: I wish I could say "the right way to handle Unicode in Lua is to X", but I haven't found X yet. slunicode at least allows you to do string matching on UTF8 strings: http://files.luaforge.net/releases/sln/
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?
I'm confused about your stringify suggestion... I think the primary use of json.stringify is to send that JSON to some API or back to a browser, but nobody else would be able to make sense of the ":1". Am I misunderstanding?
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.
OK, but who will make sense of encoding the array {2,3,5} by the object {"1"=2, "2"=3, "3"=5}? Shouldn't you be trying to represent arrays by arrays?
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.
I'm not sure what you mean. json.stringify {2,3,5} == '[2, 3, 5]', which is correct, isn't it? (Strictly, JSON has to always have a dictionary on the outside, but it's fairly standard to allow this.)
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.
I had misunderstood the semantics of json.stringify - I thought tables always mapped onto dictionary objects, even if they were arrays. The semantics I suggested is an invertible way of handling that, though the inverse will be odd for JSON arrays whose 0th element is a dictionary object.
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 Terms (https://www.webscript.io/terms) do spend a little time defining "unlimited." We didn't want people to worry about it, so we went with unlimited, but as you point out "unlimited" is always a lie when finite resources are involved.
Our goal is to never have to cut someone off for what seems like legitimate use.
> 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?
(Sorry, can't reply to the real comment, too nested.)
@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.
We probably need to write a FAQ for this. Until then, the short answer is that Lua is well-designed and well-understood as an embedded language (how we use it). That means it was easy and fast for us to integrate.
If we get a lot of feedback about it, we can definitely change course on this later by adding JavaScript and/or other languages.
I haven't ever used Lua, but I think it's simple and easy enough to pick up and learn quickly, so personally it doesn't bother me at all. I'll definitely be using this service when I have the need for it.
On the homepage, there is an example of an incrementing counter. Is this actually an atomic operation, or if two users hit the button at the same time, will it potentially only increase the count by 1?
Is it fair to call this a similar service to Zapier that runs at a lower level of abstraction?
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 would imagine that Lua was much, much simpler to pick apart and integrate into a system like this (from my experience using Lua) than trying to use a full JavaScript engine. A full JavaScript engine would be less lightweight, harder to implement and maybe even harder for end users. That's just my conjecture, anyway ;)
I'm not a fan of the pricing model - deleting user data after a period of time is a bit harsh in any circumstance, but I don't see an alternative. I'd say cap the number per account, but then you can get multiple account abuse issues.
$5/mo is cheap enough to warrant an impulse purchase, though. Good on you guys.
The fact that Lua isn't very much used will get you less users. I feel like something like JavaScript would've been more appropriate for this kind of thing.
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?
We don't plan on supporting custom domains, because we don't think people will serve up content directly from these scripts. (We think of them more as APIs, so typically invisible to end-users.)
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.
It is actually not about serving content. Custom domain makes the fail over much easier. For example, someone uses webscript.io as his app backend. If webscript.io goes down for whatever reason, he can simply point the URI to a backup server(provide he has one) if he uses a custom domain. Without custom domain all he can do is wait.
Would you mind sharing a bit about the architecture of this project? What tools and technologies & language (beside lua) did you use? I'm guessing you just need custom routes (all the URLS are on your domain?) rather than custom DNS. How are you handling sending emails, for instance? (did you plug into an email as a service provider?)
The whole thing is a Python app, written with Flask. As you said, we do custom routing to map URLs to scripts, which we then load up in a Lua VM and execute with conventions for how we pass in the request and interpret the return value.
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).
Great to see another lua based service. I'm running http://geolua.com/ which also uses Python (and even gunicorn) for the web interface and lua (in a custom libevent based server) for running user provided lua code. I sandboxed lua using chroot, a custom allocator function, runtime limits using signals and an "outer" lua environment which interfaces with the python code. The inner environment should be safe. I guess :-)
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.
As far as I'm aware, Python is vastly more popular for scripts than Lua. At first, I assumed you were just Lua guys, but apparently you're a Python fan as well, at least to some degree.
I imagine it must have to do with easy of sandboxing or something, but why Lua over Python for scripts?
This isn't called webscript.io. It's called "webscript". It's beyond pretentious. The words "web" and "script" are extremely generic and common in software development. To put them together and not only use it as a product name but try to introduce it as a new term rubs me the wrong way. (The phrase "Webscripts are a fast and easy way to receive those webhooks" gives me the idea that they intend to do just that.)
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 agree. I don't think that it's bad to choose a simple name.
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.
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.