You fought in the framework wars?

Hello, JS Party people out there! Whether you’re live, or listening to this delayed on the podcast, we are excited to have you back with us. I will be your host today, this is Kball. I’m joined by two of our amazing panelists, Divya and Chris. Divya, how’s it going?

Life is good. I’m getting over jet lag, and starting to feel normal during the day again.

Chris, how are you doing?

Super-duper. How are you doing? I know you’ve just answered that question… [laughter] But that’s how we do it here in the States.

It is, we have all these automatics. “How are you doing?” Well, I can’t say “Bad”, because then you actually have to have a conversation. You’ve gotta say “Well, life’s good… Fine… How are you?”

Alright, so our episode today - we are going to do three of our recurring segments, except one of them is brand new. We’re gonna experiment with a new segment. So if you’re listening to this, let us know what you think of our new segment.

We will start off with a segment called The Framework Wars. We’re not gonna make it into an actual war, but… One of the big, rapidly-changing, hard-to-keep-track-of things in the JavaScript world is all these crazy front-end frameworks, so we’re gonna do some quick hits on what’s going on in at least some of the big ones, some new stuff we’ve checked out… I think Divya is excited to talk about Vue; I don’t blame her, Vue is pretty awesome. But then there’s interesting things happening in React land, Angular, I think we might touch on Svelte a little bit… That type of thing. Then we will kick into another segment on pro tips, and close out with some shout-outs to awesome stuff in the community.

Let’s start on framework wars. The framework wars, if we were gonna go in order of use and popularity, we should start with React, but instead let’s go with the order of enthusiasm of panelists… Divya, do you wanna tell us what’s going on with Vue?

[04:20] Yeah. I thought it was awesome, but there was definitely some blowback going on there.

Thank you for that summary. I thought it was an interesting thing to observe in real-time. Vue has relatively recently adopted a process where they’re asking for feedback, they’re proposing things before they implement things, and this was kind of a – I mean, on the one hand they got exposed to a lot of fire from that. On the other hand, they probably kept themselves from making some missteps by doing this, because they heard about it early enough in the process that it was easy to adjust.

I’ve heard people say “pulling an Angular”, or making a mistake… I think we should just have a word and say something like “If a library or a project completely breaks all of its API in this terrible way that alienates all its users, it’s an angularization of the project.” [laughter]

Yeah, it needs to be a verb. Angularize.

Yeah. Change management is hard.

I really like what Ember does on this, even if it’s a little unintuitive for folks coming from other places. In their major releases, Ember are never adding new features. Major releases are for removing deprecated features. So over the course of a set of minor releases they’ll add new features, they’ll deprecate old features, so they give you lots of time to migrate, and then a major upgrade is not about adding new functionality, it’s about removing that deprecated stuff that’s been around long enough you’ve probably moved off it anyway.

Yeah, and you introduce the new features early on, so they’ll never remove functionality in a minor release. They’ll always add or deprecate. So you introduce stuff, and people can start experimenting and trying things, but you never have a backwards-incompatible break, except at a major, and there you’ve always had a long run-up leading into it.

Other stuff going on in some of the other frameworks… React obviously had their big Hooks release a while back. That’s almost old news, except that it’s inspiring Vue… But they’re working hard on some new things related to concurrent mode and suspense, which I think are pretty interesting. They’re allowing much cleaner component-related abstractions around asynchronous stuff - how do we represent a state while we’re off fetching data, and coming back.

There was a really fun, in-depth blog post that Dan Abramov did, because he loves to tie up all developers’ productivity as they try to wrap their heads around his blog posts… And he wrote this post on this concept of algebraic effects, which is one of the things they’re using inside Suspense, I think. But basically being able to more or less do goto statements, or doing try-catch stuff, but where you can kind of move back and forth between different layers of the stack in pretty powerful ways.

I’m excited to see what they’re doing there – we’ve seen before that frameworks can push languages forward. A lot of functionality that is in JavaScript now is in it because of things like jQuery and Dojo, that early on were working around the limitations of the language and of DOM APIs, and now they’ve been embedded in web APIs and embedded in the language. Some of the stuff that React is doing now I think is really pushing the entire ecosystem forward in pretty interesting ways.

Even a framework like Ember, that is driven by quite a team, that’s distributed, but it’s not owned by a single company - it’s more community-driven; they have much more of a community process.

That said, they have very large numbers of core team members who are inside of big companies. I think their core team is quite large, compared to for example Vue, which was for so long the one-person-driven thing… And even though it has expanded, it’s still a pretty small core team, relative to the popularity of the project.

This type of cross-proliferation is super-cool. One of the things I love about the Vue Functions API that we were talking about is how it takes concepts that were introduced with Hooks - which were really quite innovative - and adapts them to the somewhat different mental model that Vue has, and the way that Vue approaches reactivity… And it almost – I mean, part of this is my bias, enjoying Vue quite a lot, but it feels almost more natural in the second iteration. It works really cleanly with Vue’s reactivity model.

That sounds magic…

For what it’s worth – and I’ve barely used React… But when I’ve first touched it, it was after Hooks had come out, and it made a lot of sense; not having all this baggage of what React used to do in my head. It was like “Oh, I’ll just use this thing, and there you go.” Of course, I haven’t looked at some of the other functions that people talk about, like useEffect, or whatever… But Hooks seem to make a lot of sense to me just coming in as a newb with React.

Yeah, I like the Hooks approach. It’s a very approachable concept, it’s just different enough that people who were deeply invested in there absolutely had a little bit of an adjustment…

Yeah. And that seemed to be a big part of the uproar with Vue - people who didn’t wanna have to change their stuff. I don’t know if they were – you probably have a better idea if they were actually against the idea itself, or just that they didn’t wanna have to change how they were writing code.

I think there was definitely some of each there… But yeah. There’s a lot of just resistance. “I like what it is! I don’t wanna change it!” And it’s something that is important for framework and library maintainers to remember - we like continuity; there’s enough stuff changing in the world. Things that we can hold on to are rare and valuable.

Wasn’t some of the motivation there to better support TypeScript, essentially?

Yes.

Can you explain in a nutshell what that problem is?

I can explain a little bit… Though maybe Divya you may know a little bit more… But I think one of the big challenges with supporting TypeScript within Vue is that it uses a lot of essentially metaprogramming and introspection, which is somewhat magical, and can be somewhat hard to represent with types.

[19:59] People who have used Ruby and Rails a lot may know that there they used a lot of metaprogramming, and if you try to come in and insert hard types – or at least early days I always ran into typing problems, because the introspection in metaprogramming meant you had to do a lot of extra stuff to deal with types. Ruby has a very flexible type system. TypeScript – I don’t know. It’s challenging… It’s trying not to be duck-typed in the way that Ruby is.

Going to a functions-based API, it removes – Divya, you said there’s no magic… There’s still magic. Reactivity still feels like magic. But it removes some of the magic. It’s just functions. It’s functions with defined types for their arguments. It’s easy to model and represent a system in a way that a type checker can validate, as opposed to something that’s assuming properties on an object that may or may not be there, that can be set dynamically in various ways. Was that a fair assessment?

One thing I wanna make sure we touch on before we leave a segment on frameworks is Angular. They are often neglected by me personally, I know, and I think by other folks on this show, but they do still have huge numbers of people using them, especially in the enterprise world.

I did a little looking to see what’s new in Angular. It sounds like much of the buzz right now is around Angular Ivy, which is a new compiler/engine/renderer. I’m not being an Angular expert, I don’t know exactly how it fits into the ecosystem. Some of the touted benefits include reducing bundle size, though coming from Vue – I was looking at the bundle sizes they were quoting and being like “Really…?”

There was an example on a blog post that I’ll put here, where it’s like “Oh yeah, with Angular Ivy we dropped the bundle size from 509 kilobytes to 432.” And I was kind of groaning a little bit about size…

This is Angular…

I believe it is opt-in-able, but not the default, for their renderer.

They’ve recently released version eight.

And that made Ivy available, but opt-in.

Frankly, it feels to me that on many dimensions they are catching up. Some of the other touted benefits are now it’s easier to do higher-order components, and things like that, that have been around in Vue and React for a long time. I do believe that some of the functionality that exists in Angular around managing large-scale applications, the way they do dependency injection - all of that sort of stuff provides substantial benefits for people who are doing massive projects.

But yeah, it feels like right now they’re in many ways doing the same thing Vue is doing with the Functions API, of playing catch-up to innovations that have happened elsewhere in the ecosystem.

I think so, because one of the things touted is faster compilation, but…

Anyway, this is definitely outside any of our expertise, it looks like. If you are an Angular expert, I would love to hear from you a little bit more about how this works… So you can jump into the JS Party Slack channel, you can tweet at me or at JS Party.

I think there’s some interesting stuff going on in that world, but I feel like I’m kind of outside of it. But because Angular is still quite widely used, especially at larger enterprises, I felt we would be negligent if we did not bring it up.

One last thing that I think is really interesting going on in front-end frameworks right now is this idea of compile-time frameworks. The one in particular I’m thinking of is Svelte. Chris, you mentioned that you’ve played around with it some. Do you wanna talk to us about Svelte?

There’s really not a whole lot I can say, except that I was working on an app, I was just kind of playing around, trying to get something working with Node SerialPort in Electron… And I wanted to try a framework and didn’t wanna get into a huge toolchain, like with Create React App, or – Vue’s toolchain is sizeable… All these boilerplates drive me nuts, but that’s another thing. So I didn’t wanna use the boilerplate. I found something very simple with Svelte - it’s basically you have like a roll-up config, and you run the thing and it compiles the thing… And you look at your code, it is – it’s kind of like Vue, where you have this (I think it’s a) .svelte file, which is kind of analogous to a .vue file… Where you have your script, you have your styles, you have your markup in there… It is so straightforward and simple and elegant, and just like “Wow! How easy can this be?”

My brain melted a little bit, just because it was far and away the most straightforward and easy to understand framework that I’ve used in a long, long time. I think definitely people should take a closer look at Svelte, from that end of things, the architecture of the project.

[27:58] What’s different about Svelte, as far as I understand, is essentially it has no runtime; it’s just a compiler. And you write this code, that follows these conventions, and it poops out a bundle, and markup, and whatever it needs to do, and it runs. And the bundle sizes are very small. There’s not a lot of startup overhead, because it doesn’t have to bootstrap all this stuff… It’s just kind of incredible, and a great idea, and I feel like frameworks are going to start moving in that direction, where they get rid of this whole overhead of loading a runtime in your browser, or what have you, and it’s just simply compiling down to minimal vanilla JavaScript.

But because of that architecture they could optimize for - well, what’s the simplest straightforward thing we can do? Let’s look at what’s been successful in the past. People talk about how easy Vue is to understand for somebody who’s really new to JavaScript or web development. They went with that idea, I think, and just kind of “Let’s make this even easier, and just simple and straightforward.

I was really impressed with Svelte. I don’t really build too many web apps. If I do, they are of the hobby variety… But I’m definitely going to take a look at it, and I’m gonna keep working with it on this particular project, because… Yeah, it’s awesome.

Yeah, I noticed that and I didn’t pick it up because it’s an Electron app that needs to use a native module, which can kind of a harrowing experience. If you have a dev server running in Node and you need to use a native module, you’re SOL.

I tried to use Next.js, I tried to use Nuxt.js, and neither of these things worked for me, because I needed that native module… And if the dev server is running in Node - well, the native module is compiled for Electron… It’s water and oil; it just doesn’t work. But yeah, that definitely looks like a pretty cool server-side framework… Sappa? Sapper?

Sapper…

And with that, I think we can wrap up this segment, the framework wars. This was our first try on it, so listeners - let us know, give us some feedback. Did you like it, did you not like it? Was this useful?

When we come back from our break, we will be talking about some pro tips, things you can use today to make your life, your development better. Talk to you on the other side.

Welcome back, JS partiers! We are here to talk about pro tips. Pro tips from each of our panelists. It looks like - Chris and Divya, you both have very technical-related pro tips, whereas I have kind of an interpersonal one… So let’s sandwich me in the middle. Either of you wanna particularly go first?

I can go first. I write JavaScript, I do not write TypeScript, so I’m used to using doc strings. So I’m using doc strings, and I’m seeing that VS Code is giving me some information about types, and it’s able to understand the doc strings, and stuff… So I’m like “Huh, that’s neat.” So I was digging into it more, and I’m like “How can I make this work even better?” So I got kind of OCD about the Doc strings, and was reading up in the VS Code side about writing – there’s like a guide or two on there about writing JavaScript in VS Code; how it works, and how you can get better integration.

One of the things I started doing was in my JavaScript files I would put a little directive in a comment called @ts-check. What that does is it enables the TypeScript language server to essentially check your JavaScript. So because JavaScript is a subset or TypeScript, or TypeScript is a superset of JavaScript, or whatever - because of that, when you’re writing JavaScript in VS Code, you’re actually using the TypeScript service anyway. So this ts trick - it enables full type-checking of all your JavaScript. So it’ll give you some little gentle warnings when it finds something it doesn’t know about. And it’s got this little – I don’t know what they call it… Intentions, I think; that’s what they were called in JetBrains anyway… So you go and you hover over that little squiggly, and it says “This is an any type. Do you want to try to determine the type of this by its usage?” And you say “Yes.” So it goes and looks throughout your code, and it tries to determine what the type is. So when it does that, it actually plops a little doc string in there, and it’s all working with JSDoc.

So TypeScript supports a few JSDoc tags… Pretty much as many as it really needs, which is not too many. So you can use TypeScript types in your JSDoc doc string types. So I started doing this, and I’m like “Wow, this is really neat.” I can get full type-checking just with a few extra doc strings, essentially.

[36:21] Eventually, I went and – there’s a setting called the jsconfig.json file; I’d seen this file before, and I wasn’t sure what it was. This sits in your project root, and it tells the TypeScript language service in VS Code, how to check your JavaScript. So I configured that, and I told it to check all the JavaScript files, and so that’s what it did. It goes through all my source files and finds all the places where the JSDoc doc strings don’t match, it finds all the places where it can’t make inferences, and of course it pulls out all these typings from npm and automatically downloads them. All the third-party modules I was using already had some types, so it knew about all those. All I had to do was write a few more types in my doc strings.

So my project that I’m working on - at this point it’s pretty much fully typed, using doc strings and Typescript, but it’s not TypeScript at all; there’s no TypeScript whatsoever, and it’s fully type-checked. I’m like “Wow, that’s kind of amazing.

In fact, it’s like “What’s the point of TypeScript anymore if the language server can actually type-check all your JavaScript for you?” And if you have these definition files, you have doc strings, there’s really no need for all that extra syntax. And at least from my point of view, that’s a huge win, because I don’t really wanna get hung up on the extra syntax of TypeScript. Certainly there’s a few things that you probably cannot do, but I have not run into those yet.

This is like many, many source files. It’s a relatively large project for a single person to have been working on… But everything is type-checked, and it’s just doc strings - if you follow their guide, you can create type definitions. Like in TypeScript you would make an interface to do this sort of thing, or a type alias, in JavaScript what you do is you use a JSDoc @typedef. That’s @typedef, and then you can define what the base type is, and define all the properties of a particular type… And I just made it work with @typedef, to define my interfaces, and it’s great. It’s awesome.

As long as I’m talking about it, shout-out to Daniel from the TypeScript team, who helped me get some of this stuff working a little more quickly. I was running into performance issues because I essentially had a misconfiguration in this monorepo that I had. He helped me get that set up, and now it works just splendidly. I totally recommend – if you’re writing doc strings, if you’re using JSDoc and you’re using VS Code, take a look at writing JavaScript in VS Code, and it’ll show you how to set up all your TypeScript settings and get all that type inference just as you would in TypeScript. It’s great. That’s my big pro tip.

Yeah, it speaks the param, it speaks the types in return values, it supports TypeScript syntax, it seems to support the Closure Compiler syntax too, for defining types… So it’s pretty loosey-goosey with how you wanna write your docs strings… But the inference works great. All you’ve gotta do is really fill in some holes, and if you’re passing objects around, you need to describe the shape of those objects, and that’s basically it. That was the main thing that I needed to do.

Otherwise, if you have a class, an ES6-style class, it understands everything about that class, it understands all the methods, the static methods, it knows when you say this.foo is bar - it knows that foo is a property of an instance of whatever class you have… And the inference is awesome. I didn’t have to go through everything and define every return type, because it knew. So yeah, I’ve gotten a long way with it, and I highly recommend it.

Cool. I will pick up for the next one… My set of pro tips is related to talking to users or stakeholders. I think most engineers have now heard it’s important to talk to your users, and whether or not you have internalized it or not, it is important to talk to your users to understand how they’re using and what they need… But one of the trickiest things, particularly for engineers, is to understand that users are really bad at telling you what they need and what they want. And they’re bad in kind of a particular way.

They will come to you and they’ll say something like “I think this project/thing needs to do X, Y, Z”, and they’ll tell you what is essentially a solution. “I want this thing.” But users are really bad at solutions; this solution will usually be half-baked, it’ll be really weird, and if you actually build it the way they say it, they’ll try it and it won’t work, and it won’t do what they want. And I’m saying users, but stakeholders or clients are often the same way. They’ll say “I want this” - they’ll describe a thing, you build the thing, then they try it and they don’t like it.

But where users and stakeholders, and people - this is a human thing, we’re very bad at imagining the future in general, but what we’re really good at is describing what our problems are. So when somebody comes to you - if you’re talking to a user - and they say “I think you need X, Y, Z”, your job as an engineer or a project manager, whatever your role is in the situation, is to try to uncover what is the underlying problem.

Sometimes it’s as simple as saying, “Okay, what’s the problem you’re trying to solve with that? Can you show it to me? Can you tell me more about it?” Sometimes you need to dig a little bit more. An extremely useful question I’ve found is you say “What’s the most challenging or frustrating thing about X?” If they’ve put a solution in front of you, say “Okay, with that, what’s the most frustrating thing that you’re trying to solve with that?” And use that to kind of uncover the problem, which - if you have a really good problem and a really good understanding of the underlying problem, coming up with a solution… You can try a bunch of different solutions; you can explore the solution space and figure out something that will actually solve that problem very well. But if you stay at the level of “The thing that the user told me…” or “The thing that my client told me…”, you’re gonna end up with a really half-baked solution.

[44:18] So my pro tip is talk to your users, talk to your clients, but use the things they tell you to try to understand their underlying problems, not as “This is what they actually want.” And that is my pro tip. Divya, how about you? What have you got?

If you’re a freelancer, you absolutely have to have that communication with your client.

We had a mini-discussion on a different episode about Git histories, and whether to squash or not squash, and we quickly derailed, because we could see – I mean, this could be a debate episode entirely, so…

It reminds me of metaprogramming, in the sense that if feels really cool and slick, and it makes things so clean and nice and beautiful, and as you hang yourself with it or shoot yourself in the foot with it a time or two, you start to value more and more the beauty of explicitness.

Awesome. I think that makes for a great set of pro tips - communication, and communication with yourself, with Git…

Alright, let’s call that a segment and we will be back shortly with segment three, where we’re gonna do some shout-outs to our favorite people and things happening in the community. Catch you on the other side.

Welcome back, JS Party people! Let’s talk about people and things that are awesome in the community. Chris, why don’t you give us your shout-outs first?

So there was an experimental feature added to Node recently, proposed by Jan Krems, and Guy Bedford actually landed the PR… It’s the Package Exports proposal. What this thing is is it’s a new field in package.json, and it lets libraries specifically essentially create aliases of – so the best way is probably just to use an example.

If you’ve ever used something with a very large API surface - Lodash comes to mind, RxJS, sometimes they don’t want to just export the whole API from the root module. So you don’t say “give me foo, bar and bazz” from RxJS. If you want the operators, you reach into rxjs/operators. The same with Lodash, lodash/fp is a sub-path of Lodash.

Essentially, when you’re doing that, when you use the sub-path, it’s exposing implementation details… Because in order for that to work, so in order for Lodash/fp to work, one of two things has to be true. One, there needs to be an fp.js in the root of the Lodash module, and it must be published as such.

[56:23] The other thing is there may be an fp directory, and in that directory is an index.js, and it has to be published that way. So what Package Exports does is it allows a module author to declare “Okay, these are the–” I think they call them sub-paths. So these sub-paths point to these files.

So you could say something like, okay, if somebody requires mymodule/foo, that requirement will map to this other path somewhere in my source files. So you don’t have to expose the directory structure - which is an implementation detail - in order to provide those sub-paths and allow your consumers to reach in to some other place in your module and pull things out.

Right now it’s experimental, but it’s a really great idea. People will kind of rail against aliases; I’ve seen this before, where they don’t like the idea of – well, it makes code hard to find, essentially. This is for libraries, so if you need to reach into a third-party library and it’s got this export path in there, I can see where it might be difficult to actually find the source, but I’m sure tools will adapt to this.

Right now it’s experimental, and you can probably just go ahead and play with it, but because it’s experimental, it’s behind a flag and you can’t really start publishing your things and expect it to work, because it’s not gonna work for everybody yet.

Anyway, really great idea. Thank you Jan and Guy for the Package Exports proposal.

Sweet. Thanks, Chris. Divya, do you wanna go next?

[01:00:08.06] Yeah, I hope next time Nick is on we get a little bit of a debrief. I guess Jerod was there too, they’re both organizers. So next time we have Nick and Jerod on the show, they can get a debrief on NEJS.

Awesome. Alright, final set of shout-outs - I wanna do a couple shout-outs to people in the community who are doing a ton of work to make the tech industry more welcoming and accessible to people, and particularly to women. We have a long history of having an industry that’s very dominated by men. There’s been a big push recently – I can tell when I go to a conference if they’ve paid attention or not, because there are more and more conferences that really make a big deal out of gender equality, and having not just men and women, but all genders feel welcome, dealing with simple things like “What are your preferred pronouns on your tag?”, things like that. All sorts of stuff around that.

There’s people really putting a lot of time and energy and investment into making this industry more welcoming to people who are not just white men, and I wanna shout out a couple. The first one I wanna shout out is the new Ladybug Podcast, that actually one of our panelists, Emma Wedekind, is doing along with Kelly Vaughn, Ali Spittel, and Lindsey Kopacz. I probably butchered all of your names, I apologize… Though I hope I got Emma’s right, because I asked her how to pronounce it once.

So that’s one thing, check it out - The Ladybug Podcast. They’re talking about all sorts of stuff in the tech industry; they’re talking about things that are not just stuff that women run into, but it is also doing some things about particular challenges that I think women sometimes get hit by a little bit more… But more than that, they’re just talking about the tech industry from women’s perspective, which is something that we need a lot of… Because as much progress as we’ve made, there’s a lot of white dudes like me out here.

The other person I wanna call out who’s doing some great work in that space is Tracy Lee (@ladyleet). She’s the CEO of This Dot Labs, but she’s done some really interesting things in terms of curating women in tech to help improve their visibility. So if you are like me and love the Twitters, and you wanna find some amazing women in tech who are doing awesome things, go check out ladyleet’s Fempire list. There’s just a lot of really cool people.

I’m focusing on women in tech right now, but broadly I wanna advocate for expanding of sets of people that you follow to people who have different perspectives and different backgrounds. If you are a white woman, find some black man to follow; if you’re a white dude like me, find some women, find some folks who are of different backgrounds - Latin American, African American, and folks from outside the country.

When I was traveling recently I discovered I was overseas, timezone-wise I was off by like nine hours, and I discovered “Holy smokes, my feed is extremely U.S.-centric.” I don’t have those perspectives of people who are even similar to me, but in different countries in Europe, and people who have very different backgrounds… So I highly recommend looking for, seeking out people with perspectives different from yours to follow.

Yeah, those are my quick shout-outs. With that, I think we are done with this episode. Thank you for joining us for our experiment with the framework wars, for our pro tips, and now closing with shout-outs. Do send us some feedback on what you thought of the framework wars segment, and we’ll catch you next week.