really nice, was just looking at trying to use Jupyter but their JS kernels gave me issues. Being able to use arbitrary packages would be nice, babel transpiling would also be cool.
I looked into Babel but the standalone package is (comparatively) massive. Could be an optional extension, possibly.
I think it has potential for use as a way to write documentation for JS libraries, so being able to use arbitrary packages is certainly something I'd like to add. :)
One option to allow arbitrary packages that plays well with a gist-hostable style of notebook is to make use of the JSPM CDN (details towards the bottom of http://jspm.io/). I've used that for little gh-pages hosted experiments in the past. It can be a powerful way to access both the GitHub and NPM ecosystems of JS libraries.
The JSPM CDN could also provide a way to load transpilers like Babel, Traceur, Closure, and Typescript.
I grew up in what was almost certainly a post-ASCII world (my first OS was Windows 98; I was 5). Despite this I still have a weird fascination with ASCII and terminal-based stuff. I played a lot of MUDs/MUSHs when I was younger, and recently made a game engine for the terminal (https://github.com/JoelOtter/termloop).
I think people will always find relative primitiveness a novelty. Look how popular 'retro' gaming is amongst those far too young to have played the titles in their original form.
(Off to see if my Avalon character still exists...)
I remember reading a novel when I was younger which used this painting as a plot point - supposedly there was some huge secret hidden in it. Operation Red Jericho, I think - must reread sometime.
Hope you enjoy it! One suggestion would be definitely read it in print. The book is packed full of diagrams, images and diary entries which I feel wouldn't work well on an e-reader.
It seems to be one of the front contenders among the Flux alternatives now. Another one is Relay/GraphQL.
Redux adheres to the basic unidirectional data flow philosophy of Flux. Where it mainly differs is that there is one store. All state is kept in a (potentially large) graph of JS objects and arrays. It is also very functional in nature.
One advantage is that it solves the Flux store singleton problem. This makes it more amenable to building isomorphic apps, among other things.
I've been using it and find that it's more straightforward than typical Flux implementations. There's less boilerplate. It also allows for more heterogeneous data storage and more flexible structure. You don't need to create a new store every time you need a new collection, for example. You can use it to store the majority of your state, and keep your React components largely stateless.
You absolutely can. That said, if your application is to look quite static and you don't really need the game-style render-loop, you could use Termbox directly (it's great):
I like this - got some interesting results, and I like how it tells you which percentage you're in. Apparently I was in the first 1% for Run The Jewels, Bastille and Clean Bandit, which is interesting given I'm not necessarily a fan of all those bands (I love RTJ).
The UI is very pretty but a little slow, and I'm on a relatively powerful machine!
This is more of an issue with Safari than anything else - Apple's slow speed at keeping up with web standards is reasonably well documented (http://nolanlawson.com/2015/06/30/safari-is-the-new-ie/) (note: this article generated a fair amount of controversy when it was originally posted on HN)
I've just tried this site in the very newest OSX Safari and it looks dreadful. Disappointing.
It's not visible if no changes have been made (if the consensus is that's a bad idea I'm happy to change it).