are you professional in your front-end?

Front-end is often overlooked. People treat it as it would be super trivial or something that is so dirty nobody wants to touch (back-end developers often have this kind of disdain for front-end). When you have such negative views of front-end dev in your team, you would have self full-filling prophecy.

The truth is different - front-end in 2023 can be as professional as "real" programming. But you have to treat it seriously. Let's dive in and check if you have things below in your front-end project:

  • people - when you need back-end code, you need back-end developer, when you need front-end, you will need a front-end developer. And you need good developers with strong skills and professional responsibility.
  • obvious things - Git, package.json, probably bundler (e.g. Esbuild, Webpack etc.), CI/CD pipeline for deploying
  • tests - front-end code is still a code, so you can write unit tests for many things in frontend. Though unit testing GUI maybe won't be good idea. Some things can be better tested by e2e tests. If you don't have any tests written, you can still test your app - manually! Manual testing is still better than no testing (but manual testing is hard to scale, that's why automatic tests are useful)
  • good architecture (it's subjective what makes architecture "good", but I think it's important to at the very beginning to think of front-end as something that needs good architecture)
  • focus on user experience - you create software for users, so users should be happy. Gather feedback, listen to your users, react appropriately (you may have to escalate perceived problems to appropriate persons that would take a final decision, if you're not allowed to make design changes)
  • focus on performance - front-end apps have to run smoothly. And if this is not a case, you have to optimize them in many ways (performance of JS, loading times, bundle sizes etc.). Ignoring this aspect would affect negatively on the user experience.
  • standards in your code, usually enforced by Eslint or other linter
  • probably TypeScript - well, TypeScript is not silver bullet. I've seen projects written in TypeScript that were poorly written, I've seen projects written in JavaScript that were maintainable. I think though TypeScript is good when you have bigger project and probably in the mid to late project phase. JavaScript is good when you have smaller project or early phase of project. It's a tradeoff - whether you choose scalability and correctness (TypeScript) or freedom and flexibility (JavaScript). So I usually would start project with JavaScript and then gradually go to TypeScript, when project gets bigger and more stable.
  • thoughtful folder structure - though it depends on phase of project - when you start project is often pointless to divide your project into many different files and folders. Starting with one file is good. Then you can extract some things to some separate file. At some point you could rethink your file structure etc. On the other hand if you're doing something similar to things you done before, you could start from some battle-tested folder structure.

Comments

Popular posts from this blog

JavaScript landscape, job market and what next