Jerod Santo: 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.
Christopher Hiller: Hi, Chris.
Jerod Santo: I should have seen that one coming. You know Kball is always down to party... What's up, Kball?
Kevin Ball: Yo, yo, yo! Here I am!
Jerod Santo: And Nick is back from Montreal. Hoy-hoy, Nick.
Nick Nisi: Hoy, hoy.
Jerod Santo: And of course, our favorite Vue Vixen is with us... It's Divya!
Divya Sasidharan: Ho-ho-ho!
Christopher Hiller: What does "hoy, hoy" mean?
Jerod Santo: It means hello...
Christopher Hiller: Is that a thing?
Kevin Ball: It's a thing.
Christopher Hiller: I've never heard that before.
Nick Nisi: It's how Mr. Burns answers the phone in the Simpsons.
Christopher Hiller: Oh...
Kevin Ball: It's also Nick's calling card these days.
Jerod Santo: 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.
Divya Sasidharan: I tried to be seasonal, but I'm a little late. But it's close enough to Christmas, I guess, after January. [laughs]
Jerod Santo: 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?
Nick Nisi: 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.
Kevin Ball: Oh, interesting.
Christopher Hiller: Didn't somebody release a proof of concept or something for this, for Python?
Nick Nisi: [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]
Kevin Ball: Interesting. So it's like NLP model predictions, but for code.
Nick Nisi: 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.
Kevin Ball: Interesting.
Jerod Santo: 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.
Nick Nisi: That too.
Jerod Santo: That too. [laughter]
Divya Sasidharan: 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.
Kevin Ball: Wait, wait, wait... That's just started this year? What's WordPress?
Divya Sasidharan: Webflow.
Jerod Santo: Isn't Wizzywig the same idea?
Divya Sasidharan: 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--
Jerod Santo: Oh...! The marketing machine has kicked on.
Divya Sasidharan: Yes, exactly. Because you could stuff with Dreamweaver...
Jerod Santo: Much like with JAMstack, which is the way that people have been building websites for years and years and years...
Divya Sasidharan: 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.
Nick Nisi: I refuse to recognize this existential threat. [laughter]
Jerod Santo: Yes, I'll bury my head in the sand and say "This is never gonna happen."
Christopher Hiller: 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?
Kevin Ball: 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--
Jerod Santo: Like go fishing?
Kevin Ball: ...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...
Jerod Santo: [08:19] There's Wix, Squarespace...
Kevin Ball: 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.
Christopher Hiller: 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]
Divya Sasidharan: 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.
Jerod Santo: 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?
Nick Nisi: I agree, one hundred percent.
Kevin Ball: I would like to agree...
Jerod Santo: But you don't...?
Kevin Ball: Well, I'm trying to dig up real quick what the trajectory has been.
Jerod Santo: 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.
Christopher Hiller: I think as Chromium Edge matures, we'll see more people using that on Windows.
Kevin Ball: [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.
Jerod Santo: 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.
Divya Sasidharan: 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.
Nick Nisi: 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.
Jerod Santo: 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?
Kevin Ball: 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.
Divya Sasidharan: Doesn't Elm also sit technically in the same vein as Svelte, because it is compiled to JavaScript?
Kevin Ball: I guess that's true... Does it ship with a runtime though?
Jerod Santo: I believe it does.
Divya Sasidharan: I believe it does.
Kevin Ball: [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."
Divya Sasidharan: Got it.
Kevin Ball: But Elm may be doing more of that than I'm aware of.
Divya Sasidharan: 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.
Christopher Hiller: Does anybody who's using Svelte know, is New York Times using it?
Divya Sasidharan: 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.
Jerod Santo: 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."
Divya Sasidharan: Yeah.
Christopher Hiller: 2020 is the rise of microframeworks on the front-end... [laughter]
Divya Sasidharan: Microfrontends, microframeworks.
Kevin Ball: I did find it interesting--
Christopher Hiller: Microfrontends, right...
Kevin Ball: 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."
Divya Sasidharan: Oh, wow.
Christopher Hiller: Wait, wait, wait... They wrote 20,000 lines of code and it compiled to 50,000 lines of code?
Kevin Ball: Apparently...
Christopher Hiller: Whoops...
Divya Sasidharan: [laughs]
Jerod Santo: 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.
Divya Sasidharan: Today I learned...
Jerod Santo: TIL. Well, take that, Kball...
Divya Sasidharan: [laughs]
Kevin Ball: [laughs] Alright...
Jerod Santo: Alright, taken.
Kevin Ball: Well, it sounds like there needs to be more competition.
Jerod Santo: [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.
Divya Sasidharan: Yeah.
Jerod Santo: 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...
Divya Sasidharan: It's just predicting what it'll be called, and what will be the distinguishing factor.
Jerod Santo: 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]
Nick Nisi: 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.
Kevin Ball: Hm...
Jerod Santo: Hm...
Christopher Hiller: Hm...
Divya Sasidharan: Hm...
Nick Nisi: I love those groans... Keep them coming.
Jerod Santo: 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.
Kevin Ball: 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++.
Divya Sasidharan: It'll essentially be like CoffeeScript, so it'll just be adopted into JavaScript, and then people won't talk about CoffeeScript anymore...
Christopher Hiller: Hmmm...! [laughter]
Jerod Santo: Chris is bringing the groans... Who predicted that the computing at the edge will take off? CloudFlare workers, Akamai, edge workers etc.
Divya Sasidharan: I wrote that.
Kevin Ball: I was gonna say, I'm gonna guess Divya, because that's her company's nuts and bolts, right?
Jerod Santo: Oh...!
Divya Sasidharan: Yeah, but I...
Jerod Santo: You didn't put Netlify workers in here...?
Divya Sasidharan: 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.
Jerod Santo: 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?
Divya Sasidharan: 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...
Jerod Santo: 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?
Kevin Ball: 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.
Jerod Santo: 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?
Kevin Ball: Think about it as caching.
Divya Sasidharan: 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.
Jerod Santo: 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.
Kevin Ball: Oh, I had a fascinating conversation about that at JAMstack, and I realized we have not shipped that conversation yet... [laughter]
Jerod Santo: [28:02] Hm... Give us the elevator pitch, or the micro-summary...
Kevin Ball: 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.
Jerod Santo: Which probably gets harder and harder as the size of your database goes up as well... So there's lots of--
Kevin Ball: Yeah, there's lots of different pieces.
Jerod Santo: 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.
Christopher Hiller: 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?
Jerod Santo: 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.
Kevin Ball: Have you talked to Feross about it? [laughter] Because I'm sure he's figured out how to use it to destroy your machine.
Jerod Santo: [laughs] Exactly.
Divya Sasidharan: 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.
Christopher Hiller: 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...
Divya Sasidharan: Yeah, I'll be sure to call all my folders like XXX... [laughs]
Jerod Santo: Can you synchronize groaning...? Yeah, I'm not sure if the other vendors have said they're gonna implement this...
Divya Sasidharan: I have no idea...
Jerod Santo: [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.
Christopher Hiller: 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?
Jerod Santo: Exactly.
Christopher Hiller: 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.
Divya Sasidharan: 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.
Kevin Ball: 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.
Jerod Santo: Mm-hm. I think that's fair.
Kevin Ball: 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.
Divya Sasidharan: But at the same time, I don't think you should make it easier.
Jerod Santo: 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..."
Kevin Ball: 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.
Christopher Hiller: You know what would be really cool? This would enable so much awesome tooling.
Divya Sasidharan: Oh, for sure.
Christopher Hiller: 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...
Jerod Santo: 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.
Break: [35:26]
Jerod Santo: 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.
Christopher Hiller: It is not.
Jerod Santo: It is not? Okay, then I'll go to Nick. Is it Nick? "Facebook puts React into an external foundation." Is that you, Nick?
Divya Sasidharan: Oh, Kball...
Nick Nisi: It is not me...
Jerod Santo: Oh man, I suck at this game... [laughter] Okay, Kball wrote that?
Kevin Ball: Kball wrote that.
Jerod Santo: Why do you care?
Kevin Ball: 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.
Nick Nisi: Mm-hm.
Christopher Hiller: 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.
Kevin Ball: 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.
Jerod Santo: What would that practically, in a regular developer's life, what would that change or do? What would be the implications of that?
Kevin Ball: 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.
Christopher Hiller: 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.
Nick Nisi: 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.
Kevin Ball: 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.
Nick Nisi: 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.
Jerod Santo: I think it's funny both ways.
Christopher Hiller: 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?
Divya Sasidharan: 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...
Jerod Santo: Yeah, it's governance.
Divya Sasidharan: ...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.
Jerod Santo: Yeah, because what if Vue gets hit by a bus? [laughter]
Kevin Ball: 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.
Jerod Santo: For Now. BDFN.
Kevin Ball: Yeah.
Jerod Santo: 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?
Divya Sasidharan: It's supposed to come out at the end of the year...
Nick Nisi: Is that like [unintelligible 00:42:38.25]
Jerod Santo: The end of 2019...
Divya Sasidharan: The end of 2019 was what it was slated for, but I don't think there's a date...
Jerod Santo: But it didn't come out.
Divya Sasidharan: ...it hasn't shipped yet.
Jerod Santo: It didn't ship in 2019.
Kevin Ball: But we're recording from the future, so maybe...
Divya Sasidharan: Oh, maybe... Oh, no...!
Jerod Santo: So if this ships between December 19th and January 2nd, then this whole section - you can just hit fast-forward.
Divya Sasidharan: I've never wished for something not to ship so much. [laughter]
Jerod Santo: So you're changing your wishlist. You're hoping it doesn't ship until this show comes out, and then you hope it ships.
Divya Sasidharan: Yes.
Jerod Santo: Gotcha.
Kevin Ball: It'll ship on the second.
Divya Sasidharan: I know. Oh...
Jerod Santo: That would be nice.
Divya Sasidharan: That would be really nice. We'd be like forward-thinking. That's the whole point, right?
Jerod Santo: Well, you get what you want immediately.
Divya Sasidharan: Yes!
Jerod Santo: Nobody wants to wait for their wants. "Just give it to me."
Divya Sasidharan: 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.
Jerod Santo: 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...
Divya Sasidharan: I think that was Kball. Wrong again.
Jerod Santo: [44:05] Gosh! I'm betting zero on this... I can't put Divya in a corner, like "You're the Vue person."
Divya Sasidharan: [laughs] I mean, you had two options to pick for me; you've picked the wrong one, so...
Jerod Santo: Yeah... I'll get this eventually.
Kevin Ball: I have a lot of wishlist items.
Jerod Santo: Generalize it?
Nick Nisi: 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.
Divya Sasidharan: Yeah, that's totally true.
Jerod Santo: What's OS data tables? Open source?
Divya Sasidharan: Open source.
Jerod Santo: Oh, okay. I thought it meant operating system, because I was confused...
Kevin Ball: 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.
Jerod Santo: Shout-out to SlickGrid. Anybody remember SlickGrid? Just me... Alright.
Nick Nisi: I do.
Divya Sasidharan: [laughs]
Nick Nisi: It was slick.
Jerod Santo: 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...
Kevin Ball: [laughs]
Jerod Santo: Chris? Yessss!
Divya Sasidharan: Nice. [laughs]
Christopher Hiller: 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.
Divya Sasidharan: What was it called again, the thing that you were mentioning that Facebook implements?
Christopher Hiller: I think it's called Yoda.
Divya Sasidharan: Yoda... Yoga?
Christopher Hiller: Yoga. Yoga, not Yoda. Yoga.
Divya Sasidharan: Oh, okay.
Jerod Santo: So is that Baby Yoga?
Divya Sasidharan: Baby Yoga...
Christopher Hiller: Yoga. Yoga is the Flexbox thing.
Divya Sasidharan: Oh my gosh, now I really want someone to implement an open source component for CLIs called Yoda, just because... [laughs]
Christopher Hiller: 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.
Divya Sasidharan: That would be really nice.
Jerod Santo: 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.
Kevin Ball: 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.
Divya Sasidharan: 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.
Kevin Ball: It doesn't work.
Divya Sasidharan: 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.
Jerod Santo: Are there polyfills or anything you can do now, where you can kind of use a--
Divya Sasidharan: 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.
Jerod Santo: Okay. Well, that sounds like something a lot of people would like to have.
Divya Sasidharan: I mean, it very recently shipped, in like early December, so a month ago.
Jerod Santo: 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.
Kevin Ball: It's a nickroll.
Nick Nisi: I think it's gonna happen. You're gonna love it, Jerod.
Jerod Santo: 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.
Nick Nisi: We'll trick you into it somehow.
Jerod Santo: 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...
Kevin Ball: Yup. [laughter]
Jerod Santo: TypeScrrript!
Nick Nisi: We'll all be laughing about this in a year.
Jerod Santo: 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?
Kevin Ball: That was 100% me. And I'm thinking North America, South America, Europe... Last year we hit three. So the key question is...
Jerod Santo: Which events were we at in 2019? We were at NodeConf Colombia...
Kevin Ball: [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?
Jerod Santo: Nope.
Kevin Ball: Not this year. So we didn't do that. We were at All Things Open... Emma was at React Girls London, or something?
Jerod Santo: That's right, React Girls London...
Kevin Ball: What else...?
Jerod Santo: And then Node+JS Interactive in Montreal.
Kevin Ball: And Node+JS Interactive.
Jerod Santo: Pretty good list.
Kevin Ball: 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.
Divya Sasidharan: 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.
Kevin Ball: That just passed, I think.
Divya Sasidharan: That just passed, yeah. That'd be cool.
Kevin Ball: 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.
Jerod Santo: 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.
Nick Nisi: I'll go. I want to.
Divya Sasidharan: I'll go.
Jerod Santo: Oh, wait a second...
Kevin Ball: Alright, alright...
Jerod Santo: Okay...
Kevin Ball: Nick's volunteered -- I mean, you've just made it up to Montreal in December, so...
Nick Nisi: Same thing, right?
Kevin Ball: Well, how about Australia? Australia is a continent, right?
Jerod Santo: That's right.
Divya Sasidharan: Yeah, I totally missed that.
Jerod Santo: 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...
Kevin Ball: Let's make it for 2020. Let's see if we can hit six continents...
Break: [54:23]
Jerod Santo: 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?
Christopher Hiller: So these are not modifiable resolutions, right?
Jerod Santo: [laughs] That's a big out right there...
Divya Sasidharan: Recipe for disaster...
Christopher Hiller: No, like - if you're at your job and you're setting your goals, and they need to be something like--
Jerod Santo: This is not a job.
Divya Sasidharan: It's like an OKR...
Jerod Santo: That's why I said, we're all gonna lie to ourselves. You just go ahead and...
Christopher Hiller: I'm not doing that.
Jerod Santo: [laughs]
Christopher Hiller: 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.
Jerod Santo: 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?
Nick Nisi: 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.
Jerod Santo: OC. Original content.
Nick Nisi: 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--
Jerod Santo: That's the procrastinator's toolbox right there.
Nick Nisi: Exactly! [laughs]
Jerod Santo: 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.
Nick Nisi: I think so, yeah.
Jerod Santo: Got it. Divya, your turn.
Divya Sasidharan: 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..."
Nick Nisi: Well, it does.
Divya Sasidharan: 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.
Jerod Santo: It sounds like a noble goal...
Divya Sasidharan: New year, new me...!
Jerod Santo: [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?
Kevin Ball: 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...
Jerod Santo: So you're gonna steal mine, and then one-up me?
Kevin Ball: And then one-up you... [laughter] No -- alright, I won't even do my original, so you can keep...
Jerod Santo: No, I was just joking. Go ahead.
Kevin Ball: 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...
Nick Nisi: Karaoke?
Kevin Ball: Karaoke - I don't know if karaoke counts as a performance though...
Divya Sasidharan: Yeah it does, totally.
Nick Nisi: Yes, it does.
Kevin Ball: Alright, so karaoke... Maybe we'll just go karaoke-ing and various conferences, and--
Jerod Santo: It sounds like an easy way of getting there.
Kevin Ball: 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.
Jerod Santo: Well, I forgot what mine was, because Nick changed it to "Write more TypeScript", so...
Nick Nisi: I did not change that.
Divya Sasidharan: [laughs] I wrote that...
Jerod Santo: Oh... I don't know who's who anymore... [laughter]
Divya Sasidharan: It was too good... It was too good.
Jerod Santo: Cats and dogs living together...
Divya Sasidharan: You wrote "Write more", and there was nothing at the end of it. I was like "I have to finish this sentence..." [laughs]
Jerod Santo: 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?
Divya Sasidharan: An OKR?
Kevin Ball: OKR?
Jerod Santo: 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!
Break: [01:04:58.04]
Jerod Santo: Alright, break.
Kevin Ball: Alright, coffee time. I'll be right back.
Divya Sasidharan: I need to send -- I need to find that... I have a gif with...
Jerod Santo: It's a gif [ghiff].
Divya Sasidharan: ...for Kball.
Christopher Hiller: It's a gif [jiff]
Jerod Santo: Uh-oh... [laughter] We have our next Yep/Nope topic.
Divya Sasidharan: 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.
Jerod Santo: You're trying to make everybody change...
Divya Sasidharan: I'm trying to make it a thing.
Jerod Santo: ASM? It's just hard to say.
Divya Sasidharan: No, it's not...
Jerod Santo: It sounds like asthm... Which is like Asm.js. That's confusing.
Nick Nisi: I like it.
Divya Sasidharan: Thank you.
Jerod Santo: Well, you've got one. Yeah, but he likes TypeScript, so...
Divya Sasidharan: [laughs]
Nick Nisi: Ho-ho...
Jerod Santo: Can't be trusted.
Nick Nisi: Oh, my wishlist - Jerod will be writing TypeScript. [laughter]
Jerod Santo: That is a good one, I like that.
Divya Sasidharan: Oh yes, I've found it. Okay.
Jerod Santo: 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.
Kevin Ball: 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.
Nick Nisi: 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...
Jerod Santo: Sorry, what? I missed it. You don't like React, or you do?
Nick Nisi: I don't.
Kevin Ball: 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.
Jerod Santo: Oh, gotcha. It's alright.
Kevin Ball: 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.
Christopher Hiller: Kball, when did you get a new job?
Kevin Ball: I started a new job almost exactly a month ago.
Christopher Hiller: I thought you were doing freelancing.
Kevin Ball: I was.
Jerod Santo: Until a month ago.
Kevin Ball: 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.
Jerod Santo: Awesome.
Christopher Hiller: Where is this job?
Kevin Ball: 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.
Christopher Hiller: I was worried you were gonna say advertising.
Kevin Ball: No...
Jerod Santo: What's the name Humu about?
Christopher Hiller: Is that a humu-humu-nuku-nuku-apua'a?
Kevin Ball: That is the origin, yes.
Jerod Santo: I don't know what that is either.
Divya Sasidharan: I have no idea what that is.
Kevin Ball: So humu-humu-nuku-nuku-apua'a is a type of fish from Hawaii... [laughter]
Divya Sasidharan: It's like a [unintelligible 01:09:29.17]
Kevin Ball: Yeah, it's the state fish of Hawaii...
Jerod Santo: Okay... [unintelligible 01:09:34.26]
Kevin Ball: ...which my six-year-old absolutely loves saying now.
Divya Sasidharan: Can we name this episode that? Done. [laughs]
Jerod Santo: No, because this is the break. [laughter]
Divya Sasidharan: Prediction for 2020.
Jerod Santo: Prediction - nobody will understand this episode name.
Christopher Hiller: There, it is spelled now in the JS Party chat.
Kevin Ball: But anyway, the company is just Humu, which is a lot easier.
Jerod Santo: Yeah, humu-humu-nuku-kunu-kapua'a. [laughter] I just tried to read that letter for letter.
Kevin Ball: Humu-humu-nuku-nuku-apua'a.
Christopher Hiller: Yeah. The Hawaiian is very simple.
Jerod Santo: It just needs the spaces in it, so I can read it with the breaks. Anyways, we should get back to the show...
Kevin Ball: [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.
Jerod Santo: More to come on that drama... During the next break, perhaps... Okay.