True - it’s quite a good idea. Could certainly help with on-boarding. Not sure what it would actually look like though (the facilitation of it - not how it actually looks!). All I can see in my head is including a css framework by default (bootstrap, foundation, bulma etc) - but if you do that, it’s really simplistic to add on any theme that’s build on the base css framework anyway.
Also, does it then become a risk that Aurelia apps ‘always look the same’? I guess that could be a good or bad thing really, depending on one’s viewpoint.
Admin themes? Like for example the Now UI Dashboard theme by Creative Tim? Here it is up n’ running (with live updating charts and more) with Aurelia: The Costas project
I suspect there is a disconnect between what the leaders think and the mainstream developers thoughts applying Aurelia in leading edge applications. Not everyone is a guru and many have lives with families to support. Aurelia has been developed for over 10 years so can hardly be classed as new just as Angular (and others) would similarly be classed as mature JavaScript frameworks. Only the most passionate developers generally have the time and enthusiasm to harness the most of most frameworks and focus on the most useful aspects. Clearly there are ground breaking features in the latest releases but there are also expectations that needs to be realised.
The feature which sets Aurelia way above all the others is the binding functionality which automatically works out of the box (and at all times) out of sight and also out of mind but working seamlessly and continuously in all the developed applications. This is largely undersold and indicates a need for highly focused effective marketing to open source communities (and others).
All developers are used to downloading applications, updating to latest versions, installing plugins, generally without fuss for most environments. I, for one, used Visual Studio (all versions from 6 onwards), occasionally needing repair installation, but always able to produce an installation that works within a short interval of time. Typically code I wrote umpteen years ago in C++ still works today. There is no need, and should be no need) to configure HTTP parameters, C#, TypeScript Version numbers to write C#, TypeScript code to produce a working application or one that continues to compile, build, and run over a period of time either with changes to code or data or the dependents of said tools. Developers write code and are dependent on Integrated Development Environments, Coding Frameworks to keep track of dependency configuration issues in the background without developer intervention. This lack of robustness explains why Aurelia is not popular amongst the majority of the development community. Lack of documentation makes this worse since it is easy to do Hello World Examples but anything interesting takes a lot longer with a disproportionate time spent debugging problems that should not happen. For example, Webpack failed to build and run our Aurelia applications 3 times during the last 6 months when Visual Studio was updated to latest version even when no code was changed. It took ages to get things working using NPM dependency variations to get things working again.
I would suggest a pruning exercise involving placing downloads and more detailed documentation in one place ensuring everything works first time. If a developer wants to add authentication there should be code that works not just a guide saying do what you want to do but not advising what you want to do… If someone wants to update to latest router, then the download should work and so on and so forth
I think you adressed here some very important topics. First users dont care whats the issue they will likely blame Aurelia for it. E.g the hassle with Webpack updates caused issues for most mainstream frameworks. Another one is that If basic fundamentals of JS are not well understood one might think its the frameworks fault.
The more frameworks and tooling you see the easier it becomes to spot differences and also to apply higher level concepts. E.g DI patterns work in a similar way in most implementations. Knowing that you cant use an Interface as key requires you to know that they get transpiled to nothing, as such they cant be used as a key.
This knowledge on the other hand creates a certain bias. You tend to think that most errors and their fixes should be self explanatory but they arent for fresh new users. Just a perfect example is that other topic about updating Aurelia deps. Npm update is the straight forward answer but there are so many subtleties that are hard If youre not used to the way the framework operates. So even if more details are requested we might produce non satisfying content just because of that bias.
I personally think the only way to solve this is having the community help here. Go forward create a PR and many people can work together on the refinement. The core team alone cannot create all the content needed. Not because we dont want to but because we’re sometimes not even clear whats missing. Different wording can also mean a whole world. For instance Im no native english speaker but my writing is even worse. So subtleties are lost due to lack of my skills. On the other hand I had several people contribute small PRs to the Aurelia Store plugin where they just changed the wording and the resulting docs are so much better.
We try to do our best. Honestly though sometimes we maybe are blind for the obvious so whatever help we can get in the way of PRs is endlessly appreciated.
If one is not sure how to help maybe lets try to do it this way:
Take a look at this sample topic Another call function from custom element question
The docs for it are clearly not enough. Once the topic has enough satisfying answers one can pick it up ans create a PR rephrasing the docs, adding more samples. After that post the link to the PR back to the discourse topic. That way more people will review the PR and chances are we get that done in a way with having the feature fully and easily documented.
As an engineer, we have our taste on tech. We choose not only based on popularity, but also on excellence of tech. Excellence is very personal, it is based on our experience and knowledge. To me, it requires quite experience of SPA design to really appreciate how thoughtful Aurelia is.
When our choice doesn’t match the majority of the industry, we have two ways to react:
we felt the pressure from our colleagues, job opportunities, we jump to a bigger ship even when we don’t really enjoy.
we stay true to ourselves, contribute to the tool/lib we enjoy, show the spirit of open source which brought us all the fantastic tools and our jobs.
Sure the second way is harder. We have less job opportunities, less weight on resume. But to me, this is the most enjoyable way. And that is why I choose to be a programmer: I enjoy expressing myself, honestly in my way.
Don’t be afraid to be minority, believe yourself. Minority defines diversity.
I’ve followed Aurelia from the early days and fought the many hype trains of React, Ng2 and Vue and tried to pressure decision makers to adopt. But after running into so many issues with any aurelia bootstrapping style( systemjs in the beginning -> webpack -> cli -requirejs -> webpack) and upgrade paths( I dread the day I need to update the aurelia versions or some minor dependency triggers a change ), I gave in and tried out Vue and was painfully impressed.
We have a 50k+ lines of typescript code SPA in Aurelia and am already dead worried on the vnext update and how on earth we’ll be able to transition to that considering the last few version bumps destroyed basic repeater binding functionality and we had to override aurelia prototypes just to fix our production builds.
Coming from older non-SPA projects, and wanting to continue using the built-in tooling of Visual Studio and Razor, it’s tough for someone to jump into these frameworks and then all the sudden needs tons of external tools with mutliple inter-dependencies and not really understand why we can’t just download a JS file to include in projects - or even multiple JS files - that “just work” instead of having to go through pre-compilation or some other non-sense with “Loaders” when for most non-SPA apps you don’t even need Loaders (until it becomes more complex with multiple modules being shared across pages). I’d love to see an example where I could JUST use Aurelia’s bindings - no loaders, no CLI, no pre-building, nothing - just drop a “aurelia-binding.js” on a page and “wham-o!” it works!
I’ve understood how Aurelia binding works after reading for 30min. However, months of work have gone into getting Webpack (a project designed for straight JavaScript/NodeJS coding which never had any intention of working with VisualStudio - it was just “bolted on” or “shoved” into it) working the way I need it to, and then I finally gave up on it because it cannot support different versions of JS tooling for different pages… i.e. it was designed for SPA apps only.
So, maybe the slow adoption is coming from the other side of the house where developers who are not going to be doing SPA apps, or might be transitioning from a legacy/non-SPA app don’t have the bandwidth to just create a whole new app for a company, spending 8mo - 1yr getting it to work right before it can be deployed. Stakeholders want to see things working, they don’t want to hear that it’s tougher than you thought to get something working, but if we just stick it out, it’ll be worth it in the end… And so, in the end what happens? You go right back to jQuery / knockout because… “it just worked”.
Many years ago, I started with knockout based on exact same need: make legacy pages work better.
In long run, mixing legacy backend rendered view template with knockout created lots of complexity on maintainence. I gradually switched to totally refactoring frontend to SPA. This requires refactoring both frontend and backend together, but it is definitely worth. Decoupling frontend and backend logic, makes new feature implementation much easier.
Obviously Aurelia did not target that (huge) refactoring market that knockout/vue/react fit better. I believe vNext is trying to be more versatile and flexible.
I shared some similar pain that @kukks mentioned. I did have some nasty issues on repeater and if binding over the years, which I have to monkey patch some code or change my code to bypass some bug.
I learnt to keep my view template usage simple to avoid challenging aurelia. For example, I try to, as much as possible, avoid using if/repeater on template tag, avoid containerless. This might sound bad, but it is not as bad to me as my experience with react on rendering performance, and “glory global state dispatch” when I just want to open a dialog in current context.
vCurrent has some tech debts that would not be fixed easily. vNext is trying to clean it up from ground. But same as @kukks, I don’t want to migrate my production apps to vNext unless the upcoming v1-shim bridge works really well.
I will probably stay on vCurrent for the lifetime of my existing apps, unless the company I am working for became very successful
Some interesting ideas here. For years, programming procedural back end languages such as C# has improved by reducing lines of code written by refactoring and other techniques (eg separation of concerns). The same, of course, goes for TypeScript which is incredibly powerful. It should not matter what version of the language used as long as the core framework (in particular binding) continues to work. Sometimes plugins are nice to have but installing/updating them should not cause the core framework to fail. Net Core will probably stabilise at version 3.0 (2.x is still problematic) so VNext a good time to update everything at once rather than in small stages which does not work well with VCurrent Aurelia
vNext might have a nice second chance as .Net Framework is phased out over the next 10 years in favor of .Net Core (according to the road-maps they have mentioned at ms conferences).
All depends on being able to hit the market for those transitions though along with having the stability to be chosen at that given time. Though you might find a lot fewer early adopters then before due to the history.
Oh I’m sure it still has a whole host of issues to go through before then, all early libs have their issues. Probably 2-4 years until decent stabilization which could coincide with stable vNext, though it’s the web so everything could be different by then.
They certainly are pushing .NET Core in everything now though, at least the speed in 2.1 is so much better now.
Speaking from the perspective of someone who picked up Aurelia after it was announced as an alpha version, it comes down to a few things.
Documentation. When Aurelia launched it had no documentation (it was an alpha), then we finally got documentation and anyone who has written documentation before will tell you, it’s extremely hard, evident by the fact Webpack had notoriously bad documentation right up until Webpack v3. The next version of Aurelia is going to have solid documentation.
Tooling. When Aurelia debuted, Webpack wasn’t the go-to choice for all developers, the ecosystem was really fragmented and you had people using Gulp for some projects, still using Grunt for others, Babel as the transpiler of choice. Then Webpack started to emerge as the popular choice, people started using TypeScript over Babel and things got complicated.
Getting started. Related somewhat to tooling, but the barrier to entry was a little higher than React or Vue which could work using just scripts. There is now official bundle scripts for Aurelia vCurrent and vNext will have these as well. Now people can get started without any tooling whatsoever.
Examples. This comes back to documentation, but the lack of examples on how to do things like work with other libraries or add in authentication was definitely another barrier. When Aurelia launched people were still using jQuery plugins quite a lot, and each had its own quirk for integration. I am currently working on vCurrent examples and vNext will also have numerous examples to learn from as well.
Fortunately, all of these things are easy to fix and have already been fixed, or will be fixed. The reassuring thing about choosing Aurelia is that although there have been some tough learning experiences for users and the team, the core team is passionate, acknowledges these downsides and is moving on to ensure they are corrected.
If you look at the repo for vNext, you’ll see there is some seriously good stuff coming down the pipeline. The amount of work already done is impressive and some of the smartest minds I have ever had the pleasure of knowing are doing amazing things for vNext.
Your mistakes don’t define you, how you fix them is what defines you.
We have to remember that not even Vue was that popular when v1 was released. It took serious work and a rewrite to v2 for Vue to achieve its success. Also helped by Laravel adopting it as an official library of choice for Laravel projects. It is also believed Vue’s Chinese documentation and a foothold in the Chinese market also helped it become successful. But the point is its first release wasn’t as popular as its second release.
Redemption is coming and those who stuck around and persevered through the tough times are going to be glad they did.
