Ep. #44, The Developer Experience with Divya Sasidharan of Netlify

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line I've got Divya. Divya, actually, I don't even know your last name. I failed to actually grab that.

Divya Sasidharan: It's Sasidharan.

Brian: I know you as @shortdiv on Twitter.

Divya: Yes.

Brian: Excellent. Having you come on because you're a developer advocate at Netlify, and we're going to talk about that and maybe talk about your work in Vue as well.

Go ahead and introduce yourself to the audience and tell us why you're here.

Divya: My name is Divya. I work on the DevRel team at Netlify.

We're calling it "Developer experience" now because it's pretty encompassing past just conference talks and blog posts and so on, because we're starting to focus on the actual developer experience of how people use Netlify.

Integrations with the CLI, I think we're working on other things that other platforms that people can use Netlify on, and various things like that.

The idea is just to encourage and try to reach developers where they're at and try to make the experience of using Netlify as great as possible.

Brian: OK. Yeah. I don't know how many other companies are taking this model in "Developer experience," as opposed to "Developer relations" or "Evangelism."

Sounds like they're all in the same bucket. But I saw something very recently on Twitter where you're rotating as engineer on the team as well, is that true?

Divya: It is. This is a new thing that we're doing at Netlify, because the idea is that a lot of the times as DevRel, you are an engineer, but there's always this distance.

You're distanced from the product because you're very external-focusing, not to say that you're not technical, it's just that you're focused on the community and how other developers are using the product.

You're not working as much internally with the team. There's always this disconnect that happens, so we talked a lot about that and how we as developer advocates and DevRel people can also work internally with the team and try to foster that connection.

Because it's really important to do both to be effective in the role. One of the solutions we came up with was doing a rotation.

It's three months, you get to join the team, you're essentially working just side to side with the product team on their sprints, working on picking up issues, various things like that.

It's basically you're switching teams for that three months, and the idea is to foster that connection to the rest of the team as well as to sharpen your skills.

Because when you're in the role of DevRel, a lot of times you're working fairly independently, which means that in terms of code review you don't get that as much. You don't get that peer feedback, which is really valuable for if you want to improve your skills and maintain that team dynamic that is really important to being a developer.

This rotation helps address all of these concerns that we've had, and this is something that Sara Dresner--

She joined the team in May, and this is an idea that she had because she'd noticed that at Microsoft, where she was working with the developer advocates there, that disconnect.

She wanted to bring an initiative that could actually foster that connection that we so crave.

Brian: Yeah. I like that idea too, because my day job is DevRel as well. Though I do a bit of coding at my job, at GitHub we have a very unique developer relations program.

It is very true that I don't get peer review on anything. Any of the stuff that I work on, no peer review. Most of the projects I work on are one-off example applications that don't really need testing.

I do try to emphasize testing and continuous delivery as part of the stuff I touch, but it's actually not a necessity.

As long as I can talk on stage or do a workshop on something, that's about it.

I'm curious as far as developer experience and your expertise, is there a corner of the product that you're focusing on or is it this general like "You pick up some bugs" or "You pick up a feature" that's on the outskirts?

Divya: Yes. We have different teams within Netlify. The product team is composed of various smaller pieces. There's the front end team, there's the back end services team, there's the API team, and then there's also the CLI team.

When you move and do these rotations, you essentially can pick the team that you want to work with and generally try to match the skill set that you already have.

A lot of the people on DevRel tend to be front end developers, so I'm on the front end team at the moment.

I could also be on the CLI team if I choose to, but I chose to be on the front end team just because I wanted to do that for a while.

I know a lot of the folks who are on that team and I wanted to have fostered that connection and worked with them directly.

But essentially, you get to pick, and you should pick because then you get some direction. Because otherwise if it's haphazard, the point of a rotation is lost.

The idea is "You join the team, you're pretty much a part of the team, you're in stand ups and you're in retros and sprint planning, everything like that."

So that you can understand how exactly the product cycle works within Netlify.

Brian: Cool. I'm curious, you mentioned your drawing towards front end. I'm curious to hear more about your background, and how you got connected to Netlify.

From my understanding you came through the Vue community. Is that correct?

Divya: I did. I was working a lot with Vue and I'd recently-- A couple of years ago I switched from React, so I gave a talk at Vue Con about a year ago. It feels longer.

Brian: Time is a construct.

Divya: I know. I gave a talk about moving from React to Vue and a lot of the concepts that carryover between the two.

Matthias was there, he's the co-founder of Netlify, and so was Phil Hawksworth who is on the DevRel team.

I met with them while I was at the conference and they were like, "We currently have a DevRel team of one person," because at the time it's just Phil. I think you had just left at that point.

Brian: Yeah.

Divya: They were trying to grow the team, so they basically said "Would you like to go and join the team? Or can we talk more about this?"

We had a conversation and we tried to see if this would be a good fit, and it was. I love Netlify.

I was like, "This is great." I would love to be part of a team of a product that I love a lot, that's such a great opportunity. That's how I started being a part of Netlify.

Brian: Now you're on the team. Have you indoctrinated the rest of the team on going towards Vue, or are you leveraging Sarah?

Divya: It's a slow--

Brian: You also hired the GitLab guy as well.

Divya: Yeah, Jacob Schatz. It's a slow roll. Netlify's product is built in React and it's a decision that was made before my time.

A lot of the product and a lot of the developers at Netlify use React, and I think I was one of the first few people--

Probably the only person at Netlify who used Vue when I joined. Then I got a couple of people in the product to be interested in using Vue.

Then from there, conversations started about moving the dock site to Vue, which is-- It's a slow roll.

Then Sarah Dresner joined, who's a part of the core team, and she talks about Vue a lot and does a lot of the demos when she gives talks using Knox and Vue-CLI.

Then Jacob Schatz, who was at GitLab, is also a huge part in the Vue community. There's this is this growing trend, which is really nice, of people at Netlify who use Vue.

In terms of whether Netlify will move to adopting Vue totally, I'm not quite certain what that would look like. Because that's going to be hard.

I know that Netlify itself, the product moved from Angular a couple of years ago to React, so I feel like moving to Vue would be a huge step and a lot of work that might not be--

They're both great frameworks. They do the same thing. If there's really no reason to move besides developer ergonomics, then why?

Brian: Yeah, that's actually why I was-- When I was hired at Netlify I brought the last leg of that conversion from Angular to React.

I'd spent years touching a lot of back end stuff and switched over to front end my previous job before Netlify.

And I was exploring React, and then came through because of my experience from Angular and React to convert the rest of the product, or the actual dashboard itself.

It's a huge undertaking, but it's also because the way Netlify is set up literally built on the JAMstack, to have Vue 3 or Vue 4 or whatever they're going to call it for Netlify, the actual product itself.

To have a parallel or A/B test of Vue, it's funny how trivial it actually becomes at that point. Where "Yes. You're going to have to rewrite a lot of components."

My experience was when Netlify was way smaller, so it wasn't as much to convert. It's a much bigger lift.

But if someone took a weekend or their Fridays, or maybe a couple months to rewrite some of those components in Vue, it's interesting how you can approach that nowadays if that were to happen at Netlify.

Divya: Completely, yeah.

Brian: So, you're closest to Vue. I'm curious, I know Evan recently had a couple of tweets around the new version of Vue.

Community backlash around that, maybe some community love around it. I saw more of the negative than the positive.

What's your take on the future outlook of Vue and the future versions?

Divya: Yeah. Vue 3 has been an ongoing conversation for a while. The community was aware that Vue 3 was going to come, we just didn't know when.

That was a process that's been ongoing. At Vue Con this year Evan talked about Vue 3, he talked about Vue 3 last year at Vue London and Vue Toronto.

It's been happening for a while, and they've been doing an RFC process, which is very similar to how React and various other frameworks do it, where they talk about specific APIs that will change and how they will change with specific examples.

There were a couple of RFCs out, mainly the reactivity API was the big one, because Vue was from a high level perspective moving from using getters and setters to proxies.

So the way that Reactivity works would change, because there were certain caveats to using getters and setters that will be fixed in Vue 3, which is really good.

Brian: When you say "Proxies," are you talking about observables? Is that the same construct?

Divya: Yeah, it's the same idea. Observables and proxies, yeah. That conversation about Reactivity, everyone knew that change was happening but there were also conversations within the core team that were happening about how they wanted to expose that Reactivity.

There was this idea that was bouncing around called Vue Hooks, and hooks was this idea of emulating what React was doing with hooks, which is encapsulating logic.

You don't have to have a component instance, you can have Reactivity and everything isolated. You can use that without having to have a component instance, essentially.

Lifecycle hooks, whatever, but without a component. The thing with that is that was an older API.

That was last year, Sarah Dresner wrote an article about hooks, which was really popular. People were like, "This is happening. Vue is starting to be like React."

So that was a conversation that was happening, but what we were talking about just in terms of the controversy is that Vue released a new RFC, which basically consolidated a lot of the previous RFCs.

And they called it "The function's API or whatever. And in the function's API, they were going to change the way that people would interact with Vue or write Vue.

The syntax of Vue is going to change slightly, and then along with that there was also this idea of having separate builds. That was pretty much the crux of the debate, because if you looked at the adoption strategy section, it's not there anymore because it's been changed since.

They talked about a compatibility build and a standard build. The idea is that generally we are moving towards not supporting the 2.x. Everyone would--

The compatibility build would support 2.x, so all the older features of the older API and syntax, and then the standard build would not.

That caused a huge furor online. Because that indicated to everyone that Vue was deprecating everything moving forward.

So yes, Vue 3 would still have the compatibility for all the syntax, but there's a likelihood that Vue 4 will not.

Brian: OK.

Divya: That was the huge fear in the community. In a nutshell, that's what happened. Then Hacker News and Reddit just went insane.

Brian: Yeah. Is that really the case? That Vue 3 is going to be the transitional version, and then Vue 4 is going to have extremely breaking changes? Is that where we're still heading towards?

Divya: That has been reversed since then. That was basically what that RFC was, and then it's been reversed since.

There's been a promise made to the community in the new update at RFC that 3 and 4 will not be breaking changes, which I think also is--

There's many interpretations of this, because I think that making promises to the community will bite you in the future when you're like, "I want to make this change. But wait, I already promised the community I wouldn't."

So you can't make that backstop any more. Vue is in this conundrum where they like, "They promised that they won't change anything, so Vue 3 and 4 and maybe 5 cannot have breaking changes.

Which is difficult for them, maybe it might be difficult, but there won't be any breaking changes. But essentially what's happening now is that there is going to be two ways of doing things.

There's the functions API, and it is still the functions API. They're trying to call it the compositional functions API to make it a bit clearer. I don't know, it's very verbose. But they don't--

Brian: Naming is hard.

Divya: Yeah. They don't want to call it "Hooks" because they don't think it's clear enough. Because Hooks has--

In programming, there's a reference to hooking into a lifecycle hook or events or whatever, which is not what a hook actually is.

Compositional functions is the idea of composing functions together. But it's a mouthful, so in terms of marketing speak, not too great.

But it is a paradigm shift because the idea is that you are still creating your single file components, you have all of the logic and component instances, but the idea is that you're taking away any reusable logic.

I think they use Mouse, which is a really common one where it's like you're handling where the X and Y coordinates of a mouse. React uses it, Vue uses it a lot.

Example, when you're hovering over something and I want to grab the X and Y coordinate for whatever reason, the logic for grabbing that X/Y coordinate can be extrapolated into-- In React, they

extrapolate it into hooks. In Vue, they extrapolate it into-- They call it a "Compositional function."

That's essentially the role of a compositional function, to take reusable logic so you can use it elsewhere.

Brian: Is there plans to have a migration path? I guess that's what I'm getting at.

Divya: Yeah.

Brian: I recently upgraded a project that was on Webpack 1, all the way up to Webpack 4. 4.38 I think, specifically.

It happened to be a project that I cared about, but for time reasons I never had the bandwidth to go and update it and add new features.

I had found the bandwidth a couple weeks ago, and then the upgrade process was pretty challenging to be quite honest.

But once I got out of 1.0 and got to 2.0, that's when the Webpack CLI really started kicking in and I was able to upgrade and leverage some error-driven development and have some continuous delivery.

My project was on Netlify, so if the build succeeded and it was on-- I could see it on Netlify that I knew I had did something right.

Mainly because I didn't have a lot of tests, my tests were very simplistic.

There was a lot of edge cases I wasn't covering, but the fact that I could tinker with it in the staging environment made it very easy.

So I'm curious if Vue is going to have the migration path, or is it even necessary now that they've backtracked off the RFC process?

Divya: Vue generally, looking at the past processes of Vue 1 to 2, has had a really good migration strategy.

They had docs cover in very painful detail, but it's a good thing. They go in detail on how exactly to migrate and how exactly the change from one version to another will look like.

There's a lot of side by side comparisons, and even though there's a lot of negative sentiment towards the RFC, the RFC does show that.

So it does show "This is what you would do in Vue 2, and this is what you do in Vue 3.

There's that side by side comparison, which I think is really useful for a developer to understand and tease apart how exactly the paradigm shifts between two versions.

But there's also this idea of how exactly to make that migration as seamless as possible, and I think the decision to make that build compatible through future versions is also taking that into consideration.

Because future versions of Vue will still support older versions, which means that if you were to use lifecycle hooks in 2.x and if 3.x changed the naming of lifecycle hooks or whatever, it would still work in both instances.

Which is nice, because then you can leverage future versions without having to upgrade all of your applications, or you wouldn't have two versions of Vue running like 2 and 3, because they're not all-encompassing or backwards compatible.

In terms of that, I think that's something that they're really cognizant of.

Just making that migration path as seamless as possible, because the moment you make a radical change, let's say if you're just completely deprecating something like Python did with 2 to 3, then it becomes a huge pain point for developers.

Which could potentially move them off of using that platform or that framework altogether, which I think in the case of Python, you wouldn't really have that because people are like, "What else am I going to use? I have to learn a whole new programming language?"

But with Vue that can happen, because there are so many frameworks to choose from, and so the moment you are like "We're going to change the API, it's going to be really painful to migrate."

Then people will be like, "Then why don't I just move frameworks completely? Because it might as well be completely different."

I think that's something that the core team in Vue is very aware of, that they want to make sure that people moving from one to another don't feel like they have this completely impossible task of having to migrate, and that they have to do it all at once.

They can do it in pieces.

Brian: I was going to mention this as one of my picks, but in the context of our conversation right now I'm going to mention it now.

I'm curious, have you heard of the product Dependabot? Or a product similar?

Divya: Yes, I have.

Brian: There's the idea of dependency management is it's a problem.

I literally just had an entire hour-long conversation around the Rails app that we have at GitHub that wasn't touched for six months, and there's vulnerabilities and there are problems in upgrading.

So things like Dependabot, what they do is they basically take your repo and it looks for either your package JSON or your Ruby gems file and looks for any vulnerabilities or also any new dependencies.

If there was a hot fix or a simpler version, it opens up the PR and then within the PR it tells you exactly what changed as far as the change logs as well.

So it's pretty nice, but it's making the idea of migration to the newest version or migration to whatever, if you happen to be asleep at the wheel or really in the feature development and not really your project, it gives you the opportunity for it.

I love it because I just explained I went from Webpack 1 to Webpack 4 on a single project, based on using Dependabot. Literally, that's

all I did. It's helped me also revive my personal blog, which wasn't building locally for the longest time.

For whatever reason it worked on Netlify, but locally this was not working. Turned out to be a bundler issue, because it's a middle-man blog.

It's using Ruby Gems and Bundler, but I didn't know that and I don't have time to really look through why my blog was failing.

I was just using Netlify CMS to push my new changes on my new blog at work and then in production, so I just kept going that route. But because I updated old versions and security vulnerabilities, I was able to fix my local build by just doing that process.

I'm curious what your thoughts are in future development?

Because you worked for a continuous delivery and potentially a CI company, that as long as your changes work and are deployed on Netlify, so does that continuous delivery aspect.

So for future development purposes and engineering, what are your thoughts on dependency management and some of these tools?

Dependabot is one of them, I forget the names of the other ones that are out there, but there's countless numbers of dependency management tools.

Divya: Yeah, definitely. I think Dependabot is actually one of the ones that we use a lot.

Because for instance, we released Netlify Dev recently and we were trying to manage NPM versions and various things like that.

Dependabot has been the one that's notifying us of certain changes versioning that's happening within the project itself. It is annoying because it messes with your commit history slightly.

You're like, "La la la" and then Dependabot is committing. Or you see those messages from Dependabot, so it's not as clean a history if that's something that you care about.

But it is really nice for that ability of making sure that everything is in working order without you having to feel like the task of upgrading is so huge and impossible to accomplish.

Brian: Is it someone's role on the team to merge those Dependabot PRs? Or is it part of your regular engineering cycle to upgrade the version of Vue or the CLI of something?

Divya: Yeah, I believe currently it's part of an individual task.

With Netlify Dev we don't have a dedicated team to it at the moment, we're currently hiring CLI engineers and we're trying to make that a bit more clear-cut in terms of what exactly gets worked on there.

Netlify Dev is pretty much developers just picking tasks, and we're trying to work on it so the DevRel team works on it and then within the team as well.

Brian: Is it open source as well?

Divya: It's open source, yes. There's open issues and various things like that.

There's a lot of wrangling that happens within that project, so maybe not the best example here, but because of the fact that it's open source and because of how unique that project is.

But in general, with dependencies within Netlify it's not an ad-hoc process.

There is a sense of a decision on how exactly to manage dependencies if that version upgrade needs to happen.

That ends up in the sprint, and then someone works on it, and because we ultimately don't want to break things.

If you move NPM versions we don't want a project that has been deployed on Netlify that's on an older version of NPM to suddenly break.

So that's a bit more carefully done, versus an open source project which is a bit more ad-hoc at the moment, until we can figure out a better process for that.

Brian: Cool. Before we transition to picks, this was a great conversation. I wanted to actually get your take on Netlify Analytics as well.

I know it was a recent ship the last few weeks. Can you give the, what's the elevator pitch on that feature as well?

Divya: Yeah. Netlify Analytics is something that we introduced recently.

Matt introduced it at JAMstack Con London, and it's this ability to show Netlify sites and the analytics or page views, unique visitors, bandwidth, and so on.

Just any analytics that is related to your site within Netlify itself, because we already collect that data.

We are just presenting you the data that we currently have, and the nice thing of that is that you don't have to use external JavaScript to do that.

So if you're using Google Analytics or any other analytic software, you don't have to do that.

Or pixel tracking or cookies, or anything else, to count visitors and figure out unique visitors, bounce rate, et c. and things like that.

We have that information, and so we're providing a way for people who are already on the platform to use that or to see that data really easily.

So out of the box you get the numbers, and then you don't have to worry about your site performance because you're not adding external third party scripts.

I think there's also a fear in general, this happened when we released Analytics. People were like, "Netlify is violating on privacy," which is I think a misconception.

We already have that data, so we're just giving that data back to you. It's not like we're collecting more.

It is GDPR compliant. There's a lot of-- We're making sure that privacy is maintained. We're not sharing your data with any other external parties.

Brian: Am I correct that the assumption since Netlify owns the CDN portion of it, is that where the data is--?

I'm not trying to get into the secret sauce of how this works, but since Netlify itself is a CDN you know who is visiting aside from which location.

Divya: Exactly. Because that data comes directly from the server side logic in the edge nodes, so we are-- That data is not parsed by anyone else. It's on our end.

Brian: Yeah. It's pretty novel and it's pretty powerful for Netlify to have the insight to know that this data exists, or that this data is actually trackable and manageable without the extra use of all these other extra tools.

I guess we'll leave it there, and definitely listeners check out Netlify Dev and Netlify Analytics, as well as Netlify itself.

But I do want to transition us to picks, if you don't mind. These are jam picks, things that we're jamming on, things that get you going. It could be music, food, tech related.

I had already jumped into my tech-related pick, which was Dependabot. I was blown away. I've known Dependabot for a while, but I've never worked on--

Similar to yourself, I haven't been on an engineering team as a DevRel person to really leverage something like this to dependency management.

A lot of my projects tend to be short lived, like six months I work on something and then I move on to the next thing because I've got something else to talk about.

But this was great, because I was able to revive my open source project as well as my blog just from going through the motions and finding out what dependencies need to be updated.

So that was my pick, I do have a second pick which is past elitos. Pastelitos are like these pastries, they're almost like croissants but they're--

Honestly, I don't even know if they're fried. But if you happen to go to the Netlify offices in the dog patch, there is a bakery downstairs and they sell--

They're not Monday and Tuesday for some reason, but Wednesday through the weekend they sell guava pastelitos for like $2.25.

But when I first started working there they were less than $2. I'm not sure why, what's the deal and why they're so cheap, but guava paste is super cheap.

You can't tell by my voice, but I have a Cuban background. My grandma and my mom were born in Cuba, so my aunt who basically raised us, raised us like our first five years of our life.

We would spend time at her house and she would make this guava paste on crackers with cream cheese, which is exactly what they have inside of this pastelito.

Just guava and cream cheese, or some cream. I'm not really sure, it's San Francisco so it's got to be some organic goat cream or whatever.

But anyway, what I'm getting at is they're amazing and they sell them all over the place, not just in San Francisco because it's not a San Francisco treat.

That's Rice a Roni, by the way. If you see pastelitos just grab them, if you see a guava water, if you happen to be next to the Netlify office in the daytime, grab one of those too as well.

Divya, if you want to go ahead and share your picks?

Divya: Totally. I have never tried a pastelito before. I've never had it in San Francisco, I've actually had it in Miami.

They have like a really good-- It's like pastelitos de guayaba, which is what you're talking about. They are delicious, very good.

I'm going to go on that same food train first before I go on my programming pick, but there are these pastries called facturas.

They are Argentine pastries, which is because Argentina is influenced by Italian and a lot of European-- They have European influences, so their pastries are very European.

Facturas is basically their version of pastries, and it's very delicious. They're very hard to find, unfortunately, but they have medialunas which are like croissants.

You can get them with custard or sugar or dulce de leche sometimes. Absolutely delicious, unfortunately it's so hard to find. I have found so far in the US two places.

One in Miami, obviously. Then there's another that's in New York near Queens in Elmhurst. That's a place, I think.

So you have to go pretty far out, and then you'll be able to get them. So that's my pick for food. Very delicious and on the same vein as pastelitos.

Then my second pick is because we've been talking a lot about Vue, there was a post that was posted when the RFC and that whole controversy happened called "Vues Darkest Day," which is on Dev 2.

It's a really good overview of what happened, as well as how the RFC will change the way you would write your Vue code.

Or just introducing the RFC in a way that is a bit more palatable, because with RFCs a lot of the time it's very verbose.

People don't read everything, they don't understand what the meaning of all of it is and the implications.

I think that article does a really good job breaking that down, and it's one of the few out there that cover Vue 3 and this particular RFC.

Brian: Cool. Hopefully listeners will check it out. I know Swix, who works at Netlify, lives in Long Island City. Which is Queens-ish, I guess it is Queens.

Next time I see him, I'll have him try to smuggle me some facturas from this random bakery in Elmhurst.

Divya: Yeah.

Brian: So Divya, thanks for chatting about Vue and catching me up on Netlify things. Listeners, keep spreading the jam.