By now, you likely have heard the news that Ionic 4.0 is here! If you’re currently maintaining an older Ionic app though, you might have concerns about the challenges of upgrading to the latest version. While there will be some work involved to migrate over, there’s never been a better time to do so. Take a look below for some of the benefits of upgrading to Ionic 4.0, plus links to our migration guides to ease the process.

Future-Proof Apps

The Ionic Framework has been rewritten from the ground up for the last time: Now, all UI controls are web components, built on open web standards. As a result, Ionic components are no longer tightly coupled to Angular, which opens up compatibility for current favorites like React and Vue, or any JavaScript framework that becomes popular in the future. This also means that future versions of Ionic after 4.0 will be much easier to update given the underlying technology will remain the same.

Another exciting change is that Ionic is embracing framework-specific tooling. Ionic 3 has custom command line and build tooling, as well as custom router implementations, which has often led to some churn and confusion. However, now that Ionic embraces the tooling and architecture of each specific framework, it’s become much simpler to integrate our technology. Using Angular? Use the Angular CLI. Using Vue? Use the Vue CLI, etc. It’s the best of both worlds. So, as your framework of choice evolves, you get the latest and greatest tooling, leaving more time to focus on what matters—adding more value to your app.

Angular is Still a First-Class Citizen

Angular fans, have no fear! Just because Ionic 4.0 broadens our framework reach, doesn’t mean we are leaving it behind. In fact, Angular will continue to be a major focus for us in 2019 and beyond. The best part is that you’ll be able to reuse the majority of your Angular-specific code when updating to Ionic 4.0. Your services, for example, should port over without modification (assuming they aren’t depending on any Ionic-specific functionality). Ionic 4.0 supports Angular 7+ today and will closely follow future major Angular versions.

Truly Cross-Platform

Write and maintain one codebase that will run on any device or operating system across mobile and desktop. This includes native iOS and Android apps, as well as Progressive Web Apps, and even Electron-based native desktop apps. Ionic apps don’t just run on any platform, they are specifically designed to look and feel native to the platform that they run on. The benefit of this approach is that it drastically cuts down on the time and cost to create multi-experience apps that run on iOS, Android, desktop, and more.

Migrating from Ionic 1.0 to Ionic 4.0

This migration involves moving from AngularJS (aka Angular 1) to Angular 7+. There are many architectural differences between these versions so some of the app code will have to be rewritten. The amount of work involved depends on the complexity and size of your app. The upside is that for the most part, the Ionic UI components you know and love from Ionic 1 haven’t changed much.

In terms of a strategy for beginning the migration, identify a time frame (perhaps one or two sprints) to get started. We recommend feature-freezing the Ionic 1 application and getting the code in order: Fix any major bugs, eliminate tech debt, and reorganize as you see fit. Then, identify which features to migrate over and which to abandon. Then, create a new Ionic 4 application and begin porting features over. Once the team is comfortable that the new app is stable, you can shut down the Ionic 1 app.

Migrating from Ionic 3.0 to 4.0

Migration off of an Ionic 3 app will require less work than an Ionic 1 app, but you’ll need time to successfully complete the transition. Begin by reviewing Angular’s release guide to gain an understanding of the changes from Angular 2+ to Angular 7+. Next, generate a new Ionic 4 project and start by copying over various parts of your Angular code such as services, providers, pipes, and components. Work on one feature at a time, from top to bottom, testing as you go.

Two areas that received the most changes are navigation and lazy loading. Instead of using Ionic’s own NavController, we integrate now integrate with the official Angular Router. By embracing the official tooling of each framework, a more consistent and dependable routing experience is achieved. Since navigation has changed, the mechanism for lazy loading has also changed in Ionic 4. Now, this is accomplished using the loadChildren method of the Angular router.

So, what are you waiting for? Check out the full migration guides and begin migrating to Ionic 4.0 today.

If your team would like assistance with the migration, please reach out to us for more information! Ionic offers Advisory Services, which includes Ionic 4.0 training, architecture reviews, and migration assistance.

Read more

This post was written by community member, Chris Woolum. Chris is a .NET/JavaScript developer and, currently, a Chief Architect at Turnoutt, Inc. He’s passionate about software development and leveraging emerging technology. Follow him on Twitter @chriswoolum.

It was almost a year ago at Ng-Conf, when I sat in on a session about TypeScript. One of the speakers that caught my attention was Alex Eagle, a software engineer at Google on the angular-core team, who shared an update about Google’s plan to integrate a new version of TypeScript internally before releasing it to the public.

This was of particular interest to me at the time because I had been working with our architecture team at SpaceX and the adoption of new architecture components had always been a pain point for us. When I discussed this issue with Alex, he explained that his team had been using TSLint fixers (more on those in a bit) to roll out changes to their projects’ code, which got my wheels turning on how I could implement TSLint in my own projects.

During this time, Ionic 4 Beta had just been announced and while the breaking changes list wasn’t much compared to the Ionic 1 to 2 upgrade, it still took a few hours for the migration to complete and left a bit of room for error in what was a fairly small app. It was during this period that I decided to test out using TSLint fixers to perform this migration for me.

Using the fixers

I’m happy to say what came out of this endeavor was the creation of the Ionic 4 Migration tool, which you can use similarly to how you would use the normal TSLint rules. Here are the steps:

  1. Upgrade your project to use the latest Ionic version, which was RC1 at the time of this blog post draft. You should now have a bunch of errors if you try to compile.
  2. Install the rule-set using npm i -D @ionic/v4-migration-tslint . You will also want to add a file to the root of your project named ionic-migration.json and add the configuration below.
  3. Run the analyzer to identify all of the changes you will need to make in your code using tslint -c ionic-migration.json -p tsconfig.json. Bonus: We implemented a bunch of fixers to automatically correct most of the breaking changes, which you can use by adding the --fix flag to the end of the command. (Tip: Be sure your project is backed up or stored in source control just in case anything unexpected occurs.)

Limitations of the tool

Unfortunately, there were still a few changes that we were unable to automate—A big chunk of which had to do with CSS changes. This is because stylesheets are a bit more flexible, making it hard to identify a common pattern to apply across the migration tool. We also had some cases like the Ion Menu Toggle where the DOM changes were incredibly complex and had to be fixed on a case by case basis.

Lastly, during this process, there were some breaking changes where methods returned promises. While the documentation specifies that async/await should be used to execute this, we found that people were using .then() instead or they would return the promise directly from their method instead of waiting and returning the result. Because the syntax for handling promises can be so varied, we decided to not implement a fixer for these rules, and instead rely on warnings.

Overall, we found these limitations to be pretty minor and most of the tedious changes should be covered with this tool. To see what changes are covered by fixers, head to the repo page to view all of the rules with each rule containing a link to its section of the Breaking Changes page.

How does it work?

This tool is built on top of TSLint which is a static analysis tool that takes advantage of the TypeScript AST(Abstract Syntax Tree) parser. We also used Codelyzer, which is an Angular-specific implementation of these rules and includes some very helpful utilities for parsing Angular-specific components, if needed.

Each rule generally has a single target. For example: In the case of ion-button, we had to find places where ion-button existed as an attribute and then replace the element on which it was annotated. We did this by first visiting every element in the DOM tree and looked for any attributes that matched ion-button. If we found a match, we extracted the element’s content and replaced the element with a new ion-button, which had the contents of the previous element.

Ready, set, go (upgrade your app)!

I look forward to seeing how others use this tool and hope it will help you or your team’s projects when converting to Ionic 4.0. And, if you’re interested in trying to build out some of the remaining fixers, please check out the repo and feel free to submit a PR!

I’d like to thank Dan Imhoff and Mike Hartington for their help on this project—Thanks to them, our team was able to get this project over the finish line quickly and easily. Can’t wait to see what you guys build. Happy coding!

Read more

Few things in the frontend world are as hot as Design Systems, the idea of building a design spec or library of reusable components that can be shared across a team or company. Design Systems enforce style and branding guidelines, reduce design fatigue for engineers, and consolidate component engineering to one single set of components and a team that builds them. Basically, they help teams manage design at scale.

Smart companies like Hubspot, Salesforce, and Intuit have invested considerable resources in not only building their own internal design systems, but also sharing their knowledge with the rest of the frontend design world.

I’m not going to convince you that Design Systems are valuable since the proof is pretty easy to find. Rather, assuming you agree your company needs a Design System, I want to talk about the hard decisions that need to be made in order to build one.

Design or Code?

First, you need to decide if your Design System will be just a design specification, or a set of real code components.

There are essentially two major schools of thought when it comes to Design System implementations:

The first is design spec-focused, where designers build assets in a prototyping/UX tool like Figma or Sketch, and then put those design assets and concepts in a guide that specifies how engineers should implement those designs, but without any accompanying engineering implementation. The most famous example of this is Google’s Material which exists first and foremost as a design specification, with specific platform implementations of that specification made available as derivative works.

The other school of thought is that your Design System should be a real code asset that engineers can pull from as they build their apps. Generally, these components are built in a cross-platform, web-first fashion so they can be used across all the platforms your team cares about.

For most organizations, having only a design spec isn’t going to be enough, and leaves too much onus on engineers to faithfully implement the spec while also building apps with those components. Instead, teams will be more successful with a shared library of real code components a single team can maintain and any app development team can pull down and use without having to think about the actual design and implementation of those components.

How do I build a real code Design System?

Once you decide to build out a set of reusable components instead of just a design spec, the question then becomes how do you actually build that?

In the web world, there are various ways to build a set of shared components. One of the earliest was the approach popularized by Bootstrap, where the right incantation of HTML markup combined with CSS classes and jQuery results in a structured framework for frontend design. As most Bootstrap users know (and we know, we built a design tool for Bootstrap) that process can get unwieldy and leaves too much room for mistakes.

Over the last five years or so, a better option emerged: building a Design System in a specific frontend framework like Angular or React or Vue. In this approach, components could be built and shipped in such a way that an engineer just had to import and use them, and often could not make any modifications to the underlying components or make any mistakes using the components.

Why You Should Reconsider Building Your Design System on Angular, React, or Vue

While building a Design System in Angular, React, or Vue is quite a bit better than the too-open-ended approach used in Bootstrap, it has one major flaw: it only works if the rest of your company has standardized on that single framework!

While these frameworks are wonderful for building apps and most teams should be using one, they might not be right for most enterprises when it comes to building a set of components that will be distributed across teams, many of which are making their own technology decisions or will likely in the future.

Additionally, given that these frameworks evolve quickly, app dev teams may decide to move to newer versions of the framework independently of other teams, which could introduce compatibility issues with the component distribution.

It really has nothing to do with the merit of these frameworks, but the simple fact that a team that picked, say, Angular, can’t just use React components in a first-class way. Even if your company has standardized on a single frontend tech stack, we all know that the industry changes quickly and what seemed like a sure-fire choice today could change significantly in a few years.

One Component Model to Rule Them All

If Angular, React, or Vue isn’t the right choice for building a set of reusable components, then what is?

The answer is Web Components, a set of standardized APIs available in all modern browsers that makes it possible to build rich, JavaScript-powered components, and distribute them as simple HTML tags that any web developer or designer can use regardless of the frameworks or libraries they choose to use on top.

Web Components are standardized technology, and are natively supported in modern browsers. These components run on nearly all mobile devices and desktop browsers today, and since they are baked right into the browser, you don’t need a specific frontend framework to use them. For browsers that don’t natively support them, polyfills are available to fill in the gaps (more on that in a minute).

Any examples?

Web Component support is relatively new (2018 being the first viable year), so teams looking to standardize their Design System on top might struggle to find examples in the wild.

One big example is Ionic Framework version 4, the web-based UI Design System that helps teams build apps for iOS, Android, Desktop (Electron), and the Web (Progressive Web Apps, etc.).

Historically, Ionic shipped as a set of pre-made AngularJS and then Angular 2+ components. Any team using AngularJS or Angular could import Ionic’s components and use them in their app. This worked well while Angular was the only game in town, but the frontend ecosystem quickly evolved and suddenly teams were using way more than just Angular. Ionic found itself siloed and unable to help the largest number of web developers build apps.

To solve this problem, the Ionic team decided that the right decision for a Design System like Ionic was to not “bind” to a specific framework, requiring any users of Ionic to use that framework in conjunction with it. Rather, the components should be built using technology that would work in any framework, and ideally be built on top of web standard APIs that would endure for decades.

What’s fascinating is how similar Ionic’s problem is to the one we hear from teams at companies that also built their own design systems on top of a single framework. What made sense a few years ago ended up being the wrong solution as the frontend ecosystem evolved and their app development teams wanted to try new frameworks or even upgrade their existing framework.

We believe so much that Web Components are the right solution to this problem that we’ve invested in building out tooling like Stencil to make it even easier to build and distribute Design Systems with Web Components. Stencil not only makes it easy to build Web Components, but it also automatically manages polyfills for browsers that need them, along with grouping components into “collections” that can be loaded together to improve performance. It also produces components that are very small in terms of file size and exceed performance standards for the modern Progressive Web App era. Unlike a framework, stencil simply provides a structured way to generate Web Components for the purpose of building Design Systems, it likely won’t be used as the “framework” for the rest of your app.

But don’t just take our word for it. There’s a quiet surge in real-world usage of Web Components for design assets, and it’s clear that this is an approach that is highly appealing to top technology companies (take GitHub, for example).

What about Angular Elements, Vue Web Components, etc.?

Two exciting projects in the frontend world are Angular Elements and Vue’s Web Component output support. These projects allow Angular and Vue to output Web Components with the framework being “self-contained” in the components that are generated or to link with the framework externally.

I am optimistic that these projects will provide a good middle ground for teams that have existing component systems built on these frameworks, and wish to “unlock” them from the framework for teams that wish to consume the components outside of these frameworks.

Something to keep in mind with these projects: currently, they either bundle in the framework itself (Angular), or require the framework to be available as a global variable (Vue). To us, that makes them not an ideal choice for Design Systems that wish to be as lean and framework-agnostic as possible. Additionally, these projects do not automatically manage polyfills for clients meaning you’ll need to manage those yourself and also make sure you only serve them to clients that need them.

That being said, we are optimistic these projects will improve over time and make these frameworks good choices for Design Systems, despite not being ready today.

Build your Design System with Web Components

At Ionic, our business is building a leading real code Design System that teams can use to build cross-platform apps using standardized web technology. Every day we talk to more and more enterprises that want to “build their own Ionic” on top of Ionic, and come to us for help on how to do that.

As we talk with teams, it’s clear that the old approaches to solving this problem weren’t scaling. They wanted to invest in a component model that would work with any technology their teams chose to use and would be stable and last for many years to come, regardless of what happens in the frontend ecosystem.

When we bring up using Web Components to solve that problem, these teams are often intrigued and remark that this is exactly what they are looking for.

If you’re also intrigued, getting started building with Web Components is easy:

Getting Started with Web Components

There are many tutorials for building with new Web Component APIs. We recommend starting with Google’s Custom Elements overview for an introduction to the low-level APIs involved. After that, check out Stencil, LitElement, or SkateJS for some tools/libraries that simplify using the low-level APIs.

Build your own Ionic with Ionic

Finally, because Ionic Framework 4 is itself a Design System, it’s possible to use it as a base for your own Design System. And because it’s built on Web Components, it has all the benefits described above.

That means instead of investing considerable resources in building out a custom set of components and optimizing them, you can use the industry-leading Ionic Framework 4 as a base for your own Design System. We’ve invested a ton of time in exposing theming and customization features for each component, making it easy to modify and quickly apply your branding without having to break open the components to do it.

Plus, Ionic Framework 4 components work on iOS, Android, Desktop with Electron, and anywhere the web runs (like Progressive Web Apps). You get all of that for free.

If you’re a team or company that wants to build their own cross-platform design system on top of Ionic Framework, we can help! Get in touch and we’d be happy to see if Ionic can help your team build and scale a Design System using open web technologies and Ionic Framework 4.

Regardless, we hope you’ll consider building your next Design System with Web Components so all web developers can use it no matter what frameworks and libraries they choose to use.

Read more

Today I am thrilled to announce the 4.0 release of Ionic Framework, lovingly known as “Ionic for Everyone.” 🎉

Ionic 4 represents the culmination of more than two years of research and hard work transforming Ionic from “mobile for Angular” into a powerful UI Design System and app framework for every web developer in the world.

There are so many things to talk about with this release, but first I’d like to talk about how we got here.

The Angular Years 🕰

Back in 2013 when we started working on Ionic Framework, we sought to build rich JavaScript-powered components for building quality mobile apps with web technologies, and distribute them as custom HTML tags that any web developer could use in their apps.

ionic 1 and AngularJS

Unfortunately, there was no standard way to do that back then, so we jumped on the next best thing: AngularJS directives. We loved that you could build custom directives in AngularJS and package up all the complexity we needed to offer native-quality components into an easy-to-use custom HTML tag. Any AngularJS template that used that tag would magically bootstrap the component and run it as if it was natively supported right in the browser. Our early experiments with AngularJS were so successful we stopped looking at alternatives and went all-in.

When Angular 2 was announced, we knew that in order to stay relevant in the Angular world, we’d need to port Ionic to it. So, we shipped Ionic 2 and 3 to do just that. I’m so glad we did, as Ionic 3 has been the most successful version of Ionic yet.

Oh, if only the story ended there!

Frontend Churn 😵

Fast forward to 2019, and the frontend landscape looks nothing like it did back in 2013.

To start, AngularJS has been replaced by modern Angular. React, which wasn’t even on our radar back then, has achieved massive popularity. New frameworks like Vue have grown even more quickly and serve to remind us that the status quo is anything but.

frontend javascript framework churn

So much change happened so fast that “frontend churn” became the bane of a generation of web developers.

At the end of 2017, we started asking ourselves if our original dream was worth revisiting. It was clear that frontend developers would never settle on any specific frontend framework or libraries, so to assume otherwise was futile. At the same time, we were frustrated that Ionic could only be used by those that embraced Angular. And, while we loved Angular, we hated the idea that Ionic wasn’t achieving its original goal of being a toolkit for every web developer in the world.

web components

Luckily for us, something wonderful had happened in the frontend world between 2013 and 2018: Browsers had converged on a standardized component model, allowing developers to define custom HTML tags and easily distribute them to other developers. This collection of APIs become known as Web Components, and they were everything we had dreamed of back in 2013.

We started experimenting with turning Ionic into a set of Web Components in 2017, and we were blown away by how capable and efficient they were. In our minds, it was clear Web Components would be the way UI libraries, like Ionic, would be distributed in the future. So, we took a big bet and started porting all 100 of our components over.

Thusly, Ionic Framework 4, “Ionic for Everyone,” was born.

“Ionic for Everyone” 🌎

With today’s release, Ionic Framework is now distributed as a set of Web Components using the Custom Elements and Shadow DOM APIs available in all modern mobile and desktop browsers.

ionic globe

This means that practically every web developer in the world can now use Ionic’s components in their mobile, desktop, and Progressive Web Apps—just by using Ionic’s custom HTML tags in their app.

On top of that, because Ionic now targets standard web APIs instead of third-party ones, developers can rest assured that Ionic’s component APIs will stay stable for many years to come instead of falling victim to frontend and framework churn.

No longer just “mobile for Angular,” Ionic is now a modern, web-based Design System and app framework for every web developer no matter what tools and frameworks they choose to use on top.

This is the dream we’ve had since 2013, and, after six years of hard work and making some big bets on promising new technology, it’s finally a reality.

The Best Ionic Yet ⚡

Not only is Ionic 4 the most accessible and future-proof version of Ionic we’ve ever built, but it’s also the fastest and most complete.

Every one of the nearly 100 Ionic components has been evaluated for performance, theme customizability, and platform look and feel. This includes a complete iOS and Material Design refresh for each component to match the latest standards on iOS and Android.

ionic 3 to 4 performance comparison

Since each component is now a Web Component built with our new Web Component compiler project Stencil, Ionic components are optimized for load and render performance, helping Ionic apps reach the coveted 100/100 score* on Google’s Lighthouse benchmark tool (*heavily dependent on the framework used with Ionic).

We’re going to be publishing more extensive data and benchmarks comparing Ionic load/render performance across various frameworks, but the graph above shows significant improvements on First Meaningful Paint for developers using Angular with Ionic 4, and this is just the beginning.

Finally, we’ve dramatically improved the design for all new app starter templates, to help developers get to great design faster than before.

Performance for World-Class Progressive Web Apps

Progressive Web Apps are all the rage right now, and Ionic 4 was designed out-of-the-box to be the best UI framework for building high-performance PWAs.

For Ionic to reach performance standards set by Google, new approaches for asynchronous component loading and delivery were needed. To achieve this, we spent a year building out a web component pipeline using Stencil to generate Ionic’s components, ensuring they were tightly packed, lazy loaded, and delivered in smart collections consisting of components you’re actually using.

Today, Stencil-built components lead the pack in terms of bundle size and load performance, and Ionic 4 benefits from all of that.

Of course, you’ll likely be using Ionic with a separate frontend framework like Angular or React, so we will be publishing some guides shortly about how to pick the right technologies to reach Progressive Web App performance standards, since reaching performance standards with Angular and React requires some additional work.

Built for Customization 🎨

One of the biggest changes under the hood is the move to using native CSS Custom Properties, also known as CSS Variables, in each component.

v4 dark mode theming

CSS Custom Properties make it possible to expose a “public theming API” that provides structure to developers that wish to brand and customize Ionic’s components, in a way that supports easily upgrading to future versions of Ionic without introducing compatibility issues. CSS Custom Properties also provide a standardized way to theme Ionic apps independent of the frontend framework used in your app.

This means developers no longer have to modify the internals of Ionic’s Sass/CSS styles or inspect to find internal classes to override. Modifications now happen by targeting Ionic’s public theming API through the published, documented CSS Custom Properties.

This represents a significant improvement over the style modification process web developers have had to work with, in the past, which often restricted developers from being able to upgrade to new versions due to reliance on internal style modifications.

Revamped Documentation 📖

One of the things Ionic developers often tell us is that Ionic has some of the best developer documentation around.

We take incredible pride in that, but we also knew that our old docs could be improved in a number of significant ways.

Today we’re launching version 0.5 of a major revamp for the official Ionic Documentation, which along with dramatically improved performance also includes a simpler design, focused on content, and an easier-to-navigate organization.

ionic docs

We’ve also consolidated the API reference and the component reference, reducing the number of pages developers have to flip between to get the information they need.

We’re not quite done with the final version of the docs, but we’re releasing a version 0.5 today that has most of the content and API references filled out.

Check out the new work-in-progress docs.

Perfect for your Design System 👩‍🎨

With new theming capabilities and a focus on framework-agnostic web components, Ionic is ready to be the foundation for your own Design Systems, essentially building your own Ionic on top of Ionic.

design modes

We dug into this on the blog last week, so take a look if you’re interested in building a cross-platform, web-standards based Design System for your company.

Use your Framework’s Tooling 🅰

Back when Ionic 2 was built on top of Angular and modern JavaScript tooling was just emerging, Ionic had to figure out and build a fair amount of tooling in order to compile and bundle modern Angular apps. Not to mention, solutions like Angular Router were still in development and were not yet ready for Ionic to use for navigation, so we had to build our own.

angular cli

With Ionic 4, we now use your framework’s official tooling for building, bundling, and routing, so you can get the most out of your framework’s ecosystem and we can focus on what we do best.

That means you’ll use the Angular CLI when using Ionic with Angular, Vue CLI with Vue.js, and so on.

Read more about this on our blog.

React and Vue, too 🤯

Ionic is moving to a “bring your own framework” model, and because Ionic’s UI controls are now based on Web Component APIs, they can generally work out-of-the-box in all major frontend frameworks (Angular, React, Vue, etc.).

ionic react vue

However, Ionic also needs to integrate with a framework’s routing system for a first-class native navigation experience, so we still have to ship framework-specific functionality. Additionally, developers on each framework expect things to work a specific way that sometimes deviates from the way they are done with plain Web Components (like React devs expecting MyComponent vs my-component).

Our official Vue.js and React bindings are currently in alpha and you can expect them to be a big part of the Ionic 4 developer experience going forward. We are incredibly bullish on these two frameworks and expect that the majority of Ionic developers will eventually build apps with one or both.

If you’d like to try the alpha versions today, take a look at the React README and the Vue README in our repo. Don’t worry, we will make it way easier to use these projects soon.

Lastly, we dug into how Ionic Vue was created on our blog. Take a look if you’re interested in how this project came to be.

Roadmap 🗺

Roadmap

Over the last two years, we’ve been intensely focused on making Ionic the most future-proof, framework-agnostic, high-performance, and standards-based UI framework ever.

Now that 4.0.0 (codenamed Neutronium) is out and production-ready, we’re thrilled to be able to invest some more time in improving what you love most about Ionic: Our components.

Next on our roadmap includes desktop-specific UI support to expand the types of desktop apps that can be built with Ionic, improved keyboard scenarios (chat apps, etc), better theming options, richer animations, and more. Along with improvements to the core of Ionic, expect more tutorials and guides on migrating to and building with Ionic, now that we feel confident going all-in on this brave new version of Ionic Framework.

Additionally, we are excited about making React and Vue support first-class in Ionic and expect that these frameworks will become a significant percentage of the frameworks used in Ionic apps, so watch for updates on those in the near future.

We will also be working to incorporate our new Cordova alternative Capacitor as an option for new Ionic projects in the CLI. Stay tuned for more on that this year.

Thank you ❤

Before we leave, we want to extend a huge “thank you!” to the entire Ionic community. We’ve been teasing Ionic 4 for a while now, and in an ecosystem filled with change and uncertainty, we are grateful to have had your trust and patience throughout the entire process.

We also want to thank the Ionic community members who took a big bet on Ionic 4 and shipped real apps even though it was alpha and we said very clearly it wasn’t production ready 😉.

Teams like Sworkit, built and shipped entire new versions of their app with Ionic 4, and we’ve been working directly with enterprise teams that are doing the same. With Ionic 4 going into a production-ready state, the pressure release valve has been opened and we are excited to see other teams start building with it.

Last but not least, we want to thank the wonderful contributors that have stepped up to help Ionic 4, whether that was by submitting PRs, helping test new releases, or creating educational content for the community: None of this would be possible without your help.

Getting Started and Migrating

Getting started with Ionic 4 is easy. Follow the Getting Started Guide, or create a new project directly from the Ionic CLI:

npm install -g ionic # Update the Ionic CLI
ionic start awesome-app

For teams looking to migrate from an older version of Ionic to Ionic 4, we can help! Along with a fully-supported version of Ionic Framework for Enterprises building mission-critical apps (including Cordova/Capacitor native plugin support!), we have Advisory Services available for teams that need assistance. Plus, we’ve also published a Migration Guide for self-directed migrations, along with some tools to help ease the process.

Read more

We’re excited to share with you the results of our second annual Ionic Developer Survey with input from more than 10,000 community members.

The full dataset is available to view here alongside our own insights and analysis.

But before we dive in, we just wanted to say how much we appreciate the community for your consistent support. We think the results of the survey will be valuable for both developers and the vendors featured, and we couldn’t have uncovered these insights without your participation—so thank you!

There was a lot of interesting data to parse through in the results, but our takeaway is clear: Investing in web development, and the skills associated, will pay off for years to come.

The Big Three: Angular, React, Vue

While Angular is the most popular JavaScript framework used by developers who took the survey today, React and Vue usage ranked highly in 2018 with increased adoption expected to continue in 2019.

Regardless of your preferred framework, we believe each one is a solid option for any serious development project. The important thing to note here is that framework fatigue is waning. While new ideas for frameworks are still cropping up every day, developers seem to have rallied around these three as the top contenders.

Historically, Ionic has been exclusively Angular-compatible. However, as we introduce versions of Ionic that support Vue (currently in alpha) and React (shooting for early summer), we expect to see the mix of Ionic developers surveyed to diversify in their framework usage, perhaps shifting more towards these Angular alternatives.

Cross-Platform Development Makes Significant Gains

Perhaps unsurprising for our audience, cross-platform development continued to prove popular in 2018. In fact, the percentage of developers building purely with native tools dropped from 20 percent last year to 8 percent in 2018. More than half of those surveyed this year (52 percent) are building exclusively with cross-platform tools like Ionic, React Native, and Xamarin.

The evolution of cross-platform development brought about the rise of Progressive Web Apps (PWAs) in 2018 with 61 percent of developers surveyed sharing that they have already built a PWA or that they plan to build one this year.

For a while now, consumers have been trained to search app stores for new software. That’s probably why the results show that PWAs are becoming a complement to, but not replacing, native apps. That’s OK though, as PWAs are just one part of a growing, but unified “digital experience” that spans across devices.

What do you see?

There’s a lot more insight where that came from, so we hope you’ll check out the full survey analysis here.

We’re excited to see what your takeaways are and hope you enjoy viewing the results. We couldn’t have done it without you, so, again, thanks to all of you who made it possible!

Read more

© 2020 Extly, CB - All rights reserved.