I don't pretend to make bold (no pun intended) claims that the web has everything, despite its inherent flexibility to run on a myriad of devices from phones to smart watches to gaming consoles. While as authors of web content, we do have access to a plethora of HTML elements, most have reached a consensus in the community that the web platform lacks native elements. Reading through Adam Argyle's CSS predictions for 2020, it became clear to me that we still have a long way to go before we can say that the browser has finally finished evolving. In fact, I realized that whereas in the past years, the honess may have fallen on to us as developers, browser vendors now need to play catch-up with us.

Browser vendors need to up their game and listen to the users -- not to the cash. The steady influx of dependence on frameworks has caused browser vendors to concede defeat, leading to an attitude of procrastination. But we can change this by making the issue known and by looking back -- to the year of 2019 in review for web development.

The State of The Web in 2019

2019 brought us the advent of "front-end dev tools": tools like the static site generator, the proliferation of the virtual DOM, a neverending onslaught of new frameworks, and, in some rare cases, a much-needed call to action to reduce website payload size. The latter went mostly unnoticed.

A lot happened in 2019, but one thing definitely didn't:

We still use frameworks. A lot.

Whether we like it or not, the bias remains in the complex question when we ask "which" framework developers prefer. How does this surprise us in an era of shiny new toys and constant push towards consumerism?

Framework "Hell"

In a world where "framework hell" seems to dominate authors' minds, it seems odd to turn to yet another file of JavaScript. After all, why add to the complication of a new library?

Sure, we may not have <details> or <dialog> to play with in production, but that certainly doesn't mean we need to use JavaScript.

HTML Failed Us

In a perfect, world, we can use the new features (of HTML5.1) that browser vendors provide us to keep our sites accessible and our markup semantic. However, looking at "modern", "evergreen" browsers sheds light on how they really embody the antithesis to our ability to move forward in this endeavour; the lack of support accross all the "evergreen" browsers makes a polyfill required at the very least. And -- I think -- most of us would agree that going down the polyfill road leaves much to be desired.

• <details> works effectively, really only in Chrome
• <summary> removes any semantic meaning from its child elements
• <dialog> lacks support in major browsers and becomes confusing content authors to focus

So you might think, then: "sure, then I can still use <details> in production if I don't nest anything under its <summary> tag". Or perhaps, even, "I won't use 'modal' dialogs, then; I'll use inline <dialog>s instead." Sure: you can do this for FAQ sections where the question appears in the <summary> tag like so:

FAQ Question

Answer to FAQ question

<details>
    <summary>FAQ Question</summary>
    <p>Answer to FAQ Question</p>
</details>

While this approach works, it still doesn't alleviate the need for native controls for accordions -- though, admittedly, the functionality closely resembles them.

JavaScript Emerged Victorious (Again)

Oh, JavaScript... dreaded JavaScript.: the language built in under 10 days, and yet over 60 percent of jobs require

It really saddens me to see how framework "hell" has stifled the development of custom components; a large cause of the stagnation in development can easily be traced back to competing arguments about architectures from competing system designs. Vendors really have to commit to these designs, and as there exists no right way to implement a loading spinner, the browser vendors have to double down on their approach. As a result of these 4 chan-like debates, we end up with quasi-finished "components" only shipped in nightly or canary editions.

It only takes a matter of months before we come up with a new way to lazy-load iframes even before it ships natively in browsers. In these situations, we really do have to ask ourselves how browser vendors have managed to stagnate behind in such an obvious way.

1. Lazy loading. We had ways of caching and preloading images well before rel="preload" became a thing (and it still remains heavily unutilized); a thousand jQuery libraries existed to lazy-load images well before the spec became solidified. Now we already have predictive libraries outperforming native rel="prerender"
2. Progress bars. We had <div>s with inline styles like in pretty much every "fake" "progress bar" pen. Even today, web authors still neglect the <progress> element because of non-uniform support.
3. HTML Imports: the technique got polyfilled far eariler than its inception server-side, and though the Polymer project offers spec-compliant features, production-grade techniques already exist that work in older browsers

Ultimately, it seems abundantly obvious that authors seek consistency. As in: authors don't want users to have inconsistent experiences across different browsers. Makes sense, right? After all, Don Norman, the alleged king of UX, lists predictability and affordance as two main facets of effective design heuristics. Imagine if your users couldn't find the navigation after they switched to a new browser. Why does the progress bar look different?

Let's remind ourselves: it wasn't always this way.

Browser vendors, at one point, had the edge in the race between web authors and we found ourselves amazed at the "revolutionary" and "new" features the web brought forth. New additions like:

• Flexbox
• CSS Grid
• CSS Custom Properties
• fetch, MutationObserver, and IntersectionObserver JavaScript APIs
• get, set, and static/#private instance variables
• <menu>, <menuitem>, and native contextual menus
• <template>, and the beginnings of the shadow DOM

At the onset of 2017, these features seemed remarkably ahead of their time. But now that 2020 has arrived, we see browser vendors focusing on small performance bug fixes instead of fixing bugs on these newly-landed features. Flexbox has been stable for almost three years now. CSS custom properties work in Chrome and Firefox, lack support older browser versions like IE10 and Opera. CSS Grid has effectively landed, but only after a long two-year stint of development debates, and web authors still don't adopt it due to minor inconsistencies. And where is CSS subgrid? How can we fix this support issue without hammering on browser vendors?

fetch has shoddy support in older browsers such as IE, and while MutationObserver and IntersectionObserver work, we see long writeups describing their use. Browser vendors should have shipped with Object.Observe support (it even landed in Chrome canary 25), but browser vendors ultimately decided to ditch support in favour of performancce.

<menu> got removed in the HTML5.2 specification along with <menuitem>, so we won't see any of those additions despite their obvious use cases.

<template>, along with the custom element API, have promised to deliver "game-changing" APIs for developers, but we still haven't seen any uniform support for over five years. We got promised <slot> last year, but no stable polyfill solutions presently exist apart from polymer which currently lacks in documentation and usage. Only VueJS and a few other smaller framework vendors have attempted to follow the spec, and even VueJS falls short of enforcing W3C-compliant HTML.

Web components still don't work.

So what happened? Why have browser vendors neglected to continue to deliver innovative additions to the native web API? Why did FireFox conclude this year by shipping a Picture in Picture API only instead of fixing the blaring problems outlined above? Did "frameworks" catch up, or did browser vendors get caught up in the "browser wars" to try to gain market share to track user data?

The Framework Vendors Won

Whether we like it or not, we have to start by acknowledging the fact that earlier in 2018, browser vendors lost control of the web platform. At some point, developers conceded that the fight for proper semantic HTML just isn't worth it; with only 63.13% of developers performing accessibility testing, browser vendors clearly haven't offered the full piece of pie they desire.

Even in the past month, I observed a very lazy mindset within the HTML working group wherein they don't want to take a side while frameworks all have differing opinions.

The same thing happened with Object.Observable¹, a now-abandoned spec in the EcmaScript standard. An outlash of angy developers urging browser vendors to adopt their way of writing them -- ultimately culminating in the release of Angular 2 (bundled with RX.js). This marked the turning point for standards commitees leaving framework vendors to lead the way in innovation.

After all, if someone starts taking over your kitchen and making better food for themselves, why would you continue to cook for them when they'll have every ability to provide for themselves?

Frameworks, by contrast, have a simple and unambiguous way to pass data into a component.
Rich Harris

In an unfortunate twist, framework vendors have defaulted to bearing the role of innovation. The saddest part is that no one seems to care about this; those of us who started long enough ago to remember when the EcmaScript committee had presiding authority over web standards don't seem to voice our opinions in fear of entering the heated discussions surrounding "framework wars". Most of us developers who lived through this transition have now assumed more senior roles which more closely follow the adage "if it ain't broke, don't fix it."

Predictions for 2020

A Stronger Focus on Documentation

In an industry that almost always requires us to learn every day, a strong focus on documentation seems a natural result. Whereas new vendors can easily come out with a "hot new technology", as in the "bootstrap wars" of CSS, it has become clear to "framework" authors that the system with the superior documentation wins out.

But this shouldn't surprise us; people are lazy.

In a race to have "the best framework", framework vendors will place extra care on providing "copy-paste" solutions to eager developers who "just want to get the job done". This intensified competition for adoption will result in a search for ways to make menial tasks easier like creating tabs or an accordion. Framework vendors will look for ways to make their systems seem more intuitive and simple by:

• Drawing more comparisons to other popular frameworks
• Adding more dependencies
• Thorougly documenting usage

Documentation only gets developers part of the way to completing their task; it seems inevitable to me that authors will find themselves turning to more tools to escape the aforementioned inadaquecies of the web. Inevitably, in a developer's allegience to a given framework, they will encounter a functionality which doesn't yet exist. This will trouble the developers, causing them to look for even more tools. The vicious circle will repeat itself until a large tree of dependcies has been amassed. But throughout the struggle, they will remain strongly attached to the framework(s); in fact, this whole struggle will cause developers to become even more attached to frameworks.

Increased Framework Adoption

We all want a canned solution to our problems. Just look at modern-day materialism: a new skin-care solution, a new car, a new set of clothing to give us a temporary high and give us a buzz feeling for a week or so -- until the novelty fades away and we find ourselves in search for the next "big hit". At work, most developers just want to move on and get work done; they don't care whether they use a framework or not -- they just want to get their work done. Whether we like it or not, we are all results-driven in the end. Browser vendors see results when they get higher adoption, and in an economy where seconds of difference made marketing campaigns for major browser vendors, it's no surprise that vendors don't care about standards anymore.

Frameworks will continue to grow in 2020, and browser vendors will completely concede control over the DOM to the user. They will market this as a good thing, trying to increase adoption to collect user data (not Firefox, of course). Page load speed will actually decrease in so doing, but browser vendors won't care about that because they'll pin that problem on "bad developers".

Increasing Developer Confusion

With an increase of frameworks, developers will find themselves at a whim when it comes to deciding on the best approach to author web pages. Elements like <details> will get phased out in favour of drab <div>s which already pollute an extensive amount of ReactJS code. Developers will constantly face questions like:

• Do I use HTML in JS, or do I separate my files?
• Which framework do I use?
• How do I test my code?
• Where do I deploy my application?
• Do I need a virtual DOM to build performant apps?

Framework vendors will continue to market their solutions as the "ailment" to all development woes. New developers will be forced to side with a competing framework, and in so doing, will limit themselves to those jobs which only use the technologies. Developers will become siloed.

Hybrid Framework Solutions

2020 will bring forth a new genre of framework -- one very similar to the jQuery plugin ecosystem that emerged in the early 2010s. Framework vendors will begin to rely more heavily on more prominent framework players, like ReactJS, VueJS, and AngularJS. Interest will probably decrease in EmberJS, while people want to focus on monolithic, "isomorphic" app development, despite its fastboot SSR capabilities. We will see more server-rendered, hybrid libraries which will advertise themselves as "SSR" for "SPA" -- server-rendered pages for single-page applications. Just last month, an onslaught of these hybrid counterparts appeared on GitHub. We'll start to see competition for NuxtJS, Preact, and other SSR frameworks. In the same way that ionic started the "native on mobile" battle against PWAs, we'll see an increase in frameworks that depend on a framework. It will all seem meta at first, but in a few months, developers will accept it as a reality.

Static Site Generator Addiction

As developers turn to frameworks to solve their ego issues, they will gain increasing exposure to static build tools (AKA static site generators). Tools like gatsby, nuxt, and statamic will continue to gain traction, leading many deveelopers to hop on board before fully thinking out the sever-side requirements of their applications. This, in turn, will cause an uptake in serverless adoption, along with the microservice architecture. Within 2021, server-rendered pages with "hydration" will be an afterthought. Soon after, a slew of new tools to debug server and client in tandem (think webpack hotloading but for the server and for the client). For those of us who started before 2014, it will remind us of the early days of meteor.js.

Less Polyfills

Browser vendors will stagnate in their innovation, and with the increase in package size, less importance will be attributed to using "new" browser features.

Polyfill services will become hipster and outdated compared to "normal", "framework" approaches to doing things. APIs like fetch will get used gratuitiously well before browser vendors even catch up while developers often forget that IE 10 still doesn't support them. Polyfills will soon after become hipster and "old-school".

Instead of polyfills, we'll see an increasing amount of framework adoption. Players like svelte already bltantly market the ability to write less code but fail to mention the technical debt associated with it -- even if it is built-time (anyone remember CoffeeScript?). Regardless of the tech debt, web developers will continue to prioritize less code over standards-compliant code

Neglect of HTTP2 and HTTP3

Solutions like webpack will continue to grow. The community has already spoken, and webpack has emerged victorious in 2019. With the growth of packaging tools, we will observe a continued adoption of monolithic packages which fail to leverage HTTP2 multiplexing and async defer <script> tags. Instead, we will see an increasing amount of web pages which only list one giant, 3mb .js file.

<script type="nomodule"> and <script type="module"> will get ignored for the most part, leaving no reason for <script type="nomodule">. Developers will already find themselves impatiant with learning and keeping up to date with yet another framework.

HTTP3 will not matter, as a result, while popular web servers like nginx and Apache severely lag behind to catch up. We will continue to see detailed tutorials on configuring apache and nginx for HTTP2 even towards 2021.

Increased Security

Following recent data breaches, browser vendors will seek to market themselves as "more secure". Features like DNS over HTTPS and DNSSec will continue to promise users anonymity in their DNS queries, but a backdoor will inevitably surface with the implementation. Microsoft will quickly act to patch it, but the damage will already be done and users will seek redemption by switching to other, competing browsers. Unbenownst to them, the other browsers will use the same underlying web rendering engine (webkit), so it really will make no difference.

Nonetheless, browser vendors will pretend that their browsers get more secure. Naiive developers will believe them. I will continue to use SRWare Iron, and very few people will know how to anonymize their data.

Less CSS

In 2020, people will stop caring about fancy loading spinners, "blazing-fast" single-page applications, and content that appears above the fold. 2020 will confirm that content administrators have tools like Squarespace and Wordpress.com to create fancy websites with terrible accessibility themselves. 2020 will usher in an era where content reigns king, and with it, a wave of minimalism will follow. In an era of constant information and media bombardment, people will seek simplicity. Concepts of zen and simplicity will govern a vast majority of new sites and yet, ironically, these sites will depend on a myriad of build tools and server-rendering build tools like netlify and contentful.

With all of that said, CSS will become an afterthought. CSS in a .css file, as a concept, will slowly die away in favour of "all the code in one file". Frameworks like tailwind will become defacto solutions in favour of antiquated solutions like Bootstrap -- or even Zurb Foundation. Authors won't see the need to write CSS anymore, and so the concept of CSS custom properties will also die away in favour of "CSS in JS". We will see an uptick in "less is more" -- AKA minimalism -- and with it a neglect for styling altogether. Styled "components" will come included and fully-functional in almost every design system, so developers will feel entitled to them.

More DevOps

People will seek simplicity in their app designs but instead will find increasing levels of complication in their build tools. Tools like front-end application bundles will encourage developers to break their application into microservices, but the vast array of build tools required will scare most developers away. As a result, developers will find themselves forced to learn app scaffolding tools like terraform and docker. Virtualization will become an afterthought with services like Cloudflare Service Workers and netlify functions (AWS Lambda functions). Developers will come to expect fully-functional sandboxes for cloud functions.

Extraction layers to popular "serverless" architectures will spread like wildfire, and web authors will find themselves challenged with navigating this landscape in the same way as they deal with "framework hell". Deploying to a myriad of services (like with FAB) will become par for the course, but settling on just one place to run cloud functions will become a challenge. As a result, serverless authors will find their functions spread out across multiple providers, making the tracking of API endpoints require, at the very least, a reverse proxy like Cloudflare or Cloudfront.

Conclusion

2020 may not seem all that bright for those of us who have been involved since the early 2010s, but that doesn't mean we have to complain about it. Just because others have decided to favour approaches rich in dense resource payloads doesn't mean we need to.

Chris Hawkins explains in his follow-up video on ditching reactJS that the prevalence of ReactJS in today's market may, in fact, have been one of the best things to happen to him; we not only get paid more as experts in a given technology, but it helps us come to value the true versatility of the web. While the patterns often found in ReactJS like the flawed flux architecture may not have uses outside of Facebook's corporate body, other patterns like immutability in immutable.js and TypeScript do teach us a valuable lesson about the flow of data. Indeed, while the struggle intensifies in choosing "the best tool", I venture that a small, enlightened portion of us will truly come to appreciate the open nature of the web.

There exist solutions for those of us who like to follow the spec: tools like the polymer project and lithtml, which have existed since the early days of the spec, allow developers to use the latest draft of the Web Components spec to build components. Paul Irish's latest iframe YouTube embed hack uses it.

And for those of us framework-inclined, tools like emberjs allow us to separate our templates and our CSS from our view(s). We can easily build in static HTML or vanilla JS -- a tool which, whether we like it or not, will definitely be applicable in two years, regardless of which "hot framework" maintains dominance of the market.

The choice is ours.

We don't have to make an assumption that our users expect "single-page application" behaviour from our products. Users may, in fact, not require single-page applications. I often get asked in response to these sentiments what we should do instead, and my answer remains the same: conduct user testing rather than assume requirements.

The nature of the web browser means that we can build any app with some of the oldest server architectures. ASP, Java, even static HTML (who would have thought?) -- the flexibility of the web browser means all of these technologies can still work, even despite their decades of age. We need not despair in 2020, for despite the steps back we've taken, the browser still remains one of the most accessible and open technologies to date.