Angela P Ricci

Small causes can have large effects. We all know the popular interpretation of the Butterfly Effect: when a butterfly flaps its wings in Europe, for example, it will cause an earthquake in Hawaii.

The Butterfly Effect relies on the chaos theory that says that when we have a sensitive dependence of initial conditions, then a small change can result in large differences in a later state — “ Visual Analysis of Nonlinear Dynamical Systems: Chaos, Fractals, Self-Similarity and the Limits of Prediction”, Boeing, G. 2016.

If we look at the lifetime of a web project, where would reside its sensitive dependence? Because we know for experience that, in these cases, chaos may happen. Most of the time we're just avoiding the earthquake, putting all our efforts in fixing bugs; and sometimes our project presents such “large differences” that the only way to stop the earthquake would be to start all over again.

But, why is that? Where resides the sensitive dependence in a web project? Which initial conditions we should care for?

A web site or application should work as a watch, with all its marvelous gears fitting and working together in a perfect and synchronized ballet. Or, we know that's not what usually happens; we know that most web technologies have sensitive dependences, and that, of course, we cannot predict chaos; but, what if I tell you that the most sensitive dependence of our web projects could be spotted? What if I tell you that some initial conditions are often ignored and taken for granted, or even despised? What if I tell you that we can tame chaos simply by writing a proper, standard and semantic HTML?

You may not believe it, but the eye of the tempest of a site resides mainly on the initial conditions of our HTML. And yet, we always have a “good reason” to not spend time with HTML. Most of the times we say to ourselves that we'll deal with it later. But later is far too late.

It is the quality of our HTML markup that will consolidate — or jeopardize— the dependences of the CSS and Javascript. If we understand and know what we're doing, if we understand what HTML is about, we can avoid a lot of headaches and even earthquakes.

Like the Butterfly Effect theory, a bad HTML markup will forcefully, I mean forcefully, engender bad and prolix CSS, and it will demand a lot of Javascript to do what HTML and the browser would do for you with no effort.

A bad, un-semantic markup will not only lead to a fragile structure, but it will also demand extra and useless efforts to assure web accessibility, compatibility and portability. And, we all know, we cannot ignore any of those points. Not anymore.

Our site, your web application is accessed by an URL — fortunately — and we know that today our users are able to access our content and functionalities from hundreds of different devices and browsers, and it is up to us to guarantee that they will do it in the best possible conditions.

We're living exciting times: powerful internet connections, powerful devices; Internet Explorer is no more, and the web standards got up from their sleep to become an “always evolving” thing. HTML and CSS are now living standards! We have today amazing APIs, and yes, we want to try them all, we want to use the latest web technologies — enough of feeling frustrated.

Well, guess what? We can do it. There's nothing holding us down, as long as we acknowledge that not every user will access our site using the latest iPhone, with a 4G connection, or even that she will be ok to wait more than 15 seconds for our page to load — yes, bad HTML means bad performance either.

Performance is not just a cool goal. It is about our users (and their money!), it is about ecology, it is about satisfying our clients with improved conversions.

We can stay on the edge and still respect users that are not, just by following a simple approach: progressive enhancement.

Progressive enhancement allows us to give each user a satisfying access to our content and functionalities, regardless of the conditions they have at their disposal. Start with your basic functionalities, with plain and standard HTML, and then enhance from there.

We're jumping too quickly to the choice of tools and frameworks, far before knowing what the functionalities will be. We're already putting weight in our applications even before understanding what they will need, before asking ourselves how we can do it in the simplest possible way, using the existing web foundations. If we start with good, plain HTML, we won't need to add extra information and extra resources to emulate native behaviour.

Quoting John Allsopp, “Foundations matter”. We have to understand the core web technologies like HTML and CSS before bloating our applications with complex, sometimes useless, frameworks and layers like Sass, for example.

If you don't understand CSS well enough to understand what your pre-processor is reducing, is it good engineering practice to even use it?

— We have to talk about Javascript, John Allsopp

Web is about inclusion, universality, and we're doing everything to cast people out.

Let's change it! Let's create, from the beginning, truly accessible and fault-tolerant web applications. Let's stop trying to “make accessible” an already bloated markup, adding ARIA roles and attributes everywhere just to “satisfy” some legislation. Let's care.

As we're in the metaphor vein, think of your HTML code as the foundations of your house. You can change once a year the wallpapers, you can paint your windows each three years, you can change all the furniture every month if you like, but you cannot easily modify the foundations of your house, not without big efforts, lots of time, and lots of money.