
Aurelia UX - toddwprice
http://blog.aurelia.io/2016/11/04/introducing-aurelia-ux/
======
mattbeckman
Our team has been using Aurelia for many months. While it has some cool
features, there are plenty of gotchas that add a lot of overhead. Weeks spent
on features that had to be reworked due to edge cases in DI, for example, or
relying on some of the non-core packages.

It's interesting stuff, but don't jump into it expecting to run at full speed
without tripping a few times along the way.

~~~
fvdessen
I have the same experience, We have been using it for months and I cannot say
that we are happy. A lot of bugs, a lot of missing documentation, a lot of
bloat, and some bad breaking changes. It seems to me that the Aurelia team
wants to do too many thing at once, and cannot deliver to the standards that
other framework provide.

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.

~~~
pwkad
Aurelia is arguably more mature than vue though I guess that depends on who
you ask. Can you reference any bugs? Currently most issues that are open on
the main repositories are feature requests or edge cases

~~~
fvdessen
I don't remember the specific bugs, but here are our main issues with aurelia:

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.

~~~
AshleyGrant
Hey there, I'm Aurelia's Community Lead. I wanted to address these issues with
you so we can work together to deal with the issues:

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.

~~~
fvdessen
No problem, thanks for taking the time to reply.

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.

~~~
AshleyGrant
Regarding the if/else binding. Check this issue:
[https://github.com/aurelia/templating-
resources/issues/171](https://github.com/aurelia/templating-
resources/issues/171)

And this gist:
[https://gist.run/?id=f75346c4eecaa934164839316c3f0175](https://gist.run/?id=f75346c4eecaa934164839316c3f0175)

This is actually a pain point even on the team, so your post got some
conversation re-started.

------
TheAceOfHearts
Am I the only one that finds its kinda weird that they'd announce a UI/UX
framework without a live previews? That's really one of the killer features of
the web, that you can show stuff off without installing anything.

~~~
FreakyT
Agreed, all the way at the bottom they almost seem to have a link to examples,
but then it turns out that it's just a repo of examples that you can clone and
serve yourself.

It definitely seems like they're missing a huge part of what's going to sell
this framework without functioning examples online.

~~~
Drdrdrq
On top of that, they have this annoying feature where they list the number of
minutes left. Like I want a reminder how much time I am wasting reading some
random blog. Not really an example of great UX...

------
nulagrithom
> Documentation:

> 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.

~~~
kylestlb
The disclaimer on the site says it's in pre-alpha. I assume that the people
trying this out will be people who currently make things with Aurelia.

------
prplhaz4
Interesting project...seems like the main competitor here is Ionic? Not sure
how to go about identifying and comparing the strengths/weaknesses, but that
should come with some time.

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.

~~~
oblio
What's AI in this context? Aurelia I..?

~~~
prplhaz4
Updated post to clarify - Aurelia Interface - their (formerly) commercial UI
components.

------
emilong
Having never heard of Aurelia before, I was curious how this compared to React
and found this interview with the creator/lead, Rob Eisenberg, with his
thoughts:

[https://medium.com/hashnode-insights/rob-eisenberg-on-
aureli...](https://medium.com/hashnode-insights/rob-eisenberg-on-aurelia-and-
how-it-stacks-up-against-angular-2-and-react-82721d714449#.v6gc56ljn)

Also includes his comparison to Angular.

------
king_magic
Well, if they can somehow make Cordova less awfully terrible from a UX
perspective, more power to them. I'm not holding my breath, though.

~~~
GordonS
Both Ionic and OnsenUI do a pretty good job

~~~
king_magic
I've seen nothing but awful results from Ionic.

~~~
GordonS
Admittingly, the constant changes and breaking stuff in Ionic 2 is getting a
bit... tired. I know it's not at 'final' status yet, but still.

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.

------
johnjuuljensen
Has anyone used Aurelia with succes?

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.

~~~
chadporter
We've been using Aurelia in production since early beta. Have a half dozen
live projects in it now, including Cordova apps (but not Electron apps).

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.

------
spankalee
I wonder how Aurelia's style encapsulation is different from Shadow DOM, or
how CSS databinding is different from CSS custom variables.

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...](https://github.com/PolymerElements/app-
layout/tree/master/app-grid)

------
mhd
Decent grid widget that let's me get rid of ExtJS included?

~~~
TheAceOfHearts
Depending on what you mean by grid, you might find react-virtualized [0]
interesting.

[0] [https://bvaughn.github.io/react-
virtualized/](https://bvaughn.github.io/react-virtualized/)

~~~
jessedhillon
Major flaw with that component: the scroll handle size does not change. So if
you have 10,000 rows, moving the handle down by one pixel will take you from
entry #0 to ~#40. In fact, somewhere between 10k and 100k, it stops being
possible to scroll to some elements, say from #0 to #20, whether using the
wheel or the scrollbar.

