Creating a Vue.js Serverless Checkout Form: Setup and Testing

There comes a time in any young app’s life when it will have to monetize. There are a number of ways to become profitable, but accepting cash is a surefire way to make this more direct. In this four-part tutorial, we’ll go over how to set up a serverless function, make it talk to the Stripe API, and connect it to a checkout form that is setup as a Vue application. This may sound daunting, but it’s actually pretty straightforward! Let’s dig in.

Vue shop

Article Series:

  1. Setup and Testing (This Post)
  2. Stripe Function and Hosting
  3. Application and Checkout Component
  4. Configure the Checkout Component

What is Serverless?

We’ve covered serverless concepts before but, in case you haven’t read that article, let’s talk for a minute about what we mean by “serverless” because it’s a bit of a misnomer.

The promise of serverless is to spend less time setting up and maintaining a server. You’re essentially letting the service handle maintenance and scaling for you, and you boil what you need down to functions that run certain code when a request is made. For this reason, people may refer to this as Azure to help us with this. The portal and Github integration are pretty quick to manipulate, as long as you know where to go. So by all means, let’s make it happen!

Sign up for Stripe

First, we’ll create a Stripe account. We verify our new account via email and then we’ll head over to the API section, where we can retrieve two keys. You’ll note that we’re in test mode right now, which is good! We’ll keep it like that for testing, and unveil the testing key token to use while we set up the application.

Once you’re signed in, go to the API section of your dashboard to retrieve your key.

Stripe testing dashboard
The Stripe API screen

You may also want to add a phone number to your account for 2 factor auth as well.

Setting up Our Serverless Function in the Azure Portal

First, we’ll head over to the portal, (or if you don’t already have an account, you can sign up for a free trial here) and select New > Serverless Function

New Function
Setting up a new Servless Function in Azure

When we click on the Serverless Function app, we’ll be taken to a panel that asks for details to help with the setup. As you can see in the screenshot above, it will autofill most of the fields just from the app name, but let’s go over some of these options quickly:

  • Add in a unique name
  • A Resource Group (if you don’t already have one, create one)
  • I use the Windows OS because the Linux is still in preview, so Windows will be more stable
  • I use the Consumption Plan because this is the one that will have payments that scale with the use, and it will also scale automatically. The other option, App Service Plan, is good for people who prefer everything to be a bit more manual.
  • Choose a location that is close to your customer base, or a midpoint between two customer bases
  • Choose a storage, or create one as I’ve done
  • I’ll also check Pin to Dashboard because I want to be able to retrieve my function quickly later
New function settings

This will bring you back to the main portal dashboard and let you know that your function is deploying. Once it’s done, it take you to a main screen that has all of your options. From here, we’ll want to create our function, and it will be an HTTP trigger.

We’ll select Functions under our function name, and you’ll see a little table with a plus that says “New Function”:

New Function in the Portal

Once we click here, we have a few options on what we can create. We’ll pick HTTP Trigger:

Choose HTTP Trigger

We’ll be able to select the language (pick “JavaScript”) and then “Create”:

Pick the Language and Create

The Default Testing Function

From here, we’re given a default testing function which helps us see how this all works. If we open all of these panels and hit the Run button, we’ll see the output in logs.

The initial testing output
Running the function in a test environment

Here’s the code we were given:

module.exports = function(context, req) { context.log('JavaScript HTTP trigger function processed a request.'); if (req.query.name || (req.body && req.body.name)) { context.res = { // status: 200, /* Defaults to 200 */ body: 'Hello ' + (req.query.name || req.body.name) }; } else { context.res = { status: 400, body: 'Please pass a name on the query string or in the request body' }; } context.done();
};

You’ll see here that we’re passing in the context. That allows us to log, which will be shown in the lowest panel below. In the Test panel on the right, we can pass in a request body that can be used to test our application. When it runs, we see the output with a 200 status and know that everything is working. We also have a context.log for the case that it gives us a 400 error. If you’d like to play around with a serverless function and see it in action for yourself, you can create one with a free trial account.

Next Up…

Now that we have the base of our serverless function, let’s set up what we’ll need to communicate with Stripe! More to come in the next post in this series.

Article Series:

  1. Setup and Testing (This Post)
  2. Stripe Function and Hosting
  3. Application and Checkout Component
  4. Configure the Checkout Component

Creating a Vue.js Serverless Checkout Form: Setup and Testing is a post from CSS-Tricks

The latest ways to deal with the cascade, inheritance and specificity

The cascade is such an intrinsic part of CSS that they put it right there in the name. If you’ve ever needed to use !important to affect specificity in the cascade, you’ll know that it can be a tricky thing to deal with. In the early days of CSS, it was common to see highly specific selectors like this:

#sidebar ul li {}

We’re all much better at managing specificity nowadays. It’s a widely accepted best practice to keep specificity low and flat—to shun ID selectors, to make liberal use of classes, and to avoid unnecessary nesting. But there are still plenty of situations where a more specific selector will be useful. With the introduction of a newly proposed pseudo-class, more support of the shadow DOM, and the use of the all property, we will soon be able to handle inheritance and specificity in new and exciting ways.

The :is Pseudo-Class

Lea Verou recently proposed this new pseudo-class specifically designed to control specificity. It’s already made its way to the CSS Level 4 Selectors spec. Lea has a write up of why it’s useful and there’s some coverage of it in the CSS-Tricks almanac.

Let’s take :not as an example. The specificity of :not is equal to the specificity of its argument. This makes using :not rather painful. Take the following as an example:

See the Pen :not and specificity by CSS-Tricks (@css-tricks) on CodePen.

We might expect that the .red class would have higher specificity because it is lower in the cascade. However, for any styles to override div:not(.foobar) they would need to at least match the specificity of a combined element selector (div) and class selector (.foobar). Another approach would be div.red, but there is a better way. This is where :is can help.

div:is(:not(.foobar)) { background-color: black;
}

The :not selector no longer adds any specificity, so the total specificity of the above selector is simply that of one element selector (div). The .red class would now be able to override it in the cascade. Once implemented, specificity hacks will be a thing of the past.

Shadow DOM

Today, many people are using classes in HTML like this:

<form class="site-search site-search--full"> <input type="text" class="site-search__field"> <button type="Submit" class="site-search__button">search</button>
</form>

When using shadow DOM, rather than following a verbose naming convention, we’ll be able to omit classes altogether. Styles defined within the shadow DOM are scoped to apply only within the component. Styling can be achieved with simple element selectors without worrying about whether the selectors will interfere with elements elsewhere on the page.

See the Pen shadow dom by CSS GRID (@cssgrid) on CodePen.

It’s liberating to write such easy CSS. No more effort spent naming things. Shadow DOM looks like it is finally making its way to full browser support. It’s likely to make it into the next release of Firefox while Edge have implementation as a high priority.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Opera Firefox IE Edge Safari
53 40 No No No TP

Mobile / Tablet

iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox
11.0-11.2 No No 62 62 No

The all Property

The all property is a way of setting all CSS properties at once—everything from align-content to z-index. What values does it accept? I can’t think of any use case when I’d want all properties to inherit, but that’s an option. Then there’s initial which is more like applying a CSS reset where all the styles are gone. No padding. No margin. The initial value is set per property, regardless of the element it is applied to. The initial value of display is inline, even if you apply it to a div. The font-style of an em tag is normal, as is the font-weight of a strong tag. Link text will be black. You get the idea. (You can find the initial value of any CSS property on MDN.) This does perhaps limit its usefulness, going further than we might like by removing all styles, regardless of context.

See the Pen all: initial by CSS GRID (@cssgrid) on CodePen.

Sadly, the most useful value for all is also the least widely implemented: revert. It can remove the styles that you as a developer have applied, while leaving the default user-agent styles intact. We’ve all seen a page of HTML without a stylesheet—black Times New Roman on a white (transparent) background with blue underlined links. If you really want to avoid inheritance, then all: revert has you covered. All divs will be display: block and spans will be inline. All em tags will be italic and strong tags will be bold. Links will be blue and underlined.

See the Pen all: revert by CSS GRID (@cssgrid) on CodePen.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Opera Firefox IE Edge Safari
No No No No No 9.1

Mobile / Tablet

iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox
9.3 No No No No No

The future?


The miscellany of rival unstandardized methods for writing CSS-in-JS was an attempt to sidestep these same issues. That approach has gained popularity over the last several years. Some of its proponents have deemed inheritance, the cascade and specificity as fundamentally flawed design decisions of the language. The CSS Working Group at the W3C is responding by improving the power of CSS and the native web platform. It will be interesting to see the outcome…


The latest ways to deal with the cascade, inheritance and specificity is a post from CSS-Tricks

Making CSS Animations Feel More Natural

It used to be that designers designed and coders coded. There was no crossover, and that’s the way it was. But with the advent of CSS transitions and animations, those lines are blurring a bit. It’s no longer as simple as the designer dictating the design and the coder transcribing—designers must now know something about code, and coders must know something about design in order to effectively collaborate.

As an example, let’s say a designer asks a developer to make a box bounce. That’s it—no additional instruction. Without some cross-knowledge and a common vocabulary, both sides are a little lost in this communication: the developer doesn’t have enough information to fully realize the designer’s vision, but the designer doesn’t really know what the options are and how to communicate them. With a very basic interpretation, you might end up with something that looks like this:

See the Pen Bouncing Box 1 by Brandon Gregory (@pulpexploder) on CodePen.

Not very exciting. Although, to be fair, this does meet all of the criteria given. We can definitely do better than this, though.

The first thing to look at is the timing function. In the above example, we’re using a linear timing function, which means that the box is constantly moving at the same speed. In some cases, this is desirable; however, in the real world, motion usually doesn’t work like that.

An easy fix is to simply change the timing function to ease. This makes the beginning and ending of each animation a little slower than the middle part, which adds a more natural look to some animations. Here’s the box with the easing function turned on:

See the Pen Bouncing Box 2 by Brandon Gregory (@pulpexploder) on CodePen.

This is a slight improvement, but there’s still a lot of work to be done. The box still looks mechanical and stiff, with the same animation occurring in the same timeframe over and over. Adding a slight delay between bounces adds some visual contrast that seems a little more natural:

See the Pen Bouncing Box 3 by Brandon Gregory (@pulpexploder) on CodePen.

The box now looks like it’s jumping rather than simply moving up and down. There’s a little wind-up and cool-down between jumps that mimics what a live creature might do if given the same instruction. Even though we have no reference for what a jumping box would look like, we all have a pretty good idea of what a jumping creature would look like. Because we know what would happen in nature, by mimicking that, the animation feels more natural. But we can do more to make that wind-up feel a little more weighty.

If you watch cartoons, you’ll notice that natural movements are often exaggerated, creating a caricature of real life. When done well, this can feel just as natural as something in the real world, with the added bonus of infusing a little charm and character into the animation.

At this stage, collaboration between the designer and developer is crucial — but many designers may not even be aware that these options exist. It may be up to the developer to pitch this possibility to the designer.

By adding some subtle distortion to the scale of the box, we can add a lot to the animation:

See the Pen Bouncing Box 4 by Brandon Gregory (@pulpexploder) on CodePen.

Now, the box has character. It feels alive. There are many things to tweak, but this is already moving much farther than the original instruction — in a very good way!

We’re going to go a step further and add a little rebound at the end of the jump:

See the Pen Bouncing Box 5 by Brandon Gregory (@pulpexploder) on CodePen.

The second bounce is making this feel more alive, but something still seems off. The bounce looks stiff compared to the rest of the animation. We need to add another bit of distortion like we did for the wind-up:

See the Pen Bouncing Box 6 by Brandon Gregory (@pulpexploder) on CodePen.

That subtle distortion at the end makes the rebound seem much more natural. Overall, a huge improvement from our basic linear bounce in the first example.

That right there may be exactly what we’re looking for, but further tweaks to the rate of movement can be made with a custom cubic Bézier curve:

See the Pen Bouncing Box 7 by Brandon Gregory (@pulpexploder) on CodePen.

Without both the designer and the developer aware of basic animation principles and controls, this level of customization is impossible. Really, this article just scratches the surface of both fields. If you’re a web designer or a web developer who works with designers, I’d strongly urge you to read up on both.

For animation principles, The Illusion of Life: Disney Animation by Ollie Johnston and Frank Thomas is a great primer on how to make that caricature of real life seem alive and real. With that common language in place, communication and collaboration between designers and developers becomes much easier.

For the technical controls and variations of CSS animation, the possibilities are nearly endless. Delay and timing are simple to adjust. As mentioned, if you don’t like the out-of-the-box ease timing function, it’s very possible to create your own using a cubic-bezier(). You can also adjust the level of distortion you want to bring the animation closer to or further from reality. The important thing is that both the designer and developer are thinking about these variations rather than blindly taking everything without customization. Shared knowledge and collaboration can make even simple animations into great ones.

More Resources

  • 12 basic principles of animation – Wikipedia post outlining the concepts introduced in The Illusion of Life.
  • The Guide to CSS Animation: Principles and Examples – Smashing Magazine article providing a comprehensive guide to CSS animations.
  • Animation in Design Systems – 24 Ways article by Sarah Drasner
  • Animation property – CSS-Tricks almanac entry covering the property and its values
  • Transition property – CSS-Tricks almanac entry covering the property and its values
  • CubicBezier.com – Resource to create custom animation curves with a user interface.

Making CSS Animations Feel More Natural is a post from CSS-Tricks

Careful Now

Tom Warren’s “Chrome is turning into the new Internet Explorer 6” for The Verge has a title that, to us front-end web developers, suggests that Chrome is turning into a browser far behind in technology and replete with tricky bugs. Aside from the occasional offhand generic, “Chrome is getting so bad lately,” comments you hear, we know that’s not true. Chrome often leads the pack for good web tech.

Instead, it’s about another equally concerning danger: developers building sites specifically for Chrome. In theory, that’s not really a thing, because if you build a website with web standards (of which there isn’t really much of an alternative) it’ll work in Chrome like any other modern web browser. But it is a thing if you build the site to somehow block other browsers and only allow Chrome. Warren:

Google has been at the center of a lot of “works best with Chrome” messages we’re starting to see appear on the web. Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio Beta all block Windows 10’s default browser, Microsoft Edge, from accessing them and they all point users to download Chrome instead. Google Meet, Google Earth, and YouTube TV are also not supported on Firefox with messages to download Chrome.

I wouldn’t call it an epidemic but it’s not a good trend. Best I can tell, it’s server-side UA sniffing that entirely blocks the sites:

Sheesh.

If anything, I’d think you’d just let people use the site and display a warning if you’re really worried some particular feature might not work. Or even better, fix it. I have no behind-the-scenes knowledge of why they made the choice to block certain browsers, but it’s hard to imagine a technical limitation that would force it. And if it is, I’d suggest letting it be very publicly known to incentivize the other browsers to support what is needed, assuming it’s an established standard.

Even more concerning than browser-specific websites is seeing browsers ship non-standardized features just because they want them, not behind any vendor prefix or flag. There was a time when web developers would have got out the pitchforks if a browser was doing this, but I sense some complacency seeping in.

These days, the vibe is more centered around complaining about other browsers lack of support for things. For example, one browser ships something, we see one green dot in caniuse, and we lambast the other browsers to catch up. Instead, we might ask, was it a good idea to ship that feature yet?

No modern browser is shipping vendor prefixes anymore since we all ultimately decided that was a bad idea. A side effect of that is that shipping a new feature in CSS or JavaScript is all the riskier. I would think shipping an unprefixed feature to a stable version of the browser would mean the feature is standardized and not going to significantly change. Yet, it’s been happening.

In CSS, Chrome shipped motion-* properties, but then that all changed to offset-*, and the old motion-* properties just stopped working. That’s more than just annoying, that kind of thing helps developers justify saying, “I just build this site for Chrome, if you wanna use it, use Chrome.” Fine for a demo, perhaps, but bad for the web industry as a whole. Again, I have no special insight into why this happens, I’m just a developer looking in from the outside.

Here’s another CSS one I just saw the other day. People are excited about text-decoration-skip: ink; because it looks great and helps people. They are using it a lot. But apparently, that’s not the correct name for it? It’s been changed to text-decoration-skip-ink: auto; and so Chrome 64 is canning text-decoration-skip: ink;. This stuff is hard to keep up with even while actively trying.

Chris Krycho had a take on it recently as well:

Over the past few years, I’ve increasingly seen articles with headlines that run something like, “New Feature Coming To the Web” — followed by content which described how Chrome had implemented an experimental new feature. “You’ll be able to use this soon!” has been the promise.

The reality is a bit more complicated. Sometimes, ideas the Chrome team pioneers make their way out to the rest of the browsers and become tools we can all use. Sometimes… they get shelved because none of the other browsers decide to implement them.

Many times, when this latter tack happens, developers grouse about the other browser makers who are “holding the web back.” But there is a fundamental problem in this way of looking at things: Chrome isn’t the standard. The fact that Chrome proposes something, and even the fact that a bunch of developers like it, does not a standard make. Nor does it impose an obligation to other browsers to prioritize it, or even to ship it.

This isn’t all to throw Chrome under the bus. I’m a Chrome fan. I’m sure there are examples from all the major vendors in the same vein. I’d just like my two cents to be careful now. The web is the best platform to build for and generally heading in a direction that makes that even truer. The easiest way to screw that up is not being careful with standards.


Careful Now is a post from CSS-Tricks

Tales of a Non-Unicorn: A Story About the Roller Coaster of Job Searching

Hey there! It’s Lara, author of the infamous”Tales of a Non-Unicorn: A Story About the Trouble with Job Titles and Descriptions” from a couple years back. If you haven’t read that original article, I recommend skimming it to give you some context for this one, but I think you’ll still find value here even if you don’t.

A lot has happened since I wrote that article in 2015, and this follow-up has been in the works for a good six months. I ended up, not with a solution for the job titles conundrum or a manifesto about the importance of HTML and CSS, rather a simple, honest story about my roller coaster ride.

Okay, enough dilly-dally. Let’s go!

<story>

In the aftermath of the FizzBuzz drama in 2015, I doubled down on my freelance business and did really well. I got a great contract gig with startup in New York refactoring a Haml/Bootstrap situation that paid the bills and then some. I hired an assistant and started the Tackle Box, an online school sort-of-thing where I taught web development and WordPress. I made a little money off that one, too. I spoke at a handful of conferences and meetups, taught a bunch of classes, and generally had the pedal to the metal.

Then I got really, really tired.

I was sick of writing emails, sick of sending invoices, and sick of being on the computer all the damn time. I wanted to go to work and then leave work at work; something that is very hard to do in our industry, and extra difficult when you are your own boss. I enjoyed coding sometimes, but it was all about the billable hour. Why should I write code or be on the computer at all if I’m not being paid for it? This was burnout, that thing that’s become a weird, convoluted rite of passage in our industry.

I wanted to shut down Lara Schenck, LLC and be a ski bum. And you know what? I did. It was time for a break, and I took one for about six months.

Ski Bum Sabbatical

I left New York City in August of 2016 and moved back to my family’s farm near Pittsburgh. I got a job cleaning horse stalls for $7/hr at the stable where I used to ride when I was a kid. My plan was to gradually ramp down business while I lived rent-free and prepared myself for the simple life. That December, I would be starting work as a bartender at Goldminer’s Daughter Lodge in Alta, Utah, a tiny ski town outside of Salt Lake City. Room and board were included in the job; I’d make enough pocket money for booze, and my life would consist of skiing, sleeping, and socializing. No emails.

Image of a sign for the Town of Alta, population 370, elevation 8,460
Just down the winding road from Alta Ski Area.

The simple life was okay for a little bit, but bartending at a 3:2 beer bar and skiing every day wasn’t as fulfilling as I’d hoped. I cut the season short and moved to Los Angeles in March with my partner at the time. We had a mutual friend with an open room in Hollywood, and I was starved for city-living. (I have since learned that LA is not the city-living I expected, at all, but that’s another conversation.)

Time to Get a Job (for real this time)

I formally announced I was back on the scene, reached out to old clients and people from my New York network, and was even on a podcast out of the gate. None of that translated into much paying work. Luckily, I had a cushion of savings to float me for a few months (Freelancing Rule #1: You must have savings), but my heart just wasn’t in the freelance hustle this time. The prospect of negotiating contracts and engaging new leads was nauseating rather than exciting, and the small business website work I did was no longer the challenging and invigorating experience it had been before.

I decided to get a full-time job, for real this time. Once again, I wanted to work on a team and on bigger projects. I was tired of doing everything myself, and I wanted to learn from and share my experience with others. And, you know, a regular paycheck.

I set to work applying for jobs, putting long hours into carefully crafted cover letters. I had several promising interviews, got my hopes way up a couple of times, and received zero job offers. For one particular role, I’d gotten as far as discussing salary requirements and start dates, and was expecting an offer letter within the week. Then, the next week they were all of a sudden no longer hiring. I didn’t run into any FizzBuzz, for better or for worse.

I started to question why my designer/developer skillset appeared to hold so little value now when I’d felt so in demand just a year ago. I stubbornly refused to learn React just so I could have it on my resume—I’m great at other important things, why can’t people see that?! I wondered whether the five years of self-employment was a hindrance, or was there something fundamentally wrong with how I interviewed? Did I shoot myself in the foot with this whole “non-unicorn” thing in the first place?

These months were a major ego-check. It turns out, full-time jobs aren’t something you can just “get.” It’s just not that easy, for me at least.

The Value of HTML and CSS

Responding to job posts with those carefully crafted cover letters had a very low return on investment so I decided to change my approach. Instead of putting my time into writing said cover letters, I would focus on writing about real things and becoming a better developer, and the jobs would come to me. I launched a well-thought-out redesign of my website, published a Reverse Job Post, and buckled down on my JavaScript studies.

This was right around the time Mandy Michael wrote “Is there any value in people who cannot write JavaScript?” which hit the nail on the head. I wrote a question into ShopTalk show about this phenomenon and mentioned to Chris that I’d love to come on the show and talk about it if they’d like. The next day, Chris invited both Mandy and me to come on the show and hash it out:

HTML and CSS are valuable, but intimate knowledge of them has become more of a specialist role. Perhaps, one can position their skills as HTML, CSS, plus something else (e.g. UI design or WordPress). The nature of products and rapid feature releases deem quality HTML and CSS an afterthought at many companies so at the moment, maybe the demand just isn’t there. Perhaps the rise in accessibility awareness, design systems, and time lost debugging bad CSS will change the tide?

The episode was well received; I was obviously not the only one struggling with this issue. I made a Github repository called Front-end Discourse with the intention of gathering and synthesizing opinions and coming up with a plan of action on the job titles front. Chris even wrote about the job titles conundrum here on CSS-Tricks. The momentum was there; this could be my thing!

But then…I let it die.

An Unexpected Twist

A few days after the ShopTalk episode came out, I received this tweet:

Image of tweet asking Lara if she is still looking for a job, with a link to job post at careers.google.com/jobs

Umm…that’s a link to a Google job post.

I thought it was a joke at first, but nope, the tweet author sent me an email later that day, and it was the real deal! They’d been referred to me by a benevolent figure in the web industry whom I’d never met. I had a call with them and another member of their team, and it was magical. They told me all about a new team starting within Developer Relations at Google that would be working to improve the “Web Content Ecosystem.” Web Content Ecosystem? That’s WordPress! And they were recruiting me! Holy sh#t, this actually happens!

This was my dream job, not a front-end designer/developer role. I didn’t even know this was a job! I had already been doing this work on my own time for several years: teaching and speaking about WordPress, writing informational blog posts, recording videos, and helping people use WordPress more responsibly. And they would move me to San Francisco! I was not a huge fan of Los Angeles.

Unfortunately, Google doesn’t just “give” people jobs…you have to interview.

Computer Science Bootcamp

Now we have me, the designer who applied for a JS job and failed FizzBuzz, preparing for the Google interview otherwise known as the grandparent of all technical white-boarding interviews. It was time to swallow any feelings I had toward this interviewing style and get to work.

I had three weeks until a “coaching call” that would unofficially determine whether or not I could skip the technical phone screening and jump straight to the day of on-site interviews because, duh, this was meant to be. Luckily, this coincided with a lull in freelance work, which had also been picking up, so for about a week and a half, I put myself through a self-directed computer science bootcamp. On the way, I wrote a bunch of blog posts about what I learned.

Oh, how I longed to write that Tales of a Non-Unicorn: I GOT A JOB AT GOOGLE, F@#KERS!!! follow-up for all those Reddit haters after it was said and done!

The day of the coaching call arrived, and it was fantastic! I was a little slow on the coding question, but it wasn’t as hard as I’d thought, I aced the role-related questions, and the interviewer was excellent. I heard back from the recruiter who was coordinating with me, and he said I could go straight to the on-site interviews.

In the meantime, I went to WordCamp US in Nashville where this particular team at Google was a sponsor. I got to meet a few of the folks I’d be working with, and it seemed like such a great fit. This Google interest and being at WordCamp made me question why, at the beginning of my job search, I had seen my knowledge of WordPress as such a secondary skillset. WordPress is everywhere! And its awesome! I mean, sure, it’s not that “cool” yet, but mark my words, it will be in the “cool” ranks soon enough.

The Non-Unicorn Interviews at Google

In the week leading up to the interview, I focused on researching the role and beefing up my passion for improving WordPress and helping those who work with it. This was not a software engineering role, after all; in Developer Relations, passion for and knowledge of your subject is more important than knowing binary tree traversal, right?

Google flew me to San Francisco and put me up in a nice hotel. I had a full day of four interviews—usually, it’s five, one was canceled—and a long, enjoyable lunch with the folks I’d been in touch with from the get-go. I didn’t feel great about my performance in the technical parts of the interviews, but I did my best and my strategy was to come off as a great coworker who knows when to ask for help. When in doubt, I remembered the strong correlation between “hard interview” and “received offer” on Google’s Glassdoor profile.

Back in LA, freelance work kept me busy while I waited for a verdict, which wasn’t long. I felt relatively zen about the whole thing. Yes, I had my hopes up, but if it didn’t work out, I at least had work to pay the bills, and it wasn’t going half-bad. I’d been contracting with an agency and learning a lot; it wasn’t the small business WordPress sites I’d been building all by myself previously.

The Thursday after my Monday interview, I got a call from my recruiter contact. They were not going to proceed with the approval process at this time. He said I showed some very promising “Google-y” qualities, but my performance in the coding portion of the interviews wasn’t strong enough. He said he had it in his calendar to reconnect with me in six months, and that he would keep an eye out for less technical roles that might be a better fit.

…oof.

Incredibly, I was able to fend off the majority of the anger and the “I’m a failure and I suck at everything” thoughts that go hand-in-hand with rejection, maybe in part because I received such a nice email from one of the people I’d been in touch with throughout the process. He had applied three times before he got a job there—which apparently is not uncommon—and this simply meant I’d be taking a slightly different path. They were all bummed I didn’t make it.

This brings us back to the present. I don’t feel sour about algorithms or white-boarding interviews…I have another one to get ready for in six months! Unless, of course, another really awesome opportunity comes my way in the meantime. Who knows.

This whole job search has been such a ridiculous roller coaster of hopes slowly going up then crashing down. If there’s one thing I’ve learned, it’s that I still don’t know where I’ll end up, but I’m doing my best and I’ll keep doing it until the right thing comes along.

Silhouette of a car on a roller coaster about to go down a large hill

</story>

Whew, that was a lot! Thanks for making it this far. A+ for you, reader!

Post-Mortem

Before I wrap this thing up, I want to make a few observations about this whole job searching process that I hope can help others on their roller coaster ride.

  1. Algorithms and white-boarding interviews aren’t necessarily bad. I think they can be implemented badly. The Big Tech Companies are fully aware that they miss out on great candidates because of algorithm questions, but this interviewing strategy is so good at filtering out bad candidates that they keep it around. It sucks for us, but I don’t see that changing anytime soon. Plus, I learned a hell of a lot of stuff preparing for it, and it’s made me a better developer and better human being.
  2. Write a “Reverse Job Post.” I don’t recall where I learned about it, but here’s mine for reference. Even if no one reads it, it’s a great way to figure out what type of job and company you are looking for, and you could totally paste a link to it in the cover letter field for an application and call it a day.
  3. Learn computer science fundamentals. I know we are already inundated with things to learn, so it’s hard to preach this, but having context for what the tools we use actually are has helped me a lot. For example, two months ago I would have had a hard time wrapping my mind around GraphQL, but in my interview preparation I learned about graphs and tree data structures, so I was able to understand the concept relatively easily. Cracking the Coding Interview is not a good place to start, BaseCS and the Impostor’s Handbook are. Also, stay tuned for some relevant articles here on CSS-Tricks, from yours truly!
  4. Don’t spend all of your time on job boards. It’s a crapshoot. I think there are great job boards, but in general, no matter how quality the listing, whether or not the position is actually available or accurately represented in the post is a toss-up.
  5. Be vocal. I doubt any of this Google stuff would have happened if I hadn’t written into ShopTalk show and asked Chris to have me on the episode. If you have an impulse to write something or have a question or feel the urge to tweet at someone you don’t know, do it (but be a good person about it, obviously). The more web people that know you exist, the more likely it is that something will come your way.

Those are some things that helped me, but I still don’t have a job, so maybe don’t listen to what I say. I don’t know. It’s an incredibly difficult and demeaning process, and there’s no secret sauce that works for everyone. Our industry is a young one, and as far as I’m aware, there is no such thing as a surefire career path in web development.

I hope I don’t write another “Tales of a Non-Unicorn” installment. The whole idea of a “unicorn” is bogus, anyway. We are all just people, with different levels of knowledge in different areas, and if you can honestly say you’re doing your best then I think that’s all you can do.

What I will be writing, however, are some “Computer Science Study Guides” for the self-taught developer, here on CSS-Tricks, and maybe some stuff about how cool WordPress is nowadays. At the very least, “Intro To Algorithms” will be coming at you, soon!

How about you, reader?

Have you been on this roller coaster ride, too? Where did you end up? What advice can you offer to those of us who are still in the midst of our journey?


Tales of a Non-Unicorn: A Story About the Roller Coaster of Job Searching is a post from CSS-Tricks

A Round-Up of 2017 Round-Ups

This week marked the beginning of a new year and with it came a slew of excellent write-ups from folks in our industry reflecting on the year past. We thought it would be nice to compile them together for easy reference. If you know of any others that should be on everyone’s radar, please leave it in the comments.

Now on to the round-up of round-ups!

Rachel Andrew

Having been wandering the globe talking about CSS Grid for almost five years, Grid finally shipped in browsers in 2017. This was good, as I didn’t really want to be some kind of CSS vapourware lady. I knew Grid was important the first time I read the initial spec. I had no idea how my championing of the specification would change my life, and allow me to get to work with so many interesting people.

Read More

Geri Coady

One of my biggest achievements this year was the release of my second book, Color Accessibility Workflows, published by A Book Apart. I’m hugely grateful for any opportunity to talk about color and how it can impact people in the digital world, and writing for A Book Apart has long been a dream of mine.

Read More

Monica Dinculescu

You can tell I hate writing year in reviews because this one is really, really late. I tend to hate bragging, and I definitely hate introspective and, in particular, I always think I am underperforming (and that’s fine). However, that’s usually not true, and writing a year in review forces me to see the awesome things I did, so even if I did end up underperforming, at least I can learn from that. That’s the whole point of post-mortems, right?

Read More

Sarah Drasner

This year has been a surreal one for me. I’ve had years that were particularly tough, years that trended more cheerfully, but 2017 was unique and bizarre because I felt an immense guilt in my happiness.

I think this might have been the year I found the most personal happiness, but the giant caveat in everything was watching the world divide, watching racism, sexism and hatred rise, and seeing some real damage that incurred on people’s lives around the world.

Read More

Brad Frost

Throughout 2017, when people asked how I was doing, I’d say “Great…for the things I can control.” 2017 was a rough year at a macro level for everybody, and I found myself coping with the state of the world in a number of different ways. But on a personal level, I had a rewarding year full of a lot of work, a lot of travel, and even some major life changes.

Read More

Geoff Graham

It feels kind of weird to include my own round-up, but whatever.

I’ve typically set goals for myself at the start of each year and followed up on them somewhere towards the end of the year. Unfortunately, the last time I did that out loud was in 2014. I’ve been pretty quiet about my goals and general life updates since then and it’s certainly not for lack of things to write about. So, I’m giving this whole reflection thing the ol’ college go once again.

Read More

Jeremy Keith

Jeremy published 78 blog posts in 2017 (or 6.5 per month as he calculates it) and noted his personal favorites.

Read More

Zach Leatherman

I had an incredibly productive year of side projects, learning, and blog posts—I can attribute almost all of that rediscovered time and energy to quitting Facebook very early in the year. It’s also been amazing to see my daughter grow and learn—she turned two this year and I really love being a dad. We now have our own secret handshake and it’s my favorite thing.

Read More

Ethan Marcotte

And finally, one of the things I’m most proud of is, well, this little website, which I launched hastily just over a year ago. And over the last entirely-too-eventful year, I’ve surprised myself with just how much it helped to be blogging again. Because while the world’s been not-so-lightly smoldering, it felt—and feels—good to put words in a place where I can write, think, and tinker, a place that isn’t Twitter, a place that’s mine.

Read More

Eric Meyer

While this is not so much a reflection on the past year, Eric did mark the new year with a livestream redesign of his personal website—the first design update in 13 years.

My core goal was to make the site, particularly blog posts, more readable and inviting. I think I achieved that, and I hope you agree. The design should be more responsive-friendly than before, and I think all my flex and grid uses are progressively enhanced. I do still need to better optimize my use of images, something I hope to start working on this week.

Read More

Dave Rupert

My big work task this year was building a Pattern Library and it’s exciting to see that work beginning to roll out. The most gratifying aspect is seeing the ultimate Pattern Library thesis proven out: Speed. Pages load faster, CMS integrations are faster, and we can successfully turn out new production pages within a 1-day turnaround.

Read More

David Walsh

David used the new year to think about and plot upcoming goals.

Every turn of the year is a new opportunity to start over, set goals, and renew optimism that time can heal wounds and drive us to change and achieve. For me 2018 is my most important year in a long time; 2018 needs to serve as a turning point for this blog and my career.

Read More

Trent Walton

Dave, Reagan, and I celebrated our 10th official year as Paravel. In addition to some shorter-term projects, we undertook a large-scale pattern library and front-end update that is rolling out in phases this year. We’ve also enjoyed bringing in 6+ collaborators/teams to assist with projects when the need has arisen. I bet we do more of this in 2018—collaborating with friends has been fun.

Read More

CSS-Tricks

Think we’d leave out our own round-up? Of all the site stats Chris shared in this post, this one nicely summed up the action around here in 2017:

We were on a publishing roll though! We published 595 posts, blowing away last year with only 442, the previous record. We also published 50 pages (i.e. snippets/videos/almanac entries) beating 43 last year. Certainly, we’re in favor of quality over quantity, but I think this is a healthy publishing pace when our goal is to be read, in a sense, like a magazine.

Read More


A Round-Up of 2017 Round-Ups is a post from CSS-Tricks

What You Build

I tweeted this yesterday and it seemed to resonate with some folks:

What I was feeling when I wrote that was a little tired of endless discussions on tech minutia and yearning for more focus on what we are building and discussion about why.

If you’re a reader of this site, you and I live in the same bubble. It’s a nice bubble. It’s full of smart people who like to chat about web design and development. I live it and love it.

It’s easy to get into a heated discussion about frameworks, what type of class names make the most sense, which optimization techniques are most important, or what part of your code base is should be responsible for styling. Those are great discussions that guide our industry.

But what is more important? The naming convention you chose or if your user can actually book a flight? Which state store library you picked or if you actually had the scarf your user was looking for? Which command line tool pulled your dependencies or whether someone was able to find and read the instructions to send in their court appeal?

I was trying to encourage people to build and think about what they are building rather than get too discouraged about the how. You’re building things for people and that’s such a big responsibility. One that outweighs technical choices, as important as they seem.

I enjoyed the pushback I got on it though.

Most of it centered around the fact that if you make poor tech choices, that limits the quality of what you build and slows your ability to change and adapt to changing user needs. Fair enough.

Good tech just might lead to directly better features and UX for your users. Fair enough. Good tech might be a differentiator between you and your competition. Fair enough.

My favorite was calling out the story of the three little pigs. If you aren’t familiar, there is a Big Bad Wolf that is trying to eat the piggies. Each of them built a house to protect themselves. I imagine you can guess which of the pigs did better: the one who built their house out of hay, or the pig who built their house out of bricks.

Fair enough.

Drew McLellan gets into this in All That Glisters, but focuses on the old vs new tech issue:

There are so many new tools, frameworks, techniques, styles and libraries to learn. You know what? You don’t have to use them. You’re not a bad developer if you use Grunt even though others have switched to Gulp or Brunch or Webpack or Banana Sandwich. It’s probably misguided to spend lots of project time messing around with build tool fashions when your so last year build tool is already doing what you need.

And this gem:

Software, much like people, is born with a whole lot of potential and not much utility. Newborns — both digital and meaty — are exciting and cute but they also lead to sleepless nights and pools of vomit.

He goes on to say that what you are building might help dictate your tech choices. Ah yes, the what. Not only is what your things does litearlly the only thing people care about, it also helps guide tech choices.


What You Build is a post from CSS-Tricks

Auto-Sizing Columns in CSS Grid: `auto-fill` vs `auto-fit`

One of the most powerful and convenient CSS Grid features is that, in addition to explicit column sizing, we have the option to repeat-to-fill columns in a Grid, and then auto-place items in them. More specifically, our ability to specify how many columns we want in the grid and then letting the browser handle the responsiveness of those columns for us, showing fewer columns on smaller viewport sizes, and more columns as the screen estate allows for more, without needing to write a single media query to dictate this responsive behavior.

We’re able to do that using just one line of CSS — the one-liner that reminds me of when Dumbledore just waved his wand in Horace’s apartment and “the furniture flew back to its original places; ornaments reformed in midair, feathers zoomed into their cushions; torn books repaired themselves as they landed upon their shelves…”.

This magical, media-query-less responsiveness is achieved using the repeat() function and the auto placement keywords.

Much has been written about this particular one-liner, so I won’t be elaborating on how it works. Tim Wright has a great writeup on this that I recommend reading.

To summarize, the repeat() function allows you to repeat columns as many times as needed. For example, if you’re creating a 12-columns grid, you could write the following one-liner:

.grid { display: grid; /* define the number of grid columns */ grid-template-columns: repeat(12, 1fr);
}

The 1fr is what tells the browser to distribute the space between the columns so that each column equally gets one fraction of that space. That is, they’re all fluid, equal-width columns. And the grid will, in this example, always have 12 columns regardless of how wide it is. This, as you have probably guessed, is not good enough, as the content will be too squished on smaller viewports.

So we need to start by specifying a minimum width for the columns, making sure they don’t get too narrow. We can do that using the minmax() function.

grid-template-columns: repeat( 12, minmax(250px, 1fr) );

But the way CSS Grid works, this will cause overflow in the row. The columns will not wrap into new rows if the viewport width is too narrow to fit them all with the new minimum width requirement, because we’re explicitly telling the browser to repeat the columns 12 times per row.

To achieve wrapping, we can use the auto-fit or auto-fill keywords.

grid-template-columns: repeat( auto-fit, minmax(250px, 1fr) );

These keywords tell the browser to handle the column sizing and element wrapping for us, so that the elements will wrap into rows when the width is not large enough to fit them in without any overflow. The fraction unit we used also ensures that, in case the width allows for a fraction of a column to fit but not a full column, that space will instead be distributed over the column or columns that already fit, making sure we aren’t left with any empty space at the end of the row.

At first glace of the names, it might seem like auto-fill and auto-fit are opposites. But in fact, the difference between is quite subtle.

Maybe it seems like you are getting extra space at the end of the column with auto-fit. But when and how?

Let’s take a look at what is really happening under the hood.

Fill or Fit? What’s the difference?

In a recent CSS workshop, I summarized the difference between auto-fill and auto-fit as follows:

auto-fill FILLS the row with as many columns as it can fit. So it creates implicit columns whenever a new column can fit, because it’s trying to FILL the row with as many columns as it can. The newly added columns can and may be empty, but they will still occupy a designated space in the row.

auto-fit FITS the CURRENTLY AVAILABLE columns into the space by expanding them so that they take up any available space. The browser does that after FILLING that extra space with extra columns (as with auto-fill ) and then collapsing the empty ones.

This may sound confusing at first, but it makes a lot more sense when you visualize this behavior. So we’ll be doing exactly that, with the Firefox DevTools’ Grid Inspector helping us visualize the size and position of our Grid items and columns.

Consider the following demo as an example.

See the Pen auto-fill vs auto-fit by Sara Soueidan (@SaraSoueidan) on CodePen.

The columns are defined using the repeat() function and have a minimum width of 100px, and a maximum set to 1fr , so that they would expand and equally share any extra space when it is available. As for the number of columns per row, we’re going to use the auto-placement keywords, so that we let the browser take care of the responsiveness of the grid and will wrap the columns into new rows when needed.

The browser will place and size the columns in the first example using the auto-fill keyword, and it will use auto-fit for the second.

.grid-container--fill { grid-template-columns: repeat(auto-fill, minmax(100px, 1fr));
} .grid-container--fit { grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
}

Up to a certain point, both auto-fill and auto-fit show identical results.

But they don’t have identical behavior under the hood. It just so happens that they will give the same result up to a certain viewport width.

The point at which these two keywords start exhibiting different behaviors depends on the number and size of columns defined in grid-template-columns, so it will differ from one example to another.

The difference between these two keywords is made apparent when the viewport gets wide enough to fit one (or more) extra column(s) (that) into the row. At that point, the browser is presented with two ways to handle the situation, and how it handles it largely depends on whether or not there is content to be placed into that extra column.

So, when the row can fit a new column, the browser goes like:

  1. “I have some space to fit a new column in there. Do I have any content (i.e. grid items) to go into that extra column? Yes? OK, all good. I’ll add the column into the row, and it will wrap into a new row on smaller viewports.”
  2. In the case where there is no content to place into a new column: “Do I allow this new column to occupy space in the row (and, therefore, affect the position and size of the rest of the rows)? or do I collapse that column and use its space to expand the other columns?”

auto-fill and auto-fit provide the answer to that last question in particular, and dictate how the browser should handle this scenario. To collapse or not to collapse, that is the question. And that is also the answer.
Whether you want it to collapse or not depends on your content, and how you want that content to behave in the context of a responsive design.

Let’s see how this works. To visualize the difference between auto-fill and auto-fit, take a look at the following screen recording. I’m resizing the viewport enough to create horizontal space that’s enough to fit one (or more) column(s) into the row. Remember that these two rows are identical, and have the exact same of content and column number. The only difference in this demo is that I’m using auto-fill for the first one and auto-fit for the second.

Notice what is happening there? If it’s still not clear, the following recording should make it clearer:

auto-fill behavior: “fill that row up! Add as many columns as you can. I don’t care if they’re empty — they should all still show up. If you have enough space to add a column, add it. I don’t care if it’s empty or not, it’s still occupying space in the row as if it were filled (as in: filled with content/grid items).”

While auto-fill fills the row with as many columns as it can, even if those columns are empty, auto-fit behaves a little differently.
auto-fit does, too, fill the row with more columns are the viewport width increases, but the only difference is that the newly added columns (and any column gaps associated with them) are collapsed. The Grid inspector is a fantastic way to visualize this. You’ll notice that columns are being added when you keep your eye on the Grid line numbers, which will increase as the viewport width increases.

auto-fit behavior: “make whatever columns you have fit into the available space. Expand them as much as you need to fit the row size. Empty columns must not occupy any space. Put that space to better use by expanding the filled (as in: filled with content/grid items) columns to fit the available row space.”

A useful tip to remember here is that the columns added in both cases (whether collapsed or not) are not implicit columns — that has specific meaning in the spec. In our case, we are adding/creating columns in the explicit grid in the same way as if we declared you wanted 12 columns, for example. So column number -1 will work to target the end of this grid, which it doesn’t if you are creating columns in the implicit grid. Props to Rachel Andrew for this tip.

Summing Up

The difference between auto-fill and auto-fit for sizing columns is only noticeable when the row is wide enough to fit more columns in it.

If you’re using auto-fit, the content will stretch to fill the entire row width. Whereas with auto-fill, the browser will allow empty columns to occupy space in the row like their non-empty neighbors — they will be allocated a fraction of the space even if they have no grid items in them, thus affecting the size/width of the latter.

Which behavior you want or prefer is completely up to you. I have yet to think of a use case where auto-fill would make more sense than auto-fit. Do you have any use cases? If you do, please feel free to share them in the comments below.


Auto-Sizing Columns in CSS Grid: `auto-fill` vs `auto-fit` is a post from CSS-Tricks

Five Design Fears to Vanquish With CSS Grid

CSS grid, along with a handful of other new CSS properties, are revolutionizing web design. Unfortunately, the industry hasn’t embraced that revolution yet and a lot of it is centered around fear that we can trace back to problems with the current state of CSS grid tutorials.

The majority of them fall into one of two categories:

  1. Re-creating classic web design patterns. Grid is great at replicating classic web design patterns like card grids and “holy grail” pages.
  2. Playing around. Grid is also great for creating fun things like Monopoly boards or video game interfaces.

These types of tutorials are important for new technology. They’re a starting point. Now is the time, as Jen Simmons says, to get out of our ruts. To do that, we must cast off our design fears.

Fear 1: Asymmetry

We’ve been trained in the era of frameworks that symmetric and orderly designs are better. It’s true that for many applications a symmetric design or an orderly grid of items is preferred. Yet, asymmetry has the ability to capture the eye and mind in a way that symmetry never will. Asymmetry is interesting in its disorder. If you’re nervous, you can always start small.

See the Pen Asymmetric Promo Grid by Bryan Robinson (@brob) on CodePen.

In this example, we have a simple promotional space. By using an asymmetric vertical and horizontal layout, we can make a stronger visual match between our icon and our button. This isn’t a large space, but it’s not afraid of using whitespace to draw the user’s eye where we want it to go.

Speaking of whitespace…

Fear 2: Negative Space

As we left the early 2000s, we decided it was OK if users had to scroll. We began introducing whitespace into our designs and most of this fell between rows of content. This made our designs much cleaner, but is vertical whitespace the only valid option?

In this example, the design incorporates negative space to create a sense of exploration through the page. By not using traditional content rows, the user’s eye is given a chance to scan and take things in at a slower pace.

See the Pen Experimental Homepage by Bryan Robinson (@brob) on CodePen.

Fear 3: Punk Rock?

There’s no shortage of design talks focused on the print layouts of the 1970s. It was a time of great stability in design tooling, which allowed creativity to bloom. With that came inspired and avant-garde design work that centered around the punk-rock scene.

So my question is this: Can we be punk rockers in web design?

In this example, the design doesn’t care about your preconceptions. Text overlap is a bug? Nope, it’s a feature. Images shouldn’t compete with each other? Survival of the fittest!

See the Pen Grid Overlap and Punk Rock Meditation by Bryan Robinson (@brob) on CodePen.

As this example asks, is this a good idea? It’s completely up for debate. What I know is this: our tools have matured and become more stable; now is the time for experimentation. Do we want the web to look the same year after year, or do we want to dream up new and exciting patterns?

Fear 4: New Sources of Inspiration

Sources of inspiration shouldn’t cause fear, but they do often cause headaches. Remember, inspiration doesn’t mean a 1:1 translation of a concept.

Punk rock graphic design

I mentioned earlier the amazing designs that came out of the ’70s and ’80s. Here are some links to continue researching punk-rock design:

  • The Art of Punk Posters by Sean O’Hagan
  • The Art of Chaos: Punk Rock’s Timeless Influence on Graphic Design by Simon Martin

Vintage movie graphic design

Studying film in college gave me a great appreciation for vintage movie graphic design. One of my professors once told me: “You should be able to tell the tone and subject of a film by its title cards.”

This is especially true of post-World War II films. Their title sequences and posters are a treasure trove of design ideas for setting a scene.

  • The Graphic Art of Film Title Design Throughout Cinema History by Rebecca Gross
  • Saul Bass on His Approach to Designing Movie Title Sequences by The Academy of Motion Picture Arts & Sciences

Learn how to create graphic design grids

Graphic designers have been using grids for layout for centuries, and there’s a lot of great literature on the creation of these grids:

  • Video: Mark Boulton | Designing Grids | CSS Day 2017
  • Guity Novin’s A History of Graphic Design: Chapter 58, History of Layout Design and Modern Newspapers and Magazines
  • Layout Essentials: 100 Design Principles for Using Grids by Beth Tondreau

Fear 5: Fallbacks

It’s true that Grid has only 74% support in the U.S. (at the time of this writing).

That should not stop you from pushing your designs forward. There are plenty of strategies for starting with support for all browsers and then pushing forward into new patterns.

  • Using CSS Grid: Supporting Browsers Without Grid by Rachel Andrew
  • Video: Progressing Our Layouts by Jen Simmons
  • Falling Forward — Rethinking Progressive Enhancement, Graceful Degradation and Developer Morality by Bryan Robinson

What’s next?

It falls to each of us to push our industry forward. The technology is in place to challenge ourselves to create new and interesting designs. This doesn’t have to be as pointed and intense as some of these examples. It starts by realizing we can do amazing things … or we can stagnate.

How will you push the industry forward?


Five Design Fears to Vanquish With CSS Grid is a post from CSS-Tricks

Front-End Tools: My Favorite Finds of 2017

Another twelve months have passed and I’m sure all of you have come across some interesting new coding techniques, technologies, CSS tricks (of course!), and other stuff that will make you more productive in 2018.

As some of you might know, I curate a weekly newsletter called Web Tools Weekly, in which I feature dozens of links every week to new tools, mostly focusing on stuff that’s useful for front-end developers. So it’s an understatement to say that I’ve come across lots of new tools over the past 12 months.

As I’ve done in years past, I’ve put together a brief look at some of my favorite finds in front-end tools.

And please note that this is not a list of the “best” or “most popular” tools of 2017 – this has nothing to do with popularity or number of GitHub stars. These are tools I believe are unique, interesting, and practical – but not necessarily all that well-known. They are some of my personal favorite finds of the year, nothing more.

tlapse

When working on a new project, especially a large and lengthy one, it’s easy to forget the number of changes the project’s layout has gone through. tlapse is a command-line utility that allows you to set up automated screenshots of your work at specified intervals, essentially giving you a visual timeline of your development in the form of a series of screenshots.

tlapse

The project has 1,100+ stars on GitHub, so it seems developers are finding a valid use for this, even though it seems a little narcissistic at first glance. Besides the novelty of being able to look back at the progress of your project, I suppose tlapse could also be used to send visual progress reports to clients, project managers, or other development team members.

You install tlapse as a global npm package:

npm install -g tlapse

Then run it in the background and start your work:

tlapse -- localhost:3000

By default, tlapse will take screenshots at one minute intervals and the screenshots will be added to the tlapse folder in the current project (i.e. where you execute the command):

Running tlapse with the default settings

Usefully, tlapse will also take a screenshot only if it detects the layout has changed in some way. So if the next scheduled screenshot is the same as the previous, it will skip it:

tlapse skipping a duplicate screenshot

If you want to use a different directory or change the screenshot frequency, enter these as options along with the regular command:

tlapse --every 3m --directory ./screenshots -- localhost:3000

As the name suggests, tlapse allows you to make a time lapse video or animated GIF that demonstrates the progress of your work. Here’s one I created while mock-building a Bootstrap-based layout:

tlapse example

Overall, this is an easy to use tool, even for those not very comfortable with the command line, and there are certainly some use cases for wanting to take screenshots of work in progress.

KUTE.js

JavaScript animation libraries are not rare. But KUTE.js caught my eye due to its main selling point: Performance. It can’t be denied that if you’re going to even consider complex animations in web apps today, you have to be prepared to deal with potential performance problems as a result of users accessing your app on mobile devices or on slower connections.

KUTE.js

The moment you visit the KUTE.js home page, you’re greeted with a colorful, complex, super-smooth animation, testifying to the truth of this tool’s claims.

In addition to performance, two other things I like:

  • A really nice API
  • An excellent callback system

You start to build your animations by creating tween objects. For example:

var tween = KUTE.fromTo( '.box', {backgroundColor:'yellow'}, {backgroundColor:'orange'}, {complete: callback}
);

The above example creates a fromTo() tween with various options. Inside fromTo() I’ve specified the selector for the target element, the start and end values for the property being animated, and a callback function to execute when the animation is complete.

You can also create tweens using to(), allTo(), and allFromTo(), with the latter methods letting you apply animations to collections of objects.

The callback functionality is very fine-grained, allowing you to run code (which could include calling a new animation altogether) at specified points, including:

  • When an animation starts
  • For each frame of the animation
  • When an animation is paused
  • When an animation is resumed after having been paused
  • When an animation is stopped
  • When an animation is completed

I’ve only scratched the surface of the features available. The documentation on the site is good, so check that out for the full API. The CodePen below is based on one of the demos from the API docs, which uses the .chain() method to chain multiple transform animations.

See the Pen Chain Transform Animations with KUTE.js by Louis Lazaris (@impressivewebs) on CodePen.

ScrollDir

Scrolling libraries have been popular for some time now. ScrollDir, from the developers at Dollar Shave Club, is a really simple, tiny, and intuitive utility to help you do a couple of simple things with scroll detection.

ScrollDir

Once you drop in the library, in its simplest form the script just works. You don’t need to call the scrollDir() method or anything like that. If you open your browser’s developer tools and examine the live DOM while scrolling up and down on a page running ScrollDir, you can see what it does:

As shown in the above GIF, this utility adds a data-scrolldir attribute to the page’s <html> element, which changes to one of two values, depending on scroll direction:

<!-- when the user is scrolling down -->
<html data-scrolldir="down"> <!-- when the user is scrolling up -->
<html data-scrolldir="up">

It defaults to “down” when the page hasn’t yet been scrolled, although it seems like it could benefit from having a “neutral” class as a third optional state.

With this attribute in place, it’s super easy to make custom changes to a page’s layout with nothing but CSS, taking advantage of CSS’s attribute selectors:

[data-scrolldir="down"] .header-banner { top: -100px;
} [data-scrolldir="up"] .footer-banner { bottom: -100px;
}

You can see the above code, combined with some simple CSS transitions, demonstrated in the CodePen below, which is similar to the example on the ScrollDir home page:

See the Pen ScrollDir basic demo by Louis Lazaris (@impressivewebs) on CodePen.

ScrollDir offers a few minor API options if you choose to use the non-auto version of the script. In either case it’s dead simple to use and I’m sure will come in handy if you’re building something that needs changes to occur on the page based on scroll direction.

CodeSandbox

Due to the popularity of web app development using libraries like React and Vue, a number of different IDEs and other code tools have come on the scene, aimed at helping developers who are working with a specific library or framework.

CodeSandbox

CodeSandbox is an online code editor for four of the current big players: React, Vue, Preact, and Svelte. This tool is somewhat in the same category as CodePen Projects, but is specifically designed for each of the four aforementioned libraries.

One of the nice features of CodeSandbox is the ability to add npm packages in the left side bar, under a pane called “Dependencies”. There’s a button called “Add Package” that allows you to search for packages in the npm registry:

Searching for npm packages on CodeSandbox

And if your app is missing a dependency, CodeSandbox will indicate this with an error message and an option to add the required package. In the following GIF, I’ve pieced together this React calculator app as an example project in CodeSandbox:

Installing missing dependencies on CodeSandbox

Notice the project still had a missing dependency, which I was able to install instantly. Here’s the CodeSandbox link to my version of that project.

Another feature that caught my eye is the ability to “peek” at the definition of a function in the code window:

CodeSandbox's Peek feature

Like many native IDEs, this allows you to be able to track down a function’s source, for quicker debugging and whatnot. There are also some clean inline code completion features, just like a native IDE.

There are tons more features I haven’t discussed here – including GitHub integration, deployment via ZEIT, and lots more – so be sure to poke around the different panels to get a feel for what you can do.

AmplitudeJS

AmplitudeJS is a dependency-free (we like that nowadays don’t we?) HTML5 audio player “for the modern web”. I think a lot of independent hobby-driven music makers with web development experience will appreciate this one for a number of reasons.

Amplitude allows you to build your own audio player with your own custom design and layout. To add a song list, you can add it via the main Amplitude.init() method in JSON format. Here’s an example with three songs:

Amplitude.init({ songs: [ { name: "Song Name One", artist: "Artist Name", album: "Album Name", url: "/path/to/song.mp3", cover_art_url: "/path/to/artwork.jpg" }, { name: "Song Name Two", artist: "Artist Name Two", album: "Album Name Two", url: "/path/to/song.mp3", cover_art_url: "/path/to/artwork.jpg" }, { name: "Song Name Three", artist: "Artist Name Three", album: "Album Name Three", url: "/path/to/song.mp3", cover_art_url: "/path/to/artwork.jpg" } ]
});

The code behind this player generates the audio using the Web Audio API, which is kind of like adding HTML5’s audio element, but with nothing but JavaScript. So you could technically generate a functioning version of the AmplitudeJS player with zero HTML. See this CodePen as an example, which auto-plays the only song in the playlist and has no HTML. Even if you examine the generated DOM, there’s nothing there; it’s just JavaScript. In that instance, I’m using the "autoplay": true option in the init() method (the default is false, of course).

If you want to see the flexible and varied audio players that can be built with AmplitudeJS, be sure to check out the examples page. The Flat Black Player is probably my favorite for its similarity to an old-school MP3 player. I’ve put it into a CodePen demo below:

See the Pen LeEgyj by Louis Lazaris (@impressivewebs) on CodePen.

In terms of configuring AmplitudeJS, here are some of the highlights.

All the info you provide in the JSON can be added dynamically to the player wherever you want. For example the following HTML would display the song name, artist, album, and file URL for the currently playing track:

<p amplitude-song-info="name" amplitude-main-song-info="true">
<p amplitude-song-info="artist" amplitude-main-song-info="true">
<p amplitude-song-info="album" amplitude-main-song-info="true">
<p amplitude-song-info="url" amplitude-main-song-info="true">

Notice the amplitude-song-info attribute, which defines which bit of data you want to inject into that element. You wouldn’t necessarily use paragraphs, but that’s one way to do it. You can see this in action in this CodePen demo.

With the metadata features, adding a running time or time remaining indicator for the current song is easy:

<p class="amplitude-time-remaining" amplitude-main-time-remaining="true">
<p class="amplitude-current-time" amplitude-main-current-time="true">

Another great feature is the ability to work with callbacks (which is pretty much a must for any good API). Here’s two of the callback options used in a simple example:

Amplitude.init({ songs: [ // songs list would be here... ], callbacks: { before_play: function() { document.querySelector('.msg').innerHTML = 'Song will now begin...'; }, after_stop: function() { document.querySelector('.msg').innerHTML = 'Song has ended!'; } }
});

You can see this in action in this CodePen. I’ve incorporated a rudimentary play/pause button to help with the callbacks. To see the final callback, you have to wait for the song to complete (pausing doesn’t trigger the after_stop callback). The button is built using nothing but a few HTML attributes, no extra scripting needed.

This is a really small sampling of what’s possible with this player and how flexible it is. The docs are solid and should get you up and running with this tool in no time.

Honorable Mentions

That’s a detailed look at five of my favorites from the past year. But there are lots of others worth examining that are similarly lesser-known. I’ve listed some of these below:

  • BunnyJS –An ES6-based front-end framework that advertises as “Simple like jQuery, better then jQuery UI, powerful like React”.
  • keyframes-tool –A command line tool to convert CSS animations to a keyframes object suitable for use with the Web Animations API.
  • Konsul – A React renderer that renders to the browser’s developer tools console.
  • across-tabs – Easy communication between cross-origin browser tabs.
  • svgi – A CLI tool to inspect the content of SVG files, providing information on the SVG (number of nodes, paths, containers, shapes, tree hierarchy, etc).
  • CSS in JS Playground – Play around with the code for just about any of the CSS-in-JavaScript solutions (JSS, styled-components, glamorous, etc).

What’s Your Favorite Find of the Year?

So that’s it. As I said at the start, this was not meant to be an awards ceremony for best tools of the year, but more of a look at some not-so-mainstream alternatives that are interesting and practical. I hope you find some of them useful. If you’re interested in continuing to keep up with the influx of new tools in front-end development, be sure to subscribe to my newsletter.

Have you stumbled upon (or built) something cool over the past year that would be of interest to front-end developers? Let me know in the comments, I’d love to take a look.


Front-End Tools: My Favorite Finds of 2017 is a post from CSS-Tricks