The web has grown up a lot in the last 20 years. I’m about to take you on a journey of what happened after the “big bang” of the web, how it formed into the web we know and love today, and what the web will look like in the future for designers, developers and marketers.

In The Beginning…

HTML, although officially released in 1990, didn’t make it into people’s homes until the first Netscape Navigator web browser hit the ground running in ’94. (Ok, I didn’t have internet either until ’96).

For years to come, there was a single mainstream access point to the web – the desktop PC browser. Netscape ruled for about a year or two before the first version of Microsoft’s Internet Explorer came bundled with Windows 95.

Life for a web designer was simple back then. You couldn’t do much technically to begin with, but there was no concern about cross compatibility.

As a designer you only had to worry about a single screen width, and if you had fancy rollover effects on your links you were considered savvy (FrontPage anyone?). Stylistically, anything you wanted to do was done with rich text formatting and images because cascading style sheets (or CSS) were barely born.

The well documented browser war of the ’90s was in full swing, and to gain an edge in market share the team behind Navigator created a new scripting language that would run client side on a user’s computer rather than on the server. They wrote it in just 10 days and eventually named it Javascript.

That was around when Macromedia (now owned by Adobe) bought a product called FutureSplash, renamed it to Flash and brought it to market to help designers create cool animations on their websites.

The web as we know it today, with all its fundamental components, had started taking shape. (Are you picturing 8-bit tadpoles at this point too?)

Cross Compatibility Rears its Ugly Head

Hardware, believe it or not, even back then had as big an impact on the progression of web design as had software iterations.

Just as designers and developers were getting accustomed to a specific viewport size of the web, monitors were getting bigger, and so were their screen resolutions.

Now, web design had a new problem to deal with that would define one of our biggest modern day challenges – supporting different resolutions. Larger monitors were becoming the norm, but older monitors were still prevalent.

Designers had a choice – stick with the old resolution constraints (and make a narrow experience for some) or abandon users on older monitors forcing them to scroll sideways (gross!).

Design challenges aside, a lot of focus shifted towards what could be achieved technically in the browser. Could we build applications that live in the browser? And with these technical challenges, only naturally, speed took center stage. How could we render our web-pages faster? More and more people had replaced their dial-up connections with broadband, and they demanded ever-snappier experiences.

Dynamic Content Hits the Scene

We got to meet a new browser in 2002. Firefox started taking market share away from then-dominant Internet Explorer. It was faster, supported web standards properly, and gave developers debugging tools like nothing they’d seen before.

But regardless of how fast web-pages loaded, if you wanted to load any fresh content onto the screen you had to refresh the whole page from the server. I know – ridiculous. This was a major road block to effective web-app development.

By 2005, a now very well known technique called AJAX (Asynchronous Javascript and XML) opened the door for sending and fetching small pieces of content to and from the server, and adding it to an existing, already loaded, web page. This was a massive upgrade to the web – especially for web-app developers who could now load the guts of their applications once, and only load and insert small pieces of new information as necessary. The manipulation of the HTML already on the page was done with a combination of Javascript and Dynamic HTML (DHTML) which allowed Javascript to manipulate the text and style of elements on the page.

Although they were technically possible, AJAX and DHTML techniques were messy… There was no standard practice and tons of cross browser compatibility issues to contend with – Internet Explorer, Firefox and other browsers all had different levels of support for these technologies, and even if two supported the same technique, they likely did so in different ways.

This problem however, opened the door for development libraries that would mask these complexities and let developers code faster. In 2006, Jquery was released to the world to address this need. Over the years, Jquery has proven to be the de facto way in which we can overcome compatibility problems and pretend they don’t exist! (thanks Jquery : )

The Web Crosses Over to Mobile Devices

The iPhone came out in 2007 and for the first time the mobile browser was worth designing and developing for. If you haven’t had enough Steve Jobs tidbits, here’s another for you – Jobs’ original vision for apps on the iPhone was HTML web-apps delivered through mobile Safari, not the app store. He actually had to be convinced by staff to pursue the app store concept. Although we all know how that decision materialized, Jobs was a visionary and he knew that in the long run, the browser would win.

Although mobile Safari was a giant leap forward, it was still slow and capable of only the simplest rendering and workload for scripts – not really a contender to desktop browsers. But, with every new iPhone and iOS update, mobile Safari kept getting better.

iOS also spelled the impending death of Flash – specifically when the iPad first launched and made a point of not supporting it. Flash was a great way not only to animate vector graphics on the web, but also to deliver other forms of rich content like streaming video. And while for some content it’s still proving to be the most suitable solution for the desktop (as many old browsers still don’t support HTML5), it’s only a matter of time before HTML5 replaces Flash altogether.

Why? HTML5, although not fully complete even today, is replicating all of Flash’s abilities natively within HTML without the need for a third-party plugin.

Native Apps vs. HTML5

These days, no one develops new applications with Flash – it’s either native-apps or web-apps. To me, Flash was a way of catching the web up by making it possible to present interactive content in a way HTML was not capable of doing. But because it’s essentially a closed ecosystem, the lack of SEO and discoverability severally hampered its ability to satisfy marketers seeking to broadcast their message.

OK so no Flash, but when it comes to mobile, Flash wasn’t much of an option anyway. The big debate has always been “native-app vs. web-app”. Native-apps are fast, and offer some capabilities not (yet) available to HTML5 web-apps. Does that argument sound familiar? To me native-apps are our modern day version of Flash – a closed, non-searchable or discoverable platform for creating interactive experiences beyond what web-apps can produce. With one major difference – Flash made it easy to develop once, and render on any desktop browser. Native apps, on the other hand, only work on the operating system they were developed for. In fact, I believe that this was the real reason Jobs refused to support Flash – not because it was a resource hog (yes, that too), but because it was the only technology that could challenge the performance of native-apps.

Platform Wars

By 2010 the browser wars had been replaced by the platform wars. iOS, Android, and more recently Windows 8 and Blackberry 10 have caused companies to really take a 2nd look at their content marketing and distribution strategies – so many platforms to support and while majority of traffic still comes from desktop for most brands, mobile continues to make a push to the top.

The shortcomings of native-apps, most notably the inability to link to content within it (say, from an email campaign) has naturally forced companies to continue to invest in their mobile web presence, regardless of how much they’ve already spent on native iOS and Android apps.

As a result, most mobile web traffic still happens in the browser. Many companies have adopted an adaptive design methodology whereby a separate web experience loads for mobile visitors, and the desktop version loads for desktop visitors. In reality this is no different than developing both an iOS and Android app. It’s 2 separate code bases to maintain (even if both are in HTML) – and keeping both in sync becomes increasingly difficult and expensive.

A New Approach to Stop the Madness: Responsive Design

So that brings us to present day and the launch of CSS3 in 2012. Using a new technique available in CSS3 (probably the most important part of HTML5), media-queries allow developers to change styles of elements on a page based purely on the width of the browser window. This technique has been coined as “Responsive Web Design” (RWD) and its taking the web by storm.

Responsive design opens the door for web designers and developers to create and maintain a single code base, which displays the same content, in different ways, on any sized screen – from phones to tablets to old-school desktop browsers.

RWD is the answer to the never ending array of device operating systems and screen sizes. It’s a no-brainer that this technique is going to stick. The only problem is that, much like Javascript in ’95 and AJAX in ’05, its newness makes it difficult to work with. While there are great examples of sites being built responsively, it’ll be a couple of years before RWD is truly mainstream. There are only a handful of libraries that help developers with responsive design – namely Bootstrap and Groundwork. But they’re just not quite there yet. They fail to standardize key components of RWD which is probably because none have been properly defined yet.

Before RWD can go mainstream, more restrictive, standardized components will need to be established so that it becomes simpler for developers to create great responsive experiences. It’s going to happen. Much like Bootstrap standardized components like the tooltip, buttons and navigation tabs, someone will do the same for RWD in a way that’s palatable for most use-cases.

And when it happens, we’ll be well on our way to eradicating the native-app dominated mobile experiences we see today. Much like Flash, native-apps will find limited appeal when HTML5 (or HTML6) handle more of the functionality that currently still gives native-apps an edge.

The Future is Near

So what’s next for our ever evolving web? There hasn’t been much talk of it yet, but it’s inevitable that once responsive design goes mainstream we’ll start to adopt its principles in web-app development. As much as marketers want their blogs and websites easily accessible on any device and screen, so too will web-app developers. Imagine if all web-based software was accessible, with full feature support, on any screen. In the not-too-distant future, when you log into your favorite web-app, I believe you’ll be logging into a single, responsively designed experience that’s powered by the same code base no matter where you access it from. That will enable companies to truly give their users access to the full feature set of their applications, and to build their products faster. The benefits to users will be tremendous and as such we’ll start to see a drop off in native-app development.

That’s the bright future of the web and why HTML will continue to evolve as the platform of choice for marketers, designers and developers. Who knows where we’ll be in another 20 years, but one thing’s for sure – it won’t look anything like it does today.

Agree with me, or even better, don’t? Let me know about it below.

About the Author

Yoav is the founder and CEO at Uberflip and is responsible for driving the mission, vision, and goals of the company. He spends considerable time working with his team to continuously delight and surprise Uberflip's customers.

Follow on Google Plus   Follow on Twitter