Tag: Developers

Flutter For Front-End Web Developers

I started as a front-end web developer and then became a Flutter developer. I think there were some concepts that helped me adopt Flutter easier. There were also some new concepts that were different.

In this article, I want to share my experience and inspire anyone feeling paralyzed with choosing one ecosystem over the other by showing how concepts transfer over and any new concepts are learnable.

Concepts That Transferred Over

This section shows places where front-end web development and Flutter resemble. It explains skills that you already have that are an advantage to you if you start Flutter.

1. Implementing User Interfaces (UIs)

To implement a given UI in front-end web, you compose HTML elements and style them with CSS. To implement UIs in Flutter, you compose widgets and style them with properties.

Like CSS, the Color class in Dart works with “rgba” and “hex”. Also like CSS, Flutter uses pixels for space and size units.

In Flutter, we have Dart classes and enums for almost all CSS properties and their values. For example:

Flutter also has Column and Row widgets. These are the Flutter equivalent for display: flex in CSS. To configure justify-content and align-items styles, you use MainAxisAlignment and CrossAxisAlignment properties. To adjust the flex-grow style, wrap the affected child(ren) widget(s) of the Column/Row, in an Expanded or Flexible.

For the advanced UIs, Flutter has the CustomPaint class – it is to Flutter what the Canvas API is to web development. CustomPaint gives you a painter to draw any UI as you wish. You will usually use CustomPaint when you want something that is really complex. Also, CustomPaint is the go-to way when a combination of widgets doesn’t work.

2. Developing For Multiple Screen Resolutions

Websites run on browsers and mobile apps run on devices. As such, while developing for either platform, you have to keep the platform in mind. Each platform implements the same features (camera, location, notifications, etc.) in different ways.

As a web developer, you think about your website’s responsiveness. You use media queries to handle what your website looks like in smaller and wider screens.

Coming over from mobile web development to Flutter, you have the MediaQuery helper class. The MediaQuery class gives you the current device orientation (landscape or portrait). It also gives you the current viewport size, the devicePixelRatio, among other device info. Together, these values give you insights about the mobile device’s configuration. You can use them to change what your mobile app looks like at various screen sizes.

3. Working with Debuggers, Editors, and Command Line Tools

Desktop browsers have developer tools. These tools include an inspector, a console, a network monitor, etc. These tools improve the web development process. Flutter too has its own DevTools. It has its widget inspector, debugger, network monitor, among other features.

IDE support is also similar. Visual Studio Code is one of the most popular IDE for web development. There are many web-related extensions for VS Code. Flutter too supports VS Code. So while transitioning, you don’t need to change IDE. There are Dart and Flutter extensions for VS Code. Flutter also works well with Android Studio. Both Android Studio and VS Code support Flutter DevTools. These IDE integrations make Flutter tooling complete.

Most front-end JavaScript frameworks come with their command-line interface (CLI). For example: Angular CLI, Create React App, Vue CLI, etc. Flutter also comes with an exclusive CLI. The Flutter CLI permits you to build, create, and develop Angular projects. It has commands for analyzing and testing Flutter projects.

Concepts That Were New

This section talks about Flutter-specific concepts that are easier or non-existent in web development. It explains ideas you should keep in mind as you enter Flutter.

How To Handle Scrolling

When developing for the web, default scrolling behavior is handled by web browsers. Yet, you are free to customize scrolling with CSS (using overflow).

This is not the case in Flutter. Widget groups don’t scroll by default. When you sense that widget groups might overflow, you have to proactively configure scrolling.

In Flutter, you configure scrolling by using peculiar widgets that permit scrolling. For example: ListView, SingleChildScrollView, CustomScrollView, etc. These scrollable widgets give you great control over scrolling. With CustomScrollView, you can configure expert and complex scroll mechanisms within the application.

On Flutter’s side, using ScrollViews is inevitable. Android and iOS have ScrollView and UIScrollView to handle scrolling. Flutter needs a way to unify the rendering and developer experience by using its ScrollViews, too.

It may help to stop thinking about the flow of document structure and instead consider the application as an open canvas for a device’s native painting mechanisms.

2. Setting Up Your Development Environment

To create the simplest website, you can create a file with a .html extension and open it in a browser. Flutter is not that simple. To use Flutter, you need to have installed the Flutter SDK and have configured Flutter for a test device. So if you want to code Flutter for Android, you need to set up the Android SDK. You will also need to configure at least one Android device (an Android Emulator or a physical device).

This is the same case for Apple devices (iOS and macOS). After installing Flutter on a Mac, you still need to set up Xcode before going further. You will also need at least an iOS simulator or an iPhone to test Flutter on iOS. Flutter for desktop is also a considerable setup. On Windows, you need to set up the Windows Development SDK with Visual Studio (not VS Code). On Linux, you will install more packages.

Without extra setup, Flutter works on browsers. As a result, you could overlook the extra setup for target devices. In most cases, you would use Flutter for mobile app development. Hence, you would want to setup at least Android or iOS. Flutter comes with the flutter doctor command. This command reports the status of your development setup. That way, you know what to work on, in the setup, if need be.

This doesn’t mean that development in Flutter is slow. Flutter comes with a powerful engine. The flutter run command permits hot-reloading to the test device while coding. But then you will need to press R to actually hot-reload. This is not an issue. Flutter’s VS Code extension permits auto-hot-reload on file changes.

3. Packaging and Deployment

Deploying websites is cheaper and easier compared to deploying mobile applications. When you deploy websites, you access them through domain names. These domain names are usually renewed annually. However, they are optional.

Today, many platforms offer free hosting.

For example: DigitalOcean gives you a free subdomain on .ondigitalocean.com.

You can use these domains if you are building a documentation website. You can also use them when you are not worried about branding.

In Flutter’s world with mobile applications, you usually in most cases deploy your app to two places.

You have to register a developer account on each of these platforms. Registering a developer account requires a fee or subscription and identity verification.

For App Store, you need to enroll for the Apple Developer program. You need to maintain an annual subscription of $ 99. For Google Play, you need to make a one-time $ 25 payment for the account.

These stores review every app reviewed before it goes live.

Also bear in mind that users don’t easily consume app updates. Users must explicitly update installed applications. This is in contrast to the web where everyone just gets to see the latest deployed version of a website.

Managing deployed applications is relatively more demanding than managing deployed websites. However, this shouldn’t scare you. After all, there are millions of apps deployed on either stores so you can add yours, too.

Additional Thoughts On Flutter

Flutter is a cross-platform tool to build desktop, mobile, or web applications. Flutter apps are pixel-perfect. Flutter paints the same UI on each app irrespective of the target platform. This is because each Flutter app contains the Flutter engine. This engine renders the Flutter UI code. Flutter provides a canvas for each device and allows you to paint as you want. The engine communicates with the target platform to handle events and interactions.

Flutter is efficient. It has high-performance levels. This is because it is built with Dart and it leverages Dart’s features.

With these many benefits, Flutter is a good choice for many applications. Cross-platform apps save money and time during production and maintenance. However, Flutter (and cross-platform solutions) might not be an optimum choice in some cases.

Don’t use Flutter if you want users to use platform developer tools with your application. Platform developer tools here mean device-specific tools like Android developer options. It also includes browser developer tools.

Don’t use Flutter for web if you expect browser extensions to interact with the website.

Also, don’t use Flutter for content-heavy websites.


This was a review of skills that carry over from front-end web development to working with Flutter. We also discussed app development concepts that you have to learn as a web developer.

Flutter is simpler for web developers because they both involve implementing UIs. If you start Flutter, you will find out that it gives you a good developer experience. Give Flutter a try! Use it to build mobile apps and of course, showcase what you build.


Flutter For Front-End Web Developers originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.


, ,

Technical Writing for Developers

HTML, CSS, JavaScript, Python, PHP, C++, Dart — there are so many programming languages out there and you may even be totally fluent in several of them! But as we aim to write more and better code, the way we write and communicate in everyday language becomes more and more important… and perhaps even overlooked.

The way we write about and around code is arguably as important as the code itself. And despite where you fall on that line, we can all agree that our words have the potential to both help and hurt code’s effectiveness.

In this article, I want to outline how these two seemingly distinct fields — programming and writing — can come together and take our developer skills to the next level.

Wait, technical writing? Yes, that’s exactly what I mean. I truly believe we are all writers in one sense or another. And I’m here to give you a primer with writing tips, advice, and examples for how it can make you both a better developer and communicator.

Technical writing is everywhere

Last year, the team behind the popular Mac Git client, Tower, polled more than 4,000 developers and found that nearly 50% of them spent between 3-6 hours a day writing code.

Bar chart showing actual programming time per day.

And yes, that’s one survey polling a pretty niche group, but I imagine many of us fall somewhere in that range. Whatever the case, a developer isn’t writing code 24/7, because as this poll suggests, we’re spending plenty of time doing other things.

That might include:

  • demoing a new feature,
  • documenting that new feature,
  • updating a work ticket related to that new feature, or
  • backlogging work to support that new feature.

Of course, there’s always time for bathroom breaks and Wordle too.

Anyway, most of the things we typically do involve communicating with people like your team, colleagues, clients, users, and other developers.

So we do spend a good chunk of our time communicating with humans through words in addition to the communication we have with computers through code. Words are written language. And if we wrote our words better, we’d communicate better. When we communicate better, we’re more likely to get what we want.

That’s Technical Writing 101.

Venn diagram showing the overlap between technical writing and coding.

And it doesn’t even end here.. Some programmers also like to make their own products, which means they need to make marketing part of their job. Technical writing plays a huge role in that too. So, yeah. I think it’s pretty fair to say that technical writing is indeed everywhere.

What is good grammar?

With so many programming languages out there, the last thing we want is to learn another one.

Grammar is an integral part of English, and it unlocks the full potential of communication. It makes us more formal, professional, and coherent.

Let me give you a quick rundown on language.

The English syntax

Just like programming languages, English has a well-defined syntax, and it starts with words.

Words are the building blocks of English, and they fall into eight buckets:

Color coded sentence showing the English syntax.

These can be names of people, animals, places, concepts, and objects.

CSS is one of the core languages of front-end development.


Verbs convey action. Even “is” can be considered an action.

Marcia codes in the morning and answers emails in the afternoon.


Adjectives are how we describe nouns. They’re like meta that adds more detail to a sentence to paint a vivid picture.


  • CSS is an elegant and poetic language.
  • The HTML for tables is complex and cumbersome.
  • The Box Model is important to understand CSS.

Prepositions create a relationship between a noun and other words, often indicating direction, time, location, and space.


  • Did you commit your work to the repo?
  • What is the best approach for this component?
  • We conducted interviews with real users.


Sometimes actions need to be more specific, so we use adverbs such as “runs fast” and “compiles slowly.” They often end in “-ly.”


  • This is easily the best idea of them all.
  • Chip waited patiently for Dale’s feedback.
  • The team worked diligently on the project.

Conjunctions connect phrases in a sentence. Remember this classic song from the show School House Rocks?


  • CSS for styling while HTML is for markup.
  • Yes, I write code, but I also work on design.
  • That fixes the bug. Yet it introduced a new one.


Paragraphs are made of sentences that are connected to each other using transitions.


  • There are many programming languages. However, only a few are used in the web industry.
  • First, clone the directory.
  • I like this approach but on the other hand, I know another one.

When nouns become repetitive, we replace them with pronouns such as: “he,” “it,” and “that.”


  • CSS is a stylesheet language. We use it to style websites.
  • Tony loves to code and he practices every day.
  • Our customers are tech-savvy because they know code.

Think of these like UI components: they are modular pieces you can move around to construct a complete and robust sentence, the same way you might piece together a complete and robust UI. Do all of the components need to be there all of the time? Certainly not! Assemble a sentence with the pieces you need to complete the experience, just as you would with an interface.

Voice and tone

Vocabulary, punctuation, sentence structure, and word choice. These are all the ingredients of English. We use them to share ideas, communicate with our friends and family, and send emails to our coworkers.

But it’s crucial to consider the sound of our messages. It’s amazing how one exclamation point can completely shift the tone of a message:

  1. I like programming.
  2. I like programming! 🙂

It’s easy to confuse voice for tone, and vice versa.

Voice is what concerns our choice of words, which depends on context. For example, a tutorial for beginners is more likely to use slang and informal language to convey a friendly voice, whereas documentation might be written in a formal, serious, and professional manner in an effort to get straight to the point.

The same message, written in two different voices:

  • Fun: “Expand your social network and stay updated on what’s trending now.”
  • Serious: “Find jobs on one of the largest social networking apps and online jobs market.”

It’s not unusual to accidentally write messages that come across as condescending, offensive, and unprofessional. This is where tone comes into play. Read your messages out loud, get other people to read them for you, and experiment with your punctuation and sentence structure. That’s how you hone your tone.

Here’s another way to think of it: your voice never changes, but your tone does. Your voice is akin to who you are as a person, whereas tone is how you respond in a given situation.

Active and passive voice

A sentence always contains an actor, a verb, and a target. The order in which these come determines if the sentence is written in an active or passive voice.

The actor comes first in an active voice. For example: “CSS paints the background.”

Sentences that use an active voice are more straightforward than their counterparts. They’re clearer, shorter, and more understandable — perfect for a more professional voice that gets straight to the point.

With a passive voice, the actor comes last. (See what I did there?) That means our actor — CSS in this case — comes at the end like this: “The background is painted by CSS.”

Readers usually convert a passive voice to an active voice in their heads, resulting in more processing time. If you’ve ever heard that writing in an active voice is better, this is usually the reason why. Tech writers prefer the active voice most of the time, with very few exceptions such as citing research: “It has been suggested that …”

But that doesn’t mean you should always strive for an active voice. Switching from one to the other — even in the same paragraph — can make your content flow more seamlessly from one sentence to another if used effectively.

Avoiding mistakes

Grammar is all about the structure and correctness of language, and there’s nothing better to achieve that than a quick proofreading of your document. It’s very important to rid your writings of spelling mistakes, grammar issues, and semantic imperfections.

At the end of this article, I’ll show you the invaluable tools that professionals use to avoid writing mistakes. Obviously, there are built-in spell checkers in just about everything these days; our code editors even have spell-checking and linting plugins to help prevent mistakes. 

But if you’re looking for a one-stop tool for all-things grammar, Grammarly is one of the most widely-used tools. I’m not getting a kickback for that or anything. It’s just a really great tool that many editors and writers use to write clean and clear content — similar to how you might use Emmet, eslint, or any other linter to write clean and clear code.

Writing code comments

The things we write for other developers can have a big impact on the overall quality of our work, whether it’s what we write in the code, how we explain the code, or how we give feedback on a piece of code.

It’s interesting that every programming language comes with a standard set of features to write a comment. They should explain what the code is doing. By that, I don’t mean vague comments like this:

red *= 1.2 // Multiply `red` by 1.2 and re-assign it

Instead, use comments that provide more information:

red *= 1.2 // Apply a 'reddish' effect to the image

It’s all about context. “What kind of program am I building?” is exactly the kind of question you should be asking yourself.

Comments should add value

Before we look at what makes a “good” code comment, here are two examples of lazy comments:

const age = 32 // Initialize `age` to 32
filter: blur(32px); /* Create a blur effect with a 32px radius */

Remember that the purpose of a comment is to add value to a piece of code, not to repeat it. If you can’t do that, you’re better off just leaving the code as-is. What makes these examples “lazy” is that they merely restate what the code is obviously doing. In this case, the comments are redundant because they tell us what we already know — they aren’t adding value!

Comments should reflect the current code

Out-of-date comments are no rare sight in large projects; dare I say in most projects.

Let’s imagine David, a programmer and an all-around cool guy to hang out with. David wants to sort a list of strings alphabetically from A to Z, so he does the obvious in JavaScript:

cities = sortWords(cities) // sort cities from A to Z

David then realizes that sortWords() actually sorts lists from Z to A. That’s not a problem, as he can simply reverse the output:

cities = sortWords(cities) // sort cities from A to Z cities = reverse(cities)

Unfortunately, David didn’t update his code comment.

Now imagine that I didn’t tell you this story, and all you saw was the code above. You’d naturally think that after running that second line of code, `cities` would be sorted from Z to A! This whole confusion fiasco was caused by a stale comment.

While this might be an exaggerated example, something similar can (and often does) happen if you’re racing against a close deadline. Thankfully, this can be prevented by following one simple rule… change your comments the same time you change the code.

That’s one simple rule that will save you and your team from a lot of technical debt.

Now that we know what poorly written comments look like, let’s look at some good examples.

Comments should explain unidiomatic code

Sometimes, the natural way of doing things isn’t right. Programmers might have to “break” the standards a bit, but when they do, it’s advisable to leave a little comment explaining their rationale:

 function addSetEntry(set, value) {       /* Don't return `set.add` because it's not chainable in IE 11. */     set.add(value);   return set; }

That’s helpful, right? If you were responsible for reviewing this code, you may have been tempted to correct it without that comment there explaining what’s up.

Comments can identify future tasks

Another useful thing to do with comments is to admit that there’s more work to be done.

// TODO: use a more efficient algorithm linearSort(ids)

This way, you can stay focused on your flow. And at a later date, you (or someone else) can come back and fix it.

So, you just found a solution to your problem on StackOverflow. After copy-pasting that code, it’s sometimes a good thing to keep a link to the answer that helped you out so you can come back to it for future reference.

Screenshot of copying a link at StackOverflow.
// Adds handling for legacy browsers // https://stackoverflow.com/a/XXXXXXX

This is important because solutions can change. It’s always good to know where your code came from in case it ever breaks.

Writing pull requests

Pull requests (PRs) are a fundamental aspect of any project. They sit at the heart of code reviews. And code reviews can quickly become a bottleneck in your team’s performance without good wording.

A good PR description summarizes what change is being made and why it’s being made. Large projects have a pull request template, like this one adapted from a real example:

## Proposed changes Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.  ## Types of changes What types of changes does your code introduce to Appium?  - [ ] Bugfix (non-breaking change which fixes an issue)  - [ ] New feature (non-breaking change which adds functionality)  - ...  ## Checklist  - [ ] I have read the CONTRIBUTING doc  - [ ] I have signed the CLA  - [ ] Lint and unit tests pass locally with my changes  ## Further comments If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc…

Avoid vague PR titles

Please avoid titles that look like this:

  • Fix build.
  • Fix bug.
  • Add patch.

These don’t even attempt to describe what build, bug, or patch it is we’re dealing with. A little extra detail on what part of the build was fixed, which bug was squashed, or what patch was added can go a long way to establishing better communication and collaboration with your colleagues. It level-sets and gets folks on the same page.

PR titles are traditionally written in imperative tense. They’re a one-line summary of the entire PR, and they should describe what is being done by the PR.

Here are some good examples:

  • Support custom srcset attributes in NgOptimizedImage
  • Default image config to 75% image quality
  • Add explicit selectors for all built-in ControlValueAccessors

Avoid long PRs

A large PR means a huge description, and no one wants to review hundreds or thousands of lines of code, sometimes just to end-up dismissing the whole thing!

Instead, you could:

  • communicate with your team through Issues,
  • make a plan,
  • break down the problem into smaller pieces, or
  • work on each piece separately with its own PR.

Isn’t it much cleaner now?

Provide details in the PR body

Unlike the PR title, the body is the place for all the details, including:

  • Why is the PR being done?
  • Why is this the best approach?
  • Any shortcomings to the approach, and ideas to solve them if possible
  • The bug or ticket number, benchmark results, etc.

Reporting bugs

Bug reports are one of the most important aspects of any project. And all great projects are built on user feedback. Usually, even after countless tests, it’s the users that find most bugs. Users are also great idealists, and sometimes they have feature ideas; please listen to them!

For technical projects, all of this stuff is done by reporting issues. A well-written issue is easy for another developer to find and respond to.

For example, most big projects come with a template:

 <!-- Modified from angular-translate/angular-translate -->  ### Subject of the issue  Describe your issue here.   ### Your environment  * version of angular-translate  * version of angular  * which browser and its version   ### Steps to reproduce  Tell us how to reproduce this issue.   ### Expected behavior  Tell us what should happen.   ### Actual behavior  Tell us what happens instead.

Gather screenshots

Capture the issue using your system’s screen-shooting utility.

If it’s a screenshot of a CLI program, make sure that the text is clear. If it’s a UI program, make sure the screenshot captures the right elements and states.

You may need to capture an actual interaction to demonstrate the issue. If that’s the case, try to record GIFs using a screen-recording tool.

How to reproduce the problem

It’s much easier for programmers to solve a bug when it’s live on their computer. That’s why a good commit should come with the steps to precisely reproduce the problem.

Here’s an example:

Update: you can actually reproduce this error with objects:   ```html  <div *ngFor="let value of objs; let i = index">    <input [ngModel]="objs[i].v" (ngModelChange)="setObj(i, $ event)" />  </div>  ```   ```js  export class OneComponent {    obj = {v: '0'};    objs = [this.obj, this.obj, this.obj, this.obj];  ​   setObj(i: number, value: string) {      this.objs[i] = {v: value};   }  }  ```   The bug is reproducible as long as the trackBy function returns the same value for any two entries in the array. So weird behavior can occur with any duplicate values. 

Suggest a cause

You’re the one who caught the bug, so maybe you can suggest some potential causes for why it’s there. Maybe the bug only happens after you encounter a certain event, or maybe it only happens on mobile.

It also can’t hurt to explore the codebase, and maybe identify what’s causing the problem. Then, your Issue will be closed much quicker and you’re likely to be assigned to the related PR.

Communicating with clients

You may work as a solo freelancer, or perhaps you’re the lead developer on a small team. In either case, let’s say you’re responsible for interfacing with clients on a project. 

Now, the programmer stereotype is that we’re poor communicators. We’ve been known to use overly technical jargon, tell others what is and is not possible, and even get defensive when someone questions our approach.

So, how do we mitigate that stereotype? Ask clients what they want, and always listen to their feedback. Here’s how to do that.

Ask the right questions

Start by making sure that you and the client are on the same page:

  • Who is your target audience?
  • What is the goal of the site?
  • Who is your closest competitor and what are they doing right?

Asking questions is also a good way to write positively, particularly in situations when you disagree with a client’s feedback or decision. Asking questions forces that person to support their own claims rather than you attacking them by defending your own position:

  • Are you OK with that even if it comes with an additional performance cost?
  • Does moving the component help us better accomplish our objective?
  • Great, who is responsible to maintain that after launch? 
  • Do you know offhand if the contrast between those two colors passes WCAG AA standards?

Questions are a lot more innocent and promote curiosity over animosity.

Sell yourself

If you’re making a pitch to a prospective client, you’re going to need to convince them to hire you. Why should the client choose you? It’s important to specify the following:

  • Who you are
  • What you do
  • Why you’re a good fit for the job
  • Links to relevant work you’ve done

And once you get the job and need to write up a contract, remember that there’s no content more intimidating than a bunch of legalese. Even though it’s written for design projects, the Contract Killer can be a nice starting point for writing something much friendlier.

Your attention to detail could be the difference between you and another developer trying to win the same project. In my experience, clients will just as easily hire a develop they think they will enjoy working with than the one who is technically the most competent or experienced for the job.

Writing microcopy

Microcopy is the art of writing user-friendly UI messages, such as errors. I’ll bet there have been times where you as a developer had to write error messages because they were put on the backburner all the way to launch time.

That may be why we sometimes see errors like this:

Error: Unexpected input (Code 693)

Errors are the last thing that you want your users to deal with. But they do happen, and there’s nothing we can do about it. Here are some tips to improve your microcopy skills.

Avoid technical jargon

Most people don’t know what a server is, while 100% of programmers do. That’s why it’s not unusual to see uncommon terms written in an error message, like API or “timeout execution.”

Unless you’re dealing with a technical client or user base, It’s likely that most of your users didn’t take a computer science course, and don’t know how the Internet works, and why a particular thing doesn’’t work. Hence, the error.

Therefore, a good error message shouldn’t explain why something went wrong, because such explanations might require using scary technical terms. That’s why it’s very important to avoid using technical jargon.

Never blame the user

Imagine this: I’m trying to log into your platform. So I open my browser, visit your website, and enter my details. Then I’m told: “Your email/password is incorrect.”

Even though it seems dramatic to think that this message is hostile, it subconsciously makes me feel stupid. Microcopy says that it’s never okay to blame the user. Try changing your message to something less finger-pointy, like this this example adapted from Mailchimp’s login: “Sorry, that email-password combination isn’t right. We can help you recover your account.”

I’d also like to add the importance of avoiding ALL CAPS and exclamation points! Sure, they can be used to convey excitement, but in microcopy they create a sense of hostility towards the user.

Don’t overwhelm the user

Using humor in your microcopy is a good idea! It can lighten up the mood, and it’s an easy way to curb the negativity caused by even the worst errors.

But if you don’t use it perfectly, it can come across as condescending and insulting to the user. That’s just a big risk to take.

Mailchimp says it well:

[D]on’t go out of your way to make a joke — forced humor can be worse than none at all. If you’re unsure, keep a straight face.

(Emphasis mine)

Writing accessible markup

We could easily spend an entire article about accessibility and how it relates to technical writing. Heck, accessibility is often included in content style guides, including those for Microsoft and Mailchimp.

You’re a developer and probably already know so much about accessibility. You may even be one of the more diligent developers that makes accessibility a core part of your workflow. Still, it’s incredible how often accessibility considerations are put on the back burner, no matter how important we all know it is to make accessible online experiences that are inclusive of all abilities.

So, if you find yourself implementing someone else’s copywriting into your code, writing documentation for other developers, or even writing UI copy yourself, be mindful of some fundamental accessibility best practices, as they round out all the other advice for technical writing.

Things like:

Andy Bell offers some relatively small things you can do to make content more accessible, and it’s worth your time checking them out. And, just for kicks, John Rhea shows off some neat editing tricks that are possible when we’re working with semantic HTML elements.


Those were six ways that demonstrate how technical writing and development coincide. While the examples and advice may not be rocket science, I hope that you found them useful, whether it’s collaborating with other developers, maintaining your own work, having to write your own copy in a pinch, or even drafting a project proposal, among other things.

The bottom line: sharpening your writing skills and putting a little extra effort into your writing can actually make you a better developer.

Technical writing resources

If you’re interested in technical writing:

If you’re interested in copywriting:

If you’re interested in microcopy:

If you’re interested in using a professional style guide to improve your writing:

If you’re interested in writing for accessibility:

Technical Writing for Developers originally published on CSS-Tricks. You should get the newsletter.


, ,

Developers Speculating About the Long-Distant Future: 2022

This is a wonderful roundup from Jeremy, who I picture circling January 1, 2022, in red marker on a giant paper calendar back in 2008 and patiently counting the days.

See, there was a little smattering of internet drama back in 2008 (weird, right?) where Hixie kind of “officially speculated” that HTML5 would take 19 years to make it to full “recommended” status (2003-2022). Seems like most web developers at the time were quite certain HTML, and perhaps the internet as we know it, would be essentially obsolete by 2022. They were not right.

To Shared LinkPermalink on CSS-Tricks

Developers Speculating About the Long-Distant Future: 2022 originally published on CSS-Tricks. You should get the newsletter and become a supporter.


, , , , ,

Why Don’t Developers Take Accessibility Seriously?

You know that joke, “Two front-end developers walk into a bar and find they have nothing in common”? It’s funny, yet frustrating, because it’s true.

This article will present three different perspectives on accessibility in web design and development. Three perspectives that could help us bridge the great divide between users and designers/developers. It might help us find the common ground to building a better web and a better future.

The corner of a white and blue building in focus, with white on the left and blue on the right representing the divide between developers when it comes to accessibility practices.
Photo by Alexander Naglestad on Unsplash

Act 1

“I just don’t know how developers don’t think about accessibility.”

Someone once said that to me. Let’s stop and think about it for a minute. Maybe there’s a perspective to be had.

Think about how many things you have to know as a developer to successfully build a website. In any given day, for any given job position in web development, there are the other details of web development that come up. Meaning, it’s more than “just” knowing HTML, CSS, ARIA, and JavaScript. Developers will also learn other things over the course of their careers, based on what they need to do.

This could be package management, workspaces, code generators, collaboration tools, asset loading, asset management, CDN optimizations, bundle optimizations, unit tests, integration tests, visual regression tests, browser integration tests, code reviews, linting, formatting, communication through examples, changelogs, documentation, semantic versioning, security, app deployment, package releases, rollbacks, incremental improvements, incremental testing, continuous deployments, merge management, user experience, user interaction design, typography scales, aspect ratios for responsive design, data management, and… well, the list could go on, but you get the idea.

As a developer, I consider myself to be pretty gosh darn smart for knowing how to do most these things! Stop and consider this: if you think about how many people are in the world, and compare that to how many people in the world can build websites, it’s proportionally a very small percentage. That’s kind of… cool. Incredible, even. On top of that, think about the last time you shipped code and how good that felt. “I figured out a hard thing and made it work! Ahhhhh! I feel amazing!”

That kind of emotional high is pretty great, isn’t it? It makes me smile just to think about it.

Now, imagine that an accessibility subject-matter expert comes along and essentially tells you that not only are you not particularly smart, but you have been doing things wrong for a long time.

Ouch. Suddenly you don’t feel very good. Wrong? Me?? What??? Your adrenaline can even kick in and you start to feel defensive. Time to stick up for yourself… right? Time to dig those heels.

The cognitive dissonance can even be really overwhelming. It feels bad to find out that not only are you not good at the thing you thought you were really good at doing, but you’ve also been saying, “Screw you, who cares about you anyway,” to a whole bunch of people who can’t use the websites you’ve helped build because you (accidentally or otherwise) ignored that they even existed, that you ignored users who needed something more than the cleverness you were delivering for all these years. Ow.

All things considered, it is quite understandable to me that a developer would want to put their fingers in their ears and pretend that none of this has happened at all, that they are still very clever and awesome. That the one “expert” telling you that you did it wrong is just one person. And one person is easy to ignore.

end scene.

Act 2

“I feel like I don’t matter at all.”

This is a common refrain I hear from people who need assistive technology to use websites, but often find them unusable for any number of reasons. Maybe they can’t read the text because the website’s design has ignored color contrast. Maybe there are nested interactive elements, so they can’t even log in to do things like pay a utility bill or buy essential items on their own. Maybe their favorite singer has finally set up an online shop but the user with assistive technology cannot even navigate the site because, while it might look interactive from a sighted-user’s perspective, all the buttons are divs and are not interactive with a keyboard… at all.

This frustration can boil over and spill out; the brunt of this frustration is often borne by the folks who are trying to deliver more inclusive products. The result is a negative feedback cycle; some tech folks opt out of listening because “it’s rude” (and completely missing the irony of that statement). Other tech folks struggle with the emotional weight that so often accompanies working in accessibility-focused design and development.

The thing is, these users have been ignored for so long that it can feel like they are screaming into a void. Isn’t anyone listening? Doesn’t anyone care? It seems like the only way to even be acknowledged is to demand the treatment that the law affords them! Even then, they often feel ignored and forgotten. Are lawsuits the only recourse?

It increasingly seems that being loud and militant is the only way to be heard, and even then it might be a long time before anything happens.

end scene.

Act 3

“I know it doesn’t pass color contrast, but I feel like it’s just so restrictive on my creativity as a designer. I don’t like the way this looks, at all.”

I’ve heard this a lot across the span of my career. To some, inclusive design is not the necessary guardrail to ensure that our websites can be used by all, but rather a dampener on their creative freedom.

If you are a designer who thinks this way, please consider this: you’re not designing for yourself. This is not like physical art; while your visual design can be artistic, it’s still on the web. It’s still for the web. Web designers have a higher challenge—their artistic vision needs to be usable by everyone. Challenge yourself to move the conversation into a different space: you just haven’t found the right design yet. It’s a false choice to think that a design can either be beautiful or accessible; don’t fall into that trap.

end scene.

Let’s re-frame the conversation

These are just three of the perspectives we could consider when it comes to digital accessibility.

We could talk about the project manager that “just wants to ship features” and says that “we can come back to accessibility later.” We could talk about the developer who jokes that “they wouldn’t use the internet if they were blind anyway,” or the one that says they will only pay attention to accessibility “once browsers make them do it.”

We could, but we don’t really need to. We know how these these conversations go, because many of us have lived these experiences. The project never gets retrofitted. The company pays once to develop the product, then pays for an accessibility audit, then pays for the re-write after the audit shows that a retrofit is going to be more costly than building something new. We know the developer who insists they should only be forced to do something if the browser otherwise disallows it, and that they are unlikely to be convinced that the inclusive architecture of their code is not only beneficial, but necessary.

So what should we be talking about, then?

We need to acknowledge that designers and developers need to be learning about accessibility much sooner in their careers. I think of it with this analogy: Imagine you’ve learned a foreign language, but you only learned that language’s slang. Your words are technically correct, but there are a lot of native speakers of that language who will never be able to understand you. JavaScript-first web developers are often technically correct from a JavaScript perspective, but they also frequently create solutions that leave out a whole lotta people in the end.

How do we correct for this? I’m going to be resolute here, as we all must be. We need to make sure that any documentation we produce includes accessible code samples. Designs must contain accessible annotations. Our conference talks must include accessibility. The cool fun toys we make to make our lives easier? They must be accessible, and there must be no excuse for anything less This becomes our new minimum-viable product for anything related to the web.

But what about the code that already exists? What about the thousands of articles already written, talks already given, libraries already produced? How do we get past that? Even as I write this article for CSS-Tricks, I think about all of the articles I’ve read and the disappointment I’ve felt when I knew the end result was inaccessible. Or the really fun code-generating tools that don’t produce accessible code. Or the popular CSS frameworks that fail to consider tab order or color contrast. Do I want all of those people to feel bad, or be punished somehow?

Nope. Not even remotely. Nothing good comes from that kind of thinking. The good comes from the places we already know—compassion and curiosity.

We approach this with compassion and curiosity, because these are sustainable ways to improve. We will never improve if we wallow in the guilt of past actions, berating ourselves or others for ignoring accessibility for all these years. Frankly, we wouldn’t get anything done if we had to somehow pay for past ignorant actions; because yes, we did ignore it. In many ways, we still do ignore it.

Real examples: the Google Developer training teaches a lot of things, but it doesn’t teach anything more than the super basic parts of accessibility. JavaScript frameworks get so caught up in the cleverness and complexity of JavaScript that they completely forget that HTML already exists. Even then, accessibility can still take a back seat. Ember existed for about eight years before adding an accessibility-focused community group (even if they have made a lot of progress since then). React had to have a completely different router solution created. Vue hasn’t even begun to publicly address accessibility in the core framework (although there are community efforts). Accessibility engineers have been begging for inert to be implemented in browsers natively, but it often is underfunded and de-prioritized.

But we are technologists and artists, so our curiosity wins when we read interesting articles about how the accessibility object model and how our code can be translated by operating systems and fed into assistive technology. That’s pretty cool. After all, writing machine code so it can talk to another machine is probably more of what we imagined we’d be doing, right?

The thing is, we can only start to be compassionate toward other people once we are able to be compassionate toward ourselves. Sure, we messed up—but we don’t have to stay ignorant. Think about that time you debugged your code for hours and hours and it ended up being a typo or a missing semicolon. Do you still beat yourself up over that? No, you developed compassion through logical thinking. Think about the junior developer that started to be discouraged, and how you motivated them to keep trying and that we all have good days and bad. That’s compassion.

Here’s the cool part: not only do we have the technology, we are literally the ones that can fix it. We can get up and try to do better tomorrow. We can make some time to read about accessibility, and keep reading about it every day until we know it just as well as we do other things. It will be hard at first, just like the first time we tried… writing tests. Writing CSS. Working with that one API that is forever burned in our memory. But with repetition and practice, we got better. It got easier.

Logically, we know we can learn hard things; we have already learned hard things, time and time again. This is the life and the career we signed up for. This is what gets us out of bed every morning. We love challenges and we love figuring them out. We are totally here for this.

What can we do? Here are some action steps.

Perhaps I have lost some readers by this point. But, if you’ve gotten this far, maybe you’re asking, “Melanie, you’ve convinced me, but what can I do right now?” I will give you two lists to empower you to take action by giving you a place to start.

Compassionately improve yourself:

  1. Start following some folks with disabilities who are on social media with the goal of learning from their experiences. Listen to what they have to say. Don’t argue with them. Don’t tone police them. Listen to what they are trying to tell you. Maybe it won’t always come out in the way you’d prefer, but listen anyway.
  2. Retro-fit your knowledge. Try to start writing your next component with HTML first, then add functionality with JavaScript. Learn what you get for free from HTML and the browser. Take some courses that are focused on accessibility for engineers. Invest in your own improvement for the sake of improving your craft.
  3. Turn on a screen reader. Learn how it works. Figure out the settings—how do you turn on a text-only version? How do you change the voice? How do you make it stop talking, or make it talk faster? How do you browse by headings? How do you get a list of links? What are the keyboard shortcuts?

Bonus Challenge: Try your hand at building some accessibility-related tooling. Check out A11y Automation Tracker, an open source project that intends to track what automation could exist, but just hasn’t been created yet.

Incrementally improve your code

There are critical blockers that stop people from using your website. Don’t stop and feel bad about them; propel yourself into action and make your code even better than it was before.

Here are some of the worst ones:

  1. Nested interactive elements. Like putting a button inside of a link. Or another button inside of a button.
  2. Missing labels on input fields (or non-associated labels)
  3. Keyboard traps stop your users in their tracks. Learn what they are and how to avoid them.
  4. Are the images on your site important for users? Do they have the alt attribute with a meaningful value?
  5. Are there empty links on your site? Did you use a link when you should have used a button?

Suggestion: Read through the checklist on The A11y Project. It’s by no means exhaustive, but it will get you started.

And you know what? A good place to start is exactly where you are. A good time to start? Today.

Featured header photo by Scott Rodgerson on Unsplash

Why Don’t Developers Take Accessibility Seriously? originally published on CSS-Tricks. You should get the newsletter and become a supporter.


, , , ,

Jamstack Developers’ Favorite Frameworks of 2021

Which new framework should I learn this year? Is it time to ditch my CMS? What tools should I pick up if I want to scale my site to an audience of millions? The 2021 Jamstack Community Survey is here with answers to those questions and more. 

For the past two years, Netlify has conducted the Jamstack Community Survey to better understand our growing group of developers—the insights inform our services, and they also help developers learn from one another. Our survey data provides a sense of best practices as well as an idea of what else is happening in the community.

What we’re seeing this year: it’s never been a better time to be a developer in the Jamstack community! Jamstack has gone mainstream and the ecosystem is thriving. Jamstack is becoming the default choice for web developers at all stages of their careers across different geographies and touching all industries, and the community is only getting bigger. We also saw a huge rise in the percentage of students in our community over the last year, a great sign for a growing ecosystem.

In 2021, Netlify received more than 7,000 responses to the Jamstack Community Survey. This is more than double the number of responses we received in 2020, confirming the growth of the Jamstack community. 

Here are a few of the highlights from our more technical findings…

Jamstack developers work differently at scale.

32% of Jamstack developers are building sites for audiences of millions of users, but the tools they use and their development priorities are different: for instance, they are more likely to specialize in front-end or back-end work, and they are more likely to consider mobile devices a key target.

JavaScript dominates programming languages for the web—but TypeScript is giving it a run for its money.

For 55% of developers, JavaScript is their primary language. But TypeScript is coming from behind with a growing share.

A plot chart with colored dots representing different languages. Y axis is satisfaction, x-axis is usage. JavaScript is the most used and halfway up the satisfaction axis. Typescript is at the top of satisfaction, and halfway through the usage axis.

Figma is almost the only design tool that matters.

When it comes to design tools, more than 60% of survey respondents use Figma and are happier with it than the users of any other design tool we asked about.

A plot chart with colored dots representing different design apps. Y axis is satisfaction, x-axis is usage. Figma is at the upper-right corner of the chart while everything else is clustered toward the bottom left.

React still reigns supreme for frameworks.

React continues to dominate the major frameworks category in usage and satisfaction, and Next.js continues to grow alongside it. But we also saw growth and higher satisfaction from a challenger framework, Vue.

A plot chart with colored dots representing different frameworks. Y axis is satisfaction, x-axis is usage.React is at the far right, but halfway up the satisfaction axis. Express is at the top of the satisfaction axis but between 10-20% usage.

WordPress leads in CMS usage.

WordPress remains the clear leader as a content management system, but it’s not well-liked as a standalone solution. When used in a headless configuration, users reported much higher satisfaction. This was a breakout year for other headless CMSs like Sanity and Strapi.

A plot chart with colored dots representing different content management systems. Y axis is satisfaction, x-axis is usage. WordPress is all the way at the bottom right corner of the chart, showing high usage but low satisfaction. Sanity has the highest satisfaction, but is between 10-15% usage.

And that’s just a taste of what we learned. To view the complete findings of the 2021 Jamstack Community Survey, visit our survey website

The post Jamstack Developers’ Favorite Frameworks of 2021 appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , ,

Developers and Designers Work on a Single Source of Truth with UXPin

(This is a sponsored post.)

There is a conversation that has been percolating for as long as I’ve been in the web design and development industry. It’s centered around the conflict between design tools and development tools. The final product of web design is often a mockup. The old joke was that web developers make websites and web designers make paintings of websites. That disconnect is a source of immense friction. Which is the source of truth?

What if there really could be a single source of truth. What if the design tool works on the same exact code as the production website? The latest chapter in this epic conversation is UXPin.

Let’s set up the facts so you can see this all play out.

UXPin is an in-browser design tool.

UXPin is a powerful design tool with all the features you’d expect, particularly focused on digital screen-based design.

The fact that it is in-browser is extra great here. Designing websites… on a website is an obvious and natural fit. It means what you are looking at is how it’s going to look. This is particularly important with typography! The implementer of this card component can see exact colors (in the right formats) are being used, as well as the exact pixel dimensions, etc.

This is laid out nicely by Ania Kubów in a video about UXPin.

Over a decade ago, Jason Santa Maria thought a lot about what a next-gen design tool would look like. Could we just use the browser directly?

I don’t think the browser is enough. A web designer jumping into the browser before tackling the creative and messaging problems is akin to an architect hammering pieces of wood together and then measuring afterwards. The imaginative process is cut short by the tools at hand; and it’s that imagination—or spark—at the beginning of a design that lays the path for everything that follows.

Jason Santa Maria, “A Real Web Design Application”

Perhaps not the browser directly, but a design tool within a browser, that could be the best of both worlds:

An application like this could change the process of web design considerably. Most importantly, it wouldn’t be a proxy application that we use to simulate the way webpages look—it would already speak the language of the web. It would truly be designing in the browser.

It’s so cool to see this play out in a way that aligns with what great designers envisioned before it was possible, and with new aspects that melt with today’s technological possibilities.

You can work on your own React components within UXPin.

This is where the source of truth magic can happen. It’s one thing if a design tool can output a React (or any other framework) component. That’s a neat trick. But it’s likely to be a one-way trip. Components in real-world projects are full of other things that aren’t entirely the domain of design. Perhaps a component uses a hook to return the current user’s permissions and disable a button if they don’t have access. The disabled button has an element of design to it, but most of that code does not.

It’s impractical to have a design tool that can’t respect other code in that component and essentially just leave it alone. Essentially, it’s not really a design tool if it exports components but can’t import them.

This is where UXPin Merge comes in.

Now, fair is fair, this is going to take a little work to set up. Might just be a couple of hours, or it might take few days for a complete design system. UXPin only works with React and uses a webpack configuration to integrate it.

Once you’ve gotten in going, the components you use in UXPin are very literally the components you use to build your production website.

It’s pretty impressive really, to see a design tool digest pre-built components and allow them to be used on an entirely new canvas for prototyping.

They’ve got lots of help for you on getting this going on your project, including:

As it should, it’s likely to influence how you build components.

Components tend to have props, and props control things like design and content inside. UXPin gives you a UI for the props, meaning you have total control over the component.

<LineChart    barColor="green"   height="200"   width="500"   showXAxis="false"   showYAxis="true"   data={[ ... ]} />

Knowing that, you might give yourself a prop interface for your components that provides you with lots of design control. For example, integrating theme switching.

This is all even faster with Storybook.

Another awfully popular tool in JavaScript-components-land to view your components is Storybook. It’s not a design tool like UXPin—it’s more like a zoo for your components. You might already have it set up, or you might find value in using Storybook as well.

The great news? UXPin Merge works together awesomely with Storybook. It makes integration super quick and easy. Plus then it supports any framework, like Angular, Svelte, Vue, etc—in addition to React.

Look how fast:

UXPin CEO Marcin Treder had a strong vision:

What if designers could use the very same components used by engineers and they’re all stored in a shared design system (with accurate documentation and tests)? Many of the frustrating and expensive misunderstandings between designers and engineers would stop happening.

And a plan:

  1. Connect to any Git repo.
  2. Learn about all the components in that repo.
  3. Make those components available to the UXPin visual editor.
  4. Watch for any changes to the repo and reflect those changes in the visual editor.
  5. Let designer’s design and deliver accurate specs to developers for using those components.

And that’s what they’ve pulled off here.

The post Developers and Designers Work on a Single Source of Truth with UXPin appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , , , ,

Hashnode: A Blogging Platform for Developers

Hashnode is a free developer blogging platform. Say you’ve just finished an ambitious project and want to write about 10 important lessons you’ve learned as a developer during it. You should definitely blog it—I love that kind of blog post, myself. Making a jump into the technical debt of operating your own blog isn’t a small choice, but it’s important to own your own content. With Hashnode, the decision gets a lot easier. You can blog under a site you entirely own, and at the same time, reap the benefits of hosted software tailor-made for developer blogging and be part of a social center around developer writing.

Here are some things, technologically, I see and like:

  • Write in Markdown. I’m not sure I’ve ever met a developer who didn’t prefer writing in
  • Its not an “own your content” as in theoretically you could export content. Your content is in your GitHub repo. You wanna migrate it later? Go for it.
  • Your site, whether at your own custom domain or at a free subdomain, is hosted, CDN-backed, and SSL secured, while being customizable to your own style.
  • Developer specific features are there, like syntax highlighting for your code.
  • You get to be part of on-site community as well as a behind-the-scenes Discord community.
  • Your blog is highly optimized for performance, accessibility, and SEO. You’ll be hitting 100’s on Lighthouse reports, which is no small feat. Why not find out more info here about the advantages of having good SEO!

Your future biggest fans are there waiting for you ;).

Example of my personalized Hashnode newsletter with the best stuff from my feed.

The team over there isn’t oblivious to the other hosted blogging platforms out there. We’ve all seen programming blog posts on Medium, right? They tend to be one-offs in my experience. Hashnode is a Medium-alternative for developers. Medium just doesn’t cater particularly well to the developer audience. Plus you never know when your content will end up being behind a random paywall, a mega turn-off to fellow developers just trying to learn something. No ads or paywalls on Hashnode, ever.

The smart move, I’d say, is buying a domain name to represent yourself right away. I think that’s a super valuable stepping stone in all developer journeys. Then hook it up to Hashnode. Then wherever you do from that day forward, you are building domain equity there. You’re never going to regret that. That domain strength belongs entirely to you forever. Not to mention Medium wants $ 50/year to map a domain and DEV doesn’t let you do it at all.

But building your own site can be a lonely experience at first. The internet is a big place and you’ll be a small fish and first. By starting off at Hashnode, it’s like having a cheat code for being a much bigger fish right on day one.

DEV is out there too being a developer writing hub, but they don’t allow you to host your own site and build your own domain equity, as Hashnode does, or customize it to your liking as deeply.

Hashnode is built by developers, for developers, for real. Blogging for devs! The team there is very interested and receptive to your feature requests—so hit them up!

One more twist here that you might just love.

Hashnode Sponsors is a new way your fans can help monetize your blog directly, and Hashnode doesn’t take a cut of it at all.

The post Hashnode: A Blogging Platform for Developers appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , ,

The Widening Responsibility for Front-End Developers

This is an extended version of my essay “When front-end means full-stack” which was published in the wonderful Increment magazine put out by Stripe. It’s also something of an evolution of a couple other of my essays, “The Great Divide” and “Ooops, I guess we’re full-stack developers now.”

The moment I fell in love with front-end development was when I discovered the style.css file in WordPress themes. That’s where all the magic was (is!) to me. I could (can!) change a handful of lines in there and totally change the look and feel of a website. It’s an incredible game to play.

Back when I was cowboy-coding over FTP. Although I definitely wasn’t using CSS grid!

By fiddling with HTML and CSS, I can change the way you feel about a bit of writing. I can make you feel more comfortable about buying tickets to an event. I can increase the chances you share something with your friends.

That was well before anybody paid me money to be a front-end developer, but even then I felt the intoxicating mix of stimuli that the job offers. Front-end development is this expressive art form, but often constrained by things like the need to directly communicate messaging and accomplish business goals.

Front-end development is at the intersection of art and logic. A cross of business and expression. Both left and right brain. A cocktail of design and nerdery.

I love it.

Looking back at the courses I chose from middle school through college, I bounced back and forth between computer-focused classes and art-focused classes, so I suppose it’s no surprise I found a way to do both as a career.

The term “Front-End Developer” is fairly well-defined and understood. For one, it’s a job title. I’ll bet some of you literally have business cards that say it on there, or some variation like: “Front-End Designer,” “UX Developer,” or “UI Engineer.” The debate around what those mean isn’t particularly interesting to me. I find that the roles are so varied from job-to-job and company-to-company that job titles will never be enough to describe things. Getting this job is more about demonstrating you know what you’re doing more than anything else¹.

Chris Coyier
Front-End Developer

The title variations are just nuance. The bigger picture is that as long as the job is building websites, front-enders are focused on the browser. Quite literally:

  • front-end = browsers
  • back-end = servers

Even as the job has changed over the decades, that distinction still largely holds.

As “browser people,” there are certain truths that come along for the ride. One is that there is a whole landscape of different browsers and, despite the best efforts of standards bodies, they still behave somewhat differently. Just today, as I write, I dealt with a bug where a date string I had from an API was in a format such that Firefox threw an error when I tried to use the .toISOString() JavaScript API on it, but was fine in Chrome. That’s just life as a front-end developer. That’s the job.

Even across that landscape of browsers, just on desktop computers, there is variance in how users use that browser. How big do they have the window open? Do they have dark mode activated on their operating system? How’s the color gamut on that monitor? What is the pixel density? How’s the bandwidth situation? Do they use a keyboard and mouse? One or the other? Neither? All those same questions apply to mobile devices too, where there is an equally if not more complicated browser landscape. And just wait until you take a hard look at HTML emails.

That’s a lot of unknowns, and the answers to developing for that unknown landscape is firmly in the hands of front-end developers.

Into the unknoooooowwwn. – Elsa

The most important aspect of the job? The people that use these browsers. That’s why we’re building things at all. These are the people I’m trying to impress with my mad CSS skills. These are the people I’m trying to get to buy my widget. Who all my business charts hinge upon. Who’s reaction can sway my emotions like yarn in the breeze. These users, who we put on a pedestal for good reason, have a much wider landscape than the browsers do. They speak different languages. They want different things. They are trying to solve different problems. They have different physical abilities. They have different levels of urgency. Again, helping them is firmly in the hands of front-end developers. There is very little in between the characters we type into our text editors and the users for whom we wish to serve.

Being a front-end developer puts us on the front lines between the thing we’re building and the people we’re building it for, and that’s a place some of us really enjoy being.

That’s some weighty stuff, isn’t it? I haven’t even mentioned React yet.

The “we care about the users” thing might feel a little precious. I’d think in a high functioning company, everyone would care about the users, from the CEO on down. It’s different, though. When we code a <button>, we’re quite literally putting a button into a browser window that users directly interact with. When we adjust a color, we’re adjusting exactly what our sighted users see when they see our work.

That’s not far off from a ceramic artist pulling a handle out of clay for a coffee cup. It’s applying craftsmanship to a digital experience. While a back-end developer might care deeply about the users of a site, they are, as Monica Dinculescu once told me in a conversation about this, “outsourcing that responsibility.”

We established that front-end developers are browser people. The job is making things work well in browsers. So we need to understand the languages browsers speak, namely: HTML, CSS, and JavaScript². And that’s not just me being some old school fundamentalist; it’s through a few decades of everyday front-end development work that knowing those base languages is vital to us doing a good job. Even when we don’t work directly with them (HTML might come from a template in another language, CSS might be produced from a preprocessor, JavaScript might be mostly written in the parlance of a framework), what goes the browser is ultimately HTML, CSS, and JavaScript, so that’s where debugging largely takes place and the ability of the browser is put to work.

CSS will always be my favorite and HTML feels like it needs the most love — but JavaScript is the one we really need to examine The last decade has seen JavaScript blossom from a language used for a handful of interactive effects to the predominant language used across the entire stack of web design and development. It’s possible to work on websites and writing nothing but JavaScript. A real sea change.

JavaScript is all-powerful in the browser. In a sense, it supersedes HTML and CSS, as there is nothing either of those languages can do that JavaScript cannot. HTML is parsed by the browser and turned into the DOM, which JavaScript can also entirely create and manipulate. CSS has its own model, the CSSOM, that applies styles to elements in the DOM, which JavaScript can also create and manipulate.

This isn’t quite fair though. HTML is the very first file that browsers parse before they do the rest of the work needed to build the site. That firstness is unique to HTML and a vital part of making websites fast.

In fact, if the HTML was the only file to come across the network, that should be enough to deliver the basic information and functionality of a site.

That philosophy is called Progressive Enhancement. I’m a fan, myself, but I don’t always adhere to it perfectly. For example, a <form> can be entirely functional in HTML, when it’s action attribute points to a URL where the form can be processed. Progressive Enhancement would have us build it that way. Then, when JavaScript executes, it takes over the submission and has the form submit via Ajax instead, which might be a nicer experience as the page won’t have to refresh. I like that. Taken further, any <button> outside a form is entirely useless without JavaScript, so in the spirit of Progressive Enhancement, I should wait until JavaScript executes to even put that button on the page at all (or at least reveal it). That’s the kind of thing where even those of us with the best intentions might not always toe the line perfectly. Just put the button in, Sam. Nobody is gonna die.

JavaScript’s all-powerfulness makes it an appealing target for those of us doing work on the web — particularly as JavaScript as a language has evolved to become even more powerful and ergonomic, and the frameworks that are built in JavaScript become even more-so. Back in 2015, it was already so clear that JavaScript was experiencing incredible growth in usage, Matt Mullenweg, the founding developer of WordPress, gave the developer world homework: “Learn JavaScript Deeply”³. He couldn’t have been more right. Half a decade later, JavaScript has done a good job of taking over front-end development. Particularly if you look at front-end development jobs.

While the web almanac might show us that only 5% of the top-zillion sites use React compared to 85% including jQuery, those numbers are nearly flipped when looking around at front-end development job requirements.

I’m sure there are fancy economic reasons for all that, but jobs are as important and personal as it gets for people, so it very much matters.

So we’re browser people in a sea of JavaScript building things for people. If we take a look at the job at a practical day-to-day tasks level, it’s a bit like this:

  • Translate designs into code
  • Think in terms of responsive design, allowing us to design and build across the landscape of devices
  • Build systemically. Construct components and patterns, not one-offs.
  • Apply semantics to content
  • Consider accessibility
  • Worry about the performance of the site. Optimize everything. Reduce, reuse, recycle.

Just that first bullet point feels like a college degree to me. Taken together, all of those points certainly do.

This whole list is a bit abstract though, so let’s apply it to something we can look at. What if this website was our current project?

Our brains and fingers go wild!

  • Let’s build the layout with CSS grid. 
  • What fonts are those? Do we need to load them in their entirety or can we subset them? What happens as they load in? This layout feels like it will really suffer from font-shifting jank. 
  • There are some repeated patterns here. We should probably make a card design pattern. Every website needs a good card pattern. 
  • That’s a gorgeous color scheme. Are the colors mathematically related? Should we make variables to represent them individually or can we just alter a single hue as needed? Are we going to use custom properties in our CSS? Colors are just colors though, we might not need the cascading power of them just for this. Should we just use Sass variables? Are we going to use a CSS preprocessor at all?
  • The source order is tricky here. We need to order things so that they make sense for a screen reader user. We should have a meeting about what the expected order of content should be, even if we’re visually moving things around a bit with CSS grid.
  • The photographs here are beautifully shot. But some of them match the background color of the site… can we get away with alpha-transparent PNGs here? Those are always so big. Can any next-gen formats help us? Or should we try to match the background of a JPG with the background of the site seamlessly. Who’s writing the alt text for these?
  • There are some icons in use here. Inline SVG, right? Certainly SVG of some kind, not icon fonts, right? Should we build a whole icon system? I guess it depends on how we’re gonna be building this thing more broadly. Do we have a build system at all?
  • What’s the whole front-end plan here? Can I code this thing in vanilla HTML, CSS, and JavaScript? Well, I know I can, but what are the team expectations? Client expectations? Does it need to be a React thing because it’s part of some ecosystem of stuff that is already React? Or Vue or Svelte or whatever? Is there a CMS involved?
  • I’m glad the designer thought of not just the “desktop” and “mobile” sizes but also tackled an in-between size. Those are always awkward. There is no interactivity information here though. What should we do when that search field is focused? What gets revealed when that hamburger is tapped? Are we doing page-level transitions here?

I could go on and on. That’s how front-end developers think, at least in my experience and in talking with my peers.

A lot of those things have been our jobs forever though. We’ve been asking and answering these questions on every website we’ve built for as long as we’ve been doing it. There are different challenges on each site, which is great and keeps this job fun, but there is a lot of repetition too.

Allow me to get around to the title of this article. 

While we’ve been doing a lot of this stuff for ages, there is a whole pile of new stuff we’re starting to be expected to do, particularly if we’re talking about building the site with a modern JavaScript framework. All the modern frameworks, as much as they like to disagree about things, agree about one big thing: everything is a component. You nest and piece together components as needed. Even native JavaScript moves toward its own model of Web Components.

I like it, this idea of components. It allows you and your team to build the abstractions that make the most sense to you and what you are building.

Your Card component does all the stuff your card needs to do. Your Form component does forms how your website needs to do forms. But it’s a new concept to old developers like me. Components in JavaScript have taken hold in a way that components on the server-side never did. I’ve worked on many a WordPress website where the best I did was break templates into somewhat arbitrary include() statements. I’ve worked on Ruby on Rails sites with partials that take a handful of local variables. Those are useful for building re-usable parts, but they are a far cry from the robust component models that JavaScript frameworks offer us today.

All this custom component creation makes me a site-level architect in a way that I didn’t use to be. Here’s an example. Of course I have a Button component. Of course I have an Icon component. I’ll use them in my Card component. My Card component lives in a Grid component that lays them out and paginates them. The whole page is actually built from components. The Header component has a SearchBar component and a UserMenu component. The Sidebar component has a Navigation component and an Ad component. The whole page is just a special combination of components, which is probably based on the URL, assuming I’m all-in on building our front-end with JavaScript. So now I’m dealing with URLs myself, and I’m essentially the architect of the entire site. [Sweats profusely]

Like I told ya, a whole pile of new responsibility.

Components that are in charge of displaying content are almost certainly not hard-coded with data in them. They are built to be templates. They are built to accept data and construct themselves based on that data. In the olden days, when we were doing this kind of templating, the data has probably already arrived on the page we’re working on. In a JavaScript-powered app, it’s more likely that that data is fetched by JavaScript. Perhaps I’ll fetch it when the component renders. In a stack I’m working with right now, the front end is in React, the API is in GraphQL and we use Apollo Client to work with data. We use a special “hook” in the React components to run the queries to fetch the data we need, and another special hook when we need to change that data. Guess who does that work? Is it some other kind of developer that specializes in this data layer work? No, it’s become the domain of the front-end developer.

Speaking of data, there is all this other data that a website often has to deal with that doesn’t come from a database or API. It’s data that is really only relevant to the website at this moment in time.

  • Which tab is active right now?
  • Is this modal dialog open or closed?
  • Which bar of this accordion is expanded?
  • Is this message bar in an error state or warning state?
  • How many pages are you paginated in?
  • How far is the user scrolled down the page?

Front-end developers have been dealing with that kind of state for a long time, but it’s exactly this kind of state that has gotten us into trouble before. A modal dialog can be open with a simple modifier class like <div class="modal is-open"> and toggling that class is easy enough with .classList.toggle(".is-open"); But that’s a purely visual treatment. How does anything else on the page know if that modal is open or not? Does it ask the DOM? In a lot of jQuery-style apps of yore, yes, it would. In a sense, the DOM became the “source of truth” for our websites. There were all sorts of problems that stemmed from this architecture, ranging from a simple naming change destroying functionality in weirdly insidious ways, to hard-to-reason-about application logic making bug fixing a difficult proposition.

Front-end developers collectively thought: what if we dealt with state in a more considered way? State management, as a concept, became a thing. JavaScript frameworks themselves built the concept right in, and third-party libraries have paved and continue to pave the way. This is another example of expanding responsibility. Who architects state management? Who enforces it and implements it? It’s not some other role, it’s front-end developers.

There is expanding responsibility in the checklist of things to do, but there is also work to be done in piecing it all together. How much of this state can be handled at the individual component level and how much needs to be higher level? How much of this data can be gotten at the individual component level and how much should be percolated from above? Design itself comes into play. How much of the styling of this component should be scoped to itself, and how much should come from more global styles?

It’s no wonder that design systems have taken off in recent years. We’re building components anyway, so thinking of them systemically is a natural fit.

Let’s look at our design again:

A bunch of new thoughts can begin!

  • Assuming we’re using a JavaScript framework, which one? Why? 
  • Can we statically render this site, even if we’re building with a JavaScript framework? Or server-side render it? 
  • Where are those recipes coming from? Can we get a GraphQL API going so we can ask for whatever we need, whenever we need it?
  • Maybe we should pick a CMS that has an API that will facilitate the kind of front-end building we want to do. Perhaps a headless CMS?
  • What are we doing for routing? Is the framework we chose opinionated or unopinionated about stuff like this?

  • What are the components we need? A Card, Icon, SearchForm, SiteMenu, Img… can we scaffold these out? Should we start with some kind of design framework on top of the base framework?
  • What’s the client state we might need? Current search term, current tab, hamburger open or not, at least.
  • Is there a login system for this site or not? Are logged in users shown anything different? 
  • Is there are third-party componentry we can leverage here?
  • Maybe we can find one of those fancy image components that does blur-up loading and lazy loading and all that.

Those are all things that are in the domain of front-end developers these days, on top of everything that we already need to do. Executing the design, semantics, accessibility, performance… that’s all still there. You still need to be proficient in HTML, CSS, JavaScript, and how the browser works. Being a front-end developer requires a haystack of skills that grows and grows. It’s the natural outcome of the web getting bigger. More people use the web and internet access grows. The economy around the web grows. The capability of browsers grows. The expectations of what is possible on the web grows. There isn’t a lot shrinking going on around here.

We’ve already reached the point where most front-end developers don’t know the whole haystack of responsibilities. There are lots of developers still doing well for themselves being rather design-focused and excelling at creative and well-implemented HTML and CSS, even as job posts looking for that dwindle.

There are systems-focused developers and even entire agencies that specialize in helping other companies build and implement design systems. There are data-focused developers that feel most at home making the data flow throughout a website and getting hot and heavy with business logic. While all of those people might have “front-end developer” on their business card, their responsibilities and even expectations of their work might be quite different. It’s all good, we’ll find ways to talk about all this in time.

In fact, how we talk about building websites has changed a lot in the last decade. Some of my early introduction to web development was through WordPress. WordPress needs a web server to run, is written in PHP, and stores it’s data in a MySQL database. As much as WordPress has evolved, all that is still exactly the same. We talk about that “stack” with an acronym: LAMP, or Linux, Apache, MySQL and PHP. Note that literally everything in the entire stack consists of back-end technologies. As a front-end developer, nothing about LAMP is relevant to me.

But other stacks have come along since then. A popular stack was MEAN (Mongo, Express, Angular and Node). Notice how we’re starting to inch our way toward more front-end technologies? Angular is a JavaScript framework, so as this stack gained popularity, so too did talking about the front-end as an important part of the stack. Node and Express are both JavaScript as well, albeit the server-side variant.

The existence of Node is a huge part of this story. Node isn’t JavaScript-like, it’s quite literally JavaScript. It makes a front-end developer already skilled in JavaScript able to do server-side work without too much of a stretch.

“Serverless” is a much more modern tech buzzword, and what it’s largely talking about is running small bits of code on cloud servers. Most often, those small bits of code are in Node, and written by JavaScript developers. These days, a JavaScript-focused front-end developer might be writing their own serverless functions and essentially being their own back-end developer. They’ll think of themselves as full-stack developers, and they’ll be right.

Shawn Wang coined a term for a new stack this year: STAR or Design System, TypeScript, Apollo, and React. This is incredible to me, not just because I kind of like that stack, but because it’s a way of talking about the stack powering a website that is entirely front-end technologies. Quite a shift.

I apologize if I’ve made you feel a little anxious reading this. If you feel like you’re behind in understanding all this stuff, you aren’t alone.

In fact, I don’t think I’ve talked to a single developer who told me they felt entirely comfortable with the entire world of building websites. Everybody has weak spots or entire areas where they just don’t know the first dang thing. You not only can specialize, but specializing is a pretty good idea, and I think you will end up specializing to some degree whether you plan to or not. If you have the good fortune to plan, pick things that you like. You’ll do just fine.

The only constant in life is change.

– Heraclitus     – Motivational Poster         – Chris Coyier

¹ I’m a white dude, so that helps a bunch, too. ↩️
² Browsers speak a bunch more languages. HTTP, SVG, PNG… The more you know the more you can put to work! ↩️
³ It’s an interesting bit of irony that WordPress websites generally aren’t built with client-side JavaScript components. ↩️

The post The Widening Responsibility for Front-End Developers appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , ,

ooooops I guess we’re* full-stack developers now

*by “we’re” i mean front-end developers

This is a written version of a talk from Jamstack Conf London in 2019 that I put together for attendees. Because, the day before I was to board a flight for that trip, I flew off my mountain bike and broke both my arms. I felt bad that I couldn’t deliver the talk, so I both recorded it and made this. I’m moving it here because I like to keep a lot of my writing under one roof and to have a little fun with WordPress Gutenberg.

👋 Hey! I’ve spent my whole career self-identifying as a front-end developer and trying to help others become better at it.

and boy are my arms tired

I run the site CSS-Tricks (which recently had its 12th birthday), a resource site all about building websites.

I also co-founded the site CodePen, a social coding platform all about building things with front-end technology.

I also co-host a podcast called ShopTalk Show which is going on 400 episodes.

I’m sure I’ve talked to thousands of other developers over the years, which has helped me understand the industry and the spectrum of work it takes to make websites happen.

What is a front-end developer?

✅ It’s a job and a common job title.

This is important because it’s not just semantics. It’s a job that people are hired to do, and it is their job title at work. Nothing more personal than money.

How we define what this job is and what the expectations are is personal.

Look at any job board that has technology jobs on it and you’ll see postings for front-end developers.

What is a front-end developer?

✅ It deals very directly with the browser, devices, and users.

Everybody that works on websites probably has their browser open all day, but front-end developers live in there. They have DevTools open. They have multiple browsers open and test across versions and platforms.

Crucially, they care about the users that interact with those browsers and assistive technology.

Mina Markham explains what a front-end developers is at a high level:

There is a distinction from back-end developers. Its not that back-end developers don’t care about users, it’s just that responsibility is delegated.

Monica Dinculescu puts it well:

The browser is at the heart of the job of front-end development. Whatever you are doing, if your concern is how things ultimately look and work in a browser, that’s front-end development.

It’s harder than it gets credit for.

What is a front-end developer?

✅ There are loads of tools involved, but ultimately it comes down to HTML, CSS, and JavaScript.

Those are the languages that browsers speak. Yes yes, there is SVG and PNG and whatever else also, but you know what I mean.

Whatever other tooling you use, it all comes down to what ships to the browser, and front-end developers are responsible for that.

They are gonna come up at work.

Not all front-end developers know all the languages equally well. In fact, there are lots of developers out there who hardly write any JavaScript at all, but who are otherwise very successful front-end developers. And there are also a lot of front-end developers who write almost nothing but JavaScript. 🤯

My article The Great Divide digs into the split between front-end developers who are deeply into JavaScript and those who are not.

It’s not just my thoughts, but a collection of quotes from many others who feel the divide.

Brad Frost coins the terms “Front of the Front” and “Back of the Front” as a way to describe another sort of divide. He points out that it’s not a weakness, but a strength in putting those different people together.

At Google, the divide is recognized and split by job title. Plus, those two career ladders get paid the same.

Front-End Developer is a real and meaningful term.

There is no doubt about it. Particularly since about 2015, JavaScript has exploded as a language.

(If you need to look at these bigger, use DevTools or whatever. C’mon you’re front-end developers right?)

Our jobs are already facinating! So we all deal with browsers and users and devices. That’s core. But we all know different stuff, and actually put that knowledge to work.

Some of us are designers. Some of us are photographers. Some of us know the law really well. Some of us are way into performance. Some of us specialize in accessibility. Some of us embrace social media.

Metaphorically, you could map us like this tree.

This metaphor probably doesn’t hold up quite perfectly, but the divide looks a little something like this. We still share some fundamentals, and we still branch out and know lots of different stuff, but one side is heavily focused on JavaScript and “Back of the Front” type work and the other is not.

Since this talk is about the slow morphing of front-end developers starting to do more full-stack work and having that role grow wider and wider, let’s just assume we’re talking about front-end developers who go down the heavier JavaScript road.

A bunch of stuff you need to do to build websites has sort of moved stacks.

Back End → JavaScript

That is, from more of a back-end-and-friends skillset to a front-end-and-friends skillset.

Component-Driven Design & Development

Thanks, Obama JavaScript.

It seems to me non-JavaScript server-side rendered projects never really embraced components. (There are examples, don’t @ me, but I mean across the gigantic PHP CMS landscape and Ruby on Rails and huge players like that.) You had templates and includes, but they are a pale comparison to real component-driven development.

It’s facinating to see that while there is a wide variety of JavaScript-based frameworks that all disagree on plenty of things, one thing they all agree on is the idea of components. Even native web components… it’s right in the name.

Let’s take a quick look at CodePen, which is a React powered site (mostly) these days.

Even this tiny little SVG icon? It’s a component. We call it an <SVGIcon /> component because it nicely abstracts away a few things that are useful to us.

Pairing an icon with a number is another component, because it is another repeated pattern and might have additional responsibility, like being clicked.

That whole row of MetaItem components might become a component, along with other aspects of an Item’s display

So of course the whole Item itself becomes a component.

These are visual and functional abstractions of what we need to build the UIs. There is semantic HTML underneath, but the abstractions are building blocks of our own devise.

Larger and larger areas become components. In this case, it makes sense that a grid of items becomes a component, so that it can handle that layout and things like pagination.

It’s true! Not only are components capable of being intelligent building block abstractions for UIs for front-end developers, but designers are also largely already working this way. Tools like Figma, Sketch, and Adobe XD tout things like “symbols” which are spiritually connected.

I find other developers are like “cool, components, I get it”.

Site-Level Architecture / Routing

Back End → JavaScript

OK I guess this is my job now. It makes sense and I like the control, but it’s a big serious job.

Dealing with URLs and overall site structure used to feel primarily like a back end concern. These days, “routing” is becoming more and more a front-end concern.

<Suspense fallback={<Spinner />}>   <Route     exact     path={['/', '/picked-pens']}     component={anon ? AnonHomepage : Homepage}   />   <Route path={['/topics', '/topic']} component={Topics} />   <Route path={['/challenges']} component={Challenges} />   <Route path="/instagram" component={Instagram} />   <Route path="/dashboard" component={Dashboard} />   <Route     path={['/profile_new/:username', '/profile_new/team/:teamname']}     component={Profile}   /> </Suspense>

Looking back at the CodePen UI, the components don’t stop at the grid. Literally everything becomes a component. The tabs, the titles, the buttons…

… the forms, the menus, the sidebar…

Ultimately the whole gosh-darned page becomes a component.

Once the whole page is a component, what you’ve really done is turned the the URL into a component.

And now that the URL is a component, all the URLs are components, and you’re controlling the whole site.

You’ve become an architect of the entire site, in a sense.

That’s… a lot. Think of all the work you already have to do as a front-end developer. None of that goes away. You’re just responsible for a lot more now. It’s no wonder that front-end developers are feeling more and more full-stack-y.

State Management + Getting & Mutating Data

Back End → JavaScript

Another thing that has fallen into the hands of front-end developers is state management. Now that’s kind of at the core of most JavaScript frameworks and it’s a pretty great concept that wipes away a lot of front-end spaghetti problems of the past.

But state is often filled from getting data, and that’s now often on our shoulders as well.

Even more complicated is changing that data when necessary and sending data back to servers when required.

GraphQL is a pretty great answer to some of this. GraphQL is a lot of things and meaningful to different people in different ways. But to me, it’s about empowerment.

With a strong GraphQL endpoint in place, and tools like Apollo giving me tools to use in my JavaScript framework, I can, as a front-end developer, get my hands on any data I need to build UI.

import gql from "graphql-tag"; import { Query } from "react-apollo";  const GET_DOGS = gql`   {     dogs {       id       breed     }   } `;  const Dogs = () => (   <Query query={GET_DOGS}>     {({ loading, error, data }) => {       if (loading) return `Loading...`;       if (error) return `Error`;        return (         {data.dogs.map(dog => (           <div key={dog.id}>             {dog.breed}           </div>         ))}       );     }}   </Query> );

Note that not only am I getting all my own data, but I’m also managing the asynchronous nature of the component. Should I show a skeleton right away? A spinner? Should I delay rendering until the data is ready? What happens if it times out or there is another error?

Not only can I get data, but it’s on me update that data and send it back through GraphQL in the form of mutations.

mport gql from "graphql-tag"; import { Mutation } from "react-apollo";  const ADD_TODO = gql`   mutation AddTodo($ type: String!) {     addTodo(type: $ type) {       id       type     }   } `;  const AddTodo = () => {   let input;    return (     <Mutation mutation={ADD_TODO}>       {(addTodo, { data }) => (         <div>           <form             onSubmit={e => {               e.preventDefault();               addTodo({ variables: { type: input.value } });               input.value = "";             }}           >             <input               ref={node => {                 input = node;               }}             />             <button type="submit">Add Todo</button>           </form>         </div>       )}     </Mutation>   ); };

Mutations aren’t terribly more complicated than queries, but it’s all the more work that is on my plate as a front-end developer. Work that was almost surely in the realm of back-end development before.

Note that the above examples were illustrative of GraphQL, but done through Apollo Client implemented in React.

While we’re talking about components, queries, and mutations, let’s throw one more thing on the pile: styling.

Front-end developers have always been in charge of styling, but in a land of components that are self-contained in so many other ways, it starts to make sense to co-locate the styling information as well.

Here we’re using CSS modules to scope the styles to a specific component. We can and do still have global styles, and we even continue to use Sass for useful global abstractions.

.root {   display: grid; }
import styles from './styles.scss';  <NewsItems className={styles.root} />

The result of this componentization and co-locating is nice little folders that have everything from logic, to view templates, to queries and mutations, to styling all together.

It’s convenient, but it has cool interesting side effects. For example, JavaScript bundles may contain what they need (code splitting). Styling doesn’t get bloated because when components stop being used because their styles leave with them. Not to mention naming things is a lot less stressful since the naming is file-scoped.

The GraphQL documentary is kinda fun. I like what Kyle Mathews says (about 20:24) about React wiping away a whole class of front-end development problems, and how GraphQL does a similar sort of thing.

For every project? Of course not. But for the somewhat large and complex apps that we’re so often expected to build and maintain: yes.

All the very huge responsibilities front-end developers already have:

  • Pulling of the design
  • Making the design part of a system
  • Making sure it is accessible
  • Worrying about the performance
  • Testing things across browsers
  • Testing things across devices
  • Sweating the UX

Oh hello, big pile of new responsibilities

  • Component-driven design, designing our own abstractions
  • Site-level architecture
  • Routing
  • Fetching our own data
  • Talking to APIs
  • Mutating data
  • State management

The haystack of responsibilities grows and grows and grows.

That’s not to say that all of us need to know every single part of this and do it perfectly well, but it is to say that these are tasks that fall within the realm of front-end web development.

Peggy Rayzis talks about how wide the term front-end developer has gotten and that it’s likely we’re specializing.

Again, a bunch of tasks have sort of moved stacks. From what used to be rather back-end jobs to being in the JavaScript realm.

Let’s draw a spectrum and see how that has morphed through time.

LAMP is Linux, Apache, MySQL,and PHP. It’s a rather old stack, but it’s still very huge. It’s what an awful lot of CMS’s run. LAMP is how the stack is talked about.

If I’m a front-end developer working in that stack, I’m way over on the other side of the spectrum, not touching much of the technology the stack is referring to.

MEAN is another stack, referring to MongoDB, Express, Angular, and Node. Notice the OS isn’t mentioned anymore.

Notably, Angular is a front-end framework, so the stack is starting to include that. If I’m a front-end developer, what I’m working on overlaps with the stack.

Serverless moves the stack further to the right. We don’t even care what servers the code runs on anymore, it’s just server-side code using and creating APIs.

If I’m a front-end developer working in this world, I overlap in that I might even be using my JavaScript abilities to be writing these serverless functions and digesting the APIs.

Shawn Wang called Design Systems, TypeScript, Apollo GraphQL, and React a STAR app.

That’s… like… all front end stuff.

It seems to me the way we talk about the important technology that powers websites shifts more and more toward the front-end developer spectrum.

Let’s take a quick look at how serverless is expanding our front-end powers.

I made a website about serverless stuff because I think it’s cool and a big deal.

I consider JAMstack to essentially be a part of the serverless movement. Natch.

Javascript, APIs, and Markup. Although I would say, half tongue-in-cheek, that SHAMstack makes a bit more sense.

Here’s a perfect example of a JAMstack site that leverages serverless tech to do the things it needs to do.

It’s a site that lists upcoming conferences related to front-end development.

--- title: JAMstack_conf_ldn url: 'https://jamstackconf.com/london/' cocUrl: 'https://jamstackconf.com/london/code-of-conduct' date: 2019-07-09T08:00:00.000Z endDate: 2019-07-10T16:00:00.000Z location: 'London, England' byline: 'Learn how to design, develop, and deploy fast, modern web projects that run without web servers.' ---  Following the inaugural [JAMstack_conf in San Francisco](https://2018.jamstackconf.com/) in 2018, we're now also bringing an edition to London where we'll have talks about how to design, develop, and deploy fast, modern web projects that run without web servers.

Each conference is a Markdown file with Front Matter to describe meta data associated with the conference, like the city and dates.

I wasn’t deliberately trying to avoid a database, but this just seemed like the perfect kind of site to use a static site generator for and the data needs are so basic that flat Markdown files are a natural fit.

So each conference is a Markdown file, and there are some basic templates in Nunjucks, and Eleventy is wonderful for processing that kind of setup.

The site is a public repo on GitHub. That seems obvious, perhaps, but I think it’s hugely significant here.

It means that:

  1. The entire site is in the repo. To run it, you pull it down and run a single command.
  2. There is no fiddling with log ins, permissions, or credentials.
  3. It opens up the content of the site for public contributions, as well as the design and functionality. This has been huge.

The site being on GitHub means I could just leave it on GitHub Pages, but it’s like a 2-second process to put in on Netlify, which is a massive improvement. Here’s a few reasons:

  • Deploy previews. When I get a Pull Request, I can take a look at a live URL of what the site will be like with that Pull Request merged. Amazing.
  • I can activate Analytics on the site and get the most accurate possible numbers.
  • I can fiddle with my images programmatically.

There are a couple other big ones though…

With Netlify CMS, I get a UI to edit content right on the site itself. No code editing or Git involved at all once it’s set up.

I don’t even need Netlify to use Netlify CMS, but Netlify Identity makes the auth part a million times easier.

Check out this feature of the conference site. For each conference, you can click a button that reveals an email input form. Enter an email and submit, and the site fires off an email with details about the conference.

That’s a back-end thing. You can’t really send email with client-side technology alone. You can communicate with APIs that will send email, but even that requires API keys that need to be kept secret via back-end code.

const SparkPost = require('sparkpost'); const client = new SparkPost(process.env.SPARKPOST);  exports.handler = function(event, context, callback) {   client.transmissions     .send({       content: {         from: 'chris@css-tricks.com',         subject: `Conference!`,         html: `           <html>             <body>               <h1>Hello, World!</h1>             </body>           </html>`       },       recipients: [{ address: email }]     })     .then(data => {       callback(null, {         statusCode: 200,         body: `Message sent!`       });     }); };

I’ll use Sparkpost to send the email. They offer APIs to send email (that’s the entire point). They also offer a Node.js library to make it very easy. Ultimately just a few lines of code.

And that code? It’s JavaScript. I’m a JavaScript developer. This is not a stretch.

How do I run this?

That’s the meat and potatoes of serverless: cloud functions. I’m talking about AWS LambdaAzure FunctionsGoogle Cloud Functions, etc.

The Netlify version, which is AWS Lamba under the hood, is Netlify Functions. It’s stupid easy. You just toss your functions in a `/functions/` folder and run them by hitting a relative URL.

It feels very powerful to be able to build the entire site from front to back like that.

Let’s revisit the spectrum of technology again with this modern stuff in mind.

I don’t really have to care about operating systems and servers. Entire products can be built without having to care about these.

I probably don’t need to care much about databases either. It’s not that databases aren’t important, it’s just that my dealing with data is likely to happen through APIs. Perhaps a Headless CMS (e.g. Contentful). Perhaps a data storage tool that is designed to work through APIs (e.g. FaunaDB) or on-page libraries (e.g. Firestore).

So now I’m left with a spectrum of technology where I can work with all parts of it.

So I’m feeling pretty full-stacky already. But you take all that and add in:

  • I know Git
  • I can write tests
  • I design
  • I know about build processes
  • I care about performance
  • I can make sites accessible
  • I can set up a basic deploy pipeline

You’re Gosh
Danged Right
I’m a Full-Stack


The haystack of skills here is getting extremely large.

You can totally specialize. You probably will anyway. That’s good.

“Actual” unicorns, those people that are very good at every task across the entire spectrum of building websites: as rare as actual unicorns.

I’m also not trying to insinuate that back-end developers are becoming obsolete. In fact, the fact that building websites has gotten so damn complex, they are more important than ever.

Right now, I can open up the CodePen issue tracker and see 89 issues that I can’t solve alone. I need back-end developer help to dig into them and fix them. I can think of myself as full-stacky if I want, but I know that back-end stuff is where my rough edges are.

Things tend to end up a bit more like this.

Or in my case, more like this:

That’s not to make fun of anybody. I mean, maybe a little, but it draws a nice metaphor that is kinda perfect for this talk. We are the whole horse! The whole dragon! But we’ve got rough edges. So what.

It’s cool to see the tech around our job evolve to the point that we can reach our arms around the whole thing. It’s worthy of some concern when we feel like complication of web technology feels like it’s raising the barrier to entry. That happens sometimes and it’s not great. But it’s also worthy of cheer when web technology becomes simple enough that people can build things from start to finish all by themselves. That’s pretty cool.

While we’re being all productive and amazing, let’s just remember that doing a good job is everybodies job.

  • Good UX is everyone’s job
  • Good performance is everyone’s job
  • Good security is everyone’s job
  • Good accessibility is everyone’s job
  • Doing right by the people that use your website is everyone’s job

Even if you aren’t writing the code that directly affects any of those things, you care about them and fight for them to be handled well.

CodePen PRO (support your local artisanal craft software products with money)

The post ooooops I guess we’re* full-stack developers now appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , ,

How to Disable Code: The Developer’s Production Kill Switch

The following is a guest post written by Carlos Schults.

Being able to disable code in production is a power that many developers aren’t aware of. And that’s a shame. The ability to switch off some portions—or even complete features—of the codebase can dramatically improve the software development process by allowing best practices that can shorten feedback cycles and increase the overall quality.

So, that’s what this post will cover: the mechanisms you can use to perform this switching off, why they’re useful and how to get started. Let’s dig in.

Why Would You Want to Disable Code?

Before we take a deep dive into feature flags, explaining what they are and how they’re implemented, you might be asking: Why would people want to switch off some parts of their codebase? What’s the benefit of doing that?

To answer these questions, we need to go back in time to take a look at how software was developed a couple of decades ago. Time for a history lesson!

The Dark Ages: Integration Hell

Historically, integration has been one of the toughest challenges for teams trying to develop software together. 

Picture several teams inside an organization, working separately for several months, each one developing its own feature. While the teams were working in complete isolation, their versions of the application were evolving in different directions. Now they need to converge again into a single, non conflicting version. This is a Herculean task. 

That’s what “integration hell” means: the struggle to merge versions of the same application that have been allowed to diverge for too long. 

Enter the Solution: Continuous Integration

“If it hurts, do it more often.” What this saying means is that there are problems we postpone solving because doing so is hard. What you often find with these kinds of problems is that solving them more frequently, before they accumulate, is way less painful—or even trivial.

So, how can you make integrations less painful? Integrate more often.

That’s continuous integration (CI) in a nutshell: Have your developers integrate their work with a public shared repository, at the very least once a day. Have a server trigger a build and run the automated test suite every time someone integrates their work. That way, if there are problems, they’re exposed sooner rather than later.

How to Handle Partially Completed Features

One challenge that many teams struggle with in CI is how to deal with features that aren’t complete. If developers are merging their code to the mainline, that means that any developments that take more than one day to complete will have to be split into several parts. 

How can you avoid the customer accessing unfinished functionality? There are some trivial scenarios with similarly trivial solutions, but harder scenarios call for a different approach: the ability to switch off a part of the code completely.

Feature Flags to the Rescue

Defining Feature Flags

There are many names for the mechanisms that allow developers to switch a portion of their code off and on. Some call them “feature toggles” or “kill switches.” But “feature flags” is the most popular name, so that’s what we’ll use for the remainder of this post. So, what are feature flags?

Put simply, feature flags are techniques that allow teams to change the behavior of an application without modifying the code. In general, flags are used to prevent users from accessing and using the changes introduced by some piece of code, because they’re not adequate for production yet for a number of reasons.

Disable Code: What Are the Use Cases?

We’ll now cover some of the most common use cases for disabling code in production.

Switching Off Unfinished Features

As you’ve seen, one of the main use cases for feature flags is preventing users from accessing features that aren’t ready for use yet.

That way, programmers developing features that are more complex and take a longer time to complete aren’t prevented from integrating their work often and benefiting from it.

Enabling A/B Testing

The adoption of feature flags enables the use of several valuable practices in the software development process, one of which is A/B testing

A/B testing is a user experience research technique that consists of comparing two versions of a website or application to decide which one to keep. It entails randomly splitting users into two groups, A and B, and then delivering a different version of the application to each group. One group might receive the current production version, which we call the “control,” whereas the second group would receive the candidate for the new version, called the “treatment.” 

The testers then monitor the behavior of both groups and determine which of the versions achieved better results. 

Feature flags are a practical way to enable A/B testing because they allow you to quickly and conveniently change between the control and treatment versions of your application.

Enabling Canary Releases

If you deliver the new version of your app to your entire userbase at once, 100 percent of your users will be impacted if the release is bad in some way. What if you could gradually roll out the new version instead? You’d first deploy to a small subset of users, monitoring that group to detect issues. If something went wrong, you could roll it back. If everything looked fine, you could then gradually release the version for larger groups. That’s a canary release in a nutshell. It’s another powerful technique that feature flags might help with.

Customizing Features According to Users’ Preferences

It’s not uncommon to have to customize your application according to the needs of specific users, and there are several ways in which software teams can accomplish that—some more efficient, and others less so (companies that create separate branches or entire repositories for each client come to mind).

This is another area where feature flags could help, allowing teams to dynamically switch between different versions of the same functionality.

Disable Code in Production 101

How do you go about disabling code? That’s what we’re going to see now, in three increasingly sophisticated phases.

First Stage: The Most Basic Approach

We start with an approach that’s so primitive, it maybe shouldn’t be considered a feature flag at all. Consider the pseudocode below:

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {   // return calculateAdditionalWorkHoursSameOldWay(employee, start, end);   return calculateAdditionalWorkHoursImproved(employee, start, end); }

In the code above, we’re just commenting out the old version of some method and replacing it with a new version. When we want the older version to be used, we just do the opposite. (Well, I said it was primitive.) This approach lacks one of the most fundamental properties of a feature flag—the ability to change how the application behaves without changing its code.

However, it plants the seed for more sophisticated approaches.

Second Stage: Taking the Decision Out of the Code

The previous approach didn’t allow developers to select the desired version of the feature without changing the code. Fortunately, that’s not so hard to do. First, we introduce a logical variable to determine which version we’re going to use:

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {    var result = useNewCalculation     ? calculateAdditionalWorkHoursImproved(employee, start, end)     : calculateAdditionalWorkHoursSameOldWay(employee, start, end);    return result; }

Then, we use some mechanism to be able to assign the value to the variable from an external source. We could use a configuration file:

var useNewCalculation = config[newCalculation];

Passing arguments to the application might be another option. What matters is that we now have the ability to modify how the app behaves from the outside, which is a great step toward “true” feature flagging.

Keep in mind that the code examples you see are all pseudocode. Using your favorite programming language, there’s nothing stopping you from starting with this approach and taking it up a notch. You could, for instance, use classes to represent the features and design patterns (e.g., factories) to avoid if statements.

Stage 3: Full-Fledged Feature Flag Management

The previous approach might be enough when your application has only a small number of flags. But as that number grows, things start to become messy.

First, you have the issue of technical debt. Manually implemented feature flags can create terribly confusing conditional flows in your codebase. That only grows worse with new flags being introduced each day. Additionally, they might make the code harder to understand and navigate, especially for more junior developers, which is an invitation for bugs.

Another problem is that as the number of flags grows, it becomes more and more common to forget to delete old, obsolete ones.

The main problem of a homegrown approach is that it doesn’t give you an easy way to see and manage all of your flags at once. That’s why our third and final stage is a single piece of advice: Instead of rolling out your own feature flags approach, adopt a third-party feature flag management system.

Feature Flags Are a CI/CD Enabler

We’ve covered the mechanisms developers can use to disable portions of their codebase in production without having to touch the code. This capability is powerful and enables techniques such as A/B testing and canary releases, which are all hallmarks of a modern, agile-based software development process.

The names for the techniques might vary—feature flags, feature toggles, feature flipper, and so on. The way in which the techniques are implemented can also vary—from a humble if statement to sophisticated cloud-based solutions.

But no matter what you call them, you can’t overstate the benefit these mechanisms offer. They’re an enabler of Continuous Integration, which is essential for any modern software organization that wants to stay afloat.

The post How to Disable Code: The Developer’s Production Kill Switch appeared first on CSS-Tricks.


, , , , ,