Herding Code 203: Rob Eisenberg on Aurelia

The guys talk to Rob Eisenberg about Aurelia.

Download / Listen: Herding Code 203: Rob Eisenberg on Aurelia

Show Notes:

  • [Sponsor Message]
  • Hello There
    • (01:15) Kevin introduces Rob.
    • (02:05) Kevin asks Rob about his Xaml platform work with Caliburn.Micro. Rob says he’s transferred that work to Nigel Sampson, and it’s alive and well.
  • Comparing Aurelia with Angular
    • (03:22) Kevin mentions Rob’s history on the Angular team and asks what’s different about Aurelia. Rob says that he’s focused on vanilla Javascript code and minimizing configuration and metadata. Rob says that’s unique compared to most common frameworks, not just Angular.
    • (05:25) Rob also wanted to target transpiled languages so it worked well with ES6, ES5, TypeScript and Coffeescript. By comparison, Angular was pretty focused on Dart and AtScript.
    • (06:12) Jon references Rob’s post comparing Angular and Aurelia code and asks about conventions. Rob describes how conventions work, how you can create your own conventions, and how you can override conventions by providing metadata (but only for overrides, not all the time).
    • (08:56) Rob describes how binding and the templating syntax work. Aurelia minimizes additional markup for binding, whereas he sees Angular syntax focused on theoretical tooling experiences that could be built, but nobody’s committed to. Also, while Angular’s syntax is technically valid, it doesn’t work with cases like SVG. There’s a secondary binding syntax to work around that, but having two syntax doesn’t seem like a clean solution.
    • (12:31) Kevin asks for examples of conventions in Aurelia. Rob explains how custom elements work with EcmaScript 6 modules and exports. No metadata is required, as compared to Angular which requires specifying metadata in all cases even if you’re not using them. Rob also explains custom attributes (again using a simple exported class). Naming conventions set up the mappings so no metadata is required. Value converters are yet another example – the naming convention assumes that any class ending in ValueConverter is automatically registered and configured.
    • (16:24) Jon asks if Angular’s metadata requirements and verbosity are all for tooling support. Rob says yes for the HTML side, he doesn’t see a reason for it on the JavaScript side.
    • (16:43) Rob says that in Angular you need to declare all directives you’re using in your view models. That really bugs Rob because the implementation details in the view shouldn’t be reflected in the viewmodel. That was required for lazy loading, but he sees it as a design problem and a maintenance problem. Rob says that Aurelia uses an import in the view and doesn’t touch the viewmodel, using the EcmaScript 6 loader. Rob says that this design makes some conventions impossible.
  • The Aurelia Pitch
    • (21:08) Scott K says he likes the class-based design in Aurelia and asks Rob for a quick pitch for Aurelia to sell it to a team. Rob talks about the clean, standards based design that allows decomposing complex screens without requiring extra configuration. It’s easy to build, extend and maintain. Rob also talks about the binding syntax, and the ability to plug in other binding strategies by dropping in an adapter. The binding strategy system has been tested out with Breeze.js and Knockout, allowing you to use your existing models without requiring unnecessary dirty checks.
    • (26:42) Scott K asks how object.observe works with tranpilers. Rob says there’s a polyfill that generates getter / setter pairs if object.observe isn’t available. Rob explains how this works with the micro task queue, and how it allows for queued tasks to handle queued work efficiently. Rob talks about the task-queue in Aurelia, and how it can be used outside of Aurelia as well. Rather than directly observing DOM elements, the task queue allows for batching changes for efficiency.
  • Persistance
    • (35:15) Kevin asks if Aurelia handles a persistence layer. Rob says that rather than building that, they’ve worked to make it easy to plug popular persistence libraries in. He also discusses the validation system they’re working on.
    • (38:22) Jon asks if Rob’s looked at PouchDb and references Herding Code 181, in which Max Thayer explained PouchDb.
  • Why not write my own framework?
    • (39:40) Jon says he frequently hears people who are tired of JavaScript frameworks and decide to just write their own. Rob describes how it’s easy to get started but quickly falls apart. He describes some of the gotchas he’s run into in building Aurelia, with examples from aria, svg, data- attributes. Rather than writing your own framework, Rob says you should just contribute to Aurelia.
  • SVG use
    • (44:40) Jon asks if Rob thinks people will use SVG. Rob says it’s more about building a production-quality framework, then gives some possible usecases like graphs, mapping and custom elements. Rob says that people do all kinds of things you might not expect when they use a framework, and building a real framework requires it. Kevin says at his last job they’d started converting image sprites to SVG, and it was a pretty good use-case.
  • React
    • (49:05) Kevin asks about Rob’s thoughts on React. He says it’s a good renderer, but it’s not a framework. He and Scott K agree that React is a library, not a framework. Rob says he wrote a blog post in which a custom Aurelia element uses React as a custom renderer. The Babel transpiler allows mixing JSX with ES6 code, and this allows continuing to use Aurelia binding. In general, Rob says really smart, but if you need a framework you’ll end up cobbling a bunch of things together to use it. Instead, he’d recommend using a framework like Aurelia and just pulling in React when it’s required.
    • (53:22) Kevin asks if Rob’s considered adding a virtual DOM to Aurelia. Rob says it’s not clear that there would be an advantage in most cases.
  • Isomorphic rendering
    • (54:17) Kevin brings up the other JavaScript buzzword of the day: Isomorphic rendering. Rob says Aurelia doesn’t support this, he doesn’t see this sticking around. Jon says he still sees a pretty clear distinction between websites and web apps, and Rob agrees, saying he wouldn’t use Aurelia for websites.
  • Questions from Twitter
    • (57:25) Question from Twitter (@cecilphillip): "What’s the rendering perf like compared to ReactJS?" Rob says that React is going to be a lot faster for initial render time, whereas Aurelia is probably going to be faster for updates. It’s hard to give an accurate comparison; Rob says they’re mostly focused on being fast enough rather than the fastest. He says Aurelia’s not slow now, but they’re focusing on some upcoming performance enhancements that he’s expecting big results from.
    • (1:02:09) Question from Twitter (@csharpfritz): "can you talk about what lead to the choice of architecture with JSPM?" Rob explains how JSPM integrates package management with module loading. Aurelia isn’t directly dependent on JSPM, so you can use other package managers and loaders if you want. Jon says the one thing he wants JSPM to integrate rate limiting so he doesn’t hit the GitHub rate limit; Rob says this is being addressed in a future release since most cases don’t require the hitting the rate limited API.
  • Scott K’s Packaging Rant(tm)
    • (1:08:11) Scott K has a "short rant" about NPM, JSPM and all package managers in general: they all use existing config files (like gitconfig) and should be tested behind corporate firewalls and proxies. And then there’s the nested package thing, which doesn’t work well on Windows due to path length limits. Jon says he uses the flatten-packages package. There’s a short group rant about the file path length limit on Windows.
  • Final questions and wrapup
    • (1:13:40) Jon asks if there are any patterns or thoughts on server-side development for Aurelia. Rob says there are starter kits on the way, and people are using Aurelia with lots of back ends (.NET, node, MEAN, etc.). He talks about samples on the way, including a Todo app (even though he thinks Todo apps aren’t useful for application frameworks).
    • (1:17:15) Kevin asks where Aurelia’s at in a release cycle. Rob says it’s currently in preview / alpha phase but targeting a beta around June or later. Don’t go to production with it now, but get ready for the release after that.

Show Links:

  • Jeremy Bell

    I always hear people immediately complain about the long path issue in windows whenever talking about npm, as if that would just fix everything. That’s missing the point. There are two separate issues. Sure, Windows has a particularly small path size limit for legacy APIs.

    But it doesn’t matter how large the file path limit is – npm’s nested file structure is a serious design flaw either way. Fundamentally there is no reason to have nested file structures – you don’t ever need more than one copy of any particular version of a package. The file system makes a pretty poor dependency graph database, which is what npm/node is using it for. Node’s decision to use nested dependencies also makes it more difficult to make version-ed backups for CI builds, takes longer to install/update, and is more likely to fail on unstable network connections.

    Unfortunately, node/npm is too entrenched in this layout to change, so this will continue to be an issue for some time.

    • Adam Tal

      This should get better in NPM 3