Show HN: Tonic – A data visualizing REPL for Node.js
tonicdev.com
tonicdev.com
Edit: I made one[0]. I love that you force semantic versioning.
Any plans to open the source code or make it available in a way that will accommodate self-hosting? I'd really like to be able to use it to interact with systems (like databases, for example) that are on my local network and aren't practical to expose to the public internet.
First of all, I think that both hosted and downloadable models are both equally viable, and IMHO both are worth pursuing simultaneously.
While I discuss the merits of a downloadable version below, first of all, staying hosted makes a lot of sense, not just because delivering all of npm is... tricky (kudos for managing to provide it :P), but also because it gives you the option to introduce a pricing structure in the future. (That said, please definitely do keep your current featureset free. XD)
A Google Maps Overlay[1]-style API could be a viable solution for developers who choose to use your hosted system who also need access to local resources: I'm thinking something SSL-encrypted (using symmetric keys configured via a dashboard), and perhaps a small (opensource, auditible) endpoint library that connects to your server (over WebSocket or XHR, to work around pesky firewalls), which the developer would be able to connect to the relevant bits of their data with a minimum of SLOC. (I'm not sure if it's outrageously unsuitable - it's probably only useful as an idea - but Netflix' newly-released Falcor library[2] comes to mind.)
I also think a cut-down version of your system could be a very very interesting competitor to Jupyter/IPython, and it's (reasonably) rare for competition to be a bad thing.
(Looking at the whole picture, there will undoubtedly be political types who will take one look at Jupyter/your system and will point out "but one's fully open source and one's freemium," but nobody would be able to argue that, done right, freemium does undeniably have more resources going into it, and the developers involved get to work on something awesome AND go home to a full kitchen at the end of the day, which does sort of guarantee a certain consistent level of quality.)
In this model, you would have this hosted version with ALL THE PACKAGES (wow!) - and maybe some awesome paid features down the track - along with a slightly smaller-scale Github repo that people can clone and fire up locally.
Besides being "trendy", the downloadable version would be a boon for people who, for whatever reason, MUST have an air gap in their systems for whatever security purposes, but happen to be using Node for their work.
Finally, it'd be cool to offer the local version as both a loopback web server (for a standard browser) as well as an Electron[3]-based "standalone console". That puts you visually on par with IPython web notebooks and QtConsole.
Oh, and speaking of UI, one other thing would be to keep the downloadable version's UI as identical to the hosted version as possible, in both look and feel: it'd be a neat little mind trick to make devs feel like they're running your hosted version locally :P
[1]: https://developers.google.com/maps/documentation/javascript/...
I realize that the node module thing is just one example of a feature that relies on hosting, but fwiw I wouldn't mind having to manually maintain a local package.json and node_modules folder for whatever libraries I want to be able to use in the environment.
Of course, I imagine this is a non-trivial feature, and there are likely better approaches.
Super awesome job guys!
If I might start slinging feature suggestions right off the cuff:
- I'm very used to using Cmd + Enter to "submit" a text area and you have Shift + Enter. If I'm alone in expecting something different then of course you shouldn't change it, but if I'm not you might want to consider changing it.
- Let me set the number of spaces in a tab. I'm used to two and while looking at four isn't a game breaker, why tire out my fast thinking brain #1 trying to parse something unusual? I would like to control it.
Someday there will probably be preferences for all of this, but we wanted to focus on the core experience first and get something out there people could use.
Are you guys going to open source it or will this be a paid service?
There's certainly a ton of stuff we'd love to open source, but we've been focused on getting it out the door. This product is also interesting in that the ops is as challenging as the code itself, so there may be some interesting opportunities to offer paid services later, if people start wanting to do more interesting things with it. We're really just kind of hoping people show us how they can use it.
Any plans to support compile-to-js languages? Coffeescript, etc.
Additionally... Tonic is comparible to CodePen in terms of testing and thus gave me the idea;
Perhaps you could also include other languages into your platform. Such as a Stylus REPL, SASS, SCSS etc. all of which, like CoffeeScript, are just JS modules on npm.
With compilers like Stylus and SCSS you would probably default the return value to be the compiled CSS, and with Coffee you'd need a toggle button to show what the compiled JS looks like, though not 100% necessary.
With that said, if there was just a way to set up a "build" script for a REPL to set up the environment to achieve the same result. As in, you require('stylus') then have some global variable stream/buffer, tonic.output, for which you could inject into the module of your choice to generate output, and then save it via tonic.buffer.write() or something. It could then be ridiculously flexible in terms of testing out finicky new languages/compilers.
If I delete a file through there, and "go back in time" would the files would still be there?
Wouldn't that mean it's opaque, since we can't see see into it?
PS. That's picky. This is a rad project and I love the time travel & the 'requiring packages automatically installing them' feature too.
The key differences I would say are:
1. The fact that you have access to every NPM package. Node is now the environment with the most amount of packages, chances are someones solved part of your problem already, why not have all that code at your fingertips?
2. It was crucial in our mind to exactly match the behavior the code would have if you ran it through node as if it were a straight file. That means, for example, that every cell has to execute synchronously after the last (not async, you can't have ticks happen in between cells -- you're code will now behave dramatically differently if you download it, especially in an environment so dependency on asynchronous behavior like node). It really is like a living file: even hoisting works -- you'll notice that if you modify a function that is referenced in an earlier cell, Node will notify you that you've "changed" the past, and will rerun from that point. This is very different from the additive nature of iPython style repls where every cell stomps on top of the last. In Tonic, no code that has run isn't on the screen: because it really is like just running the file (again, you can download it and run it yourself).
3. Related to 1, notebooks are also easily publishable in a living way: a node notebook is just a node package. So you can require an notebook from any other notebook, instant sharing.
4. Our take on object viewers - we want these to be discoverable, not a part of the code, its a view on the results. Tonic fundamentally deals with Javascript objects, but the object viewers are applied on top -- post execution you can decide to look at an image as an image, or hex viewer, or download. An array could be a coordinate or a graph, both are available to you to switch between, not a function you call to display your data. We really want the tool to help you find new views on your data.
-- For 1, that's analogous to having every python package via pip/conda, and the same for other juypter langs.
-- For 2, this is scary/hard for traditional notebook usecases. IPython gives the user control, so there is no fear of beach balling & unintentional outside effects. I do appreciate the intent however :)
-- For 3, a notebook is just a json file and shareable. In fact, you can share a python notebook with a js app and it'd still work. With maybe 50loc, you can even keep the require syntax.
-- For 4, we're doing this within juypter just fine, and bokeh as well.
We recently went through a similar decision making process, and, when thinking about the above and more, decided it'd be better for the community for us to add features to Juypter than make yet another notebook. I don't think Juypter is the end-all (though for none of the reasons above), so I'm still confused here.
Is this stuff one-liners? Or is this a gimmick? If not, consider this a feature request.
This is meat. What you've got is fluff. No offense, its neat and you're obviously capable of what I'm suggesting. Take on the core problem of charting and you can create real value here.
1 - When trying to add release notes it closes the modal every time you press a letter, though the letter is still there when you reopen the modal.
2 - After publishing a second time the modal can no longer be closed and remains open until a full page refresh.
I am interested in how they achieved very clean async/await support. I'm assuming they are using some pre-processor.
Anyone more into the node-ecosystem can shine a light on this ?
It would be cool if you could plugin coding snippets to your own website. I'm writing JavaScript tutorials and this would be very helpful.
The feature in question is the following. We support hosting, so you could have two cells like this:
[Cell 1] f()
[Cell 2] function f() { return 5; }
Normally "dirtying" is simple, if a cell from the past has changes, then the future changes. However with hoisting, sometimes the future can change the past. You'll see that in Tonic if you were to change the 5 to a 7, Cell 1 would appropriately dim letting you know the machine will go back to that point to rerun.
also coffee script!
* im changing code in a block but every time i eval it the 3 code blocks above re-expand the results i just hid... because the last one was `_ = require('lodash')` it prints like 70 lines of func defs :/
minor gripes:
* console.log(1,2) produces two lines of output, the browser version produces "1 2" (and then wraps every 3 lines, kind of inconvient when you log (i, array[i]))
* ctrl - y redo doesnt work (ctrl z does tho)
* the dom jitter from the results div disappearing, pause, appending "loading", then appending a large div, feels off. possibly lock the height, then replace contents w/ "loading", then transition to the new results size, if you can calculate that is better. really good tool tho gj.
really minor issues! im not logged in, idk if that matters
Yeah the console.log thing is for when you have two objects, you want them on two lines. However, we could get smarter and collapse lines (that were together) if they have no fancy object viewers.
And yes -- I don't know why we chose three, we'll probably expand that.
Sorry about redo, it should work, we'll look into it.
It's incredibly cool already. This could be start of beautiful blog platform. I hope github buys you for crap load of money.