The following is a transcript from episode 31 of JS to Elm podcast released in 2018:

Hello. My name is Jesse Tomchak, and this is JavaScript Elm episode 31. JavaScript is the new C a show about learning Elm functional programming, and a general sense of leveling up as a JavaScript developer today, we’re gonna get into our topic. JavaScript is the new C. As my thesis point, but first I want to give us a little update on ow notes and sort of what that project looks like and is currently going through we’re at a sort of tipping point right now in our application where we have grown our Elm application inside of our react.

And it has sort of taken over a rather large smart container react component. We’ve stripped everything out and we’ve turned it into an entire Elm application embedded in here. And we’ve got some decisions to make as to whether we want to, how we want to move forward with this application. We can either move on to another part of the application and choose that and sort of iterate and do the same thing.

Do that again and again, and eventually we will. Come together and have to figure out how to sew or push out the last remaining pieces of the react applications. As you know, the ultimate goal is to have a complete LM application, as much as possible. The idea to replace the react application with LM entirely with the exception of any of the interior stuff that we need.

AWS signatures, API calls, things like that. The other option is to continue to grow our existing Elm application and sort of slowly take over the react as a single app, rather than trying to put all the little Elm pieces back together at the end. And frankly, I haven’t really decided which one I want to do or which one would be better or more viable or ups and downs.

I’ve got like a pros and cons list that we will probably go through once I have a decision, but it’s kind of up in the air right now. If you have any ideas, if you think one may be better than the other, or you have gone down this road, I would love to hear from you. You can get me on Twitter at JSL. You can email me at contact.

JS That would be amazing. I would really appreciate some input on that. So for today, I want to present my thesis topic. That is the following in a few short years, JavaScript will be considered in the same realm as programming in sea. Meaning to write an application, JavaScript will be considered midlevel air prone, dangerous, consistent with the lowest common denominator, and only really used when you need to leverage a specific use case to say in five years, we won’t be using JS.

Is incorrect. I think it will have the same longevity as C. It is built into the fabric of so many things as a dependency. I would say, I think day to day, developers will not be writing in plain JavaScript, but rather a higher level language that will target JavaScript. At compiled time. I’ve got a little chart or table in the show notes that.

Sort of do a quick little comparison between C as a programming language and JavaScript. The C language is an operating system is used mostly in operating system and system levels everywhere. JavaScript is used on the web everywhere. C Le C has a long list of languages that. Target it as a compile, as does JavaScript C has the Nole references as does JavaScript.

It also has undefined C is great for performance and yes, JavaScript is also optimized and stupid, fast in a optimized VM with just in time compilation. So the, the sub. Titled to this topic is JavaScripts is dead long live JavaScript. And the idea I want to convey is that I really like JavaScript. So I don’t want to come across or think that I’m of the thought that we don’t want to ever write in JavaScript.

I think it’s, I think it’s a great language. I think it has over the last couple years, I’ve learned it has. Deep deep sort of features that make it specifically unique as far as somewhat, you know, C style syntax with a lot of functional style prototyping functions as first class citizens, things that have led me to better programming, paradigms and design decisions.

It’s also really dangerous, right? Function is not defined. X is undefined. These are general things that we come across on a day to day basis as JavaScript developers. But what I want to sort of convey is that it used to be really straightforward to get started with JavaScript, open a text editor or browser, and write some JavaScript code.

You would ship the bike code as the. What the browser would basically compile and run that sort of paradigm where you could just view source and sort of skim through the entire thing at this point is fundamentally dead. JavaScript as an ecosystem now has task runners, bundlers transformers, common JS ES modules, ation uation source mats package management with MPM dev servers, prod performance builds virtual Dom rendering V just in.

Optimize compilation and so on and so on and so forth. JavaScript is no longer shipping readable bike code, readable source code as the bike code to run. Right. We are shipping these G zipped unified bundles that are, I would argue no better. For human readable then assembly. Right? You can sort of discern stuff out of there if you are used to seeing it a lot, but otherwise it’s pretty gnarly.

I would contest that JavaScript has. Been an easy language to master, but an easy platform to be productive in without a mastery of the language, with the laundry list of things that I just listed off. I also believe that that easability in getting, being productive in a, in the platform is virtually gone.

So what does it take to start up a. New application in JavaScript? Well, some, I think the first thing you would say you would argue is, well, you could still just write a dot J S file and put it in a script tag in a way you go. You could, but to start up a web application, what would be required? Well, essentially all the things that I just listed, you would need a complex CLI tool to start up a project.

If you were going to do it from scratch, you would start with a folder. N PM in it. You know, uh, I installed a, I started a new create react app and it installed, I think, 890 something packages. This is both a positive of the ecosystem that I was able to get so much in, just a few quick installs and also a negative of the ecosystem that my.

Project which doesn’t do anything, but render a blank page requires 900 packages and several build steps in order to get out there. My idea with comparing this with C as a language is because C has sort of, uh, stood the test of time, right? It is fundamentally embedded in everything from Unix to Lennox, to systems, to the subset of superset languages like C plus plus languages that interact with.

You know, Java going C sharp Python, Haskel objective C, uh, which is sort of where I got my roots from. But would you want to write your next application in just C not likely, right. You wouldn’t have the build set, the tool chain, the, the sort of nice, nice tool developing and your user experience would not be particularly awesome.

We would probably choose, you know, Java or go Lang or Haskel, you know, or swift or. You know, depending on what we were targeting, we would not choose just Rossi. I would say that the O the same goes for JavaScript. There is a laundry list of languages that interact with JavaScript. Um, you know, we know that one right off the top of our head dart type script, peer script, coffee, script, closure, script, scholar reason, and on and on and on and on.

And that was just a short list. The long list of language. Interop with JavaScript and compile to JavaScript is huge and has been going on. So long, I believe coffee scripts was 2008 or 2009. Right? So we’ve been at this for nearly a decade where we are writing in another language to sort of get around some of what we would consider as developers, the shortcomings of the language.

So I would ask you the same question. Would you write your next application in just vanilla JavaScript? Well, and some of you out there are going to nod and say, yeah, absolutely. But if you are writing an Ang. You would, you would use Cript a lot of listens as a show are trying to write an Elm and we’re we’re doing so because of the things that it offers in addition to on top of JavaScript, the compiler and the friendly air messages and this sort of type safe environment that Elm offers us for web development.

Type script offers a superset of, of static types, right? Pure script offers, sort of the same things, closure scripts, and scholar reason offers, you know, some very interesting, uh, benefits we’ve seen over several years, a. Massive explosion of languages that target JavaScript to enable them to take advantage of not just the web, but the entire ecosystem that comes with JavaScript.

Um, I’m talking specifically, you know, out of the Elm, we have ports where we can write safely an Elm and. Still take advantage of 600,000 library packages out there that are available to us. You know, APIs for local storage APIs for WebGL a, you know, web APIs for location, data, like all these things that are targeted to JavaScript.

We can still leverage in our. Language of choice for us on this podcast, it is hopefully, or more than likely Elm, but not necessarily languages that are built as a superset of C and JavaScript. Have a common theme to overcome perceived shortcomings. In sea or JavaScript. And I say perceived because they’re not necessarily tangible or concrete, but to the developer and the application and that specific build and that those specific needs plain or Rawi plain or raw JavaScript have shortcomings.

So you might ask, well, if you are making the comparison that. JavaScript is the C language of the web. And what I’m saying is a larger scope than that, that JavaScript is in essence, a companion to see in the larger sense of programming, you are not going to write your Java, your applications day to day in JavaScript in just a handful of years.

Right? We don’t nobody today I think opens new. Project and, and says, I’m gonna write this entire stack in C while doable. You’re not really likely to do so. Right. You’re gonna have to reinvent a lot of paradigms and rebuild a lot of things and, and that sort of stuff, even C plus plus like, you know, depending on what you’re trying to build out for us, we’re, we’re building user facing applications.

A lot of the time JavaScript, uh, web apps, progressive web apps, electron. Desktop apps like slack or vs code. I feel like half the apps on my desktop are all in electron now. So I’m not too far off from just using a Chromebook, I guess, which is fine if they keep the touch bar on the max, but that’s a whole nother story.

The point is that in as little as four or five years, I don’t think JavaScript will be a growing ecosystem anymore. As much as a sort of mature place for development on top of packages for interrupt will become more mainstream. The language itself is adding so many things between deconstruction and spread operators and template literals between 20 15, 20 20 17, 20 18.

Um, Array buffer memories and things like that. It is becoming a deeply complicated language that coupled with the fact that you can’t just view source code anymore and actually get an inkling of what in the world is going on, the ability to learn and, and sort of absorb JavaScript is also diminishing as well.

So as it gets more complicated, it is getting less accessible. To anyone that opens their web browser, right? They’re not looking at JavaScript code. They’re looking at modified ified Z zipped Java script. Bite code that just, I mean, it’s unreadable, but it’s small, right? It’s just a couple kilobytes or hopefully a, you know, a couple, a couple hundred kilobytes, not a couple hundred megabytes, uh, for that initial load.

Right. We’re doing lazy loading. Prefetching all that good stuff. And so this is an idea that I’ve had rolling around in my head a lot and sort of one of the reasons I started to explore other languages, I looked into Elm and I looked into pure script and I really wanted to get sort of into this vein.

Type script. Didn’t really appeal to me from. Foundation standpoint. I also didn’t really want to do a lot of angular as I really liked the sort of react paradigm. So obviously through this podcast, I I’ve, you know, put my money behind Elm and, and bet on Elm as a sort of long term, one of the. Long term outcomes to this sort of shift.

There’s also web assembly, right? This is new and coming out. This is where we actually ship assembly code that gets run natively in the browser that compiles from C and C plus plus and rust as compile targets. Right? These is standard memory management, non garbage collection applications, and the transition to high level languages that compiled to JS.

Bit happening. I said coffee scripts was 2008. So give or take 10 years now. And I think it’s just reached that sort of bursting point. You know, we had things like dart, um, coffee scripts, Ruby JS. I, I think Python JS, I think you could name most of the language that is, that would actually compile target to JavaScript.

Um, and El, you know, under the covers, there’s Hask, GC. HJS I would have to check. I’m not totally sure. Go for JS is one for go Lang, but JavaScript is so ubiquitous and yet it is so unsafe to write from a development standpoint, you know, Elm and touts, no runtime air exceptions, which JavaScript absolutely does not have.

Right. It is difficult to write JavaScript. So I think we’ve reached that tipping point tipping point in mainstream. I mean, here we are in a podcast. Every year at Elm com gets bigger and bigger and bigger. And I want. Web assembly today too. But web assembly is just getting started and you know, it, and, and by web assembly getting started, right.

We had ASM JS, uh, and before that we had, um, native client and ACL project. Right. So it’s just been constant evolution, but it will likely be years before we see a mainstream tooling in. Web assembly, right? It’ll have its sort of niches and things, but you know, as, as browser support slowly moves out, it could be a very long time before we see it as a mainstay in web development.

I hope not, but. You know, and think about the state of JavaScript in, you know, two to four years, let’s even say four years. So that’s 20, 20. Nope. That’s 2022. You know, in four years you will have 2, 3, 4 more iterations of the TC nine 30 committee we’ve got right. Patting left PAing string, string, patting, string, patting, other things, right.

They they’re piling a lot of things on the language and it’s constantly backwards compatible. At this point, we we’re working on a rays smush. You know, the language is going to sort of reach this sort of breaking point where it’s going to have to sort of either settle down. As a core or branch or, you know, I don’t think they can keep adding things at this pace, but we’ll see.

We’ll, we’ll see what happens with that now in these sort of research for supporting arguments and supporting facts. For my case, as JavaScript as the new C, I came across, uh, Landa, the ultimate org website, and I found a quote from none other than the author of JavaScripts himself. Uh, Brendan. Reads like this, the new better is better hope for multilanguage is, uh, the NaCl that I talked about a minute ago, the native client, it was the driver for pepper API that failed by being two chromium specific hope Springs, Eternals.

In my humble opinion, that CNC plus plus tool chains will have CFI enforcement for portable, safe binary code sooner than the browser vendors will agree on native client and pepper, two or pepper, three. The worst is better. Hope is compilation to JavaScript combined with language and VM evolution. That is my bet.

And I’m putting my money on it at Mozilla. This was a quote. From 2011. So seven plus years ago, Brendan had this idea that, yeah, it would be great if we could have safe binary code to the browsers, but really, uh, compilation to JavaScript combined with VM evolution is going to be our best bet. He saw this seven years ago.

It’s mainstream today. I think it will be the overwhelming solution in four or five years. Where JavaScript will not be the go-to language will, will there be a, a main go-to language, probably, you know, things seem to settle it, you know, at the top with one or two at the top, and then you sort of get a selection of, of outliers, but who knows, you know, it’s, it may be something that’s not even out yet reason has a lot of traction behind it.

Pure script is good. I’m a personal fan of Elm. But everyone’s got their own pony in this race. And the last thing I’ll say before we, uh, we go to picks is that there is a language called JavaScript plus, plus that compiles to JavaScript. So like C and C plus plus JavaScript plus plus makes my case for me.

There you go. It’s a perfect correlation. I rest my case. All right. So that’s my case for JavaScript as the new C I’d love to know what you think about the idea, the comparison, the pitfalls, the problems, the, the holes in the argument. Uh, I’d be really interested to know what you think. So catch up on Twitter with me JS to Elm.

Uh, catch up with me on slack at J Tom chalk. Let me know what you think. I really think this has. Legs, uh, until someone points out that this is a ridiculous idea, and then I’m going to continue to research it and try and. Uh, hold on to it. So let’s go to picks. Uh, my first pick is a site called type and type classes is a site for learning functional programming.

It is brought to you by the authors of the HASCO book. Chris Martin and Julie, Chris Martin and Julie, Chris Martin and Julie, uh, Julie, I don’t remember your last name. Uh, Julie. Maru key. Sorry. Julie Maki and Chris Martin, they have been talking about making videos for Haskel and have done it. The site is up it’s called tech

I think it is really super awesome. So check out the site and let me know what you think. I also found this really cool. My next pick is this really cool site called, uh,, which you may or may not already know about to create and share beautiful images of your source code. So you just type in your source code and it generates this awesome image and it even has like a tweet code button right there.

So you can just tweet your code out. It’s super rad. And my last and final pick is. Jay Phillips talks about web assembly, discussing what it is, how it can be used today and opportunities. It will unlock in the years to come. So we ended the, we ended my discussion with these sort of like, well, what about web assembly?

And where does that fit into the paradigm? And, and, you know, these things move slowly, but. There is opportunity today in web assembly. And if you were like, Hey, this is cool. Uh, check out J Phelps stock. It’s really, really good. Uh, and that’s it for this week. Next week, we will figure out what we’re doing with our Meow notes application.

As we sort of build it out in Elm, uh, as always check out the resources for all the links, um, and resources that I found to put this episode together. Please follow on. Twitter at JS LM, you can follow me at J Tom shock on Twitter. Um, you can email me. I’d love to get sent email contact JS and we’ll see you next week.