4 months ago we had a discussion on how to continue with admin UI development. The problems we face is that our admin is mostly written in PHP with old school design talking over hessian with Java backend. So you already see a lot of problems just in that sentence. Also we have a specific team that develops and maintains most of the admin parts so often they are pressured to fix bugs and deliver business critical features, which leaves us, development teams, waiting for months until our new admin requests are prioritised and finally developed. Until we have the admin we have to insert configuration from business for new apps manually which is time consuming and involves a lot of departments. This is just a tip of the iceberg... Imagine how it is to refactor Java code that is used from PHP?!
So what we figured out was that we want is to take the responsibility of developing admin apps ourselves for the products that we are in charge of and slowly start replacing existing admins and move them to the products that they belong to. This was just a first big step that we took, since most of us don't know how to develop UIs in general. The bottom line was that we wanted something that is easy to learn and use, since we don't want to innovate in this area and we want to keep focus on our area of expertise. The next question what we faced was: which technologies to use? This was also not an easy task ... We already knew that we want to go fully REST and only concentrate on admin UIs (intranet) so that pretty much ruled out a lot of stuff. We also decided that we want to go SPA (Single-page application). We didn't strictly say that we need to go SPA but this is was the direction we wanted to go. Naturally the answer to our questions was AngularJS, but I also suggested that we should take a look at ExtJS because it is probably simpler and better suits our needs. We also had few other candidates but they are not important for this story. And here the discussion started... I won't go into the details of the discussion but mainly everybody had their stand about the technology that they liked and everybody pushed strongly for their favorite without taking into consideration what we really needed or wanted. It was a personal taste war and everybody had their strong pros and a lot of cons for every other technology.
So what did we do?
But, not everything is perfect with ExtJS. First of all, it requires some more time to get to know it. This means a longer learning curve at the beginning! But luckily it is very well documented and there are a lot of examples. The other negative thing, for individuals and small companies, is the high licensing price! Yes, ExtJS is not free, unless you are using it in an opensource project. The strangest thing is that you have to buy at least 5 developer licenses... So individual developers are discriminated and ExtJS heavily relied on that people in the past so this is a big shame on Sencha for this decision, no matter what they say. Other downside that we faced is Sencha CMD which is not that good and pollutes your repository with unnecessary files. The whole project structure that you have to have, including extjs, sencha directory, etc. is just wrong. For every project we have 50Mb+ overhead in every repository because of this and what we only want is our app code! They should definitely work in this area and go more maven like and build the whole project locally and not requiring the whole structure.
In the end we are quite happy with our choice, it helped us keep focused on what is important for us and on the other hand we now control our own UIs and are able to deliver functionality to business much faster and with better quality! The UI technology evaluation and time to adopt it was a bit longer than we expected, but it was worth going into this direction. Now we have the whole product development, from top to bottom, inside our team and we are able to control, maintain and change it more easily and with much lower risk.