How is development on Acumatica Modern UI going?

#1. There were reasons to select Aurelia as a frontend framework and during the evaluation the big three were looked at as well. Aurelia suits Acumatica’s requirement better. Whether it’ll stay the UI framework in the future or not only time will show, but currently there are no plans to switch from it. 

Just to clarify here. The current switch is painful because not only the frontend framework is changing, but also because all the backend-frontend interaction is changing as well. In comparison, switching from Aurelia to e.g. Vue would be much simpler since the frontend-backend interaction is the same. 

#2. At least from what I see, the transition is pretty straight forward, so there is not much to really discuss. There are some issues that developers come to support with, but other than that the transition from aspx to Aurelia based definitions are just replacing <px:Grid runat=”server” id=”grid1” ...> with <qp-grid slot="A" id="grid1" ...> in html. Of course it’s a bit more complex than that, but it’s still not something that you can really discuss since it’s mostly a linear transition. Also, it’s only now going to the stage where we do recommend to start development with the modern UI.

#3. I’m not sure how this is related, tbh. I mean, there are some performance issues in specific places, that are fixed by specific query optimizations. But there is no “fundamental” or “architectural” flaw in the design. So, the whole “performance problems related to the DAC and inefficient querying of SQL” does not really make sense to me. 

There has been discussion amongst the developer community regarding the new UI. But the real world benefit of messing with it in beta is rather low, IMO. There will be time for that when it’s released in production. Plus, Acumatica has already built some tools to assist with the transition, and why do something manually when you may have a tool to do it for you 😀

#3. I’m not sure how this is related, tbh. I mean, there are some performance issues in specific places, that are fixed by specific query optimizations. But there is no “fundamental” or “architectural” flaw in the design. So, the whole “performance problems related to the DAC and inefficient querying of SQL” does not really make sense to me. 

If you look the performance hit from the DAC and the crazy sql queries that result, there is a lot of performance impact from coupling the middle tier to the database with BQL and the DAC. Again, we live in an asynchronous world, and you are stuck on a largely synchronous thick client middle tier. The performance impact is substantial, but unacknowledged. You are trying to make up with it with caching, but ERP data is fluid, and caching only can take you so far. There isn’t enough server power available to solve these problems, and you guys won’t fix them on your end.

AC running very slow on local | Community

​@rosenjon 

#1. As far as I know, the main reason was the results of prototyping. There were several prototypes prepared and the code was the most straightforward with the Aurelia one. Also, given that Aurelia is relatively small compared to the other ones, it’s easier for Acumatica to influence Aurelia’s roadmap if needed. 

#2. Let’s break this question into two parts. 

Part 1 - migrating existing forms to new UI and preserving the functionality. Yes, it’s basically replacing one definitions with other definitions. There is also a tool that just does that automatically. A developer may want to review the resulting form after and maybe move some things around for a better look and feel, but that’s basically it. 

Part 2 - building “new and exciting” stuff with it. The new technology does provide more flexibility and easier control over frontend. So it’s easier to build some interactive elements and stuff like that. On the other hand, the set of ERP controls is mostly stable. We don’t see a lot of need for “unusual” controls and behaviors. Most ERP forms are basically a set of fields, a grid and a couple of buttons. So, to summarize - while it’s easier to build an interactive UI, the biggest chunk of “modern UI development” is just putting the existing UI elements on a form.

#3. I’m still not sure what the issue is here. If a developer creates “crazy” business logic, it results in “crazy” BQL and “crazy” SQL. If a developer creates simple business logic, it results in simple SQL. BQL by itself does not add complexity to the generated SQL queries. 

Yes, there is some performance impact when converting BQL to SQL and when converting SQL results to DACs. But that’s just the reality of things. Any ORM framework has this impact. I’m not sure what alternative you see here.