Subscribe to CSS-Tricks feed
Tips, Tricks, and Techniques on using Cascading Style Sheets.
Updated: 8 hours 59 min ago

Deploying ES2015+ Code in Production Today

Tue, 09/19/2017 - 19:13

Philip Walton suggests making two copies of your production JavaScript. Easy enough to do with a Babel-based build process.

<!-- Browsers with ES module support load this file. --> <script type="module" src="main.js"></script> <!-- Older browsers load this file (and module-supporting --> <!-- browsers know *not* to load this file). --> <script nomodule src="main-legacy.js"></script>

He put together a demo project for it all and you're looking at 50% file size savings. I would think there would be other speed improvements as well, by using modern JavaScript methods directly.

Direct Link to ArticlePermalink

Deploying ES2015+ Code in Production Today is a post from CSS-Tricks

The Key to Building Large JavaScript Apps: The Modlet Workflow

Tue, 09/19/2017 - 14:20

You're a developer working on a "large JavaScript application" and you've noticed some issues on your project. New team members struggle to find where everything is located. Debugging issues is difficult when you have to load the entire app to test one component. There aren't clean API boundaries between your components, so their implementation details bleed one into the next. Updating your dependencies seems like a scary task, so your app doesn't take advantage of the latest upgrades available to you.

One of the key realizations we made at Bitovi was that "the secret to building large apps is to never build large apps." When you break your app into smaller components, you can more easily test them and assemble them into your larger app. We follow what we call the "modlet" workflow, which promotes building each of your components as their own mini apps, with their own demos, documentation, and tests.

Article Series:
  1. The Key to Building Large JavaScript Apps: The Modlet Workflow (You are here!)
  2. Improve Your Development Workflow with StealJS (Coming soon!)

Following this pattern will:

  • Ease the on-boarding process for new developers
  • Help keep your components' docs and tests updated
  • Improve your debugging and testing workflow
  • Enforce good API design and separation of concerns
  • Make upgrades and migrations easier

Let's talk about each of these benefits one by one to see how the modlet workflow can help your development team be more effective.

Ease the onboarding process for new developers

When a new developer starts on your project, they might be intimidated by the amount of files in your app's repository. If the files are organized by type (e.g. a CSS folder, a JS folder, etc.), then they're going to be searching across multiple folders to find all the files related to a single component.

The first step to following the modlet workflow is to create folders for each of your components. Each folder, or modlet, should contain all of the files for that component so anyone on your team can find the files they need to understand and develop the component, without having to search the entire project.

Additionally, we build modlets as their own mini apps by including at least the following files in their folders:

  • The main source files (JavaScript, stylesheets, templates, etc.)
  • A test JavaScript file
  • A markdown or text file for docs (if they're not inline with your code)
  • A test HTML page
  • A demo HTML page

Those last two files are crucial to following the modlet workflow. First, the test HTML page is for loading just the component's tests in your browser; second, the demo HTML page lets you see just that component in your browser without loading the entire app.

Improve your debugging and testing workflow

Creating demo and test HTML pages for each component might seem like overkill, but they will bring some great improvements to your development workflow.

The demo HTML page:

  • Lets you quickly see just that component without loading the entire app
  • Gives you a starting place for reproducing bugs (and reduces the surface area)
  • Offers you an opportunity to demo the component in multiple scenarios

That last item can be leveraged in a couple ways. I've worked on projects where we've:

  • Had multiple instances of the same component on a single page so we could see how it behaved in a few key scenarios
  • Made the demo page dynamic so we could play with dozens of variables to test a component

Last but not least, debugging issues will be easier because the component is isolated from the rest of the app. If you can reproduce the issue on the component's demo page, you can focus your attention and not have to consider unrelated parts of your app.

The test HTML page gives you similar benefits to the demo HTML page. When you can run just a single component's tests, you:

  • Don't need to litter your test code with .only statements that will inevitably be forgotten and missed during code review
  • Can make changes to the component and focus on just that component's tests before running the app's entire test suite
Enforce good API design and separation of concerns

The modlet workflow also promotes good API design. By using each component in at least two places (in your app and on the demo page), you will:

  1. Consider exactly what's required by your component's API
  2. Set clear boundaries between your components and the rest of your app

If your component's API is intuitive and frictionless, it'll be painless to create a demo page for your component. If too much "bootstrapping" is required to use the component, or there isn't a clean separation between the component and how it's used, then you might reconsider how it's architected.

With your component's API clearly defined, you set yourself up for being able to take your component out of its original repository and make it available in other applications. If you work in a large company, a shared component library is really helpful for being able to quickly develop projects. The modlet workflow encourages you to do that because each of your components already has its own demos, docs, and tests!

Help keep your components' docs and tests updated

A common issue I've seen on projects that don't follow the modlet workflow is that docs and tests don't get updated when the main source files change. When a team follows the modlet workflow, everyone knows where to look for each component's docs and tests: they're in the same folder as the component's source code!

This makes it easier to identify missing docs and tests. Additionally, the files being in the same folder serve as a reminder to every developer on the team to update them when making changes to that component.

This is also helpful during code review. Most tools list files by their name, so when you're reviewing changes for a component, you're reminded to make sure the docs and tests were updated too. Additionally, flipping between the implementation and tests is way easier because they'll be close to each other.

Make upgrades and migrations easier

Last but not least, following the modlet workflow can help you upgrade your app to new versions of your dependencies. Let's consider an example!

A new major version of your JavaScript framework of choice is released and you're tasked with migrating your app to the new version. If you're following the modlet workflow, you can start your migration by updating the components that aren't used by any of your other components:

The individual demo and test pages are crucial to making this upgrade. You can start by making the tests pass for your component, then double check it visually with your demo page.

Once those components work, you can start upgrading the components that depend on those:

You can follow this process until you get all of your app's components working. Then, all that's left is to test the actual app, which will be far less daunting because you know the individual components are working.

Large-scale migrations are easier when components are contained and well defined. As we discussed in an earlier section, the modlet workflow encourages clear API boundaries and separation of concerns, which makes it easier to test your components in isolation, making an entire app upgrade less intimidating.

Start using the modlet workflow in your app today

You can get started with the modlet workflow today—first, if your team is still organizing files by type, start grouping them by component instead. Move the test files to your component folders and add some HTML pages for demoing and testing your component. It might take your team a little bit of effort to transition, but it'll be worth it in the long run.

Some of the suggestions in this article might seem intimidating because of limitations in your tooling. For example, if you use a module loader & bundler that requires you to create a separate bundle for each individual page, adding two HTML pages per component would require an intimidating amount of build configuration.

In the next article in this series, we'll discuss how you can use a module loader and bundler called StealJS to load the dependencies for each of your components without a separate build for each HTML page.

Let me know what you think in the comments! If you follow a similar organization technique, then let me know what's worked well and what hasn't worked for you.

Article Series:
  1. The Key to Building Large JavaScript Apps: The Modlet Workflow (You are here!)
  2. Improve Your Development Workflow with StealJS (Coming soon!)

The Key to Building Large JavaScript Apps: The Modlet Workflow is a post from CSS-Tricks

Chrome to force .dev domains to HTTPS via preloaded HSTS

Tue, 09/19/2017 - 14:15

Mattias Geniar:

A lot of (web) developers use a local .dev TLD for their own development. ... In those cases, if you browse to http://site.dev, you'll be redirect[ed] to https://site.dev, the HTTPS variant.

That means your local development machine needs to;

  • Be able to serve HTTPs
  • Have self-signed certificates in place to handle that
  • Have that self-signed certificate added to your local trust store (you can't dismiss self-signed certificates with HSTS, they need to be 'trusted' by your computer)

This is probably generally A Good Thing™, but it is a little obnoxious to be forced into it on Chrome. They knew exactly what they were doing when they snatched up the .dev TLD. Isn't HSTS based on the entire domain though, not just the TLD?

Direct Link to ArticlePermalink

Chrome to force .dev domains to HTTPS via preloaded HSTS is a post from CSS-Tricks

React + Dataviz

Mon, 09/18/2017 - 16:20

There is a natural connection between Data Visualization (dataviz) and SVG. SVG is a graphics format based on geometry and geometry is exactly what is needed to visually display data in compelling and accurate ways.

SVG has got the "visualization" part, but SVG is more declarative than programmatic. To write code that digests data and turns it into SVG visualizations, that's well suited for JavaScript. Typically, that means D3.js ("Data-Driven Documents"), which is great at pairing data and SVG.

You know what else is good at dealing with data? React.

The data that powers dataviz is commonly JSON, and "state" in React is JSON. Feed that JSON data to React component as state, and it will have access to all of it as it renders, and notably, will re-render when that state changes.

React + D3 + SVG = Pretty good for dataviz

I think that idea has been in the water the last few years. Fraser Xu was talking about it a few years ago:

I like using React because everything I use is a component, that can be any component writen by myself in the project or 3rd party by awesome people on NPM. When we want to use it, just import or require it, and then pass in the data, and we get the visualization result.

That components thing is a big deal. I've recently come across some really good libraries smooshing React + D3 together, in the form of components. So instead of you leveraging these libraries, but essentially still hand-rolling the actual dataviz components together, they provide a bunch of components that are ready to be fed data and rendered.


nivo provides a rich set of dataviz components, built on top of the awesome d3 and Reactjs libraries.


Victory is a set of modular charting components for React and React Native. Victory makes it easy to get started without sacrificing flexibility. Create one of a kind data visualizations with fully customizable styles and behaviors. Victory uses the same API for web and React Native applications for easy cross-platform charting.


[react-vis is] a composable charting library


A composable charting library built on React components

React D3

A Javascript Library For Building Composable And Declarative Charts. A new solution for building reusable components for interactive charts.

React + Dataviz is a post from CSS-Tricks

A Rube Goldberg Machine

Mon, 09/18/2017 - 15:39

Ada Rose Edwards takes a look at some of the newer browser APIs and how they fit together:

These new APIs are powerful individually but also they complement each other beautifully, CSS custom properties being the common thread which goes through them all as it is a low level change to CSS.

The post itself is a showcase to them.

Speaking of new browser APIs, that was a whole subject on ShopTalk a few weeks back.

Direct Link to ArticlePermalink

A Rube Goldberg Machine is a post from CSS-Tricks

Basic grid layout with fallbacks using feature queries

Mon, 09/18/2017 - 13:53

I often see a lot of questions from folks asking about fallbacks in CSS Grid and how we can design for browsers that just don’t support these new-fangled techniques yet. But from now on I'll be sending them this post by HJ Chen. It digs into how we can use @supports and how we ought to ensure that our layouts don't break in any browser.

Basic grid layout with fallbacks using feature queries is a post from CSS-Tricks

“The Notch” and CSS

Sat, 09/16/2017 - 19:54

Apple's iPhone X has a screen that covers the entire face of the phone, save for a "notch" to make space for a camera and other various components. The result is some awkward situations for screen design, like constraining websites to a "safe area" and having white bars on the edges. It's not much of a trick to remove it though, a background-color on the body will do. Or, expand the website the whole area (notch be damned), you can add viewport-fit=cover to your meta viewport tag.

<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">

Then it's on you to account for any overlapping that normally would have been handled by the safe area. There is some new CSS that helps you accommodate for that. Stephen Radford documents:

In order to handle any adjustment that may be required iOS 11's version of Safari includes some constants that can be used when viewport-fit=cover is being used.

  • safe-area-inset-top
  • safe-area-inset-right
  • safe-area-inset-left
  • safe-area-inset-bottom

This can be added to margin, padding, or absolute position values such a top or left.

I added the following to the main container on the website.

padding: constant(safe-area-inset-top) constant(safe-area-inset-right) constant(safe-area-inset-bottom) constant(safe-area-inset-left);

There is another awkward situation with the notch, the safe area, and fixed positioning. Darryl Pogue reports:

Where iOS 11 differs from earlier versions is that the webview content now respects the safe areas. This means that if you have a header bar that is a fixed position element with top: 0, it will initially render 20px below the top of the screen: aligned to the bottom of the status bar. As you scroll down, it will move up behind the status bar. As you scroll up, it will again fall down below the status bar (leaving an awkward gap where content shows through in the 20px gap).

You can see just how bad it is in this video clip:

Fortunately also an easy fix, as the viewport-fit=cover addition to the meta viewport tag fixes it.

If you're going to cover that viewport, it's likely you'll have to get a little clever to avoid hidden content!

I think I’ve fixed the notch issue in landscape &#x1f37e; #iphoneX pic.twitter.com/hGytyO3DRV

— Vojta Stavik (@vojtastavik) September 13, 2017

“The Notch” and CSS is a post from CSS-Tricks

Design Tooling is Still Figuring Itself Out

Thu, 09/14/2017 - 23:20

It probably always will be, to be fair.

At the moment, there are all kinds of things that design software is struggling to address. The term "screen design" is common, referring to the fact that many of us are designing very specifically for screens, not print or any other application and screens have challenges unique to them. We have different workflows these days than in the past. We have different collaboration needs. We have different technological and economic needs.

Let's take a peak at all this weirdness.

Design tooling is still figuring out Responsive Design

It's almost taken for granted these days that any given new web project (or redesign) will be responsive design. Responsive design is the answer for screens of different sizes and different capabilities. So we can't just design a 1280px wide version and call it a day.

Software like Sketch has made multiple artboards of arbitrary sizes a first class citizen to help with this.

This doesn't completely solve the idea that we're designing for screens that can be of wildly different sizes, dimensions, and densities, but it certainly helps communicate a lot more than just one size does.

But how do you create all the different artboards you want to create? Copy and paste, resize stuff, and drag stuff around? You could, but design tooling is starting to figure itself out here a little. Here's a Sketch plugin called Constraints that is trying to make this easier:

Figma has this idea of constraints built right in:

Webflow is a unique design tool in that you aren't quite dragging things around as totally arbitrarily as you would in something like Sketch or Illustrator. Instead, you're manipulating things that are actually 1-to-1 representations of real web layout properties like margin, padding, and even things like flexbox and grid. They've made working with the Webflow editor naturally responsive, and you can see it immediately as you work.

Design tooling is still figuring out Collaboration

Imagine you do your designing with Photoshop. You have `.psd` files that are your designs. How do you deliver them? Email? Maybe, but that's a little messy for teams. Perhaps you have a shared Dropbox folder?

Adobe knows design teams need this. They have "Creative Cloud", which does everything from managing the actual software you have access to, to getting you access to design assets like fonts and stock photography, to helping you share files:

Sure, but that doesn't do anything besides giving everyone access to those files. There is even merge conflict danger, if multiple people are working on the same file.

The files themselves are only part of the story of collaboration. What about version history? What about notes and feedback? What about approval?

Invision is a big player in design tooling, and I would guess mostly because of the collaborative features. You don't create your designs in InVision, for the most part, you just upload them there and then do more with them, like talk about them:

Talking about designs overtop the designs themselves in Invision.

What if there wasn't really "files" at all to deal with? When your design software is a web app, the design documents aren't really documents you need to deal with yourself, they just kinda exist within the app. Figma is like this:

Plus, Figma offers teams, meaning collaboration amongst a team is just a matter of logging in and having shared access to everything.

Taking collaboration even further, Figma has realtime designing features. As in, Google-docs (or CodePen Collab Mode) style editing-at-the-same-time action:

Image from here.

As a testament to design tooling still figuring itself out, I don't think Figma pushes this feature very heavily anymore, marketing-wise. I think they have found that despite it being a showy feature, actual design teams don't really like it. Who knew.

This is an interesting read by Meng To comparing Figma and Sketch.

Design tooling is still figuring out Assets and Versions

Design can be more than screen mockups. A design team might need access to an icon set, a branding system, a color palette, a set of flat graphics...

Take a look at Lingo, which is an app explicitly for this. Collaboration is a key feature, but its team collaboration is based on assets.

I can imagine a tool like that not only making the sharing of assets easier but keeping the version of assets everyone is using up to date. As in, preventing people from keeping a "folder full of icons" on their local machine and having it go stale.

And speaking of versions... I'm sure we've all experienced (and heard the jokes) about files named things like:


Developers don't really have this problem thanks to version control. Where is version control for designers? Apps like Abstract are trying to help with that.

Abstract doesn't only help with collaboration, but version management as well.

Everything is saved. Nothing is lost. Version control you can trust.

Design tooling is still figuring out Design Systems

As I recently said:

We're not building pages, we're building systems. Style guides. Design systems. Pattern libraries. These things are becoming a standard part of the process for web projects. They will probably become the main deliverable.

We've seen design software slowly start to accommodate this kind of thinking over the years. Even things as simple as type styles took their sweet time making their way from places like InDesign (where they couldn't be lived without) over to Illustrator and Photoshop. They are so clearly needed that newer design tools always seem to have them.

Yet, if type is specifically what you are doing, there are tooling options specifically for that. Tools like Typecast are for that:

Or TypeNugget, which we've covered here:

One web app design tool, UX Pin, is focusing heavily on being a design tool for design systems.

We've covered that before, and you can see more about what they mean here:

Design tooling is still figuring out Interactivity

As much advancement as we're seeing with design tooling, we're also seeing that it's very hard for single tools to do it all. Interaction design is a great example of this.

Hover states! Swiping and gestures! Page transitions! Animations! Tap feedback!

As good as Sketch is at certain things, there is next to nothing there for handling interactivity. One one hand, it's a shame. Screen design is loaded with interactivity. It's definitely on designers minds and a must for their job. On the other hand, I might worry about bloat and lack of focus if all design tools tried to pack in interactivity tools.

Check out Framer, who are tackling interaction design head-on:

Framer is a visual design tool, with all the familiar styling tools (including some interesting constraint-based responsive stuff), but approach the interactive stuff literally through coding within the tool:

Design tooling is still figuring out Platforms

I feel just a smidge guilty every time I talk about Sketch, because I know it's macOS only. That excludes a huge chunk of people who work on websites. They don't even plan on it. Familiar players like Adobe generally make their products cross-platform, but even that is limited compared to the web-based tools, which work on any platform. I'd say web based tools like Figma and UX Pin have a strong advantage with the inherent collaboration and sharing abilities along with the cross-platform ability.

But desktop machines, regardless of platform, aren't the only story here. Certainly Apple had designers in mind with the iPad Pro:

What kind of design software is available on that? Affinity Designer seems to be working on it:

It's quiet in the office today and I'm feeling mischievous... Who fancies a bit of #affinitydesigner #ipad #shakycam teaser? &#x1f431; pic.twitter.com/ZfbSIJY5Vn

— Matt Priestley (@mattp4478) July 12, 2017

And tools like Graphic:

Design tooling is still figuring out Trends

You can fill a box with noise in Sketch:

I'm not entirely sure why, but I imagine it might influence designers to use noise in a design. There is no one-click option to fill an area with tiny beetles, but I imagine if there was we'd see more divs filled with tiny beetles.

Adobe Experience Design has a "background blur" feature, no doubt inspired by recent Apple designs.

Heck, I can distort and object by "Polar Coordinates" in Photoshop.

Design tools influence design, and design influences design tooling. Whatever the default opacity settings are will influence design. Whatever the default gradient colors are. Whatever the default easing values are.

Design tooling is still figuring out Data

I imagine you've heard some full throated arguments both for and against lorem ipsum text. "It doesn't reflect real design!", you might hear. Whatever you think, it sure is interesting to see design tooling try to take on designing with real data.

Adobe Experience Design has some interesting features along these lines. Take their Repeat Grid tool, which is an interesting prototyping tool in it's own right, and can also help fill in real text and images:

Webflow helps with designing with data quite a bit too. They've said:

Designing with real data gives us a deeper understanding of how a page will function. In part because it surfaces all the “problems” designers strive to avoid in their mockups, such as long headlines, low-quality images, etc.

Designing with real content gives both writers and designers better insight into what they need to do.

They have an in-built CMS to store structured data, then design tools to help get that data onto designs:

Design tooling is still figuring out Pricing Models

I bet many of you remember when Adobe software was an (expensive) one-off cost. Now the transformation is complete and we're looking at anywhere from 10 to 50 dollars monthly to use the software, which I suppose makes it more accessible to some and less accessible to some.

Web apps are almost always a monthly cost. Figma is $12/month/user for teams. Business wise, for the creators of software, that seems to be the smart move. My own experience echoes that. But I can see how that can be a turn off for a native software product. Sketch is a flat $99, which I admit feels nice.

This will never shake out, surely, and it's not just one-off cost vs. monthly. There are free trials, freemium models, in-app purchases, and add-on models that all could and are being experimented with across the tooling landscape.

Wrapping Up

There is so much more to this, and I'm hardly the person to cover it.

For instance, I didn't talk too much about designing in the browser, but there is certainly tooling there. Aside from those few typography-focused apps, we didn't focus on the proliferation of tiny single-feature apps out there. Coolors is an example of that that I quite like. Not to mention the loads of design resource sites. We also didn't talk about wild crossover projects like React-Sketchapp.

Let's end with an interesting related article. Colm Tuite recently wrote "Design tools are running out of track. Here’s how we can fix them." Here's one of his points that I think is salient:

Why can’t designers just design the actual product?! Ultimately, all mockups are disposable, yet designers spend months tweaking them to perfection. That time would be much better spent tweaking the actual product.

Design Tooling is Still Figuring Itself Out is a post from CSS-Tricks

​Deliver exceptional customer experiences in your product

Thu, 09/14/2017 - 16:12

(This is a sponsored post.)

Pendo delivers the only complete platform for Product Teams that helps companies create great products. The Pendo Product Experience Platform enables Product Teams to understand product usage, collect user feedback, measure NPS, assist users in their apps and promote new features in product - all without requiring any engineering resources. This unique combination of capabilities is all built on a common infrastructure of product data and results in improved customer satisfaction, reduced churn, and increased revenue.

Pendo is the proven choice of innovative product leaders at Salesforce, Proofpoint, Optimizely, Citrix, BMC and many more leading companies.

Request a demo of Pendo today.

Direct Link to ArticlePermalink

​Deliver exceptional customer experiences in your product is a post from CSS-Tricks

Is there any value in people who cannot write JavaScript?

Thu, 09/14/2017 - 16:07

Mandy Michael:

If all you do in your job is write JS, that is fantastic and you are awesome, just like all the people that write CSS or have a focus in a particular area like accessibility, SVG, animation etc.

What I am very concerned about is that many still don’t see value in being skilled in CSS & HTML. This attitude is something I just don’t understand. All of us working together provide value in our industry.

+1 on all Mandy's points.

I suspect HTML and CSS skill will swing back higher in desirability a bit as design trends swing toward more complicated looks. More interesting layouts being one of those things. I tend to find those developers who only dabble in HTML/CSS fall over quickly when it comes to from-scratch work that involves layout. There is a lot of gray area here too. For example, I write Ruby code, but I fall over quickly when it comes to even moderately complex things.

I also suspect this conversation is rooted in the fact that HTML, CSS, and JavaScript are so intertwined, it tickles some people the wrong way to see other people stop at the first two.

Direct Link to ArticlePermalink

Is there any value in people who cannot write JavaScript? is a post from CSS-Tricks

Design Resource Sites

Wed, 09/13/2017 - 16:34

Sometimes when you're designing something, you need little helping hands. Perhaps a nice stock photo. Perhaps a happy little color palette. Perhaps a bleep or bloop sound. Perhaps the perfect icon.

There are tons and tons of sites that do those things. There are fewer sites that curate these design resource sites into manageable, high-quality groups. So allow me to abstract that yet another step and provide a selected list of those types of sites.

The Stocks

This is the one I was trying to remember the other day that spurred the idea for this little post. I quite like how you can just hang out on this site and click around to what you need by the type of resource, and the resource sites themselves just come up iframed.

Sans Francisco

Sans Francisco is a colorful and organize list of design resources by Robinson Greig.

Design Resources (.party!)

The winner of the best-named and best-TLD goes to Jessica Paoli. Similar to Sans Francisco, it's a big long curated one-pager full or resources organized by type.


More of what we're looking for!

A hand-picked directory of the best free resources for creatives.


I suspect this is the one that inspired The Stocks, as it also does the iframe thing. You click the site you want along the persistent left sidebar, and it loads the resource site on the right.

Design Resource Sites is a post from CSS-Tricks

Do you put anything in your code specifically for “Find in Project”?

Tue, 09/12/2017 - 14:07

During a having a team meeting the other day, a code formatting idea came up that I thought was super interesting. It had to do with formatting code in a such a way that made it easier to find what you were looking for later with any code editors "Find in Project" feature.

Here's what it was.

When declaring a function in JavaScript, put a space after the function name and before the opening parenthesis, like...

function doSomething () { }

That space between doSomething and () is perfectly fine. Then when you call the function, don't use a space, like this:


It's just a syntax convention.

But now, "Find in Project" is more useful. If we want to quickly find where that function was defined, we can search for "doSomething ()", and if we want to find instances of where it is used, we can look for "doSomething()".

You could extend the idea to classes or whatever too:

class myThing () { constructor () { } doThing () { } } let example = new myThing(); example.doThing();

I'd say that's worth doing.

It reminds me of when I need to where a Ruby method is definied, I can always search for "def foo" since that "def " is required for creating the method.

I can imagine a scenario where it might be useful to define base classes in CSS like .module { but then if it's a variation or nested or used again for any other reason... .module{.

Here's a classic:

// TODO: &#x1f605;

— Charlotte Dann (@charlotte_dann) September 10, 2017

Leaving TODO comments throughout your code base turns a "Find in Project" for "TODO" an instant list of things you need to work on. Surely that could be even more nuanced, incorporating things like priority levels and assignments. Perhaps even emoji's to help like Charlotte suggested!

Here's an interesting one:

Use long classes/variables, mark future refactor points with comments. What are you looking for?

— Chris Pauley (@ChrisPauley) September 10, 2017

I like the idea of "long names". I suppose the longer and more descriptively you name things, the easier they are to search for and get specific results (avoiding repetitive matches like you would with very simple names).

Comments are a great place to leave things to search for. I often use a convention where I put my own name in the comment if I want people to know it was me leaving the comment, but it's not necessarily for me.

.thing { overflow: hidden; /* [Chris]: ugkghk this fixed a layout thing but I didn't have time to figure out exactly why. */ }

A smattering of responses:

At top of each template I add "<!-- Start [name of template] -->", at bottom, same but "End." Helps FIP and in browser-rendered code.

— Dale Henry Geist (@dalehenrygeist) September 10, 2017

I use consistent and natural language to name things, so when documentation goes stale, at least the code itself is still easy to stab at.

— John James Jacoby (@JJJ) September 10, 2017

Not in the code itself but in Sublime settings folder_exclude_patterns you can pass in an array of folders to exclude from all searches

— Ian C Woodward (@IanCWoodward) September 10, 2017

// TODO &#x1f615;
// FIXME &#x1f632;
// WT* &#x1f624;&#x1f4a3;

— Kamran Ahmed (@kamranahmedse) September 10, 2017

ctags is a lifesaver.

— Harry Roberts (@csswizardry) September 10, 2017

Naming conventions mate! BEM-esque those classes up `--thing` is always easier to find than `thing`

— James Bosworth (@fltwhte) September 11, 2017

Do you put anything in your code specifically for “Find in Project”? is a post from CSS-Tricks

HTML Templates via JavaScript Template Literals

Mon, 09/11/2017 - 14:43

You know those super cool backticks-for-strings in new JavaScript?

let emotion = `happy`; let sentence = `Chris is feeling ${emotion}`;

Besides the variable interpolation in there being mighty handy, the do multi-line strings wonderfully, making them great for chunks of HTML:

const some_html = ` <div class="module> <h2>${data.title}</h2> <p>${data.content}</p> </div> `;

That doesn't look overly different than JSX does it?! Maybe we'd do something like that as a React component:

class MyModule extends React.Component { render() { return <div class="module"> <h2>{this.props.title}</h2> <p>{this.props.content}</p> </div>; } }

But what if we don't really need React, or any other fairly-large-ish JavaScript framework?

What if the only thing we want is the ability to render HTML templates and also really efficiently re-render them when we need to, like React is known for?

As far as I understand it, that's what projects like lit-html are for. As I write, it's a pretty new library from Google and the Polymer folks.

It allows you to define an HTML template with regular template literals, like this:

import { html, render } from './lit-html.js'; const helloTemplate = (data) => html` <div class="module"> <h2>Hello ${data.name}!</h2> <p>${data.content}</p> </div> `;

Then you call the render function, passing it that template, the data, and where you want it rendered:

let data = { name: "Chris", content: "Just trying to figure stuff out." } render(helloTemplate(data), document.body);

Then say the data changes... you call render again:

data.name = "Sammy"; render(helloTemplate(data), document.body);

And this is where lit-html shines. It's smart enough to only update the parts of the DOM it needs to.

Here's a little comparison where some data is changed, then the templates re-rendered. If we innerHTML the whole thing, well, the entire DOM is changed. With lit-html it just changes smaller inner parts.

Here's a little video where you can see the DOM-updating difference:

lit-html on the left, "regular" on the right. Demo project.

There is another project along these lines too. I don't know quite enough to judge, but it's a bit older and I believe it's a bit more robust. It's called HyperHTML.

HyperHTML also allows you to create templates and render them. And most importantly rerender them efficiently.

Here's a demo where the data comes from the Quotes on Design API and inserted into a template:

See the Pen Trying HyperHTML by Chris Coyier (@chriscoyier) on CodePen.

Kinda cool that these mini-libraries exist that do useful things for us, so when situations arise that we want a feature that a big library has, but don't want to use the whole big library, we got smaller options.

HTML Templates via JavaScript Template Literals is a post from CSS-Tricks


Sun, 09/10/2017 - 20:34

This little website pulls in all the main stories from CNN and strips almost everything from the design; styles, images, fonts, ads, colors. Nada, zilch, gone. At first it looks like nothing but hypertext and it feels like an extraordinary improvement but Sam Saccone made a thread about potential improvements that the team could use to make that experience even faster such as server side rendering and replacing the React framework with something smaller, like Preact.

Either way this approach to news design is refreshing. However, I can’t find anything more about the the motivations for building this version of CNN.com besides the announcement on Twitter. It would certainly be fascinating to learn if CNN built this specifically for people caught in disastrous situations where battery life and load time might be a serious matter of life and death.

Direct Link to ArticlePermalink

lite.cnn.io is a post from CSS-Tricks

Compilers are the New Frameworks

Sat, 09/09/2017 - 21:33

Tom Dale:

Increasingly, the bytes that get shipped to browsers will bear less and less resemblance to the source code that web developers write.

Indeed. I suspected the same:

Because performance matters so much and there is so much opportunity to get clever with performance, we'll see innovation in getting our code bases to production. Tools like webpack (tree shaking, code splitting) are already doing a lot here, but there is plenty of room to let automated tools work magic on how our code ultimately gets shipped to browsers.

Tom also says:

This is a loss in some ways (who else got their web development start with View Source?) but is a huge win for users, particularly in emerging markets.

It seems to me today's world of GitHub, StackOverflow, and the proliferation of learning resources more than make up for learning via our own website spelunking, not to mention how insightful today's DevTools are, even if what they are looking at isn't hand-authored.

Direct Link to ArticlePermalink

Compilers are the New Frameworks is a post from CSS-Tricks

6 Months of Working Remotely Taught Me a Thing or Ten

Fri, 09/08/2017 - 23:08

Peter Anglea writes up his key takeaways after six months on the job with a new front-end position. His points ring true to me as a remote worker and the funny thing is that each one of the suggestions is actually applicable to anyone in almost any front-end job, whether it happens to be in-house or remote.

The full post is worth reading, though the list breaks down to:

  1. Be as available as possible
  2. Communicate clearly
  3. Go out of your way to be human
  4. Offer praise and positive sentiments early and often
  5. Create a comfortable space conducive to productivity
  6. Put your pants on
  7. Go outside
  8. Turn on your camera
  9. Work on more than one project at a time
  10. Take advantage of the perks… and be responsible

One item I would add to the list is to manage up in day-to-day conversations. In other words, give frequent and regular updates with examples of progress so that your client/boss/whomever has no doubt that you are being productive from afar. I suppose that goes along with "communicate clearly" but takes it one step further.

Direct Link to ArticlePermalink

6 Months of Working Remotely Taught Me a Thing or Ten is a post from CSS-Tricks

The average web page is 3MB. How much should we care?

Fri, 09/08/2017 - 23:07

Tammy Everts with a deep dive into the average page size, which seems to grow year in and year out.

It's a little perplexing that the average page size trends up each year as performance has become a growing concern on the forefront of our minds, but Tammy has keen insights that are worth reading because she suggests that user experience isn't always about page size and that bloat is far from the only metric we should be concerned.

Correlating page size with user experience is like presenting someone with an entire buffet dinner and assuming that it represents what they actually ate. To properly measure user experience, we need to focus on the content – such as the navbar or hero product image – that users actually want to consume. The best performance metric for measuring user experience is one that measures how long the user waits before seeing this critical content.

Spot on. There is such a thing as making intentional use of file size, depending on whether or goal is super fast load times or communicating an idea. Not that the two are mutually exclusive, but the trade-off can certainly exist.

Direct Link to ArticlePermalink

The average web page is 3MB. How much should we care? is a post from CSS-Tricks

Screen Readers and CSS: Are We Going Out of Style (and into Content)?

Fri, 09/08/2017 - 00:06

The big takeaway in this post is that screen readers do not always read content the way it is styled in CSS. Toss in the fact that not all screen readers speak or read markup the same way and that there are differences in how they render content in different browsers and the results become...well different. Kind of like cross-browser testing CSS, but with speech.

The key points:

  • Different screen reader/browser pairings behave differently
  • DOM order is everything
  • Containers are only visual

That first point is crucial. For example, beware of using <sup> to style prices in place of using a proper decimal point between dollars and cents because some screen readers will read that as a whole number. Wait, you mean, the price is $12.99 and not $1,299? Phew. &#x1f605;

Direct Link to ArticlePermalink

Screen Readers and CSS: Are We Going Out of Style (and into Content)? is a post from CSS-Tricks

Upgrade Your JavaScript Error Monitoring

Thu, 09/07/2017 - 13:39

(This is a sponsored post.)

Automatically detect and diagnose JavaScript errors impacting your users with Bugsnag. Get comprehensive diagnostic reports, know immediately which errors are worth fixing, and debug in a fraction of the time compared to traditional tools.

Bugsnag detects every single error and prioritizes errors with the greatest impact on your users. Get support for 50+ platforms and integrate with the development and productivity tools your team already uses.

Bugsnag is used by the world's top engineering teams including Airbnb, Pandora, MailChimp, Square, Shopify, Yelp, Lyft, Docker, and Cisco. Start your free trial today.

Direct Link to ArticlePermalink

Upgrade Your JavaScript Error Monitoring is a post from CSS-Tricks

So You Want To Be a Senior Developer?

Thu, 09/07/2017 - 13:39

Let me start with a classic caveat: I cannot bestow upon you the title of senior developer. I have no special insight into how companies these days are hiring and promoting people to senior developer roles.

What I can tell you is what qualities I think would make for a heck of a senior developer. I can tell you how I think about the distinction between senior developers and those who aren't quite there yet. Should I, one day, be in charge of a legion of developers where it was my call what level they were at, this is what I would think about.

A senior front end developer has experience.

There is no way around this one. You aren't going to roll into your first job a senior developer.

You probably won't roll into any new job a senior developer. Even if I was pretty sure a person was going to be a senior developer and previously has been, I'd probably wouldn't start them there, just because there is no guarantee they can be just as effective in a completely new environment. Even if the tech is the same, the people aren't.

A senior front-end developer has a track record of good judgment.

Development isn't only about writing code, it's about making choices. Good choices are researched, discussed, and influenced by instinct and experience. When you make a choice, you are demonstrating your judgement to everyone watching. If you make it clear that your judgement is informed, ethical, and as transparent as it can be, that's a good thing. If you do that over and over, that makes you senior.

A senior developer has positive impact beyond the code.

If the only thing you contribute to a team is coding chops, you probably aren't a particularly good candidate for a senior developer. Code isn't written in a bubble. Good code, anyway. Good code is a reflection of a team, a product of a cohesive vision, and a foundation for an organizations goals. To participiate in good code, and demonstrate your ability to be a senior developer, you don't isolate yourself, you sit at the middle of the table (metaphorically).

Soft skills are no joke. A senior developer can write clear emails, rope people in around ideas, lead meetings, and just clean the damn soup exlosion in the microwave before it turns into a productivity-draining war of passive agressive post it notes (metaphorically).

A senior developer is helpful, not all-knowing.

Say a co-worker comes up to you and asks you something, and you have no idea what the answer is. Does that mean you aren't ready to be a senior developer? Absolutely not. It's all about how you answer that question that makes you senior or not. Can you help suss out why they are asking to get more context and be more broadly helpful? Can you offer to help find the answer together? Will you do some research afterward and follow up with them?

Even if you do know the exact answer, just delivering it and spinning your chair back around to continue typing is a worse answer than digging into the question together with your co-worker.

Being a senior developer doesn't mean you have to know everything, it means you can help find out anything.

A senior front-end developer is a force multiplier.

This is my favorite one by far.

There are developers who are, on paper at least, multiple times as effective as others. Twice the commits, twice the lines of code written, twice the bugs closed. You can absolutely aspire to be a developer like that, but it doesn't automatically give you the senior card.

The best (and most senior) developer on a team is the one who multiplies the effectiveness of their fellow developers. Perhaps that amazing developer on your team is able to be that way because someone else is freeing up their day to make that possible. Because someone else has created a rock solid dev enviornment that fosters productivity. Because someone else taught them and gave them the keys to be that way.

A developer who is a force multiplier for the entire team is absolutely a senior developer.

I can't promise that doing these things will make you a senior developer.

I have no power to tell the chain of command at your office to think about these things and factor them in to their decision making. I can say that this would be my advice to them, should they be seeking it, on how to promote developers.

Are you in the position to promote developers? Have you? Share your thinking with us!

So You Want To Be a Senior Developer? is a post from CSS-Tricks