DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for 10 Ways Mdash Raises the Bar for UI Libraries
Jordan Brennan
Jordan Brennan

Posted on • Updated on

10 Ways Mdash Raises the Bar for UI Libraries

Mdash (pronounced "em dash") is a modern alternative to the UI libraries we've been using for the past nine years.

In stark contrast to the status quo, Mdash is framework-agnostic and immediately usable via CDN. There's no dependencies and no build step, yet it is entirely modern. Its size and simplicity hearkens back to a time when libraries Just Workβ„’.

You can learn all about Mdash on its doc site and try the live code demos, but for now I'd like to highlight 10 things about Mdash that make it awesome.

1. Tiny size

At just 6.8kb, Mdash is the smallest UI library by far:

Size comparison

Such a tiny footprint makes your app lighter and more performant on all devices and networks.

An entire app built with Vue, Mdash, and 40kb of custom code is still smaller than Bootstrap alone!

2. Practical feature set

Even with its uniquely small size, Mdash comes with a comparable set of components and utilities as other libraries.

It currently includes:

  • Maximized use of native HTML
  • 19 custom components (Alert, Icon, Tabs, etc.)
  • 150+ utility classes

The utility classes help you to augment or expand beyond the core components and implement custom designs:

Homer bio with utility classes

Rather than bloating itself with tons of opinionated components, Mdash is kind of like an HTML6. A balance between useful and overbearing. A sweet spot between Tailwind and Material-UI.

3. Maximum compatibility

While other UI libraries depend on a third-party framework and can therefore only work with that framework, Mdash leverages the power of web standards.

Here's the same Mdash component being used by 14 different technologies:

Vue
<m-alert v-if="alert" v-bind:type="alert.type">{{ alert.message }}</m-alert>

Angular
<m-alert *ngIf="alert" [type]="alert.type">{{ alert.message }}</m-alert>

Riot
<m-alert if="{alert}" type="{alert.type}">{alert.message}</m-alert>

Preact
{props.alert &&
  <m-alert type={props.alert.type}>{props.alert.message}</m-alert>
}

Svelte
{#if alert}
  <m-alert bind:type="{alert.type}">{alert.message}</m-alert>
{/if}

Handlebars
{{#if alert}}
  <m-alert type="{{alert.type}}">{{alert.message}}</m-alert>
{{/if}}

Lit, Hyper, template literals
html`<m-alert type="${alert.type}">${alert.message}</m-alert>`

EJS, ERB, lodash, Underscore
<m-alert type="<%= alert.type %>"><%= alert.message %></m-alert>

And static HTML of course :)
<m-alert type="success">My message</m-alert>
Enter fullscreen mode Exit fullscreen mode

That kind of compatibility is what the web is all about! Mdash has the scale of a truly sharable design system!

By leveraging standards and avoiding dependencies, Mdash enables a level of product-wide UI standardization not possible with other libraries. And because the codebase is so simple, it's quite reasonable for your company to fork Mdash and customize.

4. Faster in every way possible

Part of the design philosophy of Mdash is "nothing is faster than nothing". The result is a library that is faster in every way possible:

  • Getting started is instant, link to Mdash and it's ready to go
  • Learning curve is flat and short since Mdash is "just" HTML
  • Build times don't increase even 1 second because there's nothing to install or build (or fail because of some cryptic Webpack misconfig)
  • Writing code is faster because it's standard HTML and there's less of it!
  • Pages load faster because it contains so little code to download, parse, and execute (6 vs. 70, 80, 200+ kilobytes)
  • First paint starts sooner because Mdash has almost no overhead and can be server-rendered
  • Render updates are instant because Mdash is real DOM that interacts directly with highly-optimized browser APIs, not abstractions and virtual DOM

5. Familiar markup

It's back to basics. Mdash code looks and feels just like HTML because it is HTML:

Custom button type (renders an 'x')
<button type="remove"></button>

Custom list type (renders no bullets)
<ul type="none">
  <li>...</li>
  <li>...</li>
</ul>

Badge component
<m-badge count="10"></m-badge>

Dialog component
<m-dialog open>
  <h2>Title</h2>
  <p>Body</p>
</m-dialog>

Responsive grid layout
<m-row>
  <m-col span="3 sm-6">...</m-col>
  <m-col span="9 sm-6">...</m-col>
</m-row>

Utility classes
<h2 class="txt-center fnt-light">...</h2>
Enter fullscreen mode Exit fullscreen mode

Some nice side benefits are your IDE doesn't need a special plugin, browser dev tools don't need a plugin, and all the Mdash code you write is portable HTML (other than your template's syntax).

6. Uniform component API

Goodbye context switching! There are three component types and with Mdash they all have the same standard <tag attribute="value">...</tag> API:

1. Native element
<a href="/example.pdf" download>Link</a>

2. Static "micro" component
<m-icon name="phone"></m-icon>

3. Stateful interactive component
<m-dialog open>
  <h2>Title</h2>
  <p>Body</p>
</m-dialog>
Enter fullscreen mode Exit fullscreen mode

The consistency is refreshing because regardless of how different components are, the markup, and therefore your mental model, is the same. Contrast this with constant context-switching between framework idioms, JSX subtleties, classes, and custom API when using something like React Bootstrap.

7. Versatility

All types of projects can use Mdash in their UI. Static site, server-rendered, SPA, PWA - whatever you have, Mdash works! Even some popular email clients will render Mdash correctly and email clients suck!

This versatility makes Mdash especially good as a design system for larger organizations that have lots of diverse web products needing to maintain UI consistency.

8. Free and easy accessibility

In many cases Mdash is accessible by default because it leverages standards, but it also includes necessary accessibility requirements:

  • aria- attributes are set automatically where possible
  • Colors look good and meet contrast requirements (not as easy as it sounds) by staying within the perceptually uniform color space
  • 16px body font size, 13px absolute min
  • Any additional accessibility needs are clearly documented for each component, see Tabs' a11y section for example.

9. Greater longevity

Libraries come and go, but web standards are forever.

Uhh, that kinda sounded like an engagement ring commercial πŸ’β€οΈ

Anyway, like other open-source projects, Mdash wants to live a long useful life and being based on web standards assures its relevance over time. Deviating from standards, on the other hand, risks painting developers into a corner as the web platform progresses (e.g. jQuery using outdated APIs, React not working with WC).

10. Low commitment

A developer friend once shared this insight with me:

"Pick a framework not because it's popular, but for how much of a legacy mess will be leftover when it's not."

To adopt other design systems means committing to use the JavaScript framework they depend on. Tying these two concerns together - UI elements and application structure - has negative consequences.

Frameworks should be used for application structure and state, not UI elements. Here's what I mean:

Clean app architecture

Mdash's clean interface enables a modular architecture making the design system and framework more easily replaced.

Conclusion

That's 10 things that make Mdash awesome! If you'd like to try Mdash, it's really easy to get started.

Follow Mdash on Twitter
Contribute on GitHub

Thanks for reading!

Top comments (0)

Visualizing Promises and Async/Await 🀯

async await

☝️ Check out this all-time classic DEV post