Home

Frameworks and Ajax

Published 12/20/2017

As we discussed, non-standardization caused a lot of angst among early JavaScript developers.

What worked in Internet Explorer wouldn’t work in Netscape. What worked in Netscape wouldn’t work in Opera. What worked in Opera wouldn’t work in Safari.

“And that doesn’t even get to half of it,” Gunner Technology CEO Cody Swann said. “Not only did the same JavaScript not work from one browser to the next, but the ‘same’ browser on different operating systems treated JavaScript differently.”

For example, writing JavaScript for Internet Explorer on a Mac was totally different than writing JavaScript for Internet Explorer on a Windows PC.

Developers faced situations where they were writing code eight different ways just so their applications would work in all the different browser and operating system combinations.

Standards, which were pushed for by Netscape and Opera, were seen as suggestions.

And the biggest guy in the room brushed aside a lot of those suggestions.

“Two things gave Microsoft a huge lead in the browser wars,” Swann said. “First, Windows was the dominant operating system at the time and Internet Explorer came installed by default on Windows. No one ever bothered to change the default back then.

“Secondly, Internet Explorer – built on the Trident JavaScript engine had way more features than the other browsers.”

The other browsers were moving forward methodically, trying to gain consensus on how those features should be implemented.

Not Microsoft.

They moved forward with whatever they wanted and implemented it however they felt best.

This caused a lot of problems in the short term, but moved innovation forward rapidly as the other browsers fought to keep up.

The biggest innovation – one that would shape the Internet forever – was Ajax.

Asynchronous JavaScript And XML allowed developers to do things that were never possible.

It basically allowed code to access remote URLs and pull data from them without the end user ever knowing.

“Think about it this way,” Swann said. “When you access a website, you’re essentially typing in or clicking a URL, which is an address – like espn.com

“The browser sends you back information that is stylized, structured and human readable. Ajax was doing the same thing with addresses like espn.com/scores.xml. The difference is those URLs returned data that are machine – not human – readable.”

So a script could make a request to one of these URLs and update a scoreboard, for example, without the user having to request it.

Eventually, XML fell out of favor for JSON, but the mechanism style is the same.

“With Microsoft essentially inventing Ajax, the other browsers had to do something fast,” Swann said. “This lead to a wildly different implementation of Ajax across browsers.”

Now things were really starting to become a pain for developers.

Thus the Framework wars were born.

What is a Framework? Well, Wikipedia attempts an answer:

A JavaScript framework is an application framework written in JavaScript. It differs from a JavaScript library in its control flow: a library offers functions to be called by its parent code, whereas a framework defines the entire application design. A developer does not call a framework; instead it is the framework that will call and use the code in some particular way. Some JavaScript frameworks follow the model–view–controller paradigm designed to segregate a web application into orthogonal units to improve code quality and maintainability.

The library vs framework is often debated at length, but back then, both were aimed at solving the problem JavaScript developers were facing.

“We just wanted to write code once, instead of eight different ways,” Swann said. “We just wanted to write ‘go get data from this URL and then update the page’ instead of ‘if you are Internet Explorer, go get data from this URL, like this, and then update the page, like this, and if you’re Safari, go get data from this URL, like that and then update the page, like that.'”

Frameworks allowed just that, but just like browsers, each had their own ideology on *how* to accomplish just that.

And thus we had the Framework War I, which stretched from 2005 to about 2009.

The War presented a different challenge than the Browser wars.

Whereas in the Browser War, the developers were largely helpless and forced to basically choose all browsers, in the Framework War, developers got to choose which one to focus on.

The problem was choosing the right framework to focus on.

“You think picking stocks is hard?” Swann said. “At least you can dump a stock and all you lose is money.

“Frameworks were more like a marriage back then, and you were going to be stuck with the one you chose, so you better choose wisely or be really lucky.”

Swann was on the front lines.

“I was working at ESPN at the time, and somehow, I got tasked with choosing the framework we were going to use.”

At the time, there were four that Swann (and just about every other developer was considering).

MooTools, jQuery, Prototype/Scriptaculous and Dojo.

“Talk about stressful,” Swann said.

To investigate, Swann built small apps in each and rated them based on learning speed, development speed and performance.

Aside from that, documentation and community were really important.

“A framework can be wonderful, but if there’s no one out there using it and the documentation is sparse, you’re going to be on your own every time you run into a problem,” Swann said.

The lack of community and documentation eliminated MooTools and the learning curve eliminated Dojo.

“Dojo was actually my favorite,” Swann said. “It was very similar to today’s React, but it was just way too ahead of its time.”

So it was down to jQuery and Prototype.

“It was really a tossup at that point,” Swann said. “I couldn’t find a huge edge either way.”

So he deferred a bit to another framework – Ruby on Rails.

“Rails was spreading like a wildfire back then and it came bundled with Prototype,” Swann said. “So I figured Prototype would take off right along with it.”

And for awhile it did.

Despite the Rails advantage, however, Prototype eventually lost out to jQuery. Rails even eventually replaced Prototype with jQuery.

“It took years, and Prototype was very good for a long time,” Swann said. “But, yes, I suppose my horse didn’t win the race.

“Event experts can’t predict the future.”