I'm so excited that Jessica have come and come and speak here today, traveling all the way across the country from New York, even though she did, you know, he used to reside here back in the day when Jessica worked.

Get hub you.

Chances are, you've you've used some application that Jessica's sticky fingers were involved in making.

Along the way.

Jessica let let the electron team will start the electron team, get help.

And so, you know, if you've bean working on anything that's had been built as a desktop application that uses JavaScript takes him Elsie, assess all of those good things packaged up and used on the desktop app.

There are lots of them around way going toe.

We're going to lunch.

Okay.

Thanks for your talk.

Yes, you may well have encountered Jessica's work already.

Also just now works the New Yorker.

Comfortable displace hoo d'oh!

Kind of tooling on resources for musicians heard it described as get hub for musicians.

So the mind kind of boggles there.

I've seen Jessica talk a bunch of times before and always really enjoyed her take on like culture on the way teams work together on.

So I'm very, very excited to be also welcome here.

Thio Jam stack conference peacemaker.

Very, very welcome, Jessica Lord.

Thank you.

Thank you so much, Phil.

Um, yeah, Thank you.

That's well said.

My name is Jessica Lord.

I work at, um, a company called Spice in New York City.

I work on the back end and a bunch of very not jammy stuff at all.

And but I'm so I'm not talking about any of that today.

Today I'm gonna share some stories about very jammy things I worked on When I get Hub and I code for America and get hope is a code sharing site, Um, and code for America, if you don't know, is a nonprofit based here in San Francisco for writing open source software for city governments that city governments can use and be better at governing.

Um, but first I want to go into the statement and and really, why?

I'm thrilled to be here and a part of the damn satcom and really loved this area of the web the most, and excites me is because I really, truly believe that everyone is a developer that everyone could be a developer, that everyone might be a developer.

They might be on their way.

They will be a developer soon, or they actually already our developer.

But they're afraid to call themselves that.

Our profession is really special that way.

For those of us who do this professionally, it's it's different that we actually have people not doing it professionally, doing the stuff that we do professionally, that's different.

It's not like rocket science or heart surgery, and I don't mean in terms of complexity, right, because that's not to say that the work we do is an important revolutionary.

Remarkable.

It is, um, and that's what's really exciting for me about it.

And it's not to say that there aren't really brilliant people doing amazing things, But you don't need to be on the bleeding edge fringe of Web development to make something meaningful and empowering.

And there aren't heart surgery hobbyists.

There actually might be, and it's definitely illegal, Um, but it's it's one of these ways in which our profession is different than other people's, and I might really regret this metaphor later.

So we'll see.

Um, because unlike heart surgery, the Web is bigger than what we do professionally.

And unlike heart surgery, the Web is better when it's approachable, firm or people.

Um, the work we do every day is also done by tinkerers by activists by people on their weekends, by people teaching themselves by community leaders.

All these people who aren't considering themselves a professional developer, they're still using the tools that we have built and contributed and are using.

But I think it's important that when we build the tools we do and create the environments we do for Web development, we think about these tools in the context not just of other developers exactly like us, but for people, not developers.

But aren't developers people?

Yes, but they're a subset of people who could, would and should be developing.

And so for me and why I love the jam stack.

And a lot of the work I do is because I want to build things, is that there's more people building things, and I think it inflates everyone.

It is better experience on the Web when more people can use the Web.

There's this quote I love from a Neil Dash who is the CEO of glitch formally fought Creek.

But now, fully and on glitch, it seems more important than ever to encourage a diverse community of creators to experiment with their broadest set of ideas.

I think that's so true, and to me it's really important because coding is a powerful literacy and and it's not just the the broadest people out there who might be developers or who aren't developers.

But I mean, it's also the people you work with, because you probably worked with people who aren't developers or people who haven't been developers their whole lives or people who are developers but came from a totally different stack than what you're working on now.

And so I think it's really important that we don't think of a professional developer as the only kind of developer and that everyone can benefit from building things on the Web because html, CMS and JavaScript, they still work.

And, like Monica, showed us browsers do amazing things like we have these tools already, and it kind of doesn't need to be more complex than that.

So where is my screen?

I I have this kind of scale of Web things where if you imagine the two extremes off a single page site and then a really big Web app.

I think we focus on this far end, and we make it seem like this is Web development.

This is where you need to be to be putting stuff online, and it's just not true.

There's all this spot in space in the middle, and I've actually used this diagram before.

But now it's really clear to me that this is the jam spot, um, of things.

And so this is the area full of things you can do that don't have to be super complex.

And I want there to be more activity here because sometimes our projects make it out into the world and other people interface with them and those other people need less overhead.

And then sometimes a project doesn't.

It stays internal, but your teammates need less overhead, too.

Um, so all right.

The first part is it's the story of making an electron a thing.

Electron is, ah, library that get home maintains that is, for building desktop Paps that work on Mac Windows and Lennox using Web technology.

But it used to be called Adam Shell, and it was a dependency in Adam, which is get hubs text editor And it lived there and get home didn't want to do anything with it.

There was no vision for it.

There was no plan.

And I had been a good husband recently had moved on to the Adam team.

And as I dove deeper into the Adam Code and on board it and learned that all the thing making everything happened was this thing called Adam Shell, I started to think it was actually more game changing than Adam itself.

I think Adam is a great Tex other, Um, but Adam Shell felt really game changing to me, and so I started to fight for it.

Um, and you might be surprised that there was pushback because there was really no vision for this to ever be anything like Adam was the dream.

And there was just like, No, there was no plan for this.

And I kept pushing and I wrote up road plans and reasons why it should be its own thing.

And I finally, as the first step, got the okay to spend my full time working on electron stuff and the stuff that I had put on my road map.

And so Adam Cell, the core library that is now electron, was built and maintained by a guy named Chang.

And so he still worked on the core library.

And then I worked on all this other stuff had put on my road map as a sort of, like proved to get Hub.

That electron could be a thing that was worthy in stand on its own.

And the first thing I started with was documentation.

I wanted there to be one source of truth, and likely there was already pretty good documentation in the electron project.

But I didn't wanna overcomplicate that.

I want there to be one source of truth for documentation.

I wanted to standardize it with style Guide because it needed standardizing.

Um, and I want to make the most of Mark down and CSS and HTML.

I've been on projects that have, like Adam, where documentation is this whole other thing.

It lives in another rebo.

It's dependent on ah whole other tool chain for documentation and a whole other template ing library, and there's a whole other hurdle in tow on boarding just to fix the documentation.

And I wanted to make the most of what exists now, which I felt word's good enough.

Um And then, of course, a static site generator.

Um, I was like, get hub.

So I used Jekyll and what I ended up doing.

Waas The electron documentation lives inside of electron, the repo.

And so whenever you download electron, you get a copy of the documentation.

It's all marked down.

And so I want to start from there.

That is the one source of truth.

All changes to documentation happen there and then So I never learned.

Ruby, I get hub.

So I put a bunch of notes scripts into my Jekyll site that basically took the tar file from an electron release, would stream out the docks folder, read the file path, read the content of it which had now been standardized, so was predictable, and then generate the front matter and all the things that Jekyll needed so that it could then take all of those things, stream them out of the repo and then put them nicely into ah Jekyll site in the way that Jekyll wants them.

And so, yeah, like I mentioned, the style guide was really important.

So that the format of the documentation could be predictable so that incoming changes could maintain the same the same format and also because of wanting to make the most of CSS.

Knowing that I was going to be putting it on this jackal site and I would have the benefit of CSS so it could make the ledge ability of the documentation a little bit better than just reading the mark down files.

And so the style of all the documentation had to be really thought through and predictable and so on the documentation on the site.

There's also a few things that are a little bit electron specific, but because it's pulling the docks from the releases of Electron, we get tohave version documentation on the site.

And then there is a T L D R line on all of the pages because I feel like documentation.

Often times you go to the page, you have to read through two long paragraphs to even figure out if you're on the right page or not.

So I want people tohave right at the start, a place to go and no if there in the wrong place or not, um, and then electron blurs the lines between what's front and what's back end and then introduces new complexity with having two processes.

And so there's a main process and a render process.

And so each of the documentation tells what process it belongs to.

And then because when we're on the site and we have the power of CSS to improve readability, weaken, do things like make it more clear when a method or an event is something that only happens on a Mac system or a window system.

But it's really important to do this without forsaking the original mark down, because I didn't want to do something so that it looked good on the site but then was horrible to Rita's mark down.

Because the mark down is the source of truth.

And it's what ships with every download of electron and so everything that had to be done, like pushing the limits of marked down and thinking about how I'm going Thio style this in CSS.

But have it not look terrible in the marked down and so that was the bulk of the documentation.

The next thing I worked on Waas what was going to be people's first electron app and there are some other people at work.

Well, like, of course, we'll do an electron in it and it should be a scaffolding system.

And I pushed back on that.

Um, first of all, electron APS can be anything they can be a menu bar app that does one tiny thing with a window this big that I mean that tells you the time or the weather.

It can also be slack.

So there's a huge gulf in the kind of electron APs you can build, not to mention.

You can pick your flavor of front and framework in all of this stuff.

And so I felt like that's a huge undertaking to build a scaffolding tool that's going to support all these per me ations of a new electron app.

And even if it doesn't support all of them, then who are we to say, like, Well, we think you should use react.

We don't, and if you have a tiny menu, bar applicant don't need any framework at all.

And so I went with the keep it simple approach, and you clone it.

It's a bare bones electron app with an almost empty starting window you clone the repo, you in p m install you in P m start and you get an almost blank electron app.

You can open up the depth tools and you can start to poke around in it and you can especially.

I wanted to think about people who weren't coming from the desktop app space because people who are already in the space who are maybe working at a startup that used, like, chromium embedded framework and things like this they already got it.

So I don't care about them.

Like I care about the people who were front and developers or people who I didn't think that they could ever build a desktop app.

I wanted people to know that an electron, its HTML you can open it up.

You can use the crone Dev tools like you're used to and start doing the things that you already know how to do.

And so, with this little easy to clone and launch app you like very instantly, almost instantly nothing.

It's not that instant.

You can start digging around and changing an electron up, but I wanted to go beyond that because it still was really hard to get across to people.

What is electron?

Why would I use it?

What are the kind of things that I could do with it?

And so the next thing I did was build an electron app that demos the electron ap.

I, um and I think it worked up really great.

It was actually a really good tool for this, um, so that you can you can download this app and you can go through it and you can view the demos of the different kind of common things that you would do interfacing with the different, um, desktop system.

You eyes and demo things like opening a new window and so that it makes really clear, Like what this stuff means.

What was the dialogue?

If you're not coming from the does have application world like what?