The NeXT™ Big Thing
What’s the most important thing to come out of Switzerland? Chocolate? Clocks? Neutrality? The largest, most expensive scientific experiment in history which may eventually unlock the very secrets of the universe and unify our understanding of the smallest particles with that of the largest of heavenly bodies? No, none of these things. The answer is, of course, is the Internet.
More specifically, the World Wide Web, which popularized the Internet. In 1980 when I was just an embryo in my mother’s belly, the internet was but an embryo in the mind of Physicist Tim Berners-Lee, who created a simple hypertext program called ENQUIRE as a personal database of people and software models.
Tim was later tasked with inventing a clever way for the scientists working on CERN to easily share data sets and documents with each other. So in 1990 using his super cool NeXT Computer (known as “The Cube”), he expanded on his hypertext ideas and created the first version of HTML. The goal was to provide a simple and effective way for creating, sharing, and connecting documents together. He then created HTTP (hyper text transfer protocol), the first web browser, imaginatively called WorldWideWeb, and the first web server.
Most of the technology involved in the web, like the hypertext, like the Internet, multifont text objects, had all been designed already. I just had to put them together. — Tim Berners-Lee
While he may not have invented the internet (like you know who), his World Wide Web was the spark it needed to spread like wild fire.
Do you remember the first time you used the internet? I do. I was around 8 years old at the time these text based web browsers were created and can remember my brother showing me out to use one of them. I wasn’t sure what the appeal was, but a few years later I logged onto AOL for the first time and found my way to a real-time chat room. I can still remember the first message I wrote:
“Socker sucks!” — Mark Nutter, 12 year old soccer hater
My first contribution to the Internet! Needless to say, I was hooked. I can also remember creating my first website when I was a 14. In fact, I still have the original source. Behold!
Sure, this may not seem very impressive by today’s standards. Well, actually, it’s not really impressive by 1994’s standards either. But what is impressive is the fact that I loaded this up on the latest version of Safari, and aside from a few missing gifs, it looks pretty much exactly the way it did when I created it back in 9th grade. This is a testament to the beautiful simplicity and expressive power of HTML. That a 14 year old kid can learn how to whip up his own little corner of the internet in a few hours that can still offer “wicked images and cool music” using the latest tech some 20 years later is nothing short of amazing.
Tim Berners-Lee based HTML on the then popular Standard Generalized Mark-up Language (SGML), which was an internationally agreed upon method for marking up text into structural units like paragraphs, headlines, italicized blocks, etc. Except instead of simply sticking to text, he thought “why not add links that could take you to other documents? Why not images that can show charts, graphs, and cats?” Why not indeed?
In his personal notes, he listed ‘encyclopedia’ first as a possible use for HTML. I’d say he pretty much nailed that one on the head. But we’ve gone way beyond Wikipedia.
Those were much simpler times. Today, the landscape of modern web development seems be in constant Flux. We’re fast approaching a fork in the road which may change the Web as we know it. Is Tim’s original vision of a Web where anybody can participate without needing fancy tools or deep knowledge of programming under threat? Or is the Web browser becoming an application platform; a compile target for an ever growing sea of “apps”.
To understand the future, we must look to the past.
The Browser Wars
In the year of our lord, 1990, the first web browser, WorldWideWeb, was born. It was a peaceful, enlightened time where text-only information flowed unmolested between intellectuals for the purpose of pushing the boundaries of scientific discovery.
Three short years later in 1993, that period of relative peace and tranquility was shattered by the Browser Wars. Mosaic, the first popular graphical web browser was released and it fueled the meteoric rise of the Internet. Later renamed Netscape, it fended off a bevy of competing browsers to capture a near 90% share of all Internet users in just two short years. But such success would not go unnoticed.
In 1995, tech giant and evil empire Microsoft unleashed its first web browser, Internet Explorer 1.0 — a licensed rebrand of the Mosiac browser. A bloody and protracted battle ensued between Netscape and Microsoft as they fought for Internet dominance. In war, technological advances abound, and this war was no exception. Microsoft created CSS and iFrames. Netscape created the amazing <blink> and<marquee> tags. And of course, we can’t forget everybody’s favorite web language..
On the 11th Day He Rested
Ultimately, Netscape was unable to compete with the juggernaut that Microsoft had become. After all, Microsoft controlled Windows, and Windows dominated the computer industry. While Netscape relied corporate licenses for revenue and explicit downloads for the free personal edition, Microsoft simply forced IE on all its users. Netscape’s marketshare dwindled to less than 4% of all users by 2002.
The Internet bubble had burst, and with it, all the optimism surrounding the Internet. Microsoft’s anti-trust case resulted in a mere slap of the wrist. A dark shadow was cast over the World (Wide Web). Hope gave way to dispair. The Web stood upon the edge of a knife. Stray but a little, and it would fail, to the ruin of all. Yet hope remains, while the company is true.
From the Ashes Arose a ..FireFox?
Like Darth Vader’s Empire (or Kylo Ren’s First Order for you younglings), Microsoft’s grip on the Internet appeared unyielding and absolute. Practically all browser innovation ground to a halt after Microsoft released its infamous Internet Explorer 6.0. Like some sort of dystopian government issued slurry, web developers were forced to survive off of a browser locked in time. Microsoft turned its focus to other sinister projects like ActiveX, FrontPage, and SilverLight.
But the clouds began to clear. It was around this time the open source movement started to truly pick up steam. Linux was proving that thousands of distributed hackers working in their spare time could write a better operating system than the largest tech company in the world. Netscape had open-sourced much of the code for Netscape Navigator to be shepharded by the non-profit Mozilla Foundation.
Originally (and more appropriately) branded “Phoenix”, FireFox was released in 2002 and would introduce features like a separate built in search bar, tabbed browsing, private browsing, a built-in spellchecker, and a download manager. Y’know, like, all the amazing features we take for granted today; the amazing fearures Microsoft should have been working on? Geeks throughout the world — sick of supporting their family members’ spyware filled computers — began installing and promoting Firefox and Mozilla slowly started to recapture Internet marketshare.
Most importantly, Mozilla put web developers first. They provided best-in-class debugging capabilities; first as integrated features and later through 3rd party extensions like FireBug. Suddenly it was cool to be a web developer again. A renewed focus on accessibility, clean, semantic markup, and table-less layouts sparked a renaissance of web design. The tides of the Web were about to change once again.
A New Hope
Slowly but surely, FireFox began to claw back market share from the Empi.. —er, I mean Microsoft—reaching its peak at 30% of global marketshare in 2010. Like most large occupying forces, Microsoft was slow to respond. Along the way Mozilla found a powerful ally in a little Internet startup called THE GOOGLE who paid handsomely for the privilege to be Firefox’s default search engine.
We were entering the Web…2.0!!!
Focus shifted from mass consumption of mostly useful content to mass creation of mostly worthless content. Blogging, multimedia sharing, public APIs, mashups, and social networking exploded in popularity in the years following 2004. The open technologies developed during the heights of the Browser Wars were now starting to be utilized to their full potential. Closed and invasive technologies like ActiveX, Java, and Flash were being tossed aside in favor of more open, standardized, and accessible web technologies.
The web was no longer just network of linked together documents. It could be interacted with, contributed to, remixed, watched, played with, mashed up, pitched, and IPO’d. It began its disruption of entire industries who were clinging to dying business models. As more and more people joined in on this second renaissance, a new bevy of tools were created to aid developers in creating these much richer experiences.
Click. Wait. Click. Wait.
Now I will say something that may shock some of you younger folks. You will likely dismiss it as the ramblings of a worn and bitter old curmudgeon.
Most web apps in the late nineties and mid 2000’s were completely stateless. In other words, everything that the browser rendered was thrown out and replaced wholesale on every single click. For developers, this was wonderful. You only needed to worry about state on a per-page basis, and that logic only lived in one place: the server.
It was around this time I started my web development career. I graduated from the U with a degree in — of all things — Physics with the hopes that it would land me a job at Barnes & Noble or a trendy Coffee Shop. But like many of my fellow college classmates, things didn’t go according to plan (you need at least a master’s to get a job at Barnes &a Noble).
Luckily, my much smarter brother suggested I take a look at a new web framework called Ruby on Rails. I was bored and unemployed so I thought “why not?” and gave it a shot. I then proceeded to gain more practical knowledge in two months than I had in 6 CSci classes at the U of M. With Rails, software development finally clicked for me.
I was hooked and I went on to learn the ropes of freelance development and play startup roulette whenever I could afford to. Rails was the perfect companion — but then again, I am a frameworks guy. I could prototype fast and deliver multiple projects on time and I only needed to know Ruby and a bit of CSS and HTML to do it. It was a simpler time. It was a wonderful time. But then Google had to go and ruin it by creating Gmail and Google Maps.
Write Less, Do More
jQuery rose to dominance because it was especially good at providing the intuitive API that the W3C didn’t. In fact, many of the concepts introduced by jQuery are now being natively added to browsers.
We also started to see the first glimpse of the componentization of the web. jQuery widgets and plugins allowed developers to enhance existing HTML elements with behaviors went far beyond the tags specified by the W3C. And they were shareable, too. If you had a need, there was probably a jQuery plugin or widget to fill it; the problem was in wiring them up and the lack of a standard interface.
Bro, Do You Even SPA?
Chrome burst onto the web scene like a nuclear bomb. Google — no longer comfortable with depending on Mozilla and Microsoft to advance Web Browser technology — decided that in order to push the web forward, it needed build its own browser.
So in the Year of Our Lord 2008, Google officially entered the Great Br0wser Wars with the release of Chrome.
This all paved the way for a calvacade of bloated, over-engineered web applications. I remember my first attempt at writing such an abomination from scratch using jQuery. It didn’t take long to end up with what is commonly known as “jQuery sphagetti code”. I did however learn few things along the way.
1) Don’t do that.
2) Look for a library or framework written by someone smarter than you.
Think for a second about what Twitter effectively provides as a service: it lets people put text on the internet for other people to read.
That’s pretty much it…
This problem was solved 25 years ago.
The point is, there are good candidates for SPA’s and there are bad candidates for SPA’s. Gmail and Google Maps are good candidates; Twitter and blogs like Gizmodo…not so much. When your entire business model revolves around displaying text to as many people as you possibly can, it’s probably best to keep it simple (stupid).
One could argue that SPA’s run contrary to the very spirt of the Web.
- They often break the browser’s back button.
- They’re often unlinkable.
- They’re virtually invisible to screen readers and web crawlers.
- They put unreasonable demands on underpowered devices.
Where the web used to be a vibrant sea of information that could be indexed, remixed, and mashed up, it’s slowly becoming a fragmented collection of walled gardens. SPA’s are bad in all the ways native apps are are bad, but without the performance benefits and access to most OS-level APIs.
But, this hasn’t stopped us foolish web developers from charging ahead with a never ending parade of tools, libraries, and frameworks to convert our perfectly good stateless web apps into SPAs. So let’s roll up our sleeves and examine the current landscape of Web Development tools.
Libraries vs. Frameworks
So much of the landscape of modern web development is a culmination of the great Libraries vs. Frameworks debate.
While Frameworks eliminate choice paralysis and imposter syndrome, they can be too magical and hide too much behind layers of abstraction. Libraries are easy to understand and provide freedom of choice, but you are often worried about whether or you’re doing things The Right Way™.
The truth is libraries and frameworks both end up being equally complex to work with precisely because the problem of building large applications is inherently difficult. Frameworks make the first 80% of a project a breeze while leaving the real work to the last 20%. I find the reverse is true for Libraries.
Really, it all comes down to personal preference. Ask yourself:
Are you the type of person who is more likely to believe you can do something better than everyone else, or are you like me and more likely to defer to those you believe have more expertise than you?
Are you decisive or do you agonize over the smallest choices?
Do you feel a compelling need to understand how everything works, or are you willing to implicitly trust other people’s systems?
Are you a get-things-done type of person, or a do-things-right type of person?
These are questions to keep in mind while we examine two of the most popular offerings available today.
Angular’s two-way template binding felt like magic. It relieved us developers from having to write the same boilerplate logic to update the DOM again and again like we had grown used to doing with libraries like jQuery.
Angular’s popularity skyrocketed and enjoyed a brief period of supremecy as the new hot tool of choice. But this is the front-end, people — nothing stays on top for more than a couple years.
Although the hype surrounding Angular at the time was deafening, it had its stark critics who criticized its large API, use of eccentric terms like “transclusion” and “directive”, and relatively high learning curve. Naming has been a recurring problem for the Angular community. Its popular test runner Karma was originally called “Testacular” before it raised too many eyebrows. Two-way binding was also widely criticized as an anti-pattern that could lead to state management hell.
Then the Angular team found themselves between a rock and a hard place. Because they were working a few desks down from the Chrome core development team they were acutely aware of the coming Web Components specification. The problem was they hadn’t written Angular 1.0 to be compatible with them — instead treating it as a stopgap solution. Despite its popularity, they made the difficult and controversial decision to deprecate the entire framework and create a new version from scratch called Angular 2.0.
The news that there would be no backwards compatibility or clear upgrade path sent shockwaves through the community. Angular might have been able to ride out this period of uncertainty if it had not been for an little open source project started by none other than Facebook.
For Every Action…
The story behind React goes something like this: Once upon a time, some Facebook front-end engineers were having a hard time getting a notification icon to work.
MVC had failed them in a big way (or they had failed MVC, I forget which).
Anyways, they assembled the greatest front-end minds in the company to examine the problem. They came to the conclusion that “MVC doesn’t scale”. As we all know not scaling is one of the 7 deadly sins of OSS libraries (like the sin of not being backed by a large software company or the sin of existing for a more than 4 years).
So they did what any reasonable, pragmatic software development team would do when faced with a common problem that’s been solved many times by much more experienced developers: they took a proven, off-the-shelf library and integrated it following industry standards and best practices….
..nah, just kidding. This is the front end, people — they rolled their own framework!
Obviously this is a dismissive tongue-in-cheek oversimplification of the reasoning behind creating React and Flux, but it’s important to take a step back and ask ourselves why the tools we use were created in the first place. The truth is often far more nuanced than you think it is. The problem of getting a notification icon to be consistent across disparate components was symptomatic of a much larger problem that exists when creating and maintaining large, dynamic, single-page applications: managing state.
On a small enough team building a simple enough SPA, these problems can be mitigated through good communication and engineering processes. But when you have dozens of teams working on the same application (e.g. at Facebook’s scale) you’re going to have a hard time not stepping on each other’s toes. As was mentioned before, Facebook is a PHP shop and its engineers pined for the good ol’ days when you could simply refresh the page with completely new content — guaranteed to be consistent and correct. But they knew they couldn’t go back to the old click-and-wait pattern that users no longer had the patience for. So they started out with a very radical proposition.
They asked themselves “what if we just replaced the entire body of the DOM with the entire updated UI every time any new data is retrieved using innerHTML?”. Sound expensive? Well, it was. But not as expensive as you might think it was. Intrigued, they started working backwards from that conclusion, crafting a very sophisticated diffing algorithm which they cleverly branded the “VirtualDOM” which essentially acts like a single call to innerHTML but that only replaces the elements that actually changed rather than the entire tree of elements. In doing so, they were able to simulate the same mechanism stateless web applications relied on to render templates generated on the server. No more worrying about those pesky notification icons, the server was now back in the driver’s seat.
React has sparked a growing movement towards functional programming for the web. A pure function only takes inputs and returns an output — much like React components simply take properties and return DOM elements. The beauty of this approach is that you can define your entire app as a series of calls to these functions, reducing the current state of the application down to its new state.
Web Components and the Componentization of the Web
The truth is, React, Angular, Ember, and to a certain extent, jQuery (via its “widget” pattern) are — in a way — all glorified polyfills for web components. But what are web components exactly and why should you care? When HTML5 landed it brought with it a bevy of new tags like <canvas> and <video> that allowed for the creation of much richer and more semantic web sites. It also brought with it more API’s for interfacing with OS level APIs like geolocation, websockets for realtime pub-sub messaging, support for offline apps, web storage, and more.
But what became clear to many developers, including the Google Chrome core team, was that custom tags should really be created by the wider web development community rather than decided on by a slow moving standards committee and implemented natively by browser vendors six ways from Sunday. This was the conclusion the wider web development community had come to may years before, of course, which is why tools like jQuery, Angular, Ember, and React were invented.
Web components are really a formalization of this wider desire for a standard around creating and sharing custom HTML elements. While it was great that independent efforts had allowed developers to componentize their own applications, they are often not compatible with each other. This leads to a ton of churn creating the same components X number of times.
Web components consist of four key technologies.
- Custom Elements — this is what comes to mind when most people think of web components. Up until now, the set of tags that we had available to us were finite and dictated by the W3C. With web components, we can now tell the browser about a completely new tag and it will inherit the base prototype of the standard HTML element along with whatever additional behaviors we want to include. Finally, the internet can have its own <cat> element.
- Shadow DOM — Not to be confused with React’s Virtual DOM. Part of component-based software engineering is the concept of separation of concerns. CSS by its very nature relies on poluting the global scope. This is the way it “cascades” after all. But when you want to break your application into isolated components the last thing you want is some other element’s styles infecting that of other components. Shadow DOM allows the isolation of styling at the element level. Outside styles can’t get in, and inside styles don’t leak out. In this way, a web component can be transported into any web application and retain its look and feel.
- HTML Imports — this is one of the more controversial features of the web components specification and is a big reason why it has taken so long for the major vendors to agree on a 1.0 web component specification. It basically provides a way to easily import all a web components’ dependencies via a single require tag so that all anyone would need in order to add someone else’s web component to their page is include a single tag and go about adding that element to their page where ever they like. This specification is in direct competition with ES6 modules, however, and the wider web community is still very much divided on the subject of dependency management.
While these features sounded good to most people in the industry at the time, getting the major browser vendors to agree on how they should be implemented was another story altogether. First proposed in 2012, Web Components are only just now starting to show up in the major browsers with Google’s Chrome being at the forefront of adoption. In fact, it wasn’t until last April (2015) at the W3C summit that final agreement on a 1.0 spec for Web Components was reached, and that only happened because somebody locked them in a room and told them to reach a compromise on each of the features proposed in the spec. They agreed on implementations for three out of the four before lunch and knocked the last one after reconviening.
So now that we have a 1.0 spec and we’re starting to see the full web component specification show up in the major browsers, we can stop the flamewars around tools, frameworks, and libraries. We can stop running from solution to solution like Sneetches with stars upon thars. We can finally share our work and extend the web as one, cohesive community. We can move past the wild west web days where the only constant was change, wheels were made to be reinvented, and fashion-driven-development was the norm. Right?
I mean… right….?
“I definitely think it’s the wrong programming paradigm; I really hope that web components do not succeed”. — Pete Hunt, React Core Developer
There is a lot of stuff you get for free when you build like the browser doesn’t exists and this is one thing that distinguishes React from Web Components and Polymer and that kind of thing …they’re getting closer and closer in with the browser, and we’re getting farther and farther from the browser. And I think that our technique is more sustainable in the long term. — Pete Hunt
False alarm, people. Take down the streamers and let’s get back to work. You see, what Pete is saying here is consistent with the direction the React ecosystem has been heading, and it’s very much influenced by the dichotomy between Facebook and Google. Google is one of the four major browser vendors. Its business model is hinged upon people being on the web. Any fragmentation of that ecosystem into walled gardens like the Apple App store or Facebook hurts Google. So to them, web components and web standards are a big deal. Heck, Google was the group that propose web components in the first place! This is why Google is pumping such an extraordinary amount of resources into its Polymer and Material Design initiatives. They’re saying “keep building for the web”, by which they mean “keep users on the web!”.
Facebook on the other hand is chalk full of brilliant, but mostly young engineers, who find themselves in a precarious position. They control neither a major browser nor a major operating system. They are fully at the behest of those organizations who do, organizations who just happen to be competing for the same advertising dollars Facebook desires.
Sure, they could have pumped the might of their collective engineering prowess into improving the rendering performance of the major browsers and the wider development community would have benefited whether or not they chose to use React.js for their next project, but why help Google by donating precious engineering hours? To React, the browser’s DOM is a render target and nothing more. React is happy to spit out DOM, Canvas graphics, native mobile views, or plain old strings if you want to render from the server.
So what does this mean for the future of the average web developer? Is Facebook right about the web browser being a relic from the past? Should it be treated as just another render target for our applications? Is it ok to over React?
Or do we take Google’s lead and double down on the web, building our apps with Web Components and embrace the ever increasing functionality being added to web browsers all the time? Should you transclude your way into the future with Angular 2.0 or poly-fill-it-’til-you-kill-it with Polymer? Where exactly do we go from here?
A common refrain among web developers today is that of front-end development fatigue. The sheer volume and variety of libraries, tools, frameworks, specifications, and programming patterns has become overwhelming for many. It can feel as though the ground is constantly shifting beneath your feet. This churn is both the beauty and the tragedy of the open web.
Sure, we’re reinventing wheels more than a caveman with Alzheimer’s, but every once and a while something genuinely innovative rises above the crowd. It would certainly make life simpler to have our tools prescribed to us by a benevolent authority like Apple does with its iOS and OS X platforms, but we might also miss out on some killer innovations.
We’re writing coffeescript because we miss how happy Ruby made us feel.
We’re writing ClojureScript because we want to wield the power of God and the Universe.
It’s important we take a moment to pause here and reflect on everything we’ve covered. Tim Berners-Lee’s original vision of the Web didn’t include transpiling, compiling, minifying, or virtual-doms, and it certainly didn’t include anything about it being an application runtime.
Yet here we are, trying our very best to make it one. Web browsers have been in development over 25 years now, and they’ve accumulated a lot of baggage over the years. They weren’t designed to handle scrolling thousands of on-screen elements at 60 frames per second. They weren’t designed to handle notification icons. They weren’t designed to run Unreal Tournament or Photoshop. They’ve always had to contend with the albatross of backwards compatibility.
At their core, they are document rendering applications, but with more stuff bolted onto them than a Mad Max set piece. They were never designed to do what they’re being asked to do today, and if they were they’d look a lot different than to do now.
Hello Web, Goodbye World
There’s a key component of the original vision of Tim Berners-Lee’s Web that I glossed over, and one that may very well be at risk of fading away; HTML was designed to be written by people. Not programmers. Not programs. Not compilers. People. Actual, ordinary, every day people like the scientists at CERN, the cat lover in their basement, the burgeoning young author with controversial ideas, or the oppressed political activist fighting for freedom. People who have better and more important things to do than keep up to date with the latest hipster devstack trending on Hacker News. People for whom Twitter being blocked in their country or going down is more than a simple inconvenience.
This was the whole point of the World Wide Web. Anybody could participate in content creation and it didn’t require any fancy tools, compilers, frameworks, IDE’s, social media accounts, private web services, closed-source software, or college degrees.
That is what the web was all about back in the 90’s. Whip open a text editor, throw some HTML tags and text into a file, link to some other people’s files, and toss it on a webserver. Sure, it wasn’t always pretty, and there weren’t many billion dollar valuations, but it was as open and accessible as it will ever likely be again. And perhaps that’s why Web Components give me hope. What if it were possible for anybody to stitch together a rich, dynamic web application to solve their niche little problem without being a professional programmer? How many innovative creations would we miss out on if developing software for the web was relegated to code wizards in ivory towers?
Embracing the Web with Progressive Web Applications
There is a growing movement that seeks to embrace the desire for rich, dynamic web applications without throwing the baby out with the bath water. Common sense guidelines that seek to remedy some of the common problems associated with single page applications are starting to get attention. Instead of ignoring the browser or abstracting it away, they embrace it. Instead of leaving devices behind, they adapt to any set of capabilities. Instead of living in privately controlled stores, they live on the web.
They’re called Progressive Web Apps, and they are defined as:
- Progressive — Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet.
- Responsive — Fit any form factor, desktop, mobile, tablet, or whatever is next.
- Connectivity independent — Enhanced with service workers to work offline or on low quality networks.
- App-like — Use the app-shell model to provide app-style navigations and interactions.
- Fresh — Always up-to-date thanks to the service worker update process.
- Safe — Served via TLS to prevent snooping and ensure content hasn’t been tampered with.
- Discoverable — Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
- Re-engageable — Make re-engagement easy through features like push notifications.
- Installable — Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
- Linkable — Above all, to preserve the original intent of the World Wide Web, apps must be linkable.
The idea is that we have at our fingertips an impressive variety of browser technologies that, like AJAX was, we aren’t really sure how to utilize in an effective way. The mobile revolution further muddied the waters as developers and users flocked to native apps for their computing needs. Mobile browsers have stagnated in much the same way Desktop web browsers did after IE 6.0 was released. High profile companies like Facebook and Linked in abandoning HTML5 as a business strategy cast further doubt into the web as a platform.
But industry giants have bet against the Web before, and always to their own peril. Could it be that we are on the cusp of another Web renaissance where we once again reject walled gardens and closed platforms in favor of open technologies and information sharing? Perhaps what we need as an industry is for someone to step forward and show us all what’s truly possible in modern web development today like Google did with Gmail and Google Maps.
For a few glimpses into this future, we can look at apps like pokedex.org. It utilizes web workers to handle data operations without blocking UI logic in the main thread. It’s offline first to guarantee quicker initial load times and availability during periods of spotty connectivity. A react-like virtual dom is utilized to efficiently update the UI on the client and to pre-render the initial state on the server-side.
The results are rather impressive. As some of you no doubt know, there are a lot of kinds of Pokemon out there. Yet this humble little progressive web app chews through them like a native application. It certainly wasn’t a trivial effort, and the developer lists several challenges yet to be surmounted like spotty API support across browsers. But this is no different than the challenges Google Maps had to overcome to show the world what was possible.
Google, of course, is very invested in this version of the future of the Web. Its Chrome Dev Summit site follows many of the progressive web app guidelines.
Users find the app the way they find any other website — through the web browser’s address bar. It’s not bubble-wrapped inside a native wrapper and served through a proprietary store. From there, they can add it to their homescreen where it functions like any other native mobile application — top-level, full-screen, and offline capable.
It’s possible that we are on the cusp of a new renaissance in web development, similar to Web 2.0 where we experienced a return to open standards, progressive enhancement, and accessibility. The burning question in my mind is, however, is this renaissance happening too late?
Don’t Be a Sneetch
Sometimes I feel like I’m seeing it all at once, and it’s too much, my heart fills up like a balloon that’s about to burst… And then I remember to relax, and stop trying to hold on to it, and then it flows through me like rain and I can’t feel anything but gratitude for every single moment of my stupid little life… You have no idea what I’m talking about, I’m sure. But don’t worry… you will someday.
We all have to make our best guess about what the future will hold. My advice is to focus on what makes you productive today and ignore all the noise and hype about what’s just around the corner. Ignore people like me who are foolish enough to lean precariously over the bleeding edge. Don’t be a fashion-driven-developer. Don’t be a Sneetch! If you’re productive with jQuery, use jQuery! If Google Web Tools is your jam, then jam on! If you want to create a progressive app, then send me a link when you do. If you want your web apps to be completely stateless and rendered server-side, it’s likely you’ll do just fine (just ask Craigslist). Build for today, ignore the hype, and embrace the future when we get there.
One thing I am certain of: No matter what happens in the future, hang on tight, cuz it’s gonna be one hell of a ride.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!