Using MacOS For Bleeding Edge Web Development – Post 1

Anyone paying the least amount of attention these days to the web development world as surely noticed that we are living in exiting times. The amount, and quality, of the tools of the trade today is completely different from what we had only 2 years ago.

We at Byte&Code are proud to say that we spare no efforts to be at the forefront of this new world, and we would like to help everyone to do the same. That is the purpose of the series of posts that starts with this one. We’ll dive into the new frameworks and tools to give you the much need liftoff boost in using them.

Currently we believe that the MacOS system is far better suited to web development that any other (even with the lack of IE for testing), and so we’ll focus on this system. There are going to be tools that only make sense on a Mac, but still we encourage anyone with a Windows or Linux system to use these new frameworks, even if we don’t specifically provide the info.

Now, with that out of the way let’s begin by explaining the core elements of this new wave.

Collection of logos from tools in the post

Backend and APIS

It seems like forever that we associate web server side code to PHP (the dominant force, but definitely not the only one), and our concept of a layered architecture was some type of DataAccess classes providing data to another set of classes responsible for the BusinessLogic that would fill and operate the classes that actually create the HTML/CSS/JS for the View layer.

In recent years PHP (and other languages) frameworks started to appear to help developers built better code, like Laravel (an MVC framework). This helped a lot, as projects could now be “understandable” even if we didn’t look at them for two months. But with the proliferation of social media, web apps / services, a new concept re-emerged – the API – in a new (with a few years already) flavour – REST.

So the forefront of server side code in web development is now RESTfull APIs. This move truly allows for a separation of responsibility as the business logic is hidden behind a structure that is human understandable and highly maintainable.

For those who just glanced over the multiple articles written about this, let us summarize it for you. A REST API is a web service API that uses HTTP methods to convey meaning. This allows one very important and interesting thing – the same endpoint (HTTP URL) is used for several purposes, with a GET request we get a collection of elements, with a POST we create one or more elements with a DELETE we delete one or more elements. For machines this is mostly irrelevant (comparing with the SOAP version that would have several endpoints), but for us humans it’s much more readable than and endless array of endpoints. Another point is that these APIs prefer a more simple means for transporting data – the JSON format.

Ok so we can have multiple things happening using one endpoint, that’s interesting but not ground breaking. So what else is there? This technology enable a lot of smart people to think long and hard on the way we created web services, and how this could be improved. It’s not easy to explain without some sort of example so let’s to that. Imagine you needed a way for a web application to manage client data (personal data, company data). This is how we would do it now.

1 – create the relevant endpoints (this mostly relates to the classes we would get if analyzing the problem with a OOP approach), in this case we need clients and companies (yes the proposed naming convention suggests the plural form), so we would have these URLs:

2 – write what ever code is need to support the CRUD operations. In this case the CRUD operations would be map to these calls:

CREATE client(s) [POST]
READ clients [GET]
READ ONE client [GET]
UPDATE client [PUT]
CREATE company(ies) [POST]
READ company [GET]
READ ONE company [GET]
UPDATE company [PUT]

And that’s it for server side stuff (apart from things like authentication).

Once you get your head around the notion of HTTP Methods corresponding to CRUD actions, this gets really easy to read and immediately understand (keep in mind that a normal application requires more than two entities, and the beauty of these approach really shines with 20+ entities).

Almost forgot, we use NodeJS for our backend code, more on this in a next post.


HTML5 has been the buzz for the last 5 years, but now we’ve moved past it. We use HTML5 of course but not as a primary tool. Now we turn to client side frameworks (javascript frameworks mostly) to create our frontends. These frameworks enable the easy use of some form of design pattern (normally MVC) to create really complex user interfaces. In this series we’ll show you Google’s framework called AngularJS (but this is not the only one, just the one we prefer).

At this stage we need to do an attention call here. The technologies that are presented in this series are great at building web applications, but they are mostly an overkill (and a new set of problems) in building a simple website, or even a complex one that is mostly for displaying content. So these are to be used to build the next Facebook, a simple ToDo web application or a company backoffice, but not a company’s institutional web site, or a landing page, or even a blog.

So with this done, AngularJS is an MVC javascript framework. Being a javascript framework, in this case (because NodeJS changed things), means it’s all client side (runs completely in the browser), this has a lot of advantages, from reducing server side pressure on resources to allowing a better use of the superstar features of HTML5 (like local storage or WebSockets). The MVC pattern is not new but is still considered the one of the best approaches to the presentation problem. The Model part of MVC is the JSON objects that are accessible via the API.

A lot more needs to be said about AngularJS, but we’ll leave it for a latter post.


No development endeavor is complete without tools. Developers love tools (mostly until now developers loved IDEs), and we can safely say that at no other time in the coding history did we have so many tools to chose from. So to better present our favorites to you we’ll break down into some categories

General Tools

We never loved to go to the terminal so much as we do in MacOS, but it can be better (so much better). Enter .dotfiles, a set of projects pioneered by Github that easily sets a baseline of configurations for the terminal that makes the lives of developers so much easier (like displaying the current git branch, or using … to go back two folders [equivalent to cd ../..]). There are a lot of .dotfile sets, we used as our base a project from Mathias Bynens and made some modifications (here is the github link).

The .dotfile set we use has a lot of features, but the most interesting are the aliases, terminal configurations like color schemes and settings (case insensitive for auto-complete for instance), git configurations like editing the prompth to display the current branch or a more usable version of git log, a set of oxs defaults and also a set of homebrew install commands to have your Mac up and running with no effort.

The best way to understand the advantages is to use it. Just go to the terminal and type:

git clone && cd dotfiles && source

To use the OSX defaults type ./osx and to use the brew install set just type ./brew (We advise you to look at those files in order to check if you are happy with the defaults proposed).

Package Managers

Since our days in the linux world, with apt and yum, we cannot live without a package manager. For MacOS we have Homebrew, and amazing package manager that’s really simple to use. We use it for server side stuff like NodeJS, MongoDB and also for most of the software we use on a day to day basis, like Google Chrome, Firefox, Evernote anf Sublime Text.

Besides Homebrew we’d like to introduce two others, npm and bower. Npm is a NodeJS package manager (we’ll introduce Node later), and bower is a client side project packager manager and is used to manage dependencies in a web project.

Npm comes with NodeJS so just install node via homebrew with brew install node. After the install is done you can install bower with npm using npm install -g bower.

In the next posts of this series we’ll dive deeper into all this components, but for now that’s it, you have a MacOS ready for cutting edge web development.

If there’s any question or suggestion please just use the comment section of the post (we reply to every comment).

Leave a Comment.