The RunKit team is incredibly excited to be representing Stripe at TC39!
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.
Embed.ly now supports RunKit as a content provider, which
means that you can now embed any RunKit notebook on sites like
Medium, or any of the other thousands
of companies that rely on Embed.ly for embedding dynamic content.
Since day one, RunKit has shipped with several fun ways to visualize your data
including graphs, charts, and maps. Internally we call these "Value Viewers".
As package maintainers you often know how to display your data better than we do.
That's why today we're excited to announce we're opening up Value Viewers so
developers can build their own!
This new API allows you to render any HTML for your viewer. To
create a new viewer, simply require the ValueViewerSymbol from the
@runkit/value-viewer package and use it to make a custom property on your
objects. RunKit will look for this property and render a custom viewer if it's found.
Here's an example we've created for displaying the weather in a more intuitive way than JSON (code available here):
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:
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:
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.
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.
We've just deployed support for scoped packages on RunKit! 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:
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, RunKit 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 RunKit turned out to be so simple that we wanted to share the process.
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:
Then why not bring your laptop over to the Haight to share a beer and some
with the first one kicking off this Thursday from 4PM to 8PM. You can get
up to date information each week on the website.
People have used RunKit to write tens of thousands of notebooks. We love calling attention to some of the cool ones that have been published. We'll kick off with a notebook that takes advantage of our latest feature, Endpoint.
Slack is a popular messaging app for teams. Slash Commands is a Slack app that will fetch an external URL when a "slash command" is matched (any message that begins with a slash).
We're excited to announce our latest feature: RunKit Endpoint. One thing we've always wanted is a great way to use RunKit to experiment with HTTP servers. Node is for servers, and now with Endpoint, RunKit is too.
Endpoint turns any RunKit Notebook into a server by exporting a single function, endpoint. This function takes a request and response, just like a typical http.listen handler. That's it: no deploying, no ports to worry about. Your function will be called anytime someone visits the corresponding url on the runkit.sh domain. Here's an example:
RunKit now supports Node 5! Node 5 is part of the Stable release line,
which means it focuses more on features, while Node 4 focuses on stability and security as
part of the LTS release line. You can read about it more here, and you can try them both on any RunKit document:
One of the coolest things about RunKit is the ability to run Node.js code, and even
use any package on npm, without having to install anything at all. Once we had that
working, we immediately knew that it could be useful in so many more ways than just
powering runkit.com. That's why I'm excited to release the first
embedded version of RunKit.
With one <script> tag, you can add a fully functional node
environment to any web page. Your users can write and run code without leaving your
website, complete with access to all of npm. Use it in your blog, or a
presentation, or on any place else. Check it out!
As part of a two-post series, I'd like to share some in-depth details behind one of
RunKit's most asked about features: time traveling. In this first installment I'll be
focusing mainly on how the back-end works: specifically, how we're able to not only
rewind the state of your code, but any changes to the filesystem and spawned subprocesses
as well. From a high level, this allows for a lot of cool functionality like real undo
in a REPL. However, we'll also see how time traveling is actually essential to
the way notebooks fundamentally work in RunKit.