Dynamic Code Injection for Good(stanfy.com)
stanfy.com
Dynamic Code Injection for Good
http://stanfy.com/blog/dynamic-code-injection-for-good/
2 comments
The biggest problem that forces you to run through all the pre-setup UI views and other stuff is that often time you need those to recreate states, and when you have a bug, more often that not, you have a corrupt state, which will stay corrupted with or without code injection. dyci is definitely a very neat method but of limited use.
I have a secret "eval" page on sites that's enabled during development (protected by a huge password, just in case, though). It evaluates code & shows the results as I'm typing it in real time. Better than a console.
Take this page away from me, and I'll develop at least twice slower.
Take this page away from me, and I'll develop at least twice slower.
I'm interested in what ways it is better than a console? Do you add any specific features that help productivity?
I just discovered that my answer only shows when I'm logged in to my "mantrax" account. Did HN mark me as a spammer or something, WTF?
Anyway, here goes my original answer:
- Code and results side by side.
The screen is split in two, both have independent scrollbars. 1) Left column, a roomy text editor (the minor annoyances like tabbing, or CTRL+S bringing the save page dialog are easily fixed in JS, heck there are full blown editors I could use if I care, with syntax highlighting etc.). 2) Right column - results. Often when the result of your code is a large data structure in a CLI, you lose sight of your code - not here.
- Entering larger structures (functions, classes)
Often you need to copy a block of code and tinker with it and see what it produces. In CLI this can be either impossible, or awkward - you can't normally enter a class line by line, it should be entered at once. But in a roomy textarea, you can just paste it, and it just works.
- Entering (and not losing) initialization code
Likewise for any initialization code. On the command line it's very easy to test one-liners, but code that requires setup, loading your current project environment, and instancing a few objects and configuring them, the CLI comes short. If I do something wrong the CLI process might also die (fatal errors, exceptions, endless loops etc.), and lose my carefully set up test. With an eval page, every time I type something, the entire block of code gets re-evaluated from scratch, including the state set-up, nothing is lost.
- Copying code blocks back into my project
Just like it's easy to copy code form my project into the eval box, sometimes I produce a useful bit of code I want to paste back into my project. When you have code and results mixed in CLI that process becomes quite tedious. With the eval page textarea it's quick and natural.
- I don't have to finish a line to see my results (or mistakes): real time evaluation
In a CLI you need to finish typing the line and hit Return to see what happens. Then to correct it, you hit up, the line is copied and you get the chance to correct it, but in the process littering your CLI history with useless entries that are confusingly similar (but most of them are wrong). In an eval box, you can get live feedback as you type (I've made it so if you pause for 200ms, it re-executes the code and shows results), and you don't have to "copy" a line to fix it - the line is there, editable, so you just edit it. Let's say you're not quite sure about an argument format in some API call - tweak it, pause for a split moment, you see the result. Very easy to find the right code intuitively, by experimentation. Heck, sometimes it's faster than reading the documentation! Hehe.
- The power of HTML, JS widgets and the browser's developer console all come out of the box
Last, but not least: if it's in the browser, it means you have access to HTML and JS widgets. If your result is HTML, you can see the HTML DOM rendered, not just the code. And you have access to the browser's own debugging console. I can dump an object tree to the console as a dynamic expandable tree with a set of little [+] and [-] buttons. It's a different world entirely. A better world.
Anyway, here goes my original answer:
- Code and results side by side.
The screen is split in two, both have independent scrollbars. 1) Left column, a roomy text editor (the minor annoyances like tabbing, or CTRL+S bringing the save page dialog are easily fixed in JS, heck there are full blown editors I could use if I care, with syntax highlighting etc.). 2) Right column - results. Often when the result of your code is a large data structure in a CLI, you lose sight of your code - not here.
- Entering larger structures (functions, classes)
Often you need to copy a block of code and tinker with it and see what it produces. In CLI this can be either impossible, or awkward - you can't normally enter a class line by line, it should be entered at once. But in a roomy textarea, you can just paste it, and it just works.
- Entering (and not losing) initialization code
Likewise for any initialization code. On the command line it's very easy to test one-liners, but code that requires setup, loading your current project environment, and instancing a few objects and configuring them, the CLI comes short. If I do something wrong the CLI process might also die (fatal errors, exceptions, endless loops etc.), and lose my carefully set up test. With an eval page, every time I type something, the entire block of code gets re-evaluated from scratch, including the state set-up, nothing is lost.
- Copying code blocks back into my project
Just like it's easy to copy code form my project into the eval box, sometimes I produce a useful bit of code I want to paste back into my project. When you have code and results mixed in CLI that process becomes quite tedious. With the eval page textarea it's quick and natural.
- I don't have to finish a line to see my results (or mistakes): real time evaluation
In a CLI you need to finish typing the line and hit Return to see what happens. Then to correct it, you hit up, the line is copied and you get the chance to correct it, but in the process littering your CLI history with useless entries that are confusingly similar (but most of them are wrong). In an eval box, you can get live feedback as you type (I've made it so if you pause for 200ms, it re-executes the code and shows results), and you don't have to "copy" a line to fix it - the line is there, editable, so you just edit it. Let's say you're not quite sure about an argument format in some API call - tweak it, pause for a split moment, you see the result. Very easy to find the right code intuitively, by experimentation. Heck, sometimes it's faster than reading the documentation! Hehe.
- The power of HTML, JS widgets and the browser's developer console all come out of the box
Last, but not least: if it's in the browser, it means you have access to HTML and JS widgets. If your result is HTML, you can see the HTML DOM rendered, not just the code. And you have access to the browser's own debugging console. I can dump an object tree to the console as a dynamic expandable tree with a set of little [+] and [-] buttons. It's a different world entirely. A better world.
[deleted]