Aurelia UX
blog.aurelia.io
blog.aurelia.io
It's interesting stuff, but don't jump into it expecting to run at full speed without tripping a few times along the way.
It's sad because the underlying ideas are good. It is in many ways similar to Vue.js, which is very good. To readers considering Aurelia I would suggest trying Vue as well, or wait until Aurelia is more mature.
1. The build ecosystem. We started with JSPM which has a lot of annoying issues, worst of all a +-700Mo base install that takes 45min to complete, which makes docker deploys really slow. Another annoyance is a config.json that is re-generated each time you make a gulp watch and pollutes git diffs. The export config must be manually modified each time we add a new library or assets and is also a source of errors. We tried replacing it with aurelia-cli but couldn't get it to work with some external dependencies. We are considering moving to webpack.
2. Probably related to jspm but loading our applications takes 3-10secs depending on the platform and thus requires a loading screen, which I find unacceptable.
2. The documentation is in a web-application and is not indexed by Google.
3. Some modules have a javadoc style documentation that requires a lot of reading to do simple stuff.
4. The templating engine is missing an 'else' keyword.
5. Watching for model changes requires manually setting up a watcher and manually tearing it down, Vue's watchers are far easier to setup.
6. Aurelia is split into many small libraries which means you have to manage a lot of import directives.
7. Aurelia-validation was depreciated and replaced by an incompatible library without much warning, and without migration instructions.
8. Aurelia implements model watching by replacing all fields with getters and setters and thus pollutes the models when inspecting them with chrome developper tools.
9. Aurelia implementation outputs a lot of warnings when using Bluebird.js with default settings.
Otherwise as I said the underlying architecture is fine, but those annoyances add-up. It just needs more polish.
1 & 2a: We feel your pain on JSPM/SystemJS. An unbundled SystemJS application is kinda slow. My current recommendation is to either use Webpack or look at our CLI. The CLI is currently alpha, but the loading performance blows JSPM/SystemJS out of the water. The JSPM Skeleton has a loading screen b/c of how long SystemJS takes to load an unbundled Aurelia app. The CLI doesn't need this since the app loads so quickly.
3. This documentation helps us generate our documentation site which leads us to..
2b. We're working on server-side rendering which will rectify this issue, and provide a lot of value for the community of Aurelia developers.
4. I'd like to see this rectified, personally. I'm not sure that an `else` would work, but what about a set of `switch` and `case` custom elements to do this?
5. Yeah, this is somewhere we got screwed when the powers that be decided that `Object.observe` needed to be killed. That being said, have you used our `observable` attribute on VM properties? It works just like the `bindable` attribute in terms of giving you a `${name}Changed` callback that you don't need to worry about tearing down.
6. Most of the things you'll use on a daily basis are pulled together by the `aurelia-framework` module. There are some exceptions, such as router stuff. But most of the time when I'm writing aurelia import statements, I'm pulling stuff from the framework module. ymmv
7. This is true, but it was deprecated due to being a broken design. The new version is much better and is quickly pushing to release.
8. Again, something that happened due to `Object.observe` being taken from us.
9. In a CLI based application, I get one warning. I've been working to find the source of the warning so I can file an issue.
All in all, I don't want this post to feel antagonistic. We're all working towards a common goal: Building an awesome framework that makes all of our daily jobs easier.
With JSPM The loading times are slow even for bundled apps. From looking at the timeline profile it is mostly JS execution time.
The `else` keyword really does work well in Vue, you should really consider it. It's just that a lot of time we have if.bind='stuff' immediately followed by if.bind='!stuff', and 'stuff' can get complicated.
And for the Object.observe, I do not know how Vue does it but it doesn't have those issues, maybe you can use a similar solution ?
Anyway I'll file bugs and we can continue the discussion on the tracker.
And this gist: https://gist.run/?id=f75346c4eecaa934164839316c3f0175
This is actually a pain point even on the team, so your post got some conversation re-started.
VueJS does this too, any advice anyone?
And if interested in Vue, check out Quasar [0], a UX framework for Vue (recently made compatible with Vue 2.0) that seems to have a lot of the same goals as Aurelia UX.
Calling Component Authors
We know we've got a ton of members within our community who have built and want to build components for Aurelia. We're inviting you to join with our core team to build out the components of the Aurelia UX library.
It definitely seems like they're missing a huge part of what's going to sell this framework without functioning examples online.
> Forthcoming...
I feel like introducing something without documentation is a little premature. Or maybe its use is abundantly clear to those who've used Aurelia.
Hope this is captured somewhere else, and not just buried in this article...
>> Unfortunately, we won't be able to continue our work on AI (Aurelia Interface). After careful consideration and review, we realized that AI was going in the wrong direction and didn't have the versatility or the proper architecture to handle our vision of a UX Framework. With Aurelia UX, we're rebooting our efforts.
https://medium.com/hashnode-insights/rob-eisenberg-on-aureli...
Also includes his comparison to Angular.
But we've been using it for a long time and have, in the main, had great results with it.
Xamarin has however come on leaps and bounds since out team started doing mobile development. And is free too... so I could see us switching to Xamarin to get native performance on apps that demand it.
I'm currently looking into what our next client side framework should be and I have a really good feeling about Aurelia. It feels like someone finally got it right. It's the same feeling I had about ServiceStack, which is by far the best web framework I've ever used.
My main criteria is ease of use by backend devs and going by the tutorials I've done so far, that certainly seems to be the case. I am however myself a backend guy and it's quite likely that Aurelia is missing something important or that the niceness breaks down once you cross some complexity threshold, and I can't see that due to my limited experience in that field.
The biggest pain point is the build/deploy step takes some work to perfect, but this is being worked on by the community and is a pain for every front-end SPA framework.
As far as ease of use by backend devs, I'm not sure what you mean as the back end can be anything you want. We use a Node.js API for our back end, but use whatever you want to create a REST service and Aurelia will consume it just fine.
It's been great. Very easy to work with and good performance these days. The best part IMO is that you don't really get sucked into an Aurelia-or-nothing situation. It's not hard to work with other techs right inside your Aurelia app. We often had a dev that was less familiar with the possibilities in Aurelia do stuff using technologies they already knew, and then we'd convert it to use Aurelia methods later after the feature was proven.
Most of the gotchas I've run across are related to observing arrays. By default some array mutations aren't caught. There are ways around this by manually importing the BindingEngine and setting up a subscription, or using @observable on a property, but before you figure that out array observation is a bit vexing. It's not that these other methods are hard, it's that you have an expectation of collection observations and the way it works (largely for performance reasons) doesn't mesh with that.
It does pay to have someone familiar with Aurelia and not all dabblers. We do a good bit of advanced stuff like dynamically generating bindings based on conditions defined in data (e.g. show/hide this form field if these other arbitrary form fields have these arbitrary values, which can be changed by the user, and automatically rebind to the new fields when conditions are changed). Doable if you use some of the more core Aurelia features, but not really something you can do with just the basic surface APIs.
Aurelia or not, all of our architecture is front end + app-agnostic API. Backend devs don't need to give a crap about Aurelia if they don't want. If you mean "is it easy for backend devs to do front end work using this?", I don't know because we don't have any pure backend guys for me to use for reference.
You can already use media queries + CSS custom variables today to do pretty powerful script-free responsive layouts: https://github.com/PolymerElements/app-layout/tree/master/ap...