The Future of the Web

by
Published in Industry, State of the Web

Recently the web—via Twitter—erupted in short-form statements that soon made it clear that buttons had been pushed, sides taken, and feelings felt. How many feels? All the feels. Some rash words may have been said.

Article Continues Below
Article Continues Below

But that’s Twitter for you.

It began somewhat innocuously off-Twitter, with a very reasonable X-Men-themed post by Brian Kardell (one of the authors of the Extensible Web Manifesto). Brian suggests that the way forward is by opening up (via JavaScript) some low-level features that have traditionally been welded shut in the browser. This gives web developers and designers—authors, in the parlance of web standards—the ability to prototype future native browser features (for example, by creating custom elements).

If you’ve been following all the talk about web components and the shadow DOM of late, this will sound familiar. The idea is to make standards-making a more rapid, iterative, bottom-up process; if authors have the tools to prototype their own solutions or features (poly- and prolly-fills), then the best of these solutions will ultimately rise to the top and make their way into the native browser environments.

This sounds empowering, collaborative—very much in the spirit of the web.

And, in fact, everything seemed well on the World Wide Web until this string of tweets by Alex Russell, and then this other string of tweets. At which point everyone on the web sort of went bananas.

Doomsday scenarios were proclaimed; shadowy plots implied; curt, sweeping ideological statements made. In short, it was the kind of shit-show you might expect from a touchy, nuanced subject being introduced on Twitter.

But why is it even touchy? Doesn’t it just sound kind of great?

Oh wait JavaScript#section2

Whenever you talk about JavaScript as anything other than an optional interaction layer, folks seem to gather into two big groups.

On the Extensible Web side, we can see the people who think JavaScript is the way forward for the web. And there’s some historical precedent for that. When Brendan Eich created JavaScript, he was aware that he was putting it all together in a hurry, and that he would get things wrong. He wanted JavaScript to be the escape hatch by which others could improve his work (and fix what he got wrong). Taken one step further, JavaScript gives us the ability to extend the web beyond where it currently is. And that, really, is what the Extensible Web Manifesto folks are looking to do.

The web needs to compete with native apps, they assert. And until we get what we need natively in the browser, we can fake it with JavaScript. Much of this approach is encapsulated in the idea of progressive web apps (offline access, tab access, file system access, a spot on the home screen)—giving the web, as Alex Russell puts it, a fair fight.

On the other side of things, in the progressive enhancement camp, we get folks that are worried these approaches will leave some users in the dust. This is epitomized by the “what about users with no JavaScript” argument. This polarizing question—though not the entire issue by far—gets at the heart of the disagreement.

For the Extensible Web folks, it feels like we’re holding the whole web back for a tiny minority of users. For the Progressive Enhancement folks, it’s akin to throwing out accessibility—cruelly denying access to a subset of (quite possibly disadvantaged) users.

During all this hubbub, Jeremy Keith, one of the most prominent torchbearers for progressive enhancement, reminded us that nothing is absolute. He suggests that—as always—the answer is “it depends.” Now this should be pretty obvious to anyone who’s spent a few minutes in the real world doing just about anything. And yet, at the drop of a tweet, we all seem to forget it.

So if we can all take a breath and rein in our feelings for a second, how might we better frame this whole concept of moving the web forward? Because from where I’m sitting, we’re all actually on the same side.

History and repetition#section3

To better understand the bigger picture about the future of the web, it’s useful (as usual) to look back at its past. Since the very beginning of the web, there have been disagreements about how best to proceed. Marc Andreessen and Tim Berners-Lee famously disagreed about the IMG tag. Tim didn’t get his way, Marc implemented IMG in Mosaic as he saw fit, and we all know how things spun out from there. It wasn’t perfect, but a choice had to be made and it did the job. History suggests that IMG did its job fairly well.

A pattern of hacking our way to the better solution becomes evident when you follow the trajectory of the web’s development.

In the 1990’s, webmasters and designers wanted layout like they were used to in print. They wanted columns, dammit. David Siegel formalized the whole tables-and-spacer-GIFs approach in his wildly popular book Creating Killer Web Sites. And thus, the web was flooded with both design innovation and loads of un-semantic markup. Which we now know is bad. But those were the tools that were available, and they allowed us to express our needs at the time. Life, as they say…finds a way.

And when CSS layout came along, guess what it used as a model for the kinds of layout techniques we needed? That’s right: tables.

While we’re at it, how about Flash? As with tables, I’m imagining resounding “boos” from the audience. “Boo, Flash!” But if Flash was so terrible, why did we end up with a web full of Flash sites? I’ll tell you why: video, audio, animation, and cross-browser consistency.

In 1999? Damn straight I want a Flash site. Once authors got their hands on a tool that let them do all those incredible things, they brought the world of web design into a new era of innovation and experimentation.

But again with the lack of semantics, linkability, and interoperability. And while we were at it, with the tossing out of an open, copyright-free platform. Whoops.

It wasn’t long, though, before the native web had to sit up and take notice. Largely because of what authors expressed through Flash, we ended up with things like HTML5, Ajax, SVGs, and CSS3 animations. We knew the outcomes we wanted, and the web just needed to evolve to give us a better solution than Flash.

In short: to get where we need to go, we have to do it wrong first.

Making it up as we go along#section4

We authors express our needs with the tools available to help model what we really need at that moment. Best practices and healthy debate are a part of that. But please, don’t let the sort of emotions we attach to politics and religion stop you from moving forward, however messily. Talk about it? Yes. But at a certain point we all need to shut our traps and go build some stuff. Build it the way you think it should be built. And if it’s good—really good—everyone will see your point.

If I said to you, “I want you to become a really great developer—but you’re not allowed to be a bad developer first,” you’d say I was crazy. So why would we say the same thing about building the web?

We need to try building things. Probably, at first, bad things. But the lessons learned while building those “bad” projects point the way to the better version that comes next. Together we can shuffle toward a better way, taking steps forward, back, and sometimes sideways. But history tells us that we do get there.

The web is a mess. It is, like its creators, imperfect. It’s the most human of mediums. And that messiness, that fluidly shifting imperfection, is why it’s survived this long. It makes it adaptable to our quickly-shifting times.

As we try to extend the web, we may move backward at the same time. And that’s OK. That imperfect sort of progress is how the web ever got anywhere at all. And it’s how it will get where we’re headed next.

Context is everything#section5

One thing that needs to be considered when we’re experimenting (and building things that will likely be kind of bad) is who the audience is for that thing. Will everyone be able to use it? Not if it’s, say, a tool confined to a corporate intranet. Do we then need to worry about sub-3G network users? No, probably not. What about if we’re building on the open web but we’re building a product that is expressly for transferring or manipulating HD video files? Do we need to worry about slow networks then? The file sizes inherent in the product pretty much exclude slow networks already, so maybe that condition can go out the window there, too.

Context, as usual, is everything. There needs to be realistic assessment of the risk of exclusion against the potential gains of trying new technologies and approaches. We’re already doing this, anyway. Show me a perfectly progressively enhanced, perfectly accessible, perfectly performant project and I’ll show you a company that never ships. We do our best within the constraints we have. We weigh potential risks and benefits. And then we build stuff and assess how well it went; we learn and improve.

When a new approach we’re trying might have aspects that are harmful to some users, it’s good to raise a red flag. So when we see issues with one another’s approaches, let’s talk about how we can fix those problems without throwing out the progress that’s been made. Let’s see how we can bring greater experiences to the web without leaving users in the dust.

If we can continue to work together and consciously balance these dual impulses—pushing the boundaries of the web while keeping it open and accessible to everyone—we’ll know we’re on the right track, even if it’s sometimes a circuitous or befuddling one. Even if sometimes it’s kind of bad. Because that’s the only way I know to get to good.

36 Reader Comments

  2. A few more items for the history lesson:

    1. blink, marquee, center, strike, font, layer, ilayer, carousel, fittext

    2. framesets (which were the original SPA)

    3. XML / XSLT

    4. Ads (oh wait)

    I think the major theme in the mis-steps on the web is over-prioritizing presentation and leaving semantic markup as an after-thought. I have complete confidence that this is going to happen again (and again). If people start replacing [a href=”…”] with custom-elements then I will know the web is dying.

  3. We see this at the project level (well I do), so it’s not too much of a surprise to see it at the web standards level.

    – Here’s an idea!
    – Build it
    – Wow that’s awkward
    – Hey it only works in like 50% of the cases
    – OH NOES ENHANCING TO COVER THE OTHER 50% COSTS $$
    – OH HEY THE OTHER 50% HAS MONEY TOO LET’S BUILD FOR THEM
    – Build it again, but better
    – Get it almost where you want it
    – Here’s an idea!

    Context *is* everything. Whether it’s a website project or a change to a browser, it’s looking at the core users, what they need, what the business needs, who’s included, who’s excluded, how excluding certain groups/people will impact everything from perceived morality to marketing, what the ROI is, etc. etc.

    And even though I’m firmly in Camp Progressive Enhancement, some days it’s a battle to get my business contacts to acknowledge programming is hard and my IT contacts to acknowledge the users are people — so the bad code often has to come first because we don’t have time money or knowledge enough to nail the idea on the very first try.

  4. Some years ago, I developed a method for detecting the zoom level in IE 7 using Javascript. It relied on the onmove event being placed on a undisplayed element to trigger a measurement that gave me the Zoom level.
    But why was the Zoom level not exposed as an object I could query with JavaScript? What would be the harm?
    I also remember a conversation with a couple of Mozilla Firefox programmers who had absolutely no idea that if I write width: 1in; in the CSS, it doesn’t actually measure 1 inch onscreen.

    Everybody’s got a different vantage point.

    Personally, I would love much more of the stuff under the hood of the browser exposed to JavaScript. However, there may be some hesitancy on the part of browser makers about this. When things go wrong, who ya gonna blame, the faceless developers behind the site you’re on or the very visible makers of the browsers – like Microsoft, Google, or Apple? I’m sure that fielding irate complaints about this or that site not working right in IE, EDGE, Chrome, or Safari is NOT their favorite activity.

  5. Thanks everyone for contributing to the comments! Lots of great thoughts and opinions.

    One theme I’m seeing carried through several is that all this stuff is gray and messy. Very little black and white. Which is really the core of what I’m trying to get across. The more we can get out of our ideological camps (PE vs. PWAs), the more we can recognize how much we agree and move forward.

    It does strike me while reading the Twitter thread (again with the Twitter, oy!) that Jeffrey posted that lamenting the rise of Javascript (Adam Spelbring, in the thread) is a bit of a losing battle at this point.

    From a practical point of view, JS is a third of the web stack (some would argue it’s often 1/2 of the stack these days). Yes things change all the time, but this is the mercurial web here. One must adapt with it or find another line of work.

    I also think the comment about waiting 10 years for JS to go the way of Flash suggests a bit of a misunderstanding of that relationship.

    Flash was a way to get what we needed at the time (by both hook and crook). Once comparable features entered the native web via JS/HTML5/CSS3, we could ditch Flash for good.

    But Javascript is part of the native web stack, and when taken from the POV of the extensible web it becomes not a set of features, but a machine to create the features we need. It is the prototype machine. And as these custom features prove themselves to be useful (as with layout) or not useful (as with the aforementioned blink) those features will become part of the native web or fizzle into nothing.

    The goal of the extensible web isn’t to build everything in JS all the time. It’s to have the ability to prototype what we need in JS. Polyfills and prollyfills. And let the best stuff rise to the top rather than being handed to us from on high by a standards body whether we like it or not.

    And, not insignificantly, some of the greatest advocates for this idea are the people involved with standards and browser vendors. They want authors creating the features they need, instead of just second guessing us.

    It’s a more democratizing approach to web standards, ultimately. And if we want our voices to be heard, we need to start building the future we want.

  6. Totally agree on the context idea. JavaScript is often a overused when it comes to simple websites. I think it should be restrained to a more functional role, not for visual design (animations). Often, it works against the semantic web. Progressively, JavaScript components or libraries should be replaced by native browser features. Sort of best of both worlds…

  7. Well said Mum! That’s something I know that – for instance – jQuery is really behind. Once things in jQuery gain native adoption, they really want you to stop using jQuery for that. Which is a nice precedent for the EWM concept.

  9. I think a very important point is that if most front end devs can’t use something, you’re going to make it very expensive to support the code-base. Keep it at a more amateur level and you have a much cheaper to maintain situation. A very valid consideration.

  11. Nice article…What can be said about the future of the Web. There are numerous advantages of the web. I am career consultant at Jobs Aviator and I advice my candidates to build their social profiles strong and grow their social network over the internet to get a good job. Web has great influence on career of every individual.

  12. Spot on, espicially your point on “Context is everything”

    I guess many developers (including me) struggle with this. It is hard to put your finger on a certain approach/solution to a problem. It kinda voice down to your experience.

  14. The web is more going towards simplicity and due to SEO and Optimization people are more focusing towards page speed and website content rather than visuals.

    Its time to go more flat and more simple designs by keeping minimal sized images.

  15. Given the use of mobile applications in javascript , I think he still has a bright future!

  16. Progressive web apps is really interesting point made in the article. With world adopting mobility, Mobile apps are gaining more importance than the web applications and thus Progressive web applications like a push button or a simple process of doing a thing is necessary.

    I am attaining a webinar and a panel discussion about the same topic, named as “NextGen Enterprise solutions”. Here is the reference link for more details http://www.cygnet-infotech.com/next-gen-enterprise-solutions

  17. Hello ,

    Thanks for the sharing this great article related to The Future of the Web.. this article is very usefull for me…..thanks again for sharing this great article

  19. Someone said: “learn as much as you can, use as little as you need”. Spawn of new approaches, web technologies, frameworks, overload of market with generic design, templates – made us using sometimes more than we need, often missing the point in reaching to the audience and evolving the accessibility and the way of perception within the browser boundaries.

  21. Interesting article “future of web”. We are a web development company dealing in web design an development and many more services. kindly go to the link https://www.thegenisys.com/ for more info. Looking forward for more articles.

  28. Interesting piece, I’ve been following the trend of progressive web apps with great interest since it has the potential to become a rival to mobile app development in my opinion.

  33. Solid article. The web has some serious issues with business models. Sites are so choked with advertising-related bloat that make a huge portion of the internet is unusable. I think from a web perspective, the available real estate (among other things) will keep the web relevant for quite some time, but from a mobile web perspective, it might be the end of days. With
    94% of US millennial’s being smartphone users and the stark contrast in user experience between native and mobile web, the mobile web might be seeing its end of days.

    On the web, I think some of this experience starts to change over time as individuals start valuing more meaningful content and being willing to pay for it in the form of subscriptions. The NYT has done a great job of increasing their subscription base of late. Medium has recently entered the ring of subscription and individuals like Ben Thompson have been incredibly successful in the space. It will be interesting to see if we can reduce the relevance of advertising and in turn bring back a reasonable user experience on the web.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

I am a creative.

by
A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
Career