loading...

11 Front-end Predictions For 2020

beggars profile image Dwayne Charrington ・6 min read

Everyone seemingly has their own idea of what the future looks like, where they see trends and technologies heading. So, I thought I would throw my hat into the ring and share some of my own predictions for 2020 and beyond in the front-end space.

My intention isn't to make anyone angry, so if anything in this prediction upsets you, just remember these predictions are personal opinions and not guaranteed to come true nor are they based on any real factual data.

The rise of anti-frameworks

This one seems to already be happening, but in 2020 developers will start moving away from frameworks and libraries, opting for anti-frameworks in the form of Svelte and other offerings which minimally abstract HTML and Javascript, compiling down to native code.

While existing frameworks and libraries will shift focus away from features and focus on competing with upstarts like Svelte by narrowing their attention to performance and size. You will see frameworks and libraries either evolve or die.

This will all tie in with all major browsers supporting Web Components, as compile-to-code options like Svelte and standards-based frameworks such as Aurelia allow developers to build web applications that compile to Web Components.

React will begin to lose popularity

Do not misconstrue a reduction in popularity with dying, this is not a death prediction. In 2020 React will continue to be the #1 contender in the front-end space and will continue to do so for the foreseeable future, it is simply too big to just die. However, 2020 will see React lose a little bit of its market share as developers flock to other offerings.

Developers often pick React because it is a safe bet right now. It has a massive ecosystem, it is easy to find developers experienced with it. But the ecosystem is so big, it can be hard to make basic decisions and more often than not, you end up glueing together your own faux-framework with numerous packages.

Whether or not the trend of developers moving away from React and other choices towards compilers and "closer to the metal" offerings continue into 2021 and beyond, nobody knows.

Vue 3 will push some developers away

Releasing a new major version of your framework or library can be fraught with danger. Look at Angular with its turbulent release of Angular 2 which fractured the community and drove developers away to other options like React.

As Vue 3 introduces the new composition API and moves away from the Vue 2 class-based API amongst other features, developers concerned with Vue seemingly stepping in the direction of React will begin to look elsewhere. Some in my circle who moved from React to Vue have been making the move back now the honeymoon period has ended for them.

It is worth acknowledging that many of the differences between v2 and v3 of Vue seem to be behind-the-scenes and the way you build applications is largely the same, there are differences and there is also confusion.

Micro front-ends will be all the rage

In 2019, the concept of micro front-ends really started heating up as the community rallied behind the concept. Much like the backend saw a similar renaissance a few years ago the concept of breaking up monolithic front-end applications into smaller apps will be all the rage in 2020.

Eventually, developers will grow tired of micro front-ends and we will see a return to monolithic applications in 2021/2022.

TypeScript will get bigger

There is just no stopping TypeScript and as we saw in 2019 which was a phenomenal year for TypeScript adoption, 2020 will be more of the same. Many large-scale open-source projects such as Aurelia and Vue are rewriting their latest major versions in TypeScript, companies are jumping on board.

All the while, some of TypeScript's loudest critics will continue to peddle their anti-TypeScript agenda, but nobody will be listening. TypeScript is a force to be reckoned with.

Web Components will start to get better and see adoption

Right now, a few high-profile front-end thought leaders love to talk smack about Web Components. While Web Components knowingly have a few technical limitations, 2020 is the year we will see work to unify the specifications and improve Web Components get underway.

As we enter 2021, Web Components will be supported in major browsers and work will have started (possibly completed) on addressing some of the biggest limitations of Web Components, as we see frameworks and libraries in the ecosystem bridge the gap.

Aurelia will gain popularity

If you haven't heard of Aurelia nor used it, Aurelia is a Javascript framework that has been around since January 2015 when it was first announced. Since then, it has been quietly chugging along with continued updates and improvements, and a smaller ecosystem.

Sadly, Aurelia was introduced at a time when some web standards were still in flux when ES2015 was not overly supported and build tools were turbulent (predating the rise of Webpack).

In early 2020, Aurelia will see its second release Aurelia 2 which is a rewrite of Aurelia 1 with the same familiar syntax, expanded feature-set and more alignment with web standards. Now that many of the standards Aurelia abides by are solidified and improved, Aurelia 2 will be poised to take advantage of these better (including first-class Web Component support).

Browsers will take more initiative

For a very long time, the onus has been on developers to ensure they're creating performant and usable experiences for their users. Sadly, even with all of the tools at our disposal, things have not really improved.

Chrome is leading the charge here, in 2019 they implemented support for a loading attribute allowing for more performant loading strategies for images and iframes.

In 2020, we will see Chrome and other browsers begin to progressively enhance web applications by offering improvements such as the loading attribute implemented by the Chrome team.

Progressive Web Applications (PWA's) hit the big time

For years talk of web applications replacing native applications has been going around. However, PWA's have always been seen as these separate siloed things with additional steps to use. Not any more. In 2020, we are going to see PWA's finally given the respect they deserve and developers opting for PWA's over native apps.

Microsoft is already leading the charge on this front, by working on implementing support for PWA's to run on startup in Windows 10. Best of all, this is a Chromium feature and will support other operating systems.

Elm will get much-deserved attention

I think Elm is one of the most underrated languages around. While the focus is on Svelte right now and how it is an amazing compiler that compiles into native Javascript and HTML, Elm which has been around since 2012 has been doing that for seven years now.

I am not saying that people don't already use Elm (because a lot of people do), you just don't hear about it all that much and I think in 2020, that is going to change.

The attention that Svelte receives in 2020 will indirectly put Elm into the spotlight. With its renowned error messaging and lack of runtime exceptions, Elm will cause some developers to fall in love as they discover this underrated gem.

WebAssembly will continue to be fringe, for now

A lot of developers I have spoken to like WebAssembly and agree that it is important for the future of the web, however, nobody knows where to start or what to do with it just yet.

If you asked me in 2018 what I thought would be the hottest technology on the front-end in 2020, I would have said WebAssembly. While a lot of work has been done and support is decent, with a few things built in it already, sadly, WebAssembly isn't quite ready for its prime time moment just yet, but we are getting close.

Until WebAssembly has a safe and performant way to perform DOM-based operations, front-end developers using WebAssembly will be in a small minority who are. Once WebAssembly can cross that bridge and in a way that doesn't introduce a performance bottleneck, it will be a front-end arms race as libraries like React implement things like Virtual DOM in WebAssembly.

Posted on Jan 13 by:

beggars profile

Dwayne Charrington

@beggars

Lead front-end developer @ ia // Aurelia.io core team, 11 years experience, amateur professional developer.

Discussion

markdown guide
 

What? No Angular? Hmmmm.

As for Aurelia, Rob has blazed some amazing paths in the past. But prior to Aurelia 2, I'd give it a poor grade. Rob's attention was split and the product went sour. He'll need a A++ to get some of us back.

My taste for Elm is non existant. I find it's flavor disgusting. Maybe its time to try again.

Web Components? Yes, maybe React and Angular are history already.

Serverless Architecture, yes it's all good and here now!

 

Angular will keep chugging along and being Angular. People and companies who want to use it will continue to do so. But, I don't think anyone is excited about revisiting Angular again. They burned some serious bridges with that rewrite. I think Angular will remain stable. It's a stable enterprise grade framework. A lot of government agencies here in Australia use it.

I think the problems with Aurelia in the early days of its release were not the result of split focus. Rob surprisingly has always been quite active and engaged with the project, as well as the community. Even when he took his job with Microsoft, he was easily reachable by us in the core team.

What actually happened was Aurelia got caught up in the middle of emerging and changing standards, as well as front-end tooling. In 2015 Gulp was still quite popular and Webpack not the defacto standard it really has become now for bundling. The documentation was also sadly a bit lacking.

As a result, some early design decisions also got in the way. But, to Rob and the teams credit, the design of the framework and its stability has honestly been unrivalled. I went from the alpha, to beta and then stable release without there being any serious rewrite-level breaking changes.

Admittedly, it took a little bit of time to rectify those problems. But Aurelia 1 as it currently stands is well documented and easy to work with. I would encourage people to give v2 a go, it is even better (I've been using it in its incomplete state).

I definitely encourage you to check out Aurelia 2 when it is released shortly. It's a complete rewrite, with the same familiar syntax and standards compliance. The project has expanded well beyond Rob, there is a decent core team of developers working on v2. There is even a core team member who participates in TC39 meetings and is helping shape different specifications and shaping Aurelia at the same time. We also have a paid full time core team member now thanks to sponsor companies and the community, which has been amazing for the project.

 

Concerning Angular burning bridges, it can feel as though the entire community is thrown under the bus, when projects die. MSFT is king at this.

However Angular 1 was a terrible, highly opinionated, off the rails, DOA product. How it became the rage shows how much the web world wanted simple binding mechanisms.

Angular 9 is totally different and no longer hijacks Javascript via its older arcane DI system. It now allows full support of latest Javascript and Typescript and Webpack specs. Its CLI makes it simple to use. It's DI now fully supports modules.

It is fast and a natural fit for OOP folks who know MVVM.

 

Vue Hooks isn’t a thing. You’re probably thinking of the Vue Composition API, which is NEW in Vue 3.0. Also, the current APIs and such are pretty much gonna stay.

You might wanna look into things before you try to make predictions.

And tbh, most of them seem quite unfounded.

 

Vue Hooks isn’t a thing. You’re probably thinking of the Vue Composition API, which is NEW in Vue 3.0. Also, the current APIs and such are pretty much gonna stay.

Vue Hooks is the unofficial name many people use when describing the Vue Composition API. I've updated the post to reflect that, but describing them as Vue Hooks is accurate in this context because they are very much modelled off of React Hooks. Vue core team member Sarah Drasner even refers to them as hooks in her CSS Tricks article here.

You might wanna look into things before you try to make predictions.

You might want to look into things before commenting.

And tbh, most of them seem quite unfounded.

Hence the disclaimer right at the top of this post, Tobias. I'll copy and paste it here again for good measure.

My intention isn't to make anyone angry, so if anything in this prediction upsets you, just remember these predictions are personal opinions and not guaranteed to come true nor are they based on any real factual data.

 

Vue Hooks is the unofficial name many people use when describing the Vue Composition API. I've updated the post to reflect that, but describing them as Vue Hooks is accurate in this context because they are very much modelled off of React Hooks. Vue core team member Sarah Drasner even refers to them as hooks in her CSS Tricks article here.

I looked it up, and Vue Hooks is actually a separate library, not the Composition API.

Hence the disclaimer right at the top of this post, Tobias. I'll copy and paste it here again for good measure.

Guess I missed that.