The Chrome Javascript editor can do hot swapping
smotko.si
smotko.si
[1]: http://emacsrocks.com/e11.html
Basically, you can hook Emacs up to the browser and interact with the page directly without having to refresh it. You can do some really cool stuff as shown at the end of the screencast.
All this without having to sacrifice the inherent editing and programming power of Emacs.
In the screencast, code gets reevaluated using a key command (C-x C-e), just like Emacs does for lisp. However, since Emacs is extremely programmable, it would be pretty easy to set it up to run any new code as soon as you finished modifying it, or on a timer, or however you like.
As an aside, the rest of the Emacs Rocks! videos are also worth watching--they make it very clear why people really like Emacs. For example, episode 12 (about editing HTML with Emacs) not only shows how powerful some of the default modes are, but also how easy it is to customize commands.
Live editing (or "hot swapping" as it's called in the article) is my main, long-term objective. I can only devote so much time to it, and it's not as far along as I would like it to be. But, getting there... do take a look at the other branch if you're curious.
If I ever get back to web development--and, the way these things usually go, it's probably inevitable--I'll definitely give kite a go.
This is just hot swapping (as they claim), it's been around since before smalltalk.
I would add that this all seems to be in pretty early stages on the WebKit side, too. For example, I had hoped that when the debugger hits a breakpoint, and you hot-swap code in the current call frame and restart the frame, what would happen is what you'd expect to happen, alas--at least with Chome Canary--this doesn't seem to work yet.
So yes, you're right that true live editing is not around the corner, with or without Kite. I'm just aiming to get as close as possible.
> And yet, if making a live programming environment were simply a matter of adding “continuous feedback,” there would surely be many more live programming languages than we now have. As a thought experiment, imagine taking Logo (or Java, or BASIC, or LISP) as is, and attempting to build a live programming environment around it. Some parts of the problem are hard but solvable, e.g. keeping track of which pieces of code have been successfully parsed and are ready to run, and which ones haven’t. Others just don’t make sense: what does it mean for a line of Java or C, say a = a + 1, to start working as soon as I put it in? Perhaps I could test the line right away—many programming environments allow that. But the line doesn’t make much sense in isolation, and in the context of the whole program, it probably isn’t time to run it. [end quote]
Light Table is interesting in this regards, though I'm not sure what they are claiming yet. I (and others like Jonathan Edwards) think we'll have to accept significant changes in our programming models to achieve true live programming, that we can't just tack it on transparently to our existing stack, e.g. by snapping back a few stack frames on an edit.
[1] http://llk.media.mit.edu/papers/ch-phd.pdf, page 56 bottom
Really I'm just trying to improve turnaround time when developing Web apps. I think that between full-page reloads and research into better programming models, there's some middle ground worth exploring. I guess I shouldn't be using the term "live editing" for that, though.
Like CTRL-A in bash (I'd mentioned it in passing, and someone was excited to find out about it); ESC-. in bash as well to insert the last argument, incredibly handy for quickly injecting long paths. I did a talk on tmux at work, and it went over extremely well with those who attended, much beter then expected.
I guess the reason I think this way is I imagine I'm the dumbest person around, so I assume if I know something, everyone else must. And if I mention it, a part of me feels like I'll be exposing some weakness. It's stupid of me to think that way. It's a personal failing, I know. Even knowing it though won't change my way of thinking.
Sorry for hijacking.
IIRC if you do a force reload (right click the reload button with the inspector open) that bypasses cache, that should reliably destroy any local edits.
And because of this inconsistency I never knew whether I changed the wrong peace of code or the extension didn't do it's job thus making the extension pretty useless...
Speaking from experience, hot swapping JS sounds much better than it actually is in practice. First, as mentioned above it randomly fails with no explanation from Chrome. Also, I find a lot of code I want to hotswap runs on DOM ready and assumes that the page has just been loaded.
On the other hand, CSS hotswapping in Chrome works really well.
Have you tried getting in touch with Chrome developers? Printing out info when hot swapping failed would really make you extension useful.
Weirdly, I haven't noticed failures while using the Chrome editor. Might be that I just haven't logged enough hours with it yet, but so far it was working flawlessly.
Maybe it would be possible to put all your "setup" code into a single myscript.load() function and then when you've edited your js in chrome devtools, then call myscript.load() in the console to reboot all your DOM events and so on.
Just an idea, completely not tested.
P.S. Just tried your extension using vim to edit a Sass file, while compass watch is running, and your extension is watching my CSS output directory. Awesome to see changes in vim almost immediately appear in my browser!
EDIT: Formatting. Adding P.S.
https://plus.google.com/u/0/+GoogleChromeDevelopers/posts/64...
Anything else you'd like from them while you have their ear?
1) Taking suggestions from sources like this so easily ("Hey, look what I just read on HN, we should do that!")
2) Implementing a change so quickly - most companies as large as Google can take days to approve a change in a product as widely used as Chrome. (I am aware that most users won't use the developer tools, but with any added functionality comes an added unforeseen bug.)
http://worrydream.com/LearnableProgramming/
I don't understand how someone can link to his 'Inventing on Principle" video in the second paragraph of their web page and fail to comprehend the material it covers in just the first 6 minutes of its running time. Note, that Bret Victor despises the term 'live-coding' as a description of this work.
Yes, in Chrome you can technically hit "Shift+Enter" anytime you want a line break, but you cannot tab. Regardless your script will disappear after you execute it. Yes, you can make what you just typed reappear by hitting the up arrow, but then it's again difficult to edit it. It also does not support undo/redo.
That'd a fantastic feature to have in Chrome.
Just give us a proper multiline editor with syntax highlighting, line numbers and all the rest already.
I can edit stuff in the Elements tab, but the article suggests it's possible to do so in the Sources tab...?
Which version do you have?
The files in Sources tab become editable if I turn "pretty print" option on and then immediately off. But afterwards, whatever changes I make have no effect on what's displayed. Even if I right click and "save" my changes, the original unmodified source is saved (despite there being something edited in the Sources tab)...
So strange.
This is a problem because your IDE/text editor could have support(native or via a plugin) for the chrome debugger protocol[2] and update the js as you edit it, but you can't have the debugger open at the same time.
[1] http://code.google.com/p/chromium/issues/detail?id=129539
[2] https://developers.google.com/chrome-developer-tools/docs/de...
Now of course Lisp dialects had that 50 years ago or so and... Any modern which can run JavaScript can run ClojureScript and hence already had hot-swapping ; )
But it's good to see non-Lispers getting there eventually ; )
Don't get me wrong, I love FF, but the developer toolset in Chrome is amazing.