Ep. #7, DraftJS & Rich Text Editing On The Web

Brian Douglas: Welcome to another installment of JAMstack Radio. Here we have Matt Biilmann, once again. Matt, welcome.

Mathias Biilmann: Hi again.

Brian: And then we have Nik Graf. Nik, Hello.

Nik Graf: Hello, thanks for having me.

Brian: Awesome. So, we met in-person, like IRL. Actually, we're in-person today, so I don't have to preface that. But we met a couple of weeks ago, just randomly. I was holding a Serverless meeting with the Serverless guys, and then I found out that you worked there.

And then they told me you maintain DraftJS Plugins, which got me really intrigued. So, can you introduce yourself and then tell me a little bit about DraftJS plugins?

Nik: Absolutely. I'm Nik Graf, I do a lot of front-end stuff. But actually my background is full stack. So I maintained a lot of and built a lot of back-end stuff as well.

Brian: Yeah.

Nik: But especially over the last two-to-three years, I've doubled down on front end. And yeah, about one-and-a-half years ago, I decided to check out React. And that actually got me kickstarted again, because by that time I was laying it low, into more sales and freelancing.

Brian: Oh really?

Nik: Yeah, absolutely. It was like team management, and I'm part of this freelancer community called StarterSquad. And back then, I started to do more team management and helping people and coordinating.

But yeah, with React, it was a lot more fun again to do front end. Because I could see, I could build great components, encapsulate everything in there that was messy, and then give that to our team. Even I could reuse it, and it was amazing.

Brian: So it sounds like React kind of revived your career.

Nik: Absolutely.

Brian: Wow.

Nik: Yeah, absolutely, back to UX and front end.

Brian: Well, that's interesting. I think I told you off-air that I listened to your interview with React30. Michael Jackson, who hosts that, he had a very similar experience where he was getting to the point where he was done with programming at that point.

He had worked for Twitter and for some other startups after that, and he got to the point where he was just like, "I'm not sure if I really want to do this anymore." And React basically also revived his career as well.

It's really interesting how React is not only a different approach, but it also gets people excited about doing front end and UX again.

Nik: Yeah, because simply, at least for me, I worked so hard to get good UX working, but it was so hard to do. And by the end, that was really frustrating because you needed so much effort to get stuff off the ground. But nowadays, it's way, way more easier. And it's really good for the whole ecosystem, as well as for me personally, and I guess it was for Michael. Because you can simply build stuff again and it's fun.

Brian: And I think we're having the same thing with Mathias. I work with Mathias, and Mathias built our entire app in Angular, and now we've converted it to React. It's definitely an interesting approach. I think the approach of the UI of React makes it fun to actually throw components around and eject them, and stuff like that. Mathias, did you have similar experience with React when you switched over?

Mathias: Yeah, I like a lot how isolated components are. I mean, I think that's what it really got right after lots of people have sort of been attempting it, and it's like, I've been attempting it myself. I could build a very single page before any of the frameworks were around and came up with some what similar architecture, but really messy.

I want to admit that the pleasure of React, I think, is really that it nails that layer of having these UI components that are very easy to reason about. Because I think anyone who has tried to build a large app, without something like Redux and React in a single page, has run into problems of just figuring out, like, "How does a UI component come into some weird state where callbacks are not behaving in the right order?" and things like that.

I think React really brings a model that makes it easy to actually reason about what's going on in your code base.

Nik: Yeah. And let me do a shout out to Jeremy Ashkenas here, because I think we came a really long way, and the first step for me happened with Backbone. I remember the day when I was still fiddling with jQuery code and looking things up in the DOM based on attributes and then removing stuff. In hindsight, that's crazy.

The first time I saw Backbone and actually went through the code, and I didn't know there was some 0.0 or something, it was fascinating. Like, wow, you can actually build a framework for the front end to do single-page applications. And that was like, "Wow, that's amazing. And it's so beautiful." But in hindsight, it's like, "Well, we could do even better." And there's React, and we're all in love with React, so. I'm curious to see what comes next.

Brian: There's a lot of things in the works. I think different, other frameworks and plugins that are making things a little exciting, even more exciting, I know our CTO just recently, just today, built something in Elm.

Mathias: Yeah. It's going to be fun to look into.

Brian: I just looked up the code, and I was like, "Elm... Okay, I'm interested." So, let's rewind a little bit back to last year's React Conf. They announced DraftJS. What made you want to do DraftJS Plugins after the announcement of DraftJS? What was the exciting part about that?

Nik: Let me quickly explain what DraftJS is.

Brian: Oh, yeah, please.

Nik: DraftJS is a rich-text editing framework based on an immutable model. As you said, it was released by Facebook on the React Conf early this year. And when I try to do rich-text editing a couple of times in the past, and well, just doing @mentions, all that kind of stuff, it's really really hard. Because you only have text area.

What happened in the past, a lot of this, you put stuff on top divs, position them absolute, and it was all, like, big, dirty hacks. And it was super painful. In the end, building a good experience was hard. And the only team that I saw that really executed that well was Medium. Because, I think, they are still the gold standard.

Brian: I think a lot of people use them as a standard of what their CMS looks like.

Nik: But it's still sometimes foggy. I find it real fascinating, they're like, their whole, one of their core experiences is editing. And even though they fully focus on it, it's still hard to do and they still have trouble sometimes. So, I struggled with this problem myself, rich text editing.

When I saw DraftJS coming out, I was like, "Holy moly, this is amazing." Because if they do all the hard work, abstracting all the browser differences away, and I just have to write React components and apply some strategies or build my own blocks with React, then that would be amazing. For me, this was absolutely the biggest announcement of the React Conf earlier this year, and I found it super exciting.

Then, by the time I got funded by Stripe, there's such a thing as the open-source retreat. I was, right at the time, doing the open-source retreat. So they paid me to work full-time, only on my own open-source projects. And there was a super nice opportunity, because I felt like I could just fiddle with the DraftJS thing for a week or two, and yeah, it stuck with me.

DraftJS has brought in some really interesting ideas, first of all, this immutable model. And that was super interesting because you basically could intercept every change. And that made it really powerful because you have to, kind of when you use a redux, you have the stable state. And then whenever you dispatch an action, the state changes based on the reducer. But in this case you have an input form or an input in React. You have this concept of onChange. Then you have to pass it down via value again.

In this case, it's just onChange, and then edit or state. But the interesting thing is to, whenever you do a change, you get a complete new version of this model back. It's still efficient because it uses immutable JS, which under the hood uses stack trees and tries to reuse memory and all that kind of stuff. So that's pretty cool and that is super powerful.

That's why I was super excited, and second of all, you could take this model and you could actually generate a JSON structure out of it and then you could put it on the server. And compared to doing rich-text editing in the past, where most people just took the HTML, the tags and whatever the people created, and dumped it into the database, I found this horrible. Because you have to sanitize it.

Doing operations on it is really really hard because you transform the stuff on your database, or what you see is you get people dropping a special data into that, and then it's weird.

Brian: Like script tags and stuff like that.

Nik: Yeah, exactly.

Mathias: When it comes to ContentEditable, which is sort of the browser standard, all of those rich text editors have built up on, like, that's almost a malicious piece of code in itself.

Browsers are really horrible. Just the fact that, when you press 'enter' in ContentEditable, there's no consensus at all between any of the browsers, of what actually happens.

It's completely different from browser to browser, if you insert the br or a new paragraph, or if you extend the current tag you're in, it's completely different. And things like, at a point Chrome randomly started to insert a style, a "line-height: 1.5" on random elements.

Just from one day to another, they released a version of Chrome that decided to start doing that right. So anything you had that used ContentEditable suddenly began inserting line heights that might be completely different than the line heights of the rest of your document, and it's incredible how bad that API is.

Nik: Yeah, absolutely.

Brian: So Facebook's DraftJS open-source project basically--

Nik: They fixed that.

B- They fixed it for us, okay.

Nik: They abstract. Every time you do a change, it actually, because it uses ContentEditable and every time you do a change in a content in HTML, it will map back to the data structure. And every time you change the data structure, it will map back to the content.

And this is super useful because then you don't have to fiddle with HTML anymore. You just fiddle with the data structure on the user level, or developer level, and that's just convenient.

Brian: Before we jump into the plugins aspect of what you're doing, my question is, am I correct, that if Facebook built this out of their messaging platform, they were using this already somewhere else?

Nik: There is Isaac. And Isaac worked in this as far as I understood for the last one-and-a-half years, because Facebook exactly had this problem, like, "How do we do @mentions, how do we do hashtags?" All that kind of stuff.

So they basically built this, and eventually they extracted DraftJS out of this filling process of doing these things and Isaac was the guy who did most of the work as far as I understood, and that's how it happened.

Brian: So, why plugins, then?

Nik: Okay, yeah. And that's actually where it leads to, "Plugins or a plugin system?" Because DraftJS was created out of this need for having that for inputs like comments, status updates, messaging. But the problem for me was that it is a monolithic system. When you use DraftJS, you basically have to, everything you want, every feature, you have to put into this one component.

That makes it really tricky because if you have a custom block renderer and you have an image feature, and if you have a sticker feature or if you have a youtube feature, and all these things, then you would need to, in one method, basically write the same code for handling these different cases.

So I've built a couple of things with DraftJS, and in the first week, like in the first two weeks, we saw a lot of like people starting to write, trying to match Medium editor with DraftJS and building these huge codebases of one-to-two thousand lines of code with all the features in one thing.

Mathias: Yeah, I've noticed some of those, looking at them because, on the one hand we definitely wanted similar, also for Netlify CMS is like the same, I think the Medium experience, in terms of like how the toolbar appears and how you add and you block level elements, so it's really good.

But then, every time I looked at those Draft versions, it's like they try to take over everything and even handle image uploads, and some of them even tried to handle the server side of that. I think that's definitively a much more powerful approach to find a way to decouple those different things and have a solid extensible editor.

Nik: Exactly. And that's where we started to, the idea came from that. Why not abstract it and build a wrap around DraftJS, the editor component itself? We've looked into either, "Do it with high-order components or do it with a wrapper component?"

And in the end, the wrapper component is a little bit more straightforward and has some advantages, that you can do ref. And you can use this ref to, for example, set focus, and then you can expose the same thing as the editor has to the wrap as well. You basically pipe it through. There's a couple of benefits using the wrapper.

And yeah, and then we decided to go with the wrapper and basically built the system which automatically maps the DraftJS properties, that you can use to do custom things like custom blocks, or to use this and basically go for all the plugins and take every method and then combine them and run through them. And yeah, that's how plugin architecture was born.

Brian: The architecture itself, if I install DraftJS on my React component or whatever, and I have DraftJS there, I want to add DraftJS Plugins. Am I installing separate plugins each time I want a separate plugin? Or I install the entire architecture?

Nik: What you need is, you cannot use the DraftJS editor by component. You can use all the features from DraftJS itself, but there is this one wrapper component which is basically the plugin editor. And this is just a wrapper around the original editor, and then that allows you to pass in plugins as a property. And the plugins you install separately.

So it's like separate wrappers because that was the whole idea. Some people want to have a mention feature, some people want to have a mention feature and an image feature, some people only want to have the image feature.

Brian: Exactly

Mathias: We're seeing some of the same sort of challenges in terms of the CMS, where we also want the main, the CMS is based on the idea that you have different fields, each content type have a list of fields and each field has an associated widget. So it could be just a string widget or an image widget or a relations widget or a markdown widget.

Obviously, for the markdown widget is where we needed a rich text editor that we felt was solid enough to both be able to switch between a markdown mode and a rich text mode.

We definitively didn't want something that worked directly with some DOM- HTML representation, because I've been there before and I know how painful it is.

Brian: So you have actually a lot of experience with rich-text editing too.

Mathias: Yes. I've pretty much tried all of them, I think, in real products.

Brian: And for the listeners, I don't think we actually explained: Netlify is actually making a CMS to build on top.

Mathias: Yeah, I should explain a little. In itself, Netlify is like an automation platform for JAMstack sites, where you just connect the github repository to Netlify and every time you push to it, we'll run whatever build tool you're using, run the build and do an Atomic deploy to it, to our content delivery network, of the result.

That's one of the big use-cases here, it's just all the sites build around static site generators and so on, and those are amazing for developers. It's way nicer to work with something like Google and something like WordPress. It's much nicer to have everything in a git repository instead of having most important stuff in some database somewhere.

But the challenge for a lot of people is, what do we do with the non-technical users? What do we do with the marketing department, that needs to be able to go in and update the site every day and that definitely won't be firing up Atom and editing markdown through github. It's just not going to happen.

One of the ways we are tackling that is by building an open-source CMS, a Netlify CMS that's not tied to Netlify in any way. It's just tied to the idea of all your content living as a structured data in a Git repository, and then being able to give non-technical editors an intuitive interface for going in, like creating a new post or updating an author or whatever you want to change, and give them a side-by-side preview.

A little like Ghost or something like that, where you have the fields for the content you need to fill out on the one side, and then a preview of how this content will more or less look like once you hit publish and it goes live.

And then when you hit publish, we actually keep track of content, and each publish can go into a branch that then gets some associated meta data with comments and so on. So you can actually have an editorial workflow that's similar to what developers do with pull requests, but just for really non-technical people.

Once you finally say, "Publish this," it creates a commit in GitHub that triggers a build with whatever system you're using for that, and then your version of the site goes live. And then, of course, we needed to fit in the actual editing component for markdown, which is like one of the most important parts.

I've built two commercial CMSs before, so I have dealt with this a lot. I've tried, like, I have a lot of experience with like the old generation of rich-text editors like TinyMCE and CKEditor and that whole batch of content-editable based editors that are all pretty horrible in many ways.

It's been really interesting to see a whole new generation of rich-text editors come out recently.

DraftJS is one of them, and Marijn Haverbeke that made CodeMirror is working on another one called ProseMirror. And then 37signals has one that, I can't remember the name of that one off the top of my head, and then Slate is how this well where all of them has in common. That they finally put an abstraction layer between the DOM and the editor and have this internal structured representation of the document you're editing, instead of just having essentially the DOM being that representation which creates so many problems otherwise.

We eventually looked a lot at both DraftJS and Slate, and it's not a very easy decision.

Nik: I love Slate, by the way.

Mathias: I think what drew us to Slate eventually was that it seems like its internal representation of the document is more flexible than DraftJS presentation.

Nik: I can give you a little bit, I know a little bit about the background story in Slate.

Brian: What's the difference between that and DraftJS?

Nik: Ian Storm Taylor is the creator of Slate and he was there way early on when DraftJS was released. He has this Slack channel where a lot of people, I think about eight, nine hundred hang out and constantly ask questions and post answers. He was there very early on and he started to build a couple of things with DraftJS as well, and what happened is, when I built like the initial version of the DraftJS plugin system, he actually gave a lot of feedback.

I would say a lot of the good decisions in DraftJS Plugins are because he provided feedback, and that was super helpful.

Eventually, and that was a very interesting move, I think DraftJS was not moving fast enough. DraftJS is like, I think they deal with it like every other Facebook project; they focus on the use case they have and then they know how to maintain that and they know how to work with that. And that's their core focus. I think it's changing a little bit now with React.

They also do server-side rendering, and so although they don't do it by themselves, but still, that was still the case with DraftJS. And I think what, for Ian, that was not fast enough and I actually have to say I don't know what his personal ambition was, but he created Slate, and I think it's very much inspired by after DraftJS came out.

But he also took that model from other systems and yeah, the core system also looks very very similar to like what DraftJS Plugins does. He even says on the website it's inspired by DraftJS and DraftJS Plugins and ProseMirror and Quill and all these systems. I haven't done much with it yet, but the API, to me, looks more approachable.

And on the other hand, to be fair, for the people who built DraftJS, I think he has a good position to start. Because he saw the final thing he worked with DraftJS for a couple of months and then figured out, like, okay, then you have all the lessons learned and if you have the motivation, the vision to start something, you basically can build a whole new thing.

Brian: Yeah, you start from way up here instead of down where DraftJS had to start.

Nik: Absolutely, yeah.

I think without DraftJS, Slate would not be a thing. But still, it's amazing.

I think it's, and maybe you can tell more, I heard it's not fully fleshed out and a bit buggy in some cases. But I think that's just a matter of time.

Mathias: I think so, too. I mean it's obviously not a rich-text editor that's been out in the wild for super long and been beta tested by all the weird edge cases and so on, and so we definitely ought to find that we're putting in a lot of work into really making our editor component on top of it. It's not like you just plug it in and then it's done right. But I also think it's, as you say, it's obviously taken some really good architectural decisions and fundamental decisions.

Nik: Ian is super strong in that area

Mathias: It's an active project, and I think there's a lot of people seeing that this is like, I think GitBook is using it as well now, or working on it, and I think there'll be quite a bit of uptake around it. And I also think it's on a good track.

Brian: So, with DraftJS Plugins, I was going to ask, can you integrate that into Slate if it's built similarly?

Nik: The API is way too different.

Brian: Way too different, okay.

Nik: So I'm thinking about actually, with a friend in Europe, I'm doing every couple of weeks pair programming sessions, we probably build a mention plugin for Slate.

Brian: Yeah, could you priority pull in all the same plugins.

Nik: The benefit is that I have experience with all the plugins, and you know the edge cases, and so on. So that's why it's clearly a benefit. But on the other hand, it's still work and it's just a matter of time. If I could clone myself, I would dedicate one Nik to build out Slate plugins. But that's... yeah.

Brian: Maybe interesting to see, because like you said, Mathias, there's more CMSs or just rich text editors that are coming out.

Mathias: Yeah.

Brian: It will be interesting to see if they take a Redux approach where they absorb, like Facebook will absorb some of the technology from Slate, and everything's going to be in parity eventually. So I don't know. I'm not sure how or what.

Nik: What do you mean?

Brian: A year and a half ago we had so many different Flux implementations. And I know we don't have tons of DraftJS implementations at this moment. I'm not even sure. I'm actually curious, are there a lot of people using DraftJS, like in production in their code as well?

Nik: I mean, the most significant number is probably the people on Slack.

Brian: Okay.

Nik: There's like a couple hundred of them. I could even look it up. I think it's about seven, eight, nine, maybe even nine hundred people. Just being in that chatroom. And yeah, I know enough teams all around the globe, small, medium-sized companies using DraftJS.

It even goes to the point where, if you're uncomfortable about architectural decisions, so for example, there's one guy who tweeted, I don't know was it a month or two ago, they had to delay on an Angular code base but they decided to pull in these dependencies, React, Immutable.js, DraftJS, just to get the mention plugin.

Because they looked at a lot of other stuff in the Angular space, in React space, and so on, and they said, like, "That's the only thing that really does what we want. It's really a pity, but we want to have the feature and we have to move on. And eventually we might migrate to React.

"It's not happening right now, but we need that feature and we need that right now. And nobody else is providing it, in this quality." And then yeah, it makes me feel uncomfortable, why is this the only way to go? But on the other hand, I'm obviously proud that they're like so confident in this plugin.

Brian: That's awesome. I'm super impressed with your work and I'm sort of impressed with what DraftJS is, and even Slate, I'm very interested in jumping in there.

Nik: I hope they have some cross-pollination happening now, that I don't know if it will eventually merge, I think with two players out there only and they are way too different. But I hope that, basically, a lot more ideas are currently coming from Slate and I think that, I hope that, they come back to DraftJS again. And again, this also brings ideas back to Slate, and it's like, I want to see a better eco-system.

I don't care who wins. I just want to see, in three years, rich-text editing be a no-brainer.

Brian: Yeah.

Nik: That's what I want to see.

Mathias: I really hope so, too. It's been so long, and it's such a fundamental part of any system that has user input, and it's so painful.

Nik: Yeah, absolutely.

Brian: Well, hopefully people who listen to this podcast will get excited about it. DraftJS Plugins is open-source.

Nik: Absolutely.

Brian: I think it's open-source, github.com/draft-js-plugins/draft-js-plugins, right?

Nik: Yeah, exactly.

Brian: Okay cool.

Nik: Oh it's with draft-js-plugins.

Brian: Okay cool.

Nik: And you can find it.

Brian: Awesome, yeah. I hope people will jump on board and get excited about that. And then Netlify CMS, same thing, open-source as well?

Mathias: Yeah, fully open source.

Nik: Where can I check it out? I want to see it.

Mathias: Github in netlify/netlify-cms.

Nik: Awesome, and you have a demo of that as well?

Mathias: We're working right now in the transition from Ember to React. The link to the demo is gone but it will be up there early next week. But the whole code base is there, and I think one of the interesting things is that it uses this concept of back ends where Github's API is one of the back ends.

We have in a little service called netlify-git-api that you can run from a local Git repository and it gives you Github's API for your local repository so that you can use it for another back end. But then we also have a little in-memory back ends, that's just like a fake repository in memory. So you can use that for the demo and when developing, just seeing, "How do I make a widget to this, tweaks on this?" without actually having to go roundtrips to Github and so on.

Nik: I think one last thing that I learned from dealing with open-source projects is you need to have a really good demo. So people must be able to try it out, or if it's back-end stuff, then at least show exactly what it does and how you can help people.

Brian: With GIFs.

Nik: In the end, yeah, absolutely.

GIFs help a lot because the timespan people are going to look at stuff is very brief, and you basically have to market this as a product.

If you want your open-source project to be successful, or let's see, successful is maybe the wrong term. It's like being more widespread, which helps you because you get more feedback and more contributions, then you have to market it as a product.

Brian: Yeah.

M- Yeah, I totally agree. We've sort of been developing it in the open but fairly quietly until now. And then we have like a pretty big project that's going to be using the CMS that I think will go live at the end of this month or the start of next month. So around that time we'll also start pushing out more of the documentation and demos and examples, and so on, around it.

Nik: Yeah. Keeping documentation up to date is hard.

Brian: Wow, so many tools out there. Well, cool, so all in this conversation, I didn't want to get to mention it too, but I wanted to mention it, you're at Serverless.

Nik: Yes.

Brian: And Serverless does a really good job with their GIFs, too, like making me understand exactly what I need to do and the sort of output I'm looking for to see. So thumbs up to Serverless as well.

Nik: Yeah, Austin. Nowadays Austin our CEO does most of the GIFs.

Brian: Oh yeah?

Nik: Yeah, he's really good at that.

Brian: He's got a good git game.

Nik: Yeah exactly. I think he's proud of that, and that's fair enough, because he does a good job there.

Brian: Cool. So, I want to transition into picks, anything you guys are jamming with, anything that keeps you going. You do a lot of open source. Any of the GIFs you're excited about it, feel free to share. Nick, if you have something ready to go, as the guest, I'll let you go first.

Nik: One thing I do at Serverless is, I get opportunity to play with GraphQL. We do a couple of experiments, building out future platforms and, yeah, we decided to use GraphQL there, and I love it. It's so good, and that's also kind of an announcement, because yesterday we started to, Serverless, it's where we're going to release at one point or very soon that changed a couple of things.

We upgraded the Serverless GraphQL-style locator boilerplate to this, version one, and added Relay and Apollo. So you can choose between these two clients and basically finished it up yesterday and released it, probably do a marketing push or so in two weeks.

But again, I'm super excited about this because, what you can do is, you can take this thing, it takes a couple of minutes to set up the initial project, set up the project and you have it ready, you can deploy it and it's production-ready, because it runs on AWS Lambda, which theoretically scales indefinitely.

Then you could simply, for the resolvers, wrap your REST API, and that's super powerful because then, as a front-end team, you just basically put GraphQL in front of your REST API and then have all the power of GraphQL, only you don't need to overfetch, you don't need to underfetch.

You just fetch whatever you need, and it's production ready, because AWS Lambda scales amazingly. I am super excited about this and, in general, to do more with GraphQL, really enjoy this concept of just fetch what it needs, and I love it.

Brian: Awesome. Yeah, I'm going to check it out.

Mathias: It sounds really exciting. I'm also interested to see, for our team it sounds like GitHub had launched a GraphQL-based API for all of Github, which we still haven't quite figured out, like, how well does it fit with what we're doing? But that's really interesting as well, so there's that. There's a lot of interesting things going on around GraphQL.

Nik: Yeah, it's totally exciting. And the second thing is probably getting more into functional programming. So I, like once in two weeks, I do a couple of hours pair programming with Steven Nobel from Stripe and Theresa from Denmark, and we just, like the last couple of weeks, we fiddle a little bit with, or the last couple of months actually, we fiddle with Elm and now we have a pretty good understanding.

Actually, Theresa works with Elm full-time on holidays and I think the company is called Opbeat, or I'm not sure.

Brian: I wasn't aware anybody else was using it.

Mathias: Opbeat is a Danish company, so it makes sense.

Nik: Yeah, exactly.

Brian: Mathias's Danish, by the way.

M- Yeah, I'm Danish, too.

Nik: Okay, all right, the cycle closes. So, Elm is, I mean React has a lot of these functional approaches and CycleJS and RxJs, but in a language like Elm or Reason, you cannot be allowed. And right now it's more, to me personally, it's like an interesting challenge to shift my thinking paradigms.

But then I can definitely see this being the future, that we either work with Reason or with Elm.

That could be maybe the next thing after React, if it gets traction. Would be interesting to see.

Brian: You know, Mathias, I was going to segue, because I would kind of pick the Elm community as one of my picks. Recently they made a blog post about their meetups. I don't know if you were able to go to any of the meetups we sent you.

Nik: Yeah, I've been there a couple of times.

Brian: They wrote a blog post about how they basically are trying to build a community differently. So, rather than doing a talk at their meetups, they actually do hack nights. You can actually just learn Elm and get your questions answered from Evan, who is the creator of Elm, and stuff like that. So I just want to shout out to them.

I'm also excited about Elm as well. I have done one tutorial so far. I would really like to also get into the community as well, functional programming since React is like the entry door to functional programming.

I didn't know it was like a thing I needed to know, and now it's a thing I need to know.

That was my first pick, and my second pick is actually off the beaten path of what we've been talking about so far. But some people know, most of my picks are around Kanye West. I'm not going to pick him today. My pick today is Chance the Rapper, though.

He's actually on tour with Kanye West at the moment, and he's 23 years old, just turned 23. His first CD just came out in the last few months. And the guy is phenomenal. It's a different take on rap, so I think his approach is going to change the industry as far as like, what's the next thing after last 10 years of rap. I think I want to see more and more people start rapping like Chance the Rapper. Which is a very generic name, but yeah. Mathias do you have any picks?

Mathias: Mine would be David our CTO's little new project in Elm. A little open-source project to be able to test Netlify's redirect and rewrite rules and hitter rules, and so on, in the browser and put in the input format and make sure they behave right and so on.

I'm looking forward to playing around with that, especially since I've done quite a bit of work in Haskell and I actually still have four production services running in Haskell, as part or a web part of my old product. And Elm is really like Haskell in the browser, without the laziness, kind of. I'm looking into playing around with it.

Nik: How is it that the laziness can get you in some really weird cases with Haskell?

Mathias: It's both one of the big strengths of Haskell and one of the big challenges. It means that you can do things in a very declarative way sometimes, where you just define an infinite list of stuff and then take a part of it and apply operations. And since it's all they see, it doesn't matter that it's an infinite list. Because only the part that you actually touch gets evaluated, so there's a lot of things that you can do also in terms of thinking as operation systems, screens on lazy lists and things like that.

The thing is that sometimes it can be, like normally the great advantage of Haskell is that it's very easy to reason about state and so on. But laziness can sometimes be a little harder to reason about, because you sort of lose touch of, when does something get evaluated.

Some of the common performance issues that people run into in Haskell can be when they deal wrong with laziness, so they end up passing along a lot of, internally Haskell stores everything as funcs that are like placeholders for something that needs to be evaluated. You end up generating a lot of those, instead of actually generating the values that get passed around and so on. You can get interesting space leaks and stuff like that. So it could be a little tricky, but it can also be really powerful.

Nik: The Elm component, by the way, is written in Haskell.

Mathias: Yeah, and the inspiration in their whole syntax and everything is very obvious like when you look at Elm. It feels very familiar coming from Haskell.

Brian: Well, I'm going to conclude this Haskell podcast. Well, Nik, I just want to thank you again for coming on the podcast to share about DraftJS Plugins and what you've done and how you got here. And also that little tid bit you gave us with the GraphQL in Serverless and, hopefully, people who listen to this will jump on that.

Nik: Yeah, I'm excited about this.

Brian: Awesome. Well, thanks again, man.

Nik: Thanks for having me.