Note: This is part one of a three-part series titled "Developers in the New Age of the Web"
"Any application that can be written in JavaScript, will eventually be written in JavaScript." - Atwood's Law
It's undeniable; the popularity of frameworks like AngularJS, Ember, Meteor and Backbone show that big changes are happening with the way websites are built.
Single-page apps (which aren't single-page at all) are reshaping the relationship between the server and the browser. Instead of building every page view on the server and then providing it as a mostly static page, the entire rendering process has been moved to the browser.
Why is this change happening? The main reason is a separation of concerns. It makes more sense for HTML, CSS and JavaScript to be solely responsible for building out a website than having a server-side language like PHP do it. Java wasn't built for the web, and that's evidenced by the failure of Java applets on websites. Yet many websites are built with Java as their backbone.
And it goes both ways. Now the server's primary concern can be about business logic. Aside from the initial page load, the server's main role is storing and serving user data. Services like Firebase are popping up that allow developers easy implementation of an API that simply stores and retrieves data. Everything outside of that is handled in the browser.
What this means for companies is that the long-term success of their website is now more dependent on the code that runs in the browser than the code that runs on the server.
JavaScript
JavaScript. It's arguably one of the world's most popular (and still misunderstood) programming languages. What makes it so popular? It's prototypical inheritance system? The fact that almost everything is an object?
No, there's one unique thing about JavaScript that I don't think people recognize. And it's not about JavaScript, it's the fact that JavaScript lives in this place where the visual and the logical intersect. The browser is what makes JavaScript special.
I'd wager a bet that, for most other programming languages out there, almost 100% of the people writing in that language for a profession are full-time programmers. That's their specialty. But it's different for JavaScript. If you go to a conference on JavaScript, a quarter of the folks there will be the typical "programmer", another quarter are going to be focused more on visual design, and the remaining half are an interesting mix of both. They're programmers who have a "visual" brain (or designers who have a "logical" brain).
What I mean by this is that programming in JavaScript is not just about logical operations. Rarely am I faced with a situation in which I need to think about the most efficient sort algorith I can use.
Instead, my time is spent figuring out how I can get "elements" to behave in certain ways. If I click a link on a page, how can I make some content expand out from beneath it? And how can I do that in a way that's visually attractive? And how can I do that in a way that's accessible to keyboard only users? And how can I do this in a way that requires me to write no JavaScript at all? And how do I make this work roughly the same across different devices and different browsers?
The majority of my work in JavaScript day-in and day-out revolves around making the browser behave the way I intend (or at least hope), and that means knowing the world of the browser.
The World of the Browser
JavaScript got lucky. It wouldn't be what it is without its HTML and CSS. One of the best things that's happened to JavaScript in the past few years has been the advancement of HTML5 and CSS3.
There's a saying that "the best code is the code not written". Basically, if you can avoid writing a line of code by doing something smarter, that a line of code you don't have to maintain in the future.
CSS has absolutely taken over JavaScript in the animation department. If you want to make something move or shake or change sizes, it's all CSS. This is awesome. Writing animation in JavaScript was clunky, mainly because visual behavior isn't best described in a programming language. CSS provides a simple, clear syntax for expressing behavior.
Take the following "simple" animation in JavaScript.
var distances = [100, 10]; // total x/y distances to move
var duration = 1000; // animate for one second
var steps = [(distances[0]/duration), (distances[1]/duration)];
var timeElapsed = 0;
var element = document.querySelector('.myElement');
var interval = setInterval(function () {
if (timeElapsed > duration) {
// cancel interval
clearInterval(interval);
return;
} else {
// move element
element.style.top = parseInt(element.style.top, 10) + steps[0] + 'px';
element.style.left = parseInt(element.style.left, 10) + steps[0] + 'px';
// increase time elapsed
timeElapsed += 50;
}
}, 50)
Now let's see what that looks like in CSS:
.myElement {
position: absolute;
transition: all 1s linear;
top: 0;
left: 0;
}
.after {
top: 100px;
left: 10px;
}
From a 'lines-of-code' perspective, things are much simpler in CSS. There's also a ton less boilerplate. Sure, there's a programming language behind the scenes that does the actual movement, and there are JavaScript libraries out there that can simplify animations, but CSS was made for describing visual behavior and it excels at that.
And what about HTML5? It's also taking over functionality that JavaScript used to own. Just look at the new HTML5 form elements to get a good idea. A number-based input? That used to require a JavaScript plugin. Require a form field? That used to require JavaScript, but now is a simple attribute in HTML5. There are so many new features to HTML5 which ease the burden off of JavaScript and into where they're best suited.
JavaScript as a language never would have taken over Flash if not for the advancements of HTML and CSS. Many people downplay HTML and CSS as 'not programming languages', but they're just as essential to the success of JavaScript as anything else.
Continue reading "Developers in the New Age of the Web":
- The New Age of the Web (Part One)
- Front-end Engineers (Part Two)
- Cultivating Front-end Engineers (Part Three)