They'll be infinitesimal faster for the server which will sit idle most of the time anyway... and much slower for you when you make a minor header/footer mod locally, and then you need to re-upload all pages that have a header (i.e. all pages).
I'm sorry, but this project feels more like "art" than a practical tool.
Plus, with a few basic lines of PHP (available on every shared host) you can pre-generate your site statically as well (and on the server, to save you the re-uploading).
Presumably the 're-upload all pages' bit can be automated. As far the reset, the trade-off depends on how often you're updating content versus the amount of traffic coming to your site; in many cases, a tiny saving on frequently-occurring page delivery is well worth a big delay on one-off page generation.
Also, I'm surprised I got downvoted for saying that we should be considering the disabled when making decisions on how to structure a blog. I know accessibility isn't _cool_ but it's the right thing to do, especially for a text-based site, like a blog.
(PS: mendelk, I'm not accusing you of downvoting me)
According to a recent podcast I listened to[1] about a blind Software user, it seemed like there is a lot of issues with the current generation of Screen Readers. This includes issues with JS.
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.
I'm sorry, but this project feels more like "art" than a practical tool.
Plus, with a few basic lines of PHP (available on every shared host) you can pre-generate your site statically as well (and on the server, to save you the re-uploading).