Ever wondered what it is like to be a frontend developer at Startaê? What kind of technologies do we use? What methodologies do we follow? At Startaê, we are constantly learning and although it is a little hard to keep up with frontend technologies these days, we try our best to stay up to date. In this blog post, we aim to open the source of our process with you.

Before we begin, there are two concepts worth mentioning that often drive our decisions when we have to choose technologies — whoever comes from a Rails background will be familiar with them. The first one is DRY (Don’t Repeat Yourself) which reminds us of being concise and ends up paying off when we later have to give maintenance to our code. The second one is Convention over Configuration, which also reinforces conciseness and avoids bikeshedding. Although a little simple, these two concepts are very powerful and are connected with our core values.

As this post became bigger than we initially thought, we decided to split it into two parts. The first one being about the User Interface side of our stack and the second one being about Javascript. So, without further ado, let’s get started!


Being a design studio, we couldn’t care more about the interfaces we develop. In order to build beautiful interfaces and take care of organizing our styles in a structured and maintainable way, we are always looking for the best methodologies and technologies out there.

Over the years, we’ve tried quite a few of them. In this post, we’d like to share a list of the ones that we’ve mastered and that have worked best for us.

Slim / PugEmblem

As Kande described in a previous post, we love using HTML preprocessors. It avoids all the verbosity of pure HTML and helps maintain the cleanliness of our code. It comes in different flavors, depending on what language or framework you are using, but they are all very similar and achieve the same purpose. Once you pass the initial learning curve, it is definitely worth it.

BEM (Block, Element, Modifier)

We use BEM to write Modular and Object Oriented CSS. There is also a great post from Matheus on the topic. It is ideal for teams of developers on large projects that might last very long. We have been using it for a while, and it has proven to be a helpful approach to structure, organize and scale our frontend architecture. If used well, BEM will help you avoid the specificity problems of CSS, therefore generating fewer naming conflicts. You will probably never use the !important keyword ever again!

Sass

A technology that plays very well with BEM is Sass. We know CSS has evolved a lot in the past couple of years, and a lot of cool features are just around the corner — or could even be used today. But the stability and the simplicity of Sass still make it our top choice. Can’t imagine the world without nesting rules and variables.

ITCSS

Last but not least is ITCSS, which is more of a methodology than a technology. It is very useful for managing the global scope of CSS and for splitting our code into smaller files making it a lot easier to maintain. It makes removing dead code a lot simpler! If you want to go further, there is a must watch talk by its creator Harry Roberts: Managing CSS Projects with ITCSS.

There are also a few other honorable mentions that you’ll encounter in our projects: Fastclick, Hagrid and Reset.

Oh, and if you happen to be looking for a great starter template with some of what I mentioned here, you will be pleased to know that we have a template for generating static websites!

Everything we presented today plays nice together, but that doesn’t mean you can’t use each of these technologies independently. You could and you should! Give them a try and let us know what you think.

The part 2 of this series will come in another post, so keep in touch not to miss it! Cheers! :)