Compilation of JavaScript resources

The benefit of JavaScript is that there are a ton of resources. The downside of JavaScript is that there is so much, it’s hard to figure out where to start and who to believe.

After the expected period of beginner fumbling, I now know a few things to be incorrect. But more importantly, I now know many things to have no single Right Answer(™). JavaScript is so flexible that there are many ways to do many things and not much to differentiate one from another except personal preference.

This makes me wary of advice compiled on somebody’s blog, because that’s really their personal opinion and I don’t know if I necessarily agree with that person’s priorities.

But if the collection of resources was assembled by a group of people, that makes me a little more comfortable. So I was happy to stumble across JSTheRightWay.org.

The name seemed pompous and arrogant, but the introduction made me feel like I’ve found a good thing:

This is a guide intended to introduce new developers to JavaScript and help experienced developers learn more about its best practices.

Despite the name, this guide doesn’t necessarily mean “the only way” to do JavaScript.

We just gather all the articles, tips, and tricks from top developers and put it here. Since it comes from exceptional folks, we could say that it is “the right way”, or the best way to do so.

I’ll be coming back to this page quite frequently. May it live up to my hopes!

The other “cloud development”

When I set out on this adventure, I knew I wanted to eventually cover the basics of the major cloud services. Write some sample services to run on Amazon Web Services, Microsoft Azure, Google cloud services, etc.

I was surprised to stumble into an entirely different meaning of “cloud development”: writing code in a browser. I had seen the educational coding playgrounds of Codecademy, and I had seen small trial tools like JSFiddle, but I had no idea that was just the tip of the iceberg and things can get much fancier.

I had started a project to practice my newly-learned jQuery skills. Just with a text editor on my computer and running the HTML straight off the file system. As soon as I learned of these web-based development environments I wanted to try it out by moving my project over.

The first I tried was Codenvy, whose whitepapers are quite grandiose in what it offers for improving developer productivity. Unfortunately the kind of development Codenvy supports aren’t the kind of things I know anything about today. But I’ll revisit in a few weeks to check again.

The second I tried was Cloud 9, which does support simple HTML+CSS+JS projects like what I wanted to do. Working in Cloud 9 gave me some tools for static analysis and serving my file off a real web server. It also integrates into Github preserving my source control workflow.

After a JavaScript project of around 300 lines of code, I can comfortably say I’m quite impressed. In the areas of development-time tooling and integration experience, it far exceeded my expectations. However, there was an area of disappointment: the debugging experience was either hard to find or just wasn’t there at all.

When my little project goes awry, I resorted to loading up the project in a separate browser window and using the web browser debugger. This is on par with the simpler tools like JSFiddle and JSBin. I had hoped for better.

I’m cautiously optimistic I’ll find a tool with better debugging experience as I continue to explore.

Polyfill: for the gap between theory and reality

Today was a fun day hopping from one educational site to another. Since I just completed the jQuery track on Codecademy, I thought I’d look around for additional jQuery resources before I dive into another Codecademy track. The jQuery Learning Center sent me to the Mozilla Developer Network which in turn sent me to Google Developer resources which set me to…

Every one of those sites would occasionally mention some kind of polyfill. It’s not the first time I came across the term, but I had assumed it was a vector graphics concept: Draw a polygon and fill it with a color, or something along those lines. As I came across more and more polyfill references, though, I started to realize my original assumption was wrong.

In the current web development world, there’s the grand theory of HTML5, the gold standard by which all of the web will flourish. But in the real world, we are hampered by the fact that none of the browsers fully implement web standards in all the same ways. There’s even a web site set up to document all the ways in which various browsers fail to fully implement these standards.

The gap between theory and reality is bridged by polyfill, a category of tools created by various frustrated developers to make individual real-world web browsers work closer to somebody’s idea of perfect browser.

Coming from the world of operating system development, I know of this concept by the name of “compatibility shims” and I’ve even had the misfortune privilege of writing a few of them myself. Since they’re bridging the ideal world and the ugliness of the real world, shims are never great pieces of code. A shim is always constrained by some inconvenient reality, written to solve a very specific problem, and never quite live up to the ideal.

So I was not terribly surprised that we have many, many polyfill libraries floating around. Each can solve a specific problem under a specific circumstance, none are capable of solving all the problems perfectly. To solve a specific problem, a developer would have to comb through the list and test to figure out which polyfill to use. I’m sure some end up writing a quick-and-dirty solution to their one Problem of the Day instead of using a library.

But I do admire the ideal of having a centralized resource!

Unexpected find: ThingLink and its business

A Science News article online experimented with interactivity not possible in their print edition. It was fairly simple at first glance: when a cursor hovers over certain places in the image, additional information pops up. Seen all over the web, like the little pieces of trivia behind bing.com background picture of the day.

What caught my attention is the link in the corner: “Made with ThingLink, Learn More” What I had thought was a simple piece of HTML is actually a business built around the concept.

A brief exploration found that ThingLink hosts the image (and associated server storage and bandwidth) plus the interactive scripting. The package of content is then available to be served alongside content hosted elsewhere, such as WordPress.com. I can embed a ThingLink right here in this post, if I had something interesting to show.

There’s a basic level of the service for free. To make money, they sell higher tiers with features like customization, branding, and analytic information. I’m ignorant on how this information might be valuable, but ThingLink has an idea: they believe the full set of features is worth over $200/month to some people.

So definitely not just a trivial piece of HTML. It is the tip of the iceberg of a corner of web commerce I didn’t even know existed before today.

War of Currents… again?

Every engineering degree covers electricity, it’s kind of important to everything engineered by man. Same with a science degree: electrical interactions are a large part of nature. In chemistry, biology, and propagating to all the other sciences.

Outside of scientists and engineers, most college physics courses would cover electricity, at least the principle differences between alternating current (AC) and direct current (DC).

Even outside of that, AC vs. DC gets mentioned in the occasional web comic.

As part of any coverage of electricity, there would be a chapter, a footnote, or some mention of the War of Currents: An ideological battle between backers of each form of electrical power, each convinced their side is superior to the other. The history lesson usually concludes with AC winning the battle around 1900. As AC works better with our power generation, power transmission, and power consumption.

Or more precisely… AC works better with power generation/transmission/consumption technology of 1900. The world has changed a lot since.

Machinery of 1900 run on AC, but modern electronics run on DC.

Old inefficient lights run on AC, but modern LED lights run on DC.

Coal-burning power plants churn out AC, but solar panels generate DC.

We never had a practical energy storage mechanism with AC, electric batteries have always been DC.

We tolerate AC-DC conversions on all of these things. Computers have an AC/DC power supply brick. LEDs make similar conversion. Solar panels have to use an inverter to convert their DC output to AC for use. All because our power grid is AC. And that’s not going to change for as long as AC is superior for power transmission.

But today I learned that, thanks to advancing technology, the economics of long-distance power transmission is tilting in favor of DC.

This is very interesting, because photo-voltaic solar power plants need a lot of real estate so they tend to be out in the middle of nowhere. A big factor in the economic viability of such projects is long distance transmission of power to population centers.

Combine the two, and it looks like all the pieces are in place for DC to make a come back.

I’ll be watching this space with fascination.