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:
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:
StaticContext, any>, never>, 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 -.
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.
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.
Writing Typescript because everyone else is doing it. pic.twitter.com/hUiNOT4L5d
— Cem 💎 (@cem2ran) October 23, 2019
Feldman predicts the TypeScript ends up taking over the JS world
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.
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.
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.
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.
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.
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.
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.
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…
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
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.
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.
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.
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.
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?
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.