2017: Web Application
Accounting is too often about arduous, repetitive work. Too much of crunching numbers, amounts, going through dozens of tables. We are about to change it. We are arbitrue — virtual accounting assistant, a new product targeting the UK market.
As a team behind infakt.pl— we’ve been helping Small Business Owners from Poland with invoicing and accounting for years. Our success is made up of many factors, but we know that one of them is a well designed, intuitive, and usable web application.
Upon the challenge of a new project, we set our bar even higher. In 2007, when we started with inFakt, we have adopted Ruby on Rails. Today we know we’ve made a good decision. 10 years later, in 2017 we are creating a new application and we are facing another choice. We want to be able to say the same in 10 years.
New web application in 2017,
You do not have to be a watchful observer to say that in the past few years there has been a lot going on in the world of frontend. Some time ago it was enough to generate a static page views on the server. Then, it has became a necessity to modify the page (DOM) on the browser side, which has resulted in the appearance of jQuery. Asyncrhonous loading of certain elements with AJAX was introduced afterwards. You probably know this story. At some point, we wanted to keep the user informed about new events, such as news, updates, or booked files, using Web Sockets. The concept of Single Page Application — SPA has evolved naturally.
as a Progressive Web Application,
Due to widespread adoption of mobile devices, social networks and desire to unify the experience on various platforms, a new list of rules emerged: defined as Progressive Web Application. Today, whether we like it or not, the best applications today are:
- Progressive — They work for anyone, regardless of browser choice. Designed for constant adoption of new technology and continuous development.
- Responsive — They work on everything. Computers, phones, tablets, and even fridges, if applicable.
- Connection-quality independent— With background services that can defer sending data until connectivity is restored, they work offline too, so the user does not feel that his connection is slow.
- ‘Feels like an app’ — They look and act like an application, thanks to functional separation of logic and content.
- Up to date — Always updated to the latest version, due to silent updates performed by the ‘service worker’.
- Secure — always work by secure transfer.
- Discoverable —visible as an ‘application’, thanks to the presence of W3C manifest and background registration, They are listed in the search results as applications.
- Re-engaging — Make re-engagement easy through features like push notifications.
- Installable — Allow users to add apps they find most useful to their home screen without the hassle of an app store.
- Linkable — Available on the web, as a link that can be shared.
Adopting those qualities to applications development, moves a large amount of logic from the server to the browser. This transforms the role of browser from the HTML interpreter to full-fledged platform. Such a change imposes many challenges for designers, developers and web browsers. To facilitate the creation of applications new wave of supporting software in form of ‘front-end-frameworks’ emerged.
Experience has taught us that if we want to be competitive, we must always choose the cutting-edge technology. Given the trends and the fact that from the user’s point of view, SPA applications have undeniably better usability and speed — and these are the values we always strive for. We want arbitrue to be at least as successful as our first product. We know that design and choice of front-end technology are keys to some of the keys to achieve that. But how to choose make the choice?
working with REST API
inFakt has experience in creating backend with REST API with Ruby on Rails. Being very found of this technology, having experts working with us and being heavily involved local Ruby community, we decided to stay with it. This defines the basic requirement that must be met by the technology in front-end application — it must be convenient to work with REST API written in Ruby on Rails.
To keep the user constantly updated about new messages and notifications we decided that the arbitrue would use WebSockets. Rails supports this technology, using ActionCable gem. We know this technology and would like to be able to use it in our front application.
based on framework…
For a small team writing such an application from scratch, without the support of any library seems to be recipe for disaster. Properly selected and used framework, on the other hand, would enable rapid creation of modern application and give the possibility of effective project implementation. A lot of available components, plugins and conventions can be adopted to development of the application, improving transparency and making code it easy to reuse. Acting in accordance with the recommendations proposed by the library, we write code that is maintainable and friendly. On the other hand, frameworks often impose architecture and writing style, which may not always fit into our product vision.
By choosing a library we attach not only to technology, but also to the ecosystem, consisting of plugins, tutorials, documentation, examples and support. To make this choice as conscious as possible, we decided to compare the three most popular front-end frameworks. The first action was to narrow the list of candidates. For this we have used the site stateofjs.com:
The blue part of the bar is responsible the interest in technology, red is about experience. Less saturated colors indicate lack of interest, bad experiences, and saturated stand for live interest and positive experiences. According to data, Angular 2, Vue, and React attracted the most interest. The greatest satisfaction was brought by React and Vue.
As Angularjs (1) has been replaced by Angular 2, which was then deprecated with Angular 4, we will compare latest version.
Such results allowed us to narrow the candidates quickly to: React.js, Vue.js and Angular 4
We will soon publish a more technical article comparing these technologies.