Predicting the Future of the Web Development (2020 and 2025)

[Music] all right welcome everyone this is predicting the future of web development I'm Richard Feldman let's start with a question never gotten to choose your stack at work like your greenfield project solely up to you or maybe the team that you're working on you get to pick what front-end stack you're working with okay yeah me too so I've also been that position the first time I was in that position was all the way back in 2006 this is the first web app that I'd ever worked on and there were four of us was a start-up and at the time the thing that was big in web apps this is where the dawn of web apps was the lamp stack anyone ever remember the lamp stack okay yeah Linux Apache my sequel and then the pea was overloaded to be PHP Perl and Python and the reason that Pete was so important was because basically we did all of the rendering on the server we would generate HTML on the fly and then send it to the browser on every page load and so this is our first time building a web app were like okay what do we do well one way you can choose your text stack is there's there's an old saying goes choose boring technology essentially try to pick something that is mature and established and used by a lot of people so here's one example of a 2006 boring technology this is what we ended up going with it was the the number one biggest library ecosystem at the time it was the most mature option the lamp stack by considerable margin I was used by successful companies including the social networking giant of the day LiveJournal and so we chose this technology using this methodology and this is how we ended up building our entire startup on Pearl so since 2006 pearls popularity has not been the best this is the Google Trends for like pearl searches since 2006 and kind of a lesson here is that no just choosing boring technology is not a guarantee of safety this doesn't mean that everything's gonna be okay as long as you just do what everyone else is doing right now you kind of have to look towards the future and try to figure out like well how are things going to go in the future now the lesson here is that it's not necessarily a problem that pearl declined in popularity the problem is that if we were trying to hire right now there's not a lot of people who want to do pearl development these days 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 the technology and just don't really want to use it anymore so any technology that we choose no matter how popular how mainstream how much traction it's got today is 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 I think is any technology choice we're making today are we still gonna 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 safe of that I think as trying to predict like what actually is going to happen in the future and then follow that instead so I'm gonna be making some predictions today some concrete predictions I'm gonna make some predictions about what I think is going to be true about web development at the end of 2020 and then also at the end of 2025 so I'm gonna break this down into four areas one is typescript two is web assembly packages and finally compiled to j/s landscape so let's start with typescript more like hype scripts am i right I mean come on we saw Matthews talk yesterday about this this graph of like type scripts you know Google Trends like the opposite of pearls it's like really taking off a lot of people are talking about it not even bother explaining what it is because you've probably all heard of it he also drew that the comparison of typescript and CoffeeScript like a lot of people have said like well as typescript just gonna turn out like CoffeeScript what what is in the future for typescript you know there's everybody's talking about it now but are they still gonna be talking about it and using it in a few years or is it gonna end up tapering off the way the CoffeeScript did well two things to note about this one is that obviously typescript has already grown way beyond what CoffeeScript did in terms of interests if Google searches are any indication and secondly that it's trend is still going upwards so we haven't really seen any indication the typescript is slowing down so what do we think it's actually gonna do well obviously frameworks are all on board I mean this was certainly not true of CoffeeScript um like no matter what you can't relate throw a stone without hitting some framework that's either got first class typescript support or is working on adding it already but despite this the fact that there are so many people in the ecosystem getting on board not a hundred percent of people are on board there are some things that people don't like about typescript for example I saw one tweet that was complaining about having to deal with this type I'm not gonna read this whole thing out because I have a limited amount of time to give this talk but obviously like encountering this on a daily basis is not super pleasant this is kind of a really verbose like kind of difficult to understand thing there's probably some Java programmers who are now looking on me like you all made fun of us with our abstract singleton Factory proxy beam who's laughing now David Nolan yesterday said that you know maybe typescript is kind of like enterprise JavaScript and I think there's some truth to that another thing that people say they don't necessarily like about typescript is that although it gives you like more type-checking and some degree of type safety by design the type system is unsound and it can let things slip through to give you a false sense of security one notable example of this being any which is essentially means oh this type it might be anything who knows we're just gonna find out which appears four times in this type signature alone so definitely some things to like about typescript but I think the most important factor to try and predict what what is the future of typescript is looking at how it's impacting teams I hear a lot of teams saying we are trying typescript or we have used typescript we are using typescript I hear almost no teams saying we try typescript and then we went back to JavaScript actually I haven't heard of any I just don't wanna get well actually like after this talk so I'm gonna say yeah it could theoretically happen but personally I actually have not heard of a single team I'm sure somebody has that went typescript and then went back so it's basically a ratchet like people switched to it and then they don't switch back and that means that it's going to continue have to have more and more growth as long as that's true that's a really powerful force multiplier so essentially I mean there's a lot of truth I think to this tweet like you know maybe if an individual on a team is like I don't like typescript but if the whole team ends up adopting typescript anyway because that's what the team lead says we're going with that's the technical decision is or maybe the department says we're going with that and so every team has to get on board whether or not individuals like it is that doesn't necessarily mean that that's gonna change the fact that the whole team adopted it so based on this I think typescript popularity is like just getting started I actually think that well I'm gonna go on record and say I predict the typescript ends up basically taking over the Jerome I'll be specific about what I mean about that so I think by the end of 2020 I think that for commercial projects is going to be the most common choice that the teams make for a new project like if they're in that situation making a Greenfield choice they're gonna go typescript rather than JavaScript and I think by the end of 2025 there will be more people on a daily basis writing script in JavaScript without typescript we'll see if I'm right but I think that's where things are headed part 2 web assembly Lynne Clark is one of the great explainers of our time and she's done a great job explaining web assembly so I'm not gonna go into super much depth on that instead I'm going to oversimplify what web assembly is as it's a way to run almost machine code in the browser and the upshot of this is that essentially it lets you build applications that can run much faster than JavaScript now one possible use for web assembly is you can use it to improve the perfecting JavaScript apps and libraries and stuff so one example that Lynne gave was you could use this to make the react reconciler faster just speed up that one part of the library I think that's interesting but at the end of the day I don't personally think that's like how web assemblies gonna get used the most or the biggest impact that it's gonna have and the main reason I think that is I think that the existing status quo of JavaScript performance is pretty widely accepted as like fine the reason I believe this is in part that I'm on the Elm core team and a few years ago we had like a really exciting release or so we thought that was like hey look look look how much faster we made Elm like now like renders faster than like react and angular and view and ember like all these things look at look how great these numbers are and people are like okay but like you know like it's fat all the other things are fast enough so whatever I mean good job but you know look I think people are pretty okay with the status quo and so if the pitch of web assembly is it's like use the same technologies but they'll be a bit faster I don't think that's gonna be enough I think it's much more interesting for companies like Sigma and they wrote a blog post actually about how big a deal if web assembly was for them so if it was a company that makes graphics editing software like their competitors or things like Photoshop and sketch and they're making a really really serious like heavyweight app and this application is all built in C++ like they did not build this Photoshop competitor using HTML CSS JavaScript able to with C++ that's what their team looks like if you're going to work at figma on this product you're writing C++ all day so essentially what they've built is is a native application that happens to be distributed in the browser they're not really using web technologies if they attended this conference most of what we talked about would not necessarily be a much used to anyone building this thing in the actual application so essentially I think that the main thing that web assembly is going to do in the future is this going to allow browsers to compete with app stores and installers like the reason that figma chooses to build their thing in the browser i assume is the fact that in order for people to use it they can just go to a URL and immediately they're using it they 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 very low commitment a very easy way to get in also it is a great sharing story if you're like in the middle of editing something and you want to send someone else a link to be like exactly on the same page as you are and like they can just bring it up in their browser that's also really easy in browsers so there's a lot of good reasons that people might want to distribute what is fundamentally a native app in the browser instead of using an app store or an installer now another thing that's true about native apps is they tend to be pretty big in size like multi megabyte downloads are kind of a normal thing for native apps like yeah photo shops like pretty big of course you know that's what people expect not so much for with apps we hear about like the bloat crisis and we're talking about like kilobytes and if your if your payload is multiple megabytes it's like what are you even doing but again this is the thing where I think that people you know tolerate this like the status quo another experience we had on the ell team was like releasing this thing where Elms packaged like a bundled up size it got really small thanks to like some really aggressive dead code elimination and this is like not just the the baseline size that's like across the entire app so we had this real-world app which is basically a bigger version of to do MVC's they have implementations and react and angular and view and all these things and the elm one after this new release went down all the way down to 29 kilobytes for the entire 4,000 line of code single page app and react itself is like 35 kilobytes were like this is amazing look how tiny this is everyone's talking about this bloat crisis right it's a really big deal and people are like good job you know that's that's you know well done but but the other day people put up with the multi megabyte downloads I mean I know like there's a lot of talk about this stuff but there's way more talk than action and we all kind of know that this is true so I don't see any reason why this should be different for native apps like if people are willing to wait for multi megabyte Photoshop download I think they'll be willing to wait for that in the browser to okay so a reasonable question at this point is it's like okay so if this is a whole new way of doing things is this gonna replace the way that things are done now is everybody gonna be writing C++ or rust in the future instead of HTML CSS and JavaScript is this the end of HTML and CSS and JavaScript I don't think so no I think that basically this works for so many companies making so much money I don't see why people would change just because there is another option I mean they're actually as we'll talk about later there already are plenty of other options to HTML CSS and JavaScript and they're still the most popular by far I don't think web assemblies gonna change that I really think the main impact of web assembly is gonna be that the definition of what is a web app gets bigger because it starts to encompass this additional thing that just was not popular back in 2006 when we were in the lamp stack this idea of a native application distributed through the browser one particularly compelling example this I think is games like imagine rendering this scene where people can walk around in CSS this is not happening I mean yeah you need these like really low-level high performance technologies if you want to ship a game in the browser that's only a thing that's become recently viable like a plausible thing that you can do but it actually is a plausible thing that you can do now and I think there's gonna be companies they're gonna be taking advantage of that and start distributing their games through the browser first so prediction number two I think webassembly is going to expand the web app pie by the end of 2020 honestly I don't think it's gonna make much of a noticeable difference I think the people who are working on these projects are gonna be starting to work on them around now but I think by the end of 2025 we'll start to see okay there actually is a new neish of like heavyweight web apps that are basically native apps distributed in the browser okay why three packages how many people recognize this logo shout it out what is it Bower yes so this was a competing package manager to NPM they both coexisted for a while and these days NPM won pretty convincingly and now Bower usages is sort of dwindled off like even more so than Perl so a reasonable question to ask is like okay that that happened to Bower could that also happen NPM is there going to be something that replaces NPM in the future anyone recognized this logo no but interesting this is entropic so there was a talk given earlier this year this was at JS conf at the economics of open source by CJ Silverio and I don't want to steal her thunder you should watch the talk and listen to the points that she's making but essentially she introduces entropic which is an alternative package manager it's a bunch of people who worked at NPM and went on for various reasons that she explains on the talk to build a competing package manager also we've seen competing CLI is like yarn is another way to you access the NPM ecosystem and now we're also starting to see competing backends like github package registry instead of like the NPM server ecosystem now worth noting that I mean yarn is a CLI which access is the same server hardware and github package registry is sort of the opposite I mean it actually on their website they talk about you use the normal NPM CLI to access this ecosystem just point it to a different URL rather than NPM servers and so reasonable questions are like okay are these signs of NPM you know going away and I think 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 I mean really people are into the network effects of NPM by which I mean the package.json file that says here are all my dependencies and they all have their dependencies specified in that way whether it's NPM servers a github servers or something else I think the important thing the valuable thing the thing that people can reasonably continue to bet on is that that ecosystem exists and all the network effects continue to persist I think that persists through continued problems so we saw recently not recently this point a couple years ago I'm left pad where someone unpublished a package and broke a lot of people's workflows they closed that off and said you can't unpublished packages anymore that's all done earlier today Chris talked about event stream like a malicious packet or someone successfully managed to get up a whole a hold of a package that was used by a lot of people and publish a malicious release so uh hello Alain wrote a really detailed write-up of the event stream incident it's on his blog and one of the things that he talks about is basically like there was no like one root cause where you can just close this off and it's fixed like there was with left pad this is kind of a more systemic issue and it's like not really going away anytime soon this vulnerability is still there and is gonna be there for the foreseeable future and something that neither of those touched on is this so if I were to install front-end dependencies by running a bash script like this what's the difference between that NPM install which is the way that most people install front-end dependencies well one difference is that when I run bash install that Sh it execute arbitrary code on your machine which is a security concern whereas when you run NPM install in an execute arbitrary code on your machine from thousands and thousands of packages infinitely worse than running a bash script to like do install that essays because it's all of your dependencies and all their dependencies dependencies you might be thinking what do you mean I'm executing arbitrary code well there's this thing called a post install hook that any package can put in a package JSON and it will just execute arbitrary nodejs code which is to say arbitrary code on your machine every time that package gets installed so if that's a virus then cool you just got a virus and I think the main reason that this hasn't happened yet is just that it hasn't happened yet like we haven't had like the outbreak of the the NPM virus that someone spreads by using this this has been disclosed since 2016 NPM wrote a whole blog post about like hey this is the thing that can happen to you and they posted at the end of this blog post like if you want to disable this behavior and make it so that post install scripts and pre install scripts don't run run this command NPM config set ignore scripts true and then by default they just won't run anymore if you ask me this probably ought to be the default I've had this enabled for several years now and although it's less convenient there are various organ AMA cashews with it I don't think it's better than being vulnerable to this virus if you take nothing else away from this talk please go home and run this command so that if there ever is a virus outbreak you are not affected by it because I think this is going to happen III don't see why it wouldn't happen now that there's like blood in the water and people have said oh you actually can publish malicious packages like event stream interesting ok so in conclusion though do I think that NPM is going to go the way of Bower I don't think so I think NPM is here to stay I think it's it might have financial troubles github will probably bail it out by saying here's that here's alternate servers if it has more viruses and things like that I think that it will survive because of those really strong network effects but I mean I still wish the entropic folks all the best of luck but if I'm making a prediction I think that NPM ends up surviving whatever further problems come its way released the ecosystem does so I think by the end of 2020 I think there will be at least one more security incident I think that that seems like a fairly safe prediction and by the end of 2025 I think there actually will have been a virus outbreak where someone's successfully distributed a virus through an NPM package and it will affect a lot of people's machines but not those of us who have run this again please run this and don't don't be a victim of this ok which brings me to the final section compiled to j/s so back in the day if you didn't want to write javascript in the browser like 2006 error you could write Java applets which was awful or you could write flash which was a thing until it stopped being a thing these days the most popular ways to compile to j/s is to actually compile a J's dialect to j s so we talked about CoffeeScript is also dart Babel is like compiled future js2 current j/s typescript compile very slight superset of j s2 j s and smelts which is like trying to compile to more compact j s than some of the alternatives all these fundamentally are basically the same upsides and same downsides as javascript i mean they are javascript dialects any number of them could have the tag line it's just JavaScript and people be like ok that's pretty much true even CoffeeScript had that tag line typescript certainly does but there are other options which are not JavaScript dialects which actually have pretty different upsides and downsides javascript we've heard about a couple of them David Nolan talked about closure script yesterday we heard about reason ml from Brian Phelps and I'm here representing the Elm core team all of these are going to have sort of fundamentally different experience than writing JavaScript it feels like writing a different programming language because it is a different programming language one thing that's different about these that's from from my experience is that using a Jas alternative is actually cheat code for hiring good people I actually don't know how we hired anyone at no ridic before we started using Elm because pretty much everybody who applies these days which is a lot of people like we hired a head of talent and she commented I have never seen an inbound pipeline this strong in my entire career all the cover letters say Elliman them because the number of people who want to use Elm is a lot bigger than the proportion of companies that have taken the plunge and are willing to actually use it and then hire for it something there's a misperception commonly like intuitively you might think Oh it'll be hard to hire people how will we possibly hire people I admit I don't know how we hired anyone before Elm because it was way way harder so if you're wondering like you know why might I use something like this I can certainly speak to my experience with Elm I mean I talked about like okay renders fast in the top jay s frameworks emits smaller bundles on top J's frameworks also know runtime exceptions like it almost never crashes in practice this is like our error logs this is a JavaScript errors we've had like 60,000 plus since we started using Elm in 2015 Elm once it's not zero it's just zero pixels like if I were to zoom all the way and you could see like it has happened it's not never not literally never but I mean this is obviously not something we're thinking about generally speaking if it compiles it just works and then doesn't it's pretty great also this is a completely separate package ecosystem so all this stuff I just said about NPM doesn't apply to Ellen projects like we have our own package ecosystem it doesn't have posted some hooks or creates all hooks it's it's really fast and it's really nice another thing is the error messages this is like a really common thing that people praise about Elms so this is from the most recent release of Elm which was last Monday if you get a syntax error now it reports it like this hey I was parsing it import it's all I got stuck here this is maybe if you tried to use JavaScript syntax for imports rather than elm syntax because it's a different programming language it says hey I was expecting to see a module name next like in these examples it shows like multiple code examples of like how to do it properly and then it's like okay and you know they all start with capital letters and by the way go ahead and read this link if you want to learn more about it like this is a pretty I just picked this one kind of at random but there are so many examples of this we're like day-to-day writing elm code like I just get this level of help from the compiler just feels really nice like I got I don't know I don't know how to describe it the best way that I found to describe the experiences maybe by contrasting it with my experiences whenever I find myself back in the JSE ecosystem like come on I'm maintaining one of my node C allies or something like just imagine if in your life building web you eyes like things normally worked like I I don't know how else to say it but like I mean normally when I'm writing JavaScript code like I'm installing a package I'm like this didn't work with it why didn't this work with this thing like in elm I just installed packages Nate and they normally just work okay whatever and then I'm like I'm going to upgrade a package so Mike lightweight this used to work but now it it stopped working like what's what's going on I'm like googling stuff and now I'm like okay okay fine and then I go back to Elm and I'm like oh everything works again nice okay cool everything is like this like it compiles and it normally just works like III I haven't been able to express this feeling in any other way just then like whenever I go back I'm just like am i dumb like what how come I can't get anything to work anymore but in Elm it's just normal not a hundred percent of time but normally things work out pretty well and if that sounds interesting you should check out the Elm website and learn more but I also know from experience giving elm talks and stuff that a pretty small percentage of people in the audience will actually go and do that probably an even smaller percentage will actually run the NPM figman but I'm being realistic here if I'm making predictions about the future I know that you know this is a not JavaScript thing and javascript rules the web and I think that will continue like at the end of the day I really do think that the next big thing in the web is typescript it's not going to be Elm I don't think Elm is going to take over the world I think typescript well this graph will continue but that doesn't mean that I necessarily am going to be getting on this train like to me I'm like yeah I think Elm is much nicer I have no interest in that and there a lot of people who feel the same way just not as many as feel that you know tights good as well if they're gonna go with and that's fine I mean really at the end of the day again the point of this is not to win popularity contests like pearl had won the popularity contest the point is to find a technology that you're happy with and that you continue to be happy with over the next 5-10 years etc I've been using Elm for about five years and I definitely see myself using it for the next five years it's something that I'm happy with and that I think is going to continue to age well so my final prediction is that I think that Jos alternatives stay niche but that they age well I think a lot of people who are betting on these technologies today are going to continue to be happy with those bets so certainly with Elm so by the end of 2020 I think they'll still be growing we actually add for ellen conferences this year fairly a lot of people I talked to didn't know that but yeah I'm still growing but not as fast as typescript typescript is taking over the world which Elm is not and that's fine by the end of 2025 I think that they will have aged well although of course typescript will have continued to grow and will at that point still be more popular all right so to summarize it started out by talking about the passive I'll just choose boring technology and everything will be fine not necessarily a lot of times it's more about correctly predicting which technology's end up being something that you're happy with over the long haul talked about predicting is safer than following blindly which can lead you into the same kind of situation we would have been in with Perl made a few predictions about typescript webassembly the web ecosystem and compiled ejs I predict the tape script is going to take over the jas world web assembly is going to expand the web app pie rather than replacing things I think NPM is going to continue to have problems but ultimately it's going to survive them and finally I think that the j/s alternatives like Elm closure script reason ml I think they're gonna stay nice in terms of popularity but that they're gonna age well and they're a good thing to bet on so what will I do personally well I mean I think I've made pretty clear keep using young because I think it will continue to age well thanks very much [Applause] richer Feldman you have so much energy thank you so much this was a great talk to have as the last one I we have some questions do you expect AI and machine learning to make leaps in popularity and development what about pure robotics and automation that's a great question so as far as popularity goes I think that AI and mill and I'll like already are trending that way I think there's probably more to come but I also think that if I were to compare it to typescript I think typescript is underhyped relative to how far I think it's gonna go I think AI and m/l are overhyped relative to how far I think they're gonna go I think the number of applications the number of ways that they're gonna be transformative at least in the next decade is is not like we're on could be like singularity we're here everyone's thinking their way through every problem and the machines just like you know connect with our brains I don't think we're gonna get there in the next like decade maybe eventually but I don't think anytime soon more more than that I think if you look at the demos of today of like what AI and ml are doing I think it's gonna be variations on that like incremental improvements on that not really like earth-shattering stuff like a lot of people are predicting in European why Elm is not as popular as react what is it missing to become more popular yeah number one reason that Elm is not as popular as react is that Ella is not JavaScript I mean that's literally it like if you're building anything that is not JavaScript its popularity is going to be infinitesimal compared to JavaScript like the the cultural momentum behind JavaScript is just absolutely massive any programming language that is not a JavaScript dialect where the learning curve compared to JavaScript is like anything significant is gonna be really big and I think that's that's basically going to mean that I'm willing to go on record and say I don't think that anything that is not a JavaScript dialect in the next 10 years is going to get anywhere near the popularity of anything that is fundamentally JavaScript I think that's just how strong the momentum is so again but I think that's fine like you also need to be significantly different from JavaScript if you have any hope of being significantly better than JavaScript and like I think the Delta between my experience and my Elm experience is as big as it is because it's different and that also is why it's not ever going to be as popular all right our app scale to millions of customers and performance is critical and doesn't support coats pudding though yeah and is it is a deal-breaker for our team solution look you boy that word yeah sure yeah so that's a great point um please get in touch with me because basically the the steps that we wanted to take we're like cool first let's make the bundle size is really small with code slimming and then we'll look at what are people's remaining problems like in practice like hey I have this elm app and it's too big because of X and what we've heard from people were actually building L maps as they're like actually they're not too big anymore we don't really want to go to all the trouble of code splitting so never mind but if that's you and you're like hey even if like it were just like 29 kilobytes that's too big for me or like you know I'm gonna have a million lines of code and it's gonna be you know however much X that size please come talk to me because we're trying to build features based on like people's actual needs and use cases rather than just like Oh code splitting we should like check that off because everyone's doing it like we want to actually solve the problem of page load times and bundle sizes rather than just like checking features off a list yeah come talk to me all right last question on this stage for you do you think ECMAScript will continue to be the dumb nsj standard yeah so that's that's a really interesting question I'm guessing where this is coming from is like so there's ACMA script which is like hey this is how java ships would be and then there's typescript which is kind of like becoming the default compiler if I'm right if my prediction is right and it ends up taking up taking over what happens if typescript says hey you know what like ACMA script disagrees with us and we don't care we're gonna keep doing things the typescript way this is certainly not what happened to CoffeeScript like CoffeeScript you know dekma script ended up adopting some of CoffeeScript stuff and then replaced it so yeah I think it's a totally valid question I think that III don't have super high confidence in like whether or not it will continue to be the dominant jaya standard i think if it's not it will be specifically because ACMA script and typescript clash and typescript said hey look we're not gonna change but i think it's probably more likely than not that if ACMA script did clash with typescript in some way where ty script was like yeah you know we're just we disagree about what's right here I think typescript would eventually cave I think that's more likely I think it's pretty plausible that one thing I've heard people talk about is maybe I can't script will come up with a standard that says hey this is what ty javascript is and it'll probably be very close to typescript but maybe there'll be some differences I wouldn't be surprised if typescript said okay fine we'll just like get on board and now typescript becomes the the dominant compiler of the Xmas script type system so I think it's more likely than not but I want to be honest that I don't have a super high level of confidence in that one way or the other all right thank you so much everybody switcher Feldman [Applause] [Music]

Channel: Coding Tech

Views: 798,392

Rating: 4.8795056 out of 5

Keywords: typescript, web development, javascript, technologies, webassembly

Id: 24tQRwIRP_w

Length: 29min 31sec (1771 seconds)

Published: Wed Nov 13 2019

Reddit Comments

[u/BlackAvenger81]

tldw?

[u/Mr_Mandrill]

Pretty on point, but I'm not so sure about people using TS more than JS, that was quite a brave prediction.