kickstartDS

Sass is the CSS extension language of our choice for the additional constructs it offers when creating modularized and DRY styles for components in a Design System.

Key feature for us would be the support for nested declarations. Being able to write composable styles in a concise manner enables the creation of maintainable Design Systems, even if the number of components begins to scale up. In combination with BEM as a convention, it automatically forces developers to think in well defined, maintainable structures when creating additional components. Having to name things, in our mind, is a positive (wink Tailwind), especially when working on long-term codebases that often times have to signal intent to consumers (users and developers of the Design System). Communicating intent with semantic markup and structured, well-named classes is a big part of that.

Especially being able to generate CSS3 in the end, while allowing users to choose between just overwriting some values by defining design tokens / component tokens (staying well within the world of standard CSS3) or utilizing all the mixins, functions and utilities we expose for reuse of shared styling and behavior, when using Sass yourself.

Sass variables are not a huge factor for us, as we're writing design tokens and components tokens directly with CSS Properties. We generate some Sass "theme"-files based on those properties for developers working with Sass and wanting to re-use those already defined values!

Some of the new features in CSS3 make it the perfect evolution of CSS for us at the moment. CSS modules for better native use of the code we write and generate, and CSS Properties (CSS Variables) for a flexibility that was not attainable before (ignoring resource- and JavaScript-heavy solutions).

All components that are available as part of our Design System solution use CSS Properties extensively, to create multiple layers of default configuration (which colors to use, font sizes, etc). This enables users of those components to hit the ground running with sensible defaults, while always having the peace of mind of being able to break those layers open, and customize if needed. And all of this with vanilla CSS, at runtime!

Runtime configurability, for us, is the cherry on top. Being able to quickly change values in the browser to test something out, not having to rely on complex build processes and toolchains just to change some values, or the ability to write small widgets / configuration interfaces enabling website and product owners unprecedented access to theming options (if needed!).

In addition to using ES6 as a specific flavor, on top of JavaScript, as a technology, we're using TypeScript for it's additional type safety and resulting confidence when developing long lasting, well-rounded frontend solutions like a component library.

One additional feature of TypeScript we're relying heavily on is the ability to generate types for publishing packages. We use this to generate all component typings automatically, based on shared JSON Schema definitions, enabling auto-complete for properties defined in the context of the component... based on the generated types.

ES6 is the specific flavour of JavaScript we're writing for it's much improved module support, making 100% vanilla JavaScript solutions a reality. It is also much more terse and expressive in its syntax (iterators, destructuring, arrow functions, etc).

As every piece of code being run in a website built on kickstartDS components is developed in a bespoke fashion, being able to rely on such best practives while also staying complete compatible and performant. As a result, component JavaScript can be used completely independent from the underlying framework or technology, and has its own dedicated build process for optimal code splitting and bundling.