An interactive way of blogging about JavaScript | Hacker News Reader

An interactive way of blogging about JavaScript

blog.klipse.tech

137 pointsviebel33 comments

We share a similar vision at Tonic that code snippets should be completely runnable. With Tonic embeds ( https://tonicdev.com/embed ) your code is automatically connected to every version of every one of the 300,000 library on npm (just require("library") or require("library@version"), its already pre-installed). Additionally, the code is run in an actual container, so you can use filesystem examples, spin up a web server, whatever you'd like:

1. Example that spins up an express server in the example you can actually hit: http://blog.tonicdev.com/2016/03/09/snapshots.html

2. A blog post I wrote about hacking JSX with many runnable examples: http://tolmasky.com/2016/03/24/generalizing-jsx/

3. Node's fs docs with the examples converted to embed: http://capicue.com/fs.html

Good to see Tonic Dev is still alive, not sure what you guys are doing though because there have been no new features/fixes for as long as I can remember and performance and bugs are still bad and highly visible.

For other people: Is there anything like Tonic Dev (notebook kind of thing) that runs locally? I want to love Tonic but without offline support, that will never happen...

Lots of stuff in the pipeline, any specific feature requests in particular? With regard to performance, are you by chance using Firefox? We have some known issues there.

Check out jupyter. It hosts a variety of runtimes including JavaScript and has tons of other goodies like an interactive debugger and graphing. Very powerful.

I built something very similar a while ago: https://github.com/ghinda/jotted

I'd say it's more lightweight by default (it's not mandatory to use an editor like CodeMirror) and more flexible because of the plugin system (there are plugins for using Ace or CodeMirror as editors, or for compiling ES6, CoffeeScript, Less, Stylus, Markdown).

It also has a Console plugin, like the one in devtools, that makes it work like klipse. https://twitter.com/ghindas/status/697790917302996993

There are a bunch of demos on the site: https://ghinda.net/jotted/#demos

Shout-out to @ghinda for creating Jotted. We've been using it for our startup [Educative](https://www.educative.io) and are pretty happy with it.

Very nice. I may use this the next time I blog about JavaScript.

One inconvenience. I entered "while (1) {}" and the page locked up and needed to be reloaded. An infinite loop could easily happen unintentionally, and it's not user-friendly to hang, especially when the goal is an Alan Kay style educational/interactive system. It would be nice to have a "stop" button so the user could continue editing, rather than losing the page. Unfortunately I don't see any way to do this within existing browsers.

The khan academy code editor is nice like that and avoids infinite loops.

I've watched people use "learn to code" websites with this sort of auto-running javascript trip up on infinite loops and get frustrated as the page freezes. A sure-fire way for a user to accidentally do this is for them to make a `while(true)` loop first before trying to add a `if(x) break;` statement inside of it, or when they're trying to make a recursive function and mess it up.

The problem is that the page is just having the browser execute the javascript directly. Javascript in the browser doesn't have ways to directly debug itself or enforce resource limits. It would be nice if there was a javascript interpreter (yes, in javascript) that could enforce step and resource limits and have debugging support that pages could interactively embed.

The same site has also done similar plugins for ClojureScript: http://blog.klipse.tech/clojure/2016/06/07/klipse-plugin-tut...

And Ruby: http://blog.klipse.tech/ruby/2016/06/20/blog-ruby.html

The Alan Kay quote struck me as interesting.

There is no reason why Wikipedia couldn't do that.

I wrote a MediaWiki plugin to do pretty much this for JavaScript. I use it for helping teach kids JavaScript. http://fingswotidun.com/code/index.php/Main_Page

The difficulty arises when you want to extend the abilities of the wiki to do things like this within the revision/revertible mechanism that Wikipedia supports.

It is indeed something that makes sense. But I think it opens up a can of worms that is not just related to revisions.

Now that articles are not just text and images, they need a standard on what they can support. What version of Logo will they use? Do they have an emulator, or a transpiled JS VM? Who created that? Will that support mobile devices? How do you enter text on those? What are the licenses involved? OK, Logo is a given, but what else will they support? JavaScript? Processing? C++? What version of the compiler? Do they host it themselves or use a public service? It gets blurry. What about the article about an old computer, will they also embed an emulator? Those exist. And a game if it's public domain? It's a computer, after all, right? Where do you draw the line?

I agree with the sentiment, but there are big logistical and political problems related to that. Just look at how weird their audio/video support is already because they wanted to make sure they're using free players, free codecs, free assets.

I realize I'm only listing problems, but it's important to think of those. From my perspective, I think it's a lot more about WikiPedia picking their battles and focusing in textual information (with tidbits of other media) rather than "never thinking about that".

Actually letting people play with the technology is an awesome thing, but I wonder if WikiPedia is the place for that.

Good thing sites like https://archive.org/details/softwarelibrary_msdos_games exist.

It is also worth mentioning that a vast majority of code snippets is not runnable. They are fragments of large programs, might require additional files (going far beyond some standard libraries that one can pull, etc.).

All in all it would help, but only with trivial snippets approaching hello-world complexity or self-contained examples better suited for tutorials rather than encyclopaedias.

But there may be reason why Wikipedia should not do that.

This looks like another vector for XSS... when controlling your own content, no big deal. But if Wikipedia becomes an opening for people to run arbitrary JS code in the browser... even if only for a brief time until another editor corrects it. Well, I can see why Wikipedia might not want that.

Very cool indeed. I would implement it as a React component - and then in any view just have to

    <Javascript>
      [1,2,3].map((n) => (n+1))
    </Javascript>

But the of course requires you to implement the page using react, which isn't what everyone is doing.

Could use web components, which are supported in some browsers, and can be polyfilled in others.

I think you'd run into escaping issues like that. It would have to be:

    <JavaScript src={`[1, 2, 3].map(n => n + 1)`} />

Jeff Atwood also has a very great writeup of something similar to this on his blog[1]

I also have something similar going on with my blog. It focuses on game development, so I actually embed an iframe with a canvas to let the users play around with the code as they learn.

I really think that interactive interfaces like this for blogs and tutorials will be more common place in the future.

[1]https://blog.codinghorror.com/our-programs-are-fun-to-use/

Link to your gamedev blog please

Nit: using highlighted monospace for every language name and proper noun is both wrong and distracting.

Yeah if that's another new way to blog about JavaScript then I'm out.

This is really cool. Another similar system I saw recently is http://www.joelotter.com/kajero/ which aims more towards the data visualization side of things by including native support for D3.

Unless approached very carefully this has some frightening XSS implications: innocent looking HTML entered into comments could suddenly become automatically executed JavaScript.

A smart thing to do would be to run it in an iframe with the sandbox attribute so that it doesn't get access to the page's or origin's data, but that wouldn't protect from local denial-of-service attacks against the browser that infinitely loop or allocate tons of memory.

When I made my MediaWiki Plugin I don't think the sandbox attribute was not a thing.

What I did was run code in a worker with events and drawing commands passed through messages.

http://fingswotidun.com/code/index.php/Naughty_Bits

There's probably still a few more things to do to make it properly secure, but at least you can't just kill the page with while(true);

This is actually pretty cool. One of the major things that actually help learning JS is how easy it is to test out a piece of code before writing it to your main code base. Simply pop open a JS console on any browser and test that line out that you aren't sure would work.

This works in the same vein and lets you play around with the code you are learning. I am definitely using this the next time I blog about code or algorithms

On mobile it works horribly: I try to delete some characters and it gets autoupdated and recovers those characters, so deleting becomes impossible.

I agree with this sentiment but why stop at JavaScript? With repl.it you can embed dozens of languages (albeit not yet editable in the embed). Here is a quick demo on my blog http://amasad.me/2015/04/09/hello-world/

The problem with embedding iframes is that each iframe runs on a separate context. For instance, you cannot define a variable in one iframe and access it from the other one.

It's not that Wikipedia devs can't imagine it, it is the social pressures of the project that make it impossible for someone to realize a change of that scope.

Mediawiki plugins or Greasemonkey scripts pave the way for what takes years of "project work" to integrate.

Does Medium support this?

Worth mentioning that you can embed CodePens. But yeah maybe this is nice for some things, like demos of pure logic that don't need markup/CSS.

I like it.

Reply on news.ycombinator.com