In a time of expedited growth, how well would an AngularJS platform cope with technological developments stemming from market shifts and customer requirements? With a wide customer base, would it be wise to invest in this costly development at this point in time? One startup has already answered this questions.
Almost every guide covering AngularJS, starts out the same: You don’t convert an AngularJS platform to an Angular one; rather you build from scratch. The reason being, It’s not a new version to an existing product, but rather an entirely new one.
The ad-tech industry is dynamic characterized by frequent changes, both technological and regulatorical. Staying afloat require companies agility and low response time to market shifts and trends both on the end product and development practices. Furthermore, ad tech companies experiencing growth must examine their product development infrastructure scalability.
This is exactly the case for Cedato Technologies, a startup company founded in Aug 2015, and by 2016 concluded that it has to re-examine its current infrastructure and scalability; Would an AngluarJS based platform hold the test of time and allow the necessary technological developments stemming from current and future Market shifts and Customer requirements? On one hand, the company is just starting out, on the other, the massive growth they experienced occurred in so little time that they need to prepare for a similar pace in the future. With that in mind, at the beginning of 2017 the company decided to move forward with updating the platform’s dashboard that up till then was AngularJS based.
What are the differences between the technologies?
The variety of frameworks we have today, makes developers feel like a part of an impossible race. It’s hard to keep up, not knowing if whatever’s trending today, will stay relevant in a year. Many times the pressure of finding an immediate solution, outweighs the importance of planning the infrastructure correctly.
In the past year, Google have standardized Angular, pushing aside AngularJS. In practice, there is time until the change will be completed, but lets understand what is the difference between the two technologies and why moving to Angular is important?
AngularJS is like jQuery and React. It’s one JavaScript file, that does a lot of magic, but it’s capabilities are still limited. If you want animations or a routing system, you need to include dedicated JS files. It’s nice, but it’s not enough. Angular, on the other hand, is an entire framework, that includes at its core many great features. Especially if you’re working with Angular CLI. When you create a new project, it comes with a Webpack, testing-related libraries, so that you have the ability to create components and other entities very fast.
This helped us build a beta version in no time, and check each feature in our system, with confidence. So you can implement and enjoy the same features we’ve laid out the process for you.
Why did we choose AngularJS?
Let’s start with the good news, switching between the 2 technologies didn’t require a long adjustment period. Many of Angular properties and terms are familiar to whoever worked before with AngularJS. That said, it did require changing perception, getting a wider perspective of the project.
Prior to finalizing the move, we tested out alternatives, such React and Vue.JS, but the basic abilities of each were lacking. The language were less readable and above all writing js, HTML and CSS in the same file looked like a generally bad idea.
The tools that for us made Angular the obvious choice were Typescript – The language you use to write angular, which is in fact an upgraded javascript – and the Angular CLI (Command Line Interface) That comes with it. These properties allowed a simple development process, with a well organized file built , that will enable new team members to dive in pretty quickly. Indeed processes that were once complex such as modules and components were now easier to create.
Since the development environment is quite new, there aren’t as many stable modules in npmjs for components that are relatively trivial, such as fate picker or Grid-table, therefore, we had to create pretty basic element ourselves from scratch. That said, there are a lot of guides and documentations as well as a wide support from Google and Microsoft, so help was there when needed.
Mobile-first & PWAs
The mobile-first approach isn’t new, nor is it relevant to Angular only. In our case, the system includes very wide tables, heavy reports and detailed graphs. Using it via a mobile device, wouldn’t be as intuitive as Desktop to any of our clients. But in reality, the requirement for accessing via mobile is bound to happen sooner or later. So, we set the goal of delivering the best UX, and adjusted our design and features to the browser size and the device itself. Next, we researched Progressive Web Apps, and understood that we could take it a step forward.
In short, a Progressive Web App is a web app which can be installed on a mobile device. Once the user opens our dashboard on their phone, the user is greeted with a “Add to Home Screen” prompt. If the user approves this operation, the dashboard is installed on the users’ phone, as a standalone application, and not within the browser.
In terms of UX it seems as if it’s all about a click of a button, however on the programming level it means that you need to meet a list of criterias that will enable transforming Web app to progressive.
The criterias among others are working in a secured server (https as opposed to http) taking into account browsers where the js. Is turned off, as well as meeting one of the most important criterias – applying service worker. This application enables pulling data that are cached while there is no available internet connection. Meaning, when using the app offline the user will still have access to data and reports that are up to date up to 4 hours before. In our case, these abilities are critical to our platform that her main application is issuing reports , analyzing data and graphs.
By planning ahead and acknowledging that mobile accessibility is a must, we could provide our customers with a platform that is accessible from any place and time. we wouldn’t go as far as saying it’s a perfect replacement to Native Apps, but for us it was a great solution, allowing us to deliver another product to our customers, without investing time in Android/iOS development.
As a technological company the ability to foresee trends in terms of product and development practices is of the essence if you want to stay relevant.
The variety of frameworks available today, makes developers feel like a part of an impossible race. It’s hard to keep up, whatever’s trending today, will not necessarily stay relevant in a year. This is exactly the reason why the research phase is as important as the development stage, saving both time and money in the long run.
Therefore, today, we can say we have a modular application, in which every component and service are designed for a very specific purpose. The file-structure makes more sense, newcomers will have an easier time to dive in, while meeting the latest standards, set by companies like Google and Microsoft. So it may be hard to know what’s gonna happen next year, but at least we know we won’t fall short.