What prompted this discussion
On one of the Slack channels at work, I shared a link to an article by Mark Nutter that is nearly 2 years old, but could have been written yesterday, as far as I was concerned. Chris, brought up that he got off the front end dev train when Ajax first entered the scene, because he thought it was an over-engineered solution for something that could be accomplished on the back end. That was an interesting thought to me.
At the time, I didn't actually see page reloading as the enemy. It was a nice bit of icing on the cake for it not to trigger, but I was more interested in how this technique would allow for me to develop sites in a more DRY (Don't Repeat Yourself) fashion. That was the real draw for me. As the jQuery framework started to dominate, manipulating the DOM (Document Object Model) got a lot easier. What jQuery brought to the table for me was a way to target areas of a page with a syntax that was familiar and easy to read. The bonus was that it also abstracted away the extra bits Jeremy's instruction demonstrated needed to be considered if we wanted to develop for all browsers and not just the latest, coolest available.
What I've seen with my own two eyes
My career in web development began after Browser Wars 1.0 had come to a close, but web standards were still in need of advocating. A Meetup group in my area was just beginning to form and I was fortunate enough to make first contact with like-minded nerds who would help me become the kind of Front End Developer I was proud to be. Even though my career doesn't date back to the very early days, like Chris can claim, I was in web development early enough to remember the bad old days when Internet Explorer 6 was no longer the darling of the web, but the evil, despicable beast to be wrangled into submission, so that it resembled the cool stuff we could accomplish in Firefox, Safari, Opera, and eventually Chrome.
Yeah, I was one of those. Just like Mat Marquis described, I had wished for one rendering engine to rule them all so I could just do cool stuff. I was a developer who wished people would just upgrade their damn browser already, but I knew first-hand why they couldn't. I was a developer inside a behemoth organization with an IT department who blocked the web team from being able to access Facebook, Twitter, & Youtube, to protect us from stealing time from the organization...all the while not realizing that when I was on Zeldman.com or some other site they didn't understand, it was to help me do my job. Oh, and all 40,000 employees of that organization who might access the internet were on IE6, even though Microsoft had released IE8. Because of that, when we had to get approval for what we were building it had to work on IE6 or our bosses wouldn't be able to access it, thus my ire at how the web worked, or in my view, lagged behind.
What changed my mind
Progressive Enhancement led me out of my cocoon and showed me how to better develop for the medium on which I worked. It was because Dan Cederholm asked and answered the question, "Do websites need to look the same in every browser?" that I came to see how much easier my job could be if I would just stop fighting with browsers and start building for the web as it stood. Aaron Gustafson's book Adaptive Web Design was the clincher, though, that really drove home how beautifully the web works--by design!
Here are some reasons that building for the web is such a joy:
Fault tolerance. I believe this is woefully undervalued to this day. HTML and CSS have this gem baked in. It's crazy powerful! It makes the web a much friendlier place. You can screw something up and your page will still load. Depending on how mildly you screw something up, your page might only appear a little "off." It's based on the robustness principle, but goes a step further than displaying error messages when faulty input is encountered. A web browser does its best to approximate what was intended and display that best guess. If it can't figure it out, it will ignore it and continue on to render what it can decipher.
It took awhile for front-end developers nearly a decade ago, including some of the best of us, to recognize how this baked-in robustness allowed for us to write CSS without using vendor prefixes. We all got swept up in the cool, new features that browser vendors were implementing at experimental stages. We wanted to make use of those things and wrote quite a bit of overwrought CSS just to do so. Even though we cognitively understood that we didn't have to have websites look the same in every browser, we stacked on all the vendor prefixes in order to trigger every browser that supplied one. We eventually realized this was unsustainable. We awoke from our collective hallucination and got back to Progressive Enhancement roots.
The C in CSS: the cascade. More to the point, what is good about the global nature of it. There are some styles that actually belong in the global scope. Set it and forget it type stuff. Typography rules can be written so that they apply to everything rather then declaring them over and over again for each individual component. Because the cascade is our friend, we can make tweaks and alterations as blocks need to be redefined.
I'm not naive. I have certainly run into my fair share of broken styles because something wasn't properly contained...especially in bigger projects. But then plenty of articles sprung up explaining how to architect our CSS based on systems & components instead of individual pages. The Object Oriented CSS (OOCSS) framework hit the scene, thanks to Nicole Sullivan, and Jonathan Snook introduced SMACSS, which taught us how to make our own component-based frameworks when he shared the methodology behind scoping CSS to objects.
It makes sense to me that traditional programmers will recoil in horror when faced with anything declared in the global scope. Developers who have a solid aptitude for working in CSS, determine what should live there and what should not. We experiment with how much is too much and we find interesting discoveries during those experiments. The global scope is your friend, when wielded with reverence.
Javscript, the good parts. This is going to go on a tangent, because I have to explain what I have experienced to demonstrate how much Chris's statement about solving something in a more complex way than might be needed resonated with me.
<video> being referenced. I couldn't see where a link or a button might be generated. I was lost.
I asked him to explain what the functions were doing so I could help figure out what could be the cause, because the browser can play video without much prodding. Instead of successfully getting me to understand what he had built, he argued with me about whether or not it was even possible to do. I tried, at first calmly, to explain to him I had done it many times before in my previous job, so I was absolutely certain it could be done. As he continued to refuse my explanation, things got heated. When I was done yelling at him (not the most professional way to conduct myself, I know), I returned to my work area and fired up a branch of the repo to implement it. 20 minutes later, I had it working. I rubbed his nose in it and walked out of the office to finish the day working from home. It was my mic drop.
Yes, I could have handled myself better, but it's not a great feeling to have someone tell you that you don't know your job when the case is really that they don't know your job. If they would just let you do your part, then we could all shine. You try to excel at your parts. I'll try to excel at mine. Together, we build something cool.
Pendulums swing or everything is cyclical
Ecclesiastes 1:9-11. "What has been will be again, what has been done will be done again; there is nothing new under the sun. Is there anything of which one can say, 'Look! This is something new'? It was here already, long ago; it was here before our time. No one remembers the former generations, and even those yet to come will not be remembered by those who follow them."
When I reflect back on my decade plus of front end development, I am reminded of how much I sought to move the web forward, to make it do more than what was already there. First, it was because all I could see was what was lacking. I was immersed in my frustration. But, as in all things in life, your perspective can change and you begin to take note of what is right instead of only what is wrong.
The complex, bloated web of today is not new. We've been here before, even if the context was different. For some of us, this is the second time we're seeing it. For others, it's their 3rd (maybe even 4th) go around! While the over-engineered web apps have the best of intentions and barriers blocking them from achieving what they seek, they get lost in what is missing instead of striking a balance by using what is present to its fullest potential, and then layering in what is essentially a prototype or polyfill of what the web platform is missing that they require to meet their full potential.
That approach is less bloated, allows for greater access to the products or services by all device types, even the ones we don't know will exist a few years from now. Robustness and resilience are computer science best practices. As the front end community matured into recognizing that they applied to our work, we need to continue to advocate building our projects in this manner.