DEV Community: Sasha Koss

Write plain CSS while reaping the benefits of CSS-in-JS

Sasha Koss — Thu, 08 Aug 2019 13:50:57 +0000

Modern CSS land is divided into CSS-in-JS followers and plain CSS adherents with an ongoing controversy about which approach is superior. Despite the fight, it benefits us by advancing the ecosystem and making it more vibrant.

While plain CSS users get established tooling, simplicity, performance, and portability, the CSS-in-JS users enjoy the reliability and tight integration with the app code.

Why don't we have both?

Nyan CSS is a convention that allows to write good ol' CSS and import the styles as components (React/Preact/Vue.js).

Here's how it works. First, you define CSS:

.Header,
.Text {
  font-family: monospace;
}

.Header {
  font-size: 2rem;
}

.Header-size-large {
  font-size: 2.2rem;
}

.Text-italic {
  font-style: italic;
}

Then you import it as components:

import React from 'react'
import { Header, Text } from './style.css'

function Announcement() {
  return (
    <>
      <Header tag="h1" size="large">
        Welcome Nyan CSS!
      </Header>
      <Text tag="marquee" italic>
        Please, welcome Nyan CSS!
      </Text>
    </>
  )
}

And so you get:

Essentially Nyan CSS is a convention plus family of libraries that provides tight integration with frameworks (React, Preact, Vue.js, class names). You don't need to install anything to use Nyan CSS with HTML.

The convention

The convention is simplisitic and consist just of three rules:

.Button is a CSS class which represents a component (other examples are .ListItem , .UI , etc.) and can be used as <Button>Content</Button>.
.Button-disabled generates a component with a boolean prop (e.g. .Button-fullWidth, .Window-inactive) and can be used as <Button disabled />.
.Button-color-red represents a component with an enum prop (e.g. .Spacing-direction-column, .Window-mode-alert) and can be used as <Button color='red' />.

Why?

Universal design system

Because Nyan CSS is just CSS, it can be used across different projects built using different technologies with no code changes. Use the same styles for a static landing page with no JS as for React SPA.

Web technologies envolve, fashion and passion changes, and just a few things remain HTML, CSS, and JS. CoffeeScript made our lives better with its legacy, but the language itself became history.

Zero overhead

With no runtime that manipulates CSS in a browser, Nyan CSS ensures maximum performance by reducing JavaScript build size and leaving CSS management to the browser.

I was inspired by Styled Components myself, but I was working on a widget and didn't want to add extra 15Kb, so I created Nyan CSS that is not 5x size of the framework I use.

You don't need to install plugins for your editor, transpile before use or parse it anyhow. It's just CSS.

Battle-tested

I incrementally improve the approach for the last two years. I developed 6 different applications (demo: Diary Email) using Nyan CSS and confident that it just works.

Let's talk

What do you think? Give it a try. And then you can tell me if it's good or not ;-)

date-fns v2 beta is out!

Sasha Koss — Wed, 26 Jun 2019 11:31:41 +0000

For those who don't know, date-fns is a modern JavaScript date utility library. It's focused on build size and performance. It's tree-shakable so only used functionality will be included in your build. The minimal build size is just 295 B that makes it the smallest date library in JS world! Unlike other date libraries, date-fns uses native Date object and embraces the functional approach.

It took us two years to develop v2, and during the time we reworked every bit of the library. We've merged nearly 500 pull requests from a hundred contributors! Today I invite you to give it a try:

npm install date-fns@next --save
# or using Yarn:
yarn add date-fns@next

It's stable, and we don't plan to change the API. It could have been a final release, but as it introduces plenty of breaking changes in the upcoming days, we're going to work on making the upgrade process as smooth as possible. In meanwhile, you can help us by testing the library and sharing your feedback.

What's new?

Here some most exciting features, for the full list of changes (it's enormous!) see the changelog: https://date-fns.org/v2.0.0-beta.1/docs/Change-Log

EcmaScript Modules. With v2 we ship both ESM and CommonJS, so if your bundler supports tree-shaking you can import functions directly from the root of the package and still get slim build:

import { format, formatDistance, formatRelative, subDays } from 'date-fns'

format(new Date(), "'Today is a' iiii")
//=> "Today is a Wednesday"

formatDistance(subDays(new Date(), 3), new Date())
//=> "3 days ago"

formatRelative(subDays(new Date(), 3), new Date())
//=> "last Friday at 7:26 p.m."

Also, we adopted the camelcase naming scheme:

// Before v2.0.0
import addDays from 'date-fns/add_days'

// v2.0.0 onward
import addDays from 'date-fns/addDays'

Another feature I'm sure FP fans will love is new FP submodule. It introduces copies of regular functions which accept arguments in inverse order and curryied by default. They could be imported from date-fns/fp and used along with regular functions.

The main advantage of FP functions is the support of functional-style function composing.

const { differenceInDays: regularDifferenceInDays } = require('date-fns')
const { differenceInDays: fpDifferenceInDays } = require('date-fns/fp')

regularDifferenceInDays(Date.now(), 0)
//=> 17815

fpDifferenceInDays(0, Date.now())
//=> 17815

fpDifferenceInDays(0)(Date.now())
//=> 17815

const daysSinceUnixEpoch = fpDifferenceInDays(0)
daysSinceUnixEpoch(Date.now())
//=> 17815

We added dozens of new functions, but one requires special attention: parse. It allows parsing a string using arbitrary format:

import { parse } from 'date-fns'

parse('02/11/2014', 'MM/dd/yyyy', new Date())
//=> Tue Feb 11 2014 00:00:00

That was possibly the most requested feature and to make it happen we completely rewrote I18n code.

Also, we carefully refined every function to make date-fns consistent, predictable, and reliable. We made it work in edge cases like ECMAScript would work. You can read more about v2 API design in a DEV post.

What's next?

After we ship the final version, there are few initiatives that we want to focus on:

UTC versions of functions.
Durations support.
Time zones (right now TZ functionality is provided by date-fns-tz).
Integration with Intl API.

Acknowledgments

Neither v2 nor date-fns, in general, would not be possible without 153 contributors that helped to make date-fns awesome. I wish I could mention everyone but the list would be too big. But I can't skip my brother, Lesha Koss that wrote the bulk of date-fns code. You're amazing!

Thank you for reading! I hope you'll love v2. Join date-fns community at Spectrum and follow us on Twitter.

If you want to ship a side project, start with unlearning the best practices

Sasha Koss — Mon, 13 May 2019 12:36:00 +0000

Two years ago was my last week as a software engineer at Toptal where I was leading team of 12 people. Since then I work on my projects full-time. That was my the most productive and satisfying years for the whole decade-long+ career. While I still far from achieving my goal of building a sustainable business I learned a lot about product development, copy, marketing, and sales. In this article, I share lessons I learned as a developer while I was working on a dozen projects. If you like me, have an itch for making stuff and seeking for independence, this piece is for you.

Learning the best practices

My first years as a professional developer was rough. After I failed as an indie game developer for a few years I was working as a freelancer making various web projects. I was a developer you wouldn't want to see in your team. I worked long hours on low-budget projects with unrealistic estimations that were making both my clients and me disappointed in the outcome if there was one at all. Bugs, missed deadlines, features that didn't meet the expectations, I saw it all. I didn't know positive examples I but was sure that there's a better way to develop projects.

After yet another flopped project I opened for myself Ruby world that felt like a different realm. The community greatly influenced my views on development, project management, and business. I read Getting Real and all books I could find on business and project management. I religiously studied and tried all known methodologies that suppose to improve the code quality and productivity. SOLID, TDD, BDD, GTD, SCRUM, you name it. It took another few years before I became a developer that you would want to see on your team.

During all that time I was always working on side projects. I started dozens of them of all kinds, from todo lists, ticket trackers to social networks. They were taking all my free time, but I never managed to finish any of them. At first, I got excited about the idea, came up with a new shiny stack of technologies, and then developed it applying the best methodologies I learned the hard way. Then I would be stuck, lost interest or came up with a new, better idea. When I quit my job and started investing my own money into projects, I quickly realized what I was doing wrong.

Do your worst

The practices that are vital in teams might be poisonous when you work alone. Paradoxically, to do your best you must do your worst!

When there's dozen of people working on a single code base, it's necessary to ensure that the systems are designed well, the code is easy to read and have decent test coverage. Pull requests should be reviewed and merged only when they satisfy the team standards. "I'll refactor it later" never works in the teams because there's too much going on and more likely the next person that touches your code won't be you.

When you work alone, following the best practices slow you down. When you're the single code owner, you can defer writing tests until you met a critical part that can't break at any cost. Even then just couple end-to-end test could be enough. It doesn't mean that I avoid tests altogether. If the code is easy to write thought unit tests or too hard to test manually, I do it.

There's nothing worse in code design than a poorly chosen abstraction. When I develop my products, I prefer to copy-paste code two, three and even more times until I see a common pattern and if and only if I change it frequently. It doesn't matter if you have 3 repeating pieces in the code if you are never going to change it. After all, the whole point of refactoring is to make it easy to modify. I think this realization still applies to teams, but you must be systematical about it and keep a ticket in your backlog or notes in the comments.

Focusing on performance is another mistake I was repeatable making. We all the time see tweets and articles about the importance of small code bundle, fast response time or small memory print. Developers often shame companies for their sloppy work, and you might think that your small business won't survive without providing the top-notch experience. The truth is not that important if you never ship your project. People won't buy your product only because it loads in less than a second, but if it solves their problem, they will wait 5 seconds and even more. If your page has poor performance if the user created a lot of content that is a great problem to have because that means somebody actually uses it.

It doesn't matter how well your code is written, what is test coverage or how fast is it if it never shipped or has no users. Also, your first customers will be early adopters that want to have an advantage of being the first using it, and too polished product might signal them that it's too late.

Stick to the tech you already know

The whole career I was chasing the better programming languages, newest frameworks and most efficient ways to manage infrastructure. I tried at least one new tech in every side project I started, and because most of the time I was wrapping my head around and learning new concepts I never managed to get to shipping. No doubts it was beneficial for my career as I learned much more than the average engineer. It made my truly full-stack developer that can do everything from infrastructure to front-end. It also helped me to satisfy my passion for new tech without hurting my employer by experimenting in the production code.

When I started my indie maker adventure I wanted to ship instead of learning so I decided to stick to the stack, I know the best — JavaScript both on back-end and front-end. Even though I was capable of managing infrastructure myself, I choose the Firebase platform that provided everything from static website hosting, servers to a managed database. It wasn't optimal, most efficient and elegant, but because of my prior experience, it all helped me to start and focus on products quickly.

At the end of the day, I don't use most of the technologies I learned, and there's plenty of excellent examples of founders without prior programming experience that taught them self to code by doing and started making more money and much faster than me. It made me wonder if it was worth it all.

If your only goal is to learn new stuff, you can ignore my advice, but if you want to ship, avoid using new technologies unless necessary.

Be lean

For many years I worked in companies where quality was the priority. It wasn't acceptable to deploy half backed product that doesn't provide up to standard experience on all levels from the core functionality to small details. If the user enters their name, there must be a setting for that. If there's a list, there must be pagination. And so on and so forth.

When you are small, even a standard feature like name settings or password recovery could take the time that might be spent on more important things. When I was working on designs for my first big project, Ask User a widget for web sites, I noticed that I spend too much time on details that aren't necessary for the first release. I started cutting features until I left with the functionality that solves the main problem. During the development, I decided to step further and skipped things that seemed absolutely necessary at first, like the ability to remove created sites. I was planning to introduce that after the release but to my surprise, users didn't care. They wanted utterly different features that I didn't even think of initially.

Then I spend weeks writing a billing system only to learn that people don't ready to pay for the problem I solve. For the next project, Telepost, I decided to ask users to send me money to PayPal, and it worked out. Later I added a button "Activate the Pro plan" that does nothing but shows the message "We'll contact you soon" and sends me an email (using Zapier) with the user details. Then I'd talk with each interested customer individually. During the conversation, I was able to pitch my product and hear objections about why they aren't ready to pay. That not only saved me time but also helping to shape my project for users' needs.

Getting feedback as soon as possible and changing your product according to it, must be your top priority, so optimize for shipping fast. Cut as many features as possible, then cut more.

Afterword

Thank you for reading my article. I hope it was useful for you. I tried to outline the most important lessons I learned as a developer, but there's so much more to cover! If you liked it, please let me know. I'm planning to publish more articles on the topic including more business-oriented and if you're interested in reading them first, follow me on Twitter.

The photo for cover is kindly provided by chuttersnap on Unsplash

date-fns v2 API design

Sasha Koss — Wed, 12 Dec 2018 16:00:09 +0000

date-fns is JavaScript library for working with dates. It's a modern alternative to Moment.js.

For almost two years we've been working on a new major release — v2. We've reworked nearly every aspect of the library and added many exciting features. One of the most critical changes in v2 is the new API design. We carefully refined every function to make date-fns consistent, predictable and reliable. In this post, I tell about goals and values that helped us to design simple API that is pleasant to use.

Goals and values

When we just started working on date-fns, our only goal was to build a library for working with dates in functional style. For years we were adding more and more functions, often copying and adapting Moment.js API without second look on it.

After a while, we realized that our API and behavior is not as consistent as we want them to be. Arguments in functions doing a similar job were not always in the same order and had a different naming scheme. Sometimes functions were throwing exceptions where they shouldn't and weren't throwing when they should. I'm not talking about coercion logic; it was behind even our understanding.

The need for changes was obvious, but first, we had to define goals and values, that would help us make decisions in ambiguous cases.

Stick to JavaScript behavior whenever possible. We want date-fns to be an extension of the language and its standard library but not a substitute. We believe that it will ensure a long life of the library in the rapidly changing ecosystem.

Stick to existing standards. Instead of reinventing the wheel and relying on our subjective opinion we decided to look for current standards and well-established practices. That will provide the best compatibility with other languages and save us from mistakes that others made years if not decades ago.

Consistency. We want date-fns to be as predictable and easy to understand as possible. Function names, the order of arguments and the behavior must be consistent across the whole library.

Explicitness. date-fns should prefer explicitness over implicitness. Sometimes the latter helps to make code look cleaner. You know that feeling when a library does what you wanted it to do without saying a word. But more often it causes bugs that are hard to debug or even worse to notice.

Convenience. We want date-fns to be pleasant to use. We should help developers to avoid mistakes.

While the last three are self-explanatory, the first two requires deep dive.

Stick to JavaScript behavior whenever possible

Why

The initial idea of the library was to create a set of helpers that will work with the native Date object. We avoided introducing functionality that already existed in the standard library and named functions as they are part of it. In v2 we decided to go further and made date-fns behave like JavaScript in every aspect.

JavaScript and its behavior is often a subject of just critique. Because of the need for backward compatibility over the years, it accumulated nuances that nowadays considered as a bad language design. Yes, I'm talking about its coercion rules, NaN, null and so on.

However, behind every strange looking behavior stands logic consistent across the language. It might be covering weak parts of JavaScript, but it's consistent and if you learn it once it starts making sense.

Exceptions

In v2 we made date-fns throw TypeError and RangeError in cases when standard JavaScript functions do it.

Whenever an argument is required, JavaScript throws TypeError:

window.fetch()
//=> TypeError: 1 argument required, but only 0 present.

From now all functions check if the passed number of arguments is less than the number of required arguments and throw TypeError exception if so:

import { addDays } from 'date-fns'
addDays()
//=> TypeError: 2 arguments required, but only 0 present

Whenever an argument value is not in the set or range of allowed values, JavaScript throws RangeError:

(42).toFixed(-1)
//=> RangeError: toFixed() digits argument must be between 0 and 100

From now on functions throw RangeError if optional values passed to options are not undefined or have expected values:

import { formatDistanceStrict } from 'date-fns'
formatDistanceStrict(new Date(2014, 6, 2), new Date(2015, 0, 1), {
  roundingMethod: 'qwe'
})
//=> RangeError: roundingMethod must be 'floor', 'ceil' or 'round'

Coercion

Just like JavaScript date-fns coerce passed arguments to the expected type.

import { addDays } from 'date-fns'
addDays(new Date(1987, 1, 11), '42')
//=> Wed Mar 25 1987 00:00:00 GMT+0530 (+0530)

Despite being the most hated aspect of the language, coercion is quite straightforward and consistent, although it leads to unexpected results in combination with arithmetic operators.

Here are the rules that we use to coerce the arguments:

Here, the columns are what type we expect the argument to be and the rows what we actually supply as an argument — for example, in addDays the first argument will be transformed by the rules from the “date” column, and the second argument by the rules from the “number” column, so addDays(1, '1') is equivalent to addDays(new Date(1), 1).

Invalid date

Date internally represented by a number so just like with Number, incorrect operations on dates results in Invalid Date (an invalid date is a date which time value is NaN):

const date = new Date()

date.setHours('nope')
//=> NaN

date
//=> Invalid Date

date-fns reflects this behavior and will return Invalid date when you pass unconvertable values:

import { addDays } from 'date-fns/addDays'
addDays(new Date(), 'nope')
//=> 'Invalid date'

This was one of the trade-offs that were particularly hard to make:

// Detect dark theme var iframe = document.getElementById('tweet-1059894523332120576-200'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1059894523332120576&theme=dark" }

On the one hand, we would expect to have an exception when an argument has a wrong value. On the other hand, the exception would force us to wrap every function call into try-catch blocks that is bad developer experience. The standard JavaScript's approach to the problem is to expect the developer to be responsible for validating the user input. In the worst case scenario, the application will print Invalid Date and keep working that wouldn't happen if we'd throw exceptions.

Ongoing work

While writing the post, I found an inconsistency that we didn't consider. While toString called on an invalid date returns Invalid Date, toISOString as well as Intl API throws RangeError:

date.toString()
//=> 'Invalid Date'

date.toISOString()
//=> RangeError: Invalid time value

new Intl.DateTimeFormat('en-US').format(date)
//=> RangeError: Invalid time value

We incorrectly applied toString behavior to format:

import { format } from 'date-fns'

const date = new Date()
date.setHours('nope')

format(date, 'yyyy-MM-dd')
//=> 'Invalid Date'

I've opened an issue that we plan to fix before the first beta release:

format functions must throw exceptions on attempt on processing invalid dates #987

kossnocorp posted on Nov 20, 2018

See JavaScript's toISOString and Intl API for the reasoning:

const date = new Date()

date.setHours('nope')
//=> NaN

date.getYear()
//=> NaN

date.toString()
//=> Invalid date

date.toISOString()
//=> RangeError: Invalid time value

new Intl.DateTimeFormat('en-US').format(date)
//=> RangeError: Invalid time value

View on GitHub

Stick to existing standards

v2 started with the change of the filenames naming scheme. I come from the Ruby world, so I thought it's a good idea to have file names in underscore format. JavaScript renaissance just started, so there wasn't a common standard. Initially, it was irritating to see so many JavaScript'ers using the camel case format for files. But eventually, I accepted the difference and decided to prioritize common practices over personal taste and adopted camel case as well.

// v1
const addDays = require('date-fns/add_days')

// v2
const addDays = require('date-fns/addDays')

This breaking change was a turning point that allowed us to abstract from our points of views and habits and embrace existing standards and well-established practices.

One of the most significant changes was adopting Unicode Technical Standard #35 for format and parse. It caused a lot of confusion, but I believe it's worth it. You can read about that in a dedicated post.

Another standard that caused us to revisit naming schema was ISO 8601. Starting with isWithinRange function we used the word "range" for time spans:

const isWithinRange = require('date-fns/is_within_range')
isWithinRange(
  new Date(2014, 0, 3), // the date to check
  new Date(2014, 0, 1), // start
  new Date(2014, 0, 7) // end
)
//=> true

It turned out that ISO 8601:2004 defines term "interval":

time interval: part of the time axis limited by two instants

We adopted this terminology and made interval a separate entity:

import { isWithinInterval } from 'date-fns'
isWithinInterval(new Date(2014, 0, 3), {
  start: new Date(2014, 0, 1),
  end: new Date(2014, 0, 7)
})

It also made the code easier to read!

When a string is passed to new Date(), the JavaScript engine tries to do its best parsing it. In v1 we relied on the mechanism but then quickly learned that different browsers have different parsers and it leads to bugs that hard to find.

Starting with v2, whenever a string represents a date it must be a valid ISO 8601 string overwise you'll get Invalid Date.

Thank you for reading! I hope this is interesting and fits DEV community. Feedback is welcome!

I pay $1 every hour I spend working on open-source

Sasha Koss — Thu, 06 Dec 2018 13:07:12 +0000

Open source saves a shit ton of money for modern companies. It's used on every level starting with software that powers infrastructure and ending with the libraries that developers use to build the company products. Yet, maintaining an open-source project is undoubtedly the most underpaid job in our industry. I will be shocked if the average hourly rate is more than a dollar.

It's certainly less for me. Actually, it's negative. I pay $1 for every hour I spend on date-fns, a JavaScript library for working with dates that have 8M+ monthly downloads on npm. Our estimated annual budget on Open Collective is $371. On average I work 20 hours per month and pay about $50/mo for the website hosting. I'm not even talking about my hourly rate and thousands of dollars I invested into the development so we can get on par with Moment.js functionality.

The average household spends an average of $3,008 per year on dining out, the Bureau of Labor Statistics reports

If a family spends $3K on dining out then given the average tip size 20%, an adult spends at least $300 on tips. Then why every developer doesn't spend $25 monthly on donations to open source teams or individuals? That should be minimal considering that the average developer salary is at least twice as big as the average income of an American household and we're using low-skilled labor as an example.

Furthermore, if you'd try to calculate how much money companies save using open source, I won't be surprised if the number would overcome the total company funding. However, most companies suck on giving back to open source. Why's that? I think the problem is in developers again.

Developers are notoriously bad at estimating practically everything, starting with hours they need for a feature and ending with the value they bring to the company. So no surprise they don't value the time of open source contributors as well. When an open source maintainer asks for money, they either ignore them or label them as beggars or salesman. Some developers that employers should fund open source, but they look at the problem from the point of view of a Microsoft employee. And as a result, they get things such as event-stream. How many dramas do we need to start waking up?

Developers are responsible for communicating the value they get from open source and convincing their managers to pay to open source they use. Managers won't realize it by themselves unless they use it as a marketing opportunity.

With Open Collective, their Back Your Stack and Patreon it's easy as never to support the open source, so what do you waiting for?

Just go and donate to your favorite projects and maintainers and then bother your manager until they pay too. Let's make open source sustainable.

What makes a company culture great?

Sasha Koss — Tue, 27 Nov 2018 08:26:24 +0000

Corporate culture plays a huge role in the success of businesses. No matter how cool is the product or how challenging is the problems, if the working environment is toxic, the employees will find another job. Business might try using financial motivation, but it's not a secret that is the worst kind of motivation for creative professions. The only way to attract and keep the top talent is providing a working environment that allows realizing themselves maintaining life-work balance.

But what's that means? I've decided to find the answer to this question, so I've built Cultural Fit. It's a collaborative list of corporate culture traits that people love or disapprove.

I invite DEV community to help me find the answer: please vote for your favorite traits and downvote the ones you don't approve. Add missing traits and share your opinion here, in the post, or on the site:

I've build this project for Product Hunt Makers Festival 2018. This is universal Preact app. It's build using TypeScript on top of Firebase (Firestore, Firebase Hosting, Firebase Functions).

Any kind of feedback is welcome!

Thanks!