```yaml
---
slug: sslac
published: 2011-05-03T00:00:00.000Z
description: A JavaScript class library that lets you runtime patch your methods
changelog:
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
  - on: 2020-02-24
    note: You have ES6 Classes. You should certainly be using those now! `Sslac` is also long since retired, though it was in use at LinkedIn for several years because of the need to test fixes and patches for CDN-delivered code on third party sites via the browser console. Ultimately, this was a lot safer than giving the framework a "switch" flag that could retrieve runtime JS from an arbitrary URL.
---
```

The world of JavaScript is rich with ways to bring typical OOP constructs to a highly prototyped language. The world probably doesn't need another library either. Further, it probably doesn't need an entire blog post talking about its features and how it can be used. Nevertheless, the hat is being tossed into the ring. Welcome Sslac, a (somewhat) backward approach to class instantiation in JavaScript.

If you're not keen on the intro documentation, you can [download Sslac from github](https://github.com/jakobo/sslac), view the source, etc. The Short List (features)

- Natural chaining syntax to define an object
- Compatible with `instanceof` operators
- Support for superclass methods
- Change definitions of objects after creation
- Support for namespacing and `noConflict`
- Common JS 1.1 Modules compliant
- Multiple class types (static, instance, and functions)

## A Dual Object Structure

The most important thing to remember in Sslac is that when working from the Sslac chain, you're working on what's internally called the "ObjectRef". This reference isn't the object your code will instantiate, but rather a souped up dictionary with some helpful setters and getters. This syntax allows you to get a method that you've already defined somewhere along the extension chain, and then swap it for something new or patch new code over the old. We'll actually get to that in a bit, but first, the class basics.

For people who have worked with JS class libraries, the syntax should feel familiar. With lowercase versions of the words reserved (static and extends come to mind), Uppercase was used instead. An unexpected benefit of this seems to be that code written is a bit easier to read. For those who have played with Prototype or [Resig's Simple JS Inheritance](https://web.archive.org/web/20110507092802/http://ejohn.org/blog/simple-javascript-inheritance/), the syntax shouldn't feel too unwieldy either.

## Runtime Mixins and Monkeypatching

I hear it's also called "duck punching," which sounds way more cool. One thing Sslac really excels at is the ability to alter code at runtime without modifying the original source code. Much like Prototype's addMethod functionality, these runtime methods cascade into inherited objects. Unlike the other frameworks, however, Sslac provides a set of helper methods to get at the original definitions. To change a method's definition at runtime, you can retrieve the original object's definition, and then swap out a method.

    (this code sample went missing in the many migrations)

In the above, we've enabled the Person object to flip out, and enabled the Ninja object to kill people. Thankfully, only Ninjas (which extend Persons) will be able to [flip out and kill people](https://web.archive.org/web/20110507092802/http://www.realultimatepower.net/index4.htm), but that's the purpose of ninjas anyway. Prototype inheritance means that, by adding the `flipOut` method to Person, Ninja will automatically get it. The Person object's probably feeling left out though. And if it's someone else's Person object, you may not want to re-implement their method entirely. This is where that whole "duck punching" concept comes in.

Using `definitionOf` and `getMethod`, we can retrieve the original implemented method and call it using the old school `apply` method, passing the current object along with the arguments array.

## In the Real World

Perhaps the most compelling real-world use case for Sslac comes from development at LinkedIn. With our current framework deployed on high profile sites, we can take a bug we want to fix, write the patch, and then use a tool like Greasemonkey to add our own custom code on top. Bugs can be verified, partner implementations can be tested to ensure there are no regressions, all without either us or the end user developers having to change production code. This provides an invaluable mechanism, allowing code changes to be verified out in the wild, on live sites, without impacting any end user experience. If nothing else, the monkeypatching alone has made the 2k library (minified, pre gzip) well worth its cost.

[Sslac on Github](https://github.com/jakobo/sslac)


You have ES6 Classes. You should certainly be using those now! `Sslac` is also long since retired, though it was in use at LinkedIn for several years because of the need to test fixes and patches for CDN-delivered code on third party sites via the browser console. Ultimately, this was a lot safer than giving the framework a "switch" flag that could retrieve runtime JS from an arbitrary URL.

Document

This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.

A JavaScript class library that lets you runtime patch your methods

Link

code

Sslac: A Runtime Patchable Class Library

```yaml
---
slug: gulp-and-browserify
published: 2014-07-14T00:00:00.000Z
description: How to use Vinyl after gulp-browserify was blacklisted
changelog:
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

If you've tried [gulp](http://gulpjs.com/), you've probably also tried [browserify](http://browserify.org/). This also means you googled for "gulp browserify" and were led to the `gulp-browserify` plugin on npm. I haven't linked to it because the gulp team has ruled that the `gulp-browserify` plugin is blacklisted due to redundancy. Instead, the current consensus is a [recipe leveraging vinyl](https://github.com/gulpjs/gulp/issues/369), the underlying virtual file system in gulp. While I think that's technically correct, it requires intimate knowledge of browserify, streams, and the vinyl system.

## The Vinyl Code

Let's start with the code and work backwards. First up, the (simplified) recommended solution.

```js
var gulp = require("gulp");
var browserify = require("browserify");
var toVinyl = require("vinyl-source-stream");
gulp.task("js", function () {
  return browserify("file.js")
    .bundle()
    .pipe(toVinyl("bundle.js"))
    .pipe(gulp.dest("output_dir/"));
});
```

This is a very powerful pattern. We're able to leverage the default browserify npm module. [vinyl-source-stream](https://www.npmjs.org/package/vinyl-source-stream) (npm) can take a stream in progress and convert it to a vinyl supported stream, thus giving it a virtual file system and name. By using this, you no longer have to use a special plugin for browserify. However, this solution breaks down if you want to leverage the globbing in gulp.src that makes for powerful pipelines, do additional transformations prior to browserify, or simply work with a npm module that doesn't support streams or buffers. Like all things gulp, there's a plugin for this functionality; it lets us tap into a gulp pipeline, making our own modifications. That plugin is appropriately named [gulp-tap](https://www.npmjs.org/package/gulp-tap). We're going to use `gulp-tap` to get all the globbing power of gulp, but still be able to run browserify on our entries.

## What it Looks Like With gulp-tap

```js
var gulp = require("gulp");
var tap = require("gulp-tap");
var toBuffer = require("gulp-buffer");
var browserify = require("browserify");
gulp.task("js", function () {
  return gulp
    .src("**/*.js")
    .pipe(
      tap(function (file) {
        var bundler = browserify({
          entries: [file.path],
        });
        return bundler.bundle();
      })
    )
    .pipe(toBuffer())
    .pipe("...")
    .pipe(gulp.dest("output_dir/"));
});
```

Okay, we've added a few more lines courtesy of the gulp-tap plugin. However, this is a pattern that goes well beyond browserify. gulp-tap is a swiss army knife in the gulp world. It's purpose is to expose the file in the middle of the pipeline, allowing you to call whatever custom transformations you may need. The signature for the gulp-tap configuration takes two parameters. The first is the `vinyl-fs` file object and contains `file.contents`, `file.path`, etc. The second is an instance of the `through2` module in case you need to use the stream directly.

Return a buffer, return a stream, or modify `file.contents` and you're done. Even operations that don't normally return streams or buffers are automatically moved into a buffer for compatibility with the next step on the gulp pipeline.
As a caveat, it should be noted that since you are leaving the stream/buffer world during your gulp-tap operation, it will be slower than if you had a pure stream based solution. However, the leverage you gain for this strategy is high. Every npm module can be part of your gulp system now.

## gulp-buffer and gulp-stream

Not all gulp plugins are stream or buffer ready. Because of their design, they might be operating on one or the other. This is most common with plugins that are calling out to external commands or require the evaluation of the entire file in order to perform a task. gulp allows these utilities to decline handling streams by throwing an exception. Enter [gulp-buffer](https://www.npmjs.org/package/gulp-buffer) and [gulp-stream](https://www.npmjs.org/package/gulp-stream), taking in either buffers or streams and returning a buffer or stream for the next step of the pipeline.

In our above code, browserify provides a stream, but uglify only operates on a buffer. Piping through gulp-buffer solves this problem.

## Doing it Gulp's Way

The most successful gulp pipelines are those built with small modular components. Per the gulp team's recommendation, plugins shouldn't be created when there is already a npm module that accomplishes your goal. Thanks to utilities like vinyl-source-stream, gulp-tap, gulp-buffer, and gulp-stream, you can make the entire npm ecosystem gulp friendly. You really don't need to write a gulp plugin for most use cases, and that's serious leverage.


How to use Vinyl after gulp-browserify was blacklisted

var gulp = require("gulp");
var browserify = require("browserify");
var toVinyl = require("vinyl-source-stream");
gulp.task("js", function () {
  return browserify("file.js")
    .bundle()
    .pipe(toVinyl("bundle.js"))
    .pipe(gulp.dest("output_dir/"));
});


Fence

Gulp and Browserify

```yaml
---
slug: data-liberation-for-linkedin
published: 2015-03-15T00:00:00.000Z
description: Free your data
changelog:
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

Hackdays at LinkedIn are special. People get to try new ideas and technologies. I personally enjoy seeing if I can push people's buttons and make them think, so I am a sucker for the "most controversial" category we always do. In 2012, [UnLinked](http://jakobo.github.com/UnLinked/) ([github](http://jakobo.github.com/UnLinked/)) was lucky enough win one of the categories. It may end up on LinkedIn Labs eventually, but that's not really the point of this post. This post is all about how easy it is to export your LinkedIn data using the JavaScript APIs as part of the LinkedIn Platform. If you want to run your own local copy of UnLinked, just fork the github project above. Special thanks to my collaborator on this Hackday project [Efrat Orkin](http://www.coroflot.com/efratorkin) who's design ability put incredible personality and purpose into the project . This is the Hackday project, broken down from idea to its final forms.

![An image of the UnLinked project, showing an obvious like to download your data in an easy to use JSON format](https://user-images.githubusercontent.com/1795/146730319-a01f9b8d-7017-4d17-9589-b6e235eabf03.png)

## Free Your Data

I'm a huge fan of the [Data Liberation Front](http://www.dataliberation.org/), a group within Google that obsesses over freeing the data. If you ever want to know how to export/access your data from Google's data centers, this single site details everything. The goals are simple; you want to create

1. a way to export your data in an open, interoperable format…
2. that shouldn't cost the user anything…
3. and take as little time as possible

This is a pretty strong edict. Any company with APIs should be able to do this; LinkedIn is no exception. The [LinkedIn Developer Site](https://developer.linkedin.com/) documents the APIs we have available. During brainstorming, I wanted an application that makes it one-click-simple to get your profile information and download it. Docs in hand, it was time to create a "Sign in With LinkedIn" button and start accessing data.

## Building UnLinked

UnLinked itself consists of a single HTML page. Everything we did was built on the LinkedIn JavaScript APIs. That is: request access, make N calls to the API to get all the required data, and bundle the whole thing up into a JSON format. To help the application feel fast, we broke all the calls up into smaller chunks using LinkedIn's `API.Raw()` call. The results are then mashed together in the final payload. When we've got all the parts, we can do the download. For the GitHub version, a client side result is displayed. It's also possible to use the simple PHP script to trigger a download of the JSON data. The total engineering took about 3 hours from no API key to completion and completed debugging.

One of the more interesting things done in the application is the liberal use of the `.Raw()` API call. While there are shortcut methods to get various data components, `Raw` affords us several advantages. First, you don't have to accept the defaults. Since this application is designed to grab as much data as possible, it needed to ask for more than just the default commonly used fields. Second, as the number of URLs grows, it becomes very easy to change the data structure to allow an unlimited number of attributes to be retrieved, without adding much additional code. Finally, some endpoints just don't have convenience methods build in yet. For those items, we needed some way to get at the data- the original purpose `Raw` was built. Since our URLs don't change in the v1 API, this is a pretty stable solution that also affords us the power we're looking for.

## The Result

Counting the styling and graphics creation, Efrat and I spent about 10–12 hours total, which was less than a day's work for us combined. The JavaScript APIs for LinkedIn are very powerful, and the more we move as a Web to client side solutions, the more likely JavaScript APIs will move from away from their Hackday status and become part of client side models in MVC architectures.


Data Liberation for LinkedIn

```yaml
---
slug: line-numbers-in-eval
published: 2015-03-16T00:00:00.000Z
description: You should never do this. But "never" is a bit too absolute for engineering
changelog:
  - on: 2017-10-01
    note: Better alternatives than `eval` finally exist with `await import()` syntax. You should definitely explore those. Additionally, LinkedIn has sunset [Inject](https://github.com/linkedin/inject) on their production site now that many viable alternatives exist. Hoo-ray modern web development!
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

When it comes to executing code, `eval()` is a [terrible idea](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval). However, somewhere in your coding career, you will need to evaluate code.

And unfortunately, if there's an error in the code, any line numbers are going to point to the invocation of `eval()` and not the erroring line within the body itself. Lucky for us, `<script>` tags correctly report erroring lines with line numbers.

Before we go any further, this is an obligatory **don't use eval**. It should be an option of last resort. Your Content Security Policy is hopefully already preventing you from doing this.

## Trying to not Evaluate: `.innerHTML` or `.text`

The first attempt was to set `innerHTML` to your JavaScript, and then place that node onto the page via `appendChild`. If you are only concerned with modern non-Microsoft browsers, you'd be done at this point.

```js
// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
function createScriptNode(code) {
  var scr = document.createElement("script");
  scr.type = "text/javascript";
  scr.innerHTML = code;
  return scr;
}
```

Internet Explorer won't execute the JavaScript inside of this script tag, even though the `innerHTML` property is set. However, it uniquely [supports the "text" property](http://msdn.microsoft.com/en-us/library/ie/ms535892(v=vs.85).aspx), which no other browsers seem to support. When set, scripts in IE will execute once appended to the DOM. A few changes to our above script, and we have a "safe" method. Borrowing from the idea of [feature testing for things only IE supports](./enhancing-for-bugs), we'll actually feature test against this text property, falling back to alternate versions as needed.

```js
// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
function createScriptNode(code) {
  var scr = document.createElement("script");
  scr.type = "text/javascript";
  try {
    scr.text = code;
  } catch (e) {
    try {
      scr.innerHTML = code;
    } catch (ee) {
      return false;
    }
  }
  return scr;
}

```

## Tying it Together

Further optimizations can be used to pre-select the best insertion method. In [inject](https://github.com/linkedin/inject/blob/68c343180ed3a08dffb0ad445fe45d70908683e1/src/executor.js#L129), we wrap the code we want to execute within a function declaration and assignment. This enables us to store the results of the `eval` so that modules can then be executed on demand. The below example is just a simple JSON evaluator as a proof of concept. Like all things `eval`, you should always be cautious with invoking it on items that are not 100% in your control.

```js
// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
var createScriptNode = (function () {
  var testScr = document.createElement("script"),
    property = "innerHTML";
  testScr.type = "text/javascript";
  try {
    testScr.text = ";";
    property = "text";
  } catch (e) {}
  return function (code) {
    var scr = document.createElement("script");
    scr.type = "text/javascript";
    scr[property] = code;
    return scr;
  };
})();

var evalJSON = function (jsonString) {
  var exec = ["window.results =", jsonString],
    node = createScriptNode(exec),
    results;
  document.body.appendChild(node);
  results = window.results;
  delete window["results"];
  return results;
};
```

While this code definitely makes it possible to do more harm than good (we're stepping around JSLint/Hint `eval` checks), the upside is huge when you're evaluating code and need to understand at what line something is failing on. In the case of a module loading system, having both the upsides of a lazy `eval` and the  embedded script tag is a huge win.


Better alternatives than `eval` finally exist with `await import()` syntax. You should definitely explore those. Additionally, LinkedIn has sunset [Inject](https://github.com/linkedin/inject) on their production site now that many viable alternatives exist. Hoo-ray modern web development!

You should never do this. But "never" is a bit too absolute for engineering

strong

// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
function createScriptNode(code) {
  var scr = document.createElement("script");
  scr.type = "text/javascript";
  scr.innerHTML = code;
  return scr;
}


// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
function createScriptNode(code) {
  var scr = document.createElement("script");
  scr.type = "text/javascript";
  try {
    scr.text = code;
  } catch (e) {
    try {
      scr.innerHTML = code;
    } catch (ee) {
      return false;
    }
  }
  return scr;
}



// ⚠️ Obligatory THIS IS EVAL DO NOT DO THIS
var createScriptNode = (function () {
  var testScr = document.createElement("script"),
    property = "innerHTML";
  testScr.type = "text/javascript";
  try {
    testScr.text = ";";
    property = "text";
  } catch (e) {}
  return function (code) {
    var scr = document.createElement("script");
    scr.type = "text/javascript";
    scr[property] = code;
    return scr;
  };
})();

var evalJSON = function (jsonString) {
  var exec = ["window.results =", jsonString],
    node = createScriptNode(exec),
    results;
  document.body.appendChild(node);
  results = window.results;
  delete window["results"];
  return results;
};


Line Numbers in eval

```yaml
---
slug: enhancing-for-bugs
published: 2015-03-14T00:00:00.000Z
description: Sometimes, instead of feature detection, you can get away with "bug detection"
changelog:
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

In the days of Internet Explorer 6, it was common to lament the problems of the browser nobody wanted to support. Some of the bugs that developers have uncovered are well documented, some of them not. This falls more into the later camp. It's fix, while trivial, serves as a great reminder about how to build software that works in every browser.

Let's get the basics out of the way first. In every browser on the planet (except IE6), it is possible to create a checkbox in IE6 that is by default selected using everyday JavaScript.

```js
var cb = document.createElement("input");
cb.type = "checkbox";
cb.checked = true;
```

A simple checkbox
The above code would render the checkbox once you append the checkbox to the DOM, but no matter how one tries, the box won't actually start in the checked state. While it's technically possible to [sniff IE6 using conditional comments](http://dean.edwards.name/weblog/2006/11/sandbox/) and react accordingly, trying to detect a browser based on its signature will always be a poor choice and a last resort.

Internet Explorer's documentation on `document.createElement` shows that before IE9, it was possible to render an element using the angle brackets, `<` and `>` respectively. When rendering out an entire tag with angle brackets, IE6 properly sets the "checked" property. Since standards compliant browsers don't allow angle brackets, we can start with a non-standard solution, falling back to the W3C method on failure.

```js
// IE6 requires a checkbox to be made differently
try {
  var cb = document.createElement('<input type="checkbox" checked>');
} catch (e) {
  var cb = document.createElement("input");
  cb.type = "checkbox";
  cb.checked = true;
}
```

By applying the philosophy of feature detection to something that is (by all accounts) a bug, we can keep true to our development principals in the browser.


Sometimes, instead of feature detection, you can get away with "bug detection"

var cb = document.createElement("input");
cb.type = "checkbox";
cb.checked = true;


// IE6 requires a checkbox to be made differently
try {
  var cb = document.createElement('<input type="checkbox" checked>');
} catch (e) {
  var cb = document.createElement("input");
  cb.type = "checkbox";
  cb.checked = true;
}


Enhancing for Bugs

```yaml
---
slug: fake-germanizer
published: 2008-11-13T00:00:00.000Z
description: Long words can make short work of your design
changelog:
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

I ran into a problem where I needed to guess how something would look in German, without knowing a single drop of German. So, I pulled up Mozilla's XPath documents and made a small bookmarklet. It's far from perfect, but it definitely has its uses when you're trying to estimate how items will look before they reach a translation team... even if the first use was messing with my Twitter feed.

[Fauxgermanhausen das Pagen! (bookmarklet)](javascript:%28function%28%29%7Bvar%20prefixes%3D%5B%27%27%2C%27glocken%27%2C%27das%27%2C%27borfa%27%2C%27maushe%27%2C%27uber%27%5D%2Csuffixes%3D%5B%27%27%2C%27hausen%27%2C%27%20die%20vander%27%2C%27gleuten%27%2C%27noshan%27%2C%27flagellan%27%2C%27mek%27%2C%27dak%27%2C%27en%20das%27%2C%27ga%27%5D%2CxPathResult%3Ddocument.evaluate%28%27.//text%28%29%5Bnormalize-space%28.%29%21%3D%27%27%5D%27%2Cdocument.body%2Cnull%2CXPathResult.ORDERED_NODE_SNAPSHOT_TYPE%2Cnull%29%2Ci%2CtextNode%2Ccnt%2Cout%2Cj%2Cpfx%2Csfx%3Bfor%28i%3D0%2Cl%3DxPathResult.snapshotLength%3Bi%3Cl%3Bi++%29%7BtextNode%3DxPathResult.snapshotItem%28i%29%3Bif%28textNode.parentNode.nodeName.toLowerCase%28%29%3D%3D%27script%27%7C%7CtextNode.tagName%3D%3D%27style%27%29continue%3Bcnt%3DtextNode.data.split%28/s/g%29%3Bout%3D%5B%5D%3Bfor%28j%3D0%3Bj%3Ccnt.length%3Bj++%29%7Bif%28cnt%5Bj%5D.replace%28/%5Bs%5D/g%2C%27%27%29%3D%3D%27%27%29continue%3Bpfx%3D%28%21Math.floor%28Math.random%28%29*10%29%29%3F%27%27%3Aprefixes%5BMath.floor%28Math.random%28%29*prefixes.length%29%5D%3Bsfx%3D%28%21Math.floor%28Math.random%28%29*10%29%29%3F%27%27%3Asuffixes%5BMath.floor%28Math.random%28%29*suffixes.length%29%5D%3Bout.push%28pfx+cnt%5Bj%5D+sfx%29%3B%7DtextNode.data%3D%27%20%27+out.join%28%27%20%27%29+%27%20%27%3B%7D%7D%29%28%29%3B)

```js
    (function () {
      var prefixes = ["", "glocken", "das", "borfa", "maushe", "uber"],
        suffixes = [
          "",
          "hausen",
          " die vander",
          "gleuten",
          "noshan",
          "flagellan",
          "mek",
          "dak",
          "en das",
          "ga",
        ],
        xPathResult = document.evaluate(
          ".//text()[normalize-space(.)!='']",
          document.body,
          null,
          XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
          null
        ),
        i,
        textNode,
        cnt,
        out,
        j,
        pfx,
        sfx;
      for (i = 0, l = xPathResult.snapshotLength; i < l; i++) {
        textNode = xPathResult.snapshotItem(i);
        if (
          textNode.parentNode.nodeName.toLowerCase() == "script" ||
          textNode.tagName == "style"
        )
          continue;
        cnt = textNode.data.split(/\s/g);
        out = [];
        for (j = 0; j < cnt.length; j++) {
          if (cnt[j].replace(/[\s]/g, "") == "") continue;
          pfx = !Math.floor(Math.random() * 10)
            ? ""
            : prefixes[Math.floor(Math.random() * prefixes.length)];
          sfx = !Math.floor(Math.random() * 10)
            ? ""
            : suffixes[Math.floor(Math.random() * suffixes.length)];
          out.push(pfx + cnt[j] + sfx);
        }
        textNode.data = " " + out.join(" ") + " ";
      }
    })();
```

Long words can make short work of your design

Fake Germanizer

```yaml
---
# This frontmatter will be used by CodeDrift
slug: reparenting-iframes
published: 2015-03-17T00:00:00.000Z
description: How to change an iframe parent node without a reload
changelog:
  - on: 2017-10-04
    note: It's been noted in [comments](https://medium.com/@mbogdan/even-in-webkit-support-for-the-so-called-magic-iframe-has-been-removed-882a27d1bf15) and confirmed that the reparenting with `adoptNode()` no longer works and will instead cause the iframe to reload. Based on the [bug report](https://bugs.webkit.org/show_bug.cgi?id=13574), we're also not likely to see this situation change either. So until the situation changes, the answer is "no, you can't call `adoptNode()` without the iframe reloading. You will likely need to get clever with positioning items absolutely.
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

If you're playing around with iframes, there's a nasty bug that occurs when you attempt to move the iframe using methods such as `appendChild` or `insertBefore`. How nasty the bug is depends on how tolerant your code is of reloading behaviors. Any attempts to move the iframe around will cause reloads in older Safari & Firefox versions. The problem lies in how the browsers interpret these events, removing the node and then adding it to its new destination which triggers a reload. If you're trying to move iframes around on the page with something like a drag and drop interface, this rears its ugly head. Strangely enough, IE doesn't exhibit this behavior, which leaves the problem to just Webkit and Firefox.

## Workarounds in CSS

A quick search reveals only one consistent technique for moving iframes about on the page using CSS- positioning absolutely. An absolutely positioned iframe can be readjusted easily, and can track directly on top of a placeholder such as a div. This works pretty fantastically in all but the most complex of layouts where absolute positioning requires a relative parent in just the right place.

```html
<body>
  <div id="#placeholder"></div>
  
  <iframe id="theFrame" src="http://www.example.com" style="left: -12345px; top: 0; position: absolute;"></iframe>
</body>
```

```js
(function () {
  var div = document.getElementById("placeholder");
  var iframe = document.getElementById("theFrame");

  window.setInterval(function putFrameOntoPlaceholder() {
    // 1) measure the size of the iframe, change size of div
    div.width = iframe.offsetWidth + "px";
    div.height = iframe.offsetHeight + "px";

    // 2) get the div's position on the page, position iframe
    iframe.left = div.offsetLeft + "px";
    iframe.top = div.offsetHeight + "px";
  }, 100);
})();
```

In layouts that make heavy use of relative positioning, it's easy to see where this might run into snags. Styles on either the div or iframe could mess up the alignment a bit, and while it's correctable it's not very feasible for a large scale site where there's going to be several developers building code.

## Webkit & Gmail: Adopting Nodes

In July 2010, Google silently released an improvement to Gmail. It was most noticeable when using the gmail chat feature. You could open the chat window, "pop" it out of the main window, and then *close the parent window* and everything continued to work. The most fascinating part about this was the minimal load time in the popup. It was as if the entire Gmail environment were being ported over to the popup as part of the unload events. That's exactly what's happening. **The iframe contained the code both the main page and popup needed.**[The initial webkit bug on reparenting iframes](https://bugs.webkit.org/show_bug.cgi?id=32848) became the ideal fix.

This worked thanks to the [DOM Level 3](http://www.w3.org/TR/DOM-Level-3-Core/core.html) core; a new DOM manipulation method was added called `adoptNode`. Adopting an HTML node would simply move the node and in the case of the iframe, would not trigger a reload of the content. Coming back to Gmail, the JavaScript needed for the popup window is loaded into an iframe. When the parent window is closed, `adoptNode` is called, moving all of the necessary code into the popup window before itself closing.

## And Firefox? Opera? Other Browsers?

Unfortunately, as of this writing, Firefox still has [an open ticket on the [broken adoptNode behavior](https://bugzilla.mozilla.org/show_bug.cgi?id=254144), with no fixes in sight. As a last ditch effort, we can fall back to `importNode`, we will just take the performance hit and trigger an undesirable reload which can possibly erase state within the iframe if there is any.

This stuff hasn't been validated against Opera. Since Opera is based on webkit, it shouldn't be exhibiting this bug.

## Falling Back

Using the below code, it's possible to use `adoptNode` when it's available, and then fall back to the `importNode` as a last resort. Depending on the browser, you may still reload the sub-document. Should the `adoptNode` bug ever get fixed, you'll get a large performance boost in iframes and popups.

```js
try {
  document.adoptNode(window.opener.$("#my-iframe"));
} catch (exc) {
  // performance hit. Either importNode, or load the
  // frame contents with appendChild()
  // remember you'll also need state somewhere
  // in window.opener
  document.importNode(window.opener.$("#my-iframe"));
}
```

It's been noted in [comments](https://medium.com/@mbogdan/even-in-webkit-support-for-the-so-called-magic-iframe-has-been-removed-882a27d1bf15) and confirmed that the reparenting with `adoptNode()` no longer works and will instead cause the iframe to reload. Based on the [bug report](https://bugs.webkit.org/show_bug.cgi?id=13574), we're also not likely to see this situation change either. So until the situation changes, the answer is "no, you can't call `adoptNode()` without the iframe reloading. You will likely need to get clever with positioning items absolutely.

How to change an iframe parent node without a reload

(function () {
  var div = document.getElementById("placeholder");
  var iframe = document.getElementById("theFrame");

  window.setInterval(function putFrameOntoPlaceholder() {
    // 1) measure the size of the iframe, change size of div
    div.width = iframe.offsetWidth + "px";
    div.height = iframe.offsetHeight + "px";

    // 2) get the div's position on the page, position iframe
    iframe.left = div.offsetLeft + "px";
    iframe.top = div.offsetHeight + "px";
  }, 100);
})();


try {
  document.adoptNode(window.opener.$("#my-iframe"));
} catch (exc) {
  // performance hit. Either importNode, or load the
  // frame contents with appendChild()
  // remember you'll also need state somewhere
  // in window.opener
  document.importNode(window.opener.$("#my-iframe"));
}


Reparenting iframes

```yaml
---
slug: window-postmessage-and-ie
published: 2015-03-14T00:00:00.000Z
description: Limitations on a crucial cross-origin API
changelog:
  - on: 2016-01-12
    note: IE 9 Support has **ended**. That means we can finally just use `window.postMessage` the way it was intended. You can safely discard 99% of this now!
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

It started out innocently enough: the LinkedIn Platform needed to run our Professional Plugins on third party sites. To do the basic process of resizing iframes (to fit our plugins), we needed a way to talk across domains. With HTML5, we gained access to `postMessage`, which was a nice standard way of talking between domains. For the browsers such as IE6 and IE7, libraries such as [Apache Shindig](http://shindig.apache.org/) and [easyXDM](http://easyxdm.net/) have found a way to use Visual Basic objects (and later Flash) to coerce older browsers into supporting a compatible interface. Internet Explorer 8 and 9, however, have a set of quirks in its `window.postMessage` which will frustrate users of home-grown solutions and libraries alike. Inevitably, another developer is going to run into these problems.

## Internet Explorer Recasting Things to "Object"

If you're using popup windows alongside a cross domain library, you'll probably be calling methods in `window.opener` to avoid having to create multiple listeners for the postMessage object. While this nuance isn't postMessage specific, if you're using an RPC implementation in a library, you can expect your `success()` and `error()` methods to get mangled.

```js
// child window
function childFunction() {}
window.opener.parentFunction(childFunction);

// parent window
function parentFunction(f) {
  alert(typeof f); // object
}
```

To get around this, you can either serialize the function using or make sure that `parentFunction` doesn't depend on a `typeof` check. Even though in the parent window it looks like an object, it will still begin with "function" when serialized. As an added check, you can verify the existence of `call()` and `apply()` before treating it like a callable object. On some level, what Internet Explorer is doing is correct, as Functions are Objects just like everything else. Since the Parent and Child window both have different window objects, their Function objects would also be different, because reasons.

```js
// Oh IE...
window.opener.Function === Function; // false
```

As of Internet Explorer 9, the typeof operator properly displays the object as Function, implying it's callable. Therefore, the fix can be localized to IE 6/7/8 using a conditional comment in JavaScript.

## No Communication Across Popup Windows

If you're adventurous and forgo a library for cross domain communication, do not expect it to talk to popup windows in Internet Explorer 8. The worst part about this is that it's a [known bug in postMessage](http://blogs.msdn.com/ieinternals/archive/2009/09/16/Bugs-in-IE8-support-for-HTML5-postMessage-sessionStorage-and-localStorage.aspx) for which the current solution is to make an iframe, for which you can then hand off the `window.opener` assignment. There are two problems with this approach. In order to reach our opener, the popup window and iframe will need to be on the same domain or set their `document.domain` property. The second problem is a bit more vexing, as reaching through `window.opener` triggers the first bug mentioned above. The workarounds are still usable, but if you're passing anything more complex than a primitive such as a string between windows, you're sunk.

To be safe, it's worth wrapping the things in postMessage as a string using JSON. If you need to persist objects between windows, giving objects a way to instantiate on the other side is really the only option.

## Origin Mismatching

The rules for postMessage security are pretty straightforward. When calls are made, the origin is derived from the window object used to initiate the postMessage call. The below code highlights the IE8 inconsistency. For whatever reason, reaching through `window.opener` again causes issues, and the domain is changed to the initial script entry point into postMessage versus the page where the code actually resides.

```js
// popup window (popup.example.com)
document.domain = "example.com";
window.opener.postMessageInterface("string");

// window that opened the popup (iframe.example.com)
// just contains normal postMessage()
document.domain = "example.com";
function postMessageInterface(str) {
  window.top.postMessage(str);
}

// On the ultimate listening page, IE8 identifies the origin
// as where the call stack began. Other browsers all identify
// the origin as the domain from which the .postMessage() call
// was made
window.addEventListener(
  "message",
  function receive(evt) {
    // IE 8
    alert(evt.origin); // popup.example.com

    // Every Other Browser
    alert(evt.origin); // iframe.example.com
  },
  false
);
```

The workaround for this is that we can use `setTimeout`. By putting the intent to call postMessage back on the stack, we are able to resolve it with the correct origin.

```js
function postMessageInterface(str) {
  window.setTimeout(function () {
    window.top.postMessage(str);
  }, 0);
}
```

The need to make use of this workaround is even more important if you're using `document.domain` due to a CDN. Even though it's been set in the example, the values are ignored for `postMessage` on IE (even though those exact same rules allowed `window.opener` to be reached in the first place).

## Just Use easyXDM

This is a long post for saying [easyXDM](http://easyxdm.net/) has already solved these problems if you need to support IE 8 and IE 9. We're actively working towards a world where you won't need the library. But if you do, it's there.


IE 9 Support has **ended**. That means we can finally just use `window.postMessage` the way it was intended. You can safely discard 99% of this now!

Limitations on a crucial cross-origin API

// child window
function childFunction() {}
window.opener.parentFunction(childFunction);

// parent window
function parentFunction(f) {
  alert(typeof f); // object
}


// Oh IE...
window.opener.Function === Function; // false


// popup window (popup.example.com)
document.domain = "example.com";
window.opener.postMessageInterface("string");

// window that opened the popup (iframe.example.com)
// just contains normal postMessage()
document.domain = "example.com";
function postMessageInterface(str) {
  window.top.postMessage(str);
}

// On the ultimate listening page, IE8 identifies the origin
// as where the call stack began. Other browsers all identify
// the origin as the domain from which the .postMessage() call
// was made
window.addEventListener(
  "message",
  function receive(evt) {
    // IE 8
    alert(evt.origin); // popup.example.com

    // Every Other Browser
    alert(evt.origin); // iframe.example.com
  },
  false
);


function postMessageInterface(str) {
  window.setTimeout(function () {
    window.top.postMessage(str);
  }, 0);
}


window.postMessage and Internet Explorer

Posts while we built the world's largest professional network