This seems like it's a lot of overhead for what amounts, in terms of capability, to a reimplementation of greasemonkey. It also makes you implement finer controls on execution by url yourself, whereas greasemonkey has them in its syntax. The author states,
"GreaseMonkey user scripts are great, but you need to publish them somewhere and re-publish after making modifications. With dotjs, just add or edit files in ~/.js."
but this caveat is just as strong for files you maintain outside of your browser, and some browsers' implementations of userscripts/greasemonkeylikes actually have a similar filesystem-based model for managing scripts already.
While respectable, I had hoped to be more impressed by a tool that beckons me to "hack the web".
You know that once a user script is installed in chrome you can edit the script.js file in the extension's directory on the fly. It's a little more work than simply putting a file in ~/.js but it doesn't require a HTTP server to function.
True, and this is why I love dotjs. Thanks for making it!
Maybe a good followup project would be to use some of the dotjs code to help make a filesystem-based GreaseMonkey system for Chrome, which would be just as easy to manage as dotjs scripts are.
Unless you don't use Firefox and you tend to have a lot of dot files that you hack around with in your home directory. Then it starts to seem pretty awesome.
I've sneakily been using this for months on Hacker News itself- I just .hide() stories past around story #15. More signal, less noise. And it's just jQuery, so it's really easy to whip up.
It's interesting how perspectives differ on what is considered noise. On the average day I start my browsing here around link 15, or even the new queue.
You're pretty much guaranteed to hear of anything hitting the front page anyway if it was meaningful to begin with. If not, it's probably some momentary obsession or buzzword bingo (say, "Google", "Social", "Facebook killer", "Privacy", "Product launch" to take an ephemeral example :))
I quickly scan
http://hckrnews.com/
which makes sure I don't miss any upvoted story. It does have a lot of noise, but going through 20 or so articles since last time i looked doesn't take that long
"GreaseMonkey user scripts are great, but you need to publish them somewhere and re-publish after making modifications."
Publish them where? I don't understand this. Whenever I change a user.js file and save it the browser updates it and it's ready to go next time the page reloads.
Did you investigate requesting the files directly from the filesystem, like "file:///home/monkey/.js/google.com.js".
You'd need to tell users to enable file access for the extension though chrome://extensions/, since that isn't enabled by default and users have to opt into it. I also don't know if there is a way to get the current user's homedir without hardcoding it.
Also: you're being super careful to not allow arbitrary reading of the filesystem, right? A good sanity check would be to ensure that realpath() of any file served is under ~/.js before handing it off.
ahahahahah what? Dude, do you work for Microsoft? "Well see, we just have to run MS-SQL server (DESKTOP OMG EXPRESS ENGINE) here, and then we run IIS on top of it to serve this file listing..."
It's a limitation of Chrome. This isn't the first time that someone tried to use a local webserver to do something that Chrome doesn't allow. IIRC, there was someone that used a webserver to implement a hacky version of It'sAllText! for Chrome.
It looks like Ruby is only needed for the file server. You could easily substitute a Python file server (cd .js; python -m SimpleHTTPServer 3131). You could use a remote Apache server for synchronizing your scripts. I agree that Ruby is a little overkill, but it is simple enough to run easily on a Mac, and it is extensible for hackers.
Python usually, as far as I can tell. Either language is fine, I just think these things should be done in something that comes pre-installed on more systems.
I mean, I knew Chris years ago and his language of choice was Ruby, and I don't think it's changed.
Sure basic install-ability is great, but I bet you this tool was made to satiate an itch he had, and he used the tools he's used to. Little apps like these aren't engineered. Just hacks, for hacks sake.
Sounds like a relatively easy way to replace dependence on Ruby would be to just load the scripts directly from one's GitHub repo, where all your scripts can be easily synchronized.
See also jsshell[1] for Chrome. Press the button and you can run jQuery-powered JS on the fly, save snippets and run them, even automatically on regex-matched URLs.
I'm waiting for someone to build a social browser extension on top of something like this. Anyone could submit custom CSS/JS for a website and the most upvoted "theme" automatically gets loaded. Sure the JS security issues might be a nightmare, but the web would look soooo much prettier!
Great work! But I had some trouble getting it to run on my Mac.
I think it might be because I use VirtualHostX - http://clickontyler.com/virtualhostx/ - which alters my hosts file. I had to create a host - http://dotjs/ - pointing to my ~/.js/ folder - then edit the Extension JS to point the Ajax to http://dotjs/ instead of http://localhost:3131. A bit of pain but it might just be who this affects.
it will look for the js file in the extension directory instead of the local ruby web server, and this should work for any platform. To take the ~/.js convenience, a symlink in *inx system or shortcut in window will do the job.
Looks like you'll have to modify the Rakefile to use whatever Windows uses to launch the webserver. If you don't have ruby, you could probably write one in your local language of choice.
"GreaseMonkey user scripts are great, but you need to publish them somewhere and re-publish after making modifications. With dotjs, just add or edit files in ~/.js."
but this caveat is just as strong for files you maintain outside of your browser, and some browsers' implementations of userscripts/greasemonkeylikes actually have a similar filesystem-based model for managing scripts already.
While respectable, I had hoped to be more impressed by a tool that beckons me to "hack the web".