Web Development is now App Development

7 min readMay 6, 2018

Front end development got a lot harder in the last five years and it’s left a lot of people struggling. In the grand scheme of things, I can’t imagine its worse than when people shifted from Perl to PHP, C to Java, or paper to Photoshop. Technology fields are always changing.

Most of the changes from five to ten years ago everyone understands now. We saw the advantage of Sass or another CSS extension. We all learned how to use media queries and do responsive design. Most of us appreciate that AJAX let us do things we couldn’t do before. Most of us learned to embrace flexbox and other CSS3 features.

The struggle is understanding where these other things came from. npm. webpack. Modules. ES6. Vue. React. Vuex. Redux. It might feel sudden to those of us in the industry, but I think the writing was on the wall as far back as 2010.

2000 to 2010

2001: Wikipedia launches.
2003: MySpace and LinkedIn.
2004: Facebook.
2005: YouTube.
2006: Twitter.
2007: the iPhone.
2008: Google Chrome.
2009: Android and HTC Magic.
2010: Instagram, the iPad, and “Thoughts on Flash”.

While the 1980s created the Internet and the 1990s gave way to online shopping and the dot-com bubble, 2000–2010 we saw more serious changes to what we do online. Modern social networking was born. Video became widespread. Smartphones became popular. Accessibility on the web started to matter.

The technologies we had simply weren’t good enough. We were pushing XMLHttpRequest (i.e. AJAX) to its limit. Table layouts could be fluid, but couldn’t be used for “responsive web design”. We started caring about accessibility and screen readers. Macromedia (Adobe) Flash had filled a gap, but with Apple flat out refusing to run it on iOS devices it wasn’t a viable option going forward.

The web needed to advance. Steve Jobs himself called on HTML, CSS, and JavaScript to be used instead of Flash going forward. Despite there being hardly any major advances in ten years, new versions of HTML, ECMAScript and CSS were developed.

2010 to 2018

YouTube. Netflix. Games. Ads. CSS transitions and animations were only just being introduced around 2010. Before, plugins (Flash, Silverlight, ActiveX, even Shockwave) really took on the heavy lifting of “web apps”, where the app was just bundled up and embedded into a website. Just for parity, everything needed to be rebuilt.

Building a Video Player Then and Now

Let’s use the old JW Player as an example. JW Player was a flash plugin you could use to embed a video on your site. It was self contained, had built in controls and the appearance was configurable. We didn’t care if it wasn’t response or accessible. Our requirements were simple and using the plugin was simple.

To build a video player in 2018 you need to implement the UI in HTML5, style it with CSS, and hook up the controls with JavaScript. Accessibility is expected. Being responsive and mobile friendly is required. The code isn’t a self-contained, single file to include and embed. It’s snippets of three different languages that need to be integrated into your site.

In 2008, you could simply embed a video player into your site.
In 2018, the video player has to be part of your site.

Design to Development

Perhaps the last critical piece is that for most sites in 2008, other than the endless task of troubleshooting browser issues, HTML/CSS/JS were the domain of people with a design background. It was quirky, technical, typesetting. Serious programming was done in server side languages or within embeds (whether Flash, Java, ActiveX, etc.) by engineers or programmers with engineering or programming backgrounds.

Requirements in 2008 vs 2018

Let’s take a moment to look at websites as they looked in 2008 compared to now.

Time.com in 2008 (via Archive.org) and 2018.

2008 predates modern, responsive web design. Time.com had a max width. Most of the content was still using blue text to indicate hyperlinks, whereas in 2018, the whole blocks are clickable. There’s bits of two video players visible in 2018; in 2008 there’s just a still with a link to a different page. The left feels like a rich text document; the right looks like an app.

Amazon.com in 2008 (via Archive.org) and 2018.

Amazon’s site was fluid width, but not responsive. The only images in 2008 are regular <img> elements, whereas in 2018, images are used in backgrounds and bleed off the edges. Like Time, we see nearly all blue text hyperlinks are gone in favor of making whole blocks clickable. The left looks like a print catalog with hyperlinks; the right looks like an app.

Lastly, Youtube.com in 2008 (via Archive.org) and 2018.

Same story; fixed width to responsive. Blue text hyperlinks to clickable blocks. Less obvious is that the McDonald’s ad in 2018 is a video that automatically started playing (silently.) YouTube’s transition might be the most noticeable, as on 2008, it looked like search engine results. In 2018, we get a sidebar, a dark UI mode, buttons to load more videos without leaving the homepage… It’s a now a web app.

In 2008, we were building lightly designed rich text documents.
2018, we’re building lightweight applications.

Time, Amazon, and YouTube are all large websites who interact with their users heavily online, and certainly not every site we build needs to achieve parity with these. That said, large sites like these are defining user’s expectations about how the web works.

In 2018, We want every site be responsive. Industry standard still includes at least as far back as the 1136x640px iPhone 5S, up through a 5120x2880 5K display, with emphasis in the 1600x900 through 1920x1080 range; and that doesn’t even get into pixel density. Further, we want every site to be interactive. Even if its a a carousel, filtering, or validation, in 2018 we don’t expect the whole page to change every time we click.

There are non-responsive sites out there, but they feel old and a little broken. In 2008, the average visitor was more forgiving when they came across a site that didn’t work right on their phone. In 2018, they’ll ask why the site doesn’t work, or worse — simply leave.

Here we are

In 2018, we have to worry about mobile, responsiveness, accessibility, and integration to do similar things to what we did in 2008. Here’s the kicker — we’re doing a lot more complicated stuff now than we did in 2008. We weren’t using autoplaying videos as edge to edge backgrounds on homepages. We weren’t concerned with emulating weight and momentum when you drag elements around.

What’s more, is that a lot of front end developers started with design backgrounds as the job was mostly glorified typesetting. In 2018, it has more in common with traditional application UI development normally done by people with programming backgrounds.

The need for more programming heavy work brought programming tools to the frontend. Gulp, Grunt, and Webpack came from make/ant/rake. Bower, npm, and yarn came from PEAR, CPAN, ruby gems. NPM is only a server side tool to start. CSS conventions are giving way to UI frameworks, that are increasingly like UI toolkits we’d expect from desktop apps.

Conclusion

A pessimistic designer working through these times may end up frustrated; tasks they could do before without programming are now require programming. At the same time, I rejoice. Especially with PWAs, webapps are ubiquitous and powerful. Technology and browser support are rarely what limits us now; it’s just time and money.

In the past ten years, languages that had become stagnant have become fresh, revitalized, and are taking on challenges that they never would have before. Slack Desktop, Atom and VS Code, Hyper, Discord are all built with web technologies. The majority of people reading email on a computer are using Gmail, Outlook.com or Yahoo Mail. It’s not just that more and more people and businesses are online; more and more things that used to be done in Desktop applications are being done in web apps.

In 2008, the challenge was in doing something simple that worked across IE6, IE7, Firefox 2, and Safari 3. Google Chrome wasn’t released until the end of the year.

In 2018, the challenge is what we can get done within time and budget. With support for PWAs on the rise, even assumptions like “you need to be online to use a website” are re-assessed.

Web development is the future of application development. I’m glad to be a part of it.