And the truth (or at least, an attempt at redressing the balance)

The web: less engine, more gas

Twenty-four hours ago I posted a mildly ranty tweet (I know, I can’t believe it either) about the current proliferation of techniques/tools for modern web development. Here’s the tweet in question.

This was a frustrated summary of something I’ve been feeling for quite a while now. I’m a front-end web developer of a fair few years now and I feel like the last couple of years have really seen the rise of a kind of web development I’m not sure is actually good for the web. I’d like to expand a little here on why that is.

The rise of the DevOps movement of late has been a large factor in this process. There’s a lengthy article doing the rounds from Smashing Magazine describing a semi-mythical superdeveloper who can deploy code anywhere, test anything, automate package management and compile code assets like her life depended on it. Nowhere in this fantasy does it talk about the quality of the user experience of this imaginary product; the metrics of its user engagement; the visual language of its design (except to say that they’re all meaningless if the performance is poor).

Performance is of course a hugely important measure in this age of the mobile web, but performance for performance’s sake trivialises what we do. A relentless focus on how to scrape every last frame from Chrome’s rendering engine seems a bit redundant when the page it’s loading is a half-baked rendition of something a smarter agency did nine months previously. Why render a beautiful graph of pageload speeds if nobody’s converting on your product signup page?

These things aren’t either/or, sure. You can optimise and tool up and still deliver a brilliant, beautiful product. But so many of the discussions and articles I see around the web lately focus on tools or technique alone: here’s sixteen amazing things you can do with FlexBox. This is the cool new JavaScript package manager you should all be adapting your code to fit. Check out the new Chrome nightly where the devtools will show you the line of code you’re about to write before you write it. I worry that from the outside in, we look like magpies constantly alighting on the next shiny thing, losing sight of the bigger picture.

I want to see more people talking and writing about incredible digital experiences they’ve had. How can we build products and sites more like them? How can we achieve a sense of playfulness and interaction that’s so uniquely native to the web? What kind of interface can we create to best reflect what our tool aims to solve?

The web browser is a bit like a car built to travel on the road that is the web. Each website and app we make is a destination on that road. Let’s stop tuning up the engine and start driving somewhere.

  • Benjy Stanton

    Well put. I think the recent focus on performance has been good, but it feels like its time to take stock of what we’ve learnt and put more focus on the bigger picture / experience again.

  • http://paulirish.com Paul Irish

    I pretty much agree with you, though one can place me at fault here. :)

    Now, first I do think frontend development does need to take a more strict engineering approach to the practice and so things like Alex Sexton’s front-end ops makes me extremely happy. Right now our art is a big mix of knowledge and technique that you gain only by experience and reading, and it’s a total black art to people new to the field. We also tend to repeat a lot of work on every project and run into similar mistakes repeatedly. The only way to improve that situation so that instead of battling browsers, we’re building experiences is to bake more of our knowledge into the platform and tools. This way we can get back to making sexy things on the web. Chrome DevTools, for example, just wants you to get things done quicker so you can return to delivering magic.

    But ultimately, even if you have a super productive development workflow, build chain and clean architecture, it’s up to your UX to deliver. And if it doesn’t, you’ve wasted your time.

    Part of this is that as the frontend developer role has parted ways with the web designer role, it’s taken on less of the UX responsibilities and therefore it’s a not-my-problem situation. That’s bad. We craft the UI and we construct the interactions. If we aren’t invested in the success of those interfaces with our users, then we’re failures.

    This is part of why I proposed the Effeckt.css project, we need more guidance and passion when it comes to delivering smooth, slick and satisfying experiences. From what I can see, we incorporate analytics data poorly into the feedback loop. We also don’t usability test often enough or hear back from users effectively.

    One thing I always think about was when I looked at the sourcecode for Kayak.com like 4 years ago. It was bad.. like some of the more egregious jQuery spaghetti code that you’d make fun of. And I almost wanted to be nit-picky about it. But .. at the same time, the experience it enabled was fantastic! Where is one of Maslow’s Hierarchy of Needs for Web? Obviously, User experience > Development practices.

    There are a lot of parts of delivering an amazing UX that need to have attention from both the frontend developer, but probably also the design team: page load time, frontend responsivity, form factor fit, visual polish, interaction polish, success metrics, usability.

    Lastly, this:

    I want to see more people talking and writing about incredible digital experiences they’ve had. How can we build products and sites more like them? How can we achieve a sense of playfulness and interaction that’s so uniquely native to the web?

    Yes, so much.

    • Cragstar

      Totally agree with Paul.

      Either more vendors should work together to get browsers delivering the sameand make browsing and development the same across the board. And leave the vendors themselves bringing people in with features (Syncing, accounts e.t.c.) rather than because Browser 1 does what 2 cannot.

      This will allow developers to deliver great UX, knowing it will work any and everywhere.

      It is the only way Mobile Web will be able to move forward ahead of standalone apps.

      I also find http://purecss.io to be the best starting base for getting started on new projects with a very very simple structure

  • rhysbrettbowen

    The real question is what a front end web developer does. Not everyone is involved in UX and the CSS – there are people out there who only deal with the architecture of web applications. Then there are designers who work on the look and feel and will inevitably know some HTML and CSS and hopefully understands what is possible. Then you’ve got the people in the middle of those and that’s where I believe most front-end developers work.

    Here is the major problem though, there are lots of designers who fill out the UI/UX role but I don’t believe there are many whose roles only compromise the structure of the code so that slack is left up to those in the middle to take up. So really the gray area of UX is a small part when they have to take up a whole other role and I have no problem with the focus that is gaining at the moment in the ways of tooling, testing etc. That needs to be done while UX is already part of someone else’s job so all that is really needed there is to keep up with what is possible and have a bit of feedback.

  • http://blog.davemo.com/ David Mosher

    The last few years have yielded a massive expansion in browser capabilities; the vendors and standards bodies have been pushing hard to release new APIs and features to make the browser even more viable as a deployment platform for rich web experiences. If I think back just even 6 years ago, it’s not hard to remember a time when there were no new capabilities being added; when we were stuck in a sort of stagnated contraction in what was happening on the web. This sort of expanding/contracting cycle is a pretty natural thing in the evolution of technologies; but we are definitely in an expansion stage.

    This puts pressure on those of us who identify ourselves as “Web” developers, because it means we have to continue to try and keep up with the rapid pace of change in the world of the browser. It also puts an order of magnitude _more_ pressure on people entering the field of web development in 2013 and I have a lot of empathy for those who take that plunge. As Paul mentioned in his comment, this appears as a real dark art to those people just coming in. The focus on performance, tooling, devops-y type things, is a response to the massive expansion we are in; but I think the danger is, as you’ve pointed out, that we leave the foundations of the “experience” of the web and what we build behind while we obsess over “the new shiny”.

    One of the incorrect assumptions I’ve had to correct in my own mind is the idea that a beautifully _architected_ web experience == a great web experience; this was made clear to me as I explored the amazing http://www.forecast.io app on my iOS device. I dug into the code and noticed it was just a bunch of jQuery plugins strapped together! The smarmy “architect” in me wanted to look at that and dismiss it as a horrible architecture, but then I just sat back and looked at the UX of the app and it blew me away that such an awesome experience could be created on the mobile web! That experience really made me get introspective about my preconceived ideas on “beauty” as it relates to the web; UX > Architecture, and that’s the way it should be because that’s what our users care about :)

    I love your conclusion and I agree 100%, now that we have these awesome tools and APIs it’s time to create some kick ass experiences with the platform we’ve been handed.

    Thank you for posting your thoughts, I know they resonate with me and many more in the front-end community!

  • jwlrs

    I don’t think this is an either-or thing at all. Better tooling/dev-ops leads to more time available to focus on the things that matter (as long as you get your tooling figured out mostly up front and then spend most of the rest of your time actually kicking ass). I’ve observed this in so many projects I’ve worked — the more clumsy and ill-suited the tools, the less time is left to fine-tune that workflow, streamline signup, polish the look and feel, etc.

    • Andrew Consroe

      Totally agree with this point. To tie it back to the author’s car analogy, a ferrari is not only great because it has a powerful and finely tuned engine, but also because it has beautiful aesthetics, inside and out. A PT Cruiser with a ferrari engine is no better than a ferrari with a PT Cruiser engine. Gotta have both to be brilliant.

  • Carlos Rodrigues

    @David Mosher “I dug into the code and noticed it was just a bunch of jQuery plugins strapped together! ”
    Yes, I remember I tried it 10 times and it crashed the browser like 7…now I see why..

  • Guest

    I’ve been a designer/developer for about

  • Chad Pommiss

    I’ve been a front-end/back-end developer for about 12 years now. I’m one of those guys that doesn’t have a job working on a “product”, such as GMail, Facebook, Freshbooks, etc, and I don’t work for a startup. Instead, I’m probably one of the probably hundreds of thousands of developers who either work for an advertising/interactive agency or who freelance for various interactive agencies as their in-house developer. In this world, time is money, and you seek to defy the “Fast, Good, Cheap: Pick Two” saying and instead deliver all three.

    The focus on tooling is, from where I sit, essentially transforming the web development workflow into a traditional software development workflow. I’m sure for those who have the breathing room to handle it, it’s fantastic. For guys like me though, who fill a very real need to help businesses of all sizes establish an online presence, I’m feeling more and more like a dinosaur even though I’m constantly learning new front-end and back-end toolsets. There just isn’t any room, time or necessity for build tools like grunt, unit testing, object-oriented CSS, front-end MVC frameworks or the latest, super-cool “.JS” project that promises to add abstraction to your abstraction. Many of the projects I deliver will be gone in 6 months to a year and replaced with something new and shiny.

    And yet the pervasive attitude in the community seems to be that you should be using all of these things if you want to call yourself a front-end developer. Surely some of these things are being added to clever interview questions everywhere.

    All of this additional tooling is starting to even scare me, and I’m a veteran here. I don’t exactly know why I need to add all these levels of complexity to accomplish a job that I was able to, and still am able to accomplish today without it. And yet, if I were to go interview somewhere that does build a product, I’d be viewed as having an inadequate skill set even though I have the core competencies to get the work done.

    Think about what new developers must feel when they see all of these tools with fun names and all of these layers of abstraction that must be learned to build a website, which is, in it’s simplest form, a text file on a server. I feel for them. It’s certainly not the same low-barrier-to-entry of “View Source” that it was a few years ago.

    I’ve no problem learning new tech. It’s what I love about this career path, actually. If you don’t have a hunger and a passion for continuous learning (and unlearning), you won’t make it as a web developer. But I just wonder if all of this new tooling is so necessary that it needs to be preached to the community by the loudest voices within it.

    It’d be nice to see some more effort, by those with the time, go into better educational material and outreach. I wish I had the time to do it, but I’m always on a deadline =)

  • ganticular

    Web developers are failed programmers. Who cares about toyworld.

  • Pingback: Web Development Pic 'n' Mix - Phil Leggetter - Real-Time Web Software and Developer Evangelist

  • SGraham

    Maybe its simpler than that. This industry attracts people with an obsessive nature and a drive towards binary perfection. It’s right or it’s not. Why should it be surprising that these same people drill down into the very minutae of their craft (the tools), to ensure its efficiency? It’s a natural thing for developers to do. An unnatural thing for these same people is to brag and show off and perhaps thats why we don’t hear the same volume of front-end discussions. There is nothing wrong here. It’s just the people we are.

    I enjoyed your article and just wanted to offer an alternate viewpoint for discussion

  • Pingback: Bruce Lawson’s personal site  : Reading List

  • http://twitter.com/charlesroper charlesroper

    A very much related post: http://blog.geomusings.com/2013/07/19/focus/

    “Yet FFL has an overwhelmingly positive tone. This is because everyone is focused on one goal: the elimination of diabetes. Any approach that represents a step toward that goal is cheered by all, as is any technique that eases the burden of living with diabetes in the meantime. Ultimately, the various technologies showcased at the conference help facilitate progress toward this goal but the technologies are not the point.

    Let me say that again.

    The technologies are not the point.

    So the question in my mind is, what’s the goal of the web? Seems to me that the pretty obvious yet largely unspoken goal of many modern web designers and developers is to show off to their peers. We need less of that. Less vanity, less ego. Instead we need more professionalism, more humility. Or, as Mark Boulton argues, what we need is less whittling.

  • http://www.drupalgeeks.org/drupal-development Drupal Development

    The topic is so interest and so nice useful too..Thanks for sharing this post.

  • Pingback: Ripped Rx No2 Ingredients

  • Pingback: to make