RunKit Blog

RunKit is Joining TC39 to Focus on Interactive Programming

Tue, 06 Feb 2018 00:00:00 -0700

The RunKit team is incredibly excited to be representing Stripe at TC39!
We hope to do our best to help JavaScript become an even better interactive
programming experience.

At its core, RunKit is guided by the principle that the interactive programming
models pioneered by environments like Smalltalk,
Mathematica, and Jupyter offer an important path to
making development truly accessible. Although this model has already proven
itself in the data-science and prototyping spaces, we think it has tremendous
potential for every-day programming as well. The REPL's that ship with most
modern languages today give us a glimpse of this already, but we think they are
just barely scratching the surface of what's possible.

When we started RunKit we made the deliberate decision to bet on JavaScript.
Instead of focusing on running any container, or even any language, we
wanted to really dive deep into one coherent experience — whether
that be by turning the entire npm registry into an immediately
accessible standard library or
making errors actually understandable. We chose
JavaScript because we think it is already a spiritual successor to these
interactive programming models — when I first started programming, the
browser was the ultimate interactive playground, and it was free!

Today we're excited to take the next step beyond simply working on tooling to
make this vision a reality and actually participate in the future of what the
language could look like. We're excited to approach the language from a
REPL-and-Playground-first perspective. The last decade has seen JavaScript
mature into a language far more capable of architecting ever larger
applications, but we think there's still a lot that can be done to make the day
to day experience more interactive and explorable. Can we learn from Elm to make
errors clearer? Can we learn from Ruby and Pry to make the
REPL more discoverable? Can we eliminate the gap between the REPL and
the file altogether?

The future of JavaScript is bright and we are honored to be able to take a small
part in it!

Bringing Documentation to Life on Expressjs.com

Tue, 18 Jul 2017 00:00:00 -0700

We’re incredibly excited to have recently integrated RunKit directly into expressjs.com’s Hello World tutorial. The sample code in the tutorial itself is completely unchanged, but it has one major enhancement: the code is now live! When we say live, we mean that every time you load the page we’re actually spinning up a real Linux server that is running that sample code, and instantly updating in response to your edits:

As requests are made, we’re also showing you the server logs right underneath, making the connection between the code and what it does more immediate and direct. You can make the code as complex as you want: thanks to the fact that RunKit preinstalls every package from npm, you can really do just about anything here. In other words, people new to express will feel absolutely no friction in trying it out: no need for installing the right packages, no need for setting up the right JavaScript environment, no need to even install node.

This is part of a larger goal here at RunKit to bring all documentation to life. When we visit documentation online, we have to remember that we’re not reading a piece of paper but a computer, and we should be using its strengths. Our dream is to completely illiminate the gap between learning about something and actually trying it. Let us know if you want help integrating RunKit into your own site, and check out the embed docs to get started!

Bring your npm packages to life with RunKit

Tue, 07 Mar 2017 00:00:00 -0800

We built RunKit notebooks so developers can quickly and safely prototype code, and use all the building blocks from the npm community. Ever since we partnered with npm to try any package live with RunKit, the Node.js ecosystem has continued its rapid growth to almost half a million published packages. Today, we’re introducing new landing pages for all npm packages to make them even easier to discover and explore. For package owners and maintainers, it’s the best way to show off the features of your packages with a fully interactive Node environment, right in the browser.

Here’s a quick overview of the new features:

Code explorer: RunKit npm pages include a code browser, which shows you the installed package code, rather than what the code looks like on GitHub, so you can follow the code execution as you browse the very code that runs.
Linkified JavaScript: When you’re in the code browser, all the file’s requires are links. RunKit uses Node’s own path resolution, so you won’t jump to the latest globally available version of a required package, but the very one that satisfies the package.json’s constraints as though you just installed it yourself.
Markdown rendering: Read the documentation as you’re prototyping—it’s included side-by-side with a RunKit notebook.
Customization for package maintainers: By default a package’s RunKit npm page requires the package, so when you run it you’ll see the package’s exports. But, we’ve made it easy for package maintainers to do deeper integrations. If you add a sample source string in your package.json with the key runkitExample, or for more complex examples you can provide your own file under the key runkitExampleFilename.

Many package authors including D3.js and Lodash already use RunKit to show off features of their packages. We’ve created a page for package maintainers to better leverage all of RunKit’s offerings including adding a button to your package’s README to make it easier for your users to try your package in a browser:

Stop Filing Bugs, File a Container!

Wed, 01 Feb 2017 00:00:00 -0800

RunKit notebooks are a great way to file bugs on GitHub. Since RunKit automatically packages your code with its entire environment in a Docker container, anyone can clone your bug and start investigating it live in seconds, without any setup or installation. Best of all, the bug will be completely reproducible and avoid the dreaded “works on my machine”. Today we’re excited to be improving this experience even further with a completely revamped UI for filing and analyzing issues on Node.js:

Our initial focus was to make stack traces in Node.js significantly easier to interpret and understand. RunKit interacts directly with the V8 data to provide a much more detailed view than any other implementation we’ve seen. One example is how RunKit dramatically streamlines the experience of navigating the stack trace by inlining the offending code right in the frame, as well as providing documentation for many of Node’s built-in functions:

But we also focused on a lot of little details, like swapping in canonical names for functions whenever we can in order to avoid the more confusing inferred V8 names that sometimes show up. Another thing you’ll notice is that we now show you the version of the package you’re using immediately as you require it. This makes it so that all the dependency information in your notebook is immediately digestable with a glance. It’s a lot of fun when coding, but even more useful when looking at someone’s else’s code.

Together, all these features result in a bug report that surfaces all the pertinent background for a bug with no extra work for the user. Instead of relying on templates to remind people to include all this, RunKit just knows it by default. That’s because with RunKit you’re not just filing a bug, you’re filing an entire container, enabling the coolest feature of all: the ability to run it.

How To Get Started

The easiest way to get started using RunKit to file bugs is to Sign Up and then head on over to a package’s corresponding RunKit page (such as https://runkit.com/npm/lodash). You can then paste the generated link on the package’s bug tracker. If you’re a package maintainer and want a more customized experience, you can use our API to embed RunKit right on your page.

Try It Out

Introducing DemoKit: Scriptable Product Demos

Tue, 18 Oct 2016 00:00:00 -0700

Today we’re open sourcing and releasing DemoKit, our new Electron app for scripting product demos. Using the web technologies you’re already familiar with, you can now record demos, tutorials, or any other videos that show off your products. Since the demos are scripted, you can check them into GitHub, incorporate feedback and changes, and even simply re-record them when your products visually change so they’re never out of date. In order to help get you started, we’re also open sourcing RunKit’s demo that appears on our homepage.

How It Works

DemoKit uses JSX (but not React) along with HTML, JavaScript, and CSS to let you define a “movie script” for your demos. For example, the following snippet types and execute a query in Duck Duck Go:

DemoKit includes a bunch of prebuilt “props” for your movie too: browser windows (that host your live webpage to interact with), terminal windows, and code editors. One of the cool experimental features we’ve added recently is the ability to embed buttons in your videos as well. Basically, DemoKit will track where all the buttons are in your video and generate a script to make those areas clickable on your web page as well.

Why DemoKit?

One of the things we wanted to do for the RunKit rename was create a demo video of our product for our new homepage. But the idea of doing this filled me with a fair amount of dread since creating demos is such a laborious process for me. I’m always making mistakes when I type, and its rarely a collaborative or iterative process since it never feels worth it to go re-record large portions of a video.

We originally wondered whether we could abuse Selenium and QuickTime screen capture to be able to program a demo the way we programmed our tests, and this actually got us quite far. Unfortunately, Selenium really isn’t designed for this task and has some issues running simultaneous animations and commands. At this point we decided to go all-in and build a dedicated tool using many of these ideas.

The result is something we’re really proud of: any member of our team can now tweak the demo and keep it up to date and fresh. More importantly, we can now invest in video tutorials which is something I’ve wanted to do for quite some time. We’d love to hear your thoughts on it too, you can install it with npm by typing npm install demokit -g, or check out the source as well.

Tonic is now RunKit, a part of Stripe

Tue, 13 Sep 2016 00:00:00 -0700

For the past year we’ve been taking a radical approach to development tools here at Tonic. Instead of treating IDEs, frameworks, and even languages as the fundamental building blocks for development, we decided to explore what it would mean to attack these problems at the system level. Could we make progress on some long standing development headaches by essentially beginning to build a developer OS?

We started by buidling module-fs, a virtual filesystem capable of representing the entire state of npm at any particular microsecond. With module-fs we could make every version of the over 300,000 packages on npm available instantly. With truly immediate and frictionless access to any package, you could begin to think of npm as the global standard library, as essential to development tomorrow as built-in libraries are today.

Similarly, we attacked the problem of time traveling debugging not at the application level, but directly on the OS by using the bleeding edge virtualization tools of CRIU on top of Docker. We knew that for a feature like this to truly be usable outside of simple demos, it would have to match real-world use by allowing developers to rewind any mistake, including forking a process or modifying the filesystem.

We’ve exposed these core features in a number of experimental products. Notebooks are our take on how a REPL can work in such an environment: quickly and safely prototype and share code with truly zero configuration. Endpoints re-imagined deployment by doing away with it completely: the code is simply always live, no longer requiring time-consuming installation thanks to module-fs. And finally, embed proposed that all online documentation and examples could be live by allowing any webpage to leverage these technologies:

Your browser does not support HTML5 video.

A few months ago, we started talking to Patrick Collison, Stripe’s CEO, about our vision of building the future of development tools. I was already aware that Stripe had a history of investing in development, but Patrick made clear that lowering the bar to development is fundamentally aligned with Stripe’s interest in increasing the leverage of developers around the world.

From these discussions, it became increasingly obvious that it made sense for us to work together. Stripe decided to take a bet on our vision and our team, and I’m excited to announce that we are now officially part of the Stripe family. We will continue to operate independently, working from our office in the Haight in San Francisco, and we will also be changing our name to something that better encapsulates our vision: RunKit.

RunKit represents what we are truly building: a unique new platform to enable tomorrow’s development tools. In the coming weeks we’ll be releasing a number exciting updates that leverage our technologies, as well as better explanations of what’s going on under the hood. We are really looking forward to the things we can build by working with Stripe, and can’t wait to show you what we’re up to. Try it out yourself:

const React = require("react"); const { renderToString } = require("react-dom/server"); const OneMoreThing = require("one-more-thing"); renderToString(<OneMoreThing/>);

Two-Millionth Version

Tue, 23 Aug 2016 00:00:00 -0700

While querying our database to get exact numbers for Tonic’s announcement of scoped package support, we realized npm recently passed an important milestone. So here’s our belated card to celebrate the occasion.

Packages have multiple versions. npm currently has ~330,000 packages. Packages have, on average, 6.74 versions. Do the math, and that’s over two million versions of packages.

Yes, npm recently passed two million versions. Congratulations to the Node.js community, npm Inc, and everyone who’s contributed to the most massive code library in human history. Together we’re building something amazing.

We thought it would be fun to go back and figure out which specific packages and versions won the round-number lottery. So we listed every package and version in chronological order and picked out a few winners:

Milestone	Package	Date
1st package	sprintf	Nov 11 2010
10th package	uuid-pure	Dec 19 2010
100th package	useragent	Dec 29 2010
1,000th package	worker-pool	Mar 30 2011
10,000th package	PSNjs	Jun 13 2012
100,000th package	js-atom	Oct 20 2014
200,000th package	dodo-core-features	Nov 3 2015
300,000th package	servercreation	Jun 21 2016
10th version	recon@0.0.1	Dec 18 2010
100th version	jade@0.2.3	Dec 19 2010
1,000th version	searchparser@0.1.0	Jan 10 2011
10,000th version	restify@0.3.12	Jul 7 2011
100,000th version	ep_post_message@0.0.1	Jan 22 2013
1,000,000th version	ngtestharness@1.0.2	Jul 27 2015
2,000,000th version	ddv@1.0.16	Jul 19 2016

Explore

We loaded up versions-published-per-day since npm beginning, and it’s a fun chart to explore:

Of course the growth is amazing. It’s also fun and interesting how you can pick out lulls in new versions on the weekends, especially in the 2016 era (hint: switch to the 1 month (“1m”) zoom level and scroll around). You can also make out end-of-the-year Holidaze lull.

Node is definitely people’s Day Job nowadays.

Predictions

So, where is npm heading? We analyzed npm’s growth rate, tried to smooth it out and extrapolate when the next big milestones will be hit.

Here’s what we came up with:

Milestone	Extrapolated Date
3,000,000 Versions	Feb 2017
500,000 Packages	Jun 2017
1,000,000 Packages	Jul 2018

With these dates in mind, hopefully we won’t be caught surprised coming upon the upcoming npm milestones. No more belated cards, instead we can start planning 2018’s epic 1 Million npm Packages Gala.

Be there.

Scoped Package Support

Wed, 17 Aug 2016 00:00:00 -0700

We’ve just deployed support for scoped packages on Tonic! Practically, this means we’ve added around 75,000 versions of 11,800 packages.

If you’re not familiar with scoped packages, they’re just like normal packages except their name includes a namespace: require("@namespace/package-name"). This allows you to avoid collisions with existing packages. Although you may have never directly used one yourself, many are included as dependencies in other packages. Try it out right here:

require("@slack/client")

We are always looking to improve our package support on Tonic and aim to work out of the box with everything on npm, so if you run into any issues, let us know!

Building "Interesting" Previews on Demand with Tonic Endpoint

Wed, 09 Mar 2016 00:00:00 -0800

When people share content on Facebook, they expect that the content will show up a certain way in the news feed: with their own title, description, and most importantly a relevant picture. Of course, Tonic is largely about text, whether in the form of source code or the properties in an object viewer, so we had to find a way to generate pictures that made sense. Building a prototype to do that with Tonic turned out to be so simple that we wanted to share the process.

What are we doing?

The first thing to figure out was what should be in the picture? We could generate an image that contained the source code easily enough, but in many instances the results are more interesting than the code itself. And sometimes the opposite is true: an interesting chunk of code might just output something true, which is hardly worth turning into a picture.

We settled pretty quickly on the idea of turning the entire document into an image, and then taking it from there. There are a number of tools out there for turning HTML into an image, and after checking out a few, we decided to try moving forward with wkthmltoimage. It has the nice feature of being a self-contained binary, making it simple to run and deploy. And it can take HTML as a string, or a URL to a webpage that it will render directly.

Getting the image

wkhtmltoimage is cross platform, making it pretty easy to download to an OS X machine and see what an image of one of our notebooks would look like. Things worked ok out of the gate, but there was room for improvement. In order to actually make improvements, though, and to eventually deploy this as a production tool, we needed a way to generate these images programatically. We needed an API. What a great excuse to play around with Endpoint!

Creating an API with Endpoint is incredibly simple: implement one function in your notebook. The only thing our API had to do was take in a URL and then return an image of that URL. Part one was a straightforward “hello world” type Node.js problem, but part two required creating an interface to the tool running in another process. Fortunately, someone has already done that work on npm. Unfortunately, the library expected wkhtmltoimage to already be installed on the machine.

Endpoint requests, and Tonic notebooks generally, are running in generic linux sandboxes somewhere “in the cloud,” so it isn’t super simple to just install a new binary. You can always script the install process as a series of exec calls, but that’s slow and cumbersome. But if you recall that wkhtmltoimage is a self contained binary, you might reach a much easier conclusion: ship a version of the library that vendors in the binary directly. So that’s what we did.

Forking the library on Github, downloading the dependency, and publishing a new package to npm took a few minutes. And less than a minute after that, the new package was available for use in Tonic. After that, writing the code to respond to incoming requests with an image was just a few lines.

And since we specified a custom example for our package, you can play around with your own copy of this server by just visiting the package page.

“Interestingness”

Facebook wants a specific aspect ratio for the images it displays, but notebooks will be many different sizes, so the next task was to figure out how to choose the right section of the page to show in a preview. Again we ended up turning to an existing solution, with an existing package already up on npm: [SmartCrop.js].

Just as before, we wanted our image to be generated with an API, and so again we created a new Endpoint. With the same basic skeleton, this API was only a bit more complicated. First, we actually get the screenshot as an image from our existing endpoint. Then we load it into [node-canvas], and pass the image to SmartCrop. Finally, we stream the resulting image to the response.

There are a lot of parameters you can tune for your own use (adding those to your API is left as an exercise for the reader).

Deploying to production

In just a few hours, we had a working API for generating “interesting” previews for our Notebooks. There were a few more steps though. First, we spent some time optimizing the visual display of our notebook previews. For example, there was no need to show navigational elements. We created a simpler, cleaner page, and eliminated the need to load any javascript at all to make things faster.

Next was generating open graph meta tags in order to have Facebook see our previews. There’s plenty of documentation on how to generate these in Facebook’s developer center. One thing you may want to pay attention to if you’re doing this yourself is that Facebook won’t refetch an image it has already fetched, so if your image may change over time (as ours does), you’ll need some kind of query paramter to force the image to update.

Facebook also expects images to load in just a couple of seconds. Unfortunately, this doesn’t always work for us when generating a preview of a larger notebook. We ended up building a caching layer for our previews, generating them upfront and storing them for a period of time in s3.

The last step we did was move our code off Endpoint and into our own deployment environment. There are a few reasons this made sense for us, and probably will for you too if you’re moving beyond a prototype. The most obvious is that Endpoints have limits. They only allow a fixed number of requests per day, and have a memory use cap as well. Deploying to our own infrastructure lets us put our own restrictions in place, like keeping our traffic with our own private network. And making the transition was as simple as downloading the code from our Notebook and adding it to our git repo (with a few modifications).

Wrapping Up

This is just a small sampling of the ways we’re using Tonic ourselves to continue building Tonic. It’s become an invaluable tool for us when experimenting with new features and ideas, or when just trying to simplify a problem down to its smallest reproducible example.

As always, we love to hear what our users are doing with Tonic, and what they’d like to see us work on next, so please get in touch!

Class Support

Wed, 24 Feb 2016 00:00:00 -0800

We’ve just added class support to Tonic! JavaScript classes are shorthand that make it easier to work with JavaScript’s existing protoypal inheritance. As usual, Tonic is smart about the way it supports this feature, using Babel in earlier versions (like 0.12), but giving you full access to native classes in Node 4 and 5, even when not in strict mode. Give it a try:

class AbstractMockSingletonFactoryFactory { injectDependency() { console.log("Subclasser Responsibility"); } }

This brings Tonic’s ES6 support to near completion, making it one of the best places to try the latest JavaScript features in every version of Node!

Classes (native support 4+)
Symbols (native support 0.12+)
Generators (native support 0.12+)
Template Strings (native support 4+)
Spread and Rest parameters (native support 5+)
Arrow Functions (native support 4+)
Destructuring
Enhanced object literals
Default parameters in functions
Map + Set + WeakMap + WeakSet (0.12+)
Promises
Binary and octal literals
Async functions
JSX

Don’t forget, we’re holding office hours on Thursday if you want to stop by and discuss this or any other JavaScript features.

Introducing JavaScript Office Hours

Tue, 23 Feb 2016 00:31:25 -0800

Have JavaScript questions? Want to discuss ES6, React, or Promises? Then why not bring your laptop over to the Haight to share a beer and some snacks. The Tonic team will be hosting a weekly JavaScript Office Hours, with the first one kicking off this Thursday from 4PM to 8PM. You can get up to date information each week on the website.

Thursday, Feb 25, 2016
622 Shrader St.
San Francisco, CA 94117 RSVP