I'll begin with a fundamental philosophical question. I'll state my position, but move on, because in many ways it's a matter of belief, even of faith. You either effectively accept it or not.
To me, and I know to many others, the web is something more, indeed much more than anything which runs in a browser. It is much more than something simply built with the technologies of the web. It is something open, interoperable, something which aims to reach as much of the world as possible.
Approaches to developing for the web which are inherently antithetical to these core principles of the web, are to me, not really about the web.
But as I said, these are issues of belief, and not what I want to focus on today.
Let's think for a moment about what we build, when we build things for the web
We build traditional web sites, still I'd argue the vast majority of the content of the web. These are document-centric, though may, and indeed increasingly do include interactive, application-like content.
We also are now frequently building more application-like, less document-like experiences. This as we know has been going on for quite some time, but for most of that time, much of our application logic has resided on the server, with the client being a largely dumb interface.
In recent years (though examples of this, like Google Maps and Gmail go back quite some way) our client-side applications have become more sophisticated, aided in particularly by the ability to send data rather than entire pages to and from the server.
In the last 3 or 4 years, with the success of mobile application platforms like iOS and Android, we've seen the rise in the expectation that particularly mobile applications which run in the browser will be more native-like.
And in response to this, a particular architecture has emerged to build these kind of native-like applications, the Single Page Application
Developers building these SPAs have found that there are particular challenges to developing them with web technologies. In particular, performance, and the ability to work offline.
Before we continue, I'd like to note that even if all of these concerns are completely true, and that there are no alternatives to addressing the shortcomings of traditional web technologies for building SPAs, we are still only focussing on
I'm not saying the criticisms, the challenges that James has outlined are not real, not painful, and don't need solving.
It's understandable with all the frustration we have in solving a specific problem, we look to make something new, break the past's shackles, get it right this time.
But, I am suggesting we need to be very careful when looking to make profound changes to systems that have served us well for a long time now.
The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one
Fred Brooks,the Mythical Man Month
I fel this for two key reasons.
The trite one is, "the second system effect", as described by Fred Brooks in his classic of Software Engineering, The Mythical Man Month, which seems to apply very much to many of the suggestions we see in regards to how to do the web over.
The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one
Joni Mitchell, Big Yellow Taxi
The second, hopefully less trite response is rather than trying to solve a specific problem we have right now by throwing out many years of robust, solid, well thought out, well understood technologies and patterns, we should at least weigh very carefully what it is that will be gone if we just inject everything into the body.
Rich Hickey
I'm going to be quite up front here. Most of the rest of this presentation is inspired by a presentation by Rich Hickey, developer of the language Clojure, on the difference between something being easy and something being simple. You should find it and watch it. It's fantastic
(By the way, if you haven't picked up on the vibe yet, this is really a presentation about Software Engineering and the web.)
Hickey observes that we often conflate easiness with simplicity, but that these are quite profoundly different.
Simplicity (and it's obverse, complexity) is a feature of the thing we build, of our code. Is origins come from the latin meaning "single folded", as opposed to complexity, whose origins mean "many folded", or intertwined.
Easiness on the other hard is a subjective experience that we as developers have, unrelated to what we actually build.
Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.
Edsger Dijkstra
As Dijkstra notes, simplicity is hard work. But absolutely vital to building reliable systems.
It is not a daily increase, but a daily decrease. Hack away at the inessentials
Bruce Lee
There have been a great many quotations about simplicity, we all know many, from Einstein, Leonardo, Frank Lloyd Wright, but I'll leave the last word to the master, Bruce Lee. "It is not a daily increase, but a daily decrease. Hack away at the inessentials"
And I'm going to argue that we've got away with not paying enough attention to issues like complexity for too long when we build for the web, particularly on the client side for a number of reasons
In the world of traditional software development, you simply can't get away with complexity. Many systems are decades old. How many of the things we build have even lasted years?
For most of the history of the web, the tools we've used to develop with have been quite simple
But using these technologies isn't necessarily easy
So, over time we've added layers of technology and practice to help address the difficulty of developing for the web. Now, not all of these are "bad", but all of these add complexity.
We stumbled on UA sniffing, which made addressing the challenge of cross browser inconsistency easier to deal with.
We developed CSS hacks, to target different browsers with the same CSS code base. These are largely no longer needed, but add complexity to learning and maintaining code bases We added doctype switching, to allow us to develop a single CSS code base that would work in older browsers and newer ones which supported a standards based implementation of CSS and HTML.
all of these added a complexity that continues to impact years later. They make it harder to learn to be a web developer, they make our code larger, more difficult to read and to maintain.
but they did address what we considered at the time fundamental challenges. Pages needed to look as nearly identical as possible across all browsers.
This is a belief we now no longer hold strongly, and indeed as we address the challenges and opportunities of fragmented viewing contexts, from small mobile devices, to tablets, to laptops and desktops, to high resolution monitors to True HD TVs, we have rejected it.
All of this complexity, which still haunts us today was in a way about premature optimisation. Complexity has a long half life, and we need to be very careful about adding it to what we do.
With the rise of web applications around a decade ago, we encountered the challenge of inconsistent DOM implementations (we'd already discovered these problems years earlier with DHTML, but they re emerged as what we tried to do in the browser became more complex, and as browsers other than Internet Explorer gained some sort of traction).
Prototype, Dojo, Mootools, JQuery, and other monolithic JavaScript libraries emerged to help us manage the challenges of these inconsistent implementations. They also added inconsistent features to address the shortcomings of the DOM, and JavaScript. They made our lives easier. but they added complexity as well.
And increasingly meta toolsets (e.g. Yeoman. HTML5 Boilerplate, Mobile BoilerPlate) for helping us work with all these other toolsets
And to even use them you need Ruby on Rails, or Node.js set up
And this is just for client side development!
And I think we are travelling along a very slippery path of ever increasing complexity, in service of ostensible ease.
Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained…, infancy is perpetual. Those who cannot remember the past are condemned to repeat it
George Santayana
Because I'm old, and having been around the block a few times, I frequently come back to this observation by George Santayana
Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained…, infancy is perpetual. Those who cannot remember the past are condemned to repeat it
The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
Edsger Dijkstra, The Humble Programmer
The term "Software Crisis" was originally coined used at first NATO Software Engineering Conference. in 1968
Some years later, Dijkstra wrote
The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
Edsger Dijkstra, The Humble Programmer (EWD340), Communications of the ACM
You should read The Humble Programmer, it's not too long, and blends Dijkstra's personal story, with that of the infancy of our industry (Software Engineering) and deeper ideas about our wat it is we do.
As we saw, Dijkstra's counter intuitive response to this was to simplify (not to make things easier)
Separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program.
How did the software engineering world respond to this?
Perhaps the key principle, again a term coined by Dijkstra was the "separation of concerns"
"Separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity and encapsulation, with the help of information hiding.
Sound familiar? You know that thing some web folks have been banging on about since the 1990s? HTML for content, CSS for presentation, JavaScript for Behaviour Not only was this good practice, it was baked directly into core technologies of the web
When we use HTML, CSS, JS in the way they were designed, we get separation of concerns out of the box. For free.
For me, the first challenge for computing science is to discover how to maintain order in a finite, but very large, discrete universe that is intricately intertwined. And a second, but not less important challenge is how to mould what you have achieved in solving the first problem, into a teachable discipline: it does not suffice to hone your own intellect …, you must teach others how to hone theirs. … teaching yourself is discovering what is teachable.
you guessed it (yeah Dijkstra)
For me, the first challenge for computing science is to discover how to maintain order in a finite, but very large, discrete universe that is intricately intertwined. And a second, but not less important challenge is how to mould what you have achieved in solving the first problem, into a teachable discipline: it does not suffice to hone your own intellect …, you must teach others how to hone theirs. … teaching yourself is discovering what is teachable.
you guessed it (yeah Dijkstra)
That's not to say this is perfect, but to observe this is something that has worked well for a long time. We discard such things at our peril
when concerns were strictly separated - markup, presentation, behavior, then working on each in isolation, with specialized skills or areas of focus was far easier than having these concerns conflated
Maybe I'm old fashioned, but the ability to simply drop a file onto a browser, and refresh a window to rebuild is one of the pure joys of working on the web. As someone who comes from (and ocasionally still experiences) the edit compile run, cycle, the immediacy of developing for the web with nothing more than HTML, CSS and JavaScript files is frankly nearly miraculous
An don't get me started on installing and keeping up to date build tools, ruby gems, preprocessors, …
But ironically, here I've fallen into Rich Hickey's trap. I'm talking about ease, and process, not the simplicity or complexity of what we are building. So let's turn to this issue, and the impact of JavaScript everywhere on the artefacts we're building
As developers, we've long been frustrated with CSS errors and bugs. But at least the bugs are reproducible and deterministic. Same HTML + Same CSS gives the same DOM and values.
With CSS and HTML, discovering why this element has these properties set to these values is relatively straightforward. Our tools are well adapted to this problem, but the truth is the problem really isn't complicated.
Now, there are times when we will need to change the DOM programmatically. But I'd argue that we should resort to this only when it is essentially impossible to do with CSS and HTML alone.
And in order to make that decision, you really need to understand HTML and CSS well. Not just their syntax, but their essence.
to obtain the deepest benefit from learning a new language, you must learn to think in the new language, not just learn to translate your favourite programming language syntax and idioms into it.
(Not Dijkstra) Eugene Wallingford
to obtain the deepest benefit from learning a new language, you must learn to think in the new language, not just learn to translate your favourite programming language syntax and idioms into it.
(Not Dijkstra) Eugene Wallingford
In and of themselves, each of these innovations - CoffeeScript, SASS, various MVC frameworks, various tools may appear to bring much, and the case can be made for exchanging ease for some additional, but manageable complexity.
but as we pile innovation on innovation, we have an increasingly fragmented, non interoperable, fragile stack of technologies that rely on one another (I need node.js to use yeoman to give me ...
And there's a far bigger issue lurking than just debuggability.
With most websites, even the biggest, we continue to build, keep them alive, then rebuild completely
On the web, particularly the front end, we're used to throwing things away and starting over again with alarming frequency.
We build all kinds of one off, essentially disposable apps - throw it against the wall, see if it has traction.
And let's face it, in particular the "native like" SPAs we build often don't do all that much.
But as more and more of what was traditionally desktop software becomes web based, this luxury of build to dispose will soon pass.
It's well known in software engineering that rewriting applications, rather than incrementally improving them is highly corelated with negative outcomes. Some of the most significant applications of their day have essentially vanished because of massive rewrites.
In the Web, this is precisely what happened with Netscape, ceding Internet Explorer almost complete dominance of the browser for nearly a decade.
You might argue that ultimately Firefox demonstrates that this was the right response, but essentially that was a new application, not a new version of Netscape.
BTW, everything I'm talking about applies, I think not just to the issue of building everything directly with JS, it also applies to
languages which compile to JS solutions to the problems with CSS, like LESS and SASS
basically, what we are trying to do, is shoe horn into these languages, CSS and JavaScript ideas, idioms, principles that aren't core to them.
to obtain the deepest benefit from learning a new language, you must learn to think in the new language, not just learn to translate your favourite programming language syntax and idioms into it.
Remember Eugene Wallingford's observation
... to obtain the deepest benefit from learning a new language, you must learn to think in the new language, not just learn to translate your favourite programming language syntax and idioms into it.
And what we are really missing is one of the genuinely revolutionary aspects of developing for the web.
Its declarative nature (particularly HTML and CSS).
And what we are really missing is one of the genuinely revolutionary aspects of developing for the web.
And we want to throw all this out? Essentially for our own convenience?
Just to prove it's not all about JavaScript,
Are we insane?
Are we insane? I'm quite serious, are we fucking insane?
We now have
not to mention increasing the complexity of our field.
and for what?
This a is not a call to do nothing new, to not innovate in the areas I've been discussing.
Rather, it's a call to start appreciating the real nature of what we are doing
Increasingly, the web is the platform for enterprise, consumer, client server, mobile, pretty much all kinds of application
We have to grow up
While the web's long status among many as a toy, at best a publishing medium has also given us the upside of not having the harsh glare of rigorous criticism being turned on what we do.
And that's not going to last.
The things we build are going to be required to do more and more. Not just additional functionality, but last longer, be more robust and secure and performant.
We have to grow up, and take these challenges seriously
Now is not the time to turn our backs on these. To wish we could do the web over (again and again). To boil the ocean.
Good engineering is about making well researched and reasoned decisions about the tools and technologies we use, for the specific purpose we are using them for.
Which means really understanding these technologies
Not relying on tools and scaffolding and syntactic sugar.
And now is not the time to seek out easiness, at the price of the increasing complexity of the systems we build.
Save the contents of the field above to a file in the same folder as this one.