Feature-first Web Development Explained

This is a breakdown of principles and concepts in regards to Feature First Websites: Graceful Degradation - It’s simple, we kill Progressive Enhancement. A few heads exploded from that article, not entirely sure if those heads read the entire article before exploding but either way lets explore the concept.

A suggestion was made to do a follow up explaining graceful degradation and progressive enhancement. Plenty of resources exist on these topics, may be worth checking out “Regressive Enhancement”, which is quite tightly knitted to development via progressive enhancement.

tl;dr

What is feature-first?

Feature-first is a concept that separates a web site/ app’s presentation into two, “Legacy State” & “Present State”, by targeting browsers with the latest supported API features, and by generalizing browsers that do not qualify for “Present State” to be light weight, and performance oriented.

Feature-first is a future-proof concept, NOBODY LOSES.

What “Feature-first” is NOT!

• Feature-first refers to API features not functionality. There is no interference with stakeholder requirements in regards to functionality or anything to do with user stories.
• The feature-first approach doesn't exclude users. One purpose of the legacy state is to set minimal-performance to a baseline.
• Feature-first doesn't affect accessibility, feature first has little affect on how once chooses to make a site accessible. Regarding performance it is likely to have an enhancing affect in terms of usability.
• A feature-first website is one with two faces, not two websites. We have more tools than ever now to make separate states of presentation with little duplication, effectively (e.g., via templates).

The Feature-first Methodology

Explicit principles

• Define the “Present State” by features: Use modern browser APIs necessary for the future-proof project, (The APIs should ideally be supported by the majority of evergreen browsers in the least).
• Separate state by “feature detection”: Use a reliable feature detection method i.e. via Modernizr to separate legacy from present state.
• Only detect features in use & relative features: Under no circumstances should non-related or depreciating features be used to outcast specific browsers or legacy users.
• Legacy CSS should prioritize primitive systems: The style of the legacy state is not expected to replicate the present state, but ideally share resemblance. Any CSS framework in use should be explicitly light weight & not dependent on JS.
• For the legacy state, “if” you can produce content & or functionality without JavaScript on the client side, then don’t use JavaScript. The “if” is explicit, the execution is by discretion.
• Use modules & component before entire libraries, when plausible (common sense).

Implicit principles

• Use user-agent conditions with feature detection to outcast unsupported legacy browsers, from the declared feature detection: I urge you to understand why. In a nutshell user-agent detection (browser sniffing) is unreliable for supported browsers (browser versions that are still being revised, bug-fixed, updated etc). The feature-first methodology does not advocate user-agent detection for supported browsers, but does for browsers & versions with discontinued support that may qualify for the present state. User-agent detection is also “conditionally” unreliable to some extent, that’s perfectly fine, as it doesn't need to be relied upon.
• Minimal media & animation content: The legacy state should feature little to zero animations and only necessary media content.
• Generalise user performance: Use legacy browser versions to assume a general legacy performance. This may be really tough for some developers to wrap their heads around because we are satisfied with sheltered test results in cosy test environments . Feature-first if done right, solves many untold problems that users in the real world with serious things to do huff and puff about.

WHY?

• Future-proof: Building without the constraints of legacy systems increases last-ability.
• Upgrading: The cost (time & money) of upgrading to future libraries & framework versions are reduced (self explanatory).
• Websites are too bulky, especially for people with old systems. Users with older software/ hardware generally are more focused on necessities.
• Use the latest browser APIs in production: Developers are enabled to use APIs that may not be feasible with progressive enhancement in a clean manner.
• Encourages vendors to be more consistent amongst counterparts.
• Progressive Enhancement is destructive for the web: Progressive enhancement as a methodology is great, people have been using similar techniques for centuries in the physical world. Progressive enhancement on the web was necessary until now, due to the domination of auto-updating browsers.
• Legacy browsers are dying browsers: Maybe FF is not right for your target demographic (today), but despite business requirements, It’s the winning strategy as legacy users are decaying. From a broader perspective progressive enhancement is partially responsible for the lack of desire to upgrade browsers.
• Evergreen browsers: With feature-first, the timing is what is imperative. The emergence of evergreen browsers is one reason feature-first is ready to be unleashed.
• It is inevitable: Despite if you agree or disagree, It doesn't matter, some kind of feature-first approach will be a better fit for the direction of the web, progressive enhancement can not keep up with the new rapid development deployment methods i.e., evergreen/ forever-green browsers, the question is when and how rather than should.

Hopefully this explains my ideology regarding why we should try to kill Progressive Enhancement. I totally stand by that notions in regards to web development. It may take some a while for the bigger picture to sink in.

Should you drop everything and develop with graceful degradation via Feature-first? Just use your brain Marty Mcfly, weight out the pros and cons. At the end of the day you should always be hungry to adopt the approach that is “more advantageous” for the changing world ahead when feasible.

Confused?… maybe the definitions will help.