Where do we go from here

1

I have been using and pushing Aurelia for some time. I am now getting to the point where I am starting to lose faith and wondering if it is too late? React/Vue/Angular have so much market penetration in every aspect (All the control companies (MDB, Telerik, etc), native mobile experiences, massive communities) and do their job well. What benefits are there left for one to choose Aurelia anymore other than paid for support? What is my argument? What is coming that is going to be so much better or different than the others? I still love Aurelia so no hate, just love.

3 Likes
2

You should probably check the half dozen other threads that already cover this. This is a good start.

We’ve used Aurelia for large successful projects and would start new projects with it tomorrow and none of your concerns would stop us. There are plenty of others who feel the same.

5 Likes
3

I assume you’ve seen this tread.

I’ve looked at all the major alternatives and still find Aurelia to be the best. Unfortunately, we all know that the best doesn’t always win out in the marketplace because there are other factors at play. I think the core team has identified many of the issues that have held Aurelia back and are actively working on them for vNext.

One of the biggest issues I’ve seen is the general lack of knowledge among developers trying out Aurelia. It is obvious to me from the questions that are asked on StackOverflow that a fairly large percentage don’t even understand concepts as basic as MVVM.

I also think Rob’s (@EisenbergEffect) Beginning and Intermediate webinars from 2016 that are available on Vimeo for a fairly hefty fee should be viewed by newbies interested in developing with Aurelia. At least the basic one should be free. I think that could help adoption in a big way.

Also, completion of Aurelia-UX v1.0 would be a huge boon!

2 Likes
4

I’m more concerned with the amount of choices that have already been made due to the lack of integration in libraries that are well known and used. Will these companies ever pick up Aurelia having a solid three frameworks already integrated with their controls? Open source wrappers for these tools don’t get very far in the business world. What will make Aurelia so irresistible that telerik, mdb, microsoft, have to pick up and support an Aurelia integration.

5

Control libraries are rubber screwdrivers.
With some exceptions.

1 Like
6

@Alexander-Taran Thank you for the response. It was really helpful.

some examples of what i am talking about.

Telerik’s kendo pro controls and material which have professional support for integrations. (Controls)
Weex, React Native, Nativescript for mobile apps (MOBILE)
asp.net core server side rendering utilzing node services (SSR)
standard boilerplate projects shipped with IDES (intellij, visual studio, vscode)
amazing tooling (intellij, visual studio code, visual studio)

1 Like
7

What will make Aurelia so irresistible that telerik, mdb, microsoft, have to pick up and support an Aurelia integration

Precisely. Currently it’s a catch-22; I doubt the vendors will invest in Aurelia until it has greater market share and I doubt it will increase it’s market share until it has support from the vendors.

8

I also have the same issue. I introduced Aurelia more than a year ago and did a couple of projects with it. The developers I worked with were very enthusiastic about Aurelia and we all like it very much. Performance is great (even in IE 11 which we must support) and we all like the great modularity.

But now a new project begins and we begin to get discussion about Aurelia because it is not used very much and some managers are now referring to usage statistics of web frameworks.

9

That is tough. The framework is acticely maintained and developed, the releases are consistent, the feature set is suitable and beneficial for businesses, yet it is questioned about its future.

1 Like
10

depends on a project really.
If it is a “write once, support never” - go with react… whatever…
and the buyer will have to figure it all out.
If you (the team) will be responsible for supporting it.

Play out with frameworks in debate.

Have a small spec
implement it in all the frameworks/libraries
Have a change request
Implement it in all the frameworks…

give it a rest (for a week of more) to forget the code
have another change request
add a feature… change something

time everything
How long it took you to develop in each cycle

I’m pretty sure with real world features/changes - time to develop/support with aurelia will be way less.
And that is real money to business.

Show them. That while all the competitors pay 3 times more to their dev teams you can get the same result faster.
More readable

give the code to some backend dev (pretend new hire)
can he make a change in any of those.
I bet any c#/java dev could figure out Aurelia in no time
While figuring out react will take forever (-:

Good luck man.

1 Like
11

I as well as others probably are not worried about the current state we are in (stable, quick, etc.), but the state of others. The other frameworks adoption rates, integrations, and features are escalating quickly. I believe promoters of Aurelia have pushed it very hard in every aspect against the biggies, but still lag behind in each of the mentioned categories. What is the plan to get us caught up, rather than falling further behind?

2 Likes
12

I personally have been focusing on what I believe to be the most neglected part of the Aurelia ecosystem: Official services. We’ve been building up official training, online courses, and enterprise support services with the goal of making Aurelia development more sustainable. In fact, I have recently stopped accepting new clients in my consultancy so I can focus on this effort. It’s a big risk, but I refuse to live in a world without Aurelia.

@brandonseydel Have you ever worked on an application that was a frustrating mess? I had a boss who hacked a product together for fun and then started selling it as a product and never touched it again, instead handing it off to other developers in the company. We couldn’t make heads or tails of what he was trying to do. Any time I had to work with a customer using that product I was left completely exhausted and frustrated.

I work with customers around the world working on trainings, support, and development services for applications of all sizes at various stages of development and teams of all experience levels. Aurelia adoption is slowly and steadily increasing, even as we enter the 3rd year of the same major release of the framework. Why? Developer happiness. Think about what got you into this forum in the first place. If you thought Aurelia was just another choice, I think you wouldn’t even bother to make this post. You want to keep using Aurelia. And every day another developer or another company is discovering that same feeling.

It’s also worth nothing Aurelia has the single largest developer market of any front-end framework. Aurelia’s standards-focus and intuitive syntax means even a new JavaScript developer can scale up on Aurelia in less than a weeek. We see this all the time.

@jeffgrann My main focus at the moment is building focused, interactive, video-based courses for vCurrent and vNext. Announcement coming very soon.

@brandonseydel Finding a sustainable way to address this is on my radar. The problem is that often it is much easier it is to pick your favorite library and wrap it with Aurelia for the specific needs of your application than it is to build a general plug-and-play solution for everyone. If you haven’t yet, check out some of my blogs at http://davismj.me/ where I cover how to approach some of these topics.

@arjendeblok When the decision makers know less about their decisions than those forced to live by them, perhaps it’s time to start looking for more forward thinking companies. How will they stay competitive?

Again, why are you here? It’s not because you think React is better. So we’re ahead of other frameworks by some standards. We’ve gotten this far by not focusing on the same things that React and Angular did. We got here by focusing on you, the developers who use and love Aurelia. We’re not going to try to beat Facebook and Google at a different game that we have no chance of winning. We’re going to keep doing what we’ve been doing, because it’s been working.

That said, we depend on feedback from our community. We want to hear your pain points so that we can prioritize them and resolve them. We love hearing your thoughts on how we can do better.

5 Likes
13

Aurelia is really the superior conventions and elegance of it. That’s the advantage with Aurelia.

It uses ES classes and components force you to be organized. It can utilize a variety of options through the cli, such as webpack or others.

No confusing or too many rule-based conventions that require lots of training. Everything should be intuitive and this Aurelia framework seems to follow that principle a lot closer than the others.

Aurelia may not have the biggest community but I have found everything I need in the ecosystem. There are some areas still being neglected but that can be improved slightly and we’d be ready.

This website probably needs a few more links / icons on the left side to integrate with the community. Where do I find UI frameworks? Where do I find plugins? etc.

1 Like
14

The way I see it, if you know how to use Aurelia and it works for your needs, there is no need to be concerned about popularity or community size. I know Vue and React seemingly have a lot of buzz around them and a trove of plugins, but nothing seems to come close to Aurelia in terms of design (except maybe Angular, albeit more verbose).

I have been working with Aurelia for almost four years now which is absolutely crazy to even say. Every new project I have worked on these last few years has been Aurelia (in a commercial sense). And I used to work with React as well as Angular and I have also tried Vue as well.

As much as I like Vue’s simplicity and its concept of single-file components, I come back to Aurelia every single time and have never felt the need to change to anything else. Aurelia is underrated, it isn’t as popular and might be hard from a management perspective, but ask anyone who has used it and they most likely haven’t got a bad word to say about it.

Aurelia’s biggest problem is marketing and I am making it one of my missions to really get the Aurelia name out there in 2019, coinciding with vNext being released (which is going to be huge and awesome). We have to remember that while Vue is popular now, Vue 1.x was not that popular and it wasn’t until Vue 2 that people started paying attention.

But, really the concerns people have these days don’t seem to be around Aurelia lacking something (other than exposure or a big backer) but primarily based on popularity. I think this is an industry problem, if we are choosing tools, frameworks and libraries based on their popularity instead of what is the right tool for the right job, that’s not something Aurelia can change.

Similarly, look at Angular. Angular 1.x was very popular, but when Google announced and released Angular 2+ a lot of people abandoned it for React because they didn’t listen to the community and while Aurelia might be small, one thing @EisenbergEffect and the team has always done is listen to what the community wants and thinks.

6 Likes
15

I think support by component vendors is important, but overrated. Our company uses Aurelia since the beta days, and we rarely have issues with the framework itself, most of our issues are with the kendo pro suite :slight_smile: (we use the aurelia kendo bridge, but most issues come from kendo itself). I filed numerous issues with kendo’s controls and most of them are yet to be fixed, so don’t overestimate the value of technical support from these companies.
We tend to minimize dependencies on these controls because as @Alexander-Taran mentioned, they are rubber screwdrivers. Some examples:

  • we moved away from the kendo datepicker to a thin wrapper around flatpickr, it’s in every way superior to the kendo picker
  • we did the same for the upload control, where we moved to dropzone
  • we tend to build some controls completely custom, multiselect for example. All kendo controls who have to load big amounts of server data are either buggy (half-baked virtualisation) or slow

We are considering dropping kendo altogether, moving to ag-grid as an alternative for the kendo datagrid, but have yet to find a kendo scheduler alternative (which is also terrible in terms of performance)

3 Likes
16

This might be tricky topic to discuss, but since my opinion is on the completely opposite side of spectrum about this, I think it’s better to state it clearly and give a chance to people to comment/clarify.

I am following/using Aurelia since summer 2015, so for a very long time. My impression is that Aurelia team tried to consciously separate only basic information to be available for free and the rest as Official services. While this is understandable, I think it hampered (and is still hampering) adoption of the framework.

2 Likes
17

I don’t really get excited by component vendor integrations either. During the last Aurelia project I was working on, I was able to build a couple of components that exactly fit my needs and didn’t have any bloat in the same amount of time it would have taken me to figure out how to hammer something from a vendor into place.

3 Likes
18

I think Aurelia team has been operating in QA style. Just the doc was quite bad that making it’s not suitable for delivering knowledge in more depth. Beside that, I’ve seen a a number of posts, from both core team members and community members, covering a lot of high level + powerful APIs of Aurelia so I’m not sure what’s missing. That said, the team would be interested in what can be done better to avoid creating that impression.

19

(which is going to be huge and awesome)

What is it that is going to make it huge and awesome? Just pin points that are not in vCurrent will help everyone out.

20

I can provide a few pointers (bear with me though, they’re a bit technical and the concrete use cases, benchmarks etc will come further down the road):

  • The TaskQueue is gone, superseded by a much more powerful and flexible Lifecycle.

    This is an important one. The TaskQueue in vCurrent is a single entry point that allows you to ensure operations happen in a certain order. But it’s asynchronous and it also doesn’t differentiate between different kinds of tasks.

    The new Lifecycle class is fully synchronous (it uses depth-based batching) and treats various lifecycle methods such as flush, patch, connect, bind, attach as first-class citizens. Instead of every batched operation having to conform to a contextless call signature which is called in the order that they’re queued, the new lifecycle will for example ensure that all changes are flushed before proceeding to bind, or attach. Lifecycle methods are more efficient, faster, and easier to reason about.

    No more queueMicroTask in attached or inside a handleChange just to make sure your components are fully updated. They already are. And batched operations can be awaited.

  • Additional (and more robust) templating resources, covered by tens of thousands of tests hammering it with any exotic combination of things a user might want to throw at it. No more guesswork of “will this work in combination with that”. Multiple nested if and else controllers with custom containerless elements, repeaters, binding behaviors, value converters, composed elements, with various bindings and lifecycle hooks that update those bindings (some of them asynchronously)? Not a problem.

  • Collection observation is much faster (the repeater is up to 5 times faster with sorting).

  • Far more powerful composition API’s that make dynamically building pages and components a breeze.

  • The way vNext is set up will give us confidence in knowing that if the all the tests pass, we’re probably good to go. With vCurrent this is absolutely lacking and it has caused things to go stale out of carefulness.

  • No more bootstrapper or complex loader stuff. You can bootstrap and start an Aurelia app in approximately 100 characters from an included script tag on a plain html page.

  • Easier to author plugins with complex behaviors and even extend the binding syntax with simple decorators.

I could name many more things, but I’d rather get back to coding now :slight_smile:

9 Likes