I love receiving or making designs and then actualizing them in the browser. That is why I have spent most of my career with Front-end responsibilities. It is rewarding work that connects you with incredible collaborators.
But Front-end work is not easy, and because it is non-trivial I get asked about my methodology. So here you will find thoughts about Front-end development that are universal between projects that are mature, new or hastily written.
I've organized my notes into 3 sections:
We can never have a "perfect" situation for too long in a growing system. Even stacks that feel great in the beginning will lose their allure. This is the nature of our work and we must try our best to persist as many qualities as possible. Here are the problems that I optimize for:
This problem is perpetual and your users will be the first to notice. Because it is a recurring problem, people find performance issues to be a great place to onboard others to a codebase and get contributions from people of all skill levels. Some websites take many seconds to render the UI. Other times there may be an excessive amount of loaders to compensate for the initial page load. Whatever it is, we have to improve on it.
When more contributors commit lines of code into the codebase, the codebase starts to lose simplicity and can become unfamiliar to original collaborators. In addition, when people leave jobs or pass on their work, new contributors can find it hard to understand all the changes without the original context.
The outcome is known infamously as technical debt. Some examples of this in the Front-end include multiple ways to write components, unfinished refactors, unnecessary round trips for data, local state setting hacks, and unnecessary usage of important while writing CSS.
You cannot build a useful product without using state. But state is the root of all problems in the application and UI logic of your codebase. Without discipline or proper tooling, this can make any codebase unpredictable.
UI elements such as the scrollbar or select menu can appear differently in the mainstream browsers: Chrome, Safari, FireFox, and Internet Explorer and their mobile counterparts.
This problem can be related to...
Designers are often disappointed when the final product looks nothing like what was presented. This may not ruin your collaboration with other engineers, but leads to visual designers no longer wanting to work with you or your company.
It is a Front-end developers's obligation to ensure the design is implemented as thoughtfully as possible.
Teams have resource constraints, and therefore tend to use technologies that replace the need to hire specialists. Those technologies come in the form of services like Algolia, or frameworks such as Apollo GraphQL.
It is scary to use frameworks like Angular 1.X and find out it is discontinued while you are in the middle of Front-end development. Another example: when RethinkDB shut down, it forced teams to find a new long term direction for their stack.
It is unfortunate enough that something broke for your users, but lacking tests in the codebase can frustrate members of your team.
There are different testing frameworks and strategies that can help you (such as TDD). Ask yourself: what do I need in order to be confident about the reliability of my product?
No idea or solution solves all problems, but here are some of the tactics that I try in combination with each other:
Root | |-- common|-- components |-- pages|-- index.js |-- package.json
README.md throughout your codebase to explain the purpose of a folder or file. Don't hesitate to put comments to describe problematic codepaths.
/* React Example */ const MyComponent = name => {return <h1>Hello {name}</h1>}
window.location.href does not give you this.
These questions and answers may only be relevant for 2018 and reflect some common questions I get on the internet.
I think its very legit, but I haven't tried it yet. I'm waiting for Svelte to become more mainstream before adopting it into my projects.
I love Preact. A lot of people who felt abandoned in the Angular 1.X camp have moved over to Vue, which is also worth checking out.
I think it rocks, I personally can't go back to SASS or LESS even though I wrote both for years. Using Emotion or Styled Components feels really intuitive. You also get freebies, such as auto prefixing, and O(1) lookup from class names you would have gotten from manually writing CSS classes or if you used something like Tachyons. If you're in a company that still has designers writing CSS and you're using React, it is super easy transition to Emotion. However I can't say the same about Aphrodite because of how annoying it is to use commas in JavaScript objects.
Yes and no, at my work it is the logical choice because there are multiple contributors with various backgrounds. There is a lot of momentum here and people are genuinely excited about the technology.
GraphQL is great at preventing the number of roundtrips for your application. In addition, GraphQL can act as a type system to avoid the implementation of Flow or TypeScript. When using Apollo-React you don't really need to use Redux on the client (in some cases). We are currently using GraphQL subscriptions for our Expo Dev Tools and I am excited to see how well they age.
There are some “gotcha” moments. You have to be careful not to add unnecessary fields to your queries that can cause expensive joins or sub query calls. You also need to invest some time into properly setting up GraphQL. Versions are always changing so you need to keep up and maybe even send pull requests. GraphQL queries need to go through a GraphQL client because it isn't a protocol.
And there is more, mutations with optimistic responses can cause side effects if you aren't careful, you can accidentally wipe out a cached value in the original query. You'll want to make sure to pick a client setting you fully understand for determining network behavior and caching. Writing the complete schema before you know what you want can be tedious, and you're going to need more server-side logic to verify and parse the parameters unless you go with a solution like Prisma.
For independent projects I tend to stick to REST because it is just a protocol and I like the simplicity. For authentication (with cookies or JWTs) and file upload I also stick with REST. My package.json dependencies section thanks me for it.
I am probably the biggest NextJS fanboy on the internet right now. After writing a ton of custom Webpack configurations and my own server-side rendering, I am so happy to use a framework that does the heavily lifting for me.
My biggest project with NextJS is showcased here. This site you are on is written with NextJS. Their team maintains up to date examples, when I started using the framework I referenced custom-server-express and with-emotion.
If you're a beginner, check out my example codebase for NextJS + Postgres. I personally don’t use sequelize but found it easier to explain to new developers.
Don't hesitate to reach out to me on Twitter if you want to. More than willing to lend a helping hand.
To reply you need to sign in.