Wed, Mar 20, 2019Repl.it GFX: Native graphics development in the browser
At Repl.it we live and breathe making software creation easier. With our programming environment, you could start coding in your favorite language in seconds. With live deployments, we made web hosting a breeze. With Multiplayer, we've removed the drudgery from coding with friends. And today, we're excited to bring native GUI applications and game development to the browser. Before we go on, you have to see this in action: Just run the repl below, wait a few seconds for it to load, focus on the output window and start playing Tetris in Pygame: Let's take it up a notch and boot up this nifty desktop app we all love (might take up to a minute to load but then can be done recursively):
- Thu, Dec 6, 2018
Repl.it Multiplayer
Today we're announcing the most-significant evolution of our platform — something we've been building towards for a long time that we're thrilled to share with you. Introducing Multiplayer: code with friends in the same editor, execute programs in the same interpreter, interact with the same terminal, chat in the IDE, edit files and share the same system resources, and ship applications from the same interface! We've redesigned every part of our infrastructure to work in multiplayer mode -- from the filesystem to the interpreter. This works with all the languages that work on Repl.it. All free and ready for you to use right now. All you have to do is login, create a repl, start a Multiplayer session, give a link to your friends, wait for them to join, and start hacking! We started beta-testing Multiplayer last month. And while we think we're merely scratching the surface in terms of what can be done with it, a walkthrough of some of the emergent use-cases will give you an idea of how it works and how you can use it at your work, school, or for your side-project: Help
- Mon, Oct 22, 2018
Repl.it raises $4.5M, announces a million users
We're thrilled to announce that we have raised a Seed round led by Andreessen Horowitz, with Marc Andreessen and Andrew Chen championing the deal. We're also sharing that a million users are now using Repl.it. Moreover, our developers have shipped 250,000 websites/apps since our hosting platform launch in March. Checkout our Soundcloud for our latest album We started Repl.it as a side project with the straightforward goal of making it easy to get a REPL for your favorite language when you need one. Coding, we believed, should be as simple as opening a new browser tab. How Repl.it looked a few years ago
- Tue, Oct 16, 2018
File Switcher
A few days ago we shipped a simple feature that will save our users time in finding and opening files, especially for larger projects. This can even be used without having the file tree visible. Read on to see how to use it and to see a demonstration. If you've used offline IDE's before then you're probably familiar with this feature. To bring up the file switcher you can hit ctrl + P (cmd for mac), incase you're wondering why we chose that binding, it's cause it's the default for most modern editors. I'm actually interested in the history behind this feature, who started it, and why in the world did they pick ctrl + P (maybe it was meant for command pallete?), if you know you can reach out to me on twitter @masad-frost. Once you're in the file switcher you can type your file name or full path and it will show you your file, it also supports fuzzy string matching, so can just type part of the file you're looking for and it should show up.
- Tue, Sep 25, 2018
Rejected Then Recruited: Our Journey into Y Combinator
"The intoxicating delight of sudden understanding"1 best describes what I felt the first time I derived the Y Combinator (guided by the Little Schemer book). Learning Lisp (by way of Scheme) is how I first came about Paul Graham's essays. Which was, of course, a gateway drug to startups. Since then, Y Combinator (the company) has touched my life in so many ways. Jessica Livingston's book Founders at Work demystified startups and humanized founders for me -- suddenly starting a Silicon Valley startup seemed more approachable. My first job at a startup in the U.S was at Codecademy, a YC company, where I joined right after they graduated the summer 2011 program. And Hacker News has been daily reading for me for years; it's where I get exposed to new ideas and technologies and where I get feedback and exposure on my projects. Naturally, when I was thinking about taking the leap to start a startup, YC was top of mind. So I applied to open office hours to get feedback and see if our idea was something they'd back. Unfortunately, that particular meeting didn't go very well. The YC partner I met had the feedback that an online REPL is not really a startup -- it's just a fun toy -- and that instead, I should join another company building a superficially similar technology. But I've been waiting for someone to start this startup for years -- a website where people can not only learn how to code but can also build, collaborate with others, and ship software. In 2016 nobody seemed to be coming close to creating this. Unfazed, my cofounder Haya, who's a designer and also my wife, and I decided to quit our jobs and pursue the startup. We allocated $20k to help get it off the ground while we find a revenue model or until we raise money. We worked out of our home in Foster City and was able to monetize the service early-on by selling our code evaluation infrastructure as an API. However, the free service was always growing faster than our revenue, and it didn't seem like we were going to break even on this business model. I didn't think we would be able to raise money. In early 2016, some of my founder friends were struggling to raise capital, and I thought we'd fare no better since our startup is at the intersection of two industries -- devtools and edtech -- that have comparatively yielded minimal returns to VCs. Fortunately, someone took a chance on us. Roy Bahat, who heads up Bloomberg Beta, and whom I've met during my time at Codecademy decided to back us. With their stamp of approval, we were able to raise a comfortable seed round (or what's now probably called a pre-seed round). Around the same time, we got our first YC application rejection.
Thu, Jul 19, 2018Universal Package Manager
Open-source has revolutionized software development -- it wouldn't be an overstatement to say that it's been the most significant productivity win for developers in the last decade or so. At Repl.it, our goal is to make programming more accessible and what better way to do that than make available to programmers the entirety of open-source packages available at their fingertips. Today we're excited to announce our Universal Package Manager -- the Repl.it package manager that will grow to support every language on our platform. We're now starting with JavaScript, Python, HTML/CSS/JS, and the web frameworks that we support. We've had basic support for automatic package detection and installation for a while now, but what changed is that we support search and spec files (package.json, gemfile, requirements.txt, etc) across the board. Furthermore, where we used to write custom code for every language that we support, now we merely add fields to a config file. This was mad possible by creating a common package manager runner abstractions. Adding package manager support for a language is as easy as adding a couple of fields in a JSON config: In addition to this we have a more ambitious project in the works to build the same package manager that works across all languages (with the same semantics). You should come work with us.
- Sun, Jul 1, 2018
Zero Setup VSCode Intelligence
At Repl.it our goal is to provide state of the art in developer tools to everyone in the world, for free. When we started moving our product beyond a simple REPL and started adding IDE features, we had to invent standards and wrappers around every language tool for our frontend to consume. For every editor feature, say errors and warnings (linting), we had to extend our development protocol with a set of commands and data structures, and then teach our development containers how to wrap the given tool, say Pylint, and our frontend on how to consume it (say annotate the editor with errors and warnings). A similar thing has been happening with IDEs for the past few decades -- every editor had to come up with their in-house ad-hoc protocol, and every tool developer had to build adapters and wrappers for editors to consume. However, this is about to change: a couple of years ago, Microsoft's VS Code team announced "A Common Protocol for Languages", a single all-encompassing protocol that provides general-purpose language tooling -- be it refactoring, code-completion, or errors and warnings -- all implemented once and then seamlessly plugged into any editor that understands this protocol — this was dubbed the "Language Server Protocol" (LSP). In addition to LSP, VS Code also open-sourced the editor that powers VS Code: Monaco. Monaco is an editor built with web technologies, and since we started looking at LSP a few months ago, it only made sense for us to transition to Monaco first. Even before the introduction of LSP on Repl.it, Monaco allowed us to provide some cool language features (Smart Autocomplete, Go to Definition, Find References) for TypeScript and JavaScript because they're bundled with the editor. On top of that, the editor has a slick feel to it. In this release, we're rolling out language servers for Python (2, 3 and Django), C, C++, and ReasonML. And soon we'll be adding support for more languages -- Java and Ruby are looking to be next in line. Let's run through some of the features: Autocomplete and signatures
- Wed, Jun 13, 2018
React Framework Preboot
Two days ago we introduced our beta support for React frameworks, ranging from static-site generators like GatsbyJS, to fullstack frameworks like Next.js. Today we're launching a significant performance enhancement that we're calling preboot. Whenever you land on a repl, you get a container to develop against. Our containers are generic and work for any language/framework. When you land on a React framework, you had to hit "run" to start the server (it basically sends a yarn develop or similar to the container) . The container manager will then detect an open port, send an event to the IDE, which will show you a webview (speeded up gif below) -- afterward, you're on your way building your app. However, this kind of experience is suboptimal because it's slow. We pride ourselves on setting up the development environment within 2 seconds of selecting a language/framework so, naturally, we need to do better. Luckily, we have previously implemented a pooling mechanism on our infrastructure so that containers are ready and hot when you need them. What was missing from that is custom "boot" command that gets the container really hot, listening on a port, and ready to start serving. So now, when you land on a React framework environment, we grab a container for you that's already running -- your repl IDE will simply attach to it. Take a look:
- Thu, Jun 7, 2018
Repl.it ❤️ React
Despite the negative press covfefe around React.js when it first came out, I instantly fell in love with it. The thing I liked the most about it was the component model. Until then the JavaScript community has been trying for years to come up with the correct abstraction for creating reusable modules, but it was always leaky. Because React components are essentially functions, and because functions are the undisputed champion of reusable code, it worked out extraordinarily well. You don't need dependency-injection, or any other modularity hacks, you simply pass props! Also, the virtual dom made it so that components are, by default, protected from other components prying into their internals. That's just one aspect of what made me love React and it was a significant factor in me applying to work for Facebook in 2013. After I got in, I worked tirelessly to join the team behind React.js, and in early 2014 I was able to do so, and my first task was to build the React Native packager and CLI. When we launched React Native in 2015, you could just run a single command, and you'd have the entire development environment setup. Developers were so thrilled with this, that some tweeted out the command. I learned that when you make things easier, you get a lot more people through the door. So when Haya and I started Repl.it we wanted to go further than zero-config quick-starts and build a platform where you can code in any language, any framework, from anywhere. We initialy focused on education because we thought that teachers and students are underserved by the tech community. However, now that we're in 15% of US schools and growing worldwide, our technology has tranceded the education use-case, and we have an growing community of developers using Repl.it to build and deploy apps. Much of our work is supported by innovations from the React community (our apps are built with React, our IDE plugin system is inspired by Redux, etc.) so now we want to leverage our platform to give back to the community. We want to build easy and accessible tools for you to use. You can use it for developing apps, to debug libraries, or for prototyping. Furthermore, we want help spread the React technology by making it easier for outsiders and underserved communities to learn and participate in the larger developer ecosystem. Today we're excited to announce that you can try, build, and deploy fullstack React apps starting with a few of our favorite React frameworks. Before I go on, just want to note that this is a public beta release (it literary came out today) and we'll be iterating heavily on it for the next couple of months and we rely on your feedback to make it better.
- Mon, Jun 4, 2018
Don'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
- Tue, Mar 13, 2018
Repl.it: the IDE That Grows—from Playgrounds to Fullstack Apps
At Repl.it 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: Repl.it 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.
- Mon, Mar 12, 2018
Live Server Development and Deployment (Beta)
Repl.it is becoming the platform where developers come to learn and build. With web hosting we also made it possible to host websites and since then we've seen an explosion of websites hosted on Repl.it. Today we're going further by making it possible to deploy servers on Repl.it. Just open a port, run your code, and that's it, it's deployed! For our 90s website competition I built this socket.io-based chat hosted on Repl.it: 90s-chat--amasad.repl.co Here is the repl for it:
- Thu, Mar 8, 2018
Require Ruby Gems
On the heels of our Node.js npm support announcement, we're pleased to announce that we now support Ruby Gems too. We're excited to have the Ruby community join the fun. The way it works is slightly different from our Node or Python implementations. In Node or Python you simple require/import the module you'd like to use, and we'll automagically install the package for you. In Ruby, unfortunately, we couldn't find a reliable way to map requires to Gems so we had to go with a neat feature of Bundler: bundler/inline where you can define your gemspec in the code. This works well for Repl.it because we'd like to make it easy for people to use the repl without having to add files. Here is an example, this uses the gem colorlize to print an ascii drawing of the American flag: We're still working on improving this, look forward to the following the coming days: Per repl caching: install once, there forever
- Wed, Mar 7, 2018
Introducing Node.js package support
Ever since we introduced third-party package support for Python we've seen an explosion of exciting programs on Repl.it. Everything from games to machine-learning applications that just weren't possible before. Today we're happy to announce that we're expanding this to support Node.js. Just require your dependencies and we'll handle the rest for you. Here is a working repl that gets my Github stats. It uses request to fetch the data and underscore to filter the relevant stats. This is an early (open beta) release so please let us know if you hit any bugs or issues. We're currently working on the following: package.json support: if you have a package.json in your project we'll use that instead of parsing the requires. This will likely come in the next couple of days. Caching: if you install a package on a repl it will be cached forever.
- Mon, Feb 26, 2018
New and improved repls page
People use Repl.it in a variety of ways; some use it for building and shipping applications, while others use it for working on homework, and many others use it as a quick prototyping/experimentation tool. Supporting all these use cases (and more) is something we care a lot about, but up until now there wasn't an easy way to, for example, quickly go back to a project that you continue to work on every day. Today we're excited to announce some of the changes that we've been testing for the past couple of weeks. Going to "my repls" the first thing you'll notice is a big "Continue coding" section with the projects that we think you might want to go back and work on. Starring Additionally, you can now star repls, so it's easy to go back to them!