the IDE That Grows—from Playgrounds to Fullstack Apps

Amjad Masad

At we come to work every day to explore a single idea—what if programming just worked? What if instead of fiddling around with packages, configurations, and mismatching versions, you just open your IDE and start coding. What if developers can go from an idea to coding and shipping software with no time in between. What if teachers who want to teach programming don't have to also work as IT administrators. What if students can just code their homework without having to set up the development environment on every computer they wanted to code on.

There exists an inverse relationship between developer tool sophistication and the getting started step. In other words, the more sophisticated our tools are, the harder it is to set up. Some would go as far as to say that programming is getting harder to learn. Given that progress in programming and developer tools will continue we have to actively fight back against the ever-increasing complexity of setting up the dev environment.

Online coding playgrounds solve part of the problem by getting people to code as soon as possible. They're pre-setup environments that make a lot of decisions for you. They make it easy to get started, to learn to code, and maybe even prototype simple apps. However, up until now, they lacked universality which is key to computing. In other words, you can only use one language, maybe a few frameworks but you're often limited by what you can do.

Today, we're changing this. We want the best of both worlds, an IDE that starts out looking like a playground but can grow with you as soon as you require the extra power. Here is how the IDE can grow from a simple Read-Eval-Print-Loop to a full-stack application development environment:

  • will always start out as a simple REPL, with a single file editor and a console. You hit run, a new environment is created, your editor script is evaluated, and then you can interact with the result in the console.
  • If you want to use files, write to files, split your code into modules, etc., you just do that and behinds the scenes the environment will switch to one where you're interacting with the filesystem. Your code will start to compile and run as you'd expect it when you run a project.
  • Say you need to use a third-party library, merely find it (through our widget, or your favorite package registry search), require/import it, and we'll take care of installing it for you.
  • Say, for example, you were coding in NodeJS, and that package you just required was ExpressJS. You use it to listen on a port, any port you'd like; we'll detect that, host your server/repl on your subdomain (forever!) and that's it you're developing/deploying an application.

Here is a gif of what the entire workflow could look like from interacting with the repl to deploy a server:

We might've buried the lede here but it's worth repeating: opening a port in the repl is deploying! You can deploy microservices, full-stack applications, or even a background compute job.

We also know that not all applications will grow incrementally so in typical one-click-start fashion we've pre-setup a Django, Rails, Express, and Sinatra apps. You can get started on the languages page.

This will also work for other kinds of applications. You can start out by experimenting in the repl and end up building and training a machine learning model. As an example, here is a simple Generative Adversarial Network by @Jae_DukDuk that uses the MNIST database and scikit-learn python package:

A new computing primitive?

One of the most exciting things about building a platform is watching all the creative and unexpected ways people use it. serverless apps are unique in that they're stateful and that the same repl, same protocol, same everything, that you use in development is deployed and running in production.

What we're seeing with some of our users is that they split out their applications into multiple repls. They might develop their website on one repl and have another repl be their logs and administrator interface. One of the more interesting applications we've seen recently is a repl as a client-interface to a chat application. The 13-year-old @pylieas built a repl that's a client chat interface to the backend that he made separately (which is becoming the unofficial chat applications for some of the young programmers):

After getting user-interest @pyelias is starting to explore building a full stack application using Django.

We're excited to see where where our users will take this. If you have any feedback for us, we'd love to hear it.

More blog posts