The Replit Team

At Replit, we are on a mission to empower the next billion software creators. As we reflected on our mission and heard feedback from our community, we grew confident in our pursuit to create an end-to-end experience that represents the best developer tool membership in the market to go from idea to software, fast.


Today, we’re excited to announce Replit Core, a singular plan that we aim to continue investing in for years to come.


With Replit Core, you get:


Access to advanced Replit AI features

Save time and code faster with Replit's industry-leading AI coding assistant, currently powered by GPT-4.

Debug code, get intelligent autocomplete suggestions, and convert natural language to code with one click.


Announcing Replit Core - The Essential Membership for Builders

Faris Masad

Today, we are thrilled to announce CodeMirror as the new code editor on Replit for mobile devices. CodeMirror is a versatile code editor that has been specifically designed with mobile in mind, providing an excellent touchscreen experience. This change is the beginning of a focused effort on mobile development here at Replit; the editor is just the first step! The editor supports all the features you expect from a code editor, and we're working on making it even more powerful.



We hope this update will be helpful for those of you who do not have access to a computer but still want to learn and create cool things. We are also working on bringing CodeMirror to the desktop to provide a consistent experience no matter what device you or your multiplayer partners are on. We will see many of the features that we currently have only on the desktop ported to mobile in the process. Keep an eye out for threads, debugger, and more on mobile.

Watch this blog for a follow-up technical post on our experience with the editors of the web: Monaco, Ace, and CodeMirror.

We've got a lot planned for mobile, we are so excited, and we hope you are too!

A New Code Editor for Mobile - CodeMirror 6

Amjad Masad

Yesterday, I accidentally built a chat app. Surprisingly, it wasn't the first time it happened.



Before I tell you how Hackernews turned (this blog's) HTTP logs into chat, let me tell you about how a 12-year old user hacked the first chat app and community space on Replit right into a Python REPL.

In 2018 we didn't know we had such a strong community of tinkerers. We knew people make games with Replit and share it with other people. But we didn't realize we'd already been a Schelling point for young hackers.

One day, @pyelias created a post on our support forum saying he built a Chatroom and linked to a repl. I thought it would be a simple chatbot or something similar because I hadn't seen internet-based apps on the platform until that point. We had just opened up internet access to everyone, but we didn't support web hosting or any advanced features Replit has today. It was a very constrained environment.

The Internet of Fun

Mason Clayton

As long as I can remember Replit has been receiving a large number of vulnerability reports. We're very grateful for these and take them extremely seriously. However, 99% of them stem from a misunderstanding of what we do. Our main product is RCE (remote code execution) and naturally this leads to a whole lot of RCE vulnerability reports.

Fed up with low effort and time consuming vulnerability reports I set up this repl earlier this year. The bounty is simple: read my secret or edit my file and receive a $1000 cash prize. Either would be a critical vulnerability in our infrastructure. Having a clear goal and a prize was a good motivator, and indeed there was a lot of initial interest with many valiant attempts.

All was quiet until PDanielY was messing with our developer API (currently in closed alpha). Here is how he tells the story:

I was trying to make a repl.run clone and then when I tried to use it run a public repo on my alt, I saw that my main account actually connected to the repl and I could edit files and stuff.

This was ultimately due to an oversight in the token minting code used by our developer API. It used a long since deprecated method of generating tokens when accessing repls owned by someone else. Instead of producing a temporary transparent fork you'd get full access to the underlying repl. Yikes!

Once PDanielY alerted us we verified it looked suspicious and immediately revoked all developer tokens. Next we looked at the logs to see if anyone other than PDanielY have exploited the bug and luckily, we found none (the alpha developer program has only a few developers).

We've Been Pwned

Most systems -- both natural and artificial -- decay, rot, and eventually die. Software is no different. A lot has been written about fighting "software rot" but there's another type of rot related to software that's not talked about much -- the development environment rot.

When starting a new project, you make decisions like what language to use, and which platform/runtime to run on, all of which dictates what your development environment will look like. Then you'll also make explicit choices for the development environment, like how will it run on in development mode, will it run in a Virtual Machine? Maybe on containers? How will the environment be bootstrapped? Also, what does the developer work-flow look like? What test framework and runner to use? How do you package your software? etc., etc.

As you develop your software and the months and years go by, slowly but surely, you'll add more components to your system, you'll have a lot more code to test, and the overall complexity of the system increases. Now, we know that if you want to fight code complexity, you refactor your code, but how do you detect and what do you do about development environment complexity?

What makes this a tricky question to answer is that the pain is not so apparent to existing developers. Like in the boiling frog fable, the frog doesn't notice the temperature increase until it's too late. Similarly, developers don't see the complexity creep until it's far too complicated that it requires you to stop making progress on your product to stop and fix the development environment rot.

So how do we keep the development environment rot in check? A few ways:

Keep an eye on the developer on-boarding experience

Don't Let Your Development Environment Rot

Software development is one of the first -- if not the first -- examples of what J. C. Licklider called the Man-Computer Symbiosis. A "cooperative interaction" between people and computers where the person is concerned in what may be classified as the creative aspect of the work such as setting the goals, formulating the hypothesis and evaluating the results while the computer does all the "routinizable work".

This symbiotic partnership is especially effective for work that puts to the test our intellectual capacity like keeping all the moving parts of a large software system in our head. Or as Dijkstra warns us "the competent programmer is fully aware of the strictly limited size of his own skull".

This begins to explain why software engineers are so passionate about their tools. From the good old editor wars to JavaScript fatigue, we're continuously adding and improving on our arsenal because this is the best way we know how to become better engineers. From a business point-of-view, it might also explain the seemingly sudden rise and growth of the developer tools market: hosted version control, infrastructure, devops and automation etc.

Despite all this success I think we've fallen victim to the onetime useful Unix dictum Do One Thing and Do it Well. Roughly speaking, we separate our tools by development life-cycle stages: authoring, executing, testing, building, and deployment. Which limits how much information each tool has at its disposal and therefore how much utility it can provide. Sharing the work isn't easy. The text stream as the "universal interface" means that, for example, tools need to re-parse code at every stage of the life-cycle to extract whatever meaningful information it needs.

In practice it means I can't upgrade to the latest release of my favorite programming language because I need to wait on all my tools to upgrade their parsers. And this is not a theoretic problem, consider the fact that the website that you're probably reading this on was authored in ES2016 JavaScript, parsed and compiled to ES5 and then parsed again and minified and then parsed yet again to finally run in your browser which most likely runs ES2016 (back full-circle).

However, we'd like to take a stab at the problem from an angle that we, at Replit, are uniquely situated to do. Our mission is to make programming more accessible, so when we design we focus on the hobbyist and the learner (although a lot of engineers also get a lot of value from our service). This relieves us from the pressure of having to build tools that needs to compete and achieve parity with existing development tools. Our users are open to things that makes it easier for them to learn, play, and share.

Building Towards a Holistic Development Service

Or, what I wish you I knew before building Repl.it's code execution service



new drinking game "name that AWS service logo"

— TJ Holowaychuk (@tjholowaychuk) March 23, 2016

I, by no means, identify as a devops or even a backend engineer. Most of my professional experience has been equally split between frontend/product and developer tooling. I also primarily learn by doing and bias towards simplicity and MVPs -- almost to a fault. So when I approached building a service on AWS I took a very simple path and increased complexity as the service scaled up. Here are all the steps that I went through before getting to something that I'm not totally ashamed of.

eval.repl.it

Learning Devops & AWS on the Job: Building and Scaling a Service

[Update Oct 2022: We have retired our API, we are excited by our previous work but we do not have the resources to support this at the moment.]

Repl.it's code execution API is an HTTP and WebSocket endpoint that you connect to and send code to execute. You can connect from any device or browser and start executing code. This guide will describe the concepts behind the service, how it can be used, and provide a step-by-step guide for signing up and trying out the service!

Code Execution

You're probably here because you want to run some user code in an app or website somewhere. Our customers use the Repl.it API for many different things including:

In-browser coding environments

In-browser coding exercises

A New Code Editor for Mobile - CodeMirror 6

The Internet of Fun

We've Been Pwned

Don't Let Your Development Environment Rot

Building Towards a Holistic Development Service

Learning Devops & AWS on the Job: Building and Scaling a Service

API Docs