Previously on Web Frameworks, we looked at how various frameworks deal with the concept of applications. Akin to listening to the whole album, we got a sense of how the frameworks pull it all together. In this post, we explore what are common types of applications and how the frameworks we are considering might work in those use cases. If you are going to throw a party, you want to know if your favorite band is going to set the right mood.
In this post, we are looking at the aspects of mobile applications, content management or portals, consumer-facing applications, and business applications. We will discuss the common needs of each of these and then how the compared frameworks meet those needs.
This is part of a series on web frameworks. If you’ve missed our previous posts, you may want to start with If we chose our JavaScript framework like we choose our music…
Mobile
Mobile first is a buzzword that entered the common lexicon of applications, not only web applications. Like many other buzzwords, it oversimplifies several things, but it does make it easy for people to use the term. For web applications, this largely falls into three main concepts.
We have the hybrid or embedded application, where the application’s outer shell is a native container. Enhanced native integration is accomplished via Apache Cordova (or derivative distributions like Adobe PhoneGap) which allows you to write all or parts of your native application using web technologies to create an application.
The second major concept is the Progressive Web Application which was a concept originally coined by Google but has been largely adopted by the community. At its heart, PWAs are a set of best practices, fully leveraging some of the more modern standards available in web browsers on smart devices. These standards help ensure that users can experience a web application in a way is performant in constrained environments, provide functionality when not online, and deliver the benefits of an installed native application. PWA supports progressive enhancement over time.
Finally, there is the concept of Server Side Rendering (SSR). This allows an application to be instantiated server-side, and certain aspects are calculated before the HTML, CSS, and JavaScript are sent to the client device. In situations where there are constrained resources, like bandwidth or CPU speed, having this work offloaded to the server can help an application be more responsive to the user, where the user gets visible information from the application early, while the rest of the application is loading in the background.
Part of the reason why we are dissecting these different use cases is that many times, concepts can be over-hyped and are not really germane to the problems that you are trying to solve. One of those concepts that could be considered over-hyped is the concept of a responsive application, one that scales from a mobile device to a desktop application, adapting the UX to meet the constraints of those different platforms. Mobile, tablet, and desktop user experiences are quite different. Pushing all the code to manage that in a web application often makes the application larger and more complex than an application that is built specifically for a platform. Users will not be using the same application from their mobile phone and running it on their desktop, and the client application environment can be determined at load time. Having the wrong approach to responsive applications can easily sacrifice the user experience for the sake of developer ease.
Because of this risk, we should be cautious about how we build our applications. Are we using the right tools and right approaches for the problems we are trying to solve? This is why, in part, we are presenting four major use cases. What the user experience on mobile is can be very distinct to what an experience would be on a desktop business application and may require different approaches, or even different tools.
Consumer applications
We would define consumer applications as a step above content management systems or portals. You may be developing a solution, like a banking website, or the latest social media craze to topple Facebook, or something more revolutionary. We consider these applications to be a situation where you have a single authenticated user who is interacting with processes that are heavily tailored to that user, but the business process is fairly well known and straightforward, where the consumer is led down a generally linear path.
These applications tend to focus on processes that are easy to self-discover for the user, with little or no training on what they are performing. They are highly suitable for rapid evolutionary changes, since a user might only perform the process a few times a year, and the process is fairly straightforward and linear.
In order to achieve these consumer application goals, there are some typical patterns that frameworks can offer to make this easy:
- Single Page Applications (SPA): the user would be able to utilize the application without sensing that there is a full page reload between interactions, though the URL in the browser may be updated to reflect a particular location within the application.
- Authenticating users: a common use case and while it might be heavily dependent on the back-end systems, many consumer-facing applications need to leverage some of the open authentication platforms, like OAuth.
- Validation: Accepting user input and validating it, before it is sent to a back-end service, a common feature of most consumer applications. Providing an easy mechanism to describe this validation can help simply application creation.
- Server interaction: Less than a decade ago, everything about libraries was focused on AJAX (Asynchronous JavaScript And XML), which was the concept of sending requests, from the browser to a server to interact with a service or retrieve data. There are clearly many other technologies today, but this basic interaction is still fundamental to building most applications.
- Accessibility: While accessibility (a11y) might not be a top concern of those making consumer applications, it should be. The web was founded on openness and allowing everyone to access your information. We should all strive to make our applications available to everyone.
Business applications
We consider business applications to be the heavy lifting of web applications, and the unsung heroes of the enterprise. Business applications typically present many various business processes and allow the expert user to interact in an open-ended or unstructured way with the business processes. These expert users have been trained on the business processes they perform or manage, and they often would require training on the systems with which they interact.
These web applications often have complex requirements, are maintained over longer periods of time, and tend to be very sensitive to changes. Something as simple as moving the location of a button can incense your users as you have affected their user journey to their annoyance. Changes have to be socialized extensively with the user community.
While exploring this type of applications, we will look for any special sauce in dealing with these more advanced needs. We will look at many of the features we covered in more detail back in the Foundations and Applications blog posts, but apply a lens of pragmatism. We will also look at two common functional features that you find in business applications, charts and grids, which are often used to interact with and display complex data.
In the following sections, we summarize features of which we use the following convention:
- ✓ – Feature is present and reasonably usable.
- ✗ – Feature is not provided by the framework, though there may be third-party solutions that solve the problem.
- ❓ – Feature is partially present, or the framework could be capable of providing the feature, but there are some questions in our minds about the viability of the feature or how straightforward it is to make it function as expected.
- ? – Feature is on the framework’s roadmap (and we believe it will arrive and will not turn into Duke Nukem Forever).
Jump to:
Angular 2+
Mobile
Out of the box, Angular 2+ does not offer any particular focus on mobile, though Material 2 will perform optimized layout on smaller screen devices, as well components that are designed to handle mobile input, like swipe gestures.
As mentioned in the previous blog post, Angular 2+ has a dedicated mobile site which gives inaccurate and outdated information on how to create mobile PWA-compliant mobile applications. While it seems possible to create compliant PWA applications with Angular 2+, the tooling does not effectively support it at this point with confusing and contradictory issues about how the team intends to resolve this.
Angular 2+ offers a solution for Server Side Rendering called Angular Universal though this seems to suffer from the same challenge as PWAs, including the quick start guide on the website not working with current versions of Angular. There are several open issues that appear to indicate that even basic setup currently feels problematic.
If your development is mobile-focused, and you like Angular 2+, then you would likely be better suited to utilize Ionic, which is built on top of Angular 2+, offers out of the box Cordova support, and is entirely focused on mobile applications.
| Feature | Presence | Notes |
|---|---|---|
| PWA Support | ❓ | The out of the box experience is currently broken |
| Server Side Rendering | ❓ | Requires significant effort to get this working |
| Mobile Components/UX | ✓ | Assuming you use Material 2 |
| Cordova Support | ✗ | Ionic 2, built on Angular 2+ is a possibility |
Consumer applications
Angular 2+, much like Angular 1 that preceded it, is focused on providing single page applications. It allows you to define routes that trigger the application to display a particular view or activate a particular service. This allows linking to parts of an application, and the whole system is designed around presenting an application that does not require a page re-load during the user experience.
Angular 2+ does not come with any out of the box authentication integrations, though there are several third-party tools that leverage the Angular 2+ router to hook into various standard authentication platforms including OAuth.
Angular 2+ provides explicit guidelines for validating user input, generally focused on how to author templates and wire together validation logic.
Angular 2+ provides an HttpClient module that builds on top of XMLHttpRequest to make it easier to interact with servers and remote services.
As we discussed in the User Interface post, Angular 2+ does not inhibit accessibility, but the standard package does not really promote it either. Material 2 provides components that by themselves are accessible and does give some guidance on how to make whole applications that are accessible.
| Feature | Presence | Notes |
|---|---|---|
| Single Page Application/Routing | ✓ | The first router release with Angular 2 has been deprecated and replaced with a new router. |
| Authentication | ✗ | There are several proven third-party integrations. |
| Data Validation | ✓ | An explicit pattern for providing these features. |
| Server Interaction | ✓ | A decent abstraction to interact with back-end services. |
| a11y | ✓ | If you use Material 2, other UI frameworks built on Angular 2 would need to be vetted. |
Business applications
Angular 2+ provides internationalization (i18n) and a level of localization (l10n) as part of the base framework and provides reasonable guidance on how to leverage the feature.
As far as data handling, there are no tools that are part of the official Angular project, though there are various third-party solutions to provide data abstraction and integration. The third-party ng-charts package wraps chart.js and makes it easy to integrate it into an Angular 2+ project. There are also various third-party grids available such as ag-grid-angular and ng2-grid, though we have concerns about how effectively they handle large datasets.
| Feature | Presence | Notes |
|---|---|---|
| i18n/l10n | ✓ | Most general use cases can be met with the provided functionality. |
| Data Handling | ✗ | There are various third-party solutions of varying quality. |
| Charting | ✗ | There are decent third-party solutions though. |
| Grid | ✗ | There are third-party solutions, but their suitability for large data sets is questionable. |
React + Redux
Mobile
As you likely have noticed if you have read this series to this point, React + Redux are minimalistic libraries focus on solving the problems they were designed to solve, versus providing a holistic solution. Specifically, when it comes to PWA, there is no direct support, though you would not directly expect such direct support from React or Redux.
When it comes to Server Side Rendering, Redux specifically addresses the considerations that are required for being able to set up an application instance on the server and extract the sort of information needed to bootstrap an application.
There is no official support for Cordova from React and Redux, though there are many tutorials and boilerplate applications available from third-parties and there are no barriers to being able to build applications in Cordova with React + Redux.
It is worth mentioning React Native, which allows you to build native applications using JavaScript. This does not allow you to create hybrid or a mobile web application but instead create a native iOS or Android application that is indistinguishable from one built with Object C, Swift, or Java.
| Feature | Presence | Notes |
|---|---|---|
| PWA Support | ✗ | There are many guides available on how to achieve this. |
| Server Side Rendering | ✓ | There is official information on how to accomplish this. |
| Mobile Components/UX | ✓ | While you can really build any type of components with React, we consider React Native, using the native controls of mobile devices, as one type of full solution for a mobile UX. |
| Cordova Support | ✗ | Though there are no barriers to supporting Cordova. |
Consumer applications
When it comes to single page applications and routing with React, it gets a little complicated. Being fairly simplistic and straightforward libraries, with a community that builds many interesting things with React + Redux, there is significant innovation. One of those is a third-party React Router which has become the de facto router for React applications. However, keeping state for the router, it needed to be bound to the state store of Redux, which led to react-router-redux being managed by the React team and therefore being official. This was then moved into a package that is part of React Router, making it not quite official? Of course, as is common in the React ecosystem, if you are not happy with these solutions, there are plenty of other variations available.
This is the biggest challenge when it comes to React + Redux, there are so many patterns, tools, conventions, and approaches, that unless you lay down your standards early in the development process, your team will develop something that only a few people will understand and be able to maintain. Even projects developed with the same technologies might struggle to be compatible and consistent. You also need to be confident that the engineers setting the conventions and standards know what they are doing.
As you might expect, when it comes to authentication, there is no official (or pseudo-official) solution to this use case, though there are many third-party examples and solutions for various authentication platforms.
Redux’s simplistic approach to managing state with actions are called reducers, which mutate state, which then provides data to components, making the task of validating user input easy, even though there are no out of the box higher order validation schemes. This leaves the decision about how validation works up to each developer. There are third-party higher order frameworks for providing form or input type validation or keeping back-end data consistent with application state.
React + Redux by themselves do not offer server interaction APIs. They expect that developers will either leverage an abstraction and wire it into the application state, or just leverage the native browser APIs. The same goes for accessibility. The expectation is that a developer would leverage knowledge of a11y to ensure that components and applications are accessible, or that teams would leverage libraries of components that are already created to be accessible.
| Feature | Presence | Notes |
|---|---|---|
| Single Page Application/Routing | ✓ | There are many options and choices. |
| Authentication | ✗ | Nothing extra out of the box, but many references and examples. |
| Data Validation | ✓ | With a one way flow of data, validating data becomes a straightforward pattern. |
| Server Interaction | ✗ | Expected to bring your own abstraction or native APIs. |
| a11y | ✗ | Expected to build your own components or leverage a component library. |
Business applications
As mentioned in the foundations post, React + Redux don’t provide out of the box support for i18n/l10n, though there are some popular third-party solutions.
For charting, again, there is nothing out of the box, though there are dedicated third-party projects that wrap other charting libraries as React components. Notable are Uber’s react-vis, Victory and the pseudo-official react-chartjs which provides chart.js charts as React components.
For data grids, there is nothing provided out of the box. At the risk of sounding like a broken record, there are various third-party solutions, of which it is difficult to assess how effective they would be in dealing with large datasets.
When it comes to data handling, there is the Facebook-related project called GraphQL. While it is not specific to React + Redux, and can be integrated with many other projects, it is a solution to data handling that fits very well with a React + Redux solution. In addition, it solves one of the biggest challenges of client-side development, especially in a micro-services architecture, in that back-end services are seldom written with the needs of a front-end in mind. GraphQL allows a client application to easily describe the shape and structure of the data it needs and where to get it from, and a GraphQL server will orchestrate retrieving that data and shaping in the way to be efficiently consumed by the front-end application. For those willing to introduce this middle tier, GraphQL can be a hugely powerful tool to accelerate front-end development.
| Feature | Presence | Notes |
|---|---|---|
| i18n/l10n | ✗ | Expected to bring your own solution. |
| Data Handling | ✓ | Giving credit to React + Redux for GraphQL, but it can be used with many other frameworks. |
| Charting | ✗ | Again, bring your own, but there appear to be solid third-party solutions. |
| Grid | ✗ | Bring your own, but not as robust of a community of solutions as charts. |
Vue.js
Mobile
Vue.js has an official PWA template that is being maintained, also with additional information on how to leverage the template.
For SSR, Vue.js has a site dedicated to server-side rendering. It provides extensive documentation about how to manage and render Vue.js applications server-side.
As we discussed in the UI blog post in this series, Vue.js does not have an opinionated library of components, which also means the project does not have a library of mobile components or offer anything specifically in a way of dealing with the challenges of a mobile user experience. There are several third-party component libraries and frameworks that are specifically built for mobile or are designed to be responsive to being on a mobile or desktop platform.
While Vue.js doesn’t offer anything extra to directly support Cordova, there is significant community support. Furthermore, some of the UI frameworks are tailored to mobile make integration with Cordova straightforward.
| Feature | Presence | Notes |
|---|---|---|
| PWA Support | ✓ | Everything is available in the template, ready to go. |
| Server Side Rendering | ✓ | Extensive official information available, plus official helper packages to make it easy to manage an SSR application. |
| Mobile Components/UX | ✗ | Bring your own, but several mature third-party solutions based on Vue.js. |
| Cordova Support | ✗ | Bring your own, but many examples and third-party solutions. |
Consumer applications
Vue.js offers an official router which integrates well into Vue.js applications. It provides the tools and mechanisms necessary to build single page applications with Vue.js.
Vue.js does not offer anything official for authentication, but there are several complete third-party packages as well as other examples of integrating to open authentication platforms available.
Vue.js does not have any strict concepts around data validation. Traditionally the framework follows the MVVM pattern, where the ViewModel would mediate between the View and the Model, validating information. If using Vuex and an application state container, there are some patterns suggested for managing validation, though they feel like loose concepts. There are a couple of third-party solutions which provide a more rigorous system for validating data within models or a state container.
Prior to Vue.js 2, vue-resource provided an abstraction to XHR to manage requests to the back-end. With Vue.js 2, the team felt that this was not core to the Vue.js project and another organization now maintains it. Many Vue.js projects have started using the axios HTTP request abstraction library and there are many examples of how to utilize it within a Vue.js application.
Vue.js is unopinionated when it comes to the user interface, which means it is unopinionated about accessibility concerns.
| Feature | Presence | Notes |
|---|---|---|
| Single Page Application/Routing | ✓ | Has a well-developed concept of a router and how to create and manage single page applications. |
| Authentication | ✗ | A bring your own situation. |
| Data Validation | ❓ | Some level of patterns suggested, but it feels a bit confusing and left to the developer to solve. |
| Server Interaction | ✗ | Previously included, now bring your own. |
| a11y | ✗ | Something to evaluate when using a third-party component library. |
Business applications
As we mentioned in the Foundations article, Vue.js does not provide any out of the box i18n or l10n features. The same applies to data handling and abstraction, charting and grids. For all of these, there are third-party solutions, with most of them curated at Awesome Vue.
| Feature | Presence | Notes |
|---|---|---|
| i18n/l10n | ✗ | Check out i18n at awesome-vue |
| Data Handling | ✗ | Check out utilities at awesome-vue |
| Charting | ✗ | Check out charts at awesome-vue |
| Grid | ✗ | Check out tables at awesome-vue |
Dojo 2
Mobile
Initial support for PWA is provided by Dojo 2 to easily support the PWA standards. In addition, Server Side Rendering support is available. Early changes to support server side rendering of widgets are in place. Currently, the missing functionality is the ability create an application state server side, extract it, and then hydrate it on the client-side.
Existing widgets that are part of the @dojo/widgets are mobile ready and responsive in a mobile context. There are further plans to make it easy to abstract mobile input, like touch, to make it easier to author widgets that are mobile ready.
There are currently no plans for Dojo 2 to directly support Cordova, though there are no known limitations to utilizing Dojo 2 in a Cordova environment. It is likely that a community project will help integrate Dojo 2 tightly with Cordova.
| Feature | Presence | Notes |
|---|---|---|
| PWA Support | ✓ | Initial PWA support available. |
| Server Side Rendering | ✓ | From a rendering perspective, complete; from a state management perspective, forthcoming. |
| Mobile Components/UX | ✓ | Existing widgets are mobile ready, more API coming soon to make it easier to author new mobile ready widgets. |
| Cordova Support | ✗ | No current or planned support. |
Consumer applications
Dojo 2 has @dojo/routing
There is no out of the box solution to authentication, nor are there currently guides or references to integrating to open authentication platforms. It is likely this will change as Dojo 2 gets closer to a final release.
Dojo 2 provides an efficient mechanism for managing application state, though the mechanism and patterns for data validation are still being refined.
Dojo 2 has an abstraction library for XHR, fetch and Node.js http requests, called request and is available in the @dojo/core package. It is a promised-based and extensible.
All of the Dojo 2 widgets are designed to be fully accessible. The out of the box Dojo 2 theme is designed to be accessible as well, adhering to AA standard contrast levels. There is also expected to be further guidance on how to author additional widgets that are accessible.
| Feature | Presence | Notes |
|---|---|---|
| Single Page Application/Routing | ✓ | Available. |
| Authentication | ✗ | No current plans to provide out of the box. |
| Data Validation | ? | Patterns still to be refined. |
| Server Interaction | ✓ | The provided abstraction library should fit most use cases. |
| a11y | ✓ | Will provide an out of the box solution to make applications accessible. |
Business applications
Dojo 2 provides a fairly robust solution for i18n and l10n provided in the @dojo/i18n package. Using the Dojo 2 build tooling, it allows locales to be built into the bundle and allows other locales to be included to be dynamically loaded at run-time.
Dojo 2 provides a robust, reactive solution around data handling in @dojo/stores with a state container and a unidirectional flow of data.
Dojo 2 did some proof of concepts with data visualization, but have not progressed it further at this point. The team is evaluating the priority of this feature and if wrapping another charting library might be the most effective way of delivering the functionality. Some sort of solution is in the medium term roadmap beyond Dojo 2.
Dojo 2 has plans for an updated dgrid. It takes many of the concepts from dgrid 1 and brings them into a Dojo 2 pattern. The plan is to provide a modern, TypeScript based, grid that is highly performant, feature rich, extensible, and like all Dojo 2 widgets, easily exported as a web component, after the Dojo 2 release is complete.
| Feature | Presence | Notes |
|---|---|---|
| i18n/l10n | ✓ | Dojo 2 provides a full solution for i18n and l10n. |
| Data Handling | ✓ | Dojo 2 provides a robust data handling solution. |
| Charting | ❓ | Exactly how data visualization will materialize in Dojo 2 is unclear at this point. |
| Grid | ? | Dojo 2 has an alpha of a datagrid and is working on getting the grid feature complete and released after Dojo 2.0. |
Ember
Mobile
Ember.js does not offer direct support for creating PWA compliant applications, though there are a few third-party tutorials and solutions explaining how to add PWA features to an Ember.js application.
Ember.js provides a server-side rendering solution as a separate project called Ember Fastboot. It provides a framework for running Ember.js applications on a server and transporting their render and state to a client application. According to the project’s readme, because there is such a complexity and variety of third-party plugins and patterns for Ember.js, the applications that work easily with Fastboot are limited, though the team is continuing to try to improve this situation.
Ember.js does not provide any out of the box UI elements, therefore there are no mobile-ready components. One recent development though is that Ember.js has broken out their rendering engine into a separate project called Glimmer. This essentially provides a framework on which to build lightweight, fast UI components that integrate well into Ember.js applications. Components built on top of Glimmer are far more likely to perform better on processor and bandwidth constrained platforms like mobile devices.
There is no direct support for Cordova with Ember.js. Like other frameworks though, there are extensive third-party solutions and examples of how to build Cordova applications with Ember.js.
| Feature | Presence | Notes |
|---|---|---|
| PWA Support | ✗ | No direct support, though examples abound. |
| Server Side Rendering | ✓ | There is a complete solution, though it may be challenging to adapt existing applications to SSR. |
| Mobile Components/UX | ✗ | There are some component libraries for Ember.js that are mobile-focused and ready, in addition, Glimmer is a library for building performant mobile-ready components. |
| Cordova Support | ✗ | No direct support, though community examples are available. |
Consumer applications
Part of the core of an Ember.js application is its router, and defining an application’s routes is one of the core activities when creating an application. The Ember.js router provides all the features expected with a full-featured routing solution.
Ember.js does not provide authentication, though there is a very rich set of third-party solutions for Ember applications, and authentication is a common use case that is covered.
Because Ember.js applications traditionally follow a Model View Controller architecture, the Controller is usually engaged in data validation from the View. In addition to this, Ember Data is a rich library that makes it easier to manage data in an application model. Because of this, most server interaction occurs via an adapter. Ember Data provides a default adapter of JSONAPIAdapter which adheres to the JSON-API specification for interacting with JSON services.
Because Ember.js doesn’t focus on providing components as a core part of the framework, it does not directly concern itself with accessibility. On the other hand, the wider Ember community, with the support of the core Ember team, have created the Ember A11y project. This aims to get Ember projects accessible by default, as well as provides additional tools to help developers build accessible Ember applications.
| Feature | Presence | Notes |
|---|---|---|
| Single Page Application/Routing | ✓ | A fundamental part of an Ember application. |
| Authentication | ✗ | Plenty of third-party implementations. |
| Data Validation | ✓ | A robust mechanism for handling application data. |
| Server Interaction | ✓ | Defaults provided, additional adaptors available. |
| a11y | ? | Not a direct concern, but it feels like it is still a major focus of the project. |
Business applications
As mentioned in the Foundations article, internationalization and localization are not provided out of the box with Ember.js. There are at least two significant projects though that can provide it, ember-i18n and one from Yahoo!, ember-intl, which is part of Format.js.
Ember Data is more than just data validation and server interaction. It provides a higher order system to be able to manage remote data resources and describe APIs with the JSON-API specification.
Because Ember does not provide out of the box visual components, it does not provide charts or a grid, though there are extensive third-party solutions available. For charting, there are Ember specific solutions as well as wrapped solutions providing other charting solutions in an Ember way. There are many many options when it comes to grids, of highly varying quality.
| Feature | Presence | Notes |
|---|---|---|
| i18n/l10n | ✗ | Available through third-party libraries. |
| Data Handling | ✓ | Very well rounded solution. |
| Charting | ✗ | A wide range of third-party options. |
| Grid | ✗ | Several varied third-party options of varying degrees of quality. |
Aurelia
Mobile
Aurelia does not currently offer out of the box PWA support. There is a currently outstanding feature request to add this to the Aurelia CLI, though it is unclear when this support will be completed. There are also a few third-party tutorials about how to ensure your Aurelia application is PWA enabled.
As of January 2017, Server-Side Rendering is on the Aurelia roadmap to be a focus in 2017. At the time of this writing, a comprehensive SSR solution does not appear to be finished.
While Aurelia UX offers host detection (Cordova versus the Web) and platform detection (Desktop, iOS, Android), none of the UX controls are designed specifically for mobile, but there is an intent to have the Aurelia UX components work effectively on mobile. Following this information assists developers in creating mobile ready Aurelia widgets.
| Feature | Presence | Notes |
|---|---|---|
| PWA Support | ? | Have a feature request open and under consideration. |
| Server Side Rendering | ? | Officially on the project roadmap for 2017. |
| Mobile Components/UX | ? | Aurelia UX does not have mobile-ready components, though the team states it is part of their roadmap. |
| Cordova Support | ✗ | Has the plumbing to build upon, but do not directly support it. |
Consumer applications
Aurelia was conceived as a Single Page Application framework and its router is designed to be a powerful client-side router.
Aurelia does not come with any out of the box authentication integrations. There are some third-party services available, as well as tutorials from core team members that demonstrate how to create an authentication service.
Aurelia has a specific part of its platform for data validation named aurelia-validation. It uses functional chaining to provide a way of managing the validation of data and wiring that into an Aurelia application.
Aurelia has abstractions for requesting data from a server. For XHR it is called aurelia-http-client and a Fetch API abstraction named aurelia-fetch-client. The fetch client, with a polyfill, is currently recommended over the HTTP client.
Aurelia UX appears to have backlog items to ensure that those components are fully accessible, as well a stated part of the Aurelia roadmap.
| Feature | Presence | Notes |
|---|---|---|
| Single Page Application/Routing | ✓ | A feature-rich router is part of the platform. |
| Authentication | ✗ | Third-party solutions and effective tutorials. |
| Data Validation | ✓ | A dedicated part of the platform to help ensure the integrity of data. |
| Server Interaction | ✓ | Both XHR and Fetch abstractions are available. |
| a11y | ? | Part of their roadmap, though current components are not fully accessible. |
Business applications
Provides an i18n library that leverages i18next under the hood. i18next provides both the ability to deal with translations and deals with some other l10n features, like pluralization and a sufficiently robust API for building some higher order localizations like number formatting.
Aurelia does not provide any further abstractions to accessing data than what is provided in the HTTP and Fetch client libraries. It is logical that services could be created that provide a higher order abstraction of data sources.
Aurelia does not provide any out of the box charting or datagrid components. There are some third-party projects providing this functionality as well as wrappers around other libraries that make it easy to integrate.
| Feature | Presence | Notes |
|---|---|---|
| i18n/l10n | ✓ | An official integration with i18next is available. |
| Data Handling | ✗ | Could be built with the validation library into reusable services. |
| Charting | ✗ | Third-party solutions available. |
| Grid | ✗ | Third-party solutions available. |
Summary
Mobile
| Feature | Angular 2+ | React + Redux | Vue.js | Dojo 2 | Ember.js | Aurelia |
|---|---|---|---|---|---|---|
| PWA Support | ❓ | ✗ | ✓ | ✓ | ✗ | ? |
| Server Side Rendering | ❓ | ✓ | ✓ | ✓ | ✓ | ? |
| Mobile Components/UX | ✓ | ✓ | ✗ | ✓ | ✗ | ? |
| Cordova Support | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
These frameworks are a bit of a mixed bag when it comes to mobile development. Many can be used, but if the predominant use case is a mobile web application, there are other frameworks and solutions that are likely more suitable. If your use case is to provide a more complex desktop application which also works on mobile, then most frameworks are likely suitable for that.
Consumer applications
| Feature | Angular 2+ | React + Redux | Vue.js | Dojo 2 | Ember.js | Aurelia |
|---|---|---|---|---|---|---|
| Single Page Application/Routing | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Authentication | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Data Validation | ✓ | ✓ | ❓ | ? | ✓ | ✓ |
| Server Interaction | ✓ | ✗ | ✗ | ✓ | ✓ | ✓ |
| a11y | ✓ | ✗ | ✗ | ✓ | ? | ? |
It was surprising that many common use cases are catered for by these frameworks, except user authentication. Putting that aside, the frameworks were generally usable to build a consumer application, though almost all of the reviewed frameworks could improve the out of the box accessibility experience.
Business applications
| Feature | Angular 2+ | React + Redux | Vue.js | Dojo 2 | Ember.js | Aurelia |
|---|---|---|---|---|---|---|
| i18n/l10n | ✓ | ✗ | ✗ | ✓ | ✗ | ✓ |
| Data Handling | ✗ | ✓ | ✗ | ✓ | ✓ | ✗ |
| Charting | ✗ | ✗ | ✗ | ❓ | ✗ | ✗ |
| Grid | ✗ | ✗ | ✗ | ? | ✗ | ✗ |
It appears only Dojo 2 focuses on the use cases that are of greater importance in building business applications. Dojo 2 is clearly focused on business application scenarios. Ember.js would likely be the next one up, as it focuses on managing complex data interactions. At the same time, GraphQL, which we attributed to React + Redux, does a lot of the heavy lifting needed for a client application and can be used with all of the reviewed frameworks.
Up next
So maybe we have helped you narrow down what album you want to pick, and you have selected an album that is going to help you set the right mood for your party. Actually getting the record to play though is our next step. In the next post, we will delve into how you would actually develop applications with these frameworks.