Welcome to part 26 of Let's Make a Framework, the ongoing series about
I received some feedback last week about Turing -- very useful and
interesting points that I thought followers of the series would enjoy.
Øyvind Sean Kinsey commented on one of
my commits to say that he thought the way Turing creates a global alias
was unnecessary. My code looked like this:
eval(turing.alias + ' = turing.aliasFramework()');
The reason I did this was so
turing.alias would expand to
the variable name. This was so people using Turing could alias it to a
short name, like jQuery's
turing.core stores a reference to the global context, which
window. As I like to write unit tests outside
a browser I pass in an object rather than relying on
window. Because the old version of
didn't expose this global, I used
eval to create a similar
Taking on board Øyvind's feedback, I've added a method called
exportAlias to the core library, and changed
A lot of libraries and frameworks set properties on
in a similar way.
After all the work I put into creating a DOM ready implementation, it
wasn't really required! It's possible to insert
tags at the end of a document to get a similar effect -- this is
actually recommended for performance reasons by people like Yahoo! and
Arnout Kazemier let me know that all my
hard work and the source of my steadily worsening RSI was worthless, so
In all seriousness, it's useful to be aware of this alternative. Arnout
even provided an example that clearly backs up the performance claims:
Here's a good example of blocking rendering with a script. The script in the head takes 3 seconds to load and 1 second to execute. You will see a white page for 4 seconds because it blocks the rendering of the page because it's loaded in the head. And the browser can't continue because the contents might affect how the rest of page needs to be rendered.
I enjoyed the simplicity of this approach versus dozens of lines of
to know when frameworks are doing a lot of heavy lifting for features
that aren't always required.