We make the community no one else. Three years ago @shahabganji and I found Aurelia. It was amazing. We had exactly your point of view. After years we have learned, we are the community, we should write blog posts, maintaining plugins, and so on.
How many people are helping Aurelia by writing plugins/contents and …?
How many people here have clicked on the “star button” for the Aurelia 2 framework?
How many people here advertise/introduce/suggest Aurelia on Twitter/LinkedIn and other social networks?
How many people here made a useful issue or PR for Aurelia? (Just a useful suggestion no more)
The community of other frameworks did not emerge with a big bang. They have helped each other.
Again, We make the community no one else.
Comparison is never fair.
But that not on our controller, I would like to see microsoft to stop pushing blazor all the time to do web applications, and just support aurelia, this fast.design framework is another time waste, 0.001% of people would need that and some day micrsoft will move way like they did with silverligth.
Suppose no one is going to support us, what is our own decision? I am familiar with many other SPA frameworks. Believe me, I can not work with them even for 1 minute.
@zewa666
I am not sure whats your point is? Big problem with the community you are tackling here? Something nice and fancy ? what you are saying ? Anyway
@HamedFathi
Yes you are right. What I am doing is building an open source app with Aurelia 1 and switch to Aurelia 2, is a Front-End app for IdentityServer4. (Asp.Net Core, EntityFramework Core, Sql Server, etc and Aurelia as Front-End) So people who wants to start with Aurelia has complete app where they have Authorization/Authentication system available either they can use this app as a base or port the functionality whatever app they are developing.
Sorry if I complain to much, my intention is only to express my concerns about the slowness and stagnation that can scare some people and me included. I’m a developer a know how hard is give estimations when things are changing all the time and most of the work needs research.
I follow the aurelia framework for 5 years, used in 1 ou 2 small internals projects, I still have hope in a good future for this framework, I just wanted to see more deliveries over the year.
I guess it will take long time. Its stuck with the router then there are other packages like fetch and don’t know what other packages needs to be reworked before it can be released as Alpha. Its seems awesome but that awesome at the moment seems like mirage. And there is documentation.
The router pr is ready. Theres probably uncomfortableness with the “slowness” but it can explode anytime. We still got plenty of ideas and improvements to put in. Also, v1 is quite solid, and after all these years its still on par with many newer versions of other frameworks. So you are covered if you need to go as fast as possible for a new project.
I believe that is more due expectations, the first 2.0 version was on Sep 20, 2018 2 years ago and we still waiting an alpha. I don’t want to put more pressure, but what can I say???
Sorry about this, is not helping and maybe not motivating either. I just became very upset last years, many new frameworks coming all the time, sometimes creator A starts framework B, then leave B to start C, and then start D doing the same to C, and I’m not talking about aurelia.
It’s just how things are. Some years ago, It was ok to me, I moved to new projects all time to, no worries about make a project and tools evolve over the years, but last 5 years I stayed in the same project trying to make it alive for another 5, (some people is already 26 years on product). I became more aware of how ephemeral libraries and ecosystems are and how that can affect the maturity of your product, sometimes before you reach a production release there’s already a dead library that you need to replace it because is not compatible/maintained anymore.
Aurelia is the best frameworks to me not matter if is not popular or backed by a big company. Congratulations, and I’m looking forward to see next version.
I thought I’d try and give some more information on why the router is taking more time than any of us want. There are several parts to this, but here’s a summary:
The new v2 router is written fully from scratch. I tried to start with as clean a slate as possible and create a router that’d be quick and easy to work with while at the same time be feature rich. The result was a router that differs quite a lot from the v1 router. I had made a lot of choices that made it incompatible with some of the v1 core behaviors. But the router also needs to be able to support migrated v1 applications, so a “v1 mode” was a necessity from the start. In addition, I wanted fluidity between the two modes/behaviors so that you could cherry pick the parts you wanted between v1 and v2 features and behaviors.
The v1 router is, in my opinion, one of the best SPA routers out there. But its implementation has nowadays, through no ones fault, several problems. So while we wanted the behaviors of the v1 router available (if so desired) in the v2 router, it was important to not get its problems as well.
To complicate things, the v1 router doesn’t have enough tests for all its specific behaviors, details and variations. Adding features or making changes to the v1 router is something of a risky business because there’s not enough tests to guarantee that all the behaviors that developers might rely on is preserved.
For v2, we want to make sure the router is stable while still being changeable and tests is how we’re going to do that. Our tech lead and test expert Fred has added several thousand tests to the 400 or so basic ones that I had so that the tests now cover the fine details of v1 mode, the v2 mode and even alternatives in between them. Writing these tests have been very time consuming and there’s still some work left before they all pass. It’s not uncommon that tests take longer to write than the code they’re testing, but we didn’t foresee that it’d be this much work to get testing to a satisfying level. Fred’s work with the router tests has also revealed the need for refactoring and/or improvements in other parts of the framework which has further increased the amount of work.
There’s a lot of moving parts in this “multi mode router”. But we are now approaching a state where the same router can let you work with direct routing or with configured routes, use the v2 router’s dynamical principles and independent viewports or the statical principles and connected viewports of the v1 router. And even to a degree mix the behaviors and principles from the two routers into a mode that fits your application. We know you’ve been waiting. We’re sorry about that. Hopefully, you’ll find it worth it.
True, but let me explain a bit, from the user perspective, you can see more features with the same syntax in Aurelia 2 but in some parts, the behind scene is totally different just like Jurgen said: “The new v2 router is written fully from scratch.”
Making a new version with more capabilities but compatible is not easy, in addition, the team has decided to take the testing process more seriously than the previous version. Beside these, the world is going through a strange year (due to COVID 19) and many of us are/were having problems in our lives.
There are some other things that are completely new and of course challenging just like AOT (a game-changer) so we are not just upgrading the previous version.
Hence, you cannot compare it with other rivals, However, they also spend/spent a lot of time on some topics:
Vue 3 was supposed to be released with all the side libraries at the beginning of the year, but that did not happen, even though the volume of changes is less than Aurelia 2.
They changed their schedule several times and it is still not ready. (Not just the framework I mean)
Angular Ivy Renderer took around 1.5 years for the rendering part, not the whole framework. (Just to improve its infrastructure.)
React took a lot of time to release a new version (17 RC) without a new feature! (Just to improve its infrastructure.)
In all three of the above examples, their community has had many protests.
Vue 3: Some developers do not like the new syntax especially after canceling the class proposal (They had promised and then realized that it was not practical!)
Angular: A huge breaking change (just like always!) after Ivy Renderers.
React: Many programmers are upset about the lack of any new features.
I’m so glad we have you and you are so worried about Aurelia.
Finally, let me apologize to all of you (the whole community) again for the delays. I hope the end result makes you all happy.
I fully understand software development is like that, sometimes goes fast others to many stuff on the way to have a usable version. The mode to v1 should be a pain, I would consider a separated plugin as a temporary solution to people on v1, or don’t ship that support now.
You don’t need to say sorry, is normal.
Good luck.
I love the enthusiasm from the aurelia team and the community! And I understand that no-one is eligible in any way to deliver something. I’ve donated quite a bit to this project over the years and will continue to do so, I simply enjoy it that much. But please try and be more open about whats going on behind the scenes and why certain mentioned release dates can not be met. The original post mentioned what needs to be done to get to a pre-alpha release. I have clients that have products built on top of Aurelia and some have since migrated to other frameworks (not that AureliaV1 did not do the job but rather because no new developer wanted to learn an ‘old’ framework, it is what it is…). Perhaps a ‘short’ weekly update on where we stand, what needs to be done, and where we can contribute would be a great asset here. I’m a bit lost at this point on whether I should donate more, contribute, or give up altogether.
I’m looking forward to seeing Aurelia 2 and I understand delays. I had to re-write a lot of code from a previous developer that cost my team months and took me off of other tasks. Tests take a lot of time, so much so that many of us have to weigh out the benefits A lack of tests for some things isn’t the end of the world, but in the case of something like the Router they would be extremely important. With that said. Maybe backwards compatibility from day one wasn’t worth it right now.
I’m reworking a legacy application that has many external dependencies, our first go at it was to have minimal changes, but in the end that cost us more time than just forcing the pain on the other teams. In the end we ended up scrapping a lot of the original interfaces as we were limiting the future product too much. It is a balancing act and I appreciate you guys walking this tight rope.
The reason can be a bit related with that. I’m aware if Aurelia 2 since the first announcements, I know that there was no date, but when are choosing a frameworks because it’s new start or big re-write, so is not a good idea to start a new thing with version 1 if version 2 will be released in a few months, this can save you from migration problems at front. Its a bit risk to start serious work with a beta counting with a stable version before your timeline, but for prof of concepts or prototypes its ok.
The problems more about the sensation of low activity, to much to do and not so much resources.
Before some frameworks were labeled as one man frameworks, and people used that to evaluate the maintenance capacity for the framework. There’s always some fear of people endup in a project with the next knockout.js.
A lack of tests for some things isn’t the end of the world, but in the case of something like the Router they would be extremely important. With that said. Maybe backwards compatibility from day one wasn’t worth it right now.