The panel is joined by Travis Tidwell, co-founder and CTO of Form.io, a ME*N stack platform that incorprates a form builder with automatically generated REST API endpoints. Travis discusses the history of Form.io, how it’s built and works, and lays the smackdown on panelist and noted NoSQL database skeptic AJ O’Neal by showing how MongoDB is the appropriate DB for storing form data in JSON format.

Follow JavaScript Jabber on Twitter > @JSJabber

Special Guest: Travis Tidwell.

STEVE_EDWARDS: Hello everybody and welcome again to another episode of JavaScript Jabber. I am your host, Steve Edwards from a pretty clear blue sky here in Portland today. With me on the panel we have Amy Knight. 

AIMEE_KNIGHT: Hey from Nashville. It's kind of a sad Nashville right now, but getting better. Double, double hit and then COVID and yeah, so bad storms on Sunday. A lot of the city's without power and food.

STEVE_EDWARDS: Was it like tornadoes or just thunderstorms? 

AIMEE_KNIGHT: Bad thunderstorms, but like the worst outage on record and they can't send help because of COVID. So if you know anybody in Nashville, check in on them, check in on people who don't have enough, you know, may not have enough money to put food on their plate because all the food has to be thrown away. So not to be sad, but definitely check in on people here. 

STEVE_EDWARDS: Good reminder. And AJ and Neil. 

AJ_O’NEAL: Yo, yo, yo, I'm coming at you live. I feel like maybe my tune's a little too upbeat after the last intro, never mind. Yeah, it's all good. 

STEVE_EDWARDS: Okay, and our guest today is Travis Tidwell from Form.io. Travis, how you doing? 

TRAVIS_TIDWELL: I'm good, Steve, how are you? 

STEVE_EDWARDS: Good. 

TRAVIS_TIDWELL: Coming live from Dallas, Texas. I think we got the edge of that storm that hit Nashville, but it was nothing compared to what Nashville did. 

AIMEE_KNIGHT: Oh man. Yeah, it's one of those, I don't know, okay, we'll get to the text up afterwards, but yeah, I don't know, it just like makes me worried about hurricane season and everything going on. So just take care of people that...You know, you don't think about the normal stuff and everything shut down. Like people don't have a place to go to work and stuff like that because everything's closed. If they lose electricity, internet, what not. 

STEVE_EDWARDS: Oh yeah, that could be a problem. 

 

If you're a front end developer looking for remote work, then I recommend G2i, a React and React Native focused hiring platform that will connect you directly with their clients that need your skill set. What makes G2i a unique hiring experience is that they spend the time marketing you to their clients of your choice. G2i is a team of engineers that technically vets you upfront. If you pass their vetting, their clients have agreed to skip their initial interview process, saving you time and energy getting your next gig. They take care of all the hard work for you so you can get focused on development. To join G2I, go to g2i.co and apply. 

 

STEVE_EDWARDS: So anyway, the reason I had Travis on, he's one of the founders of a company called Form.io, and this is a platform that I've mentioned multiple times in the past on the podcast. And we've actually had Travis on a few years ago. It was, I forgot, I was gonna look it up and I totally forgot I'll have to look it up but I'll put it in the photos. 

TRAVIS_TIDWELL: I'm wanting to say it was probably two years ago. 

STEVE_EDWARDS: Yeah, something like that. Different panel back then. And a lot has changed over the years in terms of the platform and what they're doing and some of the neat things that they're doing and who they're doing it for. So I thought we'd have Travis on again to talk about that. So for starters, why don't you give us a little background about yourself, Travis, why you're famous, what you do, who you do it for, and so on. 

TRAVIS_TIDWELL: Yeah. So thanks, Steve. So again, my name is Travis Tidwell. I've been really developing software off and on for probably the better part of 20 years. I started, obviously, like most people, I started when I was a kid, in a teenager, and then get into college and was just writing software for fun. I actually got my start writing embedded software embedded software for fish finders. So they're in Tulsa, a fish finder company. From that point, I was just dabbling in web-based software. Of course, at that time it was a CMS platform called Drupal, which is actually how I met you, Steve, through the Drupal community. 

STEVE_EDWARDS: Saw you two different Drupal cons and came up to you and said, hey, can I, you help me with this. 

TRAVIS_TIDWELL: And you said, you came up to me at Drupal, calling like, Hey, can you help me with for my own? So that's really kind of where I got my start just right, just doing just a websites on the side, just kind of for fun. I started just doing just like a little bit of a gig where I was building software, building websites for other people. And that's kind of how most people get their start in web development. So all this time I was writing embedded software for John Deere. And then at that point, I just decided to take the dive and start at full-time. I joined a startup here in Dallas. That's what actually got me to Dallas. And then at that point, I really was diving into Drupal full time at that point. Through that process really started to identify a lot of problems with Drupal, or problems with server-rendered applications in general. And I think that's probably the best way to describe on this. These are applications that use the server to render applications. And so like Drupal is a good example of that WordPress. There's a lot of the legacy data systems like Java,.NET, all of these systems use the server to effectively render the app. So through that exploration, I started to really kind of investigate more client-side technologies. And that really started to get me into Jekyll. I was really into static site generators for a while. And then at that point, I started to move into Angular and really investigating some of the problems with client side technologies, like how do you build very complex data systems using non-server rendered technology stacks, which at that time in the AngularJS when it first came out, it was really complicated to create data-driven, especially form-based data-driven applications in that technology. And so that's really kind of the origin story of Form.io is I started to explore creating JSON-powered forms using a JavaScript renderer that would actually render the forms. At that time, there was also some competing technologies. There was like Formly, I think was a really popular one in Angular. So effectively, 

AIMEE_KNIGHT: it's like a trip down memory lane. 

TRAVIS_TIDWELL: I know. Yeah. So there were a lot of different, and also JSON Schema was another library that was being used at the time. But every single one of those libraries were just client-based. They were just rendering forms with JSON in the client. And what I was more interested in is doing the complete package, which was not only rendering the forms with the JSON in the client, but taking that very same JSON schema that you use to render the forms and use that JSON schema to automatically generate the REST APIs on the backend for the submission data. And so that concept, which is really kind of the origin and also the differentiation of Form IO versus other form platforms, is that it really does use JSON schemas as its way of creating model-driven forms in the client and then model-driven APIs. And then of course, from what I hear AJ, your favorite, model-driven databases to store all of the data in the backend. I was given a little notice that you have some things to say about model-driven databases. 

AJ_O’NEAL: I've never even heard that term before in my life. 

STEVE_EDWARDS: Well, MongoDB, document databases. 

AIMEE_KNIGHT: I haven't heard it, I haven't heard that before either. Can you explain kind of, I mean, it makes a little bit of sense in my head, but.

TRAVIS_TIDWELL: The only reason why I use the term model-driven databases is because effectively what you're doing with JSON schemas, JSON is a form of modeling. It's a data modeling. It's a construct to model data. And so there's this term called model-driven forms. In fact, there's a common model-driven forms, which is taking models and actually generating forms from that combine MongoDB with other types of libraries like Mongoose. Mongoose where you're actually creating these models and model definitions. Those model definitions actually determine how the data is gonna be stored within the NoSQL database. In my opinion, if you combine those two things together, it kind of gets around some of the negatives that a lot of people have against NoSQL databases, which is that it's free form. You can just stuff whatever you want in it. If you actually attach a model system on top of it, it actually becomes very powerful. So the reason why I call it a model-driven database is really probably more in terms of attaching a model-driven system on top of the database itself, which is effectively what Formio is doing. We are taking these form schemas and using those as the model. And then those models then determine how the data is stored. So you actually have deterministic data capture in your Mongo database because in what makes it deterministic is you can actually, you look at the form schema to determine how the data is supposed to be stored and it actually controls how the data is gonna flow into the database. In my opinion, that gets rid of a lot of the drawbacks for NoSQL. 

STEVE_EDWARDS: Now Travis, I know the first time I had the two data Drupal cons that I saw you at, you were bringing that into Drupal. You had some sort of modules that you could use JSON to render forms in Drupal, am I correct? 

TRAVIS_TIDWELL: Yeah. I would actually say that that was a, it was a little bit premature at the time of what we were trying to do with, with Drupal. I don't want to say that Drupal wasn't ready because Drupal's Drupal has been trying to solve this segregation of client and server for a long time now. I don't think that our platform was ready and we were still very much anchored to AngularJS at that time, very anchored to AngularJS. And it was really hard to detach our technology from AngularJS. If you remember, you were actually working with it. 

STEVE_EDWARDS: Yep. I remember.

TRAVIS_TIDWELL: And so the problem was not really necessarily that Drupal was not ready for JSON powered forms. It was that Drupal was really hard to work with Angular. In fact, I did a lot of talks on how to get Drupal to work with Angular. And really at that time, the best way to do it was to create these APIs using the services module. But the problem with the services module is it kind of creates this side technology. It wasn't the main data, uh, data mechanism of getting data into Drupal. And so you had this dual maintenance where I not only had to maintain my APIs, but also had to maintain the main node system. And so it just, it became really almost a maintenance nightmare. 

STEVE_EDWARDS: So I remember that was what struck me. I never could quite get my head around. I understood how you would use the JSON to render the forms. I made sense, but getting all that stuff from the backend and how you stored on that was one thing I never quite got my head around.

TRAVIS_TIDWELL: Yeah. And also we also ran into the problems with relational databases, especially with dynamic forms. A lot of people, whenever they're dealing with dynamic forms, you know, you don't really run into problems with relational databases until you start trying to do dynamic forms because what ends up happening in the web form module in Drupal had this issue, which was to do dynamic forms, you have to do table joins in order to do it. You have to have like a, like a component table and then you have to do a bunch of joins to basically create the dynamic form system within a SQL relational database. And you end up running into join limits, at least in the web form module you did. You had a 255 field limit on these forms. And so now what we were doing is we were taking this very dynamic JSON form renderer and trying to stuff that data into a relational database. And we were basically falling to the least common denominator at that point. And it wasn't becoming. It really just didn't take hold to be honest with you. There was a number of issues of trying to get that system to work with Drupal. 

STEVE_EDWARDS: Yeah. And that, that makes sense why you'd have to have your own platform that incorporates everything top to bottom, just because of the schema list structure. 

TRAVIS_TIDWELL: Yep. Uh, and also the, you know, we, we deal with big enterprise forms, you know, with FormIO and these are forms that have thousands of fields in them. Um, and really in, in a lot of, a lot of the naysayers for FormIO, in fact, I've talked to a lot of people are like, you know, why do we even need a tool like Form.io. These are people that are usually dealing with like contact forms or you know like simple forms in an application. And in that case, I said don't use Form.io that's overkill. The people that really get their benefit out of Form.io are the people that are dealing with extremely complex conditional logic field forms that basically build themselves dynamically as the user is using the form. That's like a good example, but that could potentially have thousands of fields in it. The other thing that we're seeing is the requirement to detach form management from the software release cycles. So we're dealing with companies where they basically are encumbered with form changes as like all of their software developers, that's all they do is form changes and they hate it and they would rather be building their applications. And so FormIO allows them to effectively detach it. They can hand off the form building and form management to a team of non-developers. And then they just use these embed codes in their app to release the software that way. And then they can wipe their hands clean of it. They don't have to manage it. So there's a lot of benefits that you can get out of the JSON model-driven form. What drove this conversation was talking about model-driven stuff. Model-driven forms is really powerful when you wanna do those types of things. 

STEVE_EDWARDS: Sure. All right, so we've sort of got the overview. Let's talk specifically about the tech stack that you use. And in particular, what you started out with in terms of the renders down to a specific library and how it's evolved to the more generic render that you use and then just sit whatever you need on top of it 

TRAVIS_TIDWELL: Yeah, I mean we've we've evolved quite significantly over the years on technology stacks I would say it in it's going to almost going to be hard for me to kind of even remember some of the tech stacks that we used back then. I mean it was only five years ago That's what's that's what's remarkable about it seems like forever ago, but it was really just five years ago that we started. And at that time we were basically doing our entire rendering and building was an AngularJS. So we were, we were 100% AngularJS based. ReactJS was around at that time, but it was not yet really taking hold. I mean, it was kind of taking hold at that time, but it was not yet apparent that it was going to be the incumbent. Whereas AngularJS at that time was it, like everyone was building AngularJS. And at that time it was also mean like that that acronym, the mean stack. So it was Mongo, Angular, so Express, that's right. So ExpressJS, Angular, and Node on the back end. In fact, I did a lot of YouTube videos. In fact, I have a couple of very popular YouTube videos of how to build these mean applications. I've done a lot of talks around the country where I'm like, you know, presenting about mean development. And so we really started with that technology stack. There were a lot of other technologies that we used on the front end to kind of help us compile the applications. So like at that time it was all bower. Really, you know, there was really no web pack at that time. I think there was web pack, but, you know, it was not yet popular. So it was all bower to basically use to install your dependencies. Nobody was using NPM to install front-end dependencies at that time. In fact, it was unheard of to use NPM on the front end. And so Bower was basically what we used. We used, and even at that time it wasn't Gulp, it was Grunt. So we used Grunt to compile these applications. We used a technology called Wire Depth, if any of you guys remember that. So, I mean, just remembering how we used to do it is almost embarrassing where what Wire Depth used to do was look at all of the script tags and it would like create a bundle from the script tags inside of your HTML file. And so it would basically, wire up all those dependencies and try to create a compilation of it. So we use that as well to kind of create these apps. Obviously, Node.js at that time, I think it was 0.12 Node.js. It wasn't even the major versions yet. This was before that whole, you know, that whole charade where it forked as IO.js for a while and the community fractured. Like we did all of this before that happened. 

AJ_O’NEAL: That was before NPM was even officially included.

TRAVIS_TIDWELL: Yeah, well, yes. Yeah. NPM had to be installed separately. And because it was 0.12 was the first release of Node that we released FormIO on. And so this was not even a major version of Node that would, of course, for those who have been developing Node for a while, remember, 0.8 was considered prod ready. I mean, people were building production apps on, you know, a, basically a patch release of Node. And I think Ryan was pretty strict as far as when he considered it stable. And that was part of what caused it to fracture if you remember. There were people who were like, you know, we need to release this as, put this on a different release cycle and we need to release more often. And Ryan was like, no, we can't do that. And so they created IOJS and started creating version one, version two, version three, and finally the node community came to its senses and they all merged back together again. So I'm glad that they did. So that was the technology that we started with. Since then, if you actually look at our technology now, of course we've evolved quite a bit. We've tried out, tried new technologies that have come and gone. The biggest, probably the biggest change for us as a company was this requirement to support more than one framework. So Angular at that time was it for us. Very shortly after that was React. And at that time we were like, okay, how do we support React? Well, we write a new renderer and we basically rebuilt our Angular renderer in React. And as you can tell, that caused a major problem because now if you wanted to include a feature, a new feature in our renderer, we now had to introduce it in two different renderers. We had to introduce it in Angular, we had to introduce it in React, and then at this time, Vue was starting to come up, which is Steve's favorite, Vue. And so really, Vue was the catalyst for us to say we need to do something different. Actually, no, it was Angular 2, whenever Angular 2 came around, that should have just been called something completely different because they flat out refactored and rewrote it. That made us realize that we needed a new strategy. So we actually basically refactored our renderer to be just vanilla JS. We wrote it in ECMAScript 6, ES6. We basically built, at that time we were using Webpack to compile it, to create like this like a JavaScript renderer. And that JavaScript renderer became our what we call the core render. So anytime you hear me call it, say core render, it's basically a vanilla JS render. And all this thing does is it takes JSON and renders forms. That's basically it. You hand it JSON and it spits out a form in a DOM for you. 

STEVE_EDWARDS: Now that's the formio.js repo, right? 

TRAVIS_TIDWELL: Yeah, so you can actually, it's open source. So everything I'm talking about is open source. You can go to github.com forward slash formio forward slash formiojs to see this library I'm talking about. And it is all JavaScript and we've talked about changing it to TypeScript, but that's going to be later in the future. But as of right now, it's ECMAScript 6. We use inheritance to create like almost a virtual DOM of forms in this renderer. And what we've done is we basically have created wrappers in Angular. So there is an Angular Formio, which is basically a wrapper around FormioJS. There's a React, which is a wrapper around Formio.js. And then there's a Vue. We also have Vue, which is a wrapper. Heck, we even created an Aurelia, if you believe it. Aurelia, yes, that's still around. We have an Aurelia wrapper. And then Angular Material. And of course, the other things that are coming up now are to create the, I almost call them super frameworks like Material, Angular Material, React Material. We have one in Angular Material, but we were thinking about creating one in React Material. Those are actually more complicated because those bring with it their own view processor. And so we have to kind of figure out how to retrofit the view processor to our core renderer, which we figured out in Angular material, but we have to do that for the others as well. So that's a very long-winded explanation of the technologies we're using today. On the back end, it's actually very similar. We're actually still Node.js. We've just been, we're up to Node 12 at this point. We have incorporated Docker. Docker allows us to deploy our platform to our customers. That's probably one of our biggest selling points as a company, is you can take our entire API engine and deploy it in your own environment and hook it up to your own database. This allows you to control your data and control everything. It also allows us to work with companies that are very strict GDPR, HIPAA compliance. We do a lot of government work and they basically control everything and we are not, it's not under our jurisdiction. So that's been a great thing for us is to use Docker as our mechanism for deployments. And so that's it, that's our technology stack today. 

STEVE_EDWARDS: So then the other thing I guess we could mention is the starter kits for the applications, which is what I'm working on from the vue side. So basically you take the React formula, the view formula, the angular formula, and that gives you a renderer, and then you can create a starter kit for an app built in React or vue fire it up, you've got everything built in. I know one of the things I'm working with Randall on the vue starter kit is doing like a CLI command where you can say, okay, create this and it creates your resource for you and allows someone to get up and going really pretty easily once you create your project on FormIO. 

TRAVIS_TIDWELL: Yeah, and that's that in a lot of the starter kits really, and what makes those important is it's actually somewhat complicated to digest what you can do with FormIO when you first look at it. A lot of people whenever they see Form.io, they just think Form.io is forms. And they're like, okay, I'm going to build my own application. And just whenever I run into a form, I'm going to use Form.io. A lot of people don't realize you can build an entire data-driven application with using nothing but Form.io as your backend. It really is in that case, a lot similar, a lot more similar to like something like Firebase. This allows you to effectively use forms to create resources. Now resources are just really just data constructs data modeling using forms. So you can create like an, if you're building like a, an HR application, you would build an employee resource, which is by just dragging and dropping text fields to create the first name, last name, email. And you save that. And then that creates an endpoint called employee that you can now do posts requests to submit the data to effectively create new employee records. You can also create complex relationships, like one to many relationships and many to many relationships. So it's a complete API solution where the starter kits become helpful is to really allow people to get going really quickly, building complex data-driven applications, progressive web applications that utilize these type of resource structures inside of FormIO. So yeah, those are really important. Unfortunately, like with Vue, It's kind of interesting. We've actually seen a lot of from enterprises. We deal primarily with enterprises and big governments. We've seen a lot of enterprises use Angular and React. We have not seen many, much adoption from the enterprise in vue yet. We've seen a little bit, but not much. I have a hunch on why that is. I think it has more to do with a company backing. I think enterprises like the fact that Angular is backed by Google and that React is backed by Facebook. 

AJ_O’NEAL: Oh, that made me kind of scared. I mean, 

STEVE_EDWARDS: I know I'm the same way. 

AJ_O’NEAL: Ten products in Google has kept alive for more than two years. 

TRAVIS_TIDWELL: That's true. But I can't quite put my finger on why we're not seeing more of you because Vue is such a beautiful framework, but we're not seeing it in the enterprise. The other thing that's kind of interesting to me is I actually see a different type of makeup of companies that use one framework or the other. I've seen primarily window shops, like people that use Visual Studio and and all of those tools and VS code, those companies seem to prefer Angular. And the companies that are like the hip cool companies that use those Mac computers, I say that because I use one, those companies seem to want React. It's kind of interesting, almost like a trend of the types of companies that choose one framework over the other. So anyway, we're seeing all kinds of different trends because we deal with companies that use our framework, but they get to pick their own framework. They use our platform, but then they pick their framework that they're building their apps in. 

STEVE_EDWARDS: So you've mentioned a couple of times about the API endpoints. I want to talk about that real quick. So when you build a resource and you have resources and forms, which are basically the same thing, I guess you want to talk about the difference between a resource and a form and a platform? 

TRAVIS_TIDWELL: I think I should probably start off by just saying that Form.io really came from a very simple insight, which is if you were to put a UI on top of an API, it would be a form. If you think of it, a form is a very good UI representation of an API interface. So that being said, any type of like in Firebase, one of the very first things you do in Firebase is you start off by doing like a data modeling. You create your models and you, from those models, you can create the APIs behind them and then that allows you to save data into those models. And like, you know, Mongo calls them collections and you're basically creating these different types of ways of storing data in structured formats. Forms are the same thing. You are building a data model when you build a form. Now, one thing we recognize very early on is like, okay, while we can easily claim that you can build a very complex modeling system with forms, it's not very apparent to people using this tool that they can do that and that they should do that. So what we ended up doing is even though the API makes no distinction between a form and a resource, they are the same thing. In fact, our database doesn't have a collection called resources. It all gets stuffed into forms. The reason why we deliberately separated them is we wanted people to think about forms in a little bit different way. We wanted them to think of data modeling as more of a data modeling system so that you can actually create these complex entities, make relationships to those entities while at the same time create this ability to do free form data collecting, which should be called forms. So resources, the thing, the way to think of it as a resource is a structured data object, like a noun. So like if you're building a HR application, you would have an employee resource and the employee would be very structured. You would have like first name, last name, email, maybe their address, maybe their other, other identifiers that make them like an employee object. Forms become way more bespoke. It's way more freeform. So like a good example is an employment application form. So that would make it so that the employee comes in to apply for something they're applying to be an employee. So they're gonna be filling out things like what are your references? What is your previous experience? Why do you want to join the company like it's way way more freeform than that? And so what we wanted to do is make a very clear distinction that yes, you can use forms as a very powerful data modeling tool. You also can use it in the free form fashion to create wizards, to create, you know, ways of collecting data and make it, make it very free form. And that's the reason why we have a distinction between forms and resources. Technically there's the same thing, but they're actually used in completely different ways in the application. 

STEVE_EDWARDS: Okay. So once in the platform, once you have your resources forms built. You've mentioned before how you're basically creating an API. And so you have this API page that for every resource lists all the different API actions that are available for a given form, which is really slick. So you have a get, a post, all the CRUD forms. So how is that? What do you use to generate that API documentation there?

TRAVIS_TIDWELL: It's you can think of them as virtual API's. So we actually use this is where express becomes really powerful because express allows for you to create these dynamic API's. They're like almost virtual. So we use like tokens inside of the the express JS path. Whenever you're doing like, you know, app dot get. And then you do like forward slash form form forward slash colon. And that tells it that it wants to be like a parameter. You can express was like built for that. And it's really efficient at creating dynamic APIs like that, virtual APIs. So every single one of those endpoints is not like code gen. We're not like generating code on the backend for every form. What we're actually doing is the APIs use the form definition. So this is what's a little bit unique about Form IO, is the form schema, that JSON schema that defines the form, dictates how the API behaves. So if you have a first name and last name that are required, and you set that in your form schema, that tells the API, I need to make sure that they provide first name and last name, and it has to adhere to this model. That's why I call it a model schema, model database, model APIs. And that model is defined by the form, and those APIs are automatically generated. Well, this also makes it very beneficial to use JavaScript top to bottom because we can actually do things in an isomorphic way. So let me kind of give you a description of what I mean by that. Our renderer, which is a JavaScript library is installed on the client and it is responsible for rendering the form as well as validating it. So if you forget to put first name and it's required, it will complain. If it's an email field and you do not put a proper email address, it will complain and it'll invalidate. We actually load our core renderer, that JavaScript renderer. This is one of the smartest things we ever did was to create a core vanilla JS renderer because that allows us to import that on the server. We actually import our core renderer on the server. And whenever a form is instantiated on the server, we actually instantiate the form instance from our core renderer. And that allows us to use isomorphic validation. So as that submission data is coming in, we are effectively using the core renderer on the server to validate the submission and to generate responses. And so not only is the client dynamic as far as how it validates forms based on the form schema, the APIs is like a reflection. It really is a reflection of that form into the server to form a a way of automatically generating these APIs that automatically validate. So it's a very unique way and approach to building APIs that also really enables this natural bridge to occur between the client application and the APIs. A lot of times these progressive developers, like the progressive web app developers, developers building Angular apps or Vue applications, React applications. This is one of the things they struggle with, which is how do I connect the data? How do I create windows in my application to the actual API server? And using forms creates a very natural way of thinking about it because a form is that window from the application. And so it makes a very natural way of building APIs. 

 

Right now, many of you are stuck at home, but eventually everything will open up. All right, listeners, let me ask you a question. Wouldn't you rather work from home instead of a cubicle or a noisy open office? Need to negotiate with your team and convince them to let you do it? Well, I have the perfect book for you. It's by my friend, Will Gantt. It's called Remote Work, Get a Job or Make a Career Working from Home. He's a proven author, software developer, and professional consultant with over 20 years of experience in a variety of roles. And now he wants to share his trade secrets with you. In remote work, you'll discover how to save more time, money, and mental energy each year, how working remotely can give you and your company a competitive edge in the market managing your physical health, mental health, career goals and relationships. You'll also get the ultimate list of tools and resources to help you transition into working remotely and much more. This is the perfect time to test out if working remotely is for you. And if you enjoy the freedom of working anywhere you want, then you can pick up your copy of remote work on Amazon today, or click the link below in the show description. 

 

STEVE_EDWARDS: So these API endpoints that are generated, you can access just like any other REST API, you can hit them with Postman. In fact, all your API documentation uses Postman. There's one thing that we just had someone from Postman on here a few weeks ago. Um, one of their dev rel. 

TRAVIS_TIDWELL: Yeah, we, we love Postman. We use it, we use it for our API docs. Um, and we also use it, uh, to generate PDS. PDFs is actually something pretty interesting as well. The way that we generate PDFs because very early on we were generating the PDFs of these forms in the client. Um, where the, the because a browser is actually pretty good at generating PDFs. You actually have an API from the browser to generate the PDF and get a printable. But the problem with that is you now have required the user to go to a browser to get the PDF. We actually ended up building an API, a separate API, to generate PDFs where we actually use Puppeteer on the back end. And the Puppeteer will actually use our renderer. And we have what's called a viewer, is an app that is actually rendered by Puppeteer to render a form and its submission, and then Puppeteer will generate the PDF and then that is streamed back to the user. So we even have APIs to fetch PDFs of filled-out submissions as well. So, and that's actually become a really popular product for us. In fact, almost every enterprise customer that uses Form.io ends up using our PDF server and PDF capabilities as well. 

STEVE_EDWARDS: Yeah, one of the projects I actually did that I don't think it ever got off the ground was the project to generate a PDF from a form. 

TRAVIS_TIDWELL: Business users love your PDFs. It's funny because as a developer, I'm always, I always have this opinion. Like why would people want PDFs? Isn't the web good enough? Like I don't think, I don't, my opinion, business users love the PDF and I don't think we're ever gonna get away from it. 

AJ_O’NEAL: Well, the PDF is reliable. The web is not reliable. 

TRAVIS_TIDWELL: Yeah, that's a good way to put it. 

AJ_O’NEAL: How many times has a PDF gone out of business and left you not having reports?

TRAVIS_TIDWELL: Yeah, that's true. Yeah. The PDF is reliable is a good way. What you see is what you get. It's the ultimate form of Wiziwig, right? It is the ultimate form of that. And it provides a way where if I view it on my computer and I send it to somebody, I am guaranteed it will look the exact same way that I viewed it on their computer. PDF, as far as I know, in fact, I can't claim that about web because I don't know what browser the person's going to be opening up the website in, you have no idea. It's unfortunate that we cannot claim the same thing with web. In fact, I think if we fix this browser problem, which we should talk about the browser issue because one thing that we are struggling with is all of the libraries we are depending on are deprecating their support of IE. And I don't think people realize how important IE still is to enterprises. It's unfortunate but it is the world that we live in regardless until we solve this browser issue web. 

AJ_O’NEAL: Isn't that what Babel is for though? I thought you just put it in Babel and now it's IE compatible. 

TRAVIS_TIDWELL: Yeah, you would think so, but all of these libraries that we depend on apparently don't get that memo. So what's unfortunate is we depend on libraries with our core renderer and those libraries are removing support of IE flat out removing it. 

AJ_O’NEAL: Well, yeah, but like, don't you just take your whole bundle 

TRAVIS_TIDWELL: and like babble your entire bundle and then, uh, even babble their libraries. We don't currently do that, but maybe we might have to start doing that. Like babbling, uh, doing a babble of vacation of our node modules folder. 

AJ_O’NEAL: Um, see you're trying to put the responsibility of, of the backwards. Poor folk on the rich hip folk. And that's just not going to work. It never has in human history. 

TRAVIS_TIDWELL: Yeah, that's exactly right. Yep.

STEVE_EDWARDS: So what is the tool that you're using to render your API page at slash API? It used to be Swagger, am I correct? Or? 

TRAVIS_TIDWELL: Yeah, that's still Swagger. 

STEVE_EDWARDS: It's still Swagger, okay. 

TRAVIS_TIDWELL: Yeah, yeah, we still, that's the Swagger UI, and that basically is a UI on top of the Swagger docs. You know, there's so many facets to our, there's so many little corners in the room of our platform that there's some things that I feel like, you know, as you're mentioning it, I'm like, man, it's been a long time since we've updated that that UI. So I hope it still works. It should. 

STEVE_EDWARDS: It works fine for me. I use it all the time. 

TRAVIS_TIDWELL: Okay. Well, that's good to hear. I'm sure we'd hear, I'm sure we'd hear from people if it didn't work. 

STEVE_EDWARDS: Right. So the other aspect about the platform that I want to talk about, I guess, is the form builder itself and how complex you can make forms. So it's a really, it's probably the best drag and drop form builder I've ever played with, I've ever seen. 

TRAVIS_TIDWELL: Thank you. 

STEVE_EDWARDS:  mean, it's really good. So you've got, If you go in to build a form, you've got your basic text fields and numbers, check boxes versus select boxes. Then you can get some more advanced things. Currency, you can even embed a resource within a resource, which I think is how you get the one-to-one or the one-to-many relationship that you're talking about. You got a signature where you can get somebody's type signature and so on.

TRAVIS_TIDWELL: In my opinion, probably in a lot of the other forms, to be honest with you, a lot of the other form builders have those elements. So you can find a lot of form builders that have those basic components. In my opinion, what really separates Form.io from other form builders that I've seen, one is it's actually geared towards developers. Like, one of the angles that we took that was different from the other form building tool sets out there was we explicitly wanted ours to be used by developers. So you will have, like for example, if you want to do like custom conditionals, you'll have the opportunity to write a snippet of JavaScript inside of the conditional to say, oh, here's how I want this field to behave. You also have the ability to do custom validations, writing snippets of JavaScript to perform validations. And because our system is isomorphic, those validation rules that you write in JavaScript also get executed on the server. We actually execute those in the VM on the server so that your validation snippets actually end up getting executed. You can also do conditionals and wizards and other multi-page forms has also become very popular. People building wizards and multi-step forms. I actually feel like that's gonna give you PTSD though, Steve, because I know one of the apps that you built was like overboard on the wizard function, but. 

STEVE_EDWARDS: Hey, it worked. 

TRAVIS_TIDWELL: Yeah, it did. Yep. So multi-page forms is also very popular and I feel like that's also another reason why JavaScript powered forms is way more Powerful than server rendered forms like a multi-step form if you actually think about it If you're if you're trying to figure out what page to go to next Still today all the other form systems use Ajax. They'll send an Ajax request to the server Render the next page and then that makes that basically takes you to the next next page. So first of all, you can't use it offline. Forget it, if you want to use it offline, it won't work. But it is also much slower. There's this transition that has to send a request to the server to get the next page, and then that transitions to the next page. With our renderer, that JSON is all encapsulated as part of the form, and we actually use panels to determine the pages. So the panels determine the display. And if you have a display set at the wizard, those panels become pages. And so the transitions are instantaneous as you're navigating from page to page. So the end-user experience is a lot better. Um, it also enables offline mode. That's another thing that's in my, in my opinion, has become a really big deal for enterprises. I know a lot of that's another thing that a lot of people are a little bit baffled by, you know, like in the day and age where internet is everywhere. Why do we need offline mode? In my opinion, it's actually become more important today than it ever has been because in a lot of cases enterprises are going with private clouds is kind of becoming this thing where they have their own private cloud, but those private clouds sit behind firewalls. So the second you unplug your computer, your application from their internal networks and take that device home with you, you are effectively offline as far as these organizations are concerned. And so with FormIO, you actually can build applications that you can submit forms, you can load forms, you can walk through a wizard all of this without the device even being connected to the internet, which is something very unique to JSON-powered forms in the client. 

AJ_O’NEAL: Well, and it's very nice because the internet is not reliable and it doesn't work well. I mean, anybody who's ever used wifi should have had to deal with like a less than one megabit connection on a regular basis. But people forget that when they're in their fancy offices and whatnot, like you don't, you don't have good wifi at Starbucks outside of San Francisco. You don't have a good connection at home outside of major metropolitan areas. Like people are dealing with one-megabit to five-megabit connections. 

TRAVIS_TIDWELL: Yep. And what is worse, seriously, what is the most worse experience than you filling out a form? Nobody likes filling out forms. You fill out all of this data and you're ready to submit it and your wifi gives out. And basically the page errors, you can't get back that data that you just try to submit. And in my opinion, that is the worst. 

STEVE_EDWARDS: The other example I can remember you giving, Travis, was a business I think you had that was like a scuba diving or a guiding business where they would go out on the boat, you know, get everybody's information and stuff, and, you know, save it. And then when they come back in and hook up, then everything sinks up again. 

TRAVIS_TIDWELL: Yeah, they were in, yeah, and I don't know if that company is still around anymore, but yeah, they were basically taking these devices out into the middle of the ocean and having people do their waivers. You know, like while they're out there, okay, ready to do some scuba diving, fill out this form, good luck having internet on that one. It's just not going to happen. So offline, offline apps and offline forms. And that also brings up another pretty interesting topic of discussion, which is where we're full my own is headed. Because we are actually exploring some new technologies that are pretty exciting. And my opinion, I mean, it's, it's not like, it's exciting for me. It's not like it's pillow talk with me and my wife or anything. But it's, but it. But basically the offline first nature of where the web is going. You know, there was, there's a couple of phases that the internet has been through. You know, it's been through it's mobile first movement. It's been through its API first movement. And I actually believe that the next big movement is going to be offline first where applications will have to be developed offline before you actually build it to be online. There's a lot of new technologies that are becoming standard that are helping with that, such as service workers. We actually are exploring with our next gen server technologies, the ability to run the entire API platform in the browser and service workers. And we've actually got prototypes of this working where you actually run the API server in the browser, the entirety of the API server. So all the API traffic will go to the service worker, the service worker will respond as if it is a hosted server. The database is actually local to the device. So the database would actually be indexedDB and it's the DB that sinks. That's the thing that synchronizes. It's not like replaying API traffic. Like our current offline mode, what it does right now is it detects when an API fails and then it'll replay that API back to the backend. Where that kind of falls down is a situation where, let's say that you are doing an inspection and you're out in the middle of nowhere and you need to look up customers within a five-mile radius of you but your device is offline. How are you going to do an API call to look up your customer list to say, okay, here's my customer search. As of right now, you would have to basically preload all of that information to, and to the local to the device in order to get it. What offline first allows us to do is to have our API be in a service worker. And the database is synchronized from the backend to the client and index DB so that all of that is basically available to the client. It's very, very powerful, very exciting. And we are, we are moving in that direction. 

AJ_O’NEAL: It is way cool. It comes with a lot of complexity though. And a lot of like caching cases. I mean, like the caching problem gets like a million times worse when you're using service workers. You're like, Oh crap, we forgot to. Right. 

TRAVIS_TIDWELL: Yeah. It's like, what is, what is the famous programmer joke? There's, there's two really big problems in computer science, naming things, cache and validation, and off by one. 

STEVE_EDWARDS: And off by oneers, yep. I love that one, I use it all the time. 

TRAVIS_TIDWELL: But you're right, the cache and validation is a problem. But what's beautiful about our API server is it kind of handles it for you. As long as you fall within the patterns of Form.io and use the APIs as how you're supposed to be using them, we take care of all the cache and validation. So you're basically hitting the service worker as if, actually, I take that back. You use our Form.io core renderer and our core renderer has like JavaScript SDKs where I could do like load submission. You're basically calling a method on an object called load submission. It's very similar to kind of like how Firebase works. You load submission or load form. And it's what, it is what handles all of the backend mechanics. It sends an API call or maybe it sends it to the service worker. It may load it from cache. It may load it from index DB, but you don't care. You're, you're all of that complexity is abstracted away from you. So that's what makes it enticing for a developer to use it. 

STEVE_EDWARDS: Right, and within one of the nice things from, you know, you mentioned about making this good for developers is when you're building an app, you know, obviously you can, depending on your react review, you have a component that renders a form for you. And then you can even render a form builder in your app. 

TRAVIS_TIDWELL: Yeah. 

STEVE_EDWARDS: You can render the form. And then, so the form is embedded in your app, you know there, you don't have to like go to Form IO to use the form. It's embedded in your app. And then you have all kinds of events, you know, when the form submitted do this, if somebody updates the field, do this. There's so much control that you can do crazy stuff. 

TRAVIS_TIDWELL: Yeah, because it's all, it's JavaScript control, the entire form is, and the form builder as well. And in fact, we actually have a lot of, and I can't call them customers because they actually don't pay us anything, but we have a lot of people using our core renderer, builder and renderer with their own back ends. And at that point, it's all open source, it's MIT licensed, they basically can take it, extend it, and they can embed our form builder into their own product. In fact, there's a company that I shall not name that has raised millions and millions of dollars recently that has done exactly that. They basically have embedded our form builder in their own product and are using it really to just, you know, to create these JSON-powered forms and these JSON-powered forms can then be rendered by our renderer and then you have full JavaScript control over that. And then of course you can send it to your own backend. We also do have an open-source core API as well. And a lot of people are actually using that too. A lot of people use the core API engine. That's really good for storing submissions, storing forms. It's not very good in like a team collaboration environment. Like for example, if you have more than one put request on a form, to update it from, let's say, two different people building the form together, they will clobber each other in open source, whereas our enterprise server actually handles that type of thing. So we do have a whole suite of open source libraries that you can use in the application to not only build the forms and build those schemas. In fact, I commonly say that our form builder is really nothing more than a glorified JSON schema builder. I mean, it's really what it's doing. By you building a form, you're just creating a JSON schema. 

STEVE_EDWARDS: So last thing I want to talk about before we moved to Picks was mobile and PWA. I know in the past, I don't know how much this has changed over the past couple of years, you'd use I think Apache Cordova and you could take one of your apps and make it a mobile app. Is that the route you still go down for that kind of thing? 

TRAVIS_TIDWELL: Yeah, we do have it. We still have a lot of customers using Cordova. Even that technology has evolved over the years and become a lot better. We also have some customers that are using, for example, like React Native. We do have a React Native. It's kind of lagged behind in our maintenance schedule, so we haven't been able to maintain it as readily as we have been able to maintain the other libraries. But we do have an offering. You can use our React Native renderer to render our Formio forms inside of React Native. So that's also becoming popular. And then of course, using like the Angular variants. So we have a lot of customers using, and of course the name is escaping me at the moment, the Angular version of the mobile frameworks. Angular, mobile, 

AJ_O’NEAL: Ionic. 

TRAVIS_TIDWELL: Ionic? Yep. So we have a lot of people building Ionic on Form.io, Ionic applications and Angular Material. We have an Angular Material renderer that works really well in mobile. So you can create Angular Material apps that do that as well. 

STEVE_EDWARDS: Do you know of anybody using something like NativeScript? 

TRAVIS_TIDWELL: No, not at the moment. And we don't have it. We don't have a renderer in NativeScript currently. I don't know if it would work right now, because we are JavaScript rendered. We're basically rendering DOM elements with our JavaScript renderer. You would have to do what we did with Angular Material, which is basically swapping out the view system with basically the Angular Material view. We would have to do that very same thing with native script in order to get it to work. So contributions welcome. If anybody wants to jump on that and create a native script renderer for FormIO, go have at it. That'd be amazing. 

STEVE_EDWARDS: All righty. So is there anything else you want to talk about that we haven't covered in regards to FormIO? 

TRAVIS_TIDWELL: No, well, other than we're hiring. You know, it's a it's it's we were actively seeking talented developers and anybody wants to apply just please go to our Our jobs page 

STEVE_EDWARDS: Awesome 

 

Early in my career I figured out which jobs were worth working at and which ones weren't mostly by trial and error I created a system that I use to find jobs and later contracts as a freelancer If you're looking for a job or trying to figure out where you should go next then check out my book the max coders guide To finding your dream developer job the book walks you through figuring out what you want vetting companies that meet your criteria, meeting that company's employees and getting them to recommend you for a job. Don't settle for whoever has listed their job on the job board, go out and proactively find the job you'll love. Buy the book at devchat.tv slash job book. That's devchat.tv slash job book. 

 

STEVE_EDWARDS: All right, so with that, we'll move on to picks. And Travis, since you're our guest, we'll let you go first. 

TRAVIS_TIDWELL: Yeah, so my pick is really just something that I've nerded out on with my my kids. I've got a son who's kind of getting into programming and he at school has joined the robotics club. And I was roped in to be the robotics coach. And it's all this VEX IQ robotics. And anyway, I've always kind of enjoyed sports and I've gone to sports competitions and football and nothing compares to a robotics competition, especially these VEX IQ Robotics. It's amazing. And if you actually watch them online, they have like a world championships and these kids like, they really get into this thing. And it's fun, it's good for kids to learn how to write software. And it's also competitive. So if you have a competitive child that likes, and you wanna also get them into STEM, I just highly recommend it. I've totally nerded out on it. I almost feel like I've done more research on Dex robotics than my son has just because I've really been getting into it. So that's my pick. 

STEVE_EDWARDS: AJ, what about you? 

AJ_O’NEAL: So I had a good one, but I don't remember what it is. But I've got another one that I do remember what it is, which is if you go to the NodeJS docs, there's a module called FS. You may have heard of it. And in there, there's a function called MKDUR a hundred years ago around the time that dinosaurs were roaming the earth, they added a new option to the API that is called recursive. And so you don't need the module MK Derpy and spoiler alert, you don't need run rough either because the RM Der now also has a recursive option. So, uh, I'm very pro delete junk out of the Oh package dot Jason. Oh, sorry. I just had a little moment of like a PTSD wash over me, which is not entirely untrue. I mean, that's being a little bit exaggerating, but that moment of like, that was pain washing over me, like experiencing it emotionally. I'm, I'm just so for, you know, getting rid of dependencies. I can't stand it when I NPM install. You know, I'm helping somebody with a project and they're like, yeah, just run NPM install. And, and it's, I mean, literally 1067 dependencies from 2000, 58 developers, 34 critical security bugs, 700 moderate bugs, 157 medium bugs, you know, like. 

TRAVIS_TIDWELL: We're doing the, we're doing the similar thing right now where we, historically we've always included Lodash. And if you're using Babel, it's actually very redundant because Babel includes a lot of the ES6 versions. And so you end up getting a lot of the superfluous code. 

AJ_O’NEAL: You may not know this, but you don't need ES6. Internet Explorer has Lodash built in. 

TRAVIS_TIDWELL: Yeah. 

AJ_O’NEAL: There is no browser. I mean, there are a couple of convenience functions like Plux that it low dash has that, um, the low dash used to be called underscore by the way. I don't know. You know, you know, he rewrote it. 

TRAVIS_TIDWELL: Yeah. Dalton rewrote it. 

AJ_O’NEAL: Yeah. But, um, Oh, he was so aggressive. Like I've got such a man crush on him for how he took the most popular library on NPM and owned it. 

TRAVIS_TIDWELL: Yeah. And he rewrote it as low dash. Yeah. 

AJ_O’NEAL: Well, but I mean that the strategy that he used to become the number one module was just. I mean, like T-Rex doesn't begin to describe what he did. He went through every single issue, like hundreds of issues and addressed every single one with an example. Like he literally, 

TRAVIS_TIDWELL: he was a machine. 

AJ_O’NEAL: I mean, it was doing it must've been a literal full-time job for him. When, when he was doing it because he went, he, he's like the Google bot that you never knew you needed.

TRAVIS_TIDWELL: Yeah. 

AJ_O’NEAL: He found every anyway that 

TRAVIS_TIDWELL: and now we're saying you don't need now we're saying you don't need this library. 

AJ_O’NEAL: Yes. But I know I'm going to pick him for that. You know, some some people can can manhate or whatever, but that's just like the raw power of of aggressive, like going after what you want to do and making your mark on the planet. 

TRAVIS_TIDWELL: You hear you hear the 10x dev. He's like a million X dev, right? 

AJ_O’NEAL: Well, it's not even it's not the dev. The dev isn't what did it. It's the main, his dev skills, like, sure. Yeah. He fixed like some nuance bugs for some really obscure edge cases and did it in a way that he could prove was performant in, you know, V eight and Yeager monkey. I think it was Yeager monkey at the time, or maybe it was spider monkey, whatever they called it for Firefox's engine, you know, but that wasn't the magic cause that didn't, that didn't improve anybody's life to have it be, you know, 10% faster, even twice as fast.

TRAVIS_TIDWELL: A lot of cases it was copy and paste from stack overflow and put it into a function. Right. 

AJ_O’NEAL: Well, but what he did was just the understanding people's needs and figuring out how to find where those needs are. And then like personally going in there and just spamming every single problem with a perfect copy-and-paste solution. And then like he must've had an FAQ. I can only imagine. 

TRAVIS_TIDWELL: You weren't kidding when you said you had a man crush on the guy. 

AJ_O’NEAL: No, like I imagine he must've had an FAQ that he had built up that when he encountered a problem, he copied and pasted the relevant paragraphs. Cause like every single thing was like detailed with this. I don't know. Maybe it's one of those things where when you remember it, it's even better than it was. But I just remember looking into that and just thinking. 

TRAVIS_TIDWELL: Speaking of. Wow. I know this is getting off the law on a tangent, but speaking of man crushes on developers, because I think every developer has a man crush developer or woman crush. I mean, let's let's yeah, let's be fair. 

STEVE_EDWARDS: Developer crush. 

TRAVIS_TIDWELL: Yeah. Yeah. So my man crush developer was Paul Irish. Yeah, he was he was it for me whenever I was getting into JavaScript. 

AJ_O’NEAL: We got to do a man-crush-woman crush episode. I don't know how we'd make that politically correct but... 

STEVE_EDWARDS: Developer crush.

AJ_O’NEAL: Develop but but it's it's different like because a man crush has a specific meaning It's if you're a man developer. 

TRAVIS_TIDWELL: So a woman crush would be a woman developer having a woman crush. 

AJ_O’NEAL: Okay, right It's it's different. It's it's when you're not attracted to someone because of because of any Biological reason but you're attracted to something about like you could have you could be a man and have a man crush on a woman. But it's it's it's different, you know, because if you say you were crushing on you know, this developer that's female than that, you know, like there's, there's some semantics there. 

STEVE; Yeah. Let's, uh, move out of this topic. 

AJ_O’NEAL: Yeah. Sorry. Anyway, 

TRAVIS_TIDWELL: but I get what you're saying. Yeah. And I've had it too. 

AJ_O’NEAL: So other thing is I am actually ready to announce web installed.dev. Me and my buddy. Well, first of all, it started kind of, well, it started a long time ago just I wanted an easy, quick and easy way to install the latest versions of things. Because if you've ever, you know, apt install node and it gets, it's got better because node is slowed down, right? But when you apt install something, you get like the worst, most incompatible version and the operating system always sets it up in some weird way where your environment variables aren't the way that they are in the docs and like things aren't where they're supposed to be. So using system package managers to install stuff is usually a nightmare. It leads to permission errors. You know, people start doing pseudo NPM, like all that stuff, right? And even the package straight from the Node website does this. Like if you doubt, well, I think they fixed it in the latest release, because I saw in one of the release notes, something about fixing permissions finally, but like even the main package installer for Node, like they try to do things that are operating system specific and blah, blah, blah. And it just, it screws it up. And so I wanted something where it's just like, take the tarball, untar it put it in my home directory where I always have control over permissions. And even if root touches a file, I can still like untouch it and fix it. That's just like lightweight, you know, it should be like 10 lines of code or bash, right? And then later on I was working with Amy and we were doing the go install and go has not as big of an issue with this, but it's still an issue. Like you just need things to be installed in dot local in your home directory, not installed in a system directory. And so a buddy of mine and I, who, you know, he has this problem, I have this problem, lots of people have this problem. We created webinstall.dev, which is curl bash installers where the, the hard work that is that you're not downloading a gigabyte Git repository with everything ever. You know, you just go to the website for the tool that you need and you curl HTTPS colon slash slash web install.dev slash node, for example, and pipe bash. And what it does is there's a package repository that's linked to on the page, and you can also see the source of the script with a link on the page. So we've written the code that, and some contributors as well now, we've written the code that goes out and makes an API out of however those releases are released. If the releases are on GitHub, that's super easy because we just copy and paste the required, the GitHub release API thing that we wrote, and we make a new one. But for some of them, like, Go has its own custom releases, Flutter has its own custom releases, so on and so forth. So for these things, we've created an API so that we know where the versions are, where the package is located, whatever. And this stuff is handled on the server. So we don't have to make complicated bash scripts. We don't have to require that you already have Ruby or Python or Node or whatever installed. That happens on the server. So what you get from the server is a script that based on your operating system and CPU architecture. It hands you back a bunch of environment variables that are set with the version that you need to download for whatever version you want. Because you can also do like at 12 or at 10 or at 14 or at stable or at LTS or whatever, appended to the name of the package and it'll do that. And then it has like what ends up being about three lines of unique bash code for whether it needs to move it from the bin directory to the local bin directory or if it needs to move it from, you know, because sometimes people, most people, their tar balls have a directory inside of it, but some of them don't have a directory, it's just the files bare. And you know, there's little discrepancies like that, that amount to one or two lines of bash, that you don't need to have, you know, an entire system to solve for. Well, except you do, because you have to have some sort of programming language, whatever, but we saw that on the server. So anyway. 

STEVE_EDWARDS: And you're able to get those working on Windows, I see that you have Windows support as well. 

AJ_O’NEAL: So I've got some Windows code that I need to review. Node.js will install on Windows, but it's hard-coded with version 12. I am hopeful that we'll be able to do the same thing for Windows as for Bash, where if you want to submit a Windows installer, you copy and paste a template and you change like three things, and it's going to be the same three things. It's going to be move instead of MV, but it's basically you're going to move thing, one thing from this directory to that directory. And then we might be able to use PowerShell, but it has to start in command because if you try to run PowerShell, it gives you a security exception because somebody has to turn that on explicitly. But anyway, yeah, so the goal is to- 

TRAVIS_TIDWELL: I think most developers are running PowerShell anyway. 

AJ_O’NEAL: Well, I want it to be something that someone who is uninitiated, who just wants to get up and running with Node or whatever to be able to copy and paste and not have to go Google, like, how do I change my security settings in PowerShell? Which everybody that uses it for the first time apparently has to do in order to run a PowerShell script. So anyway, that whole thing with Windows. I'm working on a solution for I've got somebody that's that's working on that and I need to review the work and test it and see and whatnot. So Windows will come but right now I mean bash was pretty easy and I'm actually excited about it. I feel like this is it solves the problem for me. It solves it. 

STEVE_EDWARDS: Yeah it sounds great. 

AJ_O’NEAL: Ryan Burnett that's my buddy that's working on it with me and I think it solves a problem for a lot of other people and so I'm just I'm excited to be able to announce it. 

STEVE_EDWARDS: Sounds awesome. All right, so my pick is going to be musical in nature. I am a real big fan of a band called Need to Breathe. They're sort of a Southern rock band out of South Carolina. Been to see them a few times. And one of my all time favorite albums that I listen to all the time, regular at least once a week or so, is called Rivers in the Wasteland. Really, really good. It has one song called Multiply that says I think it's my number two favorite song of all time right now behind another one. But just a really good song if you like the sort of Southern rock-flavored music, not quite Lynyrd Skynyrd, but that style. And I will put a link to that album in the show notes. Thank you, Travis, for coming on. 

TRAVIS_TIDWELL: Yeah, it's a pleasure. 

STEVE_EDWARDS: Talking about Formio. It's certainly been a lot of fun talking about it, you know, something that I use. If people want to get a hold of your contact you on the internets, how would they do that? 

TRAVIS_TIDWELL: I mean, I permit to live on GitHub. So you can you can find me on github. I'm just Travis T on github and on twitter I don't really do twitter very much. But you could tweet me and I'm software gnome on Twitter. That's pretty much the best way to get a hold of me is is through github because I pretty much live on github 

STEVE_EDWARDS: And then for me Oh is on Twitter's form underscore IO not just we don't 

TRAVIS_TIDWELL: I would we don't really we don't really do the Twitter much anymore from Formio. Really, you're going to find most of the activity on our GitHub page, just github.com. It's going to be github.com forward slash Formio. We also have a Gitter chat room that's fairly active. The Gitter chat room is just Formio as well. I think there's like 400, almost 500 people in the chat room there on Gitter. So it's fairly active. 

STEVE_EDWARDS: All right. Good deal. AJ, where can people reach you?

AJ_O’NEAL: Hey, I'm back to being at CoolAge86 everywhere except for GitHub where somebody created a mailinator account trying to be nice or something and stole it and can't get it back. But I gave up on the whole SolderJS thing. I still have my soldering iron right here. Don't get me wrong. I mean, it's literally with I can touch it. Oh, now I'm touching it. Okay. Rebranding was a dumb choice. So I'm CoolAge86 everywhere again for the few people that saw me as SolderJS.

STEVE_EDWARDS: Okay. And I am wonder95, Twitter, GitHub. My site is smgaweb.com. So everybody, thanks for joining us and we'll talk to you next week. 

AJ_O’NEAL: Adios! 

TRAVIS_TIDWELL: Thanks everyone. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To live your content fast with Cashfly, visit c-a-c-h-e-f-l-y.com to learn more.