Mon, Dec 13, 2021Ace, CodeMirror, and Monaco: A Comparison of the Code Editors You Use in the Browser
I’ve been working on Replit for roughly six years now, and as the team has grown, I’ve focused on the IDE (what we call the workspace) portion of the product. Naturally, I was increasingly preoccupied with the code editor. While we’ve considered creating a code editor that meets our needs, the complexity involved in developing one, the richness of open-source choices available, and the size of our staff made it a fruitless rabbit hole to enter. Our time is best spent elsewhere. I have had the pleasure (and the pain) of using Ace, Monaco, and CodeMirror in production settings, sometimes simultaneously (more on that later). In this post, I’ll go over some Replit history, my experience using the editors, and how they stack up against one another. If you’re here for a direct comparison, feel free to skip to the end, where I recap and compare. The story Prelude: Ace In the early days of Replit, around 2011, there was no code editor. It was a pure REPL interface, a console with a simple input box. Adding a code editor was an obvious next step, especially if we cater to more complex programs. Code editors give us features like syntax highlighting, editor shortcuts, auto-indentation, search and replace, etc. Cloud9 released Ace at the time as a feature-full, performant web code editor. Ace editor is still actively maintained; it has a rich ecosystem and supports many languages, keybindings and works great in the browser.
Mon, Nov 29, 2021Will Nix Overtake Docker?
In many discussions about Nix, the comparison of Nix and Docker comes up frequently. This question could be dismissed by saying that Nix and Docker are different tools that solve different problems. One is a toolkit for building and deploying containers and the other is a package and configuration manager. However, these tools do have some overlap: they can both be used to create reproducible environments. A reproducible environment is one that can be recreated from scratch in an identical way (ideally bit-for-bit). Practically, this means having the same tools, versions, and configuration between the environments. Reproducible environments are useful to ensure all developers on a project have the exact same set of tools. Additionally, you can develop in an environment that is similar to the production environment -- leading to less surprises when deploying. Both tools can solve the age-old problem of "it works on my machine". While both tools aim to solve this problem, they take different approaches.
Sun, Nov 21, 2021How to Set Up Your Own Mastodon Instance with Replit
With many development tools and even whole development environments moving to the cloud, Replit is at the forefront of this change. Replit is one of the leading cloud, in-browser IDEs with support for fifty-plus programming languages with syntax highlighting and intelligent autocompletion. However, Replit is more than just an IDE in a cloud. With additional features like real-time collaboration, GitHub integration, and detailed edit history, Replit is a full-blown workspace for teams, educators, and interviewers. This guide will show you how to install Mastodon in the Replit environment, showing its versatility and potential.You can follow along with this Repl. What Is Mastodon? Before we start, let me introduce you to Mastodon: an open-source social networking software.
Thu, Nov 11, 2021Announcing File Persistence in Hosted Apps for Hackers
We mostly think of repls as being full computers in the cloud, and one of the goals of the platform team at Replit is to enable people to build almost anything in replspace. In the past, when a file was stored in a repl, it would only be saved when the editor was opened. This went against our goal and made it impossible to write certain servers that changed files at runtime. This was especially hard for newcomers, because that's the easiest way to persist information. Starting today, Hacker and Teams subscribers will be able to write services that accept file uploads or store data in a local database (think SQLite) or text file, regardless of how the repl was started. A demo of what it looks like for a server to be able to save its files: https://sqlite.luisreplit.repl.co What is replspace? replspace is a term we coined up. In operating systems, memory is divided into kernel space and user space. Kernel space is where the kernel executes and provides its services. The kernel can access all of the memory, but the user cannot access the kernel's memory directly. By contrast, user space is all the memory that a user can access without modifying the kernel sources (or creating a kernel module). The term user space has also been used to refer to the programs that are run by users. This memory separation is important because the kernel manages all hardware resources, providing access control and coordination, and provides abstractions that let programs that run in user space make requests to interact with those resources. The kernel has several interfaces so that the user space programs can communicate with the kernel, the most important one being the system call interface. These use the abstractions laid out by the kernel to ensure that users and programs don't interfere with each other and also iron out differences in the underlying hardware and provide a uniform "view" of the resources available to the machine.
- Sun, Oct 24, 2021
Betting on Nix: donating $25K to the NixOS Foundation
As building software grows more like snapping Legos together, how people find and use those Legos becomes more important. That's why we are donating $25,000 to the NixOS Foundation and betting on Nix as the future of software distribution. In software, the Lego pieces are called packages. A package may be some code your program needs to call (a library) or another program your code needs to run. Historically, people have used package managers to find and install packages into their projects. Each language ecosystem has its own package manager. Replit built and open-sourced the Universal Package Manager to unify this fragmented landscape. Package managers are a holdover from the old model of programming, when development environments lived on personal computers. Now that development environments (ahem, repls) can run entirely in the cloud, fetching packages from a central server, unzipping them, and installing them into a filesystem seems shockingly archaic. The future is instant. When you press the run button in a repl, your code should run immediately, not pause to fetch packages. The Nix project unlocks instant repl runs. Nix uses content-addressable storage for its packages. If you know which package you want to use, you can compute its location on the filesystem without having to search a central repository. Which means we can put every single package on a fast disk in the cloud and skip the fetch-unzip-install cycle. When you press run, your program can instantly access all the packages it needs on a drive already mounted into the repl. The future is reproducible. What does that mean? If your repl works today, it should also work the next time you go to run it.
Wed, Oct 13, 2021Solidity on Replit: Diving into Web3
Today, we're announcing our official Solidity development template. Solidity is the language used to create smart contracts, which are programs that run on the Ethereum blockchain. This is important for the Web3 commmunity because there's finally an accessible and collaborative way to learn Solidity, which will unlock thousands of new developers in the decentralized web. You can try it out by creating a new Repl and typing solidity in the search bar. Or, go directly to the template page to fork it or leave feedback. :) Why this matters Lowering barriers to entry is core to Replit. Everything we do is intended to make software creation easier, faster, and more fun. So when new infrastructure and communities (like Ethereum) gain momentum, it's our responsibility to help people create for that new technological universe. So, why not try to build the best blockchain development experience in the world? Replit has a unique advantage here. Among other "web-based IDEs", Replit is a true general purpose computing environment. Every Repl you create is actually a Linux container, meaning everything we build sits on top of a fully functioning operating system. This gives us the flexibility to build basically anything we want. Almost any program or environment you can create locally, we can transform into a URL.
Mon, Sep 20, 2021A New Code Editor for Mobile - CodeMirror 6
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!
Mon, Feb 1, 2021The Internet of Fun
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.
Wed, Dec 2, 2020We've Been Pwned
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).
Mon, Jun 4, 2018Don't Let Your Development Environment Rot
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
- Mon, Mar 27, 2017
Building Towards a Holistic Development Service
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.
- Mon, Nov 14, 2016
Learning Devops & AWS on the Job: Building and Scaling a 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
- Fri, Jun 24, 2016
API Docs
[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