Skip to main content

Please Post A Test Case

I spend a lot of time writing little scraps of HTML, JavaScript, and CSS to demonstrate a technique or prove/disprove the existence of a bug. It is a royal pain to do that in a classic web page development process and make them available to the world, because it involves creating a file that is 80 percent boilerplate, adding my own code, coming up with a unique name, and dropping it in some place on a web site that I control. Ugh, so tedious.

Fortunately there already is a way to publish these working code snippets, similar to the ease of creating a blogging platform. Type some code into a box and let someone else take care of the boilerplate. For code samples you can choose from jsFiddle.net and jsbin.com. If all you need is some CSS/HTML hacking area there is also cssdesk.com, but I'll focus on two scripting-capable solutions here.

Both jsFiddle and jsbin do basically the same thing, but use different interfaces. It's mainly a matter of preference as to which one you like and use. With either, you can:
  • Choose an appropriate boilerplate for your code, including external JavaScript or CSS if needed.
  • Edit the script, HTML, and CSS for the sample code.
  • Easily change the boilerplate (for example, change jQuery versions) without editing your sample code.
  • See the live results, either in a sub-window or a full browser window.
  • Save multiple versions of the example, and go back to any previous version.
  • Share versions with other people, and allow them to create their own variations.

Just like blogging revolutionized web authorship, these sites are an incredibly powerful way to share and create code. Rather than copy/paste sample code fragments into an email and trust the person on the other end to understand the context, you can give them a completely working example with almost no additional effort. It's great for teaching as well. The HighCharts charting package has based their API documentation on jsFiddle, for example, so you can run and change the live code in their examples.

You can even embed a working code sample into another web page! The information is read-only while embedded here, but click the plus-sign to be taken to the jsFiddle web site where you can tweak to your heart's content!




Comments

hallvors said…
Consider fixing the links to the three sites you mention :)

Popular posts from this blog

Tragedy of the WebKit Commons

With Opera announcing that their future products will be based on WebKit, the Internet is abuzz with discussion about what that means and whether it's a good thing. Looking at it as a jQuery developer, it's a good thing if it gets WebKit participants to fix bugs and update older implementations. I can't be optimistic without some evidence that things are really going to change.

We don't know how many of Opera's core developers will move to WebKit development, but the press release isn't encouraging: "The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions." I suspect they want some cost savings by eliminating Presto technical staff, or -- in the most optimistic case for their employees -- refocusing existing staff on the parts outside WebKit core that make browsers different.

Opera did land their first WebKit patch so they wanted to make a statement that they weren't getting out o…

Please Stop the jsPerf.com Abuse!

According to many of the tests on jsperf.com, jQuery is slow. Really slow. The jQuery team gets bug reports from web citizens who've discovered these egregious flaws via jsperf and want them fixed. Now, jsperf.com can be a great tool when used knowledgeably, but its results can also be misinterpreted and abused. For example:

Why doesn't jQuery use DOM classList for methods like .addClass()?

There are at least three good reasons.
It doesn't make any practical performance difference given its frequency of use.It complicates code paths, since classList isn't supported everywhere.It makes jQuery bigger, which makes it load slower for everyone, every time.But this jsperf shows classList is much faster! How can you say that?

Well it's possible that test is running afoul of microbenchmark issues, and not measuring what it is supposed to measure due to the increased sophistication of today's JavaScript compilers. This is a big problem with a lot of the jsperf tests out …

You Might Not Need Babel

Babel is great, and by all means use it if it makes it easier to develop your application.

If you're developing a library on the other hand, please take a moment to consider whether you actually need Babel. Maybe you can write a few more lines of utility code and forego the need to pre-process. If you're only targeting some platforms, you may not need anything more than plain old ES6.

At the very least, make sure you know what Babel is doing for you, and what it's not. Some developers believe that Babel is protecting us from a great demon of code complexity when, in truth, browsers and node are pretty easy to deal with on their own. Let's take a look at some of the strategies for not needing Babel.

ES5 is pretty okay: In the days when we used tables for layout and the debugger was named alert(), we would have been so grateful if JavaScript had the features that ES5 has today. If you truly need Babel you are not only a weak programmer, but also an ingrate. Face it, you …