At Zoosk we have a UI component called a tooltip. It resembles a speech bubble and provides helpful information to our users. It appears when you either click on, tap on, or hover over another element.

We have many tooltips on our desktop and mobile websites, and they come in several variations. I discovered that each time I created a new one, I duplicated CSS properties that had been used for older tooltips. This inspired me to write some Sass mixins to speed up development and make it easier to customize our tooltip designs.

First iteration

Initially I came up with the following mixin:

@mixin tooltip($bg, $border, $border-radius, $bottom, $box-shadow, $color, $font-size, $left, $padding, $right, $top) {
    background: $bg;
    border: $border;
    border-radius: $border-radius;
    bottom: $bottom;
    box-shadow: $box-shadow;
    color: $color;
    font-size: $font-size;
    left: $left;
    line-height: 1.5;
    padding: $padding;
    position: absolute;
    right: $right;
    top: $top;
}

I wasn’t happy with this because it has too many parameters. It would be hard to keep them straight in my head, and I prefer tidier code.

Second iteration

I grouped similar properties into separate mixins. My hope was that mixins with fewer parameters would be easier to manage and digest. Below is the first one which handles a tooltip’s position.

@mixin tooltip-position($top: false, $right: false, $bottom: false, $left: false) {
    position: absolute;

    @if $top != false {
        top: $top;
    }

    @if $right != false {
        right: $right;
    }

    @if $bottom != false {
        bottom: $bottom;
    }

    @if $left != false {
        left: $left;
    }

    @if $left == $right {
        margin-left: auto;
        margin-right: auto;
    }
}

All parameters are optional so they aren’t compiled unless a value is specified.

With that done, I needed mixins to handle a tooltip’s visual aspects. For the pointer arrow I wanted to use a rotated ::after pseudo-element. Pseudo-elements allow you to style special parts of DOM elements. ::after is a great candidate here because it can be styled much like a span. The following snippet shows the mixins for creating the pointer and other tooltip styles.

// CREATE THE POINTER
@mixin pointer-base-styles {
    &::after {
        content: "";
        position: absolute;
        transform: rotate(45deg);
    }
}

// BACKGROUND COLOR FOR THE TOOLTIP AND POINTER ARROW
@mixin tooltip-backgrounds($bg) {
    &, &::after {
        background: $bg;
    }
}

// FONT STYLES
@mixin tooltip-text($color: false, $font-size: false, $line-height: false) {
    color: $color;
    font-size: $font-size;
    line-height: $line-height;
}

// OTHER VISUAL TREATMENTS
@mixin tooltip-framing($padding: false, $border-radius: false, $shadow: false) {
    @if $padding != false {
        padding: $padding;
    } 

    @if $border-radius != false {
        border-radius: $border-radius;
    }

    @if $shadow != false {
        box-shadow: $shadow;
    }
}

So far so good. These mixins would be added to my tooltip’s CSS declaration block via @include.

Borders for the tooltip and pointer

You might have noticed that I haven’t addressed border styles. This was intentional; borders on the pointer affect how the pointer is positioned on a tooltip’s edge. Therefore, I needed a mixin that handles both the pointer’s position and any borders.

Before I get to that, I’d like to demonstrate how a pointer’s borders affect its position. Let’s say I have a tooltip design in which the pointer points left. I can use position: absolute; and left on the pointer to move its center to the tooltip’s left edge. If there are no borders, I can do some simple math in the left value to achieve this position.

If, however, there are borders, the code above won’t work because left doesn’t factor in the border width.

To fix this, I must include the border’s width in the left calculation. In addition it’s best to apply the same border on the pointer’s internal sides but with transparent as the color. This trick makes the new left calculation work consistently regardless of border width.

This is better, but while testing the code, I found a visual issue if the design required a drop shadow. Any shadow would be applied to both the tooltip and pointer. Because the pointer is above the tooltip in the DOM stacking order, the pointer’s shadow unfortunately appeared over the tooltip.

Because of this I decided to try the ::before pseudo-element to render the pointer’s shadow. Like its counterpart ::after, ::before can function as a separate element. I can manipulate its stacking order in the DOM with the goal of positioning it under the tooltip. With this in mind I started working on the next mixin.

Positioning the pointer

To position the pointer and its shadow (::after and ::before respectively), my next mixin must take into account the following factors:

• the tooltip side on which the pointer is aligned (left, right, top, or bottom)
• the pointer’s size
• the pointer’s border width

After much tinkering I came up with the mixin below. It accepts an additional parameter cross-position that moves the pointer and shadow along the tooltip side. Visual examples of pointer positions follow the snippet.

@mixin pointer-position($size, $side, $cross-position, $border-width) {
    $half-size: $size / 2;

    height: $size;
    width: $size;

    // MOVE PSEUDO-ELEMENTS OUTSIDE OF TOOLTIP BODY
    @if $border-width != 0 {
        #{$side}: calc(#{-$half-size} - #{$border-width});
    } @else {
        #{$side}: -$half-size;
    }

    // MOVE PSEUDO-ELEMENTS ALONG TOOLTIP SIDE
    @if $side == "left" or $side == "right" {
        @if $cross-position == "middle" {
            top: calc(50% - (#{$half-size} + #{$border-width}));
        } @else {
            top: $cross-position;
        }
    } @elseif $side == "bottom" or $side == "top" {
        @if $cross-position == "middle" {
            left: 0;
            margin: auto;
            right: 0;
        } @else {
            left: $cross-position;
        }
    }
}

Styling the pseudo-elements

Now I needed to apply visual treatments to the pseudo-elements. Since the pointer-position mixin takes an argument for side, I can leverage it within a new mixin to manage the pointer’s border display. How? I can rotate the ::after element differently based on the tooltip side. This will result in the pointer’s visible borders pointing in the correct direction. Below is the last mixin that does just that and also sets box-shadow.

// ADD TO TOOLTIP'S MAIN DIV DECLARATION BLOCK VIA @include
@mixin pointer-framing($size, $side, $cross-position, $border-width: 0, $border-style: false, $shadow: false) {
    &::before {
        z-index: -1; // Puts the shadow behind the tooltip

        @if $shadow != false {
            box-shadow: $shadow;
        }
    }

    &::after, &::before {
        @include pointer-position($size, $side, $cross-position, $border-width);
    }

    @if $border-width != 0 {
        border: $border-width $border-style; // For the tooltip; including it in this mixin allows us to pass border arguments once for both tooltip and ::after.

        &::after, &::before {
            border: $border-width solid transparent;
        }

        &::after {
            border-bottom: $border-width $border-style;
            border-left: $border-width $border-style;

            @if $side == "right" {
                transform: rotate(225deg);
            } @elseif $side == "bottom" {
                transform: rotate(-45deg);
            } @elseif $side == "top" {
                transform: rotate(135deg);
            }
        }
    }
}

I noticed that $shadow is a parameter here and in the mixin tooltip-framing I made earlier. The $shadow argument would likely be the same for both the tooltip and ::before, so I removed it from pointer-framing and updated the @if $shadow block in tooltip-framing.

@mixin tooltip-framing($padding: false, $border-radius: false, $shadow: false) {
    @if $padding != false {
        padding: $padding;
    } 

    @if $border-radius != false {
        border-radius: $border-radius;
    }

    @if $shadow != false {
        &, &::before {
            box-shadow: $shadow;
        }
    }
}

@mixin pointer-framing($size, $side, $cross-position, $border-width: 0, $border-style: false, $shadow: false) {
    &::before {
        z-index: -1; // Puts the shadow behind the tooltip
    }

    &::after, &::before {
        @include pointer-position($size, $side, $cross-position, $border-width);
    }

    @if $border-width != 0 {
        border: $border-width $border-style; // For the tooltip; including it in this mixin allows us to pass border arguments once for both tooltip and ::after.

        &::after, &::before {
            border: $border-width solid transparent;
        }

        &::after {
            border-bottom: $border-width $border-style;
            border-left: $border-width $border-style;

            @if $side == "right" {
                transform: rotate(225deg);
            } @elseif $side == "bottom" {
                transform: rotate(-45deg);
            } @elseif $side == "top" {
                transform: rotate(135deg);
            }
        }
    }
}

I also updated the pointer-base-styles mixin so it includes the ::before element.

@mixin pointer-base-styles {
    &::after, &::before {
        content: "";
        position: absolute;
        transform: rotate(45deg);
    }
}

Putting it all together

Below is a sample snippet using the mixins plus a screenshot of the resulting UI. You can also see live tooltips on CodePen. (Scroll down for an embedded demo.)

$denim: #A5C5EB;
$pointer-size: 1.6rem;
$shadow: .2rem .2rem .2rem rgba(0, 0, 0, .2);

.tooltip--button-info {
    @include pointer-base-styles;
    @include pointer-framing($pointer-size, bottom, middle, .3rem, solid darken($denim, 12%));
    @include tooltip-backgrounds($denim);
    @include tooltip-framing(1em, .4rem, $shadow);
    @include tooltip-position(-7.5rem, 0, false, 0);
    @include tooltip-text(darken($denim, 50%), 1.5rem, 1.25);
    box-sizing: border-box;
    text-align: center;
    width: 90%;
}

<div class="tooltip--button-info">
    <p>Vote for the candidates by clicking a button.</p>
</div>

But there’s a gotcha (and a workaround)

If your main tooltip div has a shadow plus the transform property, the shadow on the ::before will overlap the tooltip.

This looks very much like figure “Pointer Example 4” from earlier. With the transform property, the div becomes the new stacking context for its pseudo-elements. Therefore, the ::before can’t fall behind the tooltip, even with z-index: -1. You can get around this by wrapping your tooltip’s child elements in a new div then applying the following changes:

• Move all tooltip and pointer mixins from the main div to the new wrapper div except for tooltip-position.
• If the main div has width, move that to the new div as well.
• Add position: relative; to the new div so it’s still the positioning context for the pseudo-elements.

Below is an example of the workaround. My new div has the CSS class tooltip__body. Be aware that other scenarios can set your main div as a new stacking context, including position: fixed. Check out Mozilla’s article on stacking order for a list of these scenarios.

$alert: #EACBE4;
$pointer-size: 1.6rem;
$shadow: .2rem .2rem .2rem rgba(0, 0, 0, .2);

.tooltip--alert {
    @include tooltip-position(-3.3rem, false, false, 0);
    transform: translateX(calc(-100% - #{$pointer-size}));
        
    .tooltip__body {
        @include pointer-base-styles;
        @include pointer-framing($pointer-size, right, 3.7rem);
        @include tooltip-backgrounds($alert);
        @include tooltip-framing(1em, .6rem, $shadow);
        @include tooltip-text(darken($alert, 50%), 1.5rem, 1.25);  
        position: relative;
        width: 25rem;
    }
}

<div class="tooltip--alert tooltip">
    <div class="tooltip__body">
        <p><strong>WARNING</strong></p>
        <p>This might cause an allergic reaction.</p>
    </div>
</div>

Last thoughts

The mixins in this article allow you to customize your tooltips, but they also rely on a few assumptions:

• The light source for the drop shadow is the same for all your tooltips.
• The pointer is square with no border-radius.
• The portion of the pointer that sticks out past the tooltip’s edge is the same for all.

You should, of course, make your own customizations as needed. If your tooltips share common styles (such as pointer size, padding, and rounded corners), you can declare those once under a base CSS class for all of them. If you work with designers, you should advocate for standardized designs. If it’s out of your hands, I hope these mixins will help you create manageable and tidier tooltip styles. Below is a GitHub gist with all the code.

Customizing Tooltips with the Power of Sass Mixins was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

I spent a few days watching Udacity’s accessibility course by Google to get a handle on basic accessibility techniques. It turns out that accessibility isn’t as daunting as it might sound. This article summarizes what I learned from this course. The goal is to teach web developers accessibility techniques when creating a new feature or product.

FYI Udacity’s course uses the following assistive technologies for its demos:

• ChromeVox
• Mac OS VoiceOver

Both of these tools are screen readers for users with sight impairments.

For additional reading on accessibility you can check out the following resources:

• W3C’s Web Content Accessibility Guidelines (WCAG) Overview
• WebAIM checklist

Create good page structure with correct use of elements and DOM order.

Use landmark elements.

Landmark elements like header, nav, and footer are more useful to screen reader users because they define regions of a page. It’s best to use these instead of divs which have no native semantics.

Below is a graphic that labels several HTML5 landmark elements you can use to structure your pages. For more about these, check out Lesson 4 “Navigating Content,” Concept 10 “Landmarks” in the Udacity course.

Use elements that are focusable.

Right out of the box, native form elements, buttons, and anchors are focusable by keyboards, and keyboards can interact with them to provide input or perform an action. These elements are also automatically added to a page’s tab order. If you use non-focusable elements in place of these, you’ll have to add semantics and tabindex in your DOM as well as functionality so that keyboards can interact with them.

Arrange your focusable elements in a logical tab order.

The tab order of your elements will, and should, follow the order they appear in your DOM, so try to avoid using CSS that changes the visual order in which they appear. Otherwise, the focus styles might jump around the screen during tabbing. This will cause a confusing experience for mobility-challenged people using keyboards.

Below is an example that demonstrates this unexpected behavior. The “I’m first!” button will receive focus before the other two because it is first in the DOM.

Use heading tags in their logical order.

Creating a logical page structure includes using heading tags (h1, h2, h3, h4, h5, and h6) properly. Don’t use a heading tag simply because of its style. Your heading tags should follow in their natural hierarchical order. This way a screen reader user will understand the subsections within a section. You can use CSS to style your headings as you like.

Use anchor tags when appropriate and as intended.

Since some assistive technologies allow users to browse through all links on a page, using anchor tags with an href attribute and a valid value will make them accessible to the user.

The following are common anti-patterns developers use to present actionable text on their web pages (They should be avoided.):

1. Using an anchor tag, or a span styled as a link, with scripting to perform an action when the element is clicked.

In this example the span and anchor are not actionable with a keyboard. Try using a button as an alternative.

2. Using an anchor tag with a non-sensical href value plus scripting to perform an action.

In this example having a value of “#” for the anchor’s href attribute doesn’t make the anchor actionable by a keyboard. It’s best to replace the anchor with a button element.

3. Using an img element as link content.

The first example works for sighted users, but the image will not be available to assistive technologies. To fix it, add an alt attribute with a description of the image.

Do not remove focus styles from focusable elements.

A browser’s default focus styles are extremely important to users who use a keyboard to navigate a page. Focus styles visually indicate which interactive element is ready for input, and they also tell the user where he currently is in the page structure.

For many websites a browser’s default focus style doesn’t fit with the site’s design. Focus styles are easily customizable with CSS using the :focus pseudo-class. The course provides good tips on re-writing those styles.

Write helpful link text.

Text that is hyperlinked should be written in a way that describes the purpose of the link. The following examples demonstrate this:

• This website uses cookies to ensure you get the best experience on our website. For more information, see our cookie policy.
• Subscribe to our newsletter to get weekly updates in your inbox.

The following are examples of commonly used link strings that are considered an anti-pattern to accessibility (i.e. Don’t use these.):

• Learn more
• Read more
• Click here

Write helpful alt text for images.

A screen reader will read aloud the alt text for an image, so the text needs to describe what’s going on in the image in its given context. If there is no alt attribute, the image will be handled in different ways depending on which screen reader is being using. According to Oomph’s accessibility article (published January 25, 2019), JAWS will announce “blank,” and NVDA will announce nothing. VoiceOver will announce “unlabeled image.”

The screenshot below shows VoiceOver announcing and displaying the alt text associated with the teacup image.

If an image is deemed redundant, you can add an alt attribute to the image but with an empty value. This will remove the image from the screen reader’s accessibility DOM tree; therefore, the screen reader will not announce it.

Make your site responsive, and use relative units.

There are a number of reasons why developers should make their sites responsive with a mobile friendly layout. One of those reasons is that if a user zooms into a web page, the layout will at some point switch to the page’s mobile design. This is helpful because as the page content gets bigger, the mobile design will re-align the page sections for easier browsing and scrolling.

Relative units for font sizes and width, and in some cases margin and padding, are also very important. They allow the text size to increase if the user changes the browser’s font settings, and your page elements will scale accordingly. Below are examples of how two sites change with page zoom. The first one shows the W3C’s page adjusting to its mobile design where content is stacked. The next one shows that Wikipedia’s site does increase font size, but the layout doesn’t change. The welcome banner extends beyond the viewport, and the two-column layout, though still readable, is a little cramped.

Make sure your site meets the minimum contrast requirements.

The WCAG requires that your text, images, and other components provide a minimum amount of contrast against your chosen background color. You can test your UI’s contrast at WebAIM’s Contrast Checker.

Do not convey information with color alone.

Consider the form below. It does not display error messages if the user submits an invalid value. Instead, it uses color to indicate the error.

In this example the phone number is invalid because it’s missing an area code. Both colorblind and screen reader users can have an issue with this. The red line alone does not sufficiently tell those users there is a problem. To remedy this, you should add text that explains the error.

You can use the NoCoffee Chrome extension to simulate different visual impairments and determine how you can improve your UI.

Use the right role and ARIA attributes on elements without native semantics.

In some cases you might need to forgo the use of focusable elements (such as input, select, or button) and instead use divs or spans to create new stylized components. The first thing to do is assign a role to the component’s main element. The WAI-ARIA spec lists role descriptions that you can browse and determine which best suits your component.

If you click on any of the listed roles, you’ll find more information and a table of associated ARIA attributes, some of which are required. It’s best to watch Lesson 5 “ARIA” to get a general grasp of this topic. In addition to adding role and ARIA attributes, you might need to programmatically add keyboard functionality to your component. Adding role and ARIA attributes alone does not make a component fully accessible.

Helpful ARIA resources:

• ARIA 1.1 spec
• ARIA 1.1 roles
• ARIA 1.1 practices guide
• ARIA — Accessibility | MDN

Wrap up

In summary there are two overarching lessons in accessibility:

• You can achieve accessibility on your site by using standard web development practices that you already know.
• If you can’t use natively focusable elements, you must use the role attribute plus any required ARIA attributes and extra functionality to make your custom component accessible.

General guidelines for making an accessible web page was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a lot of debate on whether to use em or px for breakpoint units in media queries. A few years ago Luke Wroblewski demoed his site at An Event Apart using em breakpoints. When he increased the browser’s font size, the page morphed into a layout that better accommodated the larger text. The audience oohhed and ahhed, and I was sold on em-based breakpoints.

In Luke’s demo the page actually switched to its mobile design. If the breakpoints had been pixel based, the layout would not have changed to its mobile design. However, the text size, which was defined with a responsive font-size unit, still would have increased. This could have resulted in cramped text if he had used pixels for size, margins, and padding values.

Recently I wondered about the applicability of em-based breakpoints — are they the right solution for all designs? Are there any disadvantages? To answer these questions for my day-to-day work I needed to understand the mechanics of em-based breakpoints as well as the direct visual impacts they have. So I dug deeper into the topic with my own testing. After the investigations, I was most intrigued by the fact that a browser’s font size setting affects the calculated value of an em breakpoint.

em- vs. pixel-based breakpoints

Below is an example in which .banner (let’s assume it’s a div) is full width by default then gets a fixed width on viewports at least 1024 pixels wide. (Please note that all code snippets here are written in SCSS syntax.)

.banner {
    font-size: 1em; // 16px
    padding: 16px;

    @media (min-width: 1024px) {
        margin-left: auto;
        margin-right: auto;
        width: 900px;
    }
}

Now look at this similar example with an em breakpoint:

.banner {
    font-size: 1em;
    padding: 16px;

    @media (min-width: 64em) {
        margin-left: auto;
        margin-right: auto;
        width: 900px;
    }
}

We’ll assume the browser’s default font size is 16px. (This is the case for most of them.) Just like the first example this media query will kick in at 1024-wide viewports (16px * 64em), but if a user increases his default font size in the browser settings, the calculated breakpoint value will also increase. For example, if the user changes the font size to 24px, the breakpoint will be 1536px. What this means is that the media query styles won’t apply in viewports under 1536 pixels wide. In this scenario someone on a tablet or laptop might see the mobile layout if the newly calculated breakpoint value is larger than his viewport width.

This might be desirable because when text size is increased, it sometimes needs larger containers to gracefully flow on the page. Since mobile layouts are often designed more simply, sometimes in a full-width stacked layout, this would give text more horizontal space.

What if you don’t want mobile layouts on large screens?

So what if you find that your mobile layout isn’t optimal on desktop screens? Consider the following mobile design:

Let’s say we want the white boxes to appear in a single row on screens at least 1024 pixels wide:

Here’s the initial code for this example using an em-based breakpoint:

.product-item {
    font-size: 1em;
    padding: 16px;

    @media (min-width: 64em) {
        width: 272px;

        .product-list & {
            display: flex;
            justify-content: center;
         }
     }
}

Let’s say a user has a laptop with a screen width of 1440 pixels, and he’s using Chrome. With the em-based media query if he increased the font size to 24px, the page would look like this:

The page displays the mobile styles because the calculated breakpoint is now 1536px, and the user’s screen maxes out at 1440. This doesn’t look terrible, but there’s now a lot of empty space in the white boxes because each is full width. There are two techniques you can try in tandem to achieve balance in a responsive desktop layout:

• using px units for your breakpoints
• using responsive units for element widths and spacing

Let’s first convert the breakpoint to pixel units. With this change the following are true when the user increases his browser’s font size:

• The padding stays at 16px.
• The banner’s width stays at 272px.
• The calculated breakpoint value remains the same.

You can view a live demo on CodePen and try out the media queries. Below is a screenshot with the results so far.

As you can see, because the product-item's width doesn’t change, any text will potentially look cramped as its size is increased. Let’s now convert the padding and width to em units:

.product-item {
    font-size: 1em;
    padding: 1em;

    @media (min-width: 1024px) {
        width: 17em; // 272px / 16px * 1em

        .product-list & {
            display: flex;
            justify-content: center;
         }
    }
}

The padding and width will scale up as the font-size increases. The text looks more comfortable within each box.

So is that the solution?

No, not necessarily. The hybrid responsive layout is not the smoking gun solution for everything. In Chrome a user can set the font size as high as 72px or even larger if he uses a third-party CSS extension. Below is a screenshot of our demo set to 72px with the hybrid responsive layout. I only included a portion of the page since it was very, very tall.

Pretty terrible. In the end the purpose of this investigation is to understand how em-based breakpoints affect layout. For me the key lessons and considerations are:

• Test your layouts in a range of font sizes.
• Determine if your mobile layout on bigger screens degrades the user experience.
• If it does and you try a hybrid responsive approach, how does the layout stand up to very large font sizes? Does it still provide a decent experience?

In my opinion most page layouts are complex enough that it’s best to be safe and use em breakpoints in your media queries in addition to responsive units for font sizes, dimensions, margins, and padding. This decision is ultimately an individual one, but be sure to test and consider your audience.

To em or not to em? That is the media query question. was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last 16 years I’ve never had a project that required custom styles for disabled inputs. I know this because when I worked on such a project last week I was pulling my hair out. Most of us in the business know that browsers like to render inputs in their own ways. My cross-browser testing showed that when you throw the disabled state into the mix, you can get a really big headache.

I created a CodePen demo of plain inputs to get screenshots of these cross-browser differences. The only significant custom style I added was a larger font-size to make the placeholder and filled text (value) more readable.

As I iterated the changes for my real-life project, I discovered some of the funny things going on with inputs, and I used some browser-specific techniques to fix them, though not all required vendor prefixes. Before I get to those solutions, it’s helpful to see a second CodePen demo with some made-up style requirements:

• Enabled placeholder text color: cornflowerblue
• Enabled input filled text color: purple
• Disabled placeholder text color: cornflowerblue
• Disabled filled text color: purple
• Disabled input background: lightgray
• All inputs: 1px solid black border

For this demo I created the styles first in Chrome. I used what I consider CSS techniques that should work consistently in these browsers (but don’t). Below are the results.

The browsers sort of rendered as expected, though at this point I purposefully didn’t include vendor-prefixed solutions for IE and Edge. Still, we have some slight variations. To provide a little insight on what’s going on, below are some observations I made when I worked on my real-life project. I also included snippets of the styles needed to meet the CodePen demo’s requirements on a per section basis.

WebKit browsers

In Chrome and Safari (desktop and iOS), Android Chrome, and Samsung Internet, setting color on input affects filled text for both enabled and disabled inputs.

Chrome (desktop version 71 and mobile version 70 on Android 7.1) and Samsung Internet (version 8.2 on Android 7.1)

• As expected you can change an input’s filled text color by customizing the color property on input. This will apply the color to both enabled and disabled filled text. If you want a different disabled filled text color, you have to set color on input:disabled.
• As expected you can change the placeholder text color by customizing the color property on input::placeholder. This will apply the color to enabled and disabled placeholder text. If you want to a different color on disabled placeholder text, use input:disabled::placeholder.

// Styles needed to meet demo requirements

input {
    border: 1px solid black;
    color: purple;
}

input:disabled {
    background: lightgray;
}

input::placeholder {
    color: cornflowerblue;
}

Firefox (desktop version 65 and mobile version 65 on Android 7.1)

• Applying a custom color value to input affects all placeholder and filled text (enabled and disabled fields). If you want a different color for your placeholder text, set the color property on input::placeholder.
• Applying a custom color to input:disabled affects disabled placeholder and filled text.
• FF applies 50% opacity to enabled and disabled placeholder text. To normalize those, add opacity: 1 to input::placeholder.

// Styles needed to meet demo requirements

input {
    border: 1px solid black;
    color: purple;
}

input:disabled {
    background: lightgray;
}

input::placeholder {
    color: cornflowerblue;
    opacity: 1;
}

Safari (desktop version 11.1)

• Like Chrome, Safari will take a custom color on input and apply it to enabled and disabled filled text. Some color values, however, will render as a different hue in disabled inputs. For example, if you use purple, the disabled filled text will look more like fuchsia.
• If you want the enabled and disabled filled text colors to match, assign your color to input. Then create a block with the input:disabled selector and use the -webkit-text-fill-color property with the same color. This will, however, apply the color to the disabled input’s placeholder text. If this is not desirable, you have two options: 1) use the -webkit-text-fill-color property on input::placeholder to change the color of all placeholder text or 2) use the -webkit-text-fill-color property on input:disabled::placeholder for specific targeting.

// Styles needed to meet demo requirements

input {
    border: 1px solid black;
    color: purple;
}

input:disabled {
    background: lightgray;
    -webkit-text-fill-color: purple; // Only needed if you want all filled text to have the same color and you happen to pick a color that doesn't render correctly in a disabled input. FYI This will also apply to disabled filled and placeholder text in Chrome.
}

input::placeholder {
    -webkit-text-fill-color: cornflowerblue; // Changes all placeholder color
}

Chrome and Safari (iOS 12)

• Like their desktop counterparts these browsers will take a custom color on input and apply it to enabled and disabled filled text. They also have the same inconsistent hue issue noted above for desktop Safari. The solution is the same.
• Disabled inputs have a 40% opacity. Setting opacity: 1 on input normalizes the opacity of the entire element including placeholder and filled text. You can also set opacity on just input:disabled for the same effect.

// Styles needed to meet demo requirements

input {
    border: 1px solid black;
    color: purple;
}

input:disabled {
    background: lightgray;
    -webkit-text-fill-color: purple;
    opacity: 1;
}

input::placeholder {
    -webkit-text-fill-color: cornflowerblue;
}

IE 11

• Setting color on input:disabled applies the color to disabled placeholder and filled text.
• Setting color on input applies the color to all filled and placeholder texts, enabled and disabled. You can use a variety of selectors to override this and customize your text colors:

input:-ms-input-placeholder {...}
input:disabled {...}
input:disabled:-ms-input-placeholder {...}
input:disabled:not(:-ms-input-placeholder) {...}

// Styles needed to meet requirements

input {
    border: 1px solid black;
    color: purple;
}

input:disabled {
    background: lightgray;
}

input:-ms-input-placeholder {
    color: cornflowerblue; 
}

Edge 17

If you want to customize placeholder text, Edge requires the input::-webkit-input-placeholder selector.

// Styles needed to meet requirements

input {
    border: 1px solid black;
    color: purple;
}

input:disabled {
    background: lightgray;
}

input::-webkit-input-placeholder {
    color: cornflowerblue; 
}

Closing

I have a third CodePen demo with all these styles consolidated. If you view it in the browsers mentioned here, you’ll see much more consistency. You don’t have to use all these workarounds; it depends on what your requirements are. Also, if you need to change Chrome’s pre-filled input styles, check out Bobby Westberg’s solution. Hopefully with all this information you’ll have an easy time customizing placeholder and filled texts for enabled and disabled inputs.

The Witchy World of Inputs was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Zoosk we often use a pattern we call an interstitial. It’s a word or short phrase flanked on the left and right by a line, and it vertically separates two sections or options on a page. In the screenshot below, the phrase “or confirm with” separates two ways to confirm your email address on Zoosk.

For this pattern, the text and lines must not overlap even if the text is dynamic. (This is the case for us; Zoosk supports 27 languages.) There are a few solutions for this, and they essentially do the same thing — in a nutshell you can apply a top border to an element then position another element containing your text on top of it. These solutions require applying a background color to the text-containing element that matches its parent’s background color. This way the text element covers up the line behind it. This generally works pretty well. If, however, you want a background pattern, responsive interstitial lines, or a solution that requires a little less maintenance, we have an answer for that.

The HTML markup

The markup for the interstitial follows:

<div class=”interstitial”>
    <span class=”interstitial__line--left interstitial__line”></span>
    <span class=”interstitial__text”>
        A responsive interstitial — The lines’ length will change based on the text. Also works on smaller screens.
    </span>
    <span class=”interstitial__line--right interstitial__line”></span>
</div>

The main interstitial container serves to hide excess length from the lines, which will be explained later. The two interstitial__line spans render the left and right lines around the text. It’s best to use spans as the children elements within interstitial. Spans next to each other will move horizontally in response to content changes in other spans. This is key for adjusting the line widths with dynamic strings.

The CSS (written in SCSS syntax)

As mentioned the interstitial div hides the extra length of the lines when overflow is set to hidden. Optionally you can define max-width or width. A responsive interstitial requires a percent value. Since interstitials usually look best when centered on a page, we included auto left and right margins in our example below.

.interstitial {
    overflow: hidden; // Hides the excess lines
    margin: 0 auto; // Optional
    max-width: 90%; // Optional
}

The lines are rendered using :before pseudo elements on the interstitial__line spans.

.interstitial__line {
    position: relative;

    &:before {
        border-top: 6px double; // Customizable
        content: '';
        height: 0;
        padding-right: 100vw;
        position: absolute;
        top: 50%; // Customizable but this is our default
    }

    &--left { // Parent class of span that renders the left line
        &:before {
            right: 10px; // The gap between the right end of the line and the text. Customizable.
        }
    }

    &--right { // Parent class of span that renders the right line
        &:before {
            left: 10px; // The gap between the left end of the line and the text. Customizable.
        }
    }
}

Let’s first tackle the :before element styles. The right padding makes the pseudo element, and therefore the border, as long as the viewport’s width. (Left padding can be used instead of right; they both have the same effect.) This is why we set overflow: hidden on the interstitial div. Because we defined the right property on the interstitial__line--left span, any width changes will flow away from the text toward the left of the page. The same goes for the interstitial__line--right span; however, its width flows in the opposite direction because we set a left value on this element. These techniques ensure the text and lines don’t overlap. We can also use the left and right values to customize the gap between each line and the text.

The interstitial__text does not require many styles:

.interstitial__text {
    display: inline-block;
    max-width: 60%; // Customizable. Max-width as a percent will make the text and lines responsive.
    vertical-align: middle;
}

Responsive interstitials require max-width as a percent, and we set display to inline-block so this property will take effect on the span. A couple of warnings: Defining max-width in pixels, rems, or ems might cause the lines to disappear on small screens depending on your string length. Also, using width instead of max-width can cause unexpected large gaps around your text if your dynamic content is short. So use max-width if you want the lines to automatically and consistently adjust with your text.

If you insist on using a non-percent value for max-width, you’ll need to use media queries to change max-width at your desired breakpoints to keep the lines visible.

A working example of this responsive interstitial is available on CodePen.

Finally, A Responsive, Low-maintenance Interstitial was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a CSS author I’ve typed many property-value pairs over and over again in different declaration blocks, and it gets really tedious. Our CSS developers here will tell you the same thing. Luckily we use Sass (and more specifically the SCSS syntax) so we’re able to group repeated properties together and call them in any block we want. These groups are called mixins.

One simple example is setting an element’s width and centering it on the page:

header {
    margin-left: auto;
    margin-right: auto;
    width: 500px;
}

This is something we do a lot, so to make this implementation a bit quicker, we can put those properties into a mixin:

@mixin limited-container($width) {
    margin-left: auto;
    margin-right: auto;
    width: $width;
}

Then we call the mixin in the original block, passing in a custom width value based on our needs:

header {
    @include limited-container(500px);
}

This will compile into the first example block shown above.

Over the years we’ve added many mixins to our in-house library. They’ve really sped up our work, and some of them are common and simple enough that we’ve put them together in a gist to share. Thanks to both Roger Flanagan and Amir Sattari for their contributions to this library and a special shoutout to Roger who is a Zoosk team lead and UI veteran responsible for many of the handy mixins we use every day.

Mixins You Need in Your SCSS Library was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

As part of the migration, we wanted to rewrite our test runner and architect it to improve overall speed and efficiency.

Test-Runner is the backbone of our automation cluster. It takes the list of tests and test machines available and runs them in parallel on the cluster.

We use Jenkins as our automation server. The cluster management and some part of test running are delegated to Jenkins and the test runner is always in sync with it while running Automation.

We started with creating a Jenkins job to run a single test. It takes the test machine, test to run, and the TestRail id to report to as parameters and runs the test on an AWS Linux spot instance pointing to the test machine’s address. As soon as the test is done, Test Runner sends the result to TestRail server.

Approach:

Step1 ( Test-Runner ):

• Compiles a list of tests to run
• Creates the list of test machines in the available cluster
• Creates a new test plan for reporting/monitoring and get’s the plan ID
• Starts the Job to create an AWS Linux spot instance cluster
• Starts the poll for “Run Single Test” job availability

Step2 ( Test-Runner ):

• Triggers a “Run Single Test” job with parameters as soon as poll finds availability and test machine is free to run the test
• Runs several tests for each machine and pings for the status of each test
• As soon as the test completes, reports back to TestRail
• Does a single rerun if there are any environment issues for a test

Step3 ( Cleanup ):

• Stop build if any of the tests stuck
• Stop the Jenkins poll thread
• Delete any files created in the process

The major change with this new architecture is that the Test-Runner starts a thread to poll for “Run Single Test” job availability and starts a new test as soon as something is available.

This small change had a huge impact. Previously we used to start a bunch of jobs and recursively check for them to start and proceed with the next batch again. If there was an issue or if a single job took longer than the normal time to start, the Test-Runner was stuck waiting for it to finish.

In a similar fashion Test Runners polls for the status of the single test run and reports back to TestRail as soon as it done and closes that particular thread.

Conclusion:

• We gained a massive boost in the time taken to complete a test run with the new architecture, from 4.5hrs to 1.5 hrs

• No more re-runs. Part of the 4.5hr job is because includes several re-runs to eliminate the platform issues which we no longer need.
• Completely platform agnostic, we can finally run the code on Mac, Linux and Windows (We are actually using all three platforms — Linux for automatic runs, Windows and Mac for development.)
• Removed the legacy code and upgraded the 3rd party libraries to the latest and greatest
• Updated our open source TestRail client library and also merged a PR contribution.

It was a fun project to work with and understand the underlying architecture of the Automation Infrastructure. Due to tight time constraints and an office move we had to quickly finish the project.

Now that we are done with the major milestone, here are the couple of things we want to focus on next:

• Some of the functional tests are still brittle, since they try to test all the possible scenarios. We are working towards making them reliable.
• There are few edge cases with the new test runner we are trying to address
• With this knowledge we want to experiment on building an isolated test environment with the VM ( Run the tests in a container like a service rather than on a separate VM)
• Invest on building more tooling around automation (like a slack bot) and reduce the test run time to ~10 minutes to enable us to achieve continuous deployment.

Are you creative and want to work on fun projects like this? If yes, come work with us at Zoosk. Check out our openings here

Migrating Automation Lab to the Cloud (Part 2) was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: Our journey on migrating from .NET Framework to .NET Core. How we leveraged Jenkins to create an on-demand cloud cluster for automation runs and saved costs on hardware and time on maintenance.

At Zoosk, we have a huge set of end-to-end tests that run a few times a day in our homegrown Automation Lab cluster. The whole infrastructure is based on windows VMs running on Hyper-V (on a monster Windows machine with 100GB RAM), with around 100 VMs running at any given point in time.

The goal was to move infrastructure to the cloud and make it cross-platform ( run on mac, linux and windows )

There were a couple of challenges associated with this:

1. Port to .NET core
2. Fix the broken pieces
3. Build infrastructure

Port to .NET core:

Microsoft has good documentation and tools to help to migrate from .NET Framework to .NET core smoothly. (check out the simple guide here)

Visual studio 2017 or later needed to work with .NET core cross-platform so our first step was to port our project from visual studio 2015.

Visual studio uses project files in the format .csproj and the fun part is VS2017’s format of .csproj changed from the VS2015 version. We started by using the one-way upgrade VS2017 provides but none of the project compiled and it has few hundred errors.

It’s a pain to look for the errors and fix them but the new format got us excited because it removed a lot of clutter from the project file and made it easier to read and understand

For example, all the embedded and compile resources inside a project can be removed, like the ones below:

<!-- the defaults -->
<Compile Include="**\*.cs" />
<EmbeddedResource Include="**\*.resx" />

And simplified project dependency definitions like these below:

<ProjectReference Include="..\Payment\Payment.csproj">
  <Project>{1A2VA732-BN78-09OD-OPD9-5698AHD9OP02}</Project>
  <Name>Payment</Name>
</ProjectReference>

are replaced by:

<ProjectReference Include="..\Payment\Payment.csproj" />

Fix the broken pieces:

After fixing the .csproj files there were few more errors left before we can could actually compile and run on VS 2017 (i.e unsupported 3rd party libraries).

With .NET core completely written from scratch and focusing on cross-platform some of the libraries didn’t support .NET core yet. Because of this, we had to find alternatives and also rewrite the code to use the new library patterns.

Using the API Portability Analyzer tool provided by Microsoft, we generated a report on the project ( see image below) to see how much effort was needed.

The changes were broken into two steps

1. Replace/ find an alternative for the 3rd party libraries with .NET core support and rewrite
2. Strip the windows API dependency code in the automation framework and rewrite to support cross-platform

Finding a replacement for the current XMPP implementation was the toughest. There isn’t any well-written documentation available for this and the only place we ended up was the RFC from Internet Engineering Task Force (IETF).

We also added our custom packets on top of the XMPP standard so re-writing that part took longer than what we budgeted for. Mail library was another piece that we had to do a heavy rewrite on.

After all the changes and rewrites were made to finally compile and run, there were about 4k lines added. But the cool part was we had a chance to remove the old and unused code as part of the migration and reduced the footprint by about 8k lines.

Build infrastructure:

And, the final piece of the puzzle… Setup Jobs to kick off automation on our nightly and master branches daily.

We use Jenkins as our automation server and now that we could run the automation test suite on Linux, It was time to retire the Hyper-V hypervisor and use AWS spot instances.

Spot instances were a perfect fit for us, because they were up to 90% cheaper than the regular instances and were provisioned to use for few hours and destroy

We started by creating an AMI for the spot instances and launched them on demand using the EC2 plugin for Jenkins.

Installing Google Chrome for CentOS is not straightforward but I found a script on a blog post by Intoli to easily install Google Chrome on CentOS to run it headless, which we used to install while creating the AMI.

Once the configuration for the AMS details was set in Jenkins, it was a piece of cake to start instances with a pipeline script.

parameters {
    string(name: 'count', 
    defaultValue: 10, 
    description: 'count of the instances to start')
}
node {
    for(i=1; i<= "${params.count}".toInteger() ; i++){
        string name = "Creating cloud instance "+i;
        stage(name) {
            ec2 cloud: 'EC2', template: 'your cloud template'
        }
    }
}

This pipeline script takes a count optional parameter and creates instances on demand on AWS, and copies the slave.jar file and launches it as a Jenkins slave computer.

By using the spot instances, we no longer needed blade runner with a cluster of VM’s.

That freed us from a lot of pressure points and improved our overall processes. A few of them are:

• No more occasional VMs going rogue and tests failing due to unknown config issues etc.
• No more cleanup/maintenance of the VM needed
• Updating the AMI reflects the changes to every instance launched after
• Scalable — now that we have this infrastructure we can let developers run automation for their changes as needed.
• Massive time improvements (more about this in part 2 )

Shout out to Conor Callahan for helping me out with a lot of dev-ops related work needed to make this possible.

Part 2 goes into details of the test runner architecture.

Migrating Automation Lab to the cloud (Part 1) was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

It doesn’t have to be that way, however. With the proper scripting, you can make changes to vast swaths of your codebase. That’s where abstract syntax trees, or ASTs, come in.

What are ASTs?

ASTs are data structures used for representing code. Specifically, they’re the way that your language’s compiler or interpreter represents it. They are regular tree data structures in which each node is a kind of syntax. For example, something like this:

x = y + 2

is represented as an AST like this:

Assignment: "="
  |- Identifier: "x"
  |- BinaryOperator: "+"
    |- Identifier: "y"
    |- NumericLiteral: "2"

This might seem a bit verbose, but it has lots of advantages over just parsing the text yourself, including:

1. No weird whitespace, comments, or other formatting to mess with.
2. Order of operations is always clear.
3. Symbols are searchable based on their meaning in code instead of their text makeup (“=” vs “==”, “(“ in a function call or declaration, etc).
4. Compiler-inferred information such as types or errors is available.
5. Telling people that you’re working with the compiler API makes you seem really smart.

You can use the wonderful ASTExplorer.net to compile and inspect ASTs of your code live.

A minimal linter

One of the easiest things you can do with ASTs is build your own linter, which will automatically analyze your code and report errors. For this example we’ll be using Typescript and its compiler API, but if Typescript isn’t your thing, try out the equivalent with Python, PHP, C#, or Java. We’ll be producing a script that warns whenever a function’s name starts with an uppercase letter.

First, we provide our file to the compiler:

import * as fs from 'fs';
import * as ts from 'typescript';

const fileName = process.argv[2];
const sourceFile = ts.createSourceFile(
  fileName,                             // File name
  fs.readFileSync(fileName).toString(), // File contents
  ts.ScriptTarget.ES2017,               // JS dialect
  true,                                 // Build out the AST
);

Next, we write a small tree traversal function that will perform a depth-first walk over the whole tree, searching for errors:

function traverse(node: ts.Node) {
  if (ts.isFunctionDeclaration(node)) {
    const name = node.name.getText();
    if (name.charAt(0).match(/[A-Z]/)) {
      const pos = sourceFile.getLineAndCharacterOfPosition(
         node.getStart()
      );
      console.error(
        `You really messed up on line ${pos.line}` +
        ` when you called your function ${name}.`
      );
    }
  }
  node.forEachChild(traverse);
}

// Start the traversal
sourceFile.forEachChild(traverse);

With that, we have a full linter in only 25 lines of code! Make sure to adjust the sassiness level of your errors to fit your company’s culture.

Rewriting code

As the bosses of the world have said many times, it’s one small step from complaining about an error to fixing it. Let’s modify the code that prints out the error message to write out the correct version instead:

// Add this at the top level
const spansToReplace = [];

// Add this after the console.error call
spansToReplace.push({
  start: node.getStart(),
  end: node.getEnd(),
  replacement: name.charAt(0).toLowerCase() + name.substr(1),
});

// Put this at the end
let newText = sourceFile.getFullText();
spansToReplace.forEach(span => {
  newText = newText.substring(0, span.start)
            + span.replacement
            + newText.substring(span.end);
});
console.log(newText);

The original AST is read-only, so we need to maintain a list of replacements ourselves and then output a modified version of the original file. We can do this by keeping track of where we found the bad nodes during the tree search and then replacing everything in one go.

Now, running this on every file in your codebase will automatically fix every function declaration, regardless of the number of files you have!

Expand your horizons

This is just a simple introduction to linting and code modifications. The example above can be modified to check for any number of things, even across source files. Here are some ideas to try yourself:

• Find var or let declarations that are never modified, and convert them to const.
• Search across files for public fields that are never accessed, and convert them to private.
• Replace public fields and their accesses with generated getters and setters.
• Use the type checker to add explicit type declarations to variables based on the return types of function calls.
• Integrate your custom linter with TSLint to get IDE highlighting.

Of course, you don’t have to do it all from scratch. ASTs are the basis of popular tools like TSLint and JSCodeshift. There are even ease-of-use libraries for the Typescript API like tsutils and ts-simple-ast. Armed with the knowledge you’ve gained here you’ll be able to take these and expand on them to bring the light back to your legacy codebase.

Refactoring at Scale with Abstract Syntax Trees was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the last two months, I’ve been translating Zoosk’s 800,000-line ES5 Javascript codebase into Typescript. The process was long and harrowing, and I crashed every single external tool I used during the process. But I persevered, and here’s how.

Planning

The most important part of any big project is planning. Here’s the breakdown of how our code was when I started:

• ~800,000 lines of Javascript written from 2008 onward
• No ES6 anywhere — all vars and functions
• No imports or exports — everything is output to the same place
• Type annotations added in JSDoc, thanks to our use of the Closure Compiler
• Code runs both in the browser and on the server via Node
• Files are built using the version of plovr from 2015

Not the most cutting-edge codebase. Here’s how I wanted it to look:

• ~800,000 lines of Typescript!
• All ES7: lets, consts, rest, spread, you name it
• All files should use imports and exports
• Code should still be deployable to both client and server

Swapping the syntax with gents

I like to say “a lazy programmer is a good programmer,” mostly because it’s almost always a good idea to take an already-existing solution. Typescript is the official language of Angular, and luckily the Angular Team maintains a tool called gents that translates @type-annotated JS into Typescript. I highly recommend starting here if you’d like to follow in my footsteps.

Don’t get too comfortable, though. Gents’s use case is so specific that the tool hasn’t had too much time to develop. It will help you greatly in that it will produce a legal-TS-syntax version of your codebase. It doesn’t guarantee that the output will work. Check the issues page before starting and submit an issue if you run into any trouble.

So after running my code through gents, I had 800,000 lines of Typescript. What I didn’t have was compiling code.

Automated fixes with Python

Robin$ tsc | wc -l  # Count the compiler errors
66213

Alright, so there are a few errors.

What do you do when you have more errors than will fit in 16 bits? You start automating updates to the code. Most of the time I’d recommend an AST-based solution, but for simple fixes it’s faster (both in writing and runtime) to use 15–20-line Python scripts.

Here’s some base code that you can use to get started.

One of the most common things that I did was use the replacement function option of re.sub in Python. Here’s a dumb example that just capitalizes its match:

def repl(match):
    return 'I am ' + match.groups()[0].upper()

re.sub('I am (\w+)', repl, 'I am hungry!')
# Returns 'I am HUNGRY!'

Of course, this is possible in JS as well. String.prototype.replace has the same functionality.

I used a ton of tiny scripts like the one above to make far-reaching edits to my codebase. Everything from removing duplicate imports to alphabetizing fields to correctly linking up our templating system was scripted in Python.

Building the code

The next big challenge was how to deploy. Our one big ask here was that we continue using the Closure Compiler for the browser code. This is due to the huge gains that advanced mode provides like dead code removal, inlining, and gzip optimizations.

The Closure Compiler is very specific about its input in advanced mode. Luckily the Angular Team came to our rescue again with tsickle, a wrapper around tsc that outputs advanced mode-compatible JS.

For me, getting started with tsickle was a headache. I ended up diving into the source of tsickle and fixing a couple bugs. Thanks to the magic of open source®, you won’t have to deal with those issues!

On the server, the extra compile step was one that we already had: linking up the output of Soy template files to code running in Node. That step had to be slightly modified to match the new style of requires that tsc outputs.

Code quality improvements

One of the big reasons we wanted to move to Typescript was that it would help us adhere to a higher standard of code quality. We expected this to come in time (and more will!), but the initial migration actually forced us to shape up a bit. Here are some things that Typescript was not happy with initially:

• Usage of fields marked with @private outside of their owning class
• The same thing being imported twice in one file
• Enums declared as static class members instead of by themselves
• Using properties of this before calling super
• Child components importing and manipulating their parents

Additionally, the compiler found seven bugs that we had missed before, completely automatically!

Join us in the sun

If you’re thinking of migrating your large codebase over to TS, I think the benefits drastically outweigh the costs. It took me two months to do ours, but a good three weeks of that time was working out bugs in the open source ecosystem, between gents, tsickle, tsc, and the Closure Compiler. I’ve submitted PRs for everything, so you should be fine.

Additionally, I spent the first month of this project working all by myself, and gained one developer during the second. A team of three devs would have been able to do 800K lines in about three weeks.

Finally, if you’re thinking that you want to move over incrementally, you can actually use Typescript on JS files with almost no effort! This will give you the ability to introduce new TS files one at a time.

That said, if you want to work on Typescript without the work, you can always apply at Zoosk.

Translating 800K lines of Javascript to Typescript was originally published in Zoosk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.