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

Tag: open-source

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

List of all the posts related to open-source

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