The panelists discuss Quilljs with its' creator, Jason Chen.

Special Guest: Jason Chen.

 

Hey everybody and welcome to episode 134 of the JavaScript Jabber Show. This week on our panel, we have Dave Smith.

Hello, world.

I’m Charles Max Wood from DevChat.TV. And this week we have a special guest, Jason Chen.

Hey, guys.

Do you want to introduce yourself really quickly?

Sure. Jason. I guess I’m on the show because I’m the author of QuillJS which is a new open source library that is basically a rich-text editor with the added benefit of it having an API. So, the hope is that by providing the API that wasn’t available before, you can build a lot. It opens the door to a lot more possibilities of building richer editing applications.

So, by an API do you mean that it’s easy to extend?

Yeah. So, it’s easier to extend and customize. So, if you look at other editors, their API is actually just basically the DOM API. You can see just by looking at it. So, I guess one thing to clarify is other editors do have an API but it’s not an API where you can edit contents of the editor. All you can do is set and the only kind of editing you can do is setting and retrieving the entire HTML.

Oh, interesting.

And then you have to parse it yourself. Or if there are APIs, that it’s just basically the DOM API you can add classes. And you already could do all of these things, so it’s really just syntactic sugar. What Quill allows you to do is you can, if you go to QuillJS.com and open the console, you can, it exposes a global variable to the editor on the page. So, you can try this out really fast where you can just insert text, format text and delete text arbitrarily in the contents of the editor. That’s one example in extending it.

Because when you try to extend an editor, for example Google has in Google Docs there’s this relatively new link editor where it actually helps you come up with the link, provides the search result and as you’re typing in content. So basically, if you wanted to build something like that, you really couldn’t with the other editors because at the end of that you want to apply a format to a small range of text that says, “Make this a link.”

Yeah.

And that’s really not possible with other editors. And that’s something, for example that is possible with Quill.

Cool. So, is that the primary distinguishing feature between this and other editors? Because today I was thinking to myself when I got out of bed, “Man, the world really needs another rich-text editor.” I’m just [inaudible]. [Chuckles]

Yeah, so the API is basically the big distinguisher between this. This is the big thing that it brings to the table that other editors don’t have. It does all the other things that you need it to do, for example working in all the different browsers. And the other thing that, I’m not sure you can call this a feature or distinguisher. It’s just something that Quill pays more attention to than other editors is that the HTML output that you get in Quill will be identical in each browser, whereas in other editors if you hit enter or various combinations of typing with backspace, enters, at some point, depending on which editor, which browser you’re editing on, you’ll get completely different HTML, which is a

big problem if you have an application and your users are on different browsers. You could save a bunch of content that somebody wrote.

Oh yeah.

And then when you present it to some other user, it will actually look different.

Yeah, that makes sense. Does it only support HTML as the output or do you support other formats too?

There are three format outputs it supports. And actually I would have rather not supported HTML output. I think it’s a very hard to deal with format. And well, I guess I can talk about that a little bit. But I guess the one it supports, outputting to plain text. And that doesn’t give you any formatting data. And then there’s this other format that I guess I call it a delta. And if you print it out it’s meant to be very intuitive. It basically is an array of objects. And each object will tell you the string and then the formatting data. So for example, it could be an array and the text is “Hello” and then there’s an object that says bold true which indicates that it’s a bolded “Hello”. And it’s just an array of a bunch of these objects.

And this type is yeah, so this type is meant to be very intuitive for when you print it out. And it’s compatible as well with this project called ottypes which is an Operational Transform type. So, people can, a lot of people when they use this they think about collaborative editing. And this was definitely kept in mind when Quill was written.

Oh, cool. Does Quill itself support any operational transforms or is it just the display portion?

There are subtle ways that it does or places that it does have to. The one place where it does this, and there are maybe more as Quill grows, but right now for example there is when you give Quill a command to edit something, the contents of the editor may have changed. And there is a short delay on you getting that event. So for example, if you call insert and A on the second character, the user may have typed a character in the 0th position and you just didn’t get that event yet. So in that case, Quill will actually do a transform so you don’t have to worry about that. But yeah, so Quill itself actually does do operational transform on its contents when it needs to.

Okay.

Yeah.

So, I’m wondering. It looks like just on the Quill website that there’s the basic functionality you would expect. When you’re talking about having the API, could I build something like a find and replace or things like that?

Yeah, sure. In that case for example, what you might do is just get the plain text output and then do a search and then figure out where the indexes are and then replace it. Yeah, so that’s definitely very possible.

That’s interesting. Now if I did that, would I be writing it mostly in JavaScript then?

Yup, it’d be in JavaScript.

So, how are people using Quill today?

So, there are lots of different use cases. Some people are using it as they have a main editing application and they’re using it where editing is for, for example a blog platform. But a lot of people are using it where editing is not the main part of the app but it is an important feature such as if they want to have comments on their product. Or there’s this product that’s kind of an interviewing tool, or it’s a recruiting tool, and one part of it is the need to compose messages to keep everyone in the loop. So, the composer is using Quill.

And that’s one of the motivators for building Quill, was that a lot of applications could benefit from just, “We’ll have textual editing.” But you didn’t want to have to spend a majority of your time supporting this because it’s just part of your app and the existing tools were pretty lacking for that. So, Quill can definitely just be a drop-in editor that just does thing well across browsers. And you can just focus on the main part of your product which for example could be a candidate pipeline tool rather than focusing a lot on the composing part of it.

So, I’ve never written a rich-text editor but I’ve always thought that they’re interesting in the sense that some of the ones that I use, u set up a text area or something like that and you give it a particular class. And then some JavaScript comes through and replaces it with something that looks really pretty that has a bunch of buttons on it. Is that done by setting up another DOM element somewhere that’s got an editable property that you can go in and change stuff on? Or do you actually expand the text area in some way?

So yeah, there’s basically two ways to write a rich-text editor. One way is to use this feature called content editable which makes a DOM node editable. And you can just go on any website and if you open up the inspector it’s a fun thing to do. And just add content editable and then you can suddenly click around and start highlighting things on the site and deleting them. And so, that’s actually a feature available and supported in all browsers. And so, that’s one way. The other way is doing this yourself. And you would have to render a cursor. And as people type you have some sort of invisible text area behind it, or a content editable div behind it where you capture keystrokes and then you figure out the intent of the user and then you add that to the screen.

And so, as far as other editors go, pretty much everyone uses content editable except for Google Docs uses the DOM-based approach. And the problem with the DOM base, well I guess the problem with content editable is that it is, it’s historically been very buggy and it still kind of is, especially between browsers. So, you have to… but then on the other hand if you do the DOMbased approach you have to re-implement everything. And most people, when they start out, and I was this way too, the DOM-based approach seems very attractive because you control everything. But I think people take for granted what an editor is expected to do and what it does do.

And so for example, if you just, there are so many shortcuts, keyboard shortcuts, and also interactions that we use that we don’t really think about. Like double-clicking highlights the entire word, triple-clicking highlights the entire, either line or paragraph. If you hit shift up it should highlight everything and then shift down, and especially when you cross boundaries, when you go shifting in different directions. And so, when you start to think about what your editor actually does that you use or just observe someone that, preferably a programmer as they’re editing, you start to, the list of things that you have to support starts growing really rapidly.

And the problem with some of these things is with a non-monospace font, just implementing for example shift up, the highlight up to the previous line, that’s actually a really hard task with a nonmonospace font with very little margin of error. Because if you’re off by two pixels if your cursor is off by two pixel, that’s noticeable to the average person. So, Google Docs in various, it still has this problem when you zoom in and use different languages, that you can notice that its cursor is off.

implement a bunch of things or just deal with a bunch of browser bugs. And so, Quill, I think really only Google seems to have the engineering strength to do the DOM-based approach, with the exception of if you’re editing, making a code editor, then I think DOM-based approach is very viable because with a monospaced font then the problem is a lot easier. So, Quill does use content editable. And it basically avoids the buggiest parts of it. And yeah, I guess I don’t really want to get into all the things that are broken. But I’ve looked at all of the features of content editable and avoid the ones that are the most problematic.

Well, I’d be curious to know what those are, but I’m also wondering. So, if you’re doing content editable and you need to add an image in or something…

Mmhmm.

Do you just upload the image and then basically insert an image tag into the editable section where your cursor is?

Yeah, basically. So, that’s an example of something that you could use one of content editable’s features to do that and there’s a command for adding an image. Quill instead will not use it because of browser compatibilities. It will just figure out where the cursor is and it’ll insert a DOM node and an image tag. And your earlier thing about I guess right now, Quill is completely frontend. So, the uploading, it expects an image URL. So yeah, the uploading part is not something that Quill does right now because it’s frontend only.

You would basically have to, either you implement some sort of backend that can accept images or you can use Imgur or something else that has an API for this.

Oh, I see.

But basically for all, at some point, the DOM expects a URL. And so, that’s the point where Quill can take a URL and add the image.

So, does that mean that Quill does not support image resizing either?

It doesn’t do resizing either yet. Yeah, but that’s something we do want to add. And yeah, that’s something you can do in HTML. So basically, if it’s possible to do on frontend, then Quill can do it.

But it won’t do, I don’t see Quill doing any sort of backend resizing, producing image files.

Sure, sure.

That sort of thing.

But maybe cropping, too?

Yeah. There are things you can do to support cropping, which is basically making negative offsets and stuff like that.

Mm, using CSS.

Yeah, exactly.

So, what would you say has been the biggest challenge producing an editor like this?

I would say that it’s definitely testing. So like I say, the editor has to work really well on different browsers. And it’s using a feature that is known to be questionable on each browser. There has to be a very, very comprehensive test suite. The problem is some of the best tools for this, for example WebDriver, Selenium, they’re known to have bugs and issues on content editable.

So, and added to that sometimes one of the problematic things that happens is when the user types or most notably the backspace or enter keys, and modifier keys, so those sorts of things are only, when you use some tools you can’t just use JavaScript testing and simulate keystrokes. You have to actually see what the browser does when you hit the enter key for example. So some tools, for example WebDriver, WebDriver doesn’t, on some systems they only simulate the keys. And on some systems it actually hits the keys natively. So, it’s either a simulated event or a native event.

So basically, the tooling for testing is pretty lacking for this sort of thing. And the requirement for testing is very high. So, at the current time there’s a lot of manual testing there I have to do. But that’s definitely been the biggest challenge in that it has to work really well for across a wide number of browsers. And it’s using a feature that is known to not work very well in across a number of browsers. And then the tools for testing it aren’t very good. So, that leads to a pretty difficult environment.

Yeah. It’s the perfect storm for testing failure.

Yeah.

It sounds really hard. Have you looked into any other testing tools like image-based testing like Sikuli?

No, I actually haven’t. What’s it called?

It’s called Sikuli, S-I-K-U-L-I. I’m probably mispronouncing it. But it came out of MIT and the idea is that it actually scans what it sees on your screen to try to find things to interact with and then send actual keystrokes to things and stuff like that. I don’t know if it would work well enough.

Yeah, it’s interesting. The key thing is if it, the keystrokes in a sense has to be native.

Yeah.

That’s the big thing with WebDriver.

Yeah, yeah, yeah. No, it’s native. You can use it on any app. It doesn’t have to be a web browser.

Okay, great.

Yeah, anyway interesting…

I’m going to go hi-jack a bank website with it now. [Chuckles]

Yeah, I’ll have to check that out.

Cool. That sounds really, really hard. [Chuckles]

Yeah.

So, what are your plans long-term to make that not a maintenance nightmare, keep it working well, you know?

Yeah, so a lot of it actually, if you modularize it enough only a small number of it has to be manually tested. For example, basically there’s a keyboard module and then there’s, I guess there’s a section of the code where basically if you assume that it reliably got keyboard events, then the rest of it could be tested with just JavaScript unit testing. Or the problem is reduced to just JavaScript tests.

Yeah, it makes sense.

So yeah, basically it tries to partition it as much as possible such that only the keyboard events have to be tested via real native events. And even though, so Selenium’s WebDriver support is also very good on Windows particularly. And the difference between Chrome on Windows and Chrome on Mac is not very large. So, there are very little differences across browsers on different operating systems. So, that’s helpful in that basically if you run WebDriver on Windows, on all of the browsers on Windows, you can have a pretty high confidence that it’ll probably work on Mac as well.

Yeah, so the only really problematic areas are, so right now basically manual testing has to be done more on mobile browsers and also for yeah, mostly mobile browsers. And then when you section off the keyboard events, most of the tests are actually not Selenium tests. There’s a point where you can assume that if, there’s a Selenium test tests the events. And then if you assume the events are all working, then the rest of it could be tested by JavaScript.

So, you mentioned that a lot of the manual testing has to happen on mobile.

Mmhmm.

What are the major differences between the mobile browsers and the desktop browsers?

Yeah, so basically officially Safari is ported because that’s what, or actually Safari and Chrome on Android because that’s what is automated by Sauce Labs. But I do also unofficially support Firefox on Android just because Firefox is pretty easy to debug and such. And I have an Android. So, there’s basically that mobile Safari is different from desktop Safari. It has different behaviors. So yeah, you have to treat it as a different browser. And also, there’s some very not obvious bugs that occur just because it’s not a, it’s a touch device.

So for example, one funny bug was when you hover something in the toolbar it shows a blue color. On desktop when you click on it, then you move away, it won’t turn blue anymore. But there’s no move away in Safari, or on a mobile device. So, when you click something the hover actually just stays there forever, or until you click on something else. So, that’s an example of something where I guess it makes sense once you realize that that’s how it’s coded, but something that’s pretty nonobvious when you, the difference between a tablet and a desktop.

So, when you set up Quill on your own website, it looks like you just download it and you include it in wherever, the header or the footer, whatever you’re going to do. And then I’m just looking to see. So, the rest of it is just, it looks like you just create a series of DOM elements. So, it’s not even, I

guess the difference is like with TinyMCE or CKEditor all you have to do is add a class to a div or something, or to a text area and it’ll do all the rest. With this, it seems like you have to be a little bit more explicit. Is there a default setup? I’m just looking at your quick start.

Oh, okay. Let me see what you are looking at. It should be…

It says create the toolbar container and create the editor container.

Yup.

And so, it’s a little bit more involved than just add the class to the whatever, though you do that too.

Yeah, I guess it has a little bit of initial content. So, if you just had no content then you didn’t have to have the sections that adds ‘Hello world’ and says ‘Some initial content there’. You could just have a DOM node and just call, say new Quill, and point it to that and give it the selector for the DOM node and it’ll make that DOM node editable. If you wanted to add your own toolbar, I guess this may differ from what the other editors do. But basically, if you want a bold button just have an element that has, have a button that has the bold class. That’s how you remove or include or not include certain formats is if you had a button for it or not.

Is there a default set of things that go in the toolbar? So, if I don’t specify a toolbar?

No, that could be the difference that you’re referring to in that Quill asks you “Where’s the toolbar?” and it’ll look for buttons and add the ones. Or it’ll look for buttons and attach event listeners to them, or to the relevant ones. There isn’t create, you can’t tell Quill right now to just create a toolbar with a default set of formats, although that could be something that we add.

CHUCK: Hmm.

That is, I guess we made that decision to make it more customizable. And I think, yeah…

Well, I have to say that that is a whole lot easier a configuration for the toolbar than I’ve seen with some of the others, because you have to go into some arcane config object and set some property. And if you misspell it or if you do something funny with it or if you write a function that’s supposed to do this or that or the other… with this it’s just, “Okay, this is what I want in there,” and then it knows that class ql-bold means, “If I click this, I want whatever’s highlighted bolded.”

Yeah, exactly. And it doesn’t even have to be in the first level. If you wanted to group your toolbars, I think we might have an example for that too. It’s just it’ll just look for the ql-bold class and then just add a listener to it. So yeah, it’s very much what the ethos of make it as easy as possible for the user, but at the same time allow a lot of customizability. Yeah, so that’s one way it does that. You can make the toolbar look however you want and Quill will just try to look for the classes or which buttons that you want, and it’ll attach those un-intrusively.

One other thing I’m seeing is themes.

Mmhmm.

Now, is that just CSS or is there more to it than that?

There is more to it. And that’s something that honestly we haven’t, we’re going in stages. And Themes isn’t something that we’ve documented very much on how to do and how to create your own. And that’s something that we’ll hopefully do soon. So, one example, something where it’s more than just CSS is you look at the multiple cursors example. In that page, when you just add that module, the cursors have a square flag with people’s names in it. And if you look at the full example, the flag has rounded corners, has a triangle. And in that case, there were some HTML changes where you basically had to specify a different template for the cursor flag. And for the rounded corners, you can make rounded corners just with CSS. But this is also centered in the middle and also has the triangular flag.

So, those sorts of things, uses a different HTML for the flag template. So, that’s something that you could specify in themes that isn’t just CSS. The intent of themes is just allowing you to customize the look, the aesthetics of the editor. And that’s the distinction between modules. Modules, it changes the functionality. And Themes changes the visuals, even though the visual sometimes may require changing HTML.

Mmhmm.

Yeah, but we focus more on, right now we’ve provided one theme that looks reasonable. And we’re focusing a lot more on the functionality part first. But in the future, there should be more themes and a lot more documentation on how to make your own and customize existing themes, too.

So, one other thing I’ve seen or I haven’t seen that is, too much with these rich-text editors is that sometimes I’m editing something, say on a blog that has its own custom theme.

Mmhmm.

And so, I want the HTML in my rich-text editor to look like exactly what it’s going to look like in the main HTML.

Mmhmm.

Is there a way to do that? Or is that harder than I think?

There isn’t a way to do that. It’s harder, I guess that means it’s harder than, yeah. Quill is very customizable. That’s something that is very difficult to do for the user to specify what kind of, so I guess what kind of HTML structure or even HTML tags to use. And I’ll give you one short example that’s even for choosing between I guess the tag to use for a line. Some people think you should use a paragraph tag. Some people think you should use a div tag. And even those two choices add a bunch of consequences that isn’t quite obvious.

So, I guess currently if you use divs it’ll paste a lot better into other editors, for example Word and Google Docs. If you use a p tag, just because there are two, just because by default there’s a margin, I guess I’m speculating on the reason right now. But if you have two p tags and you paste it into Word you’ll get three lines instead of two. So, that’s something that is probably not expected and that you didn’t think about or didn’t know the consequences. And the other thing is, but divs is I guess semantically less correct than a p tag. And actually content editable is a little bit better using a p tag.

Yeah, so I guess the problem, I guess why it’s a little bit harder, it’s harder than people expect, is part of the job of the editor is to handle all the cross-browser issues. And so, the more control you have over the HTML, the more that’s expecting the user to know about. And then that’s inviting a lot more trouble than one expects.

I’ve been wondering. Who’s working on the project with you?

So, I guess I’m the only person that’s mainly working on it. When it started, my cofounder was also helping me. But he’s doing something else now. And yeah, as far as core committer daily writing code, it’s just me right now.

Cool. So, what prompted you to get started?

Yeah, so I started a company about two, three years ago. It was called Stypi, S-T-Y-P-I. And it’s actually short for simultaneous typists. A lot people wonder why. It’s just a funny word. But there’s actually meaning behind it. Anyway, it was a collaborative code editor. And at some point we pivoted into we wanted to make it more general, not just editing code. And so, we expanded to editing rich-text. And so, that’s when I started looking for the right tool for the right job. And that’s when I found out that all these editors aren’t actually as customizable as you expect them to be. I don’t know. A lot of them advertise hundreds of API calls and then you realize all the calls are basically DOM API calls.

And so, there wasn’t really anything that did what we wanted which was collaborative coauthoring.

And so, that’s why we built it for Stypi. And we continued to build it for a while. We sold to Salesforce about two and a half years ago and we continue to work on it there. And after I left Salesforce I decided that I wanted to do this fulltime. So, that’s what I’m doing. And that’s I guess how I came to realize that there was a problem and decided that I wanted to solve that problem.

Super cool. Have you been surprised as you’ve gone along at anything in particular? Like, “Oh, this is a lot harder than I thought, or easier than I thought,” or anything stood out?

I think like a lot of engineers I thought this was easier than it actually was. But that’s okay. Challenges are good. But I think I tend to underestimate, or I either overestimate my abilities or underestimate the challenge. But I’ve been really surprised by how many, I guess I was surprised by the reaction to it and how positive it’s been and how many people are… I guess both the positivity and volume of it. Because I knew that this was something that some number of people wanted because I wanted it. And I wanted it before it was written and I wrote it because it didn’t exist. But I was quite surprised by how many people were interested in this.

And now, even people that want, so like I said the core, the big thing it adds is the API. But a lot of people are using it just as a replacement for CKEditor and TinyMCE and where they have little or no intention to modify the default behavior. So, that’s been surprising. And I don’t know if it’s because it’s a new thing or it is a lot more lightweight. And I guess I would consider them equal. And I’m not sure why they’re exactly choosing Quill over the other editors other than having a smaller code footprint. But I’ve been pleasantly surprised by the adoption.

So, does it have any dependencies like jQuery?

It does not depend on jQuery. Yeah, that’s one of the things. It does worry about code footprint. And if people didn’t care as much, it probably would use jQuery. But we try to keep the codebase really small. So, it doesn’t rely on jQuery. Basically the two libraries that it uses is this event emitter library. And it also uses Lo-Dash. And it uses a custom build of Lo-Dash, so just the functions that I like, or that it uses. And I think those two are basically tools, those two libraries I would need the functionality anyways.

And if I would have written, if I didn’t use those, what I would write would probably be basically the same, except not work as well. So yeah, it does use Lo-Dash and this event emitter library, EventEmitter2 I think is what it’s called. But yeah, certainly we do, it’s a frontend tool so it doesn’t need to be very lightweight. And it’s only a little bit more than 100K minified. So, that’d be nice to keep it that size.

Alright, well I guess the only other question that I have is if I put this into a web form that I was using and I decided that I needed to save the contents back to my backend, would it just grab the contents out of the container div that you’re using that’s editable and then just slurp that into what it’s submitting back to the server? Is that effectively how it works?

No, unfortunately not, because it’s a div. And divs aren’t a form field. There is something, if you want to do this, you basically have to grab the content and either fill in a form field or do an Ajax POST right now. That’s definitely something that’s a pretty common use case, so I’m definitely going to want to write a guide or make this easier. There could be just a module that mirrors the contents of the editor in a hidden form field or something. Or just wait for a listener, a submit, and then fills it in then or something like that. I’m not exactly sure what the right, best implementation is.

But there is some extra stuff that you have to do right now.

Mmhmm.

Just because a div is not submittable by default.

Right. What I meant was yeah, that you would have to essentially grab the HTML contents of that div and put them into a form field that gets submitted with the rest of your form.

Yup, that’s correct.

Alright. Well, I don’t think I have any other questions. So, let’s go ahead and do some picks.

Alright.

Dave, do you want to start us off with some picks?

You betcha. I have two picks for you today. And they are two that maybe our listeners have already heard of. Let’s find out.

The first one is I know most people have heard of Material Design that was introduced from Google this year. But maybe you don’t know that there’s a really cool Angular project. It’s called Angular Material, which is a set of directives that you can use in your Angular app that implement the Material Design spec. And some of them are really cool. For example, there’s a sub-header which gives you that scrolling effect where you have lists of items with categories and the little headers scroll up and they lock at the top of the viewport as you scroll out the previous one, which is pretty cool. And I understand that they are working very hard to make sure that they have accessibility built in so that you can help users with disabilities, visual or hearing impairments, which is really cool.

My other pick is also probably one that many people know about. But I wanted to mention it because it is to this day still probably my favorite source of technology news. And that is Hacker News, which is news.ycombinator.com. And I’m always pleased when I open that up. I almost always find something really interesting to read and the content is really good. I’ve been really pleased with it.

So, those are my picks.

Awesome. I’ve got a couple of picks.

The first one is something I’ve been working on. It’s JS Remote Conf. The idea is that you set your DVR to record your favorite TV shows. And then you watch talks from JavaScript people instead, in the evening. It’s going to be the first two weeks in February, Tuesday, Wednesday, and Thursday. I’m also offering tickets for users’ groups. So, if you run a users’ group or are interested in having an event for your users’ group then this is a good way to go. Anyway, you can find it at JSRemoteConf.com. And I’m also opening up a call for proposals. So, if you want to speak, I would be interested to see what you want to speak about.

Jason, what are your picks?

I have three picks. They’re very different from each other.

So, one of them is basically this podcast that I listen to all the time. I love history. So, it’s called ‘Hardcore History’. I don’t know if you guys have listened to it.

Yeah, I love that one.

Yeah. So, this one pick goes for probably one of the best podcasts that I’ve heard on history for sure.

Yeah, me too.

And goes really in-depth in a lot of historical events. It kind of makes me mad, some of the parts of history that I was never taught.

Yeah, me too. [Laughs] Totally.

Yeah, yeah.

That’s [unintelligible], hashtag politics. Anyway.

What’s your favorite series so far?

So, I really like the World War I.

Me too.

And I don’t think he did the last one yet, so it’s kind of…

Nope, not yet.

I’m wondering. Well, I know how everything ends, but I wonder how he presents it.

[Laughs] Spoiler.

[Chuckles] Yeah. So, that’s one not programmer-related at all.

Another one is there’s this tool called ngrok that I use a lot. And it’s basically, it exposes your localhost publicly on the internet. So, this is actually, this is how I do a lot of tests on Quill, is that I’m writing some code on my computer and I want to test it out on my mobile devices. I’ll just use ngrok to expose my localhost and then I can use my iPad and visit my localhost essentially and play around with it. And this will work too with my virtual machines. So, I have a bunch of virtual machines to test on IE. And it just makes it really easy to test. Some of it makes it easier to test. You can configure your virtual machines to use your localhost and map IPs and et cetera. But it’s just a really hard way. With ngrok, you just type a command and then you can visit your localhost.

So, that’s something that helped a lot in my dev workflow for sure.

I’ll have to check that out. I’ve been using a DynDNS URL and then just have my router pass through specific types of traffic to my localhost.

Yeah.

And it wasn’t that hard to set up but having something that’s maybe a little more automatic sounds good.

Yeah, seems cool.

Yeah, and then my last pick is this blogpost that I really like. But it’s basically about how to, one of the big questions is how to, what do you choose to build when you’re working on a project? What feature do you choose to build or what issue do you choose to address? And it has a really interesting way of thinking about the problem where it categorizes things into, it either is a game changer, well yeah a game changer, a show stopper, or a distraction. And basically I really enjoyed the post. And I think it’s a really interesting way to think about how I prioritize things. And it’s been helpful for me as I not just building Quill but other things. So, that is one of my picks.

Very cool.

Alright. Well, I think we’re pretty much done. Thanks for coming, Jason. It was fun to talk. And hopefully folks check out Quill or get inspired to do something similar. I know that there are a lot of possibilities out there with editing DOM directly the way that you do with the text editors. And I think there are some cool possibilities. So yeah, so we’ll wrap it up. We’ll catch you all next week.