Bookmarklets

Someone at Clearleft asked me a question recently about making bookmarklets. I have a bit of experience in that department. As well as making a bookmarklet for adding links to my own site, there’s the Huffduffer bookmarklet that’s been chugging away since 2008.

I told them that there are basically two approaches:

  1. Have the bookmarklet pop open a new browser window at your service, passing in the URL of the current page. Then do all the heavy lifting on your server.
  2. Have the bookmarklet inject JavaScript to analyse and edit the DOM of the document in the current browser window. All the heavy lifting is done directly in client-side JavaScript.

I favour the first approach. Partly that’s because it makes it easier to update the functionality. As you improve your server-side script, the bookmarklet functionality gets better automatically. But also, if your server-side script doesn’t do its magic, you can always fall back to letting the end user fill in the details.

Here’s an example…

When you click the Huffduffer bookmarklet, it pops open this URL:

https://huffduffer.com/add?page=…

…with that page parameter filled in with whatever page you currently have open. Let’s say I’ve got this page currently open in my browser:

https://adactio.com/journal/6786

If I press the Huffduffer bookmarklet, that will spawn a new window with this URL:

https://huffduffer.com/add?page=https://adactio.com/journal/6786

And that’s all it does. Now it’s up to that page on Huffduffer to figure out what to do with the URL it has been given. In this case, it makes a CURL request to figure out what to use as a title, what to use as a description, what audio file to use, etc. If it can’t figure that out, I can always fill in those fields myself by hand.

I could’ve chosen to get at that information by injecting JavaScript directly into the page open in the browser. But that’s somewhat invasive.

Brian Donohue wrote on Ev’s blog a while back about one of the problems with that approach. Sites that—quite correctly—have a strict Content Security Policy will object to having arbitrary JavaScript injected into their documents.

But remember this only applies to some bookmarklets. If a bookmarklet just spawns a new window—like Huffduffer’s—then there’s no problem. That approach to bookmarklets was dismissed with this justification:

The crux of the issue for bookmarklets is that web authors can control the origin of the JavaScript, network calls, and CSS, all of which are necessary for any non-trivial bookmarklet.

Citation needed. I submit that Huffduffer and Instapaper provide very similar services: “listen later” and “read later”. Both use cases could be described as “non-trivial”. But only one of the bookmarklets works on sites with strict CSPs.

Time and time again, I see over-engineered technical solutions that are built with the justification that “this problem is very complex therefore the solution needs to be complex” (yes, I am talking about web thangs that rely on complex JavaScript). In my experience, it’s exactly the opposite way around. The more complex the problem, the more important it is to solve it in the simplest way possible. It’s the only way of making sure the solution is resilient to unexpected scenarios.

The situation with bookmarklets is a perfect example. It’s not just an issue with strict Content Security Policies either. I’ve seen JavaScript-injecting bookmarklets fail because someone has set their browser cookie preferences to only accept cookies from the originating server.

Bookmarklets are not dead. They may, however, be pining for the fjords. Nobody has a figured out a way to get bookmarklets to work on mobile. Now that might well be a death sentence.

Have you published a response to this? :

Responses

Kevin Marks

They do work on chrome on android, but you have to type them in the address bar and rely on autocomplete to find them.

Jason Garber

Jeremy throws cold water on Brian’s bookmarklet article I linked to yesterday.

Bookmarklets are not dead. They may, however, be pining for the fjords.

Like Jeremy, I have a simple bookmarklet for saving links to my own site. My bookmarklet opens a new window/tab, passing via URL parameters the URL and title of the current window/tab to a page on my site. If I’ve highlighted some text in the page, the bookmarklet will grab that and insert it into the body field on my link form, prepended with a > (the Markdown syntax for a <blockquote>).

Easy peasy.

Not-so-humorously, that last piece doesn’t work on overly clever sites like Medium that monkey about with browser-native user interface. Neutral face emoji.

Visit “Adactio: Journal—Bookmarklets” →

cdevroe.com

Becoming cameras March 22nd, 2016 Matt Hackett, CTO/Co-founder of Beme, on Ev’s blog*: We are approaching a world in which visual and auditory presence at a distance—seeing as another, instantly—is not a rare luxury good, but a basic assumption of society and industry. The superpower of unbounded remote vision is becoming mundane. Periscope, Beme, YouTube, SnapChat. These services were not on my phone 1 year ago. Now I use them every single day. We live in a world where we can be, see, and hear anywhere we want in the world at any time. As Matt put it, we are becoming cameras. Click through to read the entire piece. *totally stolen from Jeremy Keith. #matt hackett

# Wednesday, June 1st, 2016 at 1:13pm

Chris Aldrich

Jeremy, it’s not exactly a mobile bookmarklet, but perhaps you can co-opt the sharing function on mobile with something like URL Forwarder in the Google Play store the way I did for mobile use with Known [http://stream.boffosocko.com/2016/sharing-from-the-indieweb-on-mobile-android-with-apps-and ]? It’ll let you strip out a URL and other data to share to Huffduffer or other apps. It’s also available on GitHub [https://github.com/daverix/urlforwarder ] if you want to roll your own.