RunKit looks great, and upon finding it I quickly went to work putting together a little React.js demo for some colleagues based on the One More Thing… notebook—but it’s slow!
Truly, taking couple seconds for a round-trip to the server is totally reasonable. I don’t fault RunKit at all for that. But the code I wrote doesn’t need to run on the server, so I wish I could toggle an option to run it in the reader’s browser instead. As a bonus, it would reduce load on RunKit’s servers.
I’m sure it’s something that would be nontrivial to implement, and would take some UX finesse since certain features wouldn’t work in browser mode and that has to be explained to the user somehow, but I hope it’s a feature you’ll consider making.
Thanks! I’m so glad you’re using RunKit and providing feedback!
So first, let me try to outline some of the things that happen when you hit “run”.
To start RunKit parses your code finding all the requires, RunKit then load all your required packages (and of course their dependencies) at the appropriate versions. We also transform your code so all the latest ES features (which V8 doesn’t fully support yet) are available (e.g. await). It’s only after all that do we evaluate your code.
Now, I don’t have the stats in front of me, but loading your dependencies and doing the code transform is probably taking longer than the evaluation itself. So even if didn’t evaluate the code itself, it’s unlikely you’d see any speed improvements from running your code in the browser itself (also the payload sent to the client would be much larger). As you mentioned, there are also certain UX features we’re need to explore.
All that said, we’re actively working on making things faster, with a focus on requires specifically!
If I understand correctly you are asking us to run code locally for performance reasons (not feature reasons?).
The difficulty here is that the purpose of RunKit today is to provide users with a fully functional node environment. We had at various points considered “faking” this in the browser, but there are many issues:
Many even simple JavaScript features behave differently in the browser than in node (and even in each browser). As RunKit is often used as a bug reporting tool, this can be quite bad.
If we disregard this, its still not clear when the code will be “browser equivalent”. This is particularly true if you require a library, where we’d have to ahead of time know if the library is “environment agnostic”.
Even if we could know this, we’d have to build in some way to download that library into the browser. Again, RunKit actually loads the latest version of the library available on NPM (or the version you want), so now we’d be having to pre-load all sorts of different libraries for people, just to avoid the server roundtrip.
For this reason we are instead constantly working on just making the current process faster, which we very much want to do!
Thank you both for taking the time to discuss this with me.
I’m just going to level with you. I’m primarily a client-side developer and I want something that does what RunKit does, but for browser code instead of Node.js code. JSFiddle with RunKit’s UI. Perhaps I should have put it in those terms to begin with. If that’s not something you’re interested in or that fits your vision for RunKit, that’s understandable. But I wanted to put the feature request out there anyway, just in case.
Regardless, I appreciate the work you’ve put into RunKit and I’m certain it will be useful to me for Node.js work in the future.
Just to clarify so we know the proper feature request:
If RunKit ran “as fast” as if it were running in the browser, would that alleviate this concern (again, trying to figure out whether you want browser features or performance).
If you do in fact want browser features, could you go into a bit of detail how you imagine the RunKit UI working with browser JS (it wouldn’t for example have a “CSS portion” like JSFiddle etc, so just want to know what you’d prefer, that way we can start thinking about how we’d support it). In some ideal universe “browser JS” would be an option in the node-js drop down that you could switch to, but again, not clear what would happen in that case.