Following on from her great conversation with Jen on The Web Ahead podcast, Rachel outlines a strategy to avoid feeling overwhelmed by the deluge of tools, frameworks, libraries, and techniques inundating front-end developers every day:
Learn your core skills well. Understand HTML and CSS, be able to build a layout without leaning on a framework. Get a solid understanding of how a website actually gets from the server to a browser, an understanding of security and accessibility. These are the basics, the constants. These things change slowly. These things sit underneath all the complexity and the tooling, the CMSs and the noise of thousands of people all trying to make their mark on this industry.
She also makes this important point:
As you are doing this don’t forget to share what you know.
A wonderful, wonderful history of the web from Dave at this year’s Beyond Tellerrand conference. I didn’t get to see this at the time—I was already on the way back home—so I got Dave to give me the gist of it over lunch. He undersold it. This is a fascinating story, wonderfully told.
So gather round the computer, kids, and listen to Uncle Dave tell you about times gone by.
Yes! Yes! YES!
Marco makes the same comparison I did between the dark days of pop-up windows and the current abysmal state of bloated ads and tracking on today’s web.
I have one more thing to add to this list…
But publishers, advertisers, and browser vendors are all partly responsible for the situation we’re all in.
…developers. Somebody put those harm-causing
script elements on those pages. Like I said: “What will you be apologising for in decades to come?”
In a few years, after the dust has settled, we’re all going to look back at today’s web’s excesses and abuses as an almost unbelievable embarrassment.
From the people who brought you youmightnotneedjquery.com comes youmightnotneedjqueryplugins.com.
Don’t get me wrong—jQuery is great (some of the plugins less so) but the decision about whether to use it or not on any particular project should be an informed decision made on a case-by-case basis …not just because that’s the way things have always been done.
These sites help to inform that decision.
The full text of Jason’s great talk at this year’s CSS Summit. It’s a great read, clearing up many of the misunderstandings around progressive enhancement and showing some practical examples of progressive enhancement working at each level of the web’s technology stack
Many believe we should leave the term “progressive enhancement” behind and start anew, but why not educate developers, clients and stakeholders and change many of the misconceptions surrounding it? Changing the name won’t change anything unless we address the real fundamental problems we have when describing the underlying concepts.
Stuart writes up his thoughts on progressive enhancement following the great discussions at Edge Conf:
So I’m not going to be talking about progressive enhancement any more. I’m going to be talking about availability. About reach. About my web apps being for everyone even when the universe tries to stop it.
An in-depth look at where web components stand today, together with some very good questions about where they might be heading tomorrow.
More of this kind of thing, please!
Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.
This Async event at 68 Middle Street on June 11th looks like it’s going to good (and relevant to my interests).
And that’s why you always use progressive enhancement!
Your once-a-decade reminder from Kaela Nichols.
I like this nice straightforward approach. Instead of jumping into the complexities of the final interactive component, Chris starts with the basics and layers on the complexity one step at a time, thereby creating a more robust solution.
If I had one small change to suggest, maybe
aria-label might work better than offscreen text for the controls …as documented by Heydon.
This is a fascinating bit of web archeology: John has annotated the code from one of the earliest versions of jQuery.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
Because in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.
(Initially it required jQuery but I tweaked it to avoid those dependencies and Yuri very kindly merged my pull request—such a lovely warm feeling when that happens.)
Lea wasn’t happy with the lack of styling and extensibility of the datalist element, so she rolled her own lightweight autocomplete/type-ahead widget, and she’s sharing it with the world.
The engineering benefits of building websites with a layered approach.
Why, yes, I am talking about progressive enhancement yet again! Why do you ask?
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.
That’s Netscape 1.0n, released in December of 1994, running inside Windows 3.11, released in August of 1993, running inside of Google Chrome 39.0.2171.99 m, released about a week ago, on a Windows 7 PC, released in 2009.
But when it comes to trying to navigate the web with that set-up, things get a bit depressing.
The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.
I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.
Watch this space.
You Don’t Need jQuery! – Free yourself from the chains of jQuery by embracing and understanding the modern Web API and discovering various directed libraries to help you fill in the gaps.
The tone is a bit too heavy-handed for my taste, but the code examples here are very handy if you’re weaning yourself off jQuery.
A superb article by Josh on planning for progressive enhancement—clearly laid out and carefully explained.
I’m an advocate for progressive enhancement. Tom Dale is not. But even though we may disagree on that, there’s a lot to like in his sensible, balanced answers to some sensationalist linkbaity questions.
It’s not that the pace of innovation on the Web is slower, it’s just solving a problem that is an order of magnitude more challenging than how to build and distribute trusted apps for a single platform. As we saw on the desktop, it may take a few years to catch up to all of the capabilities of a native, proprietary platform, but in terms of the impact it will have on humanity, forgive me for not losing sleep if we have to wait a few years for it to arrive.
Angry, but true.
Don’t lock yourself into a comprehensive technology that may just die within the next few months and leave you stranded. With progressive enhancement you’ll never go wrong. Progressive enhancement means your code will always work, because you’ll always focus on providing a minimal experience first, and then adding features, functionality, and behavior on top of the content.
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
A really handy bit of code from Aaron for building a robust file uploader. A way to make your web-based photo sharing more Instagrammy-clever.
Those lovely people at Filament Group share some of their techniques for making data tables work across a range of screen sizes.
Personally, I’m all for more browsers. The more, the merrier.
Here’s a dystopian vision of the web in ten years time, where professional developers are the only people able to publish on the web.
My interest in rich client-side apps has almost entirely reversed, and now I’m more interested in doing good ol’ server rendering with the occasional side of progressive enhancement, just like we did it in 2004.
This post resonates with me 100%.
Scott’s trying to find out the best ways to load critical CSS first and non-critical CSS later. Good discussion ensues.
I really hope that this is the kind of usage we’ll see for web components: enhancements for the browsers that support them without a good ol’ fashioned fallback for older browsers.
A lovely little from Josh that allows you to draw shapes in a canvas element and then copy the resulting code.
I really like this interface idea from Brad that provides the utility of input masks but without the accessibility problems.
If you insist on having a fixed header on your site, please, please, please add this script to your site. I often use the spacebar to page down so this would be a life-saver.
Tom is running a Node School at 68 Middle Street on the evening of March 27th. I plan to attend and finally wrap my head around all this Node stuff.
An interesting pattern for handling complex data tables in responsive designs. It’s a desktop-down approach, but pretty smart.
Great stuff from James Wragg and the gang at Madgex: a way of lazy-loading ads for responsive sites without messing with the ad code.
Don’t get me wrong: jQuery is great, but for a lot of projects, you might not need 90% of the functionality it provides. So try starting with vanilla JS and only pulling in jQuery if and when you need it.
Like Drew, I’ve noticed some real hostility to the idea of progressive enhancement recently. Like Drew, I don’t really understand where this attitude comes from. It’s not like progressive enhancement prevents you from doing anything you would do otherwise: it’s just another way of approaching the way you build for the web.
I hope I’m wrong, but I suspect that some developers are letting their tools dictate their principles—the tail wagging the dog (where the tail is Angular, Ember, etc.).
An in-depth look at using icon fonts without any nasty edge-cases ruining your day.
Alas, it turns out that it’s reliant on user-agent string sniffing. I guess that’s to be expected: this isn’t something that can be detected directly. Still, it feels a little fragile: whenever you use any user-agent sniffing tool you are entering an arms race that requires you to keep your code constantly updated.
Another good ol’ rant from Tom. It’s a bit extreme but the underlying lamentation with the abandonment of progressive enhancement is well founded.
John shares his concerns about the increasing complexity involved in developing for the web.
Some excellent practical advice on progressive enhancement.
This is the talk I gave at the border:none event in Nuremberg last month. I really enjoyed it. This was a chance to gather together some thoughts I’ve been mulling over for a while about how we approach front-end development today …and tomorrow.
Warning: it does get quite ranty towards the end.
Also: it is only now that the video is released that I see I spent the entire talk looking like a dork with a loop of wire sticking out of the back of my head.
The authors of the Extensible Web Manifesto explain the thinking behind their …uh… thinking.
I despair sometimes.
Here’s a ridiculous Heath-Robinsonesque convoluted way of getting the mighty all-powerful Googlebot to read the web thangs you’ve built using the new shiny client-side frameworks like Angular, Ember, Backbone…
Here’s another idea: output your HTML in HTML.
Good luck getting that script updated for the thousands of sites and applications, you say to yourself, where it’s laying dormant just waiting to send devices the wrong content based on a UA substring.
I hate carousels, but if you’re going to have one, this progressively enhanced approach looks pretty good.
Go, Dan, go!
‘Sfunny, I was talking about just this kind of thing at An Event Apart today.
Executing console.log(“hello world”) or window.alert(2+5-20) brings immediate feedback, makes you feel as though you’re getting somewhere and that you are interacting directly with the computer as a programmer. For those of you old enough to own a Spectrum, C64 or Vic20 – BASIC (itself heavily derided) had the same benefit.
A terrific long-zoom look at web technologies, pointing out that the snobbishness towards declarative languages is a classic example of missing out on the disruptive power of truly innovative ideas …much like the initial dismissive attitude towards the web itself.
There’s something fundamental and robust about being able to request a URL and get back at least an HTML representation of the resource: human-readable, accessible, fault tolerant.
Oh, no! How horrid! Now Twitter won’t control the “user experience” of that widget!
Instead, the person who actually posted the tweets in the first place gets to decide how they should be displayed. Crazy idea, isn’t it?
A terrific case study in progressive enhancement: starting with a good ol’ form that works for everybody and then adding on features like Ajax, SVG, the History API …the sky’s the limit.
Jake casts a scrutinising eye over the way that browsers load and parse scripts …and looks at what we can do about it.
A terrific piece by Remy—based on a talk he gave—on when he uses jQuery and, more importantly, when he doesn’t. His experiences and conclusions pretty much mirror my own, but of course Remy is far more thoughtful and smart than I.
Really good stuff.
A handy one-stop-shop for tips on improving front-end performance.
I like the sound of the book that Chris is writing for Smashing Magazine. It sounds like a very future-friendly approach to front-end development.
Related to my rant on links that aren’t actually links: buttons that aren’t actually buttons.
This is handy: a look at which DOM properties and methods cause layout thrashing (reflows).