IT Industry Predicting the Future of Web Development for 2020 by Carlos A. Vázquez

At ReactiveConf 2019, Richard Feldman, author of Elm in Action and creator of ‘Elm-CSS,’ made four predictions about how the future of web development will look like by the end of 2020 and 2025.

Feldman explains that back in 2006, web development was significant in web apps, and the LAMP stack was at the dawn of web apps. If you don’t remember what LAMP is, it’s Linux, Apache MySQL, and then the P was overloaded to be PHP Perl and Python.

And the reason that P was so important was that basically, developers did all of the renderings on the server, web developers would generate HTML on the fly and then send it to the browser on every page load.

Also, back in 2006, many start-ups rely on commonly used technology with the most significant library ecosystem, mature in the LAMP stack, and used by successful companies… Perl.

But since 2006, Pearl’s popularity has not been the best.

The chart above is the Google Trends for Pearl searches since 2006. The lesson here is that a commonly used technology is never a guarantee of safety. You have to look towards the future and try to figure out how things are going to be.   

Another lesson here is that when Pearl declined in popularity, companies that try to hire Perl Developers couldn’t find any, there’s not a lot of ecosystem support compared to what they used to be back then.

So it’s not necessarily a problem if something is small, but there it is a problem if people are losing interest in technology and don’t want to use it anymore.

So any technology that we choose no matter how popular how mainstream how much traction it’s got today, it’s still making a bet on the future, there’s no safe option here it’s just a matter of what do we think is going to happen.

The real question with any technology choice we’re making today is, are we still going to be happy with that in 5-10 years? 

So predicting is safer than following blindly like following the herd, and just trying to do what everybody else is doing is not as secure of that trying to predict what is going to happen in the future and then follow that instead. 

So we’re going to break down these web development predictions for 2020 into four areas:

  1. TypeScript 
  2. WebAssembly 
  3. Packages 
  4. Compiled-to-JS landscape

TypeScript 

TypeScripts in Google Trends is the opposite of Pearl; it’s taking off; many people are talking about it.

Not even going to bother explaining what it is because you’ve probably all heard of it. 

We also drew the comparison of TypeScript and CoffeeScript because many people have said that TypeScript is just going to turn out like CoffeeScript.

What is in the future for TypeScript? Everybody’s talking about it now, but are they still going to be talking about it and using it in a few years, or is it going to end up tapering off the way the CoffeeScript did? 

Well, two things to note about this: one is that TypeScript has already grown way beyond what CoffeeScript did, and secondly, that trend is still going upwards, there isn’t any indication the TypeScript is slowing down.

So what’s going to happen? Well, frameworks are all on board (Vue, Angular, React, Ember, Svelte, and Polymer). This support was certainly not true of CoffeeScript.

But despite this, not a hundred percent of people are on board. There are some things that developers don’t like about TypeScript; for example, thee’s one tweet that was complaining about having to deal with this type:

ComponetClass<Pick<RouteComponentProps<any,
StaticContext, any>, never>, any
& WithRouterStatic<(props:
PropsWithChildren<RouteComponentProps<any,
StaticContext, any>>) => Element>

Encountering this daily is not super pleasant; this is kind of a tedious kind of difficult to understand a thing. There’s probably some Java programmers who are now saying – you all made fun of us with our AbstractSingletonFactoryProxy beam who’s laughing now -.

David Nolen, a JavaScript developer for The New York Times, said, “maybe TypeScript is an enterprise JavaScript ” and there’s some truth to that.

Another thing that people say they don’t necessarily like about TypeScript is that although it gives you more type-checking and some degree of type safety, by design, the type system is unsound. It can let things slip through to give you a false sense of security.

But Richard Feldman thinks the most crucial factor to try and predict what is the future of TypeScript is looking at how it’s impacting teams.

Feldman hear many teams saying they are trying TypeScript or have used TypeScript, but he has heard almost no teams saying – we try TypeScript and then we went back to JavaScript -.

So it’s a ratchet that people switched to it, and then they don’t change back, and that means that it’s going to continue to have more and more growth as long as that’s true, that’s a potent force multiplier.

Prediction 1:

Feldman predicts the TypeScript ends up taking over the JS world 

By the end of 2020, commercial projects are going to be the most common choice that the teams make for a new project. If they’re in that situation making a Greenfield choice, they’re going to go TypeScript rather than JavaScript.

And by the end of 2025, more developers will be writing TypeScript than JavaScript without TypeScript.

WebAssembly

Lin Clark did a great job explaining WebAssembly, so we’re not going to go much depth on that; instead, let’s use Feldman’s oversimplification of WebAssembly: a way to run almost any machine code in the browser.

The upshot of this is that essentially it lets you build applications that can run much faster than JavaScript. 

One possible use for WebAssembly is you can use it to improve perf of existing JavaScript apps and libraries.

That’s interesting, but at the end of the day, that’s not the way WebAssembly is going to get used the most, developers accept the existing status quo of JavaScript performance. They are not going to change for something a little bit faster.

Richard Feldman thinks it’s much more interesting the use that companies like Figma are giving it, they wrote a blog post about how big a deal WebAssembly was for them. Figma is a company that makes graphics editing software, they are competitors with things like Photoshop and Sketch, and they’re making a serious heavyweight app.

This application is all built-in C++; they did not build this Photoshop competitor using HTML, CSS, and JavaScript. If you’re going to work at Figma on this product, you’re going yo be writing C++ all day.

Mainly Feldman thinks that the main thing that WebAssembly is going to do in the future is this going to allow browsers to compete with app stores and installers.

The reason that Figma chooses to build their app in the browser is that for people to use it, they can go to a URL and immediately start using it. Users don’t have to install it; they don’t have to accept permissions they don’t have to go to an app store, none of that stuff it’s a shallow commitment an effortless way to get in.

Now another thing that’s true about native apps is they tend to be pretty big like multi-megabyte downloads are kind of a regular occurrence for native apps, but not so much for web apps, we’re talking about like kilobytes.

So if this is a whole new way of doing apps, a reasonable question it’s, is this going to replace the way that things are done now? Is everybody going to be writing C++ in the future instead of HTML, CSS, and JavaScript? Is this the end of HTML and CSS and JavaScript? 

No, Feldman thinks that basically, this works for so many companies making so much money, he doesn’t see why people would change just because there is another option.

HTML, CSS, and JavaScript are still the most popular by far, and WebAssembly is going to change that.

The main impact of WebAssembly is going to be the definition of what is a web app. It gets more prominent because it starts to encompass this new thing that just was not popular back in 2006; this idea of a native application distributed through the browser.

One particularly compelling example is games. Imagine rendering this scene where people can walk around in CSS.

WebAssembly online games

That’s only a thing that’s become recently viable, a plausible idea that you can do now, and there’s going to be companies they’re going to be taking advantage of that and start distributing their games through the browser first.

Prediction 2:

WebAssembly is going to expand the web app pie 

By the end of 2020, there’s not going be much of a noticeable difference. People who are planing on these projects now are going to be starting to work on them during 2020. Still, by the end of 2025, we’ll begin to see a new niche of heavyweight web apps that are native apps distributed in the browser. 

Packages

Bower was a competing package manager to NPM; they both coexisted for a while, and these days, NPM won pretty convincingly, and now Bower usages are dwindled off like even more so than Perl.

If that happened to Bower, could that also happen NPM? Is there going to be something that replaces NPM in the future?

So, there was a talk given earlier this year at JSConf at the Economics of Open Source by CJ Silverio; we don’t want to steal her thunder; you should watch the talk and listen to the points that she’s making. Still, mainly she introduces Entropic.dev, which is an alternative package manager with a bunch of people who worked at NPM and went on to build a competing package manager.

Also, we’ve seen competing for CLI’s like Yarn as another way to you access the NPM ecosystem, and now we’re also starting to see competing backends like Github Package Registry instead of the NPM server ecosystem. 

So, the reasonable question is, are these signs of NPM going away? And at the end of the day, the fundamental idea of NPM is the real thing that people are making bets on whether or not it’s Yarn or something else; people are into the network effects of NPM.

NPM is here to stay, Richard Feldman thinks it might have financial troubles, GitHub will probably bail it out by saying here’s alternate servers, we believe that it will survive because of those powerful network effects so… 

Prediction 3:

NPM ends up surviving whatever further problems come 

By the end of 2020, there will be at least one more security incident making headlines. 

And by the end of 2025, they’re actually will have been a virus outbreak where someone’s

successfully distributed a virus through an NPM package and will affect a lot of people’s  machines but not those of us who have run this:

npm config set ignore-scripts true

Compile-to-JS

So back in the day, if you didn’t want to write JavaScript in the browser, like 2006 error, you could write Java Applets, or you could write Flash, which was a thing until it stopped being a thing.

These days the most popular way to compile to JS is actually to compile a JS dialect to JS, so we talked about CoffeeScript, but there’s also Dart, Babel, TypeScript, and Svelte.

All these fundamentally have the same upsides and same downsides as JavaScript, meaning they are JavaScript dialects; any of them could have the tagline; it’s just JavaScript. People be like ok that’s pretty much true even CoffeeScript had that tagline, TypeScript certainly does, but there are other options which are not JavaScript dialects which have pretty different upsides and downsides.

ClojureScript, ReasonML, and Elm. These are going to have a sort of different experience than writing JavaScript. It feels like writing a different programming language because it is a different programming language. 

Elm renders faster than top JS frameworks,  builds smaller bundles than top JS frameworks emits smaller packages on top JS frameworks, it rarely crashes in practice, generally speaking, if it compiles it works.

JavaScript rules the web, and Feldman thinks that will continue.

Although he does think that the next big thing on the web is TypeScript, it’s not going to be Elm. He doesn’t believe Elm is going to take over the world; he thinks TypeScript will.

Prediction 4

JS alternatives will stay niche but that they age well 

Many people who are betting on these technologies today are going to continue to be happy with those bets. 

By the end of 2020, they’ll still be growing not as fast as TypeScript.

And by the end of 2025, TypeScript will have continued to grow and will, at that point, still be more popular.

Quick Predictions

Are AI and Machine Learning to make leaps in popularity and development? What about pure robotics and automation? 

As far as popularity goes, AI and Machine Learning are already trending that way.  There’s probably more to come, but if we were to compare it to TypeScript, TypeScript is underhyped relative to how far it’s going to go. AI and ML are overhyped relative to how far they’re going to go. The number of applications, the number of ways that they’re going to be transformative at least in the next decade, is not going to be earth-shattering stuff like many people are predicting. 

Will Elm become more popular than React?

What Elm is missing to become more popular than React is that Elm is not JavaScript. In the next ten years, anything that is not a JavaScript dialect is not going to get anywhere near the popularity of anything that is fundamentally JavaScript.

Will ECMAScript continue to be the dominant JS standard?

It’s probably more likely than not. If ECMAScript clashes with TypeScript in some way where TypeScript disagrees about what’s right, TypeScript would eventually cave.