10 ms·

Show HN: Autocode – Automatically generate API code for SaaS apps

247 points by keithwhor 7y ago

veeralpatel979 7y ago
Hey - great work! This project can save me a lot of work writing integrations, which I find tedious at times, so I'll take a look at it. One piece of feedback: it's confusing that the org's name is Polybit, the site is https://stdlib.com/ https://stdlib.com/, and there's also something called Autocode. Please consider choosing one name for all of them (Standard Library, preferably).
- keithwhor 7y ago
  Polybit Inc. is an implementation detail. Standard Library is the platform / registry and Autocode is the IDE. We’ll keep these two. Outside of legal docs and filings you probably won’t see Polybit that much at all :).
keithwhor 7y ago
Hey all, Keith here, founder and CEO of Standard Library (we made this <3). The problem we're focused on solving is simply -- building modern integration software is too difficult. (1) For professional engineers, it's mundane work nobody wants to do and (2) for non-developers, best-in-class integration tools that rely on visual workflows just don't cut sophisticated use cases for modern businesses, they often need some code. Autocode solves these problems by providing an IDE that professional engineers can use to ship simple integrations in minutes and new (or "low code") devs can use to automatically generate API integration code without needing to know much to start with. We provide a ton of features: an API registry, API autocomplete, code generation, serverless hosting for your APIs, an in-browser execution engine for your workflows, observability + logging, complete revision history. It's kinda like Heroku and Zapier had a really, really ambitious child. We've been at this, somewhat quietly, for four years and Autocode is what we're the most proud of to date. We've been very fortunate to have the opportunity to work with some of the best companies in the industry to support our vision -- Slack and Stripe have been investors since (nearly) day one. That said, we're a small team -- just five people -- and we still have a hell of a lot of work ahead of us. We would love thoughts and feedback! YouTube video here for anybody that wants to see the full demo: https://www.youtube.com/watch?v=ha3C0X3Vyi0 https://www.youtube.com/watch?v=ha3C0X3Vyi0 Thanks so much! :)
- mclightning 7y ago
  Very cool stuff, so I want to give some feedback hoping it will succeed :) 1 - Some playground prior to signup, similar to Runkit could get you more users. 2 - Some simpler signup by Github etc. would get you more users. 3 - Right click is taken over by the site, which blocks LastPass context menu which adds another layer of difficulty to signup. Good luck, thanks
  - keithwhor 7y ago
    Thank you! Ooh! Right click / context menu. I gotta fix that. D'oh. I think there are different schools of thought re: providing a playground. We certainly have done that before with smaller launches. Our experience (anecdotally, I haven't measured exactly) is that while "playground" type experiences can sometimes increase signup volume, they tend to result in lower engagement rates overall. I believe the basic underlying hypothesis is that if you can solve a problem somebody is having and they know that, they don't care how it works: they'll sign up and figure it out. However, if you provide a playground, you artificially select for a much higher proportion of folks who enjoy the novelty of new technology / products and aren't necessarily likely to stick around. Food for thought, anyway. Don't have raw numbers here.
    - arxpoetica 7y ago
      Yes and no. This particular product probably has broader appeal than you think— For a broader audience you'd definitely want to dumb down the entry point. If you're still in the smaller audience/specific traction stage, it probably makes sense to stay more technical.
- ryanianian 7y ago
  Really cool product and a well-done demo. I noticed that the autocomplete didn't work for the co2 service (e.g. host says "I think it's response.ppm" rather than ppm being suggested. This despite the co2 service (presumably) being developed and published with autocode as well. The pervasive auto-complete and composability make the offering really compelling, but it's unfortunate that (at least in that example) the two don't work together. On a related note it would be lovely to use (or allow) typescript and publish TS declaration files and thin generated clients for APIs deployed on autocode. These are both minor nits in an otherwise impressive offering. Both are likely "next iteration" features since it seems like you've already solved a lot of the hard problems and these would be connecting existing dots together.
sarakayakomzin 7y ago
>CEO of Standard Library ah, so you're the asshole who has made things impossible to search for based on intention. Thanks for that!
jedieaston 7y ago
Can I run this code outside of stdlib somehow or does it only work there? Just have to plan around if stdlib went down or something.
- keithwhor 7y ago
  It's just JavaScript. It's absolutely portable. The APIs that run atop us use the Standard Library registry, you can think of it like a package manager / proxy of sorts. But if all you're doing is writing logic to connect things, you could conceivably host it on your own after you prototype with us -- you'll just lose some of the goodies we provide like automatic webhook signing. Also, our gateway / schema specification is open source and portable as well: https://github.com/FunctionScript/FunctionScript https://github.com/FunctionScript/FunctionScript
  - eropple 7y ago
    Why should somebody use this instead of OpenAPI?
    - keithwhor 7y ago
      They’re compatible. FunctionScript is just a system for easily adding schemas to JavaScript functions inline. We needed to write a specification that made it easy for people to build Serverless HTTP endpoints strictly from within JS.
      - eropple 7y ago
        That's not an answer, though. Why should somebody use any of this over an OpenAPI specification? I'm biased, as I've written two web frameworks that both generate OpenAPI documentation trivially and inline (for Ruby[0] and for NodeJS[1]), but I've looked pretty deeply into the project you're offering here and I'm not seeing the value over existing, open, collaborative solutions. I have a strong interest in APIs being very good and very accessible (as those links hopefully demonstrate), but I also have a very strong interest in APIs not being intermediated unnecessarily. What does any of this do that can't be effectively done with current, broadly accepted technologies? Put another way, and forgive the bluntness: why should people give your company a vig for this? [0] - https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby [1] - https://github.com/eropple/nestjs-openapi3 https://github.com/eropple/nestjs-openapi3
_bxg1 7y ago
Wow, impressive that they got their hands on stdlib.com
_bxg1 7y ago
I've developed a personal sniff-test for software development work that exists right now but isn't actually very intrinsically hard. Those areas are ripe for products like this that simplify or partially automate the process. It was only a matter of time before "glue code" got streamlined.
smcguinness 7y ago
Very cool. I just signed up, but was a bit frustrated by the hijacked experience for sign-up as it broke my LastPass plugin to generate and save my password. Just wanted to point this out.
- keithwhor 7y ago
  That’s great feedback, thank you! We’ll definitely see if we can test across a few different password managers / signup experiences to make sure it’s a smoother process.
  - bestest 7y ago
    Same here. Was expecting Safari to suggest a password, yet it did not. By inspecting the cause I was appalled to see custom inputs! Mother of dragons!
    - chairmanwow1 7y ago
      Honest question: what would compel someone into making a decision like this?
      - keithwhor 7y ago
        You mean why would somebody build custom inputs? We need our inputs on Autocode to do a whole ton of custom stuff; support emoji insertion, allow for an autocomplete dropdown, support typeahead autocomplete, have multiple layers for syntax highlighting (code editor). So we roll our own components for a lot of this stuff. We don't have problems with every password manager; the raw HTML input element is still there. I think it's probably an easy fix, we just gotta look into it.
        wise_young_man 7y ago
        None of those use cases apply for authentication though right? Or are people using emojis for logins now? Even if they were, standard browser form input I’m sure would handle them fine natively.
avip 7y ago
Preliminary feedback: it took me 5s and single downscroll to grasp what this does and why it may be useful. In current climate this by itself is a remarkable achievement so wanted to point it out.
- keithwhor 7y ago
  Thank you so much! I will say it hasn’t been a small effort. We’ve been working on the suite of products that have led up to Autocode for years. At this point I’ve personally done hundreds of 1 - 2h sessions with customers to figure out what works and what doesn’t, and I think that has sort of enabled us to focus on the features that matter and why they’re important. As you play around, I’d be interested to learn what you like and what you think is missing!
jasonhr13 7y ago
horizontal scrollbar showing on chrome
- keithwhor 7y ago
  Do you mind sharing a screenshot and your Chrome version?
  - davidweatherall 7y ago
    Not the same guy but https://i.imgur.com/BspPL2H.png https://i.imgur.com/BspPL2H.png https://whatsmybrowser.org/b/JZAUZ62 https://whatsmybrowser.org/b/JZAUZ62 Appears to be caused by using 100vw, which doesn't factor in the width of the scrollbar. Notably on the selectors: [control="LandingPage"] .hero-header and [control="LandingPage"] .platform-information .info-section
    - keithwhor 7y ago
      Aha. So likely a Windows issue / those with visible scrollbars enabled? We'll add this to the bugs list. Thanks for the info!
      - yoavm 7y ago
        Linux + Firefox too :)
neeeeees 7y ago
Very cool product, and could be useful for learning also. I suspect the fundamental [business] limitation of a tool like this is that those willing to pay recurring big bucks (medium to large software shops) tend to rely minimally on 3rd party APIs. Those who benefit the most (weekend projects, learning, rapid prototyping) where time is of the utmost value generally wouldn’t end up using it enough to become recurring customers.
- keithwhor 7y ago
  I think you’re vastly underestimating the B2B API tooling space. Large enterprises and SMBs run tons of things atop SaaS APIs, often held together with staples and duct tape. We have businesses that run on top of us today that are only just beginning to automate huge chunks of their operations with us, Airtable, Slack and other tools. Previously these things were hacked together in an unmaintainable fashion. It’s a big space.
crabasa 7y ago
This is pretty interesting! I've been working on a web scraping API that returns Open Graph information for a URL, and decided to see how easily I could build and deploy this using Autocode. In about 15 minutes I ported the code I had written to Autocode. A few things that felt pretty magical: - auto recognized and imported required NPM modules to my project - ability to run code in-line (via Runkit) - auto-generated documentation You can see the docs for this API here: https://stdlib.com/@carter/lib/open-graph-api/ https://stdlib.com/@carter/lib/open-graph-api/ ...and can see an example API GET request which returns the Open Graph information for one of the top stories on HN today: https://carter.api.stdlib.com/open-graph-api@dev/api/?url=https%3A%2F%2Fgithub.blog%2F2020-02-12-supercharge-your-command-line-experience-github-cli-is-now-in-beta%2F https://carter.api.stdlib.com/open-graph-api@dev/api/?url=ht... I'm pretty curious to see where this product goes! It would be super cool to be able to easily tack on auth and a pricing model for heavier (enterprise) users of this API.
- keithwhor 7y ago
  Thanks for the feedback! We do indeed have custom auth and pricing in the works :). Can’t give an outline on delivery because we have so much other stuff to take care of, but the API registry is already built to handle these use cases.
BillSaysThis 7y ago
Where are the list of existing integrations?
- keithwhor 7y ago
  You can view connector APIs at https://stdlib.com/search/ https://stdlib.com/search/ -- if there's something we don't offer, you can build your own Connector APIs as well. Expect this list to grow substantially: part of our model is that we work with large API companies to ensure they're supported on the Standard Library registry.
Jiger104 7y ago
As a power user of no code apps like zapier. This is really amazing, for some of the more complex work flows I've had to write python code and initiate via lambda functions. This seems like it would alleviate that need completely. Would love to see the ide support python as well as js
leesalminen 7y ago
Looks like a hug of death “service is unavailable” with an on-screen JS stack trace.
- keithwhor 7y ago
  Try again? Everything is looking good for us right now. We run on entirely serverless architecture so any failures should be completely transient. I'll get my co-founder to pay attention and see if he notices anything out of the ordinary.
howmayiannoyyou 7y ago
Excellent. I can FINALLY start migrating away from Zapier.
- keithwhor 7y ago
  We'd love to help! Feel free to e-mail us (contact@stdlib.com) if you have any questions. We also have a Slack community that you can reach by clicking the Community -> Slack tab at the top of autocode.com. :)
  - toomuchtodo 7y ago
    Is workflow import on the roadmap if you’re authenticated to your low/no code provider? With many, you can get the workflow out as a JSON blob their own frontend consumes. Love the product! Very cool!
    - keithwhor 7y ago
      That's a very good idea. We'll definitely be looking into it.
- statictype 7y ago
  What's bothering you about Zapier?
SahAssar 7y ago
Dev1: "Is that in stdlib?" Dev2: "Yeah" Dev1: "Then why isn't it working?" Dev2: "Because unlike EVERY OTHER THING called stdlib you need to install this one because it's not actually a stdlib" Dev1: "..."
- keithwhor 7y ago
  So, fun fact: our organization name is actually Polybit Inc. -- we do business as "Standard Library" because the registry we've built is pretty much core to everything we do. I expect the easy way to get around this is for folks to refer to us, when speaking technically, as "stdlib.com" ("standard lib dot com").
  - deleted 7y ago
    [deleted]
  - SahAssar 7y ago
    How would this work in languages where stdlib is an established way of talking about the actual built in standard library like https://devguide.python.org/stdlibchanges/ https://devguide.python.org/stdlibchanges/ vs https://github.com/stdlib/lib-python https://github.com/stdlib/lib-python ? Also you aren't worried at all about confusion or typosquatting (or what you would call it with a common name) with all the variations of standardlibrary, standardlib, stdlib? The npm package name standardlibrary was open, let me know if you want it transferred. No charge or bullshit, of course. I just claimed it because it was free and I guessed that somebody would typosquat it sooner or later considering your company name. If not I'll just release it
    - keithwhor 7y ago
      We're not particularly concerned about typosquatting for now. The name is based on the `.com`, i.e. all APIs / workflows built on Standard Library go to `username.api.stdlib.com`. The packages we use in NPM, RubyGems and Python are just called `lib`. The way 99.99% of developers have used us to date is starting with our in-browser or CLI tooling which installs / requires the correct package automatically. So I think that removes some of the risk you're talking about. :) You can hold on to the NPM package for now if you'd like! That's a good one. If we do find typosquatting becomes an issue, do you mind if I reach out?
samblr 7y ago
It is not difficult to see there is considerable effort spent building this. However, why would anybody use it ? I see following issues - Editors are getting mighty powerful. So why would a developer trade their favourite tool to your editor in browser ? I wouldn't switch to another editor even somebody is going to pay me more. - The process-and-cost of deploying backend has gotten way easier-and-so-cheaper - why would anybody write trivial code in autocode and then deploy on your servers ? Having said the above - I liked autocomplete provided for different apis in your editor. Sorry, if that was harsh.
- zerkten 7y ago
  I think the real market for software like this is large enterprises. There are lots of part-time developers or folks that need things glued together. Solutions like this are quite attractive to those organizations because the limited technical expertise they have is focused elsewhere. The process and cost of deploying backends is still significant for them. It is only a mostly solved problem for startups and medium-sized organizations. There is validation for this with Microsoft's "Power" platforms (Flow, PowerApps, etc) effort. This tool seems to have attached itself to competing platforms (Slack, etc.) Right now, an enterprise customer probably wouldn't get all of the pitch since the examples don't tie together their boring tech, but I guess the pitch is that they'll invest in that later.
- keithwhor 7y ago
  No problem! It's not harsh at all. I think what a lot of savvy professional developers don't necessarily grok is that they're just the tip of the iceberg, or the top of the pyramid, in terms of the types of people writing and delivering solutions with software inside of organizations. Let's say BIGCO pays you $X00k to build big, awesome production systems. There are 10x as many professional developers as you building small, hacky transient code within enterprise cos and SMBs and 100x as many tinkerers, creatives, admins, product managers and more just slapping together Airtable and Zapier as fast as possible to automate their jobs. Autocode isn't designed for the top of the pyramid. I mean, all the features can (and should!) certainly be used by folks at the top. You'll find that for a huge # of simple tasks -- tasks that don't matter where they live, like one-off daily crons -- Autocode is just plain faster. But the important thing to think about is the folks a bit downstream of the "top", the ones implementing solutions less focused on architecture and more focused on solving immediate business problems... that's where Autocode is designed to play well. Hope that helps!
deleted 7y ago
[deleted]
zebnyc 7y ago
Keith, do you plan to support other languages beyond javascript? This brings me back to 2004 when I used to work for Safeco. Business analysts / insurance agents would write business rules in VB.NET. Engineers would write application / integration code which would execute the business rules (both languages compiled to the .NET runtime so were compatible)
- keithwhor 7y ago
  Candidly: not immediately. There’s a lot of stuff we do that’s a Hard Problem (TM) to get working across a bunch of different languages, mostly associated with static analysis of code / Abstract Syntax Tree parsing. We’ve foregone multiple language support for now to focus on enabling people to be deeply productive with JavaScript by being highly opinionated.
Noumenon72 7y ago
So the idea is like, everyone who wants their app to integrate with Stripe has to write their own code that goes "response = /connect/to/stripe/${accountNum} + (json payload)", and this does that for you?
superasn 7y ago
Nice concept. Please think about adding a showcase to your homepage, i.e made with autocode. This will not only help it make it easier to understand but also show users the possibilities of what can be done with your platform.
- keithwhor 7y ago
  It’s next on our list! We support deploying from GitHub already, we just had to chop a few desired homepage features to make sure we shipped this on time. :) Coming soon!
tylerrobinson 7y ago
This is really cool! As a PM I’m somewhere in your “100x other people trying to automate stuff” category of user. My question is, would many of your features work if provided as a plugin for an existing favorite IDE? Having to use the proprietary IDE would probably be my sticking point, as it’s not easy for me to understand how or if I could start using this with an existing project in VSCode, say.
- keithwhor 7y ago
  Our team is literally itching to build plugins. E-mail us and let us know what you want!
  - dijital 7y ago
    Would the Language Server Protocol make sense for your approach here? https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/ https://microsoft.github.io/language-server-protocol/overvie... Really interesting concept for exploring a new API, but I don't see myself dropping my IDE of choice for it.
zelly 7y ago
Isn't this what GraphQL was designed to solve?
codeulike 7y ago
wsdl, right?
gitgud 7y ago
Interesting project, I went and looked at the [1] npm module "lib" (side note: well done, you guys must have bought it as it was first published 9 years ago) I saw in the API that you reference in the following manner, which stunned me! const lib = require('lib'); lib.yourUsername.hostStatus(...) How could you have a dynamic property on a synchronous object like that?! Well it turns out in the [2] source code, you can have some kind of "anonymous getter"? get: (target, name) => { return LibGen(...); } I've never seen this before and can't find any documentation about it... [1] https://www.npmjs.com/package/lib https://www.npmjs.com/package/lib [2] https://github.com/stdlib/lib-node/blob/bd7cada7ae366c10e316795300078182700bd87b/lib.js#L31 https://github.com/stdlib/lib-node/blob/bd7cada7ae366c10e316...
- keithwhor 7y ago
  It’s referred to as a Proxy (type of Object) and they’re relatively straightforward and a newer addition to JavaScript. :)

247 points by keithwhor 7y ago

Hey - great work! This project can save me a lot of work writing integrations, which I find tedious at times, so I'll take a look at it. One piece of feedback: it's confusing that the org's name is Polybit, the site is https://stdlib.com/ https://stdlib.com/, and there's also something called Autocode. Please consider choosing one name for all of them (Standard Library, preferably).

keithwhor 7y ago
Polybit Inc. is an implementation detail. Standard Library is the platform / registry and Autocode is the IDE. We’ll keep these two. Outside of legal docs and filings you probably won’t see Polybit that much at all :).

keithwhor 7y ago

Hey all, Keith here, founder and CEO of Standard Library (we made this <3). The problem we're focused on solving is simply -- building modern integration software is too difficult. (1) For professional engineers, it's mundane work nobody wants to do and (2) for non-developers, best-in-class integration tools that rely on visual workflows just don't cut sophisticated use cases for modern businesses, they often need some code. Autocode solves these problems by providing an IDE that professional engineers can use to ship simple integrations in minutes and new (or "low code") devs can use to automatically generate API integration code without needing to know much to start with. We provide a ton of features: an API registry, API autocomplete, code generation, serverless hosting for your APIs, an in-browser execution engine for your workflows, observability + logging, complete revision history. It's kinda like Heroku and Zapier had a really, really ambitious child. We've been at this, somewhat quietly, for four years and Autocode is what we're the most proud of to date. We've been very fortunate to have the opportunity to work with some of the best companies in the industry to support our vision -- Slack and Stripe have been investors since (nearly) day one. That said, we're a small team -- just five people -- and we still have a hell of a lot of work ahead of us. We would love thoughts and feedback! YouTube video here for anybody that wants to see the full demo: https://www.youtube.com/watch?v=ha3C0X3Vyi0 https://www.youtube.com/watch?v=ha3C0X3Vyi0 Thanks so much! :)

mclightning 7y ago
Very cool stuff, so I want to give some feedback hoping it will succeed :) 1 - Some playground prior to signup, similar to Runkit could get you more users. 2 - Some simpler signup by Github etc. would get you more users. 3 - Right click is taken over by the site, which blocks LastPass context menu which adds another layer of difficulty to signup. Good luck, thanks
- keithwhor 7y ago
  Thank you! Ooh! Right click / context menu. I gotta fix that. D'oh. I think there are different schools of thought re: providing a playground. We certainly have done that before with smaller launches. Our experience (anecdotally, I haven't measured exactly) is that while "playground" type experiences can sometimes increase signup volume, they tend to result in lower engagement rates overall. I believe the basic underlying hypothesis is that if you can solve a problem somebody is having and they know that, they don't care how it works: they'll sign up and figure it out. However, if you provide a playground, you artificially select for a much higher proportion of folks who enjoy the novelty of new technology / products and aren't necessarily likely to stick around. Food for thought, anyway. Don't have raw numbers here.
  - arxpoetica 7y ago
    Yes and no. This particular product probably has broader appeal than you think— For a broader audience you'd definitely want to dumb down the entry point. If you're still in the smaller audience/specific traction stage, it probably makes sense to stay more technical.
ryanianian 7y ago
Really cool product and a well-done demo. I noticed that the autocomplete didn't work for the co2 service (e.g. host says "I think it's response.ppm" rather than ppm being suggested. This despite the co2 service (presumably) being developed and published with autocode as well. The pervasive auto-complete and composability make the offering really compelling, but it's unfortunate that (at least in that example) the two don't work together. On a related note it would be lovely to use (or allow) typescript and publish TS declaration files and thin generated clients for APIs deployed on autocode. These are both minor nits in an otherwise impressive offering. Both are likely "next iteration" features since it seems like you've already solved a lot of the hard problems and these would be connecting existing dots together.

sarakayakomzin 7y ago

>CEO of Standard Library ah, so you're the asshole who has made things impossible to search for based on intention. Thanks for that!

jedieaston 7y ago

Can I run this code outside of stdlib somehow or does it only work there? Just have to plan around if stdlib went down or something.

keithwhor 7y ago
It's just JavaScript. It's absolutely portable. The APIs that run atop us use the Standard Library registry, you can think of it like a package manager / proxy of sorts. But if all you're doing is writing logic to connect things, you could conceivably host it on your own after you prototype with us -- you'll just lose some of the goodies we provide like automatic webhook signing. Also, our gateway / schema specification is open source and portable as well: https://github.com/FunctionScript/FunctionScript https://github.com/FunctionScript/FunctionScript
- eropple 7y ago
  Why should somebody use this instead of OpenAPI?
  - keithwhor 7y ago
    They’re compatible. FunctionScript is just a system for easily adding schemas to JavaScript functions inline. We needed to write a specification that made it easy for people to build Serverless HTTP endpoints strictly from within JS.
    - eropple 7y ago
      That's not an answer, though. Why should somebody use any of this over an OpenAPI specification? I'm biased, as I've written two web frameworks that both generate OpenAPI documentation trivially and inline (for Ruby[0] and for NodeJS[1]), but I've looked pretty deeply into the project you're offering here and I'm not seeing the value over existing, open, collaborative solutions. I have a strong interest in APIs being very good and very accessible (as those links hopefully demonstrate), but I also have a very strong interest in APIs not being intermediated unnecessarily. What does any of this do that can't be effectively done with current, broadly accepted technologies? Put another way, and forgive the bluntness: why should people give your company a vig for this? [0] - https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby [1] - https://github.com/eropple/nestjs-openapi3 https://github.com/eropple/nestjs-openapi3

_bxg1 7y ago

Wow, impressive that they got their hands on stdlib.com

_bxg1 7y ago

I've developed a personal sniff-test for software development work that exists right now but isn't actually very intrinsically hard. Those areas are ripe for products like this that simplify or partially automate the process. It was only a matter of time before "glue code" got streamlined.

smcguinness 7y ago

Very cool. I just signed up, but was a bit frustrated by the hijacked experience for sign-up as it broke my LastPass plugin to generate and save my password. Just wanted to point this out.

keithwhor 7y ago
That’s great feedback, thank you! We’ll definitely see if we can test across a few different password managers / signup experiences to make sure it’s a smoother process.
- bestest 7y ago
  Same here. Was expecting Safari to suggest a password, yet it did not. By inspecting the cause I was appalled to see custom inputs! Mother of dragons!
  - chairmanwow1 7y ago
    Honest question: what would compel someone into making a decision like this?
    - keithwhor 7y ago
      You mean why would somebody build custom inputs? We need our inputs on Autocode to do a whole ton of custom stuff; support emoji insertion, allow for an autocomplete dropdown, support typeahead autocomplete, have multiple layers for syntax highlighting (code editor). So we roll our own components for a lot of this stuff. We don't have problems with every password manager; the raw HTML input element is still there. I think it's probably an easy fix, we just gotta look into it.
      - wise_young_man 7y ago
        None of those use cases apply for authentication though right? Or are people using emojis for logins now? Even if they were, standard browser form input I’m sure would handle them fine natively.

avip 7y ago

Preliminary feedback: it took me 5s and single downscroll to grasp what this does and why it may be useful. In current climate this by itself is a remarkable achievement so wanted to point it out.

keithwhor 7y ago
Thank you so much! I will say it hasn’t been a small effort. We’ve been working on the suite of products that have led up to Autocode for years. At this point I’ve personally done hundreds of 1 - 2h sessions with customers to figure out what works and what doesn’t, and I think that has sort of enabled us to focus on the features that matter and why they’re important. As you play around, I’d be interested to learn what you like and what you think is missing!

jasonhr13 7y ago

horizontal scrollbar showing on chrome

keithwhor 7y ago
Do you mind sharing a screenshot and your Chrome version?
- davidweatherall 7y ago
  Not the same guy but https://i.imgur.com/BspPL2H.png https://i.imgur.com/BspPL2H.png https://whatsmybrowser.org/b/JZAUZ62 https://whatsmybrowser.org/b/JZAUZ62 Appears to be caused by using 100vw, which doesn't factor in the width of the scrollbar. Notably on the selectors: [control="LandingPage"] .hero-header and [control="LandingPage"] .platform-information .info-section
  - keithwhor 7y ago
    Aha. So likely a Windows issue / those with visible scrollbars enabled? We'll add this to the bugs list. Thanks for the info!
    - yoavm 7y ago
      Linux + Firefox too :)

neeeeees 7y ago

Very cool product, and could be useful for learning also. I suspect the fundamental [business] limitation of a tool like this is that those willing to pay recurring big bucks (medium to large software shops) tend to rely minimally on 3rd party APIs. Those who benefit the most (weekend projects, learning, rapid prototyping) where time is of the utmost value generally wouldn’t end up using it enough to become recurring customers.

keithwhor 7y ago
I think you’re vastly underestimating the B2B API tooling space. Large enterprises and SMBs run tons of things atop SaaS APIs, often held together with staples and duct tape. We have businesses that run on top of us today that are only just beginning to automate huge chunks of their operations with us, Airtable, Slack and other tools. Previously these things were hacked together in an unmaintainable fashion. It’s a big space.

crabasa 7y ago

This is pretty interesting! I've been working on a web scraping API that returns Open Graph information for a URL, and decided to see how easily I could build and deploy this using Autocode. In about 15 minutes I ported the code I had written to Autocode. A few things that felt pretty magical: - auto recognized and imported required NPM modules to my project - ability to run code in-line (via Runkit) - auto-generated documentation You can see the docs for this API here: https://stdlib.com/@carter/lib/open-graph-api/ https://stdlib.com/@carter/lib/open-graph-api/ ...and can see an example API GET request which returns the Open Graph information for one of the top stories on HN today: https://carter.api.stdlib.com/open-graph-api@dev/api/?url=https%3A%2F%2Fgithub.blog%2F2020-02-12-supercharge-your-command-line-experience-github-cli-is-now-in-beta%2F https://carter.api.stdlib.com/open-graph-api@dev/api/?url=ht... I'm pretty curious to see where this product goes! It would be super cool to be able to easily tack on auth and a pricing model for heavier (enterprise) users of this API.

keithwhor 7y ago
Thanks for the feedback! We do indeed have custom auth and pricing in the works :). Can’t give an outline on delivery because we have so much other stuff to take care of, but the API registry is already built to handle these use cases.

BillSaysThis 7y ago

Where are the list of existing integrations?

keithwhor 7y ago
You can view connector APIs at https://stdlib.com/search/ https://stdlib.com/search/ -- if there's something we don't offer, you can build your own Connector APIs as well. Expect this list to grow substantially: part of our model is that we work with large API companies to ensure they're supported on the Standard Library registry.

Jiger104 7y ago

As a power user of no code apps like zapier. This is really amazing, for some of the more complex work flows I've had to write python code and initiate via lambda functions. This seems like it would alleviate that need completely. Would love to see the ide support python as well as js

leesalminen 7y ago

Looks like a hug of death “service is unavailable” with an on-screen JS stack trace.

keithwhor 7y ago
Try again? Everything is looking good for us right now. We run on entirely serverless architecture so any failures should be completely transient. I'll get my co-founder to pay attention and see if he notices anything out of the ordinary.

howmayiannoyyou 7y ago

Excellent. I can FINALLY start migrating away from Zapier.

keithwhor 7y ago
We'd love to help! Feel free to e-mail us (contact@stdlib.com) if you have any questions. We also have a Slack community that you can reach by clicking the Community -> Slack tab at the top of autocode.com. :)
- toomuchtodo 7y ago
  Is workflow import on the roadmap if you’re authenticated to your low/no code provider? With many, you can get the workflow out as a JSON blob their own frontend consumes. Love the product! Very cool!
  - keithwhor 7y ago
    That's a very good idea. We'll definitely be looking into it.
statictype 7y ago
What's bothering you about Zapier?

SahAssar 7y ago

Dev1: "Is that in stdlib?" Dev2: "Yeah" Dev1: "Then why isn't it working?" Dev2: "Because unlike EVERY OTHER THING called stdlib you need to install this one because it's not actually a stdlib" Dev1: "..."

keithwhor 7y ago
So, fun fact: our organization name is actually Polybit Inc. -- we do business as "Standard Library" because the registry we've built is pretty much core to everything we do. I expect the easy way to get around this is for folks to refer to us, when speaking technically, as "stdlib.com" ("standard lib dot com").
- deleted 7y ago
  [deleted]
- SahAssar 7y ago
  How would this work in languages where stdlib is an established way of talking about the actual built in standard library like https://devguide.python.org/stdlibchanges/ https://devguide.python.org/stdlibchanges/ vs https://github.com/stdlib/lib-python https://github.com/stdlib/lib-python ? Also you aren't worried at all about confusion or typosquatting (or what you would call it with a common name) with all the variations of standardlibrary, standardlib, stdlib? The npm package name standardlibrary was open, let me know if you want it transferred. No charge or bullshit, of course. I just claimed it because it was free and I guessed that somebody would typosquat it sooner or later considering your company name. If not I'll just release it
  - keithwhor 7y ago
    We're not particularly concerned about typosquatting for now. The name is based on the `.com`, i.e. all APIs / workflows built on Standard Library go to `username.api.stdlib.com`. The packages we use in NPM, RubyGems and Python are just called `lib`. The way 99.99% of developers have used us to date is starting with our in-browser or CLI tooling which installs / requires the correct package automatically. So I think that removes some of the risk you're talking about. :) You can hold on to the NPM package for now if you'd like! That's a good one. If we do find typosquatting becomes an issue, do you mind if I reach out?

samblr 7y ago

It is not difficult to see there is considerable effort spent building this. However, why would anybody use it ? I see following issues - Editors are getting mighty powerful. So why would a developer trade their favourite tool to your editor in browser ? I wouldn't switch to another editor even somebody is going to pay me more. - The process-and-cost of deploying backend has gotten way easier-and-so-cheaper - why would anybody write trivial code in autocode and then deploy on your servers ? Having said the above - I liked autocomplete provided for different apis in your editor. Sorry, if that was harsh.

zerkten 7y ago
I think the real market for software like this is large enterprises. There are lots of part-time developers or folks that need things glued together. Solutions like this are quite attractive to those organizations because the limited technical expertise they have is focused elsewhere. The process and cost of deploying backends is still significant for them. It is only a mostly solved problem for startups and medium-sized organizations. There is validation for this with Microsoft's "Power" platforms (Flow, PowerApps, etc) effort. This tool seems to have attached itself to competing platforms (Slack, etc.) Right now, an enterprise customer probably wouldn't get all of the pitch since the examples don't tie together their boring tech, but I guess the pitch is that they'll invest in that later.
keithwhor 7y ago
No problem! It's not harsh at all. I think what a lot of savvy professional developers don't necessarily grok is that they're just the tip of the iceberg, or the top of the pyramid, in terms of the types of people writing and delivering solutions with software inside of organizations. Let's say BIGCO pays you $X00k to build big, awesome production systems. There are 10x as many professional developers as you building small, hacky transient code within enterprise cos and SMBs and 100x as many tinkerers, creatives, admins, product managers and more just slapping together Airtable and Zapier as fast as possible to automate their jobs. Autocode isn't designed for the top of the pyramid. I mean, all the features can (and should!) certainly be used by folks at the top. You'll find that for a huge # of simple tasks -- tasks that don't matter where they live, like one-off daily crons -- Autocode is just plain faster. But the important thing to think about is the folks a bit downstream of the "top", the ones implementing solutions less focused on architecture and more focused on solving immediate business problems... that's where Autocode is designed to play well. Hope that helps!

deleted 7y ago

[deleted]

zebnyc 7y ago

Keith, do you plan to support other languages beyond javascript? This brings me back to 2004 when I used to work for Safeco. Business analysts / insurance agents would write business rules in VB.NET. Engineers would write application / integration code which would execute the business rules (both languages compiled to the .NET runtime so were compatible)

keithwhor 7y ago
Candidly: not immediately. There’s a lot of stuff we do that’s a Hard Problem (TM) to get working across a bunch of different languages, mostly associated with static analysis of code / Abstract Syntax Tree parsing. We’ve foregone multiple language support for now to focus on enabling people to be deeply productive with JavaScript by being highly opinionated.

Noumenon72 7y ago

So the idea is like, everyone who wants their app to integrate with Stripe has to write their own code that goes "response = /connect/to/stripe/${accountNum} + (json payload)", and this does that for you?

superasn 7y ago

Nice concept. Please think about adding a showcase to your homepage, i.e made with autocode. This will not only help it make it easier to understand but also show users the possibilities of what can be done with your platform.

keithwhor 7y ago
It’s next on our list! We support deploying from GitHub already, we just had to chop a few desired homepage features to make sure we shipped this on time. :) Coming soon!

tylerrobinson 7y ago

This is really cool! As a PM I’m somewhere in your “100x other people trying to automate stuff” category of user. My question is, would many of your features work if provided as a plugin for an existing favorite IDE? Having to use the proprietary IDE would probably be my sticking point, as it’s not easy for me to understand how or if I could start using this with an existing project in VSCode, say.

keithwhor 7y ago
Our team is literally itching to build plugins. E-mail us and let us know what you want!
- dijital 7y ago
  Would the Language Server Protocol make sense for your approach here? https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/ https://microsoft.github.io/language-server-protocol/overvie... Really interesting concept for exploring a new API, but I don't see myself dropping my IDE of choice for it.

zelly 7y ago

Isn't this what GraphQL was designed to solve?

codeulike 7y ago

wsdl, right?

gitgud 7y ago

Interesting project, I went and looked at the [1] npm module "lib" (side note: well done, you guys must have bought it as it was first published 9 years ago) I saw in the API that you reference in the following manner, which stunned me! const lib = require('lib'); lib.yourUsername.hostStatus(...) How could you have a dynamic property on a synchronous object like that?! Well it turns out in the [2] source code, you can have some kind of "anonymous getter"? get: (target, name) => { return LibGen(...); } I've never seen this before and can't find any documentation about it... [1] https://www.npmjs.com/package/lib https://www.npmjs.com/package/lib [2] https://github.com/stdlib/lib-node/blob/bd7cada7ae366c10e316795300078182700bd87b/lib.js#L31 https://github.com/stdlib/lib-node/blob/bd7cada7ae366c10e316...

keithwhor 7y ago
It’s referred to as a Proxy (type of Object) and they’re relatively straightforward and a newer addition to JavaScript. :)