Web development is not what it used to be. It has undergone so many transformations and changes that it is pretty confusing to keep up with what is going on. My main problem right now is that as someone working for a player that provides the world with a browser and is involved in defining the future technologies of the open stack I wonder who our audience is.
There is no one “web developer”
I am a web developer. I build web products and I love how simple it is to create meaning with semantic HTML, interactivity with JS and make things beautiful and more intuitive with CSS. I come to this from a developer angle, as I am a terrible designer. This makes me an endangered species.
In the last few years web development has gotten a lot more players. Moving JS to the server side and the advent of Websockets, Node.js and technologies like Phonegap and Emscripten, and yes, even GWT allow a lot more people who never bothered with the web to build web apps. And this is damn good as different knowledge can lead to better and more scalable solutions. It also means we can deliver faster to a market that is hungry for more and more products. And it also forces us to re-think some of our ways.
I’ve talked to people who are amazing in HTML/CSS/JS and feel the need to learn at least one server-side language or at least get into patterns to understand what their colleagues in the web development team are talking about. It seems the shift from web sites to apps means that we need to shift much more to traditional app development than we are ready to admit yet.
Staying in our comfort zones
I know, there are a few outstanding examples that are not like that and I generalise, but look around and you will see that I have a point. We get excited about the possibilities and revel in academic exercises rather than getting real issues fixed and showing how to deliver real solutions. This goes as far as discussing for days whether to use semicolons in JS or not.
Who is the audience?
- Yeah, yeah, cool but why don’t you support the new experimental feature $x that browser $y has in the latest Nightly?
- That’s cool but I don’t like using your browser (my favourite, as it has nothing to do with the talk 🙂 )
- This is all fine but none of my clients will ever need that
- Great, but I can not use this as all my clients use browser $shouldhavedied and will never upgrade
Now the luddite fraction of this has a point – a lot of what we show when we talk about “the bleeding edge” can only be used (for now) in Nightly releases of browsers or need certain flags to be turned on. In some cases you even needed a special build of a certain browser (like the GamePad API in Firefox or Adobe’s first CSS regions proposal). This means we do expect a lot of investment from our audience for something that might change or be discarded in the near future.
The “ZOMG YOU ARE SOOO BEHIND” fraction has a point, too – if they put their money where their mouth is and really use these new technologies in products rather than just getting excited about getting something new and shiny every week. Otherwise this is just borderline trolling and doesn’t help anybody.
Getting the bleeding edge into the mainstream
The question then is how could we ever get the new technologies we talk about used and implemented? There is no doubt that we need them to make the web the high fidelity app platform we got promised when some company arrogantly proclaimed Flash to be dead. But who will be the people to use them? In a lot of cases this only happens inside the companies that drive these technologies or by partners these companies pay to build showcases to prove that things could be amazing if we just started using new tech.
To me, this is not scalable and sad. We should be innovating for the people who build things now and not for a future that needs to come. This is less sexy and means a lot more work but it means we build with our audience rather than trying to lure them to change.
If you keep your eyes open then you see that actually a lot of what we consider amazing work is a very small percentage of the market. Tech press loves to hype them up and companies love to (pretend to) use bleeding edge technology to attract tech talent to work for them, but the larger part of the market wants one thing: getting the job done.
The majority of developers use libraries and frameworks
In the case of the web development this means one thing: libraries and polyfills. Yes, the things we considered a necessary evil to be able to build things fast and still support outdated browsers are now the thing people use to build web products. These are also the things they tell others to use – try to find a question on Stack Overflow that has no “use jQuery” as at least one of the answers. Try to find a CSS example that supports various prefixes rather than pulling a “this works only in webkit” or “use Less, no, use SASS, no use SMACSS…”.
Abstracting away the need for basic knowledge
The “in-crowd” scene has a fetish for abstraction. Instead of building applications and solutions we build more libraries, micro-libraries and polyfills to abstract the evil away from implementers and then we are surprised if implementers don’t know the basics any longer. Well, they used the precious time they had to learn what we build and started getting things done. And this learning time multiplies with the amount of things we release. The hour learning backbone, SASS, LESS, hammer.js or whatever is gone and should be used to build things with it now. All the more despicable when as the “cool kids” we just drop those libraries a few months later and build the next big thing.
Shouldn’t we innovate with existing libraries?
The question I am asking myself right now is this: when most of the market uses libraries to get their job done, why do we bother assuming that people would go back to writing “native” code for browsers – especially when we fail to produce standards that do not differ across browsers?
Wouldn’t the better way to get something done to build jQuery plugins that use the new APIs we want people to play with in an unobtrusive way and see real applications built with them? A great example are performance enhancements like requestAnimationFrame and pageVisibility. We can whine and complain that libraries are horrible and especially on phones drain the battery mercilessly or we could just start playing where our audience hangs out and improve where the errors happen rather than pointing them out.
Of course some things need us to find people to play with tech outside the libraries but a lot could be sneaked in without people knowing and then allow us to show real examples where a plugin that uses a new feature made an older implementation perform much better.
View full post on Christian Heilmann