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.
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.
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.
Remember faux columns? I just did equal-height columns with flexbox yesterday. The old days sucked.
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.
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.
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.
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.
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.
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.
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.
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.
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.