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.
The first bit of Ajax that I tinkered with was due to Jeremy Keith's book "DOM Scripting." I knew absolutely no Javascript at the time, but he wrote in such a way as to have it make sense to me. I wasn't aiming for turning what I built from being a website into a web app. I liked the idea of being able to update something in the page I was building with a portion of content that might live on another page. I could just call out to that portion and insert it, almost like magic. No page reload required.
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.
In those days, we used .png images to fake rounded corners and the most popular use for a .gif at the time was for 1x1 pixel spacing, not sharing funny retorts on social media or embedding memes in our slides. The other thing we did was throw gobs and gobs of Javascript at a slow as hell rendering engine forcing whatever backwards compatibility we could at shitty browsers for the sake of "advancing the web!"
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.
This was a pivotal point in time. Front End Developers began to adopt some of the best practices that our Back End Developer counterparts had been employing for years. As front end development began to adopt back-end best practices those who may have been "traditional programmers" became attracted to what was going on in the front end. Javascript's maturity over time and the introduction of Node.js opened gates that once were locked, due to a lack of interest (in both directions). The front end now had "real promise" to those who built programs and systems to support interfaces.
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.
About 8 years ago, I interviewed for a role at a startup that had a web-based platform. They also had a web-based mobile version of that platform that was not at parity with the other platform. They were basically trying to make their mobile app version behave like a native iOS app. It was heavily (over)architected in Javascript.
I was put on the mobile team, hired as an expert in UI implementation, but I was essentially relegated to cleaning up the UI after the Javascript developer had taken things as far as he could. Frankly, it was a waste of my expertise. It finally came to a head when he had been struggling for 2 weeks(!) to get a video to play at the click of a button and display as large as possible on a phone. I looked under the hood and got lost in all the looping functions and the variables and couldn't figure out what the code was supposed to do. I couldn't find any HTML <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.
I was so frustrated by how over-architected that "web app" was that I was hell bent to rebuild it from the ground up using progressive enhancement as my guiding principle. This was before Progressive Web Apps (PWA) had a name or books written on how to do it. I would have been figuring it out as I went and with Javascript not being my strong suit, it would have taken me forever. Imagine how vindicated I felt when the term PWA was coined and Google started suggesting (err demanding) that this was the better way. This better way doesn't vilify Javascript. It plays to its strengths, allowing HTML and CSS to retain theirs, too. Everybody wins by excelling at their part. It works for humans as well as languages!
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.