2018 has been an amazing year for Aurelia! We've added long-time requested features and improvements, enabled new ways to deploy apps, shipped modern, no-hassle tooling, improved our documentation, built up financial backing, made huge advancements in our vNext implementation, and grown our core engineering team by adding six new amazing people! Wow!

Aurelia Tomorrow Not only was 2018 a great year for our current version of Aurelia, but it also saw the birth of what we've been referring to as "Aurelia vNext", our next-generation implementation of Aurelia. Early in 2018, we started with some simple prototypes and proofs of concepts, trying to explore how a modernized version of Aurelia's runtime might work. We were encouraged by the results and so began to make broader plans for the next major version of Aurelia. We started the official process by revisiting TypeScript and thoroughly reviewing how it had evolved over recent years and what the future looked like. After this review, we decided to move ahead with TypeScript as well as adopt a monorepo approach and standardize on the use of a new @aurelia NPM scope for publishing. As the first quarter came to a close, we had a solid understanding of the direction we wanted to take and how we could get there. By the second quarter of 2018, we had built enough to have a high-level plan for the packaging and distribution of vNext, settling on separating out the kernel, runtime, JIT, AOT, and plugins. Strong progress had been made on the initial implementations of the kernel, runtime, and JIT, enough to well understand the benefits that we could offer the global community. Here are a few reminders of several benefits we'll be delivering in vNext: Increased Team Agility - Use of Lerna 3 and TypeScript 3 projects has made it super easy to develop across packages, do cross-package refactoring, perform simpler integration testing, and have pain-free publishing. The entire Aurelia Core team is able to better maintain the code and assist our community by using the new setup and architecture.

- Use of Lerna 3 and TypeScript 3 projects has made it super easy to develop across packages, do cross-package refactoring, perform simpler integration testing, and have pain-free publishing. The entire Aurelia Core team is able to better maintain the code and assist our community by using the new setup and architecture. Easier Community Contributions - With one repo, there's no confusion on where to post issues or how to find the code in question. Anyone who wants to help fix a bug or add a new feature can checkout one repo , run a couple of simple commands, and be able to test their contributions against the full Aurelia framework and plugin test suite. Our new setup also has improved CI, nightly dev builds, simpler release management, integrated documentation, and more.

- With one repo, there's no confusion on where to post issues or how to find the code in question. Anyone who wants to help fix a bug or add a new feature can checkout one repo , run a couple of simple commands, and be able to test their contributions against the full Aurelia framework and plugin test suite. Our new setup also has improved CI, nightly dev builds, simpler release management, integrated documentation, and more. Removal of Cruft - There are many parts of today's Aurelia which are no longer needed or which can be represented by simpler abstractions. We're removing all these bits, simplifying internals, and performing a major cleanup. This has resulted in code that is smaller, faster, easier to understand, and can more easily evolve to meet future needs.

- There are many parts of today's Aurelia which are no longer needed or which can be represented by simpler abstractions. We're removing all these bits, simplifying internals, and performing a major cleanup. This has resulted in code that is smaller, faster, easier to understand, and can more easily evolve to meet future needs. Higher Quality, More Intuitive APIs - Over the last four years we've received a lot of feedback on Aurelia. While we've heard mostly great things about the base conventions and templating/binding language, it's clear that the low-level, imperative APIs for more advanced scenarios are not great. In vNext, we've already addressed the majority of these issues with new composition and resource APIs, more official extensibility points in the parsers and compilers, and an official renderer API.

- Over the last four years we've received a lot of feedback on Aurelia. While we've heard mostly great things about the base conventions and templating/binding language, it's clear that the low-level, imperative APIs for more advanced scenarios are not great. In vNext, we've already addressed the majority of these issues with new composition and resource APIs, more official extensibility points in the parsers and compilers, and an official renderer API. Improved Documentation - Using TypeScript has enabled us to provide better baseline documentation of our APIs from the start. However, in addition to this, we're building up detailed engineering documentation on the implementation details and the reasoning behind various decisions. All of this documentation lives side-by-side with the code in our monorepo.

- Using TypeScript has enabled us to provide better baseline documentation of our APIs from the start. However, in addition to this, we're building up detailed engineering documentation on the implementation details and the reasoning behind various decisions. All of this documentation lives side-by-side with the code in our monorepo. Smaller Framework - By removing unnecessary abstractions and cleaning up portions of the codebase that haven't aged as well, the core framework is being significantly reduced in size. Additionally, our new architecture, which allows developers to ship their apps without the JIT and Debug modules, and enables better tree-shaking, will result in even smaller bundle sizes. In the future, our AOT compiler will also produce customized builds that are even more streamlined.

- By removing unnecessary abstractions and cleaning up portions of the codebase that haven't aged as well, the core framework is being significantly reduced in size. Additionally, our new architecture, which allows developers to ship their apps without the JIT and Debug modules, and enables better tree-shaking, will result in even smaller bundle sizes. In the future, our AOT compiler will also produce customized builds that are even more streamlined. Improved Performance - A smaller framework downloads faster and has less JavaScript for the browser to parse. This will result in faster load times on its own. However, this isn't the only change that's going to have a huge impact on performance. There are many improvements and design changes to the internals of templating, binding, application and component lifecycles, etc. which are contributing to not only faster startup time but also faster render and repaint time.

- A smaller framework downloads faster and has less JavaScript for the browser to parse. This will result in faster load times on its own. However, this isn't the only change that's going to have a huge impact on performance. There are many improvements and design changes to the internals of templating, binding, application and component lifecycles, etc. which are contributing to not only faster startup time but also faster render and repaint time. More Power and Flexibility - We're removing older, leaky abstractions and focusing on creating solid advanced APIs. The end result is that we're going to open up more powerful possibilities for developers. Additionally, we're standardizing new ways to plug into the framework to extend it, define your own conventions, and use other industry technologies with less fuss (e.g. simpler Webpack integration, easier CSS Module support, etc)

- We're removing older, leaky abstractions and focusing on creating solid advanced APIs. The end result is that we're going to open up more powerful possibilities for developers. Additionally, we're standardizing new ways to plug into the framework to extend it, define your own conventions, and use other industry technologies with less fuss (e.g. simpler Webpack integration, easier CSS Module support, etc) Many Requested Fixes and Improvements - Over the years we've had a number of requests for new features and even the discovery of various design flaws that we just couldn't address in the current version of Aurelia. Our vNext implementation has already been incorporating a number of these ideas, including things like additional component lifecycle callbacks, more predictable lifecycles in complex scenarios, binding and task queuing that's easier to reason about, better/simpler dynamic composition APIs, easier imperative component creation, etc. By the end of Q3, we had our JIT up and running with most of the major features functioning. We had also implemented richer dynamic composition support, support for JSX, major component lifecycle improvements, integration testing with every major bundler/loader, and 91% test coverage, approaching 50,000 unit and integration tests. Usually, the end of the year slows down a bit, but Q4 saw the most important advancement in vNext so far: the origin of our official renderer API. With vNext, we want to open up new opportunities to enable Aurelia to be used beyond the boundaries of HTML. To enable that, we spent the last few months building 8 proof-of-concept (PoC) renderers and one production-targeted renderer. We then analyzed them as a whole and extracted a core set of interfaces that enable Aurelia to render to virtually anything. Here's what we built: HTML - We built a full HTML rendering engine for Aurelia. This mirrors the engine in today's Aurelia but adds more features, greater flexibility, enhanced performance, and increased power.

- We built a full HTML rendering engine for Aurelia. This mirrors the engine in today's Aurelia but adds more features, greater flexibility, enhanced performance, and increased power. SSR - In order to ensure that we can support native server-side-rendering from day one, we built a PoC SSR implementation as part of our renderer design process.

- In order to ensure that we can support native server-side-rendering from day one, we built a PoC SSR implementation as part of our renderer design process. PixiJS - One of the leading WebGL-based 2D game engines today is PixiJS . So, we built out an Aurelia PixiJS PoC renderer that renders 2D WebGL content. A simple demo is available here .

- One of the leading WebGL-based 2D game engines today is PixiJS . So, we built out an Aurelia PixiJS PoC renderer that renders 2D WebGL content. A simple demo is available here . ThreeJS - A popular library for building out WebGL 3D content is three.js . So, we built out an Aurelia three.js renderer that renders 3D WebGL content. A simple demo is available here . Aurelia's being used to render both the HTML controls and the 3D content. Did we mention that you will be able to combine multiple renderers in the same app?

- A popular library for building out WebGL 3D content is three.js . So, we built out an Aurelia three.js renderer that renders 3D WebGL content. A simple demo is available here . Aurelia's being used to render both the HTML controls and the 3D content. Did we mention that you will be able to combine multiple renderers in the same app? Fabric.js - If you're working a lot with 2D canvas in HTML, you might be using the Fabric.js library. We built out a PoC renderer that allows you to build Fabric apps with Aurelia. A simple demo is available here .

- If you're working a lot with 2D canvas in HTML, you might be using the Fabric.js library. We built out a PoC renderer that allows you to build Fabric apps with Aurelia. A simple demo is available here . Konva.js - Perhaps you're using Konva.js for 2D Canvas programming? We built a PoC with Konva as well. A simple demo is available here .

- Perhaps you're using Konva.js for 2D Canvas programming? We built a PoC with Konva as well. A simple demo is available here . Native Script - Moving outside of the browser itself, we built a PoC Native Script renderer. Here's a quick picture for you:

- Moving outside of the browser itself, we built a PoC Native Script renderer. Here's a quick picture for you: LibUI - Perhaps you're interested in native desktop apps? You might be using LibUI . We built a PoC renderer for that.

- Perhaps you're interested in native desktop apps? You might be using LibUI . We built a PoC renderer for that. Blessed - Maybe you're only interested in terminal UI. No problem, we built a PoC renderer for Blessed too. Renderers and Demos If you're looking for a full WebGL-based 3D engine, we're also working on a BabylonJS PoC. It's not quite ready yet but we'll share the demo when we've got it all working. We'll also follow up with future posts providing more examples of the renderers listed above. As a result of this work, we believe we've come up with a set of interfaces and abstractions that allow us to make Aurelia's renderer completely pluggable and supported as an official extension point. The design is intended to provide both maximum performance and flexibility without introducing unnecessary or obscure abstractions. Our hope is that as we stabilize this API in the next few months, community members who are passionate about the renderers listed above (or others) will join us in turning these PoCs into production implementations. While pluggable rendering was a huge achievement towards the end of the year, it's not the only major work that happened on vNext. Besides continued refinement across the JIT and Runtime pieces, we also started work on our vNext router. With the router, we've been exploring what it might mean to apply Aurelia's convention-over-configuration philosophy more deeply. The results have been pretty amazing, as we're coming up with virtually effortless ways to compose complex app routing schemes with little to no configuration at all. Of course, there will always be a traditional routing API as well, but we're looking to open up newer, streamlined options too. Here's an early demo of fully convention-based, hierarchical and parameterized routing in action. While Aurelia vNext is not ready for production use yet, the progress we made in 2018 has us all very excited. We believe a lot of what we're doing is going to be a game changer for front-end engineering in the future and we can't wait to get it in your hands.

The Core Team Over the last year, we've been honored to add six new stellar individuals to the Aurelia Core Team. bigopon joined us early in the year, contributing all the new templating features, the work on Aurelia Script, and our vNext alternative renderer PoCs. Alexander-Taran joined next, assisting with our GitHub issue triage, helping us to close out tons of issues and track features that we wanted to push into vNext. Not long after our vNext work kicked off, fkleuver joined the team, starting by making all the above improvements to our vCurrent binding engine and eventually transitioning to our lead engineer on vNext, responsible for nearly all the innovations in our next-generation binding and templating engines, as well as the solid infrastructure and test strategy we now have in place. A short bit later, huochunpeng joined to focus on the Aurelia CLI, eventually resulting in the authoring of our new auto-tracing bundler. Towards the end of the year, jwx joined us to focus on our vNext Router, working to build out the new version and exploring how Aurelia's convention-over-configuration approach can be extended to make routing and navigation both simpler and more powerful at the same time. And finally, BBosman joined to work on vNext, assisting by focusing on our code quality by improving linting, tightening down our TypeScript strictness settings, and fixing all related issues across the vNext codebase. A huge thanks to our new team members for their dedication and hard work in 2018!

In 2018 we launched our Open Collective to build up financial support for Aurelia and its ecosystem. We're ecstatic about the response we've had from businesses and community members around the world . Thanks to your support, our project is now able to cover 100% of its operating expenses and we're going to be able to do some new things in 2019 that we've never been able to do before, which we believe will help to grow Aurelia to new heights. At this time, we'd like to extend a special thanks to our Gold Sponsor, Hogia . The Hogia Group comprises 27 companies in Scandinavia and the United Kingdom. With software as a common denominator, the Hogia Group currently operates in the areas of finance and business systems, human resource systems and transport systems, and has shipped many Aurelia apps in these verticals over the years. Thank you Hogia!