AgGrid: From Open Source to Successful Business ft. Niall Crosby - JSJ 504

Niall Crosby, creator of AgGrid, joins the panel to discuss the journey from building an open source data grid used all over the world to providing support and enterprise features and running a successful business based on that same open source software.

Special Guests: Niall Crosby

Show Notes

Niall Crosby, creator of AgGrid, joins the panel to discuss the journey from building an open source data grid used all over the world to providing support and enterprise features and running a successful business based on that same open source software.

Panel
  • AJ O'Neal
  • Charles Max Wood
  • Dan Shappir
  • Steve Edwards
Guest
  • Niall Crosby
Sponsors
Links
Picks
Contact AJ:
Contact Charles:
Contact Dan:
Contact Steve:
Special Guest: Niall Crosby.
Sponsored By:

Transcript


CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from the deepness. 

CHARLES MAX_WOOD: That sounds deep. Sorry. 

STEVE_EDWARDS: Is that like the depths, but just spelled differently? 

AJ_O’NEAL: I just relistened to Mistborn, the final empire. 

CHARLES MAX_WOOD: Oh, gotcha. All right. Steve Edwards.

STEVE_EDWARDS: Hello from sunny and somewhat temperate Portland. 

CHARLES MAX_WOOD: We also have Dan Shapir. 

DAN_SHAPPIR: Hi from Tel Aviv where it's the Jewish new year. So at the time of this recording, so Shanah Tova. 

CHARLES MAX_WOOD: I'm Charles Max Wood from Top End Devs. And this week we're talking to Niall Crosby. Niall, do you want to introduce yourself? 

NIALL_CROSBY: Hi guys. How you doing? I'm calling in from, from London where we're having a heatwave. And I'm quite thankful right now we installed air conditioning in the house because I really needed to see the heat. 

CHARLES MAX_WOOD: Good timing.

NIALL_CROSBY: Oh, indeed. I'm looking at the other people outside and sweating it out. But yes, seriously, thanks for having me on the show guys. I've been wanting to come on for a while.

 

First, I figure out how to deploy them. I get them up on the web, then I run Sentry on them. And the reason why is because I need to know what's going on in my app all the time. Yeah, I'm kind of a control freak, what can I say? The other reason is, is that sometimes I miss stuff or I run things in development, you know, works on my machine, I've been there, right? And then it gets up in the cloud or up on a server and stuff happens and stuff breaks, right? I didn't configure it right. I'm an idiot and I didn't put the AWS credential in. I didn't do that last week, right? That wasn't me. Anyway, I need that error reported back. Hey Chuck, I can't connect to AWS. The other thing is, is that this is something that my users often won't give me information on and that's, hey, it's too slow. It's not performing right. And I need to know it's slowing down because I don't want them going off to Twitter when they're supposed to be using my app. And so they need to tell me it's not fast enough and Sentry does that, right? It puts Sentry in, it gives me all the performance data and I can go, hey, that takes three seconds to load, that's way too long. And I can go in and I can fix those issues and then I'm not losing users to Twitter. So if you have an app that's running slow, if you have an app that's having errors or if you just have an app that you're getting started with and you wanna make sure that it's running properly all the time, then go check it out. They support all major languages and frameworks. They recently added support for Next.js, which is cool. You can go sign up at sentry.io slash sign up. That's easy to remember, right? If you use the promo code JSJABBER, you can get three free months on their base team plan. 

 

NIALL_CROSBY: My name is NIALL. I am the founder of what was a small open source project called AG Grid. So I don't know, I guess a few people in your show might have heard of AG Grid. So should I explain what AG Grid is and where we are now? 

AJ_O’NEAL: I don't know what an AG Grid is. I know it's a grid.

CHARLES MAX_WOOD: I played with it and I'm trying to convince people that work to use it. 

AJ_O’NEAL: So I don't know what a grid is apparently. 

NIALL_CROSBY: Okay. Well, it's your grid to normally use in enterprise applications. So I think you can split JavaScript developers into kind of two different categories. You've got the people who are building enterprise applications, which is building apps to help run businesses. And then you've got people who are building consumer facing web portals and they're a much bigger group. On the consumer-based web portals, you normally don't use data grids. If you want to display data on a web page in tabular format, you'd normally just use HTML table, that's all you need. But if you're building apps for enterprise, then it's very common to have a data grid in your application doing functions. So if you imagine a trader inside a bank, he's looking at loads of stock prices, he wants a very rich experience with his data. And he ideally wants to be able to do the types of things you do in Excel. You want to sort columns, resize them, move them around, do filtering then do pivoting, do regregations, maybe go to a chart, all of that type of stuff. So what AG Grid is, is a library that allows developers to plug in a rich data grid experience into their application. So we're a third party library widget. And I got into this space because I was working for the banks in London for about maybe five or six years. And there was one particular project back in 2014 where the requirements were not, I couldn't build what I wanted to build with the data grids that were available at that time. JavaScript and enterprise was kind of new and the libraries available were still maturing. So out of frustration, and it really was frustration, I was annoyed. I built AG Grid as an open source project one Christmas as a challenge to myself. Two weeks off, I pulled out the laptop and went, hey, how hard could this be? And after two weeks... 

STEVE_EDWARDS: Famous last words, right? 

NIALL_CROSBY: Yeah. And here I am seven years later still trying to get it right. This is hard. But what was interesting though is even within two weeks, I had something which had differentiated itself enough from what was already available, both in the community and in the paid versions as well. 

DAN_SHAPPIR: If I can interject, it's surprising to me because I've been in this field forever. Even before the web, when people were building mostly native, let's say Windows applications and whatnot, I remember seeing ads for grids all over the place. And then when frameworks started to appear in the JavaScript world, I remember seeing like grids for Angular and for other frameworks. So it's kind of surprising to me that you're saying way back when in 2014, but that's not so long ago, these four old timers like me. And...And it seems kind of crazy that we still didn't kind of get it right, that you were in a position where you felt that no grid in the market was actually doing the things that you needed. So what were they missing? 

NIALL_CROSBY: Well, I think if I look back at what was available at the time, so you had Slick Grid, which is probably the most popular data grid back then, and Slick Grid was written in vanilla JS. It wasn't bound to any framework. And in Slick Grid, you couldn't pin columns sometimes called frozen columns, where you just want a column to stick to the left-hand side as you're scrolling right and left. And that's a very basic feature. Slick Grid also couldn't do row grouping if you wanted to drag a column and say group by this row. And that was one of the most popular grids. So from a feature point of view, a lot of the grids would just feature incomplete. And I believe the reason why that is, is because...You have, there was so many data grids out there, especially in the open source where you'd have people who come up and they created data grid and it would solve one problem very well. Everybody would get the row virtualization working, then maybe put in row grouping, but then things would begin to lose quality as they added complexity. 

AJ_O’NEAL: So when you say row virtualization, is that referring to, I literally have 10,000 rows. I can only show 10 on the screen at a time. So you, you give a virtual way to scroll and then it loads data. Is that? Because it's not

NIALL_CROSBY: that's right. Not loaded data, but render the data in the screen. So if you, for example, have 10,000 rows, but about 20 columns, if you try and like to get tables, if you try and render 20,000 rows into the dog with 10 columns using an HTML table, it'll cry. 

CHARLES MAX_WOOD: I've done this. 

NIALL_CROSBY: It'll just, it'll hang. It just hangs. Yeah. Right. But what you can do is load the data from your server and have 10,000 rows in memory and put them into a scrollable viewport. And then as the user scrolling up and down, you just draw the DOM for what the user can actually see. So if you're using divs to create rows, then you've only got 10 divs existing, if you can only see 10 viewports. And then as the user scrolls down, you create more divs and remove the ones that were there previously. 

DAN_SHAPPIR: Doesn't it get you into trouble with the scroll bar? How do you maintain proper sizing for the scroll bar? 

NIALL_CROSBY: Because the container that these rows are in is the correct height. 

DAN_SHAPPIR: Ah, nice. So it's just...Like a huge margin up and down properly calculated in terms of size, something like that? 

NIALL_CROSBY: Yes. Yeah. Yeah. So if you have 10,000 rows and you're 10 pixels high, then your div is 100,000 pixels high. And that gives you the full span of the scroll. 

DAN_SHAPPIR: Cool. 

NIALL_CROSBY: And that's called row virtualization. And I think that's the number one feature that all these data grids have. That's where you jump from a table into what I would consider an enterprise data grid. You have to solve row virtualization. And then we do column virtualization as well. So you've got maximum benefit of keeping the DOM light. So yeah, so back then you had a lot of grids who did those things. And then as they added features, the complexity goes up exponentially. And the reason for that is in a data grid, when you add a feature, it has to work with all the features that came before. So when I implemented the first grid, it did nothing. Then I implemented sorting. That worked. Then I implemented filtering. That needed to work with sorting as well. And then it needed to implement pinned columns, which needed to work at sorting and filtering. Then we went to row grouping that had worked on all those features before. And that complexity of features working together does go up exponentially. And that's why we have seen a lot of grids that start off well, solve specific problems well, but then they struggle to get the complete feature set in to be able to provide for a general purpose data grid. 

DAN_SHAPPIR: I'm curious. You've been doing this for a long time now. What is it, like, seven years? And I'm guessing that the initial architecture that you came up with when you started the whole thing wasn't necessarily what you now, with all your experience, would consider to be the ideal architecture because I'm guessing you learned a lot over those years. So I'm kind of wondering, were there times during this project's lifetime where you basically said, okay, I'm re-architecting this thing, I'm rewriting this thing or did it just evolve over time? I'm curious how you manage this growth and adding all these features and capabilities, which I assume you continue to do. 

NIALL_CROSBY: Yes, it has been what I best describe our engineering cycle. Constantly prototyping and constantly rewriting. I think I've rewritten the core of the grid maybe four times now. And there's lots of other areas we keep rewriting. Also, when this started, it was a small project. And I was honest when I said it was just a pet project. And when it's just a pet project, you just don't have to pick from any rules. So I chose no framework, and I chose no other external libraries. So right from the start, AG Grid has zero dependencies, which is done because I wanted to find out what it would be like for my own personal interests. It now transpires, that was a brilliant idea. And big organizations love the fact that we've got zero dependencies, because if you want to onboard into a large organization. If you have dependencies, they not only have to onboard you, they have to onboard all of your dependencies as well. So it's such a breath of fresh air for them when they see, oh, you've got no dependencies, that makes onboarding you much easier. But having done that, having no libraries, I didn't have an IOC container. I didn't have dependency injection, and that caused issues for me. So the first version of AG Grid, because it didn't have dependency injection, managing references to objects was something that was complex. And I...I went through this journey where I really felt the pain of not having an, so I wouldn't say, IOC container, I mean an inversion of control container. Because I didn't have one of them, I then had to write my own one, which then led to a new version of AG Grid, where it's then built on what started to be AG, we call it AG Stack. So internally in AG Grid, we now have our own IOC container and we have our own component library and rendering engine that AG Grid is built on. And they evolved over time.

DAN_SHAPPIR: I apologize for interrupting. I just think that for our listeners, it might be worthwhile if you could spend a few minutes explaining what inversion of control is. I think that many of our listeners may not be familiar with the term. 

NIALL_CROSBY: Sure. If you're using a framework, you're probably familiar with managing services inside that framework. I know Angular, for example, services where it will allow you to provide a class, and it will instantiate an instance of that class. Then you can inject other services into that class. And then likewise, if you have a component, you can inject services from your application into that component. React and Vue, they all have a similar mechanism of doing it. The purpose that an IOC container provides is, well, it's twofold. The first is the container manages these instances. So if your application requires an instance, then the framework will instantiate the instance for you, and then it will manage providing references to other instances in that instance that just created. If you don't have that, then your application will have to have a boot sequence that you write yourself, whereby you have all these new methods, or sorry, by credit, you have all these new calls where you're creating new instances of all these objects that your application needs. And then you'll have the second step where you start providing references around to all these different objects that need references to each other. And then when you create a component, which wouldn't be a service, then that needs to make it references to all these objects that it needs. So in an application, a typical object would be the user authentication service or the HTTP service or something like that. 

DAN_SHAPPIR: So if I another way to put it, I think, and correct me if I'm if I'm wrong, is that instead of your your code being like the entry point to the system and then as you start up, you attach yourself to vary or import directly import various external libraries and services. Instead, you register your code somewhere. The platform initializes you, and as it initializes you, it passes when it invokes or instantiates your code, it then passes in as parameters the various services that you may need to use. Is that an accurate description? 

NIALL_CROSBY: Exactly. That code you would have to write is what we call boilerplate code, and boilerplate code is bad. And history has taught us that if you can get frameworks to remove the boilerplate code, then that's good. It simplifies your code, and it also forces consistency across your code base. 

DAN_SHAPPIR: And it also reduces coupling, because you're not like importing something from some sort of an explicit path or something with a file name or whatever. Instead, it's being passed in as a parameter. So as long as the API is maintained, you don't really care where the implementation is coming from.

NIALL_CROSBY: Exactly. And that's really the real reason. I was saying there was two reasons why we have IOC containers. The real reason is for testing. So IOC containers is what enables a test library to instantiate an instance of the service you're trying to test. And then it can then inject proxies for the dependencies that that service has so that you can test that service without requiring a full instance of your application and that's what an IFC container is. 

DAN_SHAPPIR: And I totally took you off track, so I hopefully you remember where you were. 

NIALL_CROSBY: Well, where I was was when I wrote the first version of AG Grid, I didn't have any libraries and I still don't have any libraries. So over time, we had to create the libraries that one would be used to if you were using something like Angular or React. But we've kept it completely dependency-free. And well, another reason for that is obviously we're supporting different frameworks. So we support Angular, we support React, we support Vue. And if a Angular person is using AG Grid, they don't want React libraries in their stack. And likewise, if somebody's using React, they don't want to see Vue or Angular. So it was very important for us to keep us as clean as possible and have no dependencies. 

DAN_SHAPPIR: Now you're saying we and us, but a minute ago you were saying I and working over Christmas. So how did it go from being an open source project created by you personally, to talking in the royal we? 

NIALL_CROSBY: Yeah, I kind of skipped a couple of chapters in the story, I guess. So I created this project and I created it for myself. And when I went back to work after Christmas, I wanted to use it in my project, but I didn't want to just give them the project because I wrote it myself. I wanted to keep the IP. And the only way I could think of doing that at the time, then even now I think it was a good choice, was to release the project as open source. And then to make the project look like an open source project for my employer, I then created a website with some documentation. So it looked like a proper bonafide open source project. So then when I came to them and said, look, I've created this data grid, it's open source, it's better than the other options out there, can I use this in our project and work? And they said yes. Over the next while, I was playing two roles, or two hats. During the day, I was developing inside this project for my employer. And then in the evenings and weekends, I was developing at HG Grid. So I was coming up with the requirements during the day. And then in the evenings and weekends programming, like a mad thing, I had to try and get it into work because I had a website and because I was in GitHub. Other people started to take notice and that wasn't part of the plan. And people started sending me messages on GitHub and doing pull requests. And what, what I get up and it took me a few months to get this but my problem wasn't personal. It wasn't just my problem. There was a like a global need for a data grid. The issues and frustrations I had with data grids at the time were shared. Lots of people had those. So I was getting messages saying to you, realize what you've just done. You've just created something that there's a big need for you. You should push this. So on March the 16th, 2015, I wrote a blog and the blog was called Why the World Needed Another AngularJS grid because I was working with Angular at the time. And I wrote the blog and was read. I've, by the way, I've got no social footprint at this point. I'm not a popular speaker at conferences. I don't even have a Twitter account. There's just no social footprint. And I created a blog on Medium and that blog went viral and it was read 6,000 times in the first 24 hours. And from that day onwards, about 500 people a day came to the website. And that's when this thing really started going places. It started basically being a train moving. And from then, there's been this huge story to where we are now, where this train has just gotten faster and faster and faster and bigger and bigger and bigger. By say after the end of that first, of that one year, that was 2015, by the end of 2015 where I was working in my job during the day and doing AG Grid and during the evenings and weekends, I was trying my best to have a relationship with my girlfriend. And it was just too much, something I had to give. I couldn't continue AG Grid and keep everything else in my life going as well. 

STEVE_EDWARDS: So I'm assuming you kept the girlfriend, right? 

NIALL_CROSBY: I kept the girlfriend. I dropped the job. Okay. I quit my job and I went, you know what, I'm going to give this one year. Let's see if I can get to the next year was 2016. I made a promise to myself, if I can, I get to the end of 2016 and not have my bank balance drop. So basically can I pay my mortgage? Go out for go to restaurants once or twice a week and just have a nice normal life. Could it get to that self-sustaining, self-implied thing by the end of that first year? What really happened is by the end of that first year, I released Agie Grid Enterprise, which was the same plus more in terms of features and also came with support and then charged for that. And by the end of the first year, I had two employees. So that only was I cash positive. I was able to hire people and it was the start of a bonafide company. But then go, I'm just going to jump straight to today because there's so many things I could tell you about the last seven years, but just to kind of put it in context of where we are now. So today we've got thousands of customers, about seven, 8,000 customers of our enterprise version. And that's not individual developers. Like if you think of a company in the Fortune 500, that's just one customer out of our seven or 8,000 and about 80% of the Fortune 500 are currently customers of ours at some capacity. I hear somebody. That reminds me.

DAN_SHAPPIR: Yeah, that reminds me of that scene from Lord of the Rings where Legolas kills that elephant and the dwarf tells him that only counts as one. 

CHARLES MAX_WOOD: It's still just one. Yeah. 

DAN_SHAPPIR: So yeah, it's JP Morgan, but it only counts as one. 

NIALL_CROSBY: Yeah, I know. But it is. And then some companies like we've got side deals with Companies like the one you just mentioned, a lot of their finance, if you Google top 10 investment banks globally, half of them, they've basically said we're standardizing an AG grid, which is quite juicy. 

STEVE_EDWARDS: So one thing I'm always curious about when it comes to open source companies is your business model. So if I'm reading on your site, so basically, as I understand it, you basically have your open source versions that are free for anybody to use, and then you have additional versions that have additional functionality and that's where the payment comes in or companies that pay to get that extra functionality and support, I believe, for the use of the grid. 

NIALL_CROSBY: Yeah, that's it exactly. And it's that simple. We don't, we just try and keep it simple. So the community version is proper open source. Anybody can use it. You never need to give us a penny or even tell us that you're using it. And then the enterprise version comes with more features. And if you're using the enterprise version and you pay his money, you get more features and you also get access to our support system. And I think that that works really well for us because the free version that we have still stands up there and is very strong competition against not only the free grids that are out there, but even the enterprise grids. If you think of our competitors, what we give away for free, they're effectively charging for. Where we charge is where we're going above and beyond what data grids are typically doing. So one of the first things we implemented that was above and beyond was pivoting. There's no other general purpose data grid out there that will allow you to pivot the data. There are some specific grids to do pivoting, but then they won't let you do all these other things like sorting and grouping. And that's what a lot of our competitors do. And they have four or five different data grids, like their tree grid, their pivot grid, their Excel grid, and their grouping grid. Whereas we have all the features just in one grid and in it includes pivoting. So it's not a case where we're charging for something that you could get free elsewhere, or even you could pay for elsewhere. We are genuinely doing stuff, which is above and beyond what what everybody else is doing. 

STEVE_EDWARDS: So now I've noticed that you also have, and one thing we haven't talked about a lot is you have a charts library. We have an AG charts community version. As someone who's been living and breathing charts recently, just for my job as a front end developer with a huge set of data, I'm curious, is that something that's also built from the ground up? Are you depending upon anything like a D3 or something like that, or what's involved with your charting library? 

NIALL_CROSBY: That's built from the ground up. That included in my statement up, we have zero dependencies. 

STEVE_EDWARDS: Okay. 

NIALL_CROSBY: It was tempting to use the E3, but we decided not to. That was best for us. 

DAN_SHAPPIR: Out of curiosity, is it built on top of Canvas or SVG? 

NIALL_CROSBY: Yeah. It's built on top of Canvas. 

DAN_SHAPPIR: Oh, Canvas. Okay. Cool. 

NIALL_CROSBY: You'll just get performance issues with SVG. Not for everybody, but you will have a limit to how complex your charts can get. 

DAN_SHAPPIR: Yeah, because it's a model. So yeah, it's not just pixels and you have to keep all that model in memory. So yeah, if the model gets too complex, you're absolutely correct. 

NIALL_CROSBY: All right, what's the charts? One thing I love about our charts is, sorry, this is fresh in my head because I was speaking about where we've gone above and beyond what the competition is doing. I'm very excited about our charts and we give our charting library, our standalone charting library, we give that away for free. And the reason why we do that is we think, well, we're doing a meet too, we're catching up, we're doing a charting library that's just as good, possibly better than everybody else's, but it hasn't you know, exploded onto the scene and done things so, so, so much better. So that's why we give that away for free. But where we have exploded onto the screen, onto the scene and have done something way, way, way better is the integration between the two. If you use AgiGrid Enterprise, you can just select a range of cells, right click and send to chart. And you have an Excel type experience inside your data grid. But I haven't tried any code. He just set a property and on the grid enable charts true. And you have this rich charting experience. If you were to use any other library, you would need to get a grid and a charting library independently, and then write a lot of code to create that application experience. Nobody else is doing integrated charting. And that's why we think that's what should go into our enterprise version, because we've done something which is just truly world first and groundbreaking. 

DAN_SHAPPIR: So basically your kind of litmus test to determine what goes in the free version or the open source version and what goes into the enterprise version is wherever you kind of quote unquote go above and beyond, is that kind of how you make that distinction? 

NIALL_CROSBY: Yes, 100%. And I think that makes sense because if we don't, then open source projects will start doing things that we're trying to charge for. So we try and cover it all. We want to compete in the free grid version and be the best free grid that you can possibly be. And then the enterprise is going above and beyond. I'm sorry, that was a very long winded answer of saying yes especially on a techie broadcast where it was a billion questions that should just pop up and say yes or no. 

DAN_SHAPPIR: No, no, I appreciate the additional information because it's always kind of a challenge whenever you see a company that's based on an open source product or project trying to monetize it. It's always challenging. And also the premium model, obviously. By the way, I work at Wix where we're not open source but we utilize the premium model. And it's always a challenge of where you draw the line. Like where does the free offering end and the paid for service starts? And it's never trivial. So that's one thing. And the other thing is, so many open source projects struggle with successfully monetizing it and guaranteeing a reasonable income, like you said, for the maintainer of the project. So many people are doing this thankless job of essentially propping up our web ecosystem and not really being adequately compensated for it. So it's really cool and amazing that you've been able to so successfully do it. 

NIALL_CROSBY: Yeah, I'd agree. It is difficult and there's also a common expectation amongst developers that things should be free, which is changing and in recent years, we have patron systems in place where people can donate to projects. It is a struggle for open source developers if they're going to rely on donations. Like, let me give you an example of before we started charging for AG Grid. So back in 2015, I had a donate button on my website and over that full year, I got about maybe 10 or 12 donations and in total I made about 500 pounds, British pounds, $800 in donations that year, which is a, you know, it's a nice gesture, but it's not going to pay the rent or it's, yeah, it's, it's, it's nice. It's like a showing the busker trash and make a comparison. Busker is going to say it's like showing the busker 20 quid. Really, you should give him 100 quid or 200 quid. It's going to make a difference to him. So once we went enterprise, on the first day, like I was charging 250 pounds a license when we first launched. And I started selling to maybe a team a day, a four-person team. So right from the start, I was getting about 1,000 pounds a day in from customers, which was more than my entire amount of donations the year before. What I took from that is, like, these are the same people. The people who were buying from me at the early stages were that, it was that community of people who were using AG Grid since its inception and were champions of the project. They loved it. I was doing, and they were listening for the updates and they saw the donate button and they, they mostly just ignored it. But as soon as I had this option for them to buy something from me, lots of them committed to the woodwork and these customers, whenever I knew I had up until then, they were just NPM downloads. And these like banks from all over the world started coming forward and saying, yes, we've been using you for X number of months. We're a fan of yours. We'd love to buy four or 10 licenses. And they would, they would do that. So my taking from it is people are generally not good at taking money out of your back pockets and giving it to you, but they're very good at asking for an invoice and going to their boss and getting an invoice signed off for a much larger amount. So if you are an open source project and you want to monetize, if you can find a way to sell something as opposed to depend on contributions, then people, the community, are better able to respond to that and start giving you money. 

DAN_SHAPPIR: And correct me if I'm wrong, but especially in the enterprise market, I think that a lot of the companies actually prefer to have some sort of an enterprise deal, like some sort of support and then guarantees of updates and stuff like that. It's actually something that they prefer, I think. 

NIALL_CROSBY: Yes, yes. They want longevity of the company. They want to make sure you're in business in five years and they want support. The typical open source life cycle is it's great for a couple of years and then it dies off because the initial creators of the open source project move on in life. They have kids or they move jobs or something like that. One of the first customers I have was one of the first sales that was very, very weird for me. And looking back, so happy that it happened. And I was charging 250 pounds per developer and this gentleman, and he really was a gentleman, said, okay, I've got five developers. So you're going to charge me 1,250 pounds. And I said, yes. And he said, and for that, I can use the grid for a year. And then if I don't want to continue with support, I can, that's all the money I ever need to give you. And I said, yep. And he said, that's not enough. You're not charging me enough. What I'm going to do is I'm going to pay you 10,000 euros and I want you to go and get a proper EULA. the EULA I had wasn't very good. I copied somebody else's and renamed their name with AG Grid. He said, I want you to get a proper YOLO and I want you to start charging more and set up a proper company because we have a huge dependency on AG Grid in our application and we're a proper company as well. And we need to make sure that you stay in business for the next five, 10 years. And you're not going to be able to do that with a smaller metric charging and this one person garage shop that you are right now. And that was...Like it was a strange phone call because I ended up with my salesperson and me had my opening price and he ended up giving me 10 times more. But I learned so much and it really gave me an appreciation for why people want you to be a proper company. They want to pay money because they want you to be around and be a business partner with them for the future. 

DAN_SHAPPIR: Now, if I can ask a bit of a difficult question. Because I assume you as an open source project, you accept, I guess, pull requests, I don't know how often it happens, but I assume you do accept pull requests from people that are working outside your company, at least in theory. Now what happens if somebody comes along and implements in a pull request, one of the features that you're selling is an enterprise feature. 

NIALL_CROSBY: If they implement as a pull request to the open source version, something we have in our enterprise, that has never happened. Actually, the pull requests that we get are very basic. And at the start, there was more pull requests towards the start. And there was a few times where people would implement a feature. But what I found with the pull requests is people writing the pull requests were only catering are looking out for themselves. So they would implement a feature and not fully test it against the complete feature set of the grid but only tested against the features that they were using. And there was one example of this where somebody wanted to have, we call it column groups. I think there's a more common name. Basically, if you want to have two levels of groupings, so you're grouping your columns into more groups. And he implemented a version of this that worked for him, but it just didn't work with lots of other features, like moving columns around. It just completely broke down, because that's not a feature that he wanted. And then also the fact that it didn't work, you're talking about coding styles, the direction of the project. AG Grid is a very complex project, it really, really is complex. And I'm a huge believer in co-located people working together. All the people who work for AG Grid now are in London and the dev team sits together in a room. And even when a new joiner starts in AG Grid, it takes about four to six months to get to know the code base. Having, and with the systems of us sitting beside them, there's a big, steep learning curve and it takes them a long time to get to that level where they can comfortably contribute. So, AG Grid's been at the stage now, and has been for a couple of years, where people just don't do, don't provide pull requests because the project is too complex. What we do get is small bug fixes and they are brilliant. We do genuinely get some small bug fixes. But when you talk about implementing new features, we just don't get those pull requests. If it happened, if somebody did submit a pull request for an enterprise feature, we would obviously reject it because it just breaks our business model. But I've always wondered, what if somebody branched or forked, to beg your pardon, what if somebody forked on GitHub our community version, which they're completely entitled to do, and then started implementing our enterprise features and provide an alternative open source version of AG Grid, which is basically AG Grid enterprise, but developed by somebody else. And that would be easy enough for them to do because maybe I shouldn't be saying this because they don't want to be given one of the developers' ideas. But our enterprise version is also I shouldn't say open source because that's a proper noun that's got a specific definition. The source code is open on our enterprise version. It's on GitHub. So if people want to see how we've implemented the enterprise features, it's all there in GitHub. So it would be easy enough for somebody to copy these features. But that's not happened. And nobody's even tried. 

 

Hey, folks, it's Charles Max Wood. And I just wanted to jump on real quick and let you know that I am putting together a podcasting course. I get asked all the time. I've been coaching people for the last six months. How do you start a podcast? How do you put it together? What do I need in order to get it going, et cetera, et cetera, et cetera. Um, I've put together the curriculum and I did it through coaching a whole bunch of people and now I want to share it with you. You can go check out the course. It's actually going to be a masterclass. It's going to be a four week masterclass, or actually walk you through the entire process of launching a terrific sounding podcast and putting together content that people want to listen to. And you can find it at podcastbootcamp.io. 

 

DAN_SHAPPIR: I think the answer as to why it may not have happened. It has to do with what you said a minute before about how difficult the code base is to get into. I like to say that if anybody ever steals my code, I really hope that whoever that person is also fixes all my bugs. Good luck with that because without somebody explaining the code, code that is supposedly well-documented can be really challenging to get into. And yeah, so, and at the end of the day, for somebody to really take your code and start their own business around it, they would literally need to start their own business around it. And you know, you're already there, you've got the traction with the customers, that your customers trust you, it would just be really difficult to do, I think. 

CHARLES MAX_WOOD: My experience with this is, kind of interesting too, because I have a lot of good friends that work on Canvas LMS, which is made by Instructure here in Utah. It's a learning management system and they open sourced Canvas, which is their, or at least it was their flagship product, right? They had an open source community version like what we're talking about here and they licensed it GPL 3, I think. So that was one way that they avoided some of this was the through the licensing then if somebody came in and tried to re-implement some of the other stuff they have in their hosted version that they own, because obviously they've licensed to themselves as, we'll do whatever we want with it, including commercial, then those contributions would have to be open source. The other thing that was interesting about it though, and this is something that I've seen not just in the programming world, but also in the business world. I...I want something like AG Grid to solve other problems, right? So I'm not invested in creating a better AG Grid. I'm invested in the other stuff that I want to build and I'm hoping the AG Grid will help me get there, you know, if I need this solution like it. So I think that's the other thing to consider is that people are willing to spend the money to not have to put the time in to make AG Grid do more than the community version. Instead they'll just pay you guys and then they'll go solve the world problems that they're trying to solve.

NIALL_CROSBY: Like the cost of AG Grid is tiny compared to a day rate of a developer. So I think at the moment, sorry, I don't think I'm pretty sure, we're between $750 to $1,200 per developer, which is one day, give or take for a development that's in the United States. Like you would spend multiple days trying to add features or just, well, it would take you months just to learn our code base, not mind that features. So it just doesn't make sense for you to invest time when you can just pay with a minimal amount.

DAN_SHAPPIR: Now one of the, actually before that, it just occurred to me a question that I wanted to ask. So a while back we had some guests on the show talking about, from Sentry, talking about how they transitioned their project from JavaScript to TypeScript. Also at Wix, like I said, where I work, we transitioned essentially all of our core projects into TypeScript. I'm curious whether you're using JavaScript or TypeScript in AG Grid. 

NIALL_CROSBY: Definitely TypeScript. Definitely typed. I'm a Java developer, which is not true anymore because I've been doing AG Grid for about seven years. But my background before it, AG Grid is my first JavaScript project. Isn't that mad? I used to be a Java developer when I was working for these banks, and we were using JavaScript and Angular as the front end, which I just barely knew. I saw AG Grid as a good way for me, or I shouldn't call it AG Grid, I taught it a grid path project that was nameless back then would be a good way for me to learn JavaScript because I wanted to get better and learn to dome. 

STEVE_EDWARDS: Well, you know, Java, JavaScript, it's all similar, you know, same name, it's all the same stuff, right? 

DAN_SHAPPIR: Like car and carpet, right? 

NIALL_CROSBY: Yeah. 

STEVE_EDWARDS: I mean, all the recruiters, they understand that because I get emails all the time for Java positions because I do JavaScript. So they must be the same. 

DAN_SHAPPIR: I get the jobs for manual QA. So you're lucky.

NIALL_CROSBY: I actually, one thing that annoys me is nobody tries to get me to do AG Grid jobs. Loads of people in the company, they always, people are trying to poach them. Oh, you've got AG Grid experience, come work for us. But nobody tries to coach me. I would just like, not that I'd go work for somebody, but I would just like to be somebody to come to me with an AG Grid spec and say, come work for us. But anyway, I started the project as plain JavaScript, because it was just a pet project. Why bother with adding to the stack? But after a few months, I really craved for proper typing because there's so many benefits to TypeScript when you're managing a large project. So yeah, as soon as the project, as soon as I couldn't remember the different interfaces and where I wanted code completion and compile time checking, and then I moved to TypeScript at an early stage, within let's say four months into the project lifecycle. 

CHARLES MAX_WOOD: Yeah, I have a funny story about pulling the founder of a project and I can't remember what company it was, but they were pretty embarrassed. So David Heinemeyer Hansen who created Ruby on Rails, he got contacted by a recruiter from one of the companies that was actually sponsoring RailsConf. And they basically said, it looks like you have 10 years of experience in Rails and you're the only one that we can find that matches that qualification. Are you interested in a job? And he sent him a pretty nasty email back because he was the only person with 10 years of experience in Rails because he created it. And anyway, it was just a funny deal.

NIALL_CROSBY: Nasty? Why would you be nasty? I'd love to say, yes, please interview me. Let the interview go and then... 

DAN_SHAPPIR: Your topic with A.G. 

NIALL_CROSBY: Grid is my favorite topic. 

DAN_SHAPPIR: And then you won't pass the interview because some recruiter decides that you're either too old or you just don't know. You don't really know A.G. Grid. 

STEVE_EDWARDS: That's right. Gosh, that reminds me, if you've ever seen the movie Back to School...with Rodney Dazerfield. 

DAN_SHAPPIR: Yeah, I was thinking about exactly that example. 

STEVE_EDWARDS: So there's this, when he first gets to school, he's bribing everybody to do his work for him. So he has to write a paper on Kurt Vonnegut. So he gets Kurt Vonnegut to actually write the paper for him. And when he turns it in, the professor tells him, whoever wrote this paper doesn't know the first thing about Kurt Vonnegut. 

NIALL_CROSBY: Yeah. You know what? One thing I miss is jobs. Because when you're employed, you're always thinking about the next job and your CV and you're learning a new technology and you're thinking about how you would come across in the next job interview trying to explain this technology. But I think I've my experience over the last seven years have basically made myself unemployable from my dream job because I'm now like CEO of this company with 30 people and you know, given technical direction, blah, blah, blah. But I love to program like that. That's just what I really like doing. It's my it's my passion like a lot of developers, but I just can't see myself being accepted as a developer role anymore. 

DAN_SHAPPIR: I don't know. It's an interesting thought, but do you actually get to code? I mean, CEO's job is like a full-time job, I would imagine. 

NIALL_CROSBY: It is. That's why I work 12 hours a day and drink coffee constantly.

DAN_SHAPPIR: Living the healthy lifestyle. 

NIALL_CROSBY: Well, you know what? As the company grew, well, at the start I was doing everything because it was just me. I was doing sales, I was doing marketing, I was doing blogging, I was writing all the code, managing everything. And then it was all about backfilling. It's about finding people to take on specific roles. So getting another developer to help me with development, but then hire somebody to just do sales, hire somebody to just do support. And that grew and grew and grew. And I was always involved in all the different areas because I was so passionate, I guess, about it. I wanted to be involved. Even though I wasn't doing the sales, I wanted to know what was happening and helping people and guiding them. But the company just then got to the stage where there was just too much going on. There was too much, too many people, too many events, too many actions, too many decisions. And that's where I had to just change the dynamics of the company and start putting people responsible for certain areas. So right now I've got a pretty, what I think is the ideal for me. So there's three departments in the company tech and support. And each of those three departments has a department head and they're responsible for running that department. And with those three people, if they have any questions, they'll come to me, but they're running that department on a day to day basis. And one of those departments I said was the technology department. And I've got a guy, brilliant person, Rob Clark, and he's actually head of product development. So he is in charge of the development in AG Grid and I'm in his team. So I'm actually a senior developer reporting into Rob and then I'm also the CEO having Rob and two other guys reporting into me. 

STEVE_EDWARDS: That sounds like a job sandwich. 

NIALL_CROSBY: And, well, it almost like I do what Rob tells me to do until, um, until I don't want to do it and then I pull rank. I'll bring it up at the next board meeting. 

STEVE_EDWARDS: Like Michael Jordan when he was, when he owned and played for the Charlotte Hornets. 

CHARLES MAX_WOOD: Yeah. But you do have specific understandings of which role you're playing and when you're playing it. Cause I've, I've been in the position where you were kind of in three places on the org chart, but nobody told you which, where, when, yeah. 

NIALL_CROSBY: The dynamics between us often Rob is colorful and it is messy, but what gives us direction or keeps us in the right direction is we both understand what the end goal is and we're both working towards the same place. I'm like this project. It's, it's, it's my baby. So It's very difficult to replace my experiences with AG Grid over the last seven years. And it's designed exactly as I would design it, because I did design it. So it's difficult to backfill my role on the Grid. So it's, from say a project point of view, I'm a big asset to the company, being the senior developer on the Grid. But then on top of all that, I have to run the company as well. So we isolate those concerns. And plus, I'm gonna be a developer, because I'm happy being a developer.

DAN_SHAPPIR: So you said that you have like, both of you have the understanding of where you want to be. If I may ask, where is it? Where like, if you're looking forward, like the next seven years, if I may ask? 

NIALL_CROSBY: Yeah, you can ask. And it's a brilliant question. I don't know where we're going. But I said earlier, that's when the train started, that this big train started to moving. And that's where we are. That's what it's really felt like over the last seven years. I'm like holding on to my dear life and this massive system that we've built. When I say system, I mean everything to do with the company, the product, the customers, the marketing, the conferences, the grid, the code. Everything is just working together and moving fast and big. We're just like hanging on for our dear lives. It is a fantastic experience we've been given. But we can give a direction. We can obviously push it in a particular way. But even if we say, you know what, shut down the company, just quit, like you're not saying we're trying to do that, but Age of Grid would still live on. It would still go in a particular direction, still be this common project that that's still being used. So we're not in control. We're not in full control of the direction that AG Grid is going. And something else that I've learned over the last seven years is how difficult writing at the AG Grid is. Like you might think it's difficult, but trust me, it's far more difficult than you think, because I thought it was difficult five years ago. And every year I realized, oh my God, there's just so much more, so much more, so much more. And we had ideas in the past about how we could pivot the business come up with a new project, do this other thing. And we had to just stop thinking about those things because the grid was just taking so much energy. Like even now, seven years later, and I'm very proud of what we've done with the grid, but there's so much more we can do. Like all these feature requests that are coming in from customers. And then plus keeping up to date with the frameworks, like React Hooks came out last year, the year before. And we had to rewrite a very large section of the grid to make it work better, better with React Hooks. So just maintaining the grid and the charts and moving them forward is a massive project and we're not out of the woods yet with them. So I would like to think that in seven years from now, we haven't taken a right off the ball that we've continued to extend the grid and the charts and make them even better than they are today. If I was to think, how's the company going to change what new stuff would come out? I'm afraid to say these things because they may not come true, but we would like to develop out the story of a reporting replacement. Let me say that a bit differently, that doesn't make sense. If you think enterprise, and enterprises, when they build applications, it's common for them to also use reporting tool and provide reports to fit alongside the application. It's also common for somebody using an application to export to Excel and do some fidgeting with the data to prepare a charge or something to put into an email or a presentation. What we would like to do is stop people leaving your application. If somebody exports to Excel and moves to a BI tool, then your application has failed, because you haven't met the user requirements of the user. They're not able to do what they want to do with the data inside your application. So that's why we've headed down towards this kind of business intelligence tool or Excel feel to AG Grid to empower these users to be able to do all of these things. So I would like to think in a few more years, we've made AG Grid so powerful that will be a real bonafide option for our customers to say, you know what, we can stop people exporting to Exelna or we don't need to use these other BI tools because we can do all of this inside of AG Grid. 

DAN_SHAPPIR: Really cool. Now, something that I definitely want to discuss before we finish and you kind of mentioned it is your integration with the various frameworks. From my experience, when you're creating a library or component that you want to integrate into multiple frameworks, there are two main approaches that I've seen. One is to essentially re-implement whatever component it is, you know, obviously try to reuse as much of the logic and the code as possible, but essentially re-implement the tool for the various frameworks. And the other approach is kind of that I've seen is a kind of micro front-end type of an approach where you try to encapsulate the component as much as possible, segregate it from the framework so that it just exposes an API that the framework could use, maybe even going as far as using a web component. And then it kind of behaves like its own HTML element. Where on this spectrum do you fall? 

NIALL_CROSBY: We fall in a third option. So we don't want to write a new product for each framework, because that just completely spreads your effort as a dev team. And then you've got your product, well, it's no longer one product. You've got six products, whatever it is. And as you're spending time in one, you're not spending time in another. And also the products that come out of sync. So you'll have some features in one, but not in another. It's just inevitable that they don't get maintained equally or at the same speed. So we were always an agnostic code base right from the start. So the first approach we went for was wrapping the grid. So we would just put this thin layer over AG grid, which was then an interface into what was expected by the framework. So we'd have an Angular or React component, which would then wrap AG grid. But then we went a step further. What I just described there is common. There's a lot of components out there who will support Angular React and Vue by just having a thin wrapper around them. Where we go further is then we allow you to customize the grid using the framework of your choice. So if you're using, for example, Angular and you're using a G-Grid Angular, you can provide us with a Angular component, which we will then insert into the cells for you so that you can customize the contents of the cell using an Angular component. How we do that, well, what we have to do is engage with an API into Angular which you would typically use if you're just a normal developer where we take control of the instantiation of the Angular components and inject them into the DOM at these positions you're an Angular developer, the grid feels like an Angular grid, and then you can customize it with components written in Angular. So as far as you're concerned, it's Angular from top to bottom. And it's not just a style, so you can customize filters and editors, all those types of things. And we did that with Angular and Vue and React, and it worked very well up until about six months ago, where the problem that that creates is sometimes the developer knows or feels that they're not working with that framework from top to bottom. And that happens a lot in React. And that's because of the way that the React rendering engine is quite different to the other rendering engines. It's got the virtual DOM and the rendering cycle is quite unique to React. And it kind of comes with its own patterns and React developers didn't really like how AG Grid was integrating with React. So we started a project about six months ago that were almost complete. And we separated out the rendering side of the grid to the functional side of the grid, and then allowed the rendering piece to be plugged in with a React rendering piece. So now when you use React for AG Grid, it'll actually do all of the rendering in React all the way down to the component that you provided, being the cell component. So that means on the React side, if you're using AG Grid in React, and you open up the React Developer Tools, you'll be able to see a React component hierarchy all the way down through the grid because it's now a 100% React. So just to recap, then the strategy we went down is for all the frameworks except React, we wrapped a grid. And then we used the frameworks API to manage the component creation for when you customize the grid using the frameworks components. But then for React, it's a complete port of our front end, just a front end, into React. But it uses the front end. About 5% of our code is front end, because I'm talking about low level DOM operations. Set this class, set this width, insert this div, all those low level stuff. The rest, 95% of the code, which isn't interacting with the DOM, that's shared between the React version and the other versions as well. So it regards features. And the features are actually identical between the different versions. 

DAN_SHAPPIR: So you are effectively now maintaining Renders, one implemented in React and the other one that's pure direct door manipulation? 

NIALL_CROSBY: Yes, using our own rendering engine. So it's just the rendering side. We are managing two rendering engines, but most of the grid which both of these rendering engines require is shared code. And it's designed such that it's all based on interfaces and with TypeScript. And if our core part of the grid requires the rendering engine to do something, like for example, a column, and it needs to set the width of a column. It'll be an interface, a TypeScript interface with a method set width. And then if that's not implemented on either of the rendering engines, it won't compile. So in the future, if we introduce a new feature into our core, it'll add whatever it needs onto the interface for the rendering engine to do, which will then force us to implement this feature in both rendering engines, therefore forcing us to keep everything in sync and the feature list, and even the end results, which I think is pretty cool. When I say the end result, the DOM is identical, regardless of using React or one of the other rendering versions. Because if you think about it, frameworks, they all do the exact same thing. They're all just a different way to go about setting the DOM. And at the end of the day, DOM has to be identical, because they're both providing for the same browsers or applying adherent to the same CSS rules. So it's just that mechanism to get what you want into the DOM, which rendering engine are you going to use.

DAN_SHAPPIR: You know, as somebody who's never actually seen your source code, I'm going to presume and make a suggestion just off the cuff for what you could consider maybe is like essentially trying to like unify these two renders into one where in the case of React, you use React, but in the case of not React, you, I know that you like to avoid dependencies, but you introduce a dependency on something really lightweight like Preact or what's that name, Lit HTML or something like that, which has a really similar architecture and a lot of ways to react, and does kind of bring in a dependency, but it's a dependency that you can effectively inline because it's so small. 

NIALL_CROSBY: I think that's what we have done, but that library that you're suggesting is our own rendering engine. 

CHARLES MAX_WOOD: I'm waiting for the Svelte port. 

NIALL_CROSBY: That's one person who's asked for it. If we get lots of requests from our customers, then I'm sure.

CHARLES MAX_WOOD: I'm totally inking your chain. 

DAN_SHAPPIR: Or alternatively, implement it as a web component as well, and then you support any framework that you don't have native support for, they can use it as a web component. 

NIALL_CROSBY: We used to support web components, and then we dropped support for web components. The reason was the community didn't really want it. There was very little uptake on web components. Web components, they don't come with data binding which is a bit of a problem when building a system. But I don't really want to express an opinion on Web Components, although I have one. It's not relevant because we fulfill the desires of our customers. And Web Components were spoken a lot about five years ago, but the uptake just wasn't there. As I said, we provided a Web Component version of AG Grid, but the downloads were dismal. It was like half a percent of our total downloads was Web Components. 

DAN_SHAPPIR: Again, what I've seen with Web Components that they're not used as an architecture so much as that they're used as a solution for specific use cases. So for example, we had a couple of guests on the episode talking about how they used web components to enable micro frontends because they were integrating within the same web application, multiple frameworks, for example, larger enterprise customers that were integrating like, you know, the one company purchases another company or something like that. And then within the same front end, they're actually using multiple frameworks. And then they kind of use web components as a lightweight alternative to iframes in a way, to segregate their code base. So again, I'm not seeing so much the case of, I'm going to write my entire UI using web components. More of what I'm seeing is I have a problem of code, like I need to put two or more bits of code within the same page that don't necessarily play nice with each other. And rather than use iframes, I'm going to segregate between them using web components. Or within my company, SAP, I see a guy from SAP talk about that, about how within their company because they buy companies, they have different parts of the company using different frameworks. They wanted to develop a common library of components that get used everywhere. They basically didn't want to go through the effort that you did. So they just wrapped them as web components and gave them to everybody that way. 

NIALL_CROSBY: Yeah, that makes sense. I think if somebody's needing to do that right now, what they could do is use our vanilla JavaScript version, which is no framework. 

CHARLES MAX_WOOD: I was going to make a joke about jQuery, but I won't. 

NIALL_CROSBY: Go for it. No, you built it up.

CHARLES MAX_WOOD: I was just going to say, your rendering engine should have been built in jQuery. 

NIALL_CROSBY: jQuery was great back then. 

CHARLES MAX_WOOD: Yeah, it was. 

NIALL_CROSBY: Yeah, it really was. 

DAN_SHAPPIR: It's still great. It's just that it's not really needed anymore because the DOM basically got the best features out of jQuery. 

NIALL_CROSBY: Yeah. I was surprised how much the DOM gave you back in 2015 when I started doing AG Grid and I realized, hey, hold on, I don't need jQuery and people I speak to and they hear I'm not using jQuery. They were like amazed that you could get away with not using jQuery. 

CHARLES MAX_WOOD: Yeah, it's because a lot of that is standardized. 

DAN_SHAPPIR: Yeah, and these days it's all Chromium and WebKit anyway, so... 

CAHRLES: Yeah, yeah, even in Edge it's brilliant. Yep, well yeah, the ones that still aren't, they match up with all that specification, so yeah, you're pretty good either way. I'm kind of running up against the deadline myself, so I'm probably going to push this over to Pix, unless there's something really pressing that we haven't covered.

DAN_SHAPPIR: No, I think this was a great conversation. Nile, is there anything you'd like to add that we missed that we should have asked but didn't? 

NIALL_CROSBY: No, there's just so much things we could talk about. There's nothing specific. Yeah, I did find, or maybe I'm just gonna say this again, it was a wee bit dry and I'm afraid maybe we went into the business part of it a bit too much. It was a bit too, it lacked the fun developer chat that developers normally use to, it was a bit serious. 

CHARLES MAX_WOOD: I don't know, I'm interested.

NIALL_CROSBY: Yeah. I'm like, I'm obviously enthusiastic about it all. I hope it didn't come across as like the overenthusiastic, oh, here's this guy talking about how fucking great he is. Oh yeah. Sorry if I, if it was a bit too serious, but no, I think that, 

CHARLES MAX_WOOD: I think that was really good. 

NIALL_CROSBY: If you guys are happy with it, then that's, that's brilliant. And you know, if your users think this is good, then that's, that's all, that's what it's for. 

CHARLES MAX_WOOD: Sounds good. Do you want to just tell people where to get AG Grid? 

NIALL_CROSBY: Can lead that with a question? 

CHARLES MAX_WOOD: Yeah. Do you want to tell people where to get AG Grid?

NIALL_CROSBY: The best thing to do is just go to Google, AG Grid and go onto our website then, ag-grid.com and all the instructions are there. Just some getting started guides and the community version is brilliant. If you just want to just test it, see it, not after it pays any money, then just use the community version. We put so much effort into documentation to try and make it easy for people. I think just go to our website, take it from there. 

CHARLES MAX_WOOD: Awesome. We'll put a link in the show notes too. But yeah, let's go ahead and do some picks.

 

Hey folks, it's Charles Maxwood and I just wanted to jump in here and let you know about something that I'm doing. It's free. It's out there just to help you get answers to your questions about the things that you're running into with your career. So if you have questions about how to get further ahead in your career, how to start a podcast, how to get a better job, how to get a raise, how to deal with the situation at work with your boss, or just maybe you're stuck and you don't know where to go next. You know, how do I get from junior to senior, senior to whatever's next. How do I become a speaker? How do I get to the next level? That's what I'm out here to do. So every Wednesday at 12 o'clock mountain time, I'm gonna be doing a call and it's gonna be free, totally free. Go to devchat.tv slash level up and you can register for the call. It's using Zoom's webinar software. So it's pretty straightforward. And what we're gonna be doing is I'll do 10 minutes and I'll just show you how I do some form of how I level up. And then we'll just answer questions. And it's not gonna be a question and answer like, hey, what's your favorite flavor of ice cream? And then I say, rocky road or whatever, right? Instead, what we're looking for is more along the lines of, yeah, I have the situation, how do I handle it? I'm trying to figure this thing out, how do I figure it out? I'm trying to stay current, how do I stay current? And if you have any of those kinds of questions, I'll bring you on the call. We'll ask some deeper questions. We'll make sure we get you a solid answer. And I'm really looking forward to helping some people out. There will be no sales, no selling, no nothing on these calls. It is literally just 10 minutes of training and then Q and a, so you can go check it out at devchat.tv slash level up. 

 

CHARLES MAX_WOOD: AJ, do you want to start us off with the picks? 

AJ_O’NEAL: No, no, not today, actually. 

CHARLES MAX_WOOD: All right, Steve, you want to start us off with picks? 

STEVE_EDWARDS: Wow. I figured I had another 10 minutes to get mine ready since AJ was doing his, but I'll have to jump right in. So I'll start with, you know, the usual high point of the podcast is my list of dad jokes. So to start out, do you know what you call someone who tells a dad joke that isn't a dad? A faux pas. Get it? Anyway, I won't explain it. 

AJ_O’NEAL: I got it. I liked it. 

STEVE_EDWARDS: So the other day I was attacked by...A flock of sheep believe it or not sheep aren't always docile sometimes they'll attack you but fortunately I was only grazed and then and then finally, you know, I used to you know before I I Met and married my wife. I dated this one girl who was cross-eyed but it didn't last very long because we couldn't see eye to eye and plus I think she was seeing somebody on the side. I will give an attribution to that one. 

DAN_SHAPPIR: Not only do you get to get this one time, we have to deal with it on every episode. 

NIALL_CROSBY: I was saying, is this part of the podcast still or are we just hanging out? 

CHARLES MAX_WOOD: Oh, absolutely. It's part of the podcast, yeah. 

STEVE_EDWARDS: My jokes are the high point of any podcast. I will give proper attribution to that one. I got that one from Dwayne Johnson in Jungle Cruise. That's not one of the jokes that is in the clip that you see on YouTube. So my daughter and I went and saw that and I was laughing out loud in the theater and she was telling me to be quiet. Spoiler. Anyway, those are my picks. 

NIALL_CROSBY: That actually reminds me of this time, myself and my wife were in New York and we were staying in a hotel and there was this spider in the bathtub and my wife said, don't kill it, don't kill it, take it out, take it out. So I took it out for a pint. 

STEVE_EDWARDS: So good. Oh, thank you. 

NIALL_CROSBY: And he's actually a nice guy. His name is Ed. I asked him, what did he want to be in life? He said he wanted to be a web developer. 

STEVE_EDWARDS: Yes, yes. I've heard those. They're so good.

NIALL_CROSBY: And then we went to look for a bar, but all we could find was this NoSQL bar, which is pretty crap because it didn't have any tables. So then we found this other bar that was kind of better. It was a proper relational database bar. So we went up to two tables and said, can we join you? So I realized I wanted to shut up now. 

STEVE_EDWARDS: No, no, no, that's great. That's a chain of... Oh, that's so good. It kind of went...Keep going. 

DAN_SHAPPIR: It kind of reminded me of that story about the QA person that walks into a bar, orders a beer, orders two beers, orders zero beers, orders a million beers, orders a lizard, orders a book. And then the first customer, real customer walks in, asks where the bathroom is and the bar explodes killing everybody. 

AJ_O’NEAL: I've heard that one. I like that one a lot.

STEVE_EDWARDS: Oh, that's so good to be the starting point for so much great humor. I love it. 

CHARLES MAX_WOOD: Yeah. All right, Dan, what are your picks? 

DAN_SHAPPIR: Okay. So I actually have two picks for us today. The first one is our good friend, Carl Simpson is finally continuing his work on the second edition of you don't know JS yet, and he's got a Kickstarter going for it. So that's one worthwhile Kickstarter if there ever was. I'm donating to it and so should you. So I'm putting the link for that in the show note. For those of you who don't know, then you don't know, that you don't know JS yet series, the second edition. Kyle is like the best, from my perspective, best JavaScript teacher out there. Nobody knows JavaScript like Kyle knows JavaScript. And if you really want to understand the language, not the specific framework or or the DOM or whatever, but JavaScript or language, then I can't recommend any other resource more than Kyle's books. So that would be my first pick. 

CHARLES MAX_WOOD: Yeah, you don't know JS yet, go get the books. 

DAN_SHAPPIR: Exactly. Listen to this podcast and get the books. And my second pick is we're watching this series on a Netflix called, well, it's not on Netflix. It's not actually on HBO Max. It's called the White Lotus. It's kind of strange, it's kind of out there. If you would ask me to tell you exactly what it's about, then it's like entitled rich people live with really problematic personalities, staying in this fancy hotel, being served by the staff who are really poor people, but with really problematic personalities as well. But it's somehow totally addicting. It's kind of off the wall strange, but we're enjoying it a lot and I highly recommend watching it. And those would be my picks for today. 

CHARLES MAX_WOOD: All right. AJ, you have some picks? 

AJ_O’NEAL: Oh yeah, I do. I'm ready now. I'm ready. So first off, I've talked about how you can do type linting with JavaScript, but I hadn't actually done it myself. And I found that all the articles that were out there were a little too trivial in terms of, they're kind of like, here's how you work in a single file with a single object of its type. But then as soon as you go into a real project, it's much more complex than that because you have to modify the type of, say for example, Express, so that you can add your own custom properties onto the rec objects as middleware does and whatnot. Anyway, so I got together a JS doc typescript starter repo that if you're interested in doing type linting in JavaScript is a good resource and there's an issue with a link to other resources that I pulled from, but I would say that this is more complete than the read me here is probably more complete and valuable than the other articles and resources just from the perspective that they're either out of date or only had a couple of pieces each. But I'm enjoying doing JavaScript with type linting does help to find errors. I'm still kind of trying to figure out what the best pattern for it is and where to make the concessions because typing everything is kind of obnoxious, especially if you're, because I think if somebody who loved JavaScript had created a typed version of JavaScript, it would look a lot like Go. Instead, we had people that love C Sharp develop a type system for JavaScript and well, you've got TypeScript, but I mean, it's just, it's not, it's not idiomatic to JavaScript at all. TypeScript is not, it's, it's not even just shoehorned. It's a completely different language. Doing this, I grew in my distaste of TypeScript because all of the complexity and the inheritances and the, it's just Go and JavaScript have never seemed so similar to me, but I realized that they actually are because they're so lightweight and so simple to manipulate and use anyway. So there's that. Also I I'm going to throw in a couple of other cool things. I've mentioned the Zen of Python and the Go Proverbs many times. I actually now have links to the Zen of Python printable poster and the Go Proverbs printable poster if you would like those. I've got AJAquery. For those of you that are still on JQuery and really looking to level up, I recommend you check out AJAquery. It's probably the best JQuery alternative with full DOM compatibility. And other than that, if you're interested in following me the live streams or the little snippets of code teaching that I do. You can do that beyond code. I've got links to Facebook, YouTube, and Twitter. Oh, and one other thing I threw in, I got a nice small Docker image for Node for deploying Node apps. If you're interested in seeing a template for that. So yeah, that's it. 

CHARLES MAX_WOOD: Awesome. Well, I'm going to throw in a few picks of my own. I'll make it quick. The first one is I finished listening to Ready Player 2, which is the sequel to Ready Player 1. Not nearly as good. I enjoyed it. Right. So I'm going to pick it, but ready player one was way better, way better. There were just some, I think some of the pop culture references from the eighties that he made in ready player to just weren't, they didn't appeal to me as much, I guess. And then yeah, there were just, there was some social commentary in there that I just felt like didn't need to be in it, but cool story. I think the other thing is, is I don't think he took his advantage of the interesting bits of the characters that were there that that he could have he could have fleshed that out a little bit more. But I did enjoy it, even if I'm critiquing it. So ready player two. Right now I'm listening to Masters of Doom, which is kind of a what it's not a documentary by biography somewhere in the middle of it's by David Kushner. And he talks about the story of the guys that created doom. And anyway, really, really enjoying that. Incidentally, both books are narrated by Will Wheaton. So I'm still on the same narrator but enjoying those books. And then I just want to shout out if you want to launch a podcast in four weeks, that sounds great. You got some idea. You want to build your brand, build up a freelancing practice, support some product you're working on. I'm putting together Podcast Bootcamp and you can get that at podcastbootcamp.io. And yeah, I'll walk you through a four-week program, get your podcast launched, make you sound terrific. And yeah, it'll, you know, it's going to have the video walkthroughs and guides and worksheets and all that stuff. But you also get group coaching from me. You'll have access to me through the Discord setup. And so I'll be answering those questions on a day to day basis. And I'm running it starting the middle of September. So what that kind of puts you into is a cohort with other people. So you'll, if somebody asks a question you didn't think of, you know, you get the answer. So that all works out. It's going to be awesome. And that's a podcastbootcamp.io. And then one last thing, I'm getting ready to launch this and it's JavaScript picks, JavaScriptpicks.com. Essentially it's a directory, podcasts, videos, courses, tools. So I would assume that there's gonna be a tools or library section for grids and it'll have AG grid in it, for example. So if you're looking for a resource for your web development, it'll list out NPM packages, it'll list out libraries and list out tools and you know so whatever you're trying to do and it'll also have resources listed in there if you're trying to extend your learning journey. So those are my picks. Niall what are your picks? 

NIALL_CROSBY: I wasn't expecting you to ask me. I told my jokes. Where's my picks? 

CHARLES MAX_WOOD: Awesome. 

NIALL_CROSBY: I'll give you a little fact I learned about an hour ago from my wife. We're moving back to Ireland, moving back to Dublin next month. We're about four weeks currently living in London and moving back to Dublin and the moving company said that there's a huge exit is happening right now out of the UK that business for them they've they normally move people in both directions from Ireland to the UK but right now there's a big move of people from the UK back to Ireland and a lot of families which doesn't normally happen so I guess with them Brexit or whatever else there's a big shift of them of people just leaving the UK because you're not happy without that same shift of people coming back in I don't know if that's what I was meant to be speaking about, but that's been resonating with in my head for the last hour. 

CHARLES MAX_WOOD: Interesting. 

STEVE_EDWARDS: I mean, UK has pretty onerous business taxes too, doesn't they have a data factor? 

NIALL_CROSBY: Um, it's a business tax is low, it's high. It's, um, well, about 20% in Ireland is low. It's about 12%. But the company is staying here. I'm not moving the company, just myself. Interesting. Well, definitely good luck with that. 

CHARLES MAX_WOOD: Hopefully, uh, that all works out the way you want it to.If people want to connect with you online, where do they find you? I'm assuming Twitter, GitHub, places like that. 

NIALL_CROSBY: The best thing to do is go to the AG Grid account on Twitter, ag-grid. That's effectively my profile. Or if you want to get in direct contact, do info at ag-grid.com is the email address. And it's just asked to be passed on to me. 

CHARLES MAX_WOOD: Cool. All right. Well, thanks for coming, Niall. This was a lot of fun. 

NIALL_CROSBY: Excellent, guys. It was a pleasure. Thank you very much. Good to meet you all. And it was great. I enjoyed myself. 

CHARLES MAX_WOOD: Yeah. All right. Well, we'll wrap it up here. And until next time, folks, Max out.

STEVE_EDWARDS: Adios! 

DAN_SHAPPIR: Bye! 

AJ_O’NEAL: Adios!

 

Album Art
AgGrid: From Open Source to Successful Business ft. Niall Crosby - JSJ 504
0:00
1:15:30
Playback Speed: