Javascript tips and tricks?


#1

I hope my question isn’t too offbase for this forum. I’m wondering what Javascript frameworks, tools or design principles the FlightAware engineers have used/are using to guide them in the construction and successful running of this web site.

I’ve been tasked with designing a feature-rich browser client to run in coordination with an existing server-side API. The challenges are similar to those successfully tackled by the FlightAware site. My background however is more weighted to the server side, where (like the FlightAware founders) I have a fondness for Tcl-based tools.

It occurred to me that it might be fruitful to ask people who evidently share some of my engineering/design values how they approach Javascript development. The world of Javascript tools and frameworks is developing so rapidly it’s hard to evaluate and compare them confidently.

tl;dr - Knowing what you know now, what advice would you give an old Tcl hacker on how to approach development of a sophisticated Javascript client?


#2

I’m not a js developer, but I’ll try to get the attention of one or three.

The two big js libraries we use are jQuery and OpenLayers. Also the datatables plugin for jQuery, and probably a few more plugins. The mobile site is jQuery Mobile.

Also we’re big fans of lazyloading to avoid blocking the page render.


#3

Tell us more about your project and we may be able to offer more detailed suggestions.

FlightAware is highly modular. The flight finder, for example, is built almost entirely in vanilla JavaScript. This is why it’s so much faster at filtering than Kayak or other checkbox-filtering interfaces. The only jQuery is a few lines for animation, and only for newer browsers.

The maps are done with OpenLayers, a mapping library, paired with vanilla JS. This library allows us to ignore many of the details of browser compatibility and basic dragging, zooming, and projection math and concentrate on things like animation.

A very important thing we pay close attention to is page load speed. We want visitors to see the page as quickly as possible, and everything not absolutely necessary to come in later. For example, the maps don’t begin loading until you can see the page. Then, after the maps load, the ads begin to load. It’s important that failures of external resources, like ads or social sharing tools, never hold up our page load if their servers are down.

However, what’s helped us most as far as long term structure and maintainability, is keeping a sharp, simple divide between the client and server side. The server emits the simplest of data structures and the JavaScript accepts only the simplest data structures. It’s this divide that lets us safely overhaul either side without risking breaking the other.

For example, our mapping technology recently switched from units in degrees to units in meters. With the way our site is built, we could have made this change entirely on the server side or entirely on the client side. Either the server could switch to emitting coordinates in meters and the client side left alone, or the client side could convert to meters and no change at all would be required on the server side. We opted for the latter, but either option was open to us. If the communication layer between server and client were at all obfuscated and anything but the simplest data structures were passed between, this upgrade would’ve been a disaster that required careful coordination of fixes on both sides.


#4

The mobile site uses jQuery mobile, along with backbone.js and underscore.js. The approach we take on mobile is to fetch all the data through a json api and render it on the client. This allows us to (1) use as little bandwidth as possible, and (2) cleanly abstract our data from how it is presented.

It’s unclear whether you’re a javascript beginner or not, but I should mention that you can get a lot of milage out of really learning Javascript the language and how to use it effectively. It’s a better language than most people give it credit for. I recommend Javascript, the Good Parts by Douglas Crockford. It’s short and opinionated. This will serve you no matter what framework you end up using.