jQuery data and JSON

jquery_logojQuery is picky about the JSON that is read from in HTML5 data elements. Of course, it’s not really jQuery that’s at fault, it’s simply that the JSON spec is a lot more strict than simple javascript.

In javascript, I can define an object like this:

var object = { look: "ma", no: "quotes" };

Note the lack of quotes on the key names in the object.

Since JSON is a data exchange specification, it requires quoted keys.

So, if you want to put JSON into a data element, you need to do this.

<span data-stuff='{"i":"need","the":"quotes"}'></span>

Here is the relevant quote from the JSON documentation:

“When the data attribute is an object (starts with ‘{‘) or array (starts with ‘[‘) then jQuery.parseJSON is used to parse the string; it must follow valid JSON syntax including quoted property names.”

http://api.jquery.com/data/

Compile this into that

UPDATE: I made a mistake in thinking that RubyMotion compiled Ruby into Objective C. That was incorrect and is corrected in the comments below.

There’s a new trend I find very interesting. It goes like this; take some code in one language, and compile it into another.

Sometimes it’s a completely new language, like CoffeeScript, or Clojure. Other times it’s an existing language like changing Ruby into Objective C with RubyMotion, or Emscripten, which changes C++ into Javascript.

My initial reaction was that programmers are inherently lazy. We want our syntactic sugar. Those are the things that make languages easy to work with. There is nothing bad about this. Making things easy on ourselves is a good thing. We get more done, and the world is better for it.

Also, I lied before when I said this was a new trend. It’s actually been around a long time. No one writes assembly code anymore. C was a better way of expressing code, so we moved to that, and let the compiler do the work of assembling things into machine code. Compile-this-into-that; C into machine code.

But machine code is inflexible. Write once, run once. So, Java comes along and promises to fix all that with bytecode, and a virtual environment. Compile-this-into-that; Java into bytecode. Interpret with a JVM.

There’s also PHP and Ruby. It’s not strictly the same, but the concept is similar. No compile step, but you simply write the code, and then run through an interpreter, much like you do with Java. The interpreters are written in C. So, it’s not compile-this-into-that, but rather, interpret-this-with-that.

So, if this has been going on for a long time, why am I even bother to write about it? Well, the new trend is adding more and more steps, and I find it slightly disturbing. Compile-this-into-that-and-interpret-with-another. Like I said before if it makes us more productive, I’m all for it.

However, I think we may be writing compilers because it’s easier than evolving the systems we use. Examine that statement for a minute. Writing a *compiler* is easier? Why would that be?

My opinion is that it’s because standards are controlled by committee. Compilers are something one person, or a single group of people acting in concert can do. It’s kind of obvious, but I had to write it all down to get my head around it. We’re writing compilers because we can’t get our systems to evolve fast enough to keep up with our needs. We can’t get systems to evolve fast enough because our systems are bogged down by bureaucracy. Here are two lists companies that work on javascript. Ordinary Members, Associate Members. Many of those companies have competing interests, so progress is slow.

But, for now, it’s what we have. It lets us write in our favorite and most comfortable environment and get the benefit of making that code available in many places. And as long as the compilers write better code in the destination language than we do, why not? Anyone have opinions that differ? Let me know in the comments below, or on Twitter or Google Plus.