rs love

Design

A destination to share insights about web development and how to honor the craft.

Web Development

Futureland

Climate

Rules for Rulers

power

nss code of conduct ad hoc committee

Investment

Mydora Myspace streaming service

Music Supply

Trusted Friends Only

A Universe

experiment

this archive is dead. we moved off of rs to google drive. 

https://drive.google.com/drive/u/1/folders/1v82I6glWCoMthsvqCtljvMq3GKxnU4Td

Understanding Knowledge as a Commons

science sessions

The starting point for global exploration using the 

Genesis

rs-devlog

Jimmy, this article is awesome! Thoughtful, and well written. I especially appreciated the gotchas, and the Q&A section. I also didn’t know about your CSS post before, so that is on the reading list for tomorrow. Rock on, bro

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.

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 

 "We have state, and it is all over the place."

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. 

 "Our UIs look different in each browser"

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. 

 "What you implemented looks nothing like the design."

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.

 "We are using technology that is no longer supported."

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 

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 

 shut down, it forced teams to find a new long term direction for their stack.

 "Something broke, where are the Front-end tests?"

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:

Establish what simple and familiar mean to your team.

Spend time optimizing for layout and paint performance.

Create meaningful conventions that are easy to understand.

Try JavaScript on both client and server.

Pick libraries that are actively downloaded, updated, and discussed.

Use a popular state management solution for global state.

Implement instantaneous subsequent page loads.

Don't allow server side secrets to appear in the client JavaScript or HTML document.

Thoughts and ideas about how to solve some Front-end problems in 2018.

It is painful sometimes to be rotated into a team with people who aren't philosophically aligned with you (

). But someone has to put the effort into developing a relationship, and if you're reading this it might as well be 

You want to have good habits and EQ around conflict.

Interviews are a great place to test the waters. Protect yourself.

Build cadence with small and easy to read pull requests. Even for trivial things.

If you're leading, produce a document or materials that communicates your vision for the codebase from now to 6 months.

JavaScript in the browser isn't always super performant, so be careful when using popular main thread animation libraries like 

Be weary of using too many infinite animations.

"What you implemented looks nothing like the design."

If you can't measure that the site is performing better, you're going to build bad habits. You need to be able to share improvements.

Some frameworks or libraries can give you this functionality for minimal effort. Check out the 

 full page load speed in Chrome Inspector. Makes me happy.

, where small bundle sizes are part of the philosophy.

Delete unused code, even if you may use it in the future.

Don't require entire libraries in cases where you only need a couple of methods. MomentJS is an example of a library with a lot of bloat.

) or pick a framework that has an asset building implementation that does it for you.

. Learn how to configure your tools to get the most out of them.

Plenty of CSS-in-JS tools do auto-prefixing and class name generation. Look into 

 if you're writing CSS with a Webpack setup.

If you work on the Front-end, you must know your CSS.

Use the english language carefully, write methods that are self documenting in their signature.

Create a filesystem structure that represents the boundaries of your codebase. Here is a super basic example.

 throughout your codebase to explain the purpose of a folder or file. Don't hesitate to put comments to describe problematic codepaths.

"We have state, and it is all over the place."

I use local state for forms I know are used once. Examples of this are the login, signup or forgot password forms.

When you avoid local state, you can do nifty things with your global state such as 

 in bug reports and reload the steps that lead to the exception.

More predictable outcomes in your code when state changes from a centralized place.

Use stateless components / plain function components whenever possible.

/* React Example */

const MyComponent = name => {

Your entire team only has to learn one language to be productive on both the client and server. It is a lot more productive than traditional JavaScript/Python, JavaScript/PHP, JavaScript/Ruby setups.

Fast initial loads which is great for performance.

Client can just focus on hydrating components (binding events).

NPM is a great resource for tracking activity. Take a look at 

 and look at the weekly downloads and open issues to get a pulse for the health of a project.

 is a great place to see if a project is still active.

Find one other person who has used the technology in production and take notes about their usage.

"We are using technology that is no longer supported."

. Although I'm looking into replacing it with 

Using a JavaScript object exclusively as a form of state could be fun as an experienced team. I’ve seen some experts joke about this. Don’t do this if you don’t know what a deep copy and shallow copy are.

Most modern JavaScript frameworks support a routing library built in to make this fairly easy, such as 

Hey! My name is Jim and I love to build websites. You can learn more about me at 