How to start your next front end project
Starting a new project is always exciting, but also might be tedious with all preparations which need to be done at the beginning, or you can miss something important that affects your work for next couple of months. Recently I have been thinking about my process when I start a new project. So there are my few tips and things to think before kick off next one:
Talk with your UX/Designer
As a frontend/UI developer, you must be involved in the design process, that means you should check what with your colleagues are doing. Discussing with them once a day usually is enough. I see testing for accessibility or performance issues that the design might cause, or just debating small implementation details. I have been in a situation where spent days trying to implement something, and in the end, the result was not good enough, so I went to my designer, discussed it, changed the design with few pixels and the problem become easy to solve. So when you see a problem you can see: “Hey if you move this element to the right will save me X days work”, “if you replace this with that, the performance will be much better”, “if the animation starts from here it will be much smoother on mobile device” . However, the idea is not to be lazy and do the easiest job; our goal is to deliver excellent product and delivery it on time.
I am pretty sure that you are going to use HTML/CSS & JS but how you are going to use them? Are going to build SPA with Angular + GraphQL or PHP Laravel website which server-side render templates. Usually, that is the first and point you have to decide, what you need, how dynamic is the website, what is the backend ( if you have ).
Nothing matters if no one of your users cannot open and use your site. You are not building products for yourself. You are making it for users/customers. If you are doing a redesign of an old website, check out statistics so you can have an overview of currently used browsers. After that, you can decide: Which are the browsers you are going to support, what is the behaviour when the browser is not supported (empty page, partially broken page ), What are the fallbacks and what is the impact to support those browsers. Think about progressive enhancement.
Might sound funny for many people but CSS is hard, and we need a process for it from file organisation to way of structuring and naming classes. There are many solutions for that like BEM, Atomic, OOCSS, SMACSS, CSS-in-JS. If you are using a component-based framework like React maybe style encapsulation in component level is important so can go for CSS-in-js like solution ( styled-components, glamorous ), for PHP/Django I prefer to use BEM. Web components also can give you encapsulation using shadow dom but unfortunately is not supported everywhere yet. There is no silver bullet, use whatever fit your needs, choose one and stick with it. Choose you preprocessor if you need one.
I always start with: do I need that library or framework, is not because I do not like JS ( actually I love it). I just don’t want to add unnecessary things to my page weight, so every library has been doubted before added to my project. Nowadays, for many projects maybe we do not need jquery or react or whatever-today-is-modern-in-js-world. Often I like to refer to http://youmightnotneedjquery.com/ and just go with simple solution
Depends on the size of organisation you might not want to stick to any modern framework, that is the reason why many large companies choice Web Components, instead of going with React or Angular.
Performance & Accessibility
Consider those two, are you going to have some performance budget, what is your target audience. What kind of devices your customers use and when. Start with optimisations like serving correct image formats and size, adding gzip ( or another compression) on assets. Accessibility is essential for many users, don’t underestimate it, many reports show that 1/5 of people have some kind of that problem.
File structure and organisation
How are you going to organise your files, based on features, based on type? What about other assets like icons, fonts, images etc.?
Setup build tool
There are plenty of choices depends on your architecture. If you want to use the modern JS (es2015+) probably, you need transpiler like babel. If you need external modules, you might need too like Webpack, Browserify, Rollup. Also, you might need some task runner like Gulp, Grunt ( does someone still use it ? ) or just NPM scrips for that. CSS preprocessors ( SCSS, Less ) can be part of this. Also image resizing, compressing, optimising, creating font icons and whatever can be automated.
Nowadays almost every website includes a custom web font, and it is critical to know how to serve and prioritise those fonts. Maybe not all fonts are needed all time, so some of them may be loaded asynchronously, also is a best practice approach to optimise the fonts and serve in the right format, woff2 has high compression but is not supported in some old browsers. Think about font fallback when your font cannot load or loading takes too long, it is super annoying when you can see the page because of font loads too long, having timeout and fallback helps.
SVG icons, font icons, just images? There are few options for working with icons: making image sprite, font icons or use of svgs. You can integrate that process part of your build/task tools so don’t have to do manual work.
( In a project I created a gulp task which creates font-icon based on folder with svgs, so everyone even the designer can drop an icon in the projects and automatically appeared in the font on my next git pull)
Using reset.css or normalize.css, set up a base font size, line height. Define variables with colours, sizes, padding, media query breakpoints. Create a grid, basic styling like h1-h6. It is useful to define those things up front and reuse them over pages.
Create reusable components between pages, try to find patterns, speak with your designer about that; usually, the designers also want everything to be consistent across pages, so it is not going to be challenging to help you with that. Can be small things like buttons, links, inputs, labels, and headings to more complex components like media list, headers, carousels. Also, some components might seem similar but they are not, sometimes is better to duplicate components instead of creating wrong / high abstraction. Duplication is far cheaper than the wrong abstraction
Make a distinction between production and dev environment. Maybe those environments use different databases, APIs, and services. Don’t leave that for the last day before going live, and realise that you have a lot of hardcoded variables ( for example URL to a rest API ). Also in production is likely your code to be minified and compressed so setup those things from the beginning.
Depends on the project maybe you need things like linters and code formatters, so is better if you agree with your team and configure those from the start, so everyone of that team is aligned with the rules. In some projects setup style guide also might be super useful.
That was my list, maybe is not complete, nor in the right order or even not the correct things to do but it is just my experience, so your suggestions are always welcome in the comments