JS Party – Episode #108

New Year's Party! 🎉

our 2020 predictions, wish lists, & resolutions

All Episodes

Jerod, Divya, Chris, KBall, & Nick ring in the new year with our 2020 predictions, wish lists, & resolutions. Will Chrome’s browser market share decrease? Will Svelte (or a Svelte-alike) continue to trend? Will Jerod finally write some TypeScript?! Listen along and let us know your thoughts on the matters.



Rollbar – We move fast and fix things because of Rollbar. Resolve errors in minutes. Deploy with confidence. Learn more at rollbar.com/changelog.

DigitalOcean – The simplest cloud platform for developers and teams Whether you’re running one virtual machine or ten thousand, makes managing your infrastructure too easy. Get started for free with a $50 credit. Learn more at do.co/changelog.

Notes & Links

đź“ť Edit Notes


đź“ť Edit Transcript


Play the audio to listen along while you enjoy the transcript. 🎧

Okay, the ball drops in five… Four… Three… Two… One… Happy New Year! That’s right, friends, we are wringing in the new year by throwing a New Year’s JS Party. Join us for our 2020 predictions, our wishlists, and stay tuned for the resolutions at the end; that’ll be fun.

We have a huge cast of characters with me today. b0neskull is here… Say hi, Chris.

I should have seen that one coming. You know Kball is always down to party… What’s up, Kball?

Yo, yo, yo! Here I am!

And Nick is back from Montreal. Hoy-hoy, Nick.

Hoy, hoy.

And of course, our favorite Vue Vixen is with us… It’s Divya!


What does “hoy, hoy” mean?

It means hello…

Is that a thing?

It’s a thing.

I’ve never heard that before.

It’s how Mr. Burns answers the phone in the Simpsons.

It’s also Nick’s calling card these days.

Well, it’s interesting, because Divya has been working relentlessly on her calling card, and I asked her about it last week, and she said it wasn’t ready yet. And then I asked you today, just now, I said hello, and you said “Ho-ho-ho!” Is this your calling card, “ho-ho-ho”? I think that one’s taken.

I tried to be seasonal, but I’m a little late. But it’s close enough to Christmas, I guess, after January. [laughs]

That’s right. Well, we’re coming to you from the future, but we’re recording in the past. The magic of podcasting. You’ll be listening to this on or after January 2nd, 2020. That being said, we’re acting as if it’s January, because technically we’re sitting here on December 19th, looking forward, as we do, in our crystal balls. We are going to predict the future, or fail to, dramatically, on today’s show… So let’s start off with some predictions for 2020. We have a lot of them. Some good, others - you decide. I will pick from a list, and I’ll start at the end, where the predictions got crazier and crazier as you went down the list… I will start from the end… “AI assistance will be a thing while writing code.” Who wrote this down and why?

I did, and I think that it will be a thing. I think in the way that we have autocomplete - I think that autocomplete will become more intelligent with AI assistance, knowing more about the code and/or the open source APIs that you’re working with.

Oh, interesting.

Didn’t somebody release a proof of concept or something for this, for Python?

[03:52] I saw it specifically for Vim, something called – I think it was called TabNine. I tried it out and I didn’t get it to work after like two minutes of trying, so… That’s why I’m predicting in 2020 [unintelligible 00:04:03.06]

Interesting. So it’s like NLP model predictions, but for code.

I think that one specifically looks at open source code on GitHub, maybe that’s using the APIs that you’re using, and sees what you’re trying to pass into it, and then suggests how to write your code based on how lots of other people have written that code.


Yeah, there are definitely companies and groups out there working on this, and I’ve seen a lot of announcements and future projections of like “These are things that we’re working on to integrate into your code editors.” That being said, I don’t think we’ve seen too much that actually works like Nick has experienced. So I think maybe 2020 is a pretty decent prediction; people will start to pull these things together and make them actually useful.

That being said, when I see “AI-assisted”, I think of like an actual robot giving me the side-eye as I write some terrible code.

That too.

That too. [laughter]

I think sort of like on the side of it, but not exactly an AI-assisted, is this no-code thing, which is what WebFlow’s whole shtick is… Where you’re essentially creating websites without writing any code. I think that has just started this year, and 2020 might be the time when it gains wider adoption and you see more of that, and you start working with more no-code-to-code type workflows.

Wait, wait, wait… That’s just started this year? What’s WordPress?


Isn’t Wizzywig the same idea?

Yeah, well – it’s not that it started this year, it’s just that I think people created a name around it… Because I think it’s existed for a while. You could do Wizzywig stuff with–

Oh…! The marketing machine has kicked on.

Yes, exactly. Because you could stuff with Dreamweaver…

Much like with JAMstack, which is the way that people have been building websites for years and years and years…

Well, there’s some extra things to JAMstack - and we can talk about that later - that makes it slightly different now than maybe 10-20 years ago… But the idea with no code is just essentially very similar to Dreamweaver, like drag-and-drop, or even WordPress, I guess, if you have the editor… You’re essentially doing things without having to write any code, which I think – that has been around for a while, but I think oftentimes you see that as individual… You don’t see people doing both, where they’re doing Wizzywig and then coding at the same time. But you might see, similar to what Nick was mentioning, with AI assistance writing your code. You might see no-code living alongside people who write code.

For example, a designer might create something in Webflow, and then a developer might come in and just edit or change stuff. Who knows… I don’t know. It’s a prediction.

I refuse to recognize this existential threat. [laughter]

Yes, I’ll bury my head in the sand and say “This is never gonna happen.”

I totally understand the low-code/no-code for non-developers, or people that just don’t wanna touch the code… But we’re developers and we like to code, and so it’s really hard, in my experience, to get interested in a low-code or no-code tool to do pretty much anything, right?

I think one of the things here is we keep automating more and more stuff that’s boring, in order to free us up to do more and more interesting things… Boring, or labor-intensive–

Like go fishing?

…and think about higher-level stuff. Well, there was this great tweet that was particularly funny because a lot of people took it seriously and didn’t fully grok what it said… Somebody was like “No-code is gonna eliminate development, just like compilers eliminated all the software developers.” This concept that going up a level of abstraction doesn’t actually remove the need for people thinking at more complex levels, it just lets you do more with the same amount of intensity.

Basic websites have been no-codable for a long time, with WordPress, with the build-your-own-website…

[08:19] There’s Wix, Squarespace…

Yeah, those are what I was trying to think of. That’s old news, but that’s the same thing, of like “Okay, certain things, so long as you stay within certain boundaries and you have certain constraints and you’re not doing these things, are completely automatable and doable without having to understand the guts”, and that bar keeps rising up… But that has not reduced the amount of people coding. People coding has continued to rise; we just keep doing more and more complex things that push the edge further.

Yeah, I agree, it’s not a zero-sum game. There’s just gonna be more people coding, there’s gonna be more code, there’s gonna be more no-code [unintelligible 00:08:58.07] [laughter]

I think it’s similar to what Kball was saying, which is also just ease of use. For example, with no-code - or even with Wordpress, which is essentially the alternative - it’s this ability for you to not write code in certain aspects. For instance, if you’re someone who really dislikes writing CSS, and making your website look pretty from that aspect, you could focus on a no-code tool like WordPress, or whatever plugins or Webflow’s workflow, or whatever that is, to do all of that, so that the styling is almost applied on top, and then you can focus on something else.

So I think it’s the idea of abstracting away the work that you’d rather not do, into something else that will do it for you… Whether that be an AI assistant, like Nick was saying, or whatever this no-code tool is.

Let’s move on to other predictions, because we could probably continue to talk about this… I love the idea of having more no-code; it sounds really nice to me, Chris. But let’s go to a prediction that I actually wrote down, which I think that Google’s share of browser usage is gonna start to drop, as alternative browsers gain usage… Especially browsers that either focus on security and privacy, or begin to see that as a competitive advantage, and integrate security and privacy features.

I’ve just downloaded Microsoft’s Chromium-based Edge and noticed that they’re now offering as a feature tracking prevention – what do they call it…? Protect yourself with tracking prevention. Of course, we’ve seen Apple adding that to Safari, we have Firefox, which has always been more privacy-focused, and upstart browsers like Brave, that are basically taking everything Chromium has to offer, ripping out the Google bits, and providing a browser that is better in many ways, but similar in other ways.

So it seems like to me that Google’s control of the browser landscape is gonna start to diminish. That being said, Chromium itself is gonna continue to rise. What are your guys’ thoughts on that?

I agree, one hundred percent.

I would like to agree…

But you don’t…?

Well, I’m trying to dig up real quick what the trajectory has been.

I did look up real quick… Chrome, according to StatCounter - in 2018, Chrome was at 61% market share worldwide, and in 2019 it’s been at 64% worldwide. So it’s seen a 3% increase this year. That’s why I say it will begin to drop; it has to turn the other direction. Because it is still continuing to grow, even though there has been more and more complaints or dissatisfaction by users.

I think as Chromium Edge matures, we’ll see more people using that on Windows.

[11:51] The one question I would ask to sort of think about this is what percentage of browser use is mobile, and what are the trends in that direction? Because most of the alternatives we’ve talked about here are really, from my understanding, focused on desktop and laptop… But huge amounts of browsing right now is mobile, and most of those users are just using what’s on the device.

So on the mobile browser market share you have Chrome at 62%, which is slightly down from overall, and Safari at 21%, which is up quite a bit from its overall, as Safari for desktop has never been a game-changer, but iOS has a huge hold of the mobile market share. So there is a difference there, for sure… And I think that Apple’s relentless power grab on iOS and refusal to have any other rendering engines on their platform has continued to keep Safari’s dominance there, and I think it will continue in that way. Maybe they’ll let go of the default browser option as the platform matures… I don’t know. It seems to be the last stand for Safari on iOS, as you can’t change the default.

I think another thing to note, which is going off of Kball’s idea, is this concept of like – a lot of people are using mobile to view content on the web, but there’s also this concept of in-app browsers, which is like… I don’t even know where they live, honestly… Because essentially, you’re viewing content, and then it opens a browser within the application that you’re in. A lot of people view content that way. So you’re not technically on a browser-browser, you’re within the application, opening into a browser, which is a weird use case.

I’m sure in 2020 more people will be having that kind of an experience.

I also think that we’re gonna see a bifurcation based on features… Because it seems like browsers are kind of spreading out in the available features for them. And I’m not talking about language support or anything like that, but if you are more privacy-focused, you’re gonna not be on Chrome; you’re gonna be on Safari or Firefox, or maybe Brave. If you want the picture-in-picture, you’re gonna be in Safari. There’s these features that are specific to browsers, that might force your decision into which one you use based on what’s available.

Well said. Let’s move to future predictions here… We have Svelte gaining more popularity. Pre-compiled framework will continue to gain traction. I’m just reading this from our list… And we’ll see both Svelte get more popular, and another candidate emerge. Who wrote that and who would like to expand?

I wrote that, and I will expand on it a little bit. I’m seeing more and more and more attention paid to the cost of JavaScript and the cost of JavaScript frameworks… And more and more and more folks trying to innovate at a compile level, so doing things like JAMstack where you’re pre-compiling things, pre-compiling more and more into frameworks like Svelte, that compile down to just simple, native JavaScript with no runtime… And I think that those trends are currently accelerating and will continue to accelerate.

Right now, Svelte is kind of the only innovator I know of in that space at the framework level. We’re going all the way to making a framework that’s pre-compiling as much as possible and boiling things down, but it’s been getting a lot of noise, or it got a lot of noise in 2019. I think it’s gonna continue to get a lot of noise in 2020, and my hope is that we will start to see competition there… Because I know in the other frameworks spaces having competition has sparked a ton of innovation. React and Vue and Angular have all learned from each other. Svelte has learned from all of them, but I think there’s probably some optimizations you can make at the compilation stage, that having more competition in that space would help spark.

Doesn’t Elm also sit technically in the same vein as Svelte, because it is compiled to JavaScript?

I guess that’s true… Does it ship with a runtime though?

I believe it does.

I believe it does.

[16:09] So that’s one thing that I think is a little bit different, but I don’t know how much it boils down– yeah, one could argue that… I’m not familiar enough with Elm to say in particular, but it is a compile-to-JavaScript language and framework.

I draw a little bit of a distinction between compile to JavaScript, but the same model of “We’re gonna have a runtime, and we’re gonna have this sort of complex thing that we ship out, that is a bunch of JavaScript weight that goes out, regardless of how complex your app is”, as compared to “We’re gonna try to pre-compute everything we possibly can, and boil down what we ship to the absolute minimum.”

But Elm may be doing more of that than I’m aware of.

I can’t speak to Elm either, because I don’t work with it, but I do know that in the front-end landscape Elm was one of the first to do a lot of compile-to-JavaScript type work, which I think Svelte took a lot of inspiration from when Rich Harris wrote Svelte, essentially. But I think you’re right, Svelte is very much focused on making it as lightweight as possible. You’ll hear it online, essentially Svelte arguing about how the performance of Svelte is very nice. I think there was that animation, a couple of weeks ago; they were like “This was written in React”, and then someone jumped on it and wrote it in Vue, someone wrote it in Angular, someone wrote it in Svelte, and so on.

Does anybody who’s using Svelte know, is New York Times using it?

That’s a good question. I know he built it for the use cases that he was facing there, but I have no idea if they use it.

So they at least did use it internally at the New York Times for a lot of their JavaScript journalism? I know that GoDaddy has some stuff in production. I remember looking at the list a couple months back. I don’t think you can say the New York Times uses X, where X is one thing, because they have a lot of projects, and lots of different – that style of journalism is like each project is its own unique little thing, and then it moves on to the next one. So it’s not like a “Our product is built with framework X.”

2020 is the rise of microframeworks on the front-end… [laughter]

Microfrontends, microframeworks.

I did find it interesting–

Microfrontends, right…

I did find an interesting blog post that somebody said “Oh, the amount of code produced by their own compiler can be somewhat lengthy. Our 22,000-line application compiles to a file with over 53,000 lines of JavaScript that is 1.6 MB in size.”

Oh, wow.

Wait, wait, wait… They wrote 20,000 lines of code and it compiled to 50,000 lines of code?




Whoops… Michael Rowlings is pointing out in our JS Party chat room - by the way, live listeners, hang out in #jsparty of the Changelog community Slack; all free, of course… And he says that it’s not totally fair to say that Svelte has no runtime. There is a runtime, it just hides it. And then I think he pasted a large portion, or maybe the entire “runtime” into your chat. It’s small [unintelligible 00:19:22.24] but the point is that Svelte is trying to do as much as possible when you build, versus having a runtime that you interact with in the page that you ship every time.

Today I learned…

TIL. Well, take that, Kball…


[laughs] Alright…

Alright, taken.

Well, it sounds like there needs to be more competition.

[19:54] I agree. I think we’ll see a lot of the existing competition stealing good ideas, and moving more things that they can into pre-compilation steps. I think Angular is already making moves in that direction.

The [unintelligible 00:20:05.29] I’m not well familiar with that, but the competition is good. I think predicting there’ll be a new competitive JS framework next year is not exactly going out on a limb. I mean, come on…

It’s just predicting what it’ll be called, and what will be the distinguishing factor.

Speaking of that, somebody wrote “JavaScript will be renamed to TypeScript” in our document… So why is Nick trolling us in our document here? [laughter]

This is a callback to our “Should JavaScript be renamed?” episode, where we debated that… And I think that just looking at the now couple-weeks-old State of JavaScript results, where 58% of developers who responded to this have used TypeScript and would use it again, and 22% have an interest in learning it, and at least heard of it… So it seems like for a majority of us now JavaScript has been renamed to TypeScript for us.




I love those groans… Keep them coming.

Well, speaking to that point - so the State of JS 2019 survey results just came out late last year… It was a couple of weeks ago, now that it’s January 2nd… I wrote up a few insights, and one of those insights is that TypeScript is winning developer hearts. If you look at graph on the State of JS, which we’ll link in, 58.5% of respondents - which, by the way, all that demographic data and everything is really available to download this year, so they’ve definitely been working hard on these surveys to make them better… 58.5% have used it and would use it again, whereas only 7% who have used it would not use it again.

Yeah, but JavaScript has the name brand, right? So I think you’re more likely to have TypeScript renamed to JavaScript, and just go that way… Because as we discussed, trying to rebrand something that has millions and millions of packages is problematic. Instead, we’ve already got this concept of JavaScript having multiple different versions, and “Oh, am I compatible with this, or am I compatible with this?” Maybe TypeScript will just be JavaScript++.

It’ll essentially be like CoffeeScript, so it’ll just be adopted into JavaScript, and then people won’t talk about CoffeeScript anymore…

Hmmm…! [laughter]

Chris is bringing the groans… Who predicted that the computing at the edge will take off? CloudFlare workers, Akamai, edge workers etc.

I wrote that.

I was gonna say, I’m gonna guess Divya, because that’s her company’s nuts and bolts, right?


Yeah, but I…

You didn’t put Netlify workers in here…?

Well, yes, Netlify workers as well. I mean, I didn’t write that because it currently is not a huge thing at the moment, but it will be. I think in 2020 – you see a lot of companies talking about computing at the edge, because there’s an interest, a resurgence of interest (not recent), because CDNs have existed for a long time… But there’s a resurgence in interest specifically for performance and all that good stuff, on essentially pre-rendering and then putting things on a CDN. But then in contrast to how things were in the past, we’re also looking at a lot more interactivity of pages. So not only do we want things static, we also want to make API calls, and do redirects, and various things that are happening, logic that’s happening on your site… And now it takes a long time for you to do that, because you’re essentially having to hit the cloud, and then hit a server, and then come back… So there’s a lot of latency that happens as a result.

If you think of a redirect, that’s essentially what – that roundtrip has to happen, because you have to go to the server, the server has to tell you “Hey, the page is no longer here, it’s here”, and then you have to do that roundtrip over and over, and it takes a lot of time.

[24:04] With edge workers, you can do a lot of that HTTP routing really quickly, without having to do that trip all the way back to the server for any of that functionality to work… And I think that’s really powerful, especially from a performance standpoint. And I imagine that a lot more people will start using, a lot more companies will start building their own version of workers.

That is cool. So let’s say I have a website and I have a server API, and my server is in New York City, at a central cloud infrastructure there. And I have somebody who’s running my website in Japan. And they download all my files, and they’re happy-go-lucky; they got their JAMstack static stuff, served from a CDN, so it’s super-fast to get them their files… But then it comes time for them to do auth, and they hit the A part of the JAMstack… And they make the API request. Well, that API request currently, in the current infrastructure, goes all the way back to New York City, to run that request and get the response, and update. But with these edge workers, you’re basically distributing the API that you write out to the CDN as well. So your function actually exists at wherever CloudFlare is closest to Japan, probably right there in Japan. So now your functions are running there, so the roundtrip time is much decreased. Is that right, Divya?

Yeah, that’s exactly what it is. Because I think people tend to forget that – we assume everything’s in the cloud, and so everything is fast, but that’s not the case, because there is a lot of that server time and latency that happens, and that’s essentially… It happens at the speed of light, but distance takes time to travel; so the further you are from the specific server where your logic sits, the longer the latency. With edge workers, you’re essentially putting the logic right where the user is, as close as possible… So that latency is reduced significantly. And of course, there’s extra stuff that can happen, with that being more reliable, faster…

So does that automatically distribute my data as well? Let’s say that in order to do that authentication, I have a users table. And in my current setup, my users table is in New York City, with my API server, and it just has this local [unintelligible 00:26:15.28] to query the database and get the answer. But in the case of it being distributed around the world, I have an edge API in Japan… How does that edge function access my data? Does it also have to be distributed?

So when you originally auth, you go from not authed to auth; you’re probably gonna go back to your central API. But then you get a cryptographically-verifiable token that can be verified at the edge.

Well, then let’s change it away from auth and say – now I’m at the edge and I have another function that says “Give me the list of recipes (it’s a recipe app).” Does the list of recipes have to be distributed geographically close to that edge worker, or does it also have to go back to the database and do caching?

Think about it as caching.

Yeah, it’s caching. So you’re not saving all – because essentially, it’s not a server. It’s still a CDN. So you don’t want your database to be there, because that’s not what this is. It’s essentially utilizing – you’re still making a lot of those requests if you need new data, but you are making use of the caching abilities. So you can essentially refresh the cache when you need to, get from the cache when you need to…

Ideally, what will happen is that if the data has already been fetched, it’s cached; so you can grab from the cache itself, so it’s super-fast. But I don’t think it removes that point of having to go to the server when you need to do authorization of any form.

So when will we get that? Because what I would prefer is just to distribute my application around the world, and I can just hit my API that’s closest, and they all have the same data, and everything’s hunky-dory.

Oh, I had a fascinating conversation about that at JAMstack, and I realized we have not shipped that conversation yet… [laughter]

[28:02] Hm… Give us the elevator pitch, or the micro-summary…

Well, high-level is we’re working on it. But there’s a really interesting question about – like, thinking about what sets of data can live where. What types of consistency guarantees do you need… So if you have something where you have to be absolutely – you know, you have to have atomic transactions, you’ve gotta have absolute consistency at any particular glance, then it’s gotta be centralized in some way. But you could imagine building out essentially the equivalent of a distributed data store, where you have eventual consistency, and having that living at the edge, because it just then has to find a way to replicate out to the other edge nodes.

Which probably gets harder and harder as the size of your database goes up as well… So there’s lots of–

Yeah, there’s lots of different pieces.

Cool. Definitely an interesting space to be watching. Alright, let’s do one more from our predictions, and then we’ll move into the wishlist. Somebody grab out a prediction that they put down, or is interesting to them, that we haven’t touched on yet, and that will be our last one.

What’s this “I predict something bad will happen with the Native File System API”? Can somebody explain what they’re worried about, what that is?

That’s me… And I’m worried about security, because we have a new API which is coming about, the Native File System API, which exists I think now in Chrome, just landed in… I don’t know, some channel of Chrome. Super-Canary? I don’t know. And what it does is it allows at the user’s permission for the browser to reach outside of its sandbox and access the native file system of your machine. Right now everything’s been sandboxed, and every browser can only access the things inside of the browser’s permission space. With the Native File System API, it enables us, as it says here on this website, “To build powerful web apps that interact with files on the user’s local device, like IDEs, photo and video editors, text editors and more.” So after a user grants a web app access, the API allows web apps to read or save changes directly to files and folders on the user’s device.

They’ve put a lot of work into this, and they have a whole section on security and permissions, and I will say that my skepticism is high, because these things are very hard to do correctly. And any time you allow what has previously been a safe, sandboxed little space access to the entire system, usually bad things happen, especially when these things just ship. And it’s just now shipping, at the end of 2019. My prediction is we will see some hacks or some zero-days against specifically this API.

Have you talked to Feross about it? [laughter] Because I’m sure he’s figured out how to use it to destroy your machine.

[laughs] Exactly.

Also, it’s currently on Chrome with a flag, and no other browser supports it, and I don’t see – do you know what the expectation is for other browsers to support this at all? Because it just seems that on web.dev it says Chrome is implementing it behind a flag, but I have not heard about it [unintelligible 00:31:37.20] any other browsers. I have no idea to what level this will be adopted.

Chrome is gonna wanna look at your files and index them and upload the data to Google. [laughter] And then send you ads based on your documents…

Yeah, I’ll be sure to call all my folders like XXX… [laughs]

Can you synchronize groaning…? Yeah, I’m not sure if the other vendors have said they’re gonna implement this…

I have no idea…

[32:10] But it’s a thing where Chrome is currently leading the way… And I don’t wanna say this isn’t desirable, because it absolutely is, especially for people trying to build very rich-featured web applications. If I’m trying to build an in-browser photo editor - well, it will be very useful for me to have access to all the photos that are on your disk, versus having to move them around, or upload them, and what have you. This is something I think developers do want, it just can be very precarious because it’s opening up perhaps a Pandora’s box of problems.

It would be awesome to be – well, I guess… But it would be neat to have VS Code in your browser, but it just works with your file system instead of the cloud, right?


That would be cool, I guess. I don’t know if I’d necessarily feel the need to use it, but honestly, I don’t know if I would trust Chrome with it.

Yeah. It seems that the draft in the W3C - the person that’s on it is a person from Google, and it’s only one person… It’s very much in draft.

The one thing that I will say is I think we as developers are much more paranoid and much more aware of the permission boundaries of browsers than your typical user.

Mm-hm. I think that’s fair.

So while yes, I think there is a big concern about misuse and something bad happening, like, folks already install apps everywhere; they’re already giving access to their file system to anyone and everyone.

But at the same time, I don’t think you should make it easier.

Yeah, that’s a strange argument. It’s like, “Well, the side door is already unlocked, and so is the back door. Unlock the front door. What’s the difference? It’s already insecure…”

What I’m saying is I’m not convinced that this is actually – particularly since it is going through the browser, and I think they are being very careful about how they do it… If this makes people less inclined to just install random apps, it’s probably a better-controlled gateway than we currently have for the majority of users. It’s probably going to be more secure than the tendency to install an app everywhere, for everything.

You know what would be really cool? This would enable so much awesome tooling.

Oh, for sure.

Everything that you’re doing right now on the command line… Maybe there is a GUI front-end for it that just does the same thing. It’s not giving you everything Electron does, right? It’s not giving you access to all of Node’s built-ins, or anything like that, but… I mean, that file system access goes a long way, and that’s a lot of what tools do - open files, monkey with them, output a file…

Alright, so that’s a few things that we predict will happen in 2020. Hold our feet to the fire and let us know at the end of this year if that’s true. Stay tuned, we’ll be back for things that we would like to see happen in 2020.

It is now time for us to report our wishlist. What would we love to see happen in 2020? We have a few things written down here… I wanna skip to the end, because I like this one. I’m guessing this is something that Chris wrote, but I’m interested to hear who it is.

It is not? Okay, then I’ll go to Nick. Is it Nick? “Facebook puts React into an external foundation.” Is that you, Nick?

Oh, Kball…

It is not me…

Oh man, I suck at this game… [laughter] Okay, Kball wrote that?

Kball wrote that.

Why do you care?

Why do I care? Because as much as I like Vue more than React, I think React is a very positive thing for the community, and the amount that it is owned by Facebook - which I consider to be a generally toxic company - is a problem.


Yeah. That would be nice. I don’t think they have any reason to put it in a foundation. The only way that’s gonna happen is if React’s users demand it. And so far, people don’t seem to care.

I do not know any details on this. A conversation I had with someone who tends to consult on this type of thing, while we were at All Things Open, led me to believe this was a possibility.

What would that practically, in a regular developer’s life, what would that change or do? What would be the implications of that?

I think short-term, very little. Medium to long-term, it might have a large impact. The biggest thing right now is that React makes a ton of choices in terms of prioritization of features and in terms of how they optimize things, for particularly Facebook’s use cases. And not being super, super-deep in the React community, I haven’t followed deeply around what the impacts of that have been in some places, but I’ve seen it come up a few times on Twitter, with people like Dan Abramov, who are public faces for React, being like “Look, y’all, let me remind you, the choices we’re making are what Facebook needs. They may not be the right choices for you.” Because it makes a lot of stuff that makes a ton of sense if you’ve got massive, massive scale, and the types of problems that Facebook is solving, that may be over-optimizations, or even over-complex, bloated, what have you, when you’re talking about smaller apps.

It’s a very top-down project, and as Dan said, it’s not serving the community; it’s serving Facebook, and they throw it over the wall, essentially.

And given the numbers that we see in the State of JS survey and in pretty much other surveys, it’s a significant part of the ecosystem that’s just being thrown over the wall right now.

Yeah. And I think they do a good job; they’ve got a lot of great stuff. They’ve got an incredible pipeline of innovations that they’ve been putting out. A lot of the things that have improved Vue and Angular, some of the really big changes in how they think about the world originated in React; React has done some really, really good work. So I don’t wanna throw the team working on it under the bus, or say that they’re doing bad work, or that they’re not doing things that are valuable to the community… However, they are prioritizing based on Facebook’s needs, and they’re very transparent about that, but it still drives all that decision-making.

I think the same problem is there for Angular. However, React is far more widely used… Looking at that same State of JS framework, the number of people who have used, but would not use again for Angular outnumbers the people who have used and would use again, plus the number who are interested in it… So Angular is not nearly as popular.

[40:05] And secondly, I haven’t heard any sort of insight rumors that Angular is likely to be spun out into a foundation, whereas I did hear the potential that that might happen with React.

And what if React got hit by a bus tomorrow? Or, sorry, what if Facebook got hit by a bus tomorrow? [laughter] Man, I screwed that up.

I think it’s funny both ways.

Right. We know that Facebook is kind of just throwing it over the wall, Angular is (I would say) the same thing… Now, Vue is - from what I understand - pretty much BDFL style governance, right?

I think they’re moving away from that. It used to be, for a time, but especially moving from Vue 2 to Vue 3, it’s moving away from that style of (I guess) governance…? I don’t even know what you call it…

Yeah, it’s governance.

…because there’s now officially a core team, and everyone has a piece that they focus on. So whether that be the compile aspect of things, or whatever else there is to it - documentation, and stuff like that - there’s various people that focus on that and support that work… So Evan doesn’t have as much – they still have meetings and they talk about things collectively, but I think Evan has given free rein to people to focus on specific parts of Vue. So it’s moving very much away from it. I think it’s also not sustainable to have just one person maintain a framework that so many people use.

Yeah, because what if Vue gets hit by a bus? [laughter]

And what if Evan gets hit by a bus is the relevant question here, where there is no equivalent for React or Angular. I do think that he is still a little bit in that BDFL position, but the community there, with his acceptance, have very much started that transition away. They took a lot of lessons, I believe, from the Ember community, which never has been the BDFL approach, really, and they introduced a bunch of processes around RFC’s, and getting community input, and distributing the team more, and things like that… So I suspect that maybe by Vue 4 we’ll truly be away from a BDFL. So call him a benevolent dictator, but not for life. He’s working his own way out.

For Now. BDFN.

Speaking of Vue, we have a wishlist item “Vue 3 will ship”, which sounds like maybe it’s a troll, because isn’t it supposed to come out pretty soon now? Like, if it doesn’t ship, won’t that be a disappointment?

It’s supposed to come out at the end of the year…

Is that like [unintelligible 00:42:38.25]

The end of 2019…

The end of 2019 was what it was slated for, but I don’t think there’s a date…

But it didn’t come out.

…it hasn’t shipped yet.

It didn’t ship in 2019.

But we’re recording from the future, so maybe…

Oh, maybe… Oh, no…!

So if this ships between December 19th and January 2nd, then this whole section - you can just hit fast-forward.

I’ve never wished for something not to ship so much. [laughter]

So you’re changing your wishlist. You’re hoping it doesn’t ship until this show comes out, and then you hope it ships.


It’ll ship on the second.

I know. Oh…

That would be nice.

That would be really nice. We’d be like forward-thinking. That’s the whole point, right?

Well, you get what you want immediately.

Nobody wants to wait for their wants. “Just give it to me.”

Exactly. It will ship, it will ship. Yes. There’s a lot of work that needs to be done, because they’re changing Vue 3, and the call functionality, so a lot of it is – it’s essentially TypeScript is a first-class citizen, which is really great, because people who used TypeScript in the past with Vue had to use a lot of hacks for it, and Vue syntax for TypeScript looked completely bonkers. It essentially looked like React… But I think now, with Vue 3, it’ll look a bit more – there’ll be more parity between writing Vue without TypeScript and Vue with TypeScript.

So while we’re talking about Vue, we also have a wishlist item - “A great OS data tables component for Vue.” I’m guessing that one’s from Divya…

I think that was Kball. Wrong again.

[44:05] Gosh! I’m betting zero on this… I can’t put Divya in a corner, like “You’re the Vue person.”

[laughs] I mean, you had two options to pick for me; you’ve picked the wrong one, so…

Yeah… I’ll get this eventually.

I have a lot of wishlist items.

Generalize it?

Yeah, I don’t think it has to be specifically for Vue. I don’t think there’s a good data tables component for anything.

Yeah, that’s totally true.

What’s OS data tables? Open source?

Open source.

Oh, okay. I thought it meant operating system, because I was confused…

There are some decent solutions for React specifically. There’s a very fully-featured old school jQuery-based solution that while I didn’t love working with it, it was actually super-powerful in a lot of ways… So I’d like to see just a powerful, flexible Vue component or library (however you wanna think about it) thing for data tables. I do think in the React community there are some better solutions. There’s essentially nothing good that I could find for Vue.

Shout-out to SlickGrid. Anybody remember SlickGrid? Just me… Alright.

I do.


It was slick.

I’m betting zero, I’m betting zero… Okay. What else. Somebody wants a grid-based component model for CLI apps. I’m guessing this one is gonna be…


Chris? Yessss!

Nice. [laughs]

There’s this project called Ink, which is essentially React in your terminal… I mean, yeah, you need React, so there’s a significant overhead there. It’s based on Facebook’s Yoda, which is their implementation of Flexbox, I wanna say… So it’s Flexbox in a terminal. And I don’t feel like that’s really the – it’s a difficult abstraction in the terminal, because you’re not really working with this box model on the terminal. What you’re working with is a grid. You’re working with 80x25, so it’s really difficult with Ink to do some of the – essentially anything grid-based. And so what I’d love to see would be something that allows you to use components, just like you’d write in React or something like that, and output awesome CLI apps, but you would create them declaratively.

I would like to see something like that maybe built on Preact, because I think that the overhead of loading all of React in the terminal is a big hit on startup time… But I just want a better way to make awesome CLI UIs.

What was it called again, the thing that you were mentioning that Facebook implements?

I think it’s called Yoda.

Yoda… Yoga?

Yoga. Yoga, not Yoda. Yoga.

Oh, okay.

So is that Baby Yoga?

Baby Yoga…

Yoga. Yoga is the Flexbox thing.

Oh my gosh, now I really want someone to implement an open source component for CLIs called Yoda, just because… [laughs]

There’s a stab at this in Rust, or something like that, too. Anyways, that’s what I want, and I’m just kind of a CLI nerd, so… That’s my thing.

That would be really nice.

I hope you get your wishlist item. Who wants a CSS subgrid in Chrome, and why? Kball, you’ve got a long list here, buddy.

I’ve got a long wishlist. I want a CSS subgrid in Chrome for a couple of reasons. So it recently shipped in Firefox, so we know that there’s been good progress here. And what a CSS subgrid lets you do in a way that is really painful to do right now is nest different grids and have them all line up. So you can have a grid-based component and a grid-based subcomponent, and have the pieces of the subcomponent line up with the parent component.

[48:03] The big reason that I want that is I think that it enables you to – right now you use CSS Grid mostly for layout-level components, and if you’re gonna use it inside of a component, you need to be really careful and thoughtful about how it’s interacting with your layout… Nesting things where if you have a grid-based layout and then you have a grid-based component, the nesting is really a pain in the ass. If you have subgrid enabled, I think most of that goes away, and suddenly you can have independent component development, where the components are utilizing grid to lay themselves out in a reasonable manner, and they can be nested into a grid-level layout using the subgrid, and have everything line up perfectly.

So I just think it explodes the possibilities of what we can do with grid, so that we’re not just thinking about it at the level of page layouts, but it suddenly becomes something that anytime you’re doing two-dimensional positioning, whether it’s at a page level or a component level or a subcomponent level, you can use grid, use the power that we have there, and nest things in and out in a straightforward way, without having to have the whole picture in your mind as you develop each piece.

I think subgrid is super-cool. It’s really neat, and it shipped in December, so it’s pretty recent… But I think [unintelligible 00:49:19.12] only available in Firefox at the moment, so hopefully other browsers implement it. Because I’ve had the problem of trying to hack a grid within a grid, which is really annoying; it doesn’t work.

It doesn’t work.

It just doesn’t… Yeah, it doesn’t work. The browser is like “I don’t know what to do with this information.” You know, just treat it like its own component… But yeah, it’s a really neat implementation.

Are there polyfills or anything you can do now, where you can kind of use a–

I don’t think so. There aren’t. I think it’s just Firefox that has it at the moment, and there’s no polyfills that I know of.

Okay. Well, that sounds like something a lot of people would like to have.

I mean, it very recently shipped, in like early December, so a month ago.

Alright, next up - somebody wants me to write TypeScript in 2020, and [unintelligible 00:50:11.09] Now, this one I have a feeling is a rickroll, and our resident rickroll expert is Nick Nisi.

It’s a nickroll.

I think it’s gonna happen. You’re gonna love it, Jerod.

Well, it’s not on my list of resolutions, that’s for sure… [laughter] And now that I know how bad you want it, I think it’s set in stone that it will not happen.

We’ll trick you into it somehow.

Trick me into it… We’ll see what happens. I would like to write some code at all in 2020, because man, the last six months I feel like I’ve written very little… Like, I write snippets and things here or there, or I fix bugs, but I haven’t had a… I haven’t had a six-hour coding session in probably six months, and I need more of that in my life. Probably the first time in 12-15 years that I haven’t had a serious, serious coding session in a very long time, so… I need to write some code at all, let alone… TypeScript. [laughter] See how I say that, with just disdain, and…

Yup. [laughter]


We’ll all be laughing about this in a year.

It’s like the guy at the end of Scooby-Doo [unintelligible 00:51:15.03] Alright… This has to be Kball, because somebody wants to see JS Party live shows on 4+ continents, and I know Kball wants to travel the world for JS Party, which - you can’t blame him… But that’s you, isn’t it, Kball?

That was 100% me. And I’m thinking North America, South America, Europe… Last year we hit three. So the key question is…

Which events were we at in 2019? We were at NodeConf Colombia…

[51:49] Yeah, so we were at JSConf Hawaii, we were at React Amsterdam, we were at NodeConf Colombia… Did we do a live show at JSConf US, or did we not end up doing that?

Not this year. So we didn’t do that. We were at All Things Open… Emma was at React Girls London, or something?

That’s right, React Girls London…

What else…?

And then Node+JS Interactive in Montreal.

And Node+JS Interactive.

Pretty good list.

Solid set, but I’d like to see us back in all those continents… I know we’re planning for NodeConf Colombia again, which I’m super-excited about. So we’ll have South America. I’m sure we’ll do something in North America. So getting something in Europe again, and then adding one, whether it’s Asia, or Africa… I don’t know.

Oh, yes…! You should think about – I think JSConf Asia is in Singapore, and then there’s WebConf Asia as well, which is in Hong Kong. And I think there’s a JSConf Japan as well, but I think that’s towards the end of the year.

That just passed, I think.

That just passed, yeah. That’d be cool.

But yeah, I’d love to see us get out to something, and just keep growing this thing, because JP Party - it’s a movement, it’s a worldwide party.

That’s right. So listeners, if you are in Africa, which is a large area of the Earth, or if you’re in Asia, which is another very large area of the Earth, and you either organize an event, or you’re going to an event in 2020, and you would love to have JS Party be involved, contact us via Twitter, @jspartyFM, or editors@changelog.com. However you like, get a hold of us. We’d love to work with you and make that a reality. JS Party live shows in 4+ continents. Now, let me say, if you’re out there listening in Antarctica - don’t call us. [laughter] We’re not going out there, it’s too cold.

I’ll go. I want to.

I’ll go.

Oh, wait a second…

Alright, alright…


Nick’s volunteered – I mean, you’ve just made it up to Montreal in December, so…

Same thing, right?

Well, how about Australia? Australia is a continent, right?

That’s right.

Yeah, I totally missed that.

Challenging our geography skills here today, as I forgot one major continent. Yes, I would love to go to Australia. Let’s make it happen, folks…

Let’s make it for 2020. Let’s see if we can hit six continents…

Okay, it is now time for us to lie to ourselves, and to each other, about what we’re gonna do this year. We’re gonna set out some resolutions and we’re gonna throw them out into the airwaves, so people can throw them back at us and say “See? You’re a failure.” No, we’re gonna succeed, and we’re gonna help each other succeed. And if you have your own resolutions, definitely share them with us. We can be accountability friends. Let’s go round robin and see what everybody would like to do in developer world in 2020. How about Chris? What’s your resolution?

So these are not modifiable resolutions, right?

[laughs] That’s a big out right there…

Recipe for disaster…

No, like - if you’re at your job and you’re setting your goals, and they need to be something like–

This is not a job.

It’s like an OKR…

That’s why I said, we’re all gonna lie to ourselves. You just go ahead and…

I’m not doing that.


Okay, I wrote here “I wanna spend more time maintaining my projects.” I didn’t get a lot of time this last year to work on Mocha especially, and I want to give it more time next year. There are some other very small projects that need more love as well. I spent about half of the year creating my new report-toolkit project for Node.js diagnostic reports… So yeah, Mocha needs love, and I wanna give it what it needs, and I hope I can do that. That would be my resolution.

That’ s a good one. Nick, your’s is blank. I’m wondering if maybe you’re just resolved not to have a resolution, or did you accidentally hit Delete? What’s up with you, Nick?

Yeah, I just wanna take it easy in 2020. Not think of anything… [laughter] No, I’ve been trying to think of this, like “Where do I wanna be a year from now in terms of this?” And one thing that I’ve been working on in my free time is I do – not to steal anyone else’s, because it seems like we’re all very much on the same page… But I want to write more and tweet more, and adding content. Good learning content, and things like.

OC. Original content.

Yes, exactly. So I’ve been doing what you normally do - or at least what I normally do in these cases - I’ve been rewriting my blog, so that I can actually write something… Because that’s the most important thing. I can’t write something until–

That’s the procrastinator’s toolbox right there.

Exactly! [laughs]

Working on your tools. So just generally… You don’t have any set goals. You just want to write and tweet more original content in 2020.

I think so, yeah.

Got it. Divya, your turn.

I also similarly feel very – every year I always tell myself that I’ll write more, and then it happens till February, and then it drops off, so I’m not gonna say that anymore. But I do want to – and this is not very quantifiable either, but I want to be more perceptive of working on my own things, because oftentimes… Like, I’m on the road a lot, so I end up being sucked into doing work stuff. Which I love, I absolutely love my job, but I also wanna work on things that are outside of that… Because I think you grow when you do things that are outside of your comfort zone a lot.

For me, that’s something that’s really important, personal development, outside of my area of expertise… I like how sometimes when I learn things, things I’m interested in and things that I end up going deep on [unintelligible 00:59:34.21] is not what I expect to be learning and doing… So I want to spend 2020 doing more of that. We’ll see if that even happens. It’s always – it’s so frustrating; it’s like the spring happens and then you forget everything. It’s the worst. But yeah, working on my personal projects.

[59:57] Honestly, I think people always talk about being public, and then being public means that you’re more accountable… But for me that doesn’t work, because oftentimes being public means I feel like it needs to be perfect, which ends up me not doing the thing, because I think it’s never ready, which is – I mean, not to call Nick out, but I would do the same thing, where I’ll be like “The blog needs to be perfect if I write anything”, or “My post needs to be perfect…”

Well, it does.

Yeah, it does. But then it never gets out the door, and that’s the problem. So for me, working on personal projects is a way for me to just squirrel away work that I’m doing, without having to be public. I think that allows me to grow publicly. People don’t have to see my process; I can do that without anyone looking at me… [laughs] Which I feel more comfortable with anyway. But yeah, hopefully they’ll help.

It sounds like a noble goal…

New year, new me…!

[laughs] I wish we’d do video right now, because that peace sign was epic. Okay, new year, new Divya. Is it a new Kball? It sounds like maybe it’s gonna be more/better Kball… What have you got going on?

More/better Kball… So my initial one, which then you wrote “Don’t steal my thunder”, so I’m gonna do another one, so you can do this, too…

So you’re gonna steal mine, and then one-up me?

And then one-up you… [laughter] No – alright, I won’t even do my original, so you can keep…

No, I was just joking. Go ahead.

So my original one is I’m gonna write at least one article beyond my newsletters each month. Now, I do have the newsletters, which keep me honest to writing regularly, but my amount of writing actual, standalone articles dropped off a lot over the course of the year, as we all know how that happens… So I’m gonna get back on that and be writing at least one each month, is my resolution there.

But my non-writing resolution, since we all have this shared “Oh, I’m gonna write more” thing, is I wanna do at least four live performances of things that are not tech. So it’s not JS Party live shows, or talks, or things like that. I do have a few different other things; I’ve been doing improv classes, so this last year I had three different improv performances, which was good… Hopefully, we’ll be able to continue that into the new year, and that would take care of this. But if not, I need to seek something else out. I also do dance, I used to do performances in competitive dance, so maybe that…


Karaoke - I don’t know if karaoke counts as a performance though…

Yeah it does, totally.

Yes, it does.

Alright, so karaoke… Maybe we’ll just go karaoke-ing and various conferences, and–

It sounds like an easy way of getting there.

Check-check… The other thing I’ve been thinking about exploring is stand-up, but I have not started that yet… So just high-level, at least four live performances, and we’ll see how that plays out. Most likely those will end up being improv, because I’m hoping to keep running with that, but it could be something else. We’ll see.

Well, I forgot what mine was, because Nick changed it to “Write more TypeScript”, so…

I did not change that.

[laughs] I wrote that…

Oh… I don’t know who’s who anymore… [laughter]

It was too good… It was too good.

Cats and dogs living together…

You wrote “Write more”, and there was nothing at the end of it. I was like “I have to finish this sentence…” [laughs]

So most years I refuse to do resolutions because of all the reasons that they are pitfalls… Or they aren’t pitfalls, but you have pitfalls – anyways, I often fail at them, and I end up worse off than I was, because I’m a bit of a failure. But a few years back I did resolve to write more, and I actually set a goal… I had a KYR – or what’s it called, Divya?

I had an OKR. Once a week I was gonna write for my personal blog; I could write about something technical or personal once a week. This was probably 2016-2017… And I made it really far. I made it like – it was past spring, let’s just say that. And once a week is difficult for lots of reasons, mostly because for me it’s inspiration. So the 1%, versus the 99% perspiration… I don’t have much of a trouble perspiring when I write; it’s the inspiration that I struggle with. I just can’t think of things to write about, so once a week is difficult.

[01:04:08.28] That means that I do want to write more (non-TypeScript), and I’m thinking I would like to set a goal of every other week, and see how far I make it. So that’s what I’m going to do… It’s going to be technical writing, OC, as Nick would say, original content; not just link blogging, which is a lot of what we do at Changelog News - pointing to interesting things… That doesn’t count, because I do that multiple times every day. But original posts, I would love to do every other week… And we’ll see how this goes.

So there you have it, friends - our predictions, our wishlists, and our resolutions for the year ahead. That’s our show. Welcome to 2020! We’ll talk to you again next time!

Alright, break.

Alright, coffee time. I’ll be right back.

I need to send – I need to find that… I have a gif with…

It’s a gif [ghiff].

…for Kball.

It’s a gif [jiff]

Uh-oh… [laughter] We have our next Yep/Nope topic.

Actually, I tweeted about the ASM versus ESM thing, and then like… [laughs] I think I’m the only one who says ASM at the moment.

You’re trying to make everybody change…

I’m trying to make it a thing.

ASM? It’s just hard to say.

No, it’s not…

It sounds like asthm… Which is like Asm.js. That’s confusing.

I like it.

Thank you.

Well, you’ve got one. Yeah, but he likes TypeScript, so…



Can’t be trusted.

Oh, my wishlist - Jerod will be writing TypeScript. [laughter]

That is a good one, I like that.

Oh yes, I’ve found it. Okay.

Keep wishing, Nick. Keep wishing. I probably would have tried it by now if it wasn’t for this show, but… I’ve made it my enemy, so I can’t give it a shot. It’s a part of my identity now; I’m anti-TypeScript by identity.

At the new job that we’re working at we have a new part of the codebase that’s in TypeScript, and an old part that is not… And I have to say it’s pretty darn nice, the TypeScript part. There’s a lot to be said of – however, the downside is the new part is also in React, the old part is in Vue… And I like React a lot less than I like Vue, to be honest.

Yes. I’m in the same with boat with React. Not necessarily with Vue; I’ve never looked at Vue. But I just don’t see…

Sorry, what? I missed it. You don’t like React, or you do?

I don’t.

So yeah, at my new job where I’m working, we have an old part of the codebase that is vanilla JavaScript and Vue, and a new part that is TypeScript and React on the front-end… And the TypeScript is actually really nice. It’s much nicer to be working in the TypeScript than in vanilla JavaScript, when it’s a large codebase with lots of people touching it… But I am being reminded that I like Vue a lot better than I like React.

Oh, gotcha. It’s alright.

That’s okay. The last couple weeks I’ve been working deep on the back-end on some things, so I don’t have to worry about it.

Kball, when did you get a new job?

I started a new job almost exactly a month ago.

I thought you were doing freelancing.

I was.

Until a month ago.

Until a month ago. I got a really cool opportunity, at a job that is very aligned with my interests, and they were okay with me only working three-quarters time, so that I can still podcast and I can still write my newsletter and do various other things without it eating up the rest of my day… Which was one of the big reasons I wanted to stay freelancing. So I’m excited about it.


Where is this job?

It’s in downtown Mountain View. It’s a company called Humu, and it’s focused on essentially applying learnings from behavioral economics and psychology to make workplaces better. We’re building tooling that helps with things like improving culture, manager effectiveness and diversity and inclusion.

I was worried you were gonna say advertising.


What’s the name Humu about?

Is that a humu-humu-nuku-nuku-apua’a?

That is the origin, yes.

I don’t know what that is either.

I have no idea what that is.

So humu-humu-nuku-nuku-apua’a is a type of fish from Hawaii… [laughter]

It’s like a [unintelligible 01:09:29.17]

Yeah, it’s the state fish of Hawaii…

Okay… [unintelligible 01:09:34.26]

…which my six-year-old absolutely loves saying now.

Can we name this episode that? Done. [laughs]

No, because this is the break. [laughter]

Prediction for 2020.

Prediction - nobody will understand this episode name.

There, it is spelled now in the JS Party chat.

But anyway, the company is just Humu, which is a lot easier.

Yeah, humu-humu-nuku-kunu-kapua’a. [laughter] I just tried to read that letter for letter.


Yeah. The Hawaiian is very simple.

It just needs the spaces in it, so I can read it with the breaks. Anyways, we should get back to the show…

[laughs] But yeah, anyway - new job. It’s awesome so far. I’ve been there almost exactly a month, so I’m still in honeymoon, so… We’ll see. And TypeScript is winning me over, React is not so much.

More to come on that drama… During the next break, perhaps… Okay.


Our transcripts are open source on GitHub. Improvements are welcome. đź’š

Player art
  0:00 / 0:00