Forem: Skypack

The best classless CSS frameworks in 2021

Melissa McEwen — Tue, 09 Mar 2021 00:13:36 +0000

Ever need style for some plain HTML? Then classless CSS frameworks are for you. I started using these when working on code examples for our Best Date Libraries post. The plain HTML examples looked distractingly ugly, but writing I didn't want to write any CSS. I found Sakura, a classless CSS framework. With just one CSS file my examples looked far more polished. And I didn't have to change the HTML at all.

What is a classless CSS framework?

Classless CSS differs from other types of CSS frameworks that target classes. For example, with Bootstrap (the most popular traditional CSS framework) you need to add class="blockquote" to your blockquotes to style them. Or WYSIWYG.css, a "class-light" CSS framework. WYSIWYG.css targets basic HTML elements, but only within a container with class="wysiwyg".

Who are classless CSS frameworks for?

Classless CSS frameworks are ideal for demos, proofs of concept, minimalist sites, and code examples.

Beyond that, their lack of precision limits design options and can override other CSS, making a larger site design look weird. Furthermore they don't offer much contextual flexibility. For example let's say you want to have headers look different when used on a sidebar vs. the body of a blog post. It's also almost impossible to have a layout beyond a basic single column without using classes.

Testing classless CSS frameworks

We picked eleven classless CSS frameworks to test in Codepen. Want to see what they look like when applied to the same page? Toggle them in our Classless CSS Tester Codepen:

Our favorite: Sakura

I ended up picking Sakura for use in examples in Codepen. Sakura covers most HTML elements I use in examples such as headers. Most importantly, Sakura makes HTML look tidy and readable, but isn't distracting.

For prototyping: MVP.css

If you're building a prototype, MVP.css is a great choice. MVP.css allows you to construct basic user interfaces with plain HTML. If you're at a hackathon or just hacking a side project, check this one out:

For bloggers: holiday.css

If you're building a simple blog and want basic style, holiday.css looks clean and styles the semantic elements commonly used in writing. Plus it has a cool dark mode!

What to look for in a classless CSS framework

Readability

Ideally, a classless CSS framework should make text much more readable. Some things to look for are:

Spacing: Does the framework use spacing to improve readability and convey hierarchy?
Fonts: Does the framework use fonts designed for the web? For example Why You Don’t Use Garamond on The Web explains why some fonts aren't suited for use on websites. Are the font sizes readable and do they have a clear hierarchy? That can be complicated to judge but I like the pointers laid out in The Responsive Website Font Size Guidelines .
Color contrast: Color can make a difference in how legible text is. Check out the accessibility section for more on this.

Coverage

It's worth thinking about what HTML elements you want to style. Not all frameworks style the same elements. When I write blog posts I like to use the <aside> element for tips and other tangential information. Many classless CSS frameworks do not style asides, which makes them look like part of a paragraph. On the flip side, there may be elements you do not want to style. MVP.css styles <section> elements which might be confusing on a blog.

Size

Most classless CSS frameworks are small, ranging from 1.3 to 5.1 kb. The exception is those that use custom fonts. Classless css frameworks that use @import for custom fonts are usually around 200-600kb. You have to decide whether those fonts are worth their size.

Theming

A classless CSS framework can be as simple as a single CSS file, but others use tools like SASS that output CSS as part of a build process. The advantage of the more complex tool chain is the ability to "theme" the final output. For example, with Sakura you can create your own theme by changing variables in a SASS file. Holiday.css has both light and dark modes and switches based on prefers-color-scheme.

Accessibility

Is CSS really part of accessibility? Definitely! Let's take the humble <a> element for example. If only styled with color, colorblind users may not be able to distinguish links from regular text. WebAIM's Links and Hypertext guidance recommends styling links with an underline. And if links aren't underlined, have higher contrast and hover effects. For further reading on this topic see the WebAIM Contrast and Color Accessibility guidelines.

Some other common CSS accessibility issues:

Color contrast is too low — for example light blue text against a slightly less light blue background.
User interface elements difficult to use — such as buttons that are too tiny to click.

Style

Do you want to go for a minimal look or a more stylish sparkle ✨? Most classless CSS frameworks are minimalist. But there are a few with a distinctive style like Tufte.css, based on the work of data visualization pioneer Edward Tufte.

Resources

The best JavaScript date libraries in 2021

Melissa McEwen — Tue, 16 Feb 2021 15:28:33 +0000

Wrangling dates and times in JavaScript can be a headache. JavaScript date libraries provide user-friendly APIs and useful utilities that alleviate some of that pain. But with so many options how do you pick the best one? In this post we delve into the world of JavaScript date libraries to help you choose. Our top pick, date-fns, delivers the best feature set combined with an elegant modular architecture.

Our picks

Best overall: date-fns

date-fns offers great documentation, functional architecture, and utilities that handle almost any task you can think of. If dates are a critical concern for your JavaScript application, use date-fns. Each feature has clear documentation written in ESM (ES Modules) for the browser. Logical and consistent function names encourage readable code. A modular architecture allows build tools to trim away unused code for a slimmer final build.

Best for time zones: Luxon

If time zones or localization are your primary concern, we recommend Luxon. Luxon leverages JavaScript's Intl for speed and slimness while providing what Intl doesn't: an immutable user-friendly API. Concise, well-written documentation eases the learning curve for getting started.

Best minimalist option: Day.js

For basic handling of dates, Day.js is a minimalist library that offers an excellent API without much overhead. While Day.js has fewer features than Luxon or date-fns, it's much smaller in size.

The Research

When to use a JavaScript date library
Our previous pick: Moment.js
How we picked
Our picks in detail
- Date-fns
- Day.js
- Luxon
Other JavaScript date libraries
Useful Resources

When to use a JavaScript date library

Why not just use JavaScript's built-in Date object? A good JavaScript date library provides a clear advantage over JavaScript's Date in several ways: immutability, parsing, and time zones. In addition, JavaScript date libraries offer useful utilities for date manipulation and formatting, which can save developers time and energy.

ℹ️ Maggie Pint's blog post Fixing JavaScript Date describes how Javascript's Date was based on a Java (nope, not a typo) API from the 1990s. That Java API is long gone from Java but its problems live on in JavaScript's Date.

JavaScript's Date is mutable, which can lead to unintentional bugs. Let's say you create a Date object named currentTime. You display it on top of the website. Another developer comes in and wants to create a widget that displays next weeks events. They use currentTime.setDate(currentTime.getDate() + 7) at the top to the widget to display next week's date. However it also changes the date in the header! Oops. With an immutable date library, adding a week would create a new instance so the original would not change.

While Date has a parse method, MDN documentation for Date's dateString notes that usage is "strongly discouraged." An excellent answer in the Stack Exchange question Why does Date.parse give incorrect results? describes in detail differences in formatting standards and browsers lead to inconsistent and unreliable results. If you need to parse, a date library is a must.

ℹ️ UTC is enough for everyone..right? is an incredible interactive presentation by Zach Holman on how dates work in programming

Time zones are another major frustration. Date in the browser always represents the local system date stored as milliseconds since January 1st, 1970 in UTC. A Date can rendered as a string in a different time zone using Intl, but the Date itself is always the local system time.

Date also lacks utilities for common tasks like creating human-readable relative dates. Using library utilities for such tasks can save a lot of time.

ℹ️ TC39, the major JavaScript standard's committee, is working on a new modern API called Temporal (see the proposal here) that solves all of the above issues. The Future of Date and Time in JavaScript by Christofer Eliasson is an excellent read of the history behind Temporal and what it means for JavaScript.

In the meantime, be aware of the limitations of Date and use a library when you need one.

Our previous pick: Moment.js

For a long time Moment.js was king of the JavaScript date libraries, but in 2020 Moment.js's maintainers published a Project Status announcing they consider Moment.js a legacy project.

The maintainers argued that there was no way to refactor Moment.js to meet the demands of modern JavaScript development such as immutability and tree shaking. Lighthouse (Chrome's built-in auditing tool) warns against using Moment because of its large size (329 kb).

For these reasons, we do not include it as one of our recommended picks. If you are looking for a replacement to Moment.js that closely matches its API, try Day.js.

How we picked

We looked at data from Skypack and NPM trends to identity the most popular and trending libraries and evaluated them against these core criteria:

Browser-friendly: We evaluated JavaScript date libraries for use directly by the browser rather than the Node.js backend.
Great documentation: Users look to this to implement the library correctly. We looked at the parts the facilitate this process: organization, search, examples, and the individual pages relating to the methods we tested.
Modularity + Tree shaking: Modular architecture allows you to shrink your library size by "tree-shaking" out any library code you're not using. Common build tools capable of tree-shaking include Webpack, Snowpack and Rollup.
Features: Feature-richness was just one factor. We also considered whether a library was especially good at certain tasks.
Performance: Measuring performance gives us a clue at how fast each library performs common operations. This usually isn't noticeable but in large, complex apps can cause lag.
Size: One of the biggest problems people had with Moment.js was size. A large library can substantially increase page load times.
Anti-bug features: Immutability, readability, and informative error messages can help prevent bugs. When code is readable, you can learn a lot about what it does by reading it. Format, syntax, and naming conventions can make all the difference in readability.

How we tested

When evaluating each library we made a CodePen using Skypack. We attempted to pick out common use cases that illustrate differences between libraries:

Rendering the current date & time
Rendering the current date using a custom format
Modifying a date to add/remove time
Working with timezones
Parsing arbitrary date strings

First we implemented these cases using JavaScript's Date:

We wrote up examples for performance testing on perf.link and all of the tests and code are available in the Date/time performance examples GitHub repository. If you have a specific use-case, you can modify one of the provided examples. JavaScript date libraries contain hundreds of methods and features that we couldn't test them all. Instead, we opted to test the same methods demonstrated in our Codepens.

A chart of the performance data is also available on CodePen. The data doesn't indicate a clear advantage for any one library. Each JavaScript date library implements different features differently, so that's not surprising.

⏱ For other performance comparisons see

Why you shouldn't use Moment.js...

You don't (may not) need Moment.js

The sizes listed on each review are based on loading via the Skypack CDN. If you're using a build tool to tree-shake and the library is tree-shakable (like date-fns), the size will depend on what parts you use. For evaluating libraries with tree-shaking we recommend Bundlephobia.

A caveat to our testing is we did not consider back-end Node.js use. Many JavaScript date libraries rely on browser APIs so may not work correctly on the back-end.

Other cases to test

Depending on your needs there are lots of other tests you could do. If you'd like to test other features not covered here, you can make changes to any of the examples in our embedded Codepens or CodePen date collection.

For example:

Does it let us know if we have an invalid date when we pass in invalid items? For example moment(undefined) behaves like moment() and doesn't output an error, which could lead to bugs.
How well does it handle different languages and locales?
Can it render relative dates (like "4 days ago")? Can it do this in different languages?
Does it work in older browsers?

Our picks in detail

Date-fns

Size: 58.9 kb (tree-shakable)

date-fns is a pleasure to use, offering all the benefits of a modular architecture and covering almost any date use case. Our example shows the power of good naming and syntax in conveying information. Code like add(now, {days: 7}) is straightforward to understand even if you're unfamiliar with date-fns.

To get the most out of date-fns's modular architecture, use a tree-shaking build tool (see our criteria section) and import only the features you need:

import { format, add, getHours, parse } from "https://cdn.skypack.dev/date-fns@2.16.1";

In the example above, a tree-shaking build tool would remove all code from date-fns that's not used in format, add, getHours, or parse. The final build would be much slimmer. Still at 58.9kb for the whole package, it's not giant in the first place.

date-fns doesn't package a browser build for NPM (see the related GitHub issue) and therefore only works on CDNs that transform for the browser like Skypack and ESM.run. However, documentation has examples labeled for the browser as both ESM(ES Modules) and ES2015. This ensures developers don't get confused trying to run Node.js backend code in the browser.

Limitations

Although we liked almost everything about date-fns, it is not for everyone. For starters, date-fns seems geared towards experienced developers working with a professional tool chain. Working without a build tool, the tree-shaking advantage disappears.

Note that our CodePen example starts with a const now = new Date(), which is the default JavaScript Date object. As noted in our Date section a Date is always the current system's time zone. date-fns has a separate library for working with time zones using helper functions. We found the documentation and examples for these helper functions less consistent than the main date-fns. Our resulting code is less readable than the rest of the examples. Our time-zone example for date-fns is 4 lines of code, compared to 1 for Luxon.

Another quirk we encountered was if you Google "date-fns parse" the top results take you to the v2.0.0-alpha docs for parse, which no longer work (the current version is 2.16). We found ourselves using Google because the documentation's built-in search seems to search only title and descriptions of sub-pages. The information architecture of the menu could also use improvement, as we would it overwhelmingly long. On occasion, a modal advertising "Get awesome JavaScript jobs to your email" covered the menu's bottom.

The hardest part of implementing date-fns Codepen examples was parsing, since they use different format tokens from other libraries. Furthermore, some tokens are not compatible with other tokens and the compatibility table is a Google doc that is hard to read.

Day.js

Size: 4kb

If Date fulfills almost all your needs but you don't want to deal with its downsides, Day.js is a great choice. Day.js's small size makes it ideal for build-tool free environments like CodePen and plain JS/HTML/CSS projects. If you're forced to support older browsers, Day.js 's Readme says it supports IE as far back as IE 7, though we did not test these capabilities.

The Day.js documentation claims "If you use Moment.js, you already know how to use Day.js", which would make migrating easier. You can see direct comparisons at the excellent You don't (may not) need Moment.js. The code in our example CodePen is readable with the exception of the parsing and time zone cases.

A well-organized menu helped us find what we need in the Day.js documentation. In addition the documentation search gives great results organized by type. We liked that most documentation pages have example code.

Limitations

Like date-fns, Day.js builds on top of JavaScript's Date, so time zone support requires another library. But unlike date-fns, Day.js relies on a plugin system that we did not find intuitive. You not only need to import the plugin but you also need to enable it by running dayjs.extend(plugin_name).

There is a stark contrast in our CodePen example between the time zone example and the other examples. The time zone example is much less readable and you'll also notice we commented it out. That's because it gave us incorrect results. It could be because our example time zone is an edge case or we did something wrong, but we attempted to follow the documentation. We recommend Luxon instead if you need to deal with time zones.

We encountered a few minor issues in the docs. The documentation does not contain any ESM (Es Modules) examples. This is especially apparent in the documentation for loading plugins in the browser, which recommends loading via script tag and then extending via the window global. In general for readability and browser compatibility, we prefer to avoid globals.

Unlike the other libraries you don't indicate a format with tokens when parsing. This worked fine in our CodePen but we wonder how correctly it would handle ambiguous formats. We felt the documentation could use more examples, specifically the parsing page. It took us a minute to realize parsing isn't its own method: you use dayjs() and pass in a string. Unfortunately this syntax makes the code less understandable at a glance.

Luxon

Size: 29.5kb

If time zones are high on your list of concerns, go with Luxon. Dealing with time zones is never fun, so it's nice to use a library where it just works. Most date libraries don't have a built-in time-zone support because adding a time zone database is complex and adds a lot of weight to the final size. To get around this problem, Luxon hacks into JavaScript's Intl API, which most browsers support. It's the only JavaScript date library we evaluated that does not extend Date, instead using its own DateTime class. In our experience this makes working with time zones less bug-prone.

Luxon's creator Isaac Cambron is a Moment.js maintainer. In Why does Luxon exist he says "Luxon started because I had a bunch of ideas on how to improve Moment but kept finding Moment wasn't a good codebase to explore them with."

Luxon's documentation is divided up into a Manual and Reference. Since the more technical API documentation is in the Reference, the Manual is much more readable. Most importantly the Manual is well-written and organized into clear sections, with browser-friendly install instructions for ESM (ES Modules). The resulting code in our CodePen example is remarkably readable, particularly for the time zone case.

ℹ️ "Can't we just get rid of time zones?" A common developer refrain, usually after dealing with a time zone related bug. So You Want To Abolish Time Zones is a great read on why that's not a panacea.

Limitations

We recommend date-fns for date dependent applications because compared to Luxon it has a larger feature set and is tree-shakable. If feature set is not a major concern, Day.js is a better pick because it's ~7 times smaller than Luxon (29.5kb for Luxon vs. 4kb for Day.js). Except for time zones, Luxon doesn't offer a clear advantage.

We noted above that Luxon relies on Intl and that most browsers support it, but this doesn't include older browsers. A polyfill is available, but this will increase the complexity and size of using Luxon.

A minor quibble is Luxon's documentation search doesn't seem to index the entire text.

Other JavaScript date libraries

Here are two interesting JavaScript date libraries that we didn't have time to evaluate:

Forem: Skypack

The best classless CSS frameworks in 2021

What is a classless CSS framework?

Who are classless CSS frameworks for?

Testing classless CSS frameworks

Our favorite: Sakura

For prototyping: MVP.css

For bloggers: holiday.css

What to look for in a classless CSS framework

Readability

Coverage

Size

Theming

Accessibility

Style

Resources

The best JavaScript date libraries in 2021

Our picks

Best overall: date-fns

Best for time zones: Luxon

Best minimalist option: Day.js

The Research

When to use a JavaScript date library

Our previous pick: Moment.js

How we picked

How we tested

Other cases to test

Our picks in detail

Date-fns

Limitations

Day.js

Limitations

Luxon

Limitations

Other JavaScript date libraries

Useful Resources