« All Episodes

The Frontend at Whiteboard

Published 11/13/2015

In today's episode I talk about some of the front-end tools we use at Whiteboard.


Join Spec on Slack: http://spec.fm/slack

Mentioned on today's episode:


Today's episode is sponsored by Hired.com! If you are a developer or a designer looking for a job, Hired is a fantastic place to begin your journey! The special link for a doubled bonus is https://hired.com/developertea.

And lastly...

Please take a moment and subscribe and review the show! Click here to open Developer Tea in iTunes.

Transcript (Generated by OpenAI Whisper)
Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking about the front end tools that I use at Whiteboard. I'm really excited to talk about this because these are the tools that make up my day to day. It's the stuff that I work with each and every moment of the day. Now, I could be talking to you for many, many episodes about the tools that I have used, with front end and back end, but I want to try to keep it a little bit shorter so that you guys have kind of an overall picture of the tool set that I use, but also that a modern developer might end up using in the field, particularly a front end developer. So to be very clear, these tools are primarily related to HTML, CSS and JavaScript and more specifically to CSS and JavaScript. So before we jump in, I want to go ahead and thank today's sponsor, hire.com. If you are a designer or a developer and you're looking for a job, no matter what kind of job you're looking for part time or otherwise, you should check out hire.com. It's a great place to start on that journey of looking for a job in the industry. We'll talk more about hire.com and what they are offering to you later on in the show, but let's go ahead and jump in to the tools that I use each and every day. Now, to really understand this, you have to understand kind of the overall workflow at Whiteboard. We have projects that we work on for many different clients and we manage them in many different places and a lot of Developer Touch these projects. But typically we work in two primary spaces. Now we've branched out from these. So don't take this as these are the only spaces that Whiteboard has worked in. But we primarily work with WordPress and Rails. WordPress is a PHP. It used to be called a blog framework, but now it's more considered like a CMS. And then Rails, of course, is the Ruby on Rails framework. Now, it's important for you to know that all of the tools that I mentioned in today's episode will be included in the show notes. You can find those show notes at spec.fm. Of course, if you want to talk to me more about any of these tools, you should do that in Slack. You can join the spec Slack community by going to spec.fm slash slash. So we use WordPress and Rails. And so there's a lot of tools that are specific to WordPress and a lot of tools that are specific to Rails. So I'm going to try to stay away from those tools and talk more about generally available tools for front-end developers. So let's talk about some management tools first, because these are the ones that kind of act as the glue. And I'll be mentioning them later when I talk about the other tools that we use. The first tool that I want to mention is Bower. Bower is a package manager for front-end third-party tools. The vendor frameworks and libraries like jQuery, you can pull in things like Font Awesome or Bootstrap. There's a lot of things that you can pull in through Bower, but it is specifically for front-end. It is powered by Node. So we also use Node for a lot of these particular tools, but it's powered by Node. And it basically allows you to set up a file that says, here's the stuff that I want to use. Go out and get these versions of those things. Now, I mentioned we use Node. We also definitely use NPM, which is the Node package manager. It's similar to Bower, but it also allows us to install tools that are not necessarily specific to front-end web development. One of the tools that you can install with NPM, for example, is called Gulp. Now Gulp allows you to process things using Node. You can process a myriad of different things. For example, you can use Gulp to compress your images. You can use it to minify your JavaScript or your CSS files. You could use it to create your documentation. In fact, Gulp can be used basically to run any kind of code that you can imagine running. Anything that you can write or connect to with Node. Now, I'll be mentioning how we use Gulp as we go through the rest of these tools, because Gulp really is one of those pieces that kind of glues everything together. We'll be talking quite a bit about Gulp. Another similar version of this tool is called Grunt. Grunt came before Gulp was on the scene. If you're looking into the different tools in this particular space, Grunt is another great option for you. Another tool we use that is in this package manager world is called Composer. This one isn't necessarily 100% front-end, but we do use Composer to pull in PHP assets that end up being on the front end. I feel like it's worth mentioning here. Composer is a PHP package manager. Definitely look at Composer if you are working in the PHP world. It will make pulling new packages in much easier for you. We also use Typekit and Fonts.com. Both of these allow you to use fonts that you otherwise wouldn't necessarily be able to use on the web. You can load font files in asynchronously, for example, and use a huge library of fonts available to you in that way. You pay a monthly fee for them. We use Typekit on almost every project that we work on at Whiteboard. Speaking of loading assets in asynchronously, we also tend to use CDNJS. Whenever a framework or a plugin is available on CDNJS, typically we use that for the ones that aren't already on, for example, Google or jQuery.com. We will use CDNJS if those plugins are available there. For example, Handlebars is available on CDNJS. We'll talk a little bit more about Handlebars in just a few minutes. You want to use CDNs because basically they keep that load off of your application server. It keeps your application server only serving the HTML. The assets can be loaded in from other servers. It basically can help speed up your application. Speaking of speeding up your application, another tool that we use on just about every project at Whiteboard is called Cloudflare. If you haven't used Cloudflare, you should go and check it out. Cloudflare.com. We use Cloudflare primarily for caching and to take some of that load off of what would essentially be a static home page. Cloudflare is great for this particular use case. It is super fast. It's distributed all over the world. It should be noted that Cloudflare is not a replacement for your server. It is simply a stack that sits in front of it in the request chain. If you just go to Cloudflare.com, you'll find out a little bit more about how to set it up. They do have a free tier, by the way. I should also mention, by the way, that nobody on today's episode is sponsoring today's episode other than hired. All these tools, none of this is advertising. I'm simply explaining the things that we use at Whiteboard. The next two tools have sponsored the show in the past, but they are legitimate and we do use both of them at Whiteboard. The first one is DigitalOcean. We use DigitalOcean to spin up new projects quickly and we also use it to migrate old sites off of old LAMP stacks on EC2 servers onto brand new stacks on DigitalOcean. It's a little bit easier to manage for us. That's what we use DigitalOcean for. We also use Linode. Linode is a great solution for super fast Linux servers. We use that for some of our larger scale sites as well. That covers some of the non-specific tools that we use, the stuff that glues everything together. We also use WP Engine, by the way, for WordPress hosting since I was talking about the different hosts. We use WP Engine for WordPress hosting. We also use Heroku for our Rails hosting, typically. The thing that all of these hosts have in common is that they are relatively easy to start a new server and we need new servers all the time at Whiteboard. We are constantly working on new projects and so having the ability to push to new servers, having the ability, for example, to push to a Heroku repository and know that that particular Heroku repository is isolated from all the rest of our projects. We value that and all of these hosting providers actually allow you to do that kind of thing. Before we talk about the language-specific tools for CSS, HTML, and JavaScript, I want to talk to you about Hired.com today's sponsor. If you are a developer or a designer in the industry and you're looking for a job, go to Hired.com and create a free account today. This is totally free to you. You can get up to five offers right away, basically. You get offers from companies all around the world, and salary ranges starting at $75,000 and they go up from there, but they also provide the offers upfront before you ever even talk to the companies. You get salary and equity offers upfront. There are part time and full time opportunities on Hired.com. Normally Hired provides a $2,000 signing bonus as kind of a thank you for using the service to find your employment. But if you use the special link that you can find in the show notes at spec.fm, Hired has agreed to double that signing bonus to $4,000. Make sure you use that link, create your account, and if you end up getting a job through Hired, you will get a $4,000 signing bonus. Thank you so much to Hired.com for supporting Developer Tea and for supporting today's episode. We've been talking about tools today. I've talked about the tools that act as the glue for the rest of the front end development that we use at Whiteboard. Now I'm going to talk to you about the language-specific tools. We're going to start with JavaScript. Now JavaScript has a huge list of tools that you could use. The list is ever growing longer, and it is not only for front end development. This could go on for a very long time, but I've narrowed it down to the ones that we use most often. The very first thing that you should know about JavaScript is that you do not have to have a tool to use JavaScript. JavaScript is available in the browser as is. JavaScript itself should be considered a tool that you use. Now more specifically at Whiteboard, we have been writing ES6 and transpiling using Babel. We do that transpiling using Gulp. We load in Babel in our Gulp file and we write our JavaScript as ES6. Whenever we save the file, our Gulp file is watching for that save. It hears that we've saved the file and then it will actually transpile it and write that into a new file. Now, if you're unaware of what this means, essentially not all browsers support ES6 yet. In fact, most do not support all of the features of ES6. We have to rewrite this JavaScript into a version of that JavaScript that the browsers do understand. Luckily, we do not have to do that by hand. Babel handles all of that for us. Some of the tools we use with our JavaScript, we use the jQuery framework. Sometimes we will opt for the Zepto framework and this is mostly for DOM manipulation and selection. If we're building something with a sufficient amount of complexity and something that needs to control state and has a UI that is based on the state and we're trying to control all of that in our JavaScript, we typically use React. If you're not familiar, React is a framework created by a Facebook. React uses a special format of JavaScript. It's a special syntax of JavaScript called JSX and we use Babel to transpile JSX into JavaScript. It's the same tool that we use to transpile our ES6 into a format that browsers can understand. Now you may see ES6 as ES2015, which is actually the correct spec, but a lot of people are still referring to it as ES6. Those are interchangeable ES6, ES2015. On top of these bigger tools, there are a lot of smaller tools that we will use on various projects. For example, the underscore library, which provides us a bunch of small methods that allow us to do things like a functional language may do, iterators and that kind of thing. We use slick.js, which is a slider and it comes with a bunch of resources with CSS resources and that kind of stuff. That's a little bit more of a heavy-handed tool that we use. It's all over the map. There's a lot of small tools available for JavaScript, but knowing those base-level tools, that's the most important piece to getting all of this working together. Then you will know when you need another tool. It's a little bit easier to understand what you need once you have those base tools down. Learning your transpiling, so that's the ES6 using Babel or something similar, or if you want to write vanilla JavaScript without transpiling, that's perfectly fine as well. Then knowing the larger frameworks that you're going to be using, for example, jQuery and React, they're a little bit larger, quite literally, in size, and they have a little bit larger of scope and functionality, so it's important to know what those frameworks are because they actually have a larger effect on your overall code base. We also use some large frameworks like D3, but we use them less often because their use case for our projects is typically relatively limited. I also want to mention very quickly the idea of polyfills. Babel works on the concept of polyfills in a lot of cases, but the idea here is to provide functionality that the browser otherwise doesn't have, but another browser may have. For example, the request animation frame, not every browser supports request animation frame, so you have to write a wrapper for all the other browsers. You could consider parts of the jQuery library, polyfills, and there are a ton of these small polyfills available. We use those throughout different projects based on our particular needs for that project. Finally, I want to go over our CSS tool stack. As you all know, this week I am at SASConf whenever you are listening to this episode, and so it may come as no surprise that we use SAS at whiteboards. More specifically, we use the SCSS syntax of SAS. We also use straight CSS from time to time, typically not as much as we used to, and sometimes that's on legacy projects that don't necessarily have our current build process in the code base. So, if you rely on SCSS, we actually have a WordPress theme that we start from that is open source that you can go and take a look at. It's called launch frame. It's on get hub, get hub.com slash whiteboard slash launch frame, and all of these different tools, well, actually a lot of them, maybe not all of them, but a lot of them are visible there on get hub. So if you're interested in kind of seeing how our gulp file, for example, is organized, that's a great place to go and look. But we have our SCSS and all of our linting setup for that SCSS. All that is done via gulp. I can't go over every single package because this episode again would be incredibly long, but we use bootstrap for alpha, which came out just a few weeks ago. Bootstrap for alpha. We pull that in fresh on every project. Whenever it goes into the official version for, we will most likely switch over to that as well. We tend to use BIM on most of our projects. That's block element modifier, CSS. This is more of a methodology than it is a tool, but it is a worthwhile tool to take a look at if you have had difficulty organizing your CSS, especially on larger projects. BIM is awesome for this particular use case. And then finally, we do tend to also use font icons. Now I don't recommend using font icons if you only have one or two icons on the page. If you're using quite a few of those icons, does it make sense? Otherwise, I think you should be using SVG for most of those icons. But we use font awesome and we use GitHub's octacon. Both of these are really good, well-designed icons sets that are available totally for free, completely open source, and they're both available by using BOWER, which we talked about way earlier in the show. So check those out if you are using icons all over your sites. One awesome and octacon are both really high quality font icons sets. So we've only scratched the surface when it comes to front-end tools. There are so many tools available, especially when you're talking about processing tools, things that can help the actual development process be a little bit smoother. We didn't even talk about Git, for example. There are so many different tools, and we will be talking about these tools on this show, more in the future. But we also talk about this kind of stuff in our Slack channel. I'd love for you to join me there. It's spec.fm slash slack. Now if you have a specific question, that is the best place to find me and ask me that specific question about that specific tool. Again, all of the links for all of these tools can be found in the show notes. And if you want to hear more about tools in the future, please let me know. Reach out to me on Twitter or on Slack. You can find me on Twitter at developer.t. You can email me at developer.t. at gmail.com. Thank you so much for listening to this episode of developer.t. I hope you've had a fantastic and productive week, and I hope you have a restful weekend. Thank you again to today's sponsor, hire.com. If you are looking for a job and you are a developer or a designer, there is no reason you shouldn't at least check out hire.com. It's totally free to you. And there's no risk in checking it out. So go to hire.com. Make sure you use the special link in the show notes because if you do end up getting a job through that link, you can double your signing bonus. Normally they give out $2000, but if you use that link, it turns into $4,000 just like that. So check out the show notes. Again, those are at spec.fm. Thank you so much for listening to today's episode of developer.t. And until next time, enjoy your tea.