TXJS: A Look at Javascript as a Language and Community

August 30th, 2012 by Keith Peters

Recently, Todd Anderson and I attended TXJS, a JavaScript conference in Austin, TX. I wanted to give some general feedback on the conference itself, and then discuss a bit about JavaScript as a language and the JavaScript community.

The Conference

The conference was a one-day, two-track setup with nine slots and a day of training beforehand. Each slot was 40 minutes, which in my mind is short for a technical presentation. With a full hour, you can start to teach a few concrete techniques. But 40 minutes just leaves you time to get across a general idea, suggestion or viewpoint. In other words, in a shorter session, you might be able to say WHY you should do something, but in a longer session you could show HOW. Then again, even an hour is barely enough time to teach anything concrete and many people do not do well at it. All too often I’ve found myself getting bored and looking at my watch towards the end of a longer session. Perhaps conferences need to offer a mix of longer and shorter sessions.
It was very strange to be at a conference where I was not a speaker and knew nobody except the other person from my company I came with. I believe the last conference I attended without speaking at was Flash Forward NYC in 2004. In that sense, it was kind of a relief to just sit back and go to all the sessions and take it all in without having to worry about my own talk. Much stranger was just not knowing anybody there. Todd and I mostly hung out together and talked to a few others here and there. I’m far more used to meeting up with the usual crowd that has been present at every Flash event for the last 10 years. Also, being a speaker affords you a certain amount of mini-celebrity at an event, with people you don’t know coming up and talking to you, mentioning your talk, your site, your books, whatever. It was odd to just be another nameless face in the crowd. Odd, but probably good to get that perspective now and then.

The Training

The training on the first day was an overview of the JavaScript language from Ben Alman of Bocoup, a company located right here in Boston. Ben undoubtedly knows his subject matter and it was a solid day of training, but I would say his talk was targeted a bit more towards newcomers to the subject. I picked up on several small concepts I didn’t know and clarified several others, but it was largely a review of material for me. This is not to say that a review is bad. I went through a lot of the examples and tried out various iterations and came out with more confidence than I went in with, so that’s good.

Given the nature of the training and the time constraints of the sessions themselves, I can’t say that I walked away from the conference with a huge wealth of new knowledge of specific things about JavaScript. But I did walk away with several areas sparked with interest for future study, which I am actively pursuing. One of these subjects is Node.js.

New Interests

Node.js, for the uninformed, is a JavaScript engine outside of the browser, wrapped, optimized, and enhanced for use as a server, but also useful on a local machine. Node allows you to write server side applications in JavaScript, and also allows you to write command line JavaScript programs that run on your local machine. This can be useful for testing, build processes, automation tasks, etc. This is similar to how Ruby is largely used on the server, but commonly used for local build processes and other tasks as well. I picked up a book on Node.js and was amazed that within an hour of starting the book I was writing HTTP and socket servers. Not only did they work, but I understood every line of code that went into them. Amazing. Very simple yet powerful stuff that I’m glad to add to my knowledge base.

The next area of interest that was sparked at TXJS was WebGL. This is an implementation of OpenGL, the 3d graphics library used in many computer platforms including all iOS and Android devices, but implemented in the browser with a JavaScript API. Although I wound up missing the one WebGL session at TXJS (a tough choice between that and another session going on at the same time), I vowed to do some investigation of it on my own. Still working through Node right now, but WebGL is next on the list.

Communities and Focus

I’ve been thinking a lot about tech communities lately. I got a foot in the door of the Flash community back in the early 2000′s and while I’ve always delved into other various technologies, I never got really involved in any other tech communities. Now, I’m not saying anything as inflammatory as “Flash is Dead”, but I do think the Golden Age of Flash is in the past and it’s probably not going to see the level of excitement and support it saw in its heyday. Personally, I do not have a ton of interest in where Flash’s current road map is leading it, which is what led me to become more interested in HTML5/JavaScript. But I haven’t joined the anti-Flash crowd either. We’re still pulling in lots of Flash work here at Infrared5 so I imagine I’ll have a hand in AS3 for a good long while to come.
Anyway, when I started getting more interested in JavaScript development, I naturally started looking at the JS community. Unfortunately, I think it has quite a different dynamic than what I have become accustomed to with Flash. Firstly, the JS community is probably a lot larger than the Flash community ever was. But for a community of that size, it seems like there are disproportionately fewer well known names – JavaScript celebrities or “rock stars” if you will. I think a lot of this has to do with a lack of focus in the language and development practices. Love it or hate it, Adobe (and Macromedia before it) has always been a central point around which the Flash community revolved. They’ve held the reins on the product. You’ve always known you that you’d be getting a new version of Flash every 18 months or so, and that there would be a finite number of cool new features in that update. If you’re lucky enough, you might get onto the beta. Adobe/Macromedia have historically sponsored most if not all of the major Flash conferences and the same group of evangelists and developer relations people show up to talk and listen. Moreover, Adobe has given the ActionScript language a focus, with official components, tutorials and sample code that established a set of best practice and way to code.

Contrast that with JavaScript as it stands today. There is a standards committee that can’t seem to agree on anything. If they do agree on something today, it could be literally years before it is official. Meanwhile, browser vendors are moving forward implementing features years before they are official and sometimes before they are even agreed upon. Some are even implementing their own features that are not part of any standards process.

And that’s only the core language. Ask a group of JavaScript developers about the best architecture for an application and you will start a holy war. Classes or prototypal inheritance? The best MV* framework? AMD or CJS? Forget about it. World War III almost broke out a few months ago over the question of whether or not you should use semicolons! There’s even a growing question about whether or not it makes sense to code JavaScript IN JavaScript. With a steadily increasing list of languages that “compile to javaScript” but offer different – possibly better – constructs for managing large applications, it is a valid question. But with so many of these new languages around, and no standard, we are again back into the question of which is “the best”. And the arguments ensue…

Summary

It’s an exciting time to be into JavaScript, but not an easy one. There is massive innovation happening on so many fronts. There are dozens of new frameworks and libraries coming out daily – more than any person could possibly keep up with. Standards are evolving and there is something new to learn every day. The pace of this innovation makes it hard to keep up, and the lack of focus means that no matter what you do, how you code, or which framework or library you use, there will be countless people waiting in the wings to tell you you’re doing it all wrong. My advice is to learn what you can, don’t worry about the rest, and have fun.

Keith Peters

, , ,

The Brains Behind the Booth

August 29th, 2012 by Rosie

This month, IR5’s very own Kelly Wallick is featured in the ‘Sunday Sidebar’ on VideoGameWriters.com. Kelly talks with Christopher Floyd about her work as organizer for the Indie Megabooth, the life of an extreme multi-tasker, and her most prized geek possession. Check it out here!

Be sure to say ‘Hi!’ to Kelly this weekend at PAX!

Infrared5's Kelly Wallick

, , , , ,

TXJS: How I Found a Fresh Perspective in the Heart of Texas

August 28th, 2012 by Todd Anderson

TXJS: How I Found a Fresh Perspective in the Heart of Texas

Every year, developers from all over the world make their way to Austin, Texas, to spend a day learning the latest and greatest developments in JavaScript. This year, I had the pleasure of attending the third annual TXJS. Drawn in by the promise of mid-June heat and the wild grackles of Austin, it was the wonderful venue and line-up of exceptional speakers that make TXJS an event I would highly recommend attending.

TXJS was a dual-track event, so conference-goers had to choose their talks wisely. Fortunately, the recordings will be made available online at some point. The talks I was fortunate enough to see did not disappoint. Though I picked up some tidbits about the language here and there, the real take-away from the event was a fresh perspective on developing. I will outline three rules I plan on making habit of remembering:

Test Smarter

I am a huge advocate for testing and analysis in development. Loosely tied to that is my desire for refining the build and deployment process for projects. My ultimate goal as a developer is to deliver a product that provides the best experience to the user under the given environment. I have been pursuing that goal by writing unit tests, vetting and (sometimes) writing plugins for my IDE and creating proper build dependencies and deployment scripts. In focusing on this, my comfort level in testing the experience of a deployed application in its natural environment has plateaued.

Part of this may be due to the nature of every day use of a browser, but mostly it is because of laziness and a ”good-enough” mentality. I am quite familiar with ‘WebKit Inspector’, as I use it every time I test in development and the staging-ready build, yet I have stuck to using Safari as the browser for this.I have a problem with tabs and cache when it comes to my everyday browser. By “problem”, I mean I am a hoarder. By “everyday browser”, I mean the one I check email, rss feeds, click links and (leave) open tabs in: Chrome. I have literally dozens of tabs going at a time. It is a problem. I’ll admit it. What is a bigger problem is that it was keeping me from the wonderful WebKit Inspector that Chrome provides, all because I didn’t want to clear my cache and ruin my set up.

This is where my time at TXJS started to impact my thinking. In Madj Taby‘s talk, Tools and Techniques for Faster Development, he presented useful tips and tricks in using the WebKit Inspector provided from the Google Chrome team. Taking and expanding on topics he discussed in Modern Web Development: Part 1, he showed some key features I knew I could just not live without in my testing from that moment forward, mainly the settings (settings for your inspector, can you believe it?!), more profiling options, event handler listing and expanded memory graphing.

From this talk, I realized that I should be engaging with the Inspector more. I run things through WebPageTest (which I think uses PageSpeed) and various browser plugins like Dom Monster and YSlow, but I am not engaged with the result – only re-active. I should be testing and experimenting more in the same environment that the end product will be interacted with while I am interacting with it.

Chrome Canary is now my interactive development and pre-staging deployment test browser and I am happy about seeing the light to upgrade.

Madj Taby’s talk offered some clarity for me on how I can be testing smarter, taking advantage of tools available to me to be a better developer.

Experiment & and Challenge Current Implementations

Far too often, I find myself implementing the same solution for what appears to be the same problem again and again. While there is nothing technically wrong with that approach, as long as it is tested properly and known to be a valid solution, I might be missing out on discovering an alternate path which will provide the same desired result. Even if the new path is not as straightforward, it has the potential to get me thinking in new ways about a subject I thought I had mastered..

Alex Russel‘s talk, Overconstrained: the Secret Lives of Rectangles, reminded me of that fact. One of his projects, Cassowary JS, addresses constraint-based layout for DOM elements. The methodology used in addressing the issue is a bit more involved than that, but the end result is a toolkit used to assign constraints to elements whose layout will be updated at runtime.

[NOTE: The wording in the preface to this section, in as far as weighing the validity of a new experimental path, should not be directly applied to Alex's work demonstrated. Anything I mention in this section is not intended to belie his work- it was his talk that made me realize my own short-coming in experimenting more with solutions. It's probably the talk I spoke to others most about afterward.]

I like a clean separation of layout and logic and lean towards Progressive Enhancement, staying far away from adding DOM elements and styles through JavaScript. I oftentimes find myself battling rendering engines to achieve the desired layout. Is it so wrong that I dive into scripting a layout in hopes of coming to an understanding of how the layout routines are run? It certainly is not. I don’t want to throw out my principles of application design to ‘just get it done’, but I can be more open to exploring different choices that may provide a new angle to look at the problem.

Have Fun

The title of this section is not meant to sound frivolous. In fact, the talk that drove this point home to me involved highly technical material, but it was presented in a playful manner by Heather Arthur in her talk, Machine Learning for JS Hackers, on a subject that culminated in a project that had me and many others in the room laughing along – kittydar: face detection for cats.

The talk was actually more about machine learning and perception, yet the underlying tone (at least how I perceived it) was to follow your interests and experiment. “Have fun!” Arthur is not hired to write detection scripts for social networks to send Growl notifications on incoming cat picture uploads – at least as far as I am aware. The underlying message of the talk was in machine learning, from which experimentation and exciting projects arise. The talk made me realize that sometimes diving into a subject and experimenting is meant for your own enjoyment; it doesn’t always have to tie back to some body of work.

Conclusion

Its great that I have found a method of working that is comfortable for me, but I shouldn’t stop experimenting and evaluating other methods and procedures that can help me find a solution or just having a laugh. Sometimes it takes being immersed in the intellect of others to light that fire. Thanks to Alex Sexton, Rebecca Murphy, the crew and sponsors for putting on a great event.

,