An exhaustive list of all the elements that will speed up your current web developments and offer the best user experience.

The Front-End Performance Checklist speeds up your web developments


In October 2017, I launched my [first open-source project on Github](https://medium.freecodecamp.org/how-my-first-project-won-6000-stars-on-github-in-5-days-6340ec99829e): the Front-End Checklist. In few hours, the project gained international visibility. After that, for a number of weeks, I had an incredible journey with many people around the world. I recently started giving talks in local communities around [Spain](https://en.wikipedia.org/wiki/Spain) and [Portugal](https://en.wikipedia.org/wiki/Portugal) about the project, and I plan to check out [France](https://en.wikipedia.org/wiki/France) later on.

Doing these presentations gave me a different perspective and vision about the worldwide communities who organize meetups regularly. I discovered that there were an huge number of people who were looking for more and more content and wanted to participate in local communities.

After initiating the [Front-End Dev Mauritius community](https://www.facebook.com/groups/frontenddevmauritius), I know how complicated it can be to find people willing to share their experiences about Front-End Development. And for some, such as those who recently have moved from another city or country, having a welcoming tech community is important to getting setting up.
I wanted to share with you some of the things I learned before, during, and after these meetups I participated in throughout Europe. And I want to encourage you to **participate more in local events no matter where you are today**.

## Don’t give up!

![Map showing Spain and Portugal and a line linking Barcelona to Madrid and Porto](/images/articles/learned-presenting-side-project-europe/map-front-end-checklist-conference.png 'Barcelona, Madrid and Porto')

Knowing that I would be on "holidays" for a few weeks in France, Spain, and Portugal I decided to try contacting local groups in **Barcelona, Madrid, Lisbon, Aveiro, and Porto**. I sent messages directly to the founders of local groups using [Meetup.com](https://www.meetup.com/), or contacted them via Twitter when they had specified their account on their profile. But, as I was expecting, I didn’t receive a lot of replies at first.

In **Barcelona** however, Bettina from [Ignit](https://itnig.net/), who managed the “_[Barcelona Front-End Development Meetup](https://www.meetup.com/fr-FR/Barcelona-Front-End-Development-Meetup/)_”, answered me really quickly. We decided, after some email exchanges and a phone call, to have a meetup on 14 March about my project.

In **Madrid**, the “Front-end Developers Madrid” organizers never answered me. But Juan Macias, a teacher’s assistant at “Ironhack Madrid,” did everything to help me setup a talk, which I gave on 16 March.

In **Lisbon**, Shannon Graybill from “Lisbon Le Wagon” showed a lot of interest in having me do a presentation. But we lost touch after we tried to call each other few times without setting a time. Besides, I decided not to present in Lisboa, but instead tried to do something in Porto (easier for me, as I was in Aveiro for two weeks).
Then in Porto I contacted Ricardo Mendes, who usually organizes “Porto Codes”. After few messages and emails, we decide to organize a talk on 5 April at Porto.io, at a coworking space in the middle of the city.

![Event page on the Porto Codes Meetup page](/images/articles/learned-presenting-side-project-europe/meetup-front-end-checklist-madrid.jpeg)

## Know your audience

One of the first rules I learned about giving a talk or a presentation was to “know your audience.” That is maybe the most challenging but nonetheless important rule you need to have in mind.
A few days before each talk, I went through all the profiles on Meetup, trying to know my future audience better. Unfortunately, most of the people don’t put their Twitter or Facebook account in their profiles. They don’t often answer some basic questions sent by the owner of the group when they subscribe, which makes it really hard for a speaker learn about the target audience of a meetup.
I sent a tweet to some people before the meetup in Barcelona, but I didn’t receive any responses. Next time 😉.

<Tweet url="https://twitter.com/TheDavidDias/status/972860228457975808" />

Since I didn’t know my audience in advance, I then decided to ask about each person’s career just before I started my talk. I adapted my content and discourse depending on their responses and it seemed that my slides were understandable by any level.

## Check for other local events

I’m not a fan of football (although my father is) — I never felt passionate about it. But that was something that would’ve been useful to think about before setting the Barcelona meetup’s date. Twenty-three peopole planned to come, but just…2 of them came. I discovered afterwards that “Barcelona — Chelsea” was probably one of the reasons why people didn’t come.
For me, it was an awesome time. I was able to focus more on specific questions asked by Jimmy from Los Angeles and Costa Rica and Marcela from Mexico (I also won’t forget the delicious pizza we ate after the meetup at Anauco).

## Print your username on a tee-shirt

![David Dias standing up and presenting near a video projector and MacBook. He is wearing a white tee-shirt with his username @thedaviddias printed in black.](/images/articles/learned-presenting-side-project-europe/iron-hack-david-dias-spain.jpeg 'Ironhack in Madrid (Spain)')

That might sound crazy, but printing my username on a tee-shirt was one of the things I’m happy I did. Some people may ask you how to contact you or may be too shy to do so. But with your username “on you,” it’s impossible not to find you on Internet (or forget who you are 😅)!

<Tweet url="https://twitter.com/itnig/status/973996442636472320" />

<Tweet url="https://twitter.com/SoyJuanMacias/status/974736513266339840" />

<Tweet url="https://twitter.com/locks/status/981961050827390982" />

## Tell stories and share what motivates you

Telling stories is not that hard.
Lots of talks I’ve heard in the past, from different people, seemed “empty,” without any soul. Doing a talk is much more for me than a simple exposition of facts or numbers or code. It’s about a story, how someone found a way to develop their application, how some new technologies can improve the way we work in our daily lives, and so on.
In my case, it was how a “simple” checklist changed the way I see the Front-End worldwide community, and the way that some people will work in the future.

## Don’t need to be the best

![David Dias standing front of a slide showing a list of JS task runners (Grunt, Gulp, Webpack...)](/images/articles/learned-presenting-side-project-europe/talking-about-task-runners.jpeg 'Talking about task runners at Ironhack Madrid')

That is maybe one of the biggest lesson I wanted to share with you in this post: you don’t need to be the best or the expert to share what you know or what you’ve learned before.
Lot of beginners with less than a couple years of experience don’t feel confident sharing what they know with others, because they think they don’t know enough.
From my point of view, that’s the wrong belief. Whether you have experience or not, you always have something useful that can be shared with others. It’s as simple as that. And it’s something some people need to start believing once and for all.

## Take photos before everyone leaves!

If your audience is used to sharing photos on Twitter or other social media, you’re lucky — you’ll have some photos of you to help you remember your talk or show the presentation you did. They might even come in handy if you want to write an article about it 😅.
But taking a group photo with all your attendees is a fun thing to plan before everyone runs out of the meetup. I failed on that point many times, and I was only able to take a picture in Porto with the two organisers, including Tim Lai.

<Tweet url="https://twitter.com/TheDavidDias/status/982013829969301505" />

A photo took after most of the attendees already went home.

## Ask for feedbacks

This is another thing I missed, but I now know how useful it could’ve been. Having feedback on any work or talk can be really helpful when we try to improve ourselves and the way we present things.
In my next meetups, I’ll probably give attendees a [bit.ly](https://bitly.com/) link redirecting to a [Typeform quizz](https://www.typeform.com/) which I’ll ask them to fill out.

And in case you didn’t read my article about how everything began, take a look at it here.
Putting it all together
Giving these talks in different cities and countries helped me learn how much can be shared and taught to an incredible number of people. During these last few years, while learning and sharing my vision of Front-End development, I wasn’t able to see how large the community of people wanting to become better actually was.
We can start with something really small, and that small thing can give us the opportunity to meet people and give them something they needed or were searching for.

Now, let’s recap each point I went through:

- Even if local communities don’t always send you a response, **don’t give up**!
- Always **check for other local events** when you decide on a date for a meetup
- Try to **know your audience** before, or prepare your talk to be accessible for anyone
- Printing **your username on a tee-shirt** can be helpful
- Remember to **tell stories** and to **show your motivation**
- You **don’t need to be the best** to share something with someone else
- Don’t forget to **take photos** before everyone leaves
- **Ask for feedback** to improve your next talk

## Thank you for reading!

That’s it. In case you like my article and find it useful, here are some things you can do to show your support:

- Give a star ⭐️ on GitHub: https://github.com/thedaviddias/Front-End-Checklist (It’s important for me to continue launching other open-source projects)
- Follow me on GitHub: https://github.com/thedaviddias
- Follow me on Twitter: https://twitter.com/thedaviddias


An overview of what I learned presenting the Front-End Checklist during my vacations in Europe

What I learned after presenting my side project in Europe


One month ago, I launched the [Front-End Checklist on GitHub](https://github.com/thedaviddias/Front-End-Checklist). In less than 2 weeks, more than 10,000 people around the world starred the repository. That was completely unexpected and incredible!

![A screenshot of the number of stars on Github](/images/articles/front-end-checklist-just-tool-everything-depends-on-you/featured.jpg)

I’ve been working as a front-end developer since 2011, but I started to build websites in [2000](http://www.csszengarden.com/). Since then, like us all, I’ve been trying to improve the quality of my code and deliver websites faster. Along the way, I’ve been managing developers from two different countries. That has helped me to produce a checklist a little different than what I’ve found on around the web over the years.

While I was creating the checklist, I continuously had the book “[The Checklist Manifesto: How to Get Things Right](https://amzn.to/2k9f6XG)” by Atul Gawade in mind. That book has helped me build checklists for my work and personal life, and simplify things that sometimes seem too complex.

If you are working alone or in a team, individually, remotely, or on-site, I wanted to share some advice on using the Front-End Checklist and the [web application](http://frontendchecklist.io/) that goes with it. Perhaps I can convince you to integrate it into your development cycle.

![A screenshot of the HEAD section on frontendchecklist.io](/images/articles/front-end-checklist-just-tool-everything-depends-on-you/start-to-check.jpg)

## Decide which rules your project and team need to follow

Every project is different. Before starting a new project, the whole team (i.e. the project managers, designers, developers, QA, etc.) need to agree on what the deliverables will be.

To help you to decide, I created 3 different levels of priority: high, medium, and low. You don’t necessarily need to agree with those distinctions, but they may help order your tasks.

The Front-End Checklist app was done to facilitate the creation of personalized checklists. Change some JSON files to your liking and you are ready to start!

## Define the rules to check at beginning, during, and at the end of your project

You shouldn’t check all these rules only at the end of a project. You know as well as I do how projects are at the very end! Too hectic. Most of the items of the Front-End Checklist can be considered at the beginning of your development. It’s up to you to decide. Make it clear to your team upfront what happens when.

## Learn a little more about each rule

Who loves reading the [docs](https://devdocs.io/)? Not most of us, but it’s essential. If you want to understand the reasons for the rule, you can’t avoid reading up about them. The more you understand the why of each rule, the better developer you become.

## Start to check!

The [Front-End Checklist](https://frontendchecklist.io/) app can facilitate your life as a developer. It’s a live checklist, so as you complete items your progress and grade are updated live. Everything is saved in localStorage so you can leave and come back as needed.

The project is open source, so feel free to fork it and use it however you like. I’m working on making sure all the files are commented. I especially invite those interested in [Pug](https://pugjs.org/api/getting-started.html) to take a look at the [views folder](https://github.com/thedaviddias/Front-End-Checklist/tree/master/src/views).

## Integrate automated testing in your workflow

We all dream of automation (or is it just me?). For now, the Front-End Checklist is just an interactive list, but some of the tasks can be automated in your workflow.

Take a look at the [gulpfile](https://github.com/thedaviddias/Front-End-Checklist/blob/master/gulpfile.babel.js) used to generate the project. All tasks are packages you can use with [npm](https://scotch.io/tutorials/using-npm-as-a-build-tool), [webpack](https://webpack.js.org/), etc.

## Validate every page before sending to QA team and to production

![A screenshot of the print version of frontendchecklist.io](/images/articles/front-end-checklist-just-tool-everything-depends-on-you/validate-before-qa.jpg)

If you’re passionate about generating clean code and care about your code quality, you should be regularly testing your pages. It’s so easy to make mistakes and remove some essential code. Or, someone else on your team might have done it, but it’s your shared responsibilty to be catching things like that.

The Front-End Checklist can generate beautiful reports you can send to a project manager or Quality Assurance team.

## Enjoy your work above all

Some people might look at such a long checklist and feel sick to their stomach. Going through such a list might cause anxiety and really not be any fun.

But the Front-End Checklist is just a tool to help you deliver higher quality code. Code that affects all aspects of a project: the SEO, the user experience, the ROI, and ultimately the success of the project. A tool that can help across all those things might actually help reduce your anxiety and improve your health!

## Conclusion

The success the Front-End Checklist received in such a short time reminded me that a lot of people are really interested in finding ways to improve their work. But just because the tool exists doesn’t directly help with that. You also need to commit to using it.

In a time where AI is taking over many manual tasks, quality is a must-have. Even if automation takes over a lot of our tasks, some level of quality will remain impossible to automate, and us front-end developers still have many long days to enjoy our jobs.


The steps you need to follow to efficiently use the application frontendchecklist.io

The Front-End Checklist is just a tool… everything depends on you


![](/images/articles/how-my-open-source-project-earned-6000-stars-on-github-in-just-5-days/github-stars.jpeg 'A screenshot of the Front-End Checklist repository (numbers are already outdated since I finished writing that article)')

Last month I launched two open source projects on GitHub. A few days later, my [Front-End Checklist](https://github.com/thedaviddias/Front-End-Checklist) was showing more than **6,000 stars** (17,000 as of writing). And I got 600 stars for my Resources-Front-End-Beginner project!

It was unexpected for me to receive such support coming from so many people around the globe: USA, Brazil, China, Japan, France, Canada, Spain, Mauritius, Japan, Portugal... Even now, I still can’t believe how many pull requests I received with changes and corrections these last days.

For so long I received gifts from the open source world. Now I felt it was finally time for me to give back everything I have learned, and to help others.

As a professional Front-End manager, I spend my time teaching and encouraging others to learn and practice. I regularly share interesting content and useful tools on the [Front-End Dev Mauritius group](https://www.facebook.com/groups/frontenddevmauritius/) on Facebook. But I never planned that the Front-End Checklist will become a worldwide project.

## My motivations to write another Front-End checklist

I’ve seen some Front-End checklists over the past year on the web:

- [Web Developer Checklist](http://webdevchecklist.com/)
- [A Checklist for Website Reviews](https://drublic.de/articles/frontend-checklist/)
- [Opquast checklist (in French)](https://checklists.opquast.com/en/)

Some of them helped me years ago when I wanted to improve my Front-End knowledge, but most of them were just “not enough.”

Two years ago, I decided to start writing my own checklist based on my experiences. That checklist became way more important when I started to manage Front-End teams in France and Mauritius. Based on questions and usual mistakes from the teams, the content kept improving.

When I needed to teach someone how to become a better Front-End developer, I always had in mind that checklist that I started to work on. The document which started with a simple personal need became an ambitious tool for my team.

Then I started to feel the need to share it with more people.

A month ago I decided to put a first version on GitHub. And… at that moment, everything started to happen fast… really fast.

## Things can happen fast on the internet. Really fast.

On 18 October, I published the first version of my Front-End Checklist. I went to see all members of my team and I asked them to put a star 😀 on the repository. They don’t really have the habit to star projects on Github, I had to encourage them to do so 😂.

A few hours later, watching an episode of [Hawaii Five-O](https://en.wikipedia.org/wiki/Hawaii_Five-O) with my [wife](https://medium.com/@kajaaldias), I opened my GitHub repository on my iPad. I was shocked to find that in only few hours, I had already received 700 stars.

![](/images/articles/how-my-open-source-project-earned-6000-stars-on-github-in-just-5-days/dean-surprised.gif '700 stars on Github in only few hours')

I was not able to understand why and where these stars were coming from. (At that time, I didn’t know about the Insights > Traffic section on GitHub.)

I hadn’t even published any tweet about the Github repository. The next day, I published on my Twitter account: just few likes and retweets about the checklist. Nothing that may explain, where everyone was coming from.

<Tweet url="https://twitter.com/TheDavidDias/status/920894390641614848" />

I then started to validate pull requests and answer some logged issues. I was feeling so grateful for that unimaginable support. Even working daily with international websites, I forgot sometimes the power of Internet. (Or it’s maybe I’m living in a small island far from everything 😂.)

Next day, I received on Twitter a message from Product Hunt:

<Tweet url="https://twitter.com/ProductHuntHi/status/920896487600640001" />

Without really taking time to think, I opened my Illustrator and designed a logo to put on the page. I kept it basic, inspired by the logo of Front-End Coders, a future NGO I’ll be launching soon officially.

![](/images/articles/how-my-open-source-project-earned-6000-stars-on-github-in-just-5-days/frontend-open-source-projects.jpeg 'Front-End checklist and Front-End beginners essential logos')

Since then, I received in less than one week 40 pull requests, was published on Codrops for my 2 lists in their Collective #359, on the Panda Weekly Newsletter #130 and #131, Hacker news, Reddit (multiple times), NewsCenter.io, La Ferme du Web and more.

Translation in Japanese, Spanish, Chinese, Korean, Portuguese and Vietnamese were done in less than 2 weeks!

![](/images/articles/how-my-open-source-project-earned-6000-stars-on-github-in-just-5-days/insights-front-end-checklist.jpeg 'Insights for the Front-End Checklist on 23 October 2017')

The list is positioned first on Google for the words “Front-End Checklist”. Some landing pages on Github have the checklist on first position (Front-End Development, Checklist, Guidelines).

I discovered more recently that the project was on top of the trending feed on
GitHub
with more than 6,000 stars in less than a week (on 27 October 2017).

The Front-End Checklist is trending on Github!
Checklists can be more than simple checklists
I’m a big fan of “Awesome”, the curated list of awesome lists created first by
Sindre Sorhus
. But some lists are colossal and I found myself sometimes struggling to find what I want. I’m not sure if it’s because the amount of links or the absence of information attached to each link.

This is why I decided to add emoticons in my two lists. I usually don’t use them too often, but in that case I found interesting to add more of these to have more information about the content of my links.

The Front-End Checklist use emoticons to add more informations for each rule
As mentionned in the introduction of the Front-End Checklist, I used:

📖 for documentation or article links
🛠 for online and / or testing tools links
📹 for any type media, but specially video content
I also used 3 images (High, medium, low) to integrate different levels of priorities. I didn’t find any emoticon that could replace these images easily.

The list of resources for Front-End Beginners also use emoticons to add some additional informations.
On my list of resources for Front-End Beginners, for example, I decided to indicate free and paid tutorials. It’s easier to have these type of informations before you click on any link. People can directly focus on what they prefer.

I use daily applications like Cloud Outliner Pro and MindNode to create new lists for my personal and professional life (and
Todoist
). I can’t imagine doing a complex task without a set of items into a list.

If you have something to share, share it on GitHub now!
When it comes to sharing documentation or code, today, there’s no other place I like more than Github. Last week I decided I needed to put my work in a place where people can easily access and participate.

This kind of project is meant to be used and perfected by experiences and different points of view. Because Front-End development is always moving, evolving, it’s not always simple to stay on track on everything. Collaborative projects, where people can participate are for me the best way to have constantly updated tools.

I regularly meet young developers and people who want to become Front-End developer. Even on my YouTube channel, I receive lot of questions and requests. The first advice I give to them is to start coding and put their work on Github. It’s a way for them to show their interests to their friends, a future recruiter and to the world.

The Front-End Code Camp is an event workshop to better understand the process of web development.
Don’t hesitate, everything you do, related to coding and web, take time to present it correctly on an README file and click “push”!

What’s next?
By the time I wrote this article I was already working on a small open-source web app... Today, you can already access the Front-End Checklist App online!

Due to many requests, I’m already working on an NPM module which will probably be used by a future website. It was not in my initial plans but when I saw so many people asking for, I couldn’t refuse.

I have much more to share! I’m working on other lists that may be as good as the Front-End Checklist… Well, I hope! 😃


The Front-End Checklist is my first open-source project gaining so much attraction and visibility! In this article, I explain what happen the first 5 days my project got published.

My content about side-project

The Front-End Performance Checklist speeds up your web developments

What I learned after presenting my side project in Europe

The Front-End Checklist is just a tool… everything depends on you

How my open source project earned 6,000 stars on GitHub in just 5 days