Blog

#development

#web-development

I’m opinionated. If you’ve worked with me or hung out with me for any period of time, you know this. I’ve been building for the web since 2001, before JavaScript libraries, before CSS, before Web Standards. That is a lot of years of experience and with it, one learns a few things. The Standards movement was a major thing just as I was getting started freelancing. jQuery was just coming about as I entered and assisted in teaching a JavaScript class in college. Responsive Web Design was coined and defined as I started my first role at an agency in Chicago.

One learns a few things.

Of the last few years, I have pushed hard against using jQuery. Simply put, most browsers have solid support for new technologies that emulate many of the great features of jQuery. Those native features do it faster, better, and require less code. Remove jQuery and you remove 30+kb of resource load.

I have pushed against Bootstrap. It is a large beast of a library when most sites that include it use it for a grid system and not much else. A grid system can be written in less than 100 lines of CSS that’ll achieve the needs of your site specifically, so why include 200+kb of resources?

I have pushed against WordPress. It’s not good for the developer and offers a not-great experience for the client. There are better CMSs.

So this Summer and Fall, I decided to dabble.

I hadn’t built a website on WordPress in many years. The last one I built was before ACF took off. So I built a client a site in WP and I didn’t hate it. Much of what I have said against WP remains true. Especially after launching a large site on Craft earlier this year. But, for what it does well, it does well. Build a couple of custom plugins was a breeze. ACF made storing complex data from two third-party sources easy and displaying it easier.

I have never used Bootstrap but always maintained that it is best suited for prototyping and administration panels. So as I started building an admin panel for a current project, I decided to try Bootstrap. And I didn’t hate it. There are parts that I won’t touch. The grid system is actually one of them. The spacing utility classes, while useful if you are not writing a lick of CSS, are another. But, the component structure isn’t far from something like Atomic CSS and is actually a welcome thing for the needs of the project. Unfortunately, it requires that the page resources weigh over 300kb, which means I will likely scrap Bootstrap in a few weeks and rewrite with my own CSS.

We must, as developers, not become set in our ways and get dogmatic about certain things. There are things that we should be more opinionated about than others. I wasn’t necessarily wrong with either WordPress or Bootstrap. But, now that I have worked more with each, I can see the lure of them when it comes to getting something done quick and dirty. Atop that, I now have a more solid argument against some points of them.

So if you haven’t dabbled with something in a while or at all, maybe try. You may learn a few things.

But the core principles and mechanisms [of CSS] are no more complicated than they were a decade or even two decades ago. If anything, they’re easier to grasp now, because we don’t have to clutter our minds with float behaviors or inline layout just to try to lay out a page. Flexbox and Grid (chapters 12 and 13, by the way) make layout so much simpler than ever before, while simultaneously providing far more capability than ever before.

Eric Meyer

I built my first couple of layouts with Grid over the last weeks. Hot dog. Things that would have taken me forever with floats took me just a couple lines of code with Grid. I’ve been using Flexbox for a while, to the point of mostly knowing the syntax, but Grid is a brand new beast.

It is astonishing that we have, for almost 20 years of CSS, never had a native layout system. Now we do. Instead of complex (and large) libraries like Bootstrap, we can now do complex layout with simple syntax. Hell, we can do far more complex, asymmetric and two-dimensional layout with Grid that we would never consider doing before. A renaissance in web design is coming. But are front-end developers up to snuff?

The subtle difference between progressive enhancement and graceful degradation is lost on too many. Many of those that support “mobile first” don’t support progressive enhancement, which is an oxymoron.

Mobile first is progressive enhancement. Start with the most important part of any site: content. Mark it up. Semantically. Why? Because some readers experience your site without CSS. It’s true. Some just want the content. Screenreaders and search engines are the largest of these.

Then style the content. That’s the CSS. Mobile first says start with the LCD, the Lowest Common Denominator: mobile. But make sure that your CSS works in the LCD. That might be IE 9. It might be IE 11. Look at your analytics if possible. Progressive enhancement means add features when available. Progressively enhancing. You see? So if you are using a feature that is only available to IE 11 and better (Chrome, Firefox, etc.) and you need to support IE 9, make sure that the feature is not necessary for the user experience.

Then JavaScript. Understand that some have JavaScript disabled. Whether it be over-cautious IT departments, search engines that cannot handle rendering and parsing JavaScript, users with bad network connectivity that fails to load it, or most importantly screenreaders that help those with handicaps consume the content of the web. JavaScript is an enhancement. So long as you have the last two components set, your page works fine when JS is turned off. So, as features are available, use them.

But see, too many developers these days have abandoned this methodology that fueled the Web Standards movement. Instead, sites require over 300 kilobytes of JavaScript libraries and don’t load anything if JavaScript is disabled. Instead of starting with content, they start with jQuery, Angular, React, or whatever the library de jour is. Everything is built in JavaScript. This is graceful degradation, start with the Greatest Common Denominator. Except many aren’t even testing for the LCD. They aren’t turning off JS to make sure that their site will work for those that disable JS. Often they even break the most basic components of the web browser: the URL and the back/forward buttons.

We need to get back to progressive enhancement as the standard. We need to get back to the promise that the web is accessible to all, no matter the device they use.

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.

Mandy Michael

Preach! It’s all I see these days in job descriptions. JAVASCRIPT! Ninja preferred. Rockstar acceptable. And then they produce crap frontend code. Their HTML and CSS is restricted to Bootstrap at best, custom crap with style attributes all over the place at worst. When I was their age, the emphasis of frontend was on the other side of the triangle: HTML and CSS. Without these, your JavaScript means nothing. Even if you are embedding your CSS and HTML in your JavaScript. Shudder.

Remember faux columns? I just did equal-height columns with flexbox yesterday. The old days sucked.

Now if we could just convince the kids to stop putting HTML and CSS inside the JavaScript…

DirecTV has announced that they will only support Internet Explorer starting in July. Sorry, my bad. They will only support Chrome. Still, just as bad a move.

I remember when I got my first Mac back in 2004. Many sites still only supported Internet Explorer 6. And IE6 didn’t exist on Mac. Only IE5 did. Off the top of my head, the biggest two sites that I frequented that did this were my bank and Old Navy. Yes, Old Navy, an ecommerce site, in 2004 only supported IE6. No reason for it, as they didn’t use much DHTML— the hip term for JavaScript at the time— and certainly had no features that would require a specific browser, but that was the way things were done in the early 2000’s. You picked one or two browsers to support and that was it.

When jQuery first came out in 2006, it was built around browser-detection based forking. If IE, do things this way; if Firefox, do things this way. It wasn’t long before they abandoned that and went to feature-detection. If the browser supported this feature, do things this way; otherwise, do things this way.

When iPhones first hit, the popular thing was to look for a user-agent string that included iPhone. If present, deliver an iPhone experience. Then responsive web design hit in 2010 and we started targeting screen dimensions.

This was the push for the longest time. Get away from detecting browsers and specific devices. Look instead at what the browser and device are capable of, and progressively enhance the UX from there. Build for the lowest common denominator.

But now, so many sites are built to require JavaScript. React, Angular, Vue, and other JavaScript frameworks have taken over front-end development. We are including so much JavaScript on our sites that we need task management scripts and package managers to keep everything straight. Our engineering has gotten more complex than ever necessary.

And, to make matters worse, we are starting to see developers getting back to supporting specific browsers. When your front-end uses very specific, new technologies, that is the choice a developer has to make. Either a) don’t use it, as the support isn’t great yet; b) use progressive enhancement and provide a feature when available; c) find a polyfill to provide support to the greatest number of users. There should be no d) only support Chrome.

If you don’t learn your history, you are damned to repeat it.

Using a framework is not always bad, outsourcing your understanding of the basic languages of front-end development to one is definitely bad.

Rachel Andrew

Great article on CSS support, making everything look the same everywhere, and more. This line, though, stood out to me. It’s an argument I frequently find myself in. Everyone knows that I hate Bootstrap. The why is what they don’t often understand. That line sums it up.

All too often I see “JavaScript” developers that cannot write a single line of vanilla JavaScript. Front-end developers that struggle outside of Bootstrap. That don’t know what the browser is capable of without Angular.

Have you outsourced your understanding of the basic languages to a framework?

Personal sites, our blogs, these were once our playgrounds. My own site was the first place I added rollover images, CSS for fonts, tried out a “table free” design. I wrote about the web, surrounded by my own experiments with the web. We all did, and it was only in reading those words from 1999 that I realised there was more to owning your own content than simply not publishing your words elsewhere.

Rachel Andrew

My first blog was called Cochon d’Vol, butchered French for the Flying Pig. It was on a blogging system I built in PHP called Blog Wizard. I put a lot of work into that blogging system. Even had a logo. Never intended to release it. But it was mine. And the site went through a redesign every few months. Because that’s what we did back then.

That was a lot of work. Sites like MySpace were much easier for publishing content. And MySpace, unlike its predecessors, allowed for custom CSS to be injected by users, making each MySpace profile an experience. Usually a gaudy experience with animated backgrounds and poorly chosen colors. And then came Facebook. More refined, less targetted at children. Just publishing.

We lost sight of the importance of our own domains. Photos went up to Instagram. Every thought that came to mind went up to Twitter. But our oasis, our experimental island, was lost. Over the last year or two many of my favorite writers in web development have returned to their blogs. I have done my best to do the same. The temptation of tweeting is hard. Look at President-Elect Trump. Finding a happy medium— a pattern of what goes to those centralized networks and what goes to my own site— takes time and intentionality.

But here I can play. A refresh of this site will be coming soon, something I started working towards right after New Years. After a tumultuous 2016, I finally updated Ghost to the latest and greatest version, gaining a lot of functionality that I hadn’t had before and started planning around an updated look. Let’s return to writing refined, thoughtful articles instead of spontaneous, haphazard thoughts. Let’s return to our playgrounds.

The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.

Must read for front-end developers. No, seriously. Don’t, please don’t let the speed at which you write code influence the future maintainability of your code.

I tried to find a couple of quotes from this article, but I think I need this entire section to sum up where I am as a web developer.

Many web developers have “moved on” from a progressive-enhancement-focused practice that designs web content and web experiences in such a way as to ensure that they are available to all people, regardless of personal ability or the browser or device they use.

Indeed, with more and more new developers entering the profession each day, it’s safe to say that many have never even heard of progressive enhancement and accessible, standards-based design.

For many developers—newcomer and seasoned pro alike—web development is about chasing the edge. The exciting stuff is mainly being done on frameworks that not only use, but in many cases actually require JavaScript.

The trouble with this top-down approach is threefold:

Firstly, many new developers will build powerful portfolios by mastering tools whose functioning and implications they may not fully understand. Their work may be inaccessible to people and devices, and they may not know it—or know how to go under the hood and fix it. (It may also be slow and bloated, and they may not know how to fix that either.) The impressive portfolios of these builders of inaccessible sites will get them hired and promoted to positions of power, where they train other developers to use frameworks to build impressive but inaccessible sites.

Only developers who understand and value accessibility, and can write their own code, will bother learning the equally exciting, equally edgy, equally new standards (like CSS Grid Layout) that enable us to design lean, accessible, forward-compatible, future-friendly web experiences. Fewer and fewer will do so.

Secondly, since companies rely on their senior developers to tell them what kinds of digital experiences to create, as the web-standards-based approach fades from memory, and frameworks eat the universe, more and more organizations will be advised by framework- and Javascript-oriented developers.

Thirdly, and as a result of the first and second points, more and more web experiences every day are being created that are simply not accessible to people with disabilities (or with the “wrong” phone or browser or device), and this will increase as standards-focused professionals retire or are phased out of the work force, superseded by frameworkistas.

Zeldman

I’ve personally been building websites since 2001. The web standards movement was just beginning. In 2004, I was part of a state web development competition through my high school and they required our sites be built in XHTML and CSS. I felt the push back against ugly, inaccessible plugins— like Flash— and bad JavaScript practices from the start. Fast forward seven years and I led the charge for responsive web design at a Chicago-based agency, declaring that we shouldn’t upcharge our clients for something that is absolutely necessary. That was before we reached 50/50 desktop-to-mobile traffic.

Progressively enhanced, responsive, and accessible websites are in my blood. And that’s why it pains me so much to be rehashing conversations from the start of the standards movement as to why we shouldn’t require JavaScript, or assume that our user’s device supports fill-in-the-blank, or even assume our users can see like we do. And I’m having to rehash these conversations regularly with the Angular and React JavaScript frameworkistas.

We fought this fight for a reason and it matters today more than ever. Tomorrow is Blue Beanie Day. I’m old enough to remember why. I will be wearing one to stand for accessibility and progressive enhancement. I hope you do too.