Usable Live Programming(research.microsoft.com) |
Usable Live Programming(research.microsoft.com) |
As you edit JSX files, after a small delay, components re-render in browser, using React's diff algorithm to reconcile DOM. This means their state is not destroyed. For example, you can live-edit a modal window without having to refresh and open it again. You can change event handlers and debug a complex component on the fly.
There are no browser plugins involved, it's all just JS. This is implemented on top of Webpack, if you want to give it a try, check it out! (I assume familiarity with Webpack, but I plan to write an explanatory blogpost later.)
I'm very excited about this because I think it's the future of front-end development. It is possible thanks to React's separation of side-effects and Webpack's powerful plugin system (loaders are essentially macros).
Project on Github: https://github.com/gaearon/react-hot-loader (contains an example you can run)
Demo video: http://vimeo.com/m/100010922
What I think I would appreciate more than "live" values of variables etc. would be integration of some statistics into IDE. For example, how often was this function called? What is the usual value of this parameter? What is the mean/modus value? What are the outliers? How often was this condition true? And so on.
What you want is some more advanced logging facility, which is completely possible (e.g. Graphs over time in playground); I don't think logging should be limited to just lines of text (an intern is working on log-driven relation graphs).
Anyway, good that someone is playing with this.
Check out Theseus from MIT / Adobe Research: http://blogs.adobe.com/open/behind-the-scenes-with-theseus-a...
http://research.microsoft.com/pubs/211297/managedtime.pdf
It's great research. Near term applicability would be more useful to me as an IDE plugin that works with existing reactive frameworks. For instance, it turns out that the latest Java UI framework (JavaFX) has a reactive/lazy functional bindings framework in it. Every property of every UI widget can be connected to other properties or derived expressions of those properties. Of course Java itself has no support for this so it's all framework level stuff. An IDE plugin / embeddable DSL that understood these constructs and allowed for real-time debugging like in the videos would be useful indeed: whilst I love binding UI widgets to the backend data model with that framework, debugging it can be a total timesink.
You could have glitch for an existing language, but it would look more like ReactJS for JavaScript.
I'd like to capture the execution flow of a method, visualize it and then watch those visualizations diverge from the old code to the new code.
The runtime could collect a minimal representative set of function invocations and then use that in a visualization during the edit,debug cycle one could see exactly how the new code diverges (kinda like having a column of inputs in a spreadsheet).
When it comes to live coding, Pharo is "hardcore" , everything is live, direct , accessible and easily modifiable. Pharo is based on Squeak , which is based on Smalltalk-80 which is based on Smalltalk that means 45 years of live coding experience condensed in beatiful language, IDE and evironment. Pharo can already do all the things that the linked article tries to accomplish.
The end goal is provide a unified direct experience to the user, no delays, no complexities just what you want to do with your code.
So to anyone whos really interested to live coding, try Pharo or some modern implementation of Lisp. Even if you create your own live coding implementation it will give you a good idea how great live coding can be.
I got into a debate with well known Smalltalk guy about this once: my position was that we could achieve complete liveness, where even the past is repaired with respect to code changes, in a way that is responsive. His argument was that this kind of liveness is impossible, and that we should settle for just Smalltalk-style liveness (modify objects directly, fix-and-replace code without "repairing the past").
This is new for computer science in the same way the refrigerator is new for storing food
It is time to move beyond Smalltalk and Self-style reduced liveness.
* Webpack isn't religious and plays well with CommonJS, AMD, whatever. We almost didn't have to change the code when ported from RequireJS.
* Browserify's "all in one bundle" approach is precisely what we wanted to get away from, because our codebase grew like crazy. Webpack supports [code splitting][1] which allowed us to cut initial JS by half.
* As Pete Hunt said on some thread I can't find now, Browserify doesn't bring anything really new to the table. Webpack, on the other hand, brings "loaders" (first-class support for applying cacheable transformations as a build step for module). While they are not documented very well[2], they allow insane extensibility. They can be used for anything, from declarative code splitting with require() returning a promise[3], to compiling LESS[4], to bundling CSS as a JS dependency[5], to running JSHint[6].
* Hot Module Replacement gives each module an API to declare how it reacts to its dependencies being updated[7]. Loaders can use this API too, e.g. `style-loader` uses HMR to replace stylesheet without reloading the page[8], so you don't need to write extra code.
The biggest downside right now is the documentation being too technical. In the long run though, I believe Webpack will get more popular once its docs are improved, because it's just crazy powerful and extensible.
[1]: https://github.com/webpack/docs/wiki/code-splitting
[2]: https://github.com/webpack/webpack/issues/360
[3]: https://github.com/gaearon/promise-loader
[4]: https://github.com/webpack/less-loader
[5]: https://www.npmjs.org/package/style-loader
[6]: https://github.com/webpack/jshint-loader
[7]: http://webpack.github.io/docs/hot-module-replacement-with-we...
[8]: https://github.com/webpack/docs/wiki/hot-module-replacement
Scaling will perhaps come with time, by which I mean managed time. It is a nice goal for next gen languages.