why remain an "app-in-url":

1. when saved as a bookmarklet, the app works even if the site (or even the computer's network access altogether) is down
   • then again, it will be rare for the site to be down, given GitHub pages' uptime stats,
     and if there's no network access, well, who would use a browser notepad anyway?
   • you can save the html file to your disk and have a local copy that works regardless
     (note: this is an argument for not splitting the script & css to a separate file;
     the ico file should likewise be included as a data URI in the html ← done in 093c4bf)
2. the readability and length limitations of a data URI / browser URL bars / a href attributes
   may force the code to remain short and concise.
   • on the other hand, that's pretty much a hack;
     it would be much nicer to have properly indented, documented and linted code.
3. instant loading (no network request). Note that this only works
   if the data URI link has been saved as a bookmarklet, otherwise the loading is instant alright,
   but only after the host page has been loaded, which defeats the purpose.

why abandon the data URI approach and become a regular web page:

1. having the app in the url bar was cute/clever when it started out (d71b37b)
   
   as "data:text/html,<textarea%20autofocus/>",
   but now it's not practical to either write or read that anymore
2. if saved as a bookmarklet, updates (bug fixes or new functionality)
   don't become available unless the bookmark is manually updated/replaced
3. having the whole app within a string in a href attribuite of a link is ugly, hard to maintain,
   and requires extra encoding that wouldn't be necessary otherwise
4. this doesn't matter much, but if we want to be pedantic, github (and any other code analysis tool)
   will report accurate stats for languages used in the project
5. usability/convenience: going to browserpad.org would drop anyone directly into the text editor!
   (this would require a proper "about" dialog though)