Tags: javascript

What is React?

I’m in a similar position to Remy:

I don’t use React. I don’t really gravitate towards larger frameworks, only because my daily work doesn’t require it, and I’m personally more interested in the lower level techniques and parts of the web and JavaScript.

But, like Remy, I’m interested in knowing what are the ideas and techniques embedded within large frameworks that will end up making their way into the web stack:

What I want to know is: what should I be taking away from React into my own continued evolution as a web developer?

There are some good responses in the comments.

cursory hack

Sorcery!

(well technically, JavaScript + canvas, but y’know, to-may-to, to-mah-to)

Creating An Accessible Modal Dialog

In the same vein as Hugo’s script, Ire walks through the steps involved in making an accessible modal window. Seeing all the thinking and code required for this really highlights the need for a way of making the document in the background inert.

Stuff I wish I’d known sooner about service workers

Some helpful “gotchas” that could save you some frustration if you’re starting out with service workers.

Progressive Enhancement for JavaScript App Developers | De Voorhoede

Build JS apps responsibly - cover your basics, render strategically and enhance into true apps.

sw-toolbox

If you’re going to dip your toes into the world of service workers, this handy library from the Chrome team is a good place to start.

Service worker meeting notes - JakeArchibald.com

Jake has written up the notes from the most recent gathering to discuss service workers. If you have any feedback on any of the proposed changes or additions to the spec, please add them. This proposal is the biggie:

We’re considering allowing the browser to run multiple concurrent instances of a service worker.

React Isomorphic Demo

It is possible to use React without relying completely on client-side JavaScript to render all your content—though it’s certainly not the default way most tutorials teach React. This ongoing tutorial aims to redress that imbalance.

Besides the main benefit of server rendering giving faster page loads, it also enables large amounts of the site to run without JavaScript. There are many reasons why you would want this, but my personal reasons are that it allows you to completely drop support JavaScript in older browsers, but still have the site function.

Adding Service Worker to a simple website - rossta.net

A nice little walkthrough of a straightforward Service Worker for a content-based site, like a blog.

The Service Worker Lifecycle

The life cycle of a Service Worker—with all its events and states—is the one bit that I’ve never paid that much attention to. My eyes just glaze over when it comes to installation, registration, and activation. But this post explains the whole process really clearly. Now it’s starting to make sense to me.

Teaching web development to design students (Phil Gyford’s website)

Phil’s write-up of teaching web development to beginners is immensely valuable in the run-up to the Codebar workshop that Charlotte is running this weekend. This bit gave both us a real “a-ha!” moment:

It only occurred to me at the end that I should have encouraged the students to try and fix each other’s bugs. If anyone had problems I’d go round and help people and often it’d be a little typo somewhere. Helping each other would acknowledge that this is entirely normal and that a second pair of eyes is often all that’s needed.

EmberCamp London Keynote 2016 // Speaker Deck

I really, really like what Ember is aiming for here:

First, we deliver the raw content, ensuring those on slow connections or without JavaScript get they’re after as soon as possible. Next, we load the minimum set of JavaScript needed to interactivity for that page, keeping transfer time and parsing time low. Once the user has an interactive page, we can start preemptively loading other parts of the application, including frequently-accessed data.

That’s how you get the holy grail of resilience and performance:

Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.

I sincerely hope other frameworks are paying attention to this layered approach.

Oh, and I also like this observation:

There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.

Rivets.js — Lightweight and powerful data binding + templating solution for building modern web applications

Mark recommended this JavaScript library as lightweight alternative to Vue.js …itself a kind of lightweight alternative to React. Basically I’m interested in the data-binding stuff.

Things to Know (and Potential Dangers) with Third-Party Scripts | CSS-Tricks

Third-party scripts can provide powerful functionality, but they also bring risks to privacy, security, performance, and page behavior.

» Service Workers at Scale, Part II: Handling Fallback Resources Cloud Four Blog

This ongoing series about the nuts’n’bolts of implementing Service Workers is really good. This one is great for getting to grips with the cache API.

Enhancing Optimistically | Filament Group, Inc., Boston, MA

I love the thinking that Scott puts into all aspects of building on the web. Here, he outlines a really robust approach to cutting the mustard for progressive enhancement.

Making your JavaScript Pure · An A List Apart Article

I really like this piece by Jack. All the things he’s talking about—pure functions and referential transparency—are terms I was previously unfamiliar with …but the concepts smell familiar. It’s good to have terminology (and reasoning) to apply to the way I structure my JavaScript.

Progressive Enhancement and Modern JavaScript ― Caolan

I think JavaScript frameworks have been blinkered to the needs of many developers (most websites are not SPAs or run by Node, nor should they be) for too long. We need to find a way to apply the lessons of modern frameworks to the rest of the web - it would be sad if everyone had to run JavaScript on their server and good-old resilient HTML was considered only as a fallback.

Introducing Multirange: A tiny polyfill for HTML5.1 two-handle sliders | Lea Verou

You’re supposed to be able to create two-handled sliders with input type="range" but the browser support isn’t there yet. In the meantime, Lea has created a nice lightweight polyfill.

turbolinks/turbolinks: Turbolinks makes navigating your web application faster

I really, really like the approach that this JavaScript library is taking in treating Ajax as a progressive enhancement:

Turbolinks intercepts all clicks on a href links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using XMLHttpRequest, and then renders the HTML response.

During rendering, Turbolinks replaces the current body element outright and merges the contents of the head element. The JavaScript window and document objects, and the HTML html element, persist from one rendering to the next.

Here’s the mustard it’s cutting:

It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.

This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.

Vanilla List: The Vanilla Javascript Repository

Here’s a handy directory of scripts that set out to solve one problem without any dependencies. Useful for poking at, picking apart, and learning from.

Developing Dependency Awareness – Smashing Magazine

A typically superb article by Aaron. Here, he breaks down a resilient approach to building for the web by examining the multiple ways you could add a button to a page. There’s a larger lesson here too:

We don’t control where our web-based products go or how our users access them. All we can do is imagine as many less-than-perfect scenarios as possible and do our best to ensure our creations will continue to do what they’re supposed to do. One of the easiest ways to do that is to be aware of and limit our dependencies.

Building Web Apps for Everyone - O’Reilly Media

Here’s a fantastic and free little book by Adam Scott. It’s nice and short, covering progressive enhancement, universal JavaScript, accessibility, and inclusive forms.

Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.

Did I mention that it’s free?

Responsive Product Comparison Table

Here’s a nice little pattern from Dave—showing data tables one column at a time on smaller screens.

Why Javascript Development is Crazy

The state of Javascript development is overwhelming and confusing because everyone is overengineering their apps by default without even realizing it.

Node: Up and Running

One of these days I’m going to step outside of my PHP comfort zone and actually build something in Node. One of these days. When I do, this book looks like a good place to start (and the online version is free).

simpl.info

This is a very handy resource—a collection of minimum viable implementations of HTML5 features and JavaScript APIs.

NPM & left-pad: Have We Forgotten How To Program? | Haney Codes .NET

Not to sound all “Get off my lawn, kids!” but I think there might be something to this. When you’re requiring hundreds of dependencies to do little tasks that you should be able to code yourself, something’s not right.

But, for the love of all that is programming, write your own bloody basic programming functions. Taking on dependencies for these one-liners is just nuts.

That said, you don’t want reinvent hundreds of wheels either (as most of the comments point out). There’s a balance to be had.

Thomas Fuchs proposes a middle ground for JavaScript.

The copy & paste guide to your first Service Worker

Minimum viable Service Worker tutorial. Copy, paste, and don’t ask questions.

Also:

Exhibit A

Exhibit B

Introduction to Ember FastBoot by Tom Dale on Vimeo

I’m so happy that Ember is moving to a server-side rendering model. Not only that, but as Tom points out here, it’s crucial that the server-side rendering is the default and the client-side functionality than becomes an enhancement.

Instagram-style filters in HTML5 Canvas | Viget

Una’s [Instagram filters in CSS}(https://github.com/una/CSSgram) are great, but the browser support for CSS filters isn’t as good as, say, the browser support for canvas. Here’s a clever bit of scripting to polyfill filters using canvas.

Introducing A11y Toggle

Here’s a bit of convergent evolution: Hugo’s script is similar to what I wrote about recently.

He also raises a point that Kevin mentioned:

I would like to investigate on the details and summary elements as they are basically a native implementation for content toggles.

For some reason details never got much browser love, even though it’s clearly paving a well-trodden cowpath.

Widespread XSS Vulnerabilities in Ad Network Code Affecting Top Tier Publishers, Retailers - Randy Westergren

An a revelation that comes as a shock to absolutely no one, the JavaScript injected by ad networks can be used as a vector for attack.

This industry-wide problem serves as a great example of how 3rd-party components can compromise the security of an otherwise secure site.

One more reason to install an ad blocker.

An update (March 2016) on the current state & recommendations for JavaScript …

Making web apps? Care about SEO? Here’s Google’s advice:

Use feature detection & progressive enhancement techniques to make your content available to all users.

A Year Without jQuery

In many ways, moving to vanilla JavaScript highlights the ugliness of working with the DOM directly, and the shortcomings of native Element object — shortcomings which Resig solved so incredibly eloquently with the jQuery API.

Having said that, the lessons I’ve learned over the last year have made me a better developer, and the tools built in the process have opened my eyes and given me enough confidence and understanding of vanilla JavaScript that the only scenario where I would personally consider using jQuery again would be a project needing IE8 support.

Maybe we could tone down the JavaScript / fuzzy notepad

Accept that sometimes, or for some people, your JavaScript will not work. Put some thought into what that means. Err on the side of basing your work on existing HTML mechanisms whenever you can.

If you’re going to override or reimplement something that already exists, do some research on what the existing thing does first. You cannot possibly craft a good replacement without understanding the original.

Remember that for all the power the web affords you, the control is still ultimately in end user’s hands.

Dyslexia

An attempt to convey the experience of (one kind of) dyslexia through code.

EnhanceConf - Stefan Tilkov - How to embrace the browser - YouTube

The videos from EnhanceConf are started to go up already. Stefan’s talk really struck me—all the talks were great but this one had the most unexpected insight for me. It really clarifies a lot of ideas that I’ve been trying to articulate, but which Stefan crystalises by taking the long-zoom view.

hunt

This looks like it could be quite a handy (and relatively lightweight) script for attaching events—like animations—to an item’s visibility, so the events only trigger when the item is scrolled into view.

Frontend Design | Brad Frost

Well, this pretty much sums up the front-end team at Clearleft:

Frontend design involves creating the HTML, CSS, and presentational JavaScript code that makes up a user interface.

I’ve often said that at Clearleft, development is always in the service of design. And like Brad, I often find myself defining that work by what it isn’t:

They understand UX principles and best practices, but may not spend their time conducting research, creating flows, and planning scenarios

They have a keen eye for aesthetics, but may not spend their time pouring over font pairings, comparing color palettes, or creating illustrations and icons.

They can write JavaScript, but may not spend their time writing application-level code, wiring up middleware, or debugging.

They understand the importance of backend development, but may not spend their time writing backend logic, spinning up servers, load testing, etc.

Making A Service Worker: A Case Study – Smashing Magazine

Lyza has written an excellent deep dive into Service Workers, complete with code.

I’m really chuffed that she gave me a shout-out to my exhortation:

So if you decide to play around with Service Workers, please, please share your experience.

By the way, I like her point about this being a good opportunity to use ES6/ES2015/HipsterScript features like arrow functions in the browser: any browser that supports Service Workers also supports the latest JavaScript.

The accessibility stack: making a better layer cake » Simply Accessible

A great description of a solid architectural approach to building on the web (and not just for accessibility either).

Introducing Soundslice offline mode | The Soundslice Blog

Adrian documents how he’s using Service Workers on Soundslice. I could imagine doing something similar for The Session.

JavaScript web apps considered valuable · molily

A response to a rant I linked to recently.

The solution for bad JavaScript web apps is not to abandon them altogether, but to make better ones.

I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.

JavaScript is the best technology to build excellent interactivity in the browser. Still, the most important skill of a client-side JavaScript developer is to know when not to solve a problem with client-side JavaScript. It’s always more robust to solve a problem further down in the stack.

The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.

Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.

Don’t tell me what my browser can’t do! by Christian Heilmann

A great piece by Christian on taking a responsible, customer-focused approach to building on the web.

You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button.

Yes, this is an argument for progressive enhancement. No, that does not mean you can’t use JavaScript.

You can absolutely expect JavaScript to be available on your end users computers in 2016. At the same time it is painfully naive to expect it to work under all circumstances.

Why I hate your Single Page App by Stefan Tilkov

A linkbaity title for a ranty post. But it’s justified.

My point is that from an architectural perspective, most single page apps are the result of making the wrong choices and missing important opportunities.

Feature.js

A lightweight alternative to Modernizr. It doesn’t add classes to your markup so it’s up to what you do with the results of any test.

It’s perfect for cutting the mustard on a case-by-case basis.

Delicious Changes | The Official Delicious Blog

The first big change you’ll notice is our transition from the javascript front-end framework that has been powering the content at https://www.delicious.com. The engineers who crafted this version of the site are incredibly talented, and their code is amazing. It’s beautiful and powerful, but it has posed several significant challenges for us. For example, the search engines have a real problem reading our content, hindering users’ efforts to use Google or Bing to find what they’re looking for on Delicious.

VerbalExpressions/JSVerbalExpressions

Regular expressions are my kryptonite so I can definitely imagine using the PHP port of this plain English syntax.

Reimagining Single-Page Applications With Progressive Enhancement – Smashing Magazine

Some really great thinking here by Heydon on how to make single page apps but using HTML for the views instead of relying on client-side JavaScript for the rendering. He explains the code he’s using, but what really matters here isn’t the specific solution; it’s the approach. Smart!

The Problem with Progressive Enhancement by Alex Lande

I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.

Specifically:

  1. Performance—”Progressively enhanced behaviors like using links that point to real URLs, or server-side form submission handling, allow users to perform important actions before JavaScript loads.”
  2. Resilience—”If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper.”
  3. Business, Business, Business.

ScrollReveal

A nice self-contained script for animating items into view as the document scrolls.

I’d like be interested to hear what Graham thinks of this code—he’s my go-to person for smooth scroll-based animations.

(I’m very confused by the tagline for ScrollReveal—”Easy scroll animations for web and mobile browsers”—eh? Mobile browsers are web browsers …”web” is not a synonym for “desktop”.)

JavaScript: 2015 in Review

Use a framework if you must but never presume it’s viable over the long-term. Newer and better alternatives will appear before you’re half-way through your project. Never forget frameworks are an option — you don’t have to use one.

getify/You-Dont-Know-JS

Graham—whose opinion I trust completely—has been raving about these books. And Kyle Simpson is a super-smart guy. So I reckon I should make these JavaScript tomes my holiday reading.

Photo upload and progressive enhancement for FixMyStreet / mySociety

Matthew describes a very nice bit of progressive enhancement for drag’n’drop file uploads (similar to the CSS Tricks article I linked to recently).

It uses the Dropzone JS which looks like it aligns nicely with the progressive enhancement approach.

Interactive Storytelling | Codrops

I think this might be the most tasteful, least intrusive use of scroll events to enhance a Snowfallesque story. It’s executed superbly.

You can read all about the code. Interestingly, it’s using canvas to render the maps even though the maps themselves are being stored as SVG.

(There’s a caveat saying: “This is a highly experimental project and it might not work in all browsers. Currently there is no IE support.” I don’t think that’s true: the story works just in IE …that browser just doesn’t get the mapping enhancements.)

Simplified JavaScript Jargon

An A-Z of JavaScript jargon (although some of the “explanations” could do with de-jargonifying themselves).

Autumn-Earth/serviceWorker.js

Here’s a really nice addition to my Service Worker script—opportunistically add non-critical CSS, JavaScript, and fonts to a cache as you go.

Progressive Enhancement—Ain’t Nobody Got Time for that | GlückPress

Two sides of a debate on progressive enhancement…

Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:

If your content website breaks down from JavaScript issue — it is broken.

Joe Hoyle disagrees:

Unlike Rarst, I don’t value progressive enhancement very highly and don’t agree it’s a fundamental principle of the web that should be universally employed. Quite frankly, I don’t care about not supporting JavaScript, and neither does virtually anyone else. It’s not that it doesn’t have any value, or utility - but in a world where we don’t have unlimited resources and time, one has to prioritise what we’ll support and not support.

Caspar acknowledges this:

I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).

But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:

Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.

See also: Mike Little’s thoughts on progressive enhancement and accessibility.

Cutting the Mustard Revisited — sixtwothree.org

Jason revisits some cutting-the-mustard techniques, as started by the BBC and refined by Jake. This kind of feature-testing is indispensable for progressive enhancement.

Personally though, I’m still uncomfortable with the assumptions baked into equating particular features with particular browsers …maybe I’ve known PPK too long.

I much prefer to cut the mustard on a case-by-case basis by feature testing the actual APIs I’m about to use in a script. I realise that might be harder to scale, and it’s more verbose, but it’s the only way to be absolutely sure.

The “Blur Up” Technique for Loading Background Images | CSS-Tricks

Quite a few moving parts in this technique from Emil, but it’s very clever.

Bliss.js — Heavenly JavaScript!

A small little JavaScript helper from Lea.

The helper library for people who don’t like helper libraries.

Universal React ◆ 24 ways

I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:

  • The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
  • In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
  • The next time a user clicks, rather than being sent to the server, the client-side app is in control.
  • If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.

YES!!!

Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Progressive enhancement needs better advocacy • Zetafleet

A rousing call to arms for progressive enhancement. I agree with the sentiment, but I’m less comfortable making assumptions about the reasons why developers don’t use progressive enhancement:

However, what’s actually happening is that “universal access to content” is being subversively replaced with “universal access for a limited subset of users that I care about”.

Honestly, I think that plenty of developers just aren’t thinking about it—especially if they’re relying on a particular tool or framework to save them time and effort (which is not a crime). So that’s why I agree with the title of this piece: let’s talk about this more; let’s make sure developers understand what they’re doing when they make JavaScript a requirement for basic functionality.

I particularly like the point in here about content blockers like NoScript:

In fact, it’s probably more likely that a user will try browsing the Web today without scripting than at any other time since the 1990s.

Performance Calendar » Reducing Single Point of Failure using Service Workers

This is a nifty use of Service Workers—using a cache to mitigate unresponsive Content Delivery Networks.

The stuff in here about Promise.race is particularly useful for “lie-fi” scenarios: instead of thinking about the network connection in a binary way (either it’s available or it isn’t), considering the scenario of a crappy network connection seems more realistic.

Drag and Drop File Uploading | CSS-Tricks

This is a terrific example of progressive enhancement in action: going from a simple file input to a lovely interactive drag’n’drop interface.

The code uses jQuery but it could be easily adapted to vanilla JavaScript, and anyway, it’s not so much the code that matters, it’s the approach.

Blocked! - O’Reilly Radar

Following on from that Wired article I linked to about disabling JavaScript, Simon St. Laurent brings in another factor—content blockers on iOS:

Apple offers its users the power to turn off much of the Web: fonts, styles, scripts, and more.

He rightly points out that the answer to building a robust, resilient web has been here all along:

Turning off web fonts, CSS, and images will frustrate designers and limit user interface possibilities, but turning off JavaScript might mean that we have to reconsider the architecture of our applications. Without JavaScript, the Web returns to its foundations of HTTP requests returning pages, with links and form submissions as the backbone of application structure.

HTML5: The New Flash

A new presentation from the wonderfully curmudgeonly Steven Pemberton, the Nosferatu of the web. Ignore the clickbaity title.

I don’t agree with everything he says here, but I strongly agree with his preference for declarative solutions over (or as well as) procedural ones. In short: don’t make JavaScript for something that could be handled in markup.

This part really, really resonated with me:

The web is the way now that we distribute information. We will need the web pages we create now to be readable in 100 years time, just as we can still read 100-year-old books.

Requiring a webpage to depend on a particular 100-year-old implementation of Javascript is not exactly evidence of future-thinking.

I Turned Off JavaScript for a Whole Week and It Was Glorious | WIRED

When someone’s web browsing experience can be so drastically improved by simply switching off JavaScript, you know it’s time for an intervention with web developers.

This is our fault. Client-side JavaScript gave us enormous power and we abused that power.

Aerotwist - The Cost of Frameworks

Here’s Paul’s write-up of his excellent talk at FF Conf.

Previously I’ve used the term “developer convenience” when describing the benefits of using a framework. Paul uses the term “ergonomics” to describe those benefits. I like that. I worry sometimes that the term “developer convenience” sounds dismissive, which isn’t at all my intention—making our lives as developers less painful is hugely important …but it’s just not as important as improving the lives of the end users (in my opinion …and Paul’s).

As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet. Frameworks come and go, it just seems to be the ebb and flow of the web, and, as I said above, they do contribute ideas and patterns. But if you ever find that the one you use no longer works for you, or has a bug that remains unfixed, being able to understand the platform that underpins it will help enormously.

You should use [insert library/framework], it’s the bestestest! / Paul Lewis - YouTube

This was one of favourite talks at this year’s FF Conf. But I will readily admit there’s a hefty dollop of confirmation bias in my enjoyment.

Best viewed with - Velocity Amsterdam 2015 // Speaker Deck

Are we doomed to see history repeat itself? With the amount of client-side MVC frameworks and the upcoming implementation of the ES6 syntax, will we soon be seeing a repeat of the “browser wars.” Will more websites only work in a select number of browsers with the capabilities to run their code?

An Offline Experience with Service Workers | Brandon Rozek

A great walkthrough of setting up a Service Worker for a blog. The code is here but more importantly, as Brandon says:

I wouldn’t be able to implement this myself if it wasn’t for some of the awesome people I mentioned earlier sharing their experience. So share, share, share!

Moodboard — a small JavaScript library for presenting image moodboards on the web

A lovely little script from Nat to create a nice montage of images. It works by progressively enhancing a regular series of images in the markup.

Making a Simple Site Work Offline with ServiceWorker | CSS-Tricks

Another clear explanation by Nicolas of using Service Worker, this time on CSS Tricks.

The State of JavaScript on Android in 2015 is… poor - Discourse Meta

There’s something quite Kafkaesque about reading through the comments on Jeff Atwood’s request for an alternative to Ember.js …for rendering some text on a screen.

Every now and then someone pipes up with “server-rendered HTML?”, there’s a pause, and then a response of “naahhhhh.”

Surreal.

Official Google Webmaster Central Blog: Deprecating our AJAX crawling scheme

It’s official: hash bang URLs are an anti-pattern, and if you want your content indexed by Google, use progressive enhancement:

Since the assumptions for our 2009 proposal are no longer valid, we recommend following the principles of progressive enhancement.

Responsive News — AMP and Responsive Web Design

Tom’s thoughts on what AMP means for developers and publishers. He was initially sceptical but now he’s cautiously optimistic. Like me, he’s hoping that AMP can force the hand of those third-party advertisers to get their act together.

Publisher’s development teams are very capable of creating fast experiences for mobile users, but they don’t have the clout to coordinate all the additional cruft that is added to the page. However, if all the different publishers dev team’s got together and put their weight behind a single implementation, then we can force third parties to change their habits.

A fictional conversation about progressive enhancement

So a web app is defined as a system that requires the JavaScript excesses for it to work. And the argument for the JavaScript excesses is that we need it to build web apps. That sounds a teeny bit circular to me.

180: Panel on “Inline Styles” - ShopTalk on Huffduffer

Shop Talk Show is trying a new panel format. They got me on to join in the discussion about adding inline styles with JavaScript instead of using Cascading Style Sheets.

Confidence and Overwhelm

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.

Dave Shea – – beyond tellerrand DÜSSELDORF 2015 on Vimeo

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.

The ethics of modern web ad-blocking – Marco.org

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.

This won’t be a clean, easy transition. Blocking pop-ups was much more incisive: it was easy for legitimate publishers to avoid one narrowly-useful Javascript function to open new windows. But it’s completely reasonable for today’s web readers to be so fed up that they disable all ads, or even all Javascript. Web developers and standards bodies couldn’t be more out of touch with this issue, racing ahead to give browsers and Javascript even more capabilities without adequately addressing the fundamental problems that will drive many people to disable huge chunks of their browser’s functionality.

Amen!

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.

You might not need jQuery plugins

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.

Designing with Progressive Enhancement — sixtwothree.org

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

It’s time to progress

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.

as days pass by — Availability

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.

Practical Questions around Web Components - Ian Feather

An in-depth look at where web components stand today, together with some very good questions about where they might be heading tomorrow.

Tiny two way data binding

I really like this approach that Remy is taking: write some code to one thing, and just one thing. I much prefer my JavaScript to be small pieces loosely joined rather than monolithic.

More of this kind of thing, please!

How we built the new gocardless.com — GoCardless Blog

A classic example of the holy grail of web performance and robustness—start with regular HTML sent from the server, enhance once it’s in the browser …if the browser is capable of it. In this case, it’s using JavaScript (React) on both the server and the browser.

The JavaScript-Dependency Backlash: Myth-Busting Progressive Enhancement

Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.

Killer page load performance – Async

This Async event at 68 Middle Street on June 11th looks like it’s going to good (and relevant to my interests).

Everyone has JavaScript, right?

And that’s why you always use progressive enhancement!

screen shot from the TV series Arrested Development, showing a character whose catchphrase began 'And that's why...'

Progressive enhancement with handlers and enhancers | hiddedevries.nl

I like this declarative approach to associating JavaScript behaviours with HTML elements.

Keeping it simple: coding a carousel by Christian Heilmann

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.