We are excited to announce that our first feature release after Ionic 4.0 is out now! In keeping true to using code names from the periodic table of elements, Ionic 4.1 is named Hydrogen (after the initial release of Neutronium).

We have some exciting new features to share in this release, so let’s dive right in!

Skeleton Text Update

The ion-skeleton-text component got some love in the form of a few new features and docs updates. Now, you can use ion-skeleton-text inside of media controls like ion-avatar and ion-thumbnail, which makes showing skeleton screens for your list items look more natural.


You can now also animate the skeleton text by passing in the animated prop:

  <ion-avatar slot="start">
    <ion-skeleton-text animated></ion-skeleton-text>
    <h2><ion-skeleton-text animated style="width: 100px;"></ion-skeleton-text></h2>
    <p><ion-skeleton-text animated style="width: 180px;"></ion-skeleton-text></p>
    <p><ion-skeleton-text animated style="width: 80px;"></ion-skeleton-text></p>

Skeletons placed inside of avatars and thumbnails will automatically adjust their size to their containers, so no need to specify a style on those. Skeletons can also be styled to have a custom border-radius, width, height, or any other CSS styles for use outside of Ionic components.

Indeterminate Checkboxes

The ion-checkbox component now has a new prop called indeterminate, and when true, it will show the checkbox in a quasi half-on/half-off state. This is useful in scenarios where you are using a “check all” checkbox, but only some of the options in the group are selected:


A checkbox with both the checked and indeterminate property set will appear as indeterminate. The behavior matches that of a native checkbox, where indeterminate is only a visual state.

Thanks to simonhaenisch for the PR to add this!

Select Component with compareWith

Previously, when determining if a particular option in an ion-select was selected or not, a strict === comparison was done on the object. A new compareWith property was added to ion-select that would either let the developer specify a particular property on the object to compare or provide a custom function to do the compare.

This was a feature in Ionic 3 and is now added back into Ionic 4.

Special thanks to community member zakton5 for providing a PR for this!

CSS Display Utilities

A few CSS classes were added to help with hiding elements and responsive design.

  • Add the ion-hide class to any element you want to hide (setting the display to none)
  • Use the new .ion-hide-{breakpoint}-{dir} classes to hide based on breakpoints for certain screen sizes. Check out the docs for more info.

This can be added to an existing Angular project at the end of the global.scss file:

@import '~@ionic/angular/css/display.css';

It is also included in the bundle that is used by React and Vue.

Big shout out to seiyria for this update!

Bug fixes Abound!

With the above feature updates, we also closed out many bugs since the 4.0.2 release. Check out the changelog for a full list of fixes and updates.

Happy building! 💙

Read more

Nothing strikes fear into the hearts of developers quite like being told their app is slow. Because of this, great pains are taken to optimize the loading and startup performance in our apps. The techniques we use have changed over the years, but the good news is that a lot of the heavy lifting is now done for us by our frameworks and build systems.

In this post, we will take a look at how lazy loading can be used to help speed up the load times of your Ionic Angular apps. Also, it doesn’t matter if your app is packaged and downloaded from the store, or a progressive web app (PWA) running off a server, lazy loading can help increase your startup times in both situations.

Why Optimize Loading Performance?

Performance is about letting users do what they need to do with your app as quickly and efficiently as possible. If your app is slow to load or unresponsive, then your customers will quickly leave and find an app that works better.

Over the past several years, web sites have started to become more app-like by offering better experiences and more functionality. As apps have become more complex, the amount of JavaScript needed to be downloaded has increased as well. JavaScript is the most expensive asset to download, so this dramatic increase in size now posed a new dilemma for our web apps.

To counter these larger bundle sizes, there are now a few additional techniques we can use to help our apps stay fast. One of these techniques is lazy loading, which breaks larger JavaScript bundles up into smaller chunks and delivers them to the browser as needed. Let’s see how we can begin to optimize our loading performance in an Ionic Angular app.

Note, it is known that premature optimization is the root of all evil. What we will go over are particular techniques you can use to see if it helps your apps, but these aren’t one-size-fits-all rules to throw at every project. Take the time to build out your app and then go over these options to see if they can point you in the right direction and are a good fit for your goals.

Lazy Loading in Ionic Angular

The idea behind lazy loading is that we only download the HTML, CSS, and JavaScript that our application needs to render its first route, and then load additional pieces of our application as needed. The great news is that a new Ionic Angular 4.0 app has lazy loading configured by default. Lazy loading is expressed through how the Angular routes are setup:

const routes: Routes = [
    path: '',
    loadChildren: './tabs/tabs.module#TabsPageModule'

This is the initial route that is created for you when starting a new Ionic app using the tabs starter template. By specifying a loadChildren string (instead of passing a page class to component), the Angular router will load this file dynamically when the user navigates to the route. This JavaScript also gets split off from the rest of the app into its own bundle.

Below, we have the routes setup in the tabs routing module:

const routes: Routes = [
    path: 'tabs',
    component: TabsPage,
    children: [
        path: 'tab1',
        children: [
            path: '',
            loadChildren: '../tab1/tab1.module#Tab1PageModule'
      /// tab 2, tab3...

Each tab in this configuration loads its children lazily as well, meaning all the files for tab2 are not loaded until the user navigates to the tab2 page.

By breaking apart our app into separate lazily loaded chunks, we make it so that the browser doesn’t need to download, parse, and compile our entire app before the user even interacts with the first page. If our app was of significant size, this would greatly increase the initial load time of the app.

Using lazy loading can help your app load fast, however, if a user navigates to a new page, the assets will still need to be downloaded before the user views the page. There can be a small delay while this download happens, and it could be several seconds if on a slow network, giving your app a sluggish feel.

But lazy loading was supposed to make our app fast! Well, it did, at least for the initial page load. Now, let’s take a look at how to pre-load additional routes so they are available when the user wants them.

Optimizing Lazy Loading

When importing the Router module in the main app module, you can specify a pre-loading strategy to use. There are two that come out of the box with Angular:

  • NoPreloading: Does not perform any preloading of lazily loaded modules. This is the default behavior if no strategy is specified.
  • PreloadAllModules: After your app loads the initial module, this strategy will preload all the rest of the modules when the network becomes idle. In the Ionic starter templates, we set this option for you automatically.

To specify which strategy to use, set the preloadingStrategy parameter on the options object when setting up the router in app-routing.module.ts:

    imports: [
      RouterModule.forRoot(routes, { preloadingStrategy: PreloadAllModules })
    exports: [RouterModule]

The preloadAllModules strategy essentially loads the rest of the app in memory after the first route loads. Navigating between pages will now be quick, as all the routes and modules are loaded and ready to go.

While preloadAllModules is a sensible default for most apps, if your app is large enough, loading the entire thing might not be the best option. You might waste user’s bandwidth (if your app is a PWA) by downloading screens they might not visit. Your initial load might also be slower using preloadAllModules if your app is so large that it takes considerable time to parse and compile the JavaScript.

Fortunately, we can also define custom pre-loading strategies in Angular. Let’s take a look at how to set this up next.

A Simple Pre-Loading Strategy

We will start off by creating a simple strategy that we can use to specify which routes we want to pre-load up front. Using this strategy, we can ensure the most important parts of our app are primed and ready to be navigated to after the first screen loads.

To create this strategy, Angular provides an abstract class called PreloadingStrategy that you can implement. This class has one method you need to override, preload, which takes in the configured lazy route, and a parameterless function you can call to programmatically load the lazy route. It returns an observable of type any.

Note that only routes that are lazy (have the loadChildren property) are passed into Pre-loading strategies for processing.

To provide some determination on if we should pre-load a route or not, we can use the data property on the route definition to inform our strategy:

    path: '',
    loadChildren: '../tab2/tab2.module#Tab2PageModule',
    data: {
      preload: true

Now, let’s create a SimpleLoadingStrategy class to pre-load all lazy routes that have this data attribute.

import { PreloadingStrategy, Route } from '@angular/router';
import { Observable, of } from 'rxjs';

export class SimpleLoadingStrategy implements PreloadingStrategy {
  preload(route: Route, load: Function): Observable<any> {
    if (route.data && route.data.preload) {
      return load();
    return of(null);

To use this strategy, go into app-routing.module.ts and pass in the SimpleLoadingStrategy in the options. Also, since the custom strategy is a service, pass it into the providers collection as well:

    providers: [SimpleLoadingStrategy],
    imports: [
      RouterModule.forRoot(routes, { preloadingStrategy: SimpleLoadingStrategy })
    exports: [RouterModule]

Now, any routes with preload set to true will be pre-loaded and ready to use after the app initially loads.

This strategy was purposefully simple to show the basics of creating a custom pre-loading scheme. And while this basic strategy might work for some apps, it’s still not practical for a larger app with many routes and screens.

Now that we know how to create a pre-loading strategy, let’s take it one step further and create a more sophisticated one to meet a larger app’s needs.

A Selective Pre-Loading Strategy

An ideal pre-loading strategy might try to stay one step ahead of the user and pre-load any routes that the user might try to go to next. On a tabs interface, you could pre-load each of the tabs so they are fast and responsive when the users click between them. When a user visits a list screen, you could pre-load the details view so it’s ready to go.

With the above strategy in mind, we will create one that we can use to programmatically load routes from within our Ionic pages. This will give you the power to pre-load the appropriate pages you think the users will navigate to in the near term. We will also build this strategy in a way to keep our code clean and concise using TypeScript decorators. There is some setup to do, but the end result will be worth it.

First, let’s see how our route definitions will be set up. Instead of using a preload property on the route, we will simply give the route a name so we can reference it later. Setup each of your lazy loaded routes that you would like to pre-load like the following:

    path: ':id',
    data: {
      name: 'ItemDetail'

Our new pre-loading strategy will keep track of these routes, but instead of calling the load function immediately, we will store it in a dictionary so we can access it later:

import { PreloadingStrategy, Route } from '@angular/router';
import { Observable, of } from 'rxjs';

export class SelectiveLoadingStrategy implements PreloadingStrategy {
  routes: { [name: string]: { route: Route; load: Function } } = {};

  preload(route: Route, load: Function): Observable<any> {
    if (route.data && route.data.name) {
      this.routes[route.data.name] = {
    return of(null);

  preLoadRoute(name: string) {
    const route = this.routes[name];
    if (route) {

The preLoadRoute method takes in the name of the route, and (if it’s found in the dictionary) calls that route’s load method. This method is what will be called directly from our Ionic pages. PreloadingStrategies are just services, so they can be injected into our components like any other service:

constructor(private loader: SelectiveLoadingStrategy) {}

ngOnInit() {

When the above list screen loads, it will start pre-loading the ItemDetail screen.

We could end it there, but adding a bunch of loading code into our components complicates their logic and adds the loader dependency that isn’t very cohesive with the rest of the component. So, let’s clean up this logic by abstracting the loading code into a TypeScript decorator. Then we can add that decorator to each of the pages we want to use pre-loading on.

Create the PreLoad decorator:

import { AppModule } from '../app.module';
import { SelectiveLoadingStrategy } from '../util/SelectiveLoadingStrategy';

export function PreLoad(page: string): ClassDecorator {
  return function(constructor: any) {
    const loader = AppModule.injector.get(SelectiveLoadingStrategy);

    const ngOnInit = constructor.prototype.ngOnInit;

    constructor.prototype.ngOnInit = function(...args) {
      if (ngOnInit) {
        ngOnInit.apply(this, args);

This is a class-based decorator that takes in the name of the route you want to load (as defined in the route config). The loader property calls into Angular’s injector service (which we grab from the main app module) to get an instance of SelectiveLoadingStrategy. Then, we override the ngOnInit method. In our new ngOnInit, we load our route by calling loader.preLoadRoute, and then call the original ngOnInit method (if it exists).

In order to get access to the Injector service, we will expose that as a static property from app.module.ts:

export class AppModule {
  static injector: Injector;
  constructor(private injector: Injector) {
    AppModule.injector = injector;

Now, all that’s needed to pre-load a route from another page is to include the PreLoad decorator like so:

  selector: 'app-item-list',
  templateUrl: 'item-list.page.html',
  styleUrls: ['item-list.page.scss']
export class Tab2Page {

And, boom! No more loading code in our actual component classes.


As the web platform has matured over the past few years, many techniques have come along to help with performance. With more mobile devices being used today than ever before, it’s important to make sure your app is fast and responsive. When you start with a mobile-first mindset, you not only make sure your app performs well on these devices, but that it will perform even better on faster devices with better network connections.

In this post, we went over how to set up lazy loading in an Ionic Angular app, and how to use eager pre-loading to load additional views before the user needs them. Hope it was helpful!

While these techniques will take you a long way, there is still more that can be done to optimize your apps user experience. Interested in learning more? Head over to the docs or hit us up in the comments below or on twitter with your questions or suggestions.

Happy Coding!

Read more

Today, we’re excited to announce that Ionic React is now available in beta! Take a read below to understand more about this release and how to get started building with Ionic and React.

A Quick History

If you are familiar with Ionic Framework, you more than likely associate it with Angular. Historically, your assumption would be correct, as Ionic and Angular have been exclusively paired for a long time. However, with the recent release of Ionic Framework 4.0 this has changed: Now, Ionic’s core is able to adapt and expand to support many different frameworks. In previous posts, we mentioned that Vue and React were in the works…

Finally, however, we’re thrilled to share that the @ionic/react beta is here! 🎉

What is Ionic Framework?

If you’re already using React, but haven’t done so with Ionic, you might be wondering: What is the Ionic Framework and why should I care?

Well, let’s take a step back and just say, “Hello, we’re Ionic!” We’re about 5 million apps (and users) strong, with companies like Nationwide, Marketwatch, and Sworkit using our code.

We’re best known for our popular open source Framework, which at its core is a collection of UI components for building high-quality, cross-platform hybrid apps. All of these components are built with HTML, CSS, and JavaScript and can be easily deployed natively to iOS and Android devices, to desktop with Electron, or to the web as a progressive web app (PWA).

Why does this matter? Because the web is awesome and only getting better! Building with web technologies allows developers to leverage their existing skills for native development, while also depending on the stability of the web. Meaning, you don’t have to learn any special new tools, use a subset of CSS, or rewrite portions of your app when building with Ionic—It just works across multiple platforms, all using one codebase.

And, because the Ionic Framework is focused on the Component/UI layer, you can still keep your framework’s build tools and CLI. Our main goal is to care about how your apps look and behave, not how they’re built. In the past, Ionic Framework has been built only supporting Angular. While we still love and support Angular, we’re also opening up to other tools in the front-end ecosystem. This is why we’re excited to share the details about @ionic/react.

How to Get Started with React & Ionic?

Getting started is quite simple. Begin first with create-react-app, because we want you to use Ionic with React in the most familiar way. We also recommend using TypeScript in your app, something we recently wrote about on our blog if you need tips. While this is not required, we mention it because Ionic React ships with TypeScript type definitions, and it makes for an excellent developer experience.

 npx create-react-app my-ionic-app --typescript
 cd my-ionic-app

Ionic provides components to help with navigation like tabs and stack-based navigation. Right now, we support react-router so we will need to install it as a dependency along with @ionic/react.

npm install @ionic/react react-router react-router-dom @types/react-router @types/react-router-dom

Fire up your favorite code editor and open up App.tsx. Then replace the contents of the file with:

import React, { Component } from 'react';
import '@ionic/core/css/core.css';
import '@ionic/core/css/ionic.bundle.css';
import {
} from '@ionic/react';

class App extends Component {
  render() {
    return (
              <IonCardSubtitle>Welcome to Ionic</IonCardSubtitle>
              <IonCardTitle>Running on React</IonCardTitle>

export default App;

Run npm run start and you got yourself an Ionic React app!

Alright, that is pretty much it. From here, you can use Ionic Components as you wish. Now, let’s dive into the specifics of what components are available from Ionic.

What Does Ionic React Include?

We ship around 70 components with Ionic React. These components should cover the majority of use cases for building a mobile application—Including buttons, cards, menus, tabs, alerts, modals, and so much more. Next, let’s take a look at a few example components to gain a better understanding of what to expect when building with Ionic.


Button provides a clickable element that can be used in forms or anywhere that needs standard button functionality. They can also display text, icons, or both. Additionally, buttons can be styled with several attributes to look a specific way.

<IonButton onClick={this.props.dismissModal}>Cancel</IonButton>


Cards are just a standard piece of UI that serves as an entry point to more detailed information. A card can be a single component, but it is often made up of some header, title, subtitle, and content.

    Card Heading
    This is some card content.


A Modal is a dialog that appears on top of the app’s content and must be dismissed by the app before an interaction can resume. It is useful as a select component when there are a lot of options to choose from, or when filtering items in a list, as well as anytime you need the users’ input before you can continue.

  onDidDismiss={() => this.setState(() => ({ showModal: false}))}
  Some content to display in the modal.

Ionic & the React Ecosystem

Additionally, some people might be wondering how Ionic fits into the overall React ecosystem.

React developers have long used React Native to make native apps for iOS and Android. We think React Native is a good approach for native app development, but we have always believed in the web platform and think React developers will find many advantages in creating hybrid mobile, desktop, and progressive web apps with Ionic and React. We even see opportunities in using React Native and Ionic together. Stayed tuned for more info on that coming soon.

Next Steps for Ionic & React

It is pretty early for @ionic/react and there’s a lot more to test before we recommend it for production, though we’re happy to finally have this available for our community to try!

If you would like to see an example application that shows usage and provides more context around the best way to leverage each component, please take a look at our demo application built with @ionic/react, here.

To see the demo running live, click here.

We’ve always said that Ionic’s biggest asset is our large, passionate community, and now we need your feedback.

If you want to give Ionic a try in your next React app, please do so—we’d love to know how it goes! You can reach out to us on Github with your thoughts and updates, just make sure you mention React somewhere in the issue text when you do. Our issue bot will make sure it gets to the right people.

Now that you have more information about how to use ‘@ionic/react’, we can’t wait to see what you create. Happy building!

Read more

We’re thrilled to have recently announced the release of Ionic’s fourth major version, and its ability to work across all frameworks (or with no framework at all).

We’ve been overwhelmed with the positive feedback, and so far 4.0 has exceeded our expectations of what’s been possible with a rewrite. So, with the official Ionic Framework 4.0.0 release behind us, I figured now would be a great time to lay out our roadmap and immediate plans for next steps—a vision, if you will, for where we hope to take Ionic Framework in the near future…

Improved Desktop Support

As you might be aware, we’ve always had a ‘mobile-first’ mentality, focusing on providing a mobile and tablet friendly user interface and experience—something that, traditionally, has been difficult to pull off with only the web. However, as more developers and organizations have adopted Ionic as their UI framework of choice, the request for improved desktop support has been ever increasing.

As a result, our next big area of focus will gravitate towards improving the desktop experience with Ionic, while continuing to ensure its mobile-friendliness. Our first step will be to improve Ionic’s media queries by ensuring components adjust as expected when the browser’s real estate space expands or changes. Beyond that, we’ll ensure individual components adjust accordingly.

For example, the current ion-datetime component acts as expected on a mobile device, however, it looks a bit out of place on desktop. What’s great is now that Ionic is able to lazy-load components, on-demand, we’ll be able to instead load a different calendar component that is expected for a desktop UI. Other plans involve vertical range sliders and investigating if we should provide another mode following the desktop macOS patterns. Please feel free to submit, or add to any feature requests for desktop UI components that we should look into next.

Framework Integrations

With the initial 4.0.0 release, we also shipped @ionic/angular, which is based on top of the framework agnostic @ionic/core. The next step is to get both Ionic React and Vue up to the same quality as the Angular release. Throughout their beta versions we’ll keep them at 0.x.x, but once they’re ready for the official major release, we’ll then line them up with the same release version as @ionic/core.

Luckily, a vast majority of the work within Ionic is already available to each integration without any code duplication, and the framework integration itself is a minimal wrapper. In most cases, if a bug is found within a certain component, then the fix is immediately available to each integration. Same concept goes for any new features.

Another upcoming improvement is packaging up each Ionic component as a stand-alone, self-contained web component. By default, each component has the added feature to allow them to be lazy-loaded. But, we also want to ensure each component can act as a traditional web component, which allows Ionic to be consumed in any way possible.

Server-Side Rendering (SSR) and Prerendering

One enhancement that can drastically improve startup performance is server-side rendering, which renders components to static HTML on the server, or prerendered during a build step. For more information about the “why”, plus benefits and trade-offs, please see Rendering on the Web. Most frameworks provide a way of rendering their components without a browser, and Angular Universal is Angular’s way.

Upcoming versions of Ionic will provide methods to “hydrate” themselves on the server. In the case of Ionic Angular, this means we’ll be providing the IonicServerModule which can be imported within Angular Universal builds. The exciting part here is that the core server-side hydration code is reusable in each framework, and only a minimal wrapper is used at the final step. Expect to hear more about this soon!

Custom Web Animations

Animations within a web browser have come a long way since Ionic 1 was first released. In previous versions, even the game-changing requestAnimationFrame API wasn’t available on many mobile devices, resulting in the janky animations from the fallback use of setTimeout.

Ionic 2 and 3 saw many improvements due to our internal animation library, which actually continues to power 4.0’s page transitions. However, this animation library has been intentionally kept as an internal tool knowing that we’ll soon be able to migrate to the standardized Web Animations API.

By following a web standard, it’ll make it easier for developers and third-party libraries to provide custom animations for Ionic. Making this transition has long been in the back of our minds, and we hope to start providing even more animation options, soon.

Improved Stability and Predictable Releases

With the core team focused on refactoring Ionic and shipping 4.0, it was often difficult to triage issues that came in. Now that the API has stabilized, and the refactoring is behind us, we’ll be able to dedicate more time to handling issues reported by the community. This effort can already be seen from our cadence of patch releases since 4.0.0 was released. At the top of our list, right now, are page transitions, navigation fixes, and keyboard issues.

Patch releases, meaning any release that fixes existing features, are scheduled to ship every two weeks. To see which issues we’re currently working on, or what is next in the queue, please see our Github Project Board. Major releases will not be released any sooner than six-months from the last major release.

Let’s Build Some Apps!

Obviously, we’re pretty excited about Ionic Framework and what the future holds for Ionic developers! And, we hope this update gave you a little glimpse into all the next steps to come. We are also beyond grateful (THANK YOU!👏🏽👏🏽) for the Ionic community and their support throughout this process.

As always, we’re open to your feedback so please feel free to hit us up on Github, Slack, or the community forum.

Happy building with Ionic Framework 4.0! 🎉

Read more

This post is contributed by Kevin Ports, designer and front-end developer at Ionic. He’s passionate about pixels, code, and the space in between.

If you’re building a handful of apps in a startup or small business, delivering a consistent user experience across teams and projects is relatively easy. But if you represent a global corporation with hundreds of developers and designers distributed throughout the world, enforcing a set of design standards can get messy. Having a Design System can help.

A Design System is a centralized library of components that can be shared across teams and projects to simplify design and development while ensuring consistent brand experiences, at scale. In some cases, a Design System is nothing more than a collection of visual design specs. But for the purposes of this post, we’re going to talk about Design Systems as a collection of real-code components that front-end developers drop in their projects like Lego blocks, to quickly build new user experiences without having to worry about the core design of each component.

The HubSpot team, a pioneer in Design Systems, explains why this is valuable:

“That’s the beauty of building a design system. By deciding on a detail once, you free up your entire product development team to focus on solving actual customer problems.”

Of course, for HubSpot, it took 34+ designers and over two years of work to perfect their Design System. For most businesses, that kind of commitment just isn’t feasible.

Enter: Web Components. In this post, I’ll explain the five reasons why Web Components are the perfect way to quickly bootstrap a new Design System, with a future-proof design that will benefit you for years to come.

1. They work everywhere

Web Components use a set of standardized APIs that are natively supported in all modern browsers. These UI components run on nearly all mobile devices and desktop browsers today.

Through the use of a hybrid mobile framework like Ionic, you can deploy Web Components across just about any platform or device, from native iOS and Android apps, to Electron and desktop web apps, or even Progressive Web Apps.

For anyone building a Design System, the big benefit of this is that it finally addresses the need for a single source of truth—one standardized library that works everywhere.

2. They’re easy to customize

By definition, a Design System implies a customized collection of UI components that match your specific brand standards and style guidelines. While there are no limits to what your designers can conceptualize, implementing those customizations in some development environments and frameworks can be tricky.

For example, let’s say you’re using React Native to build a mobile application and you want to change the border around a button. If React Native doesn’t open up customization for that border, you’d be unable to modify it without going directly into the native implementation to manually program it. That doesn’t mean you can’t change the border, it just means it will be harder to do so in some situations. Check out our guide comparing Ionic and React Native for more on this topic.

In contrast, Web Components can be styled and customized to match any design pattern you want to achieve. With the simple use of HTML, JavaScript, CSS, you can build a library of UI components that match whatever your designers dream up. You can start with a ready-made Web Component library like Ionic and then customize from there, or use a tool like Stencil to build your own Web Components from scratch.

3. They help drive adoption

A Design System is only valuable to the extent that it’s actually adopted by your team. Having a brilliant style guide that is widely praised but always ignored is of no value. Web Components can help to address this challenge in a few key ways.

First, the simplicity of Web Components (just a few lines of HTML) makes development faster and easier. And, because they run on any platform or device, a single library will serve any development project. All of that adds up to a great developer experience. And happy developers are more likely to adopt your Design System.

Second, if you’re using Ionic’s library of components, we offer solutions to help drive adoption, like building your own collection of robust developer docs (modeled after our own world-class Docs) and tools like Studio, which offers a customizable library of components that developers can drop right into their development project.

4. They’re future-proof

Perhaps the most appealing benefit of Web Components is that they liberate us from the highly volatile landscape of front-end frameworks and tooling. By using a consistent set of web standards, Web Components are not dependent on a specific front-end framework like Angular, React, or Vue. Sure, you can use Web Components with any of these frameworks, and we encourage you to do so in order to take advantage of the many benefits they provide. But, the great thing is that you won’t be dependent on that framework for your components to work.

This is awesome news for development teams. First, as much as we love the hot frameworks of today, who knows what tomorrow will bring? By choosing Web Components, you insulate yourself from the threat of tech churn and no longer have to worry about picking the right horse.

Second, you will give your development teams the flexibility to choose the underlying frameworks and tools that they prefer. One of the great challenges of implementing a universal Design System is getting all of your development teams to standardize on just one set of technologies. Given the varied interests of most developers, that pretty much guarantees that someone will be unhappy because their tool of choice wasn’t selected. With Web Components, each team can use what works best for them, giving them complete freedom to use the tools they love—today and tomorrow.

5. There are plenty of WC libraries to leverage

Building a Design System from scratch is no easy task. I already mentioned that it took the HubSpot team two years and over 34 designers to build their Design System.

The great news is that there are already a number of Web Component-based UI libraries out there for you to start with: Ionic being one of the biggest and most well known. In fact, as our CEO, Max, argued in his post from a few weeks ago, Ionic is a Design System. You can start with our library of components and easily customize them to suit your needs.

How to get started

If you’re ready to start building a Design System with Web Components, start by checking out our library of totally free, open source UI components. Or schedule a Strategy Session with one of our team members to see how Ionic can help you build a customized Design System that your developers will love.

Read more

© 2020 Extly, CB - All rights reserved.