How Yayoi Kaikei Online Selected Wijmo's JavaScript UI Library

_This article was originally published on August 29, 2016, in BuildInsider. _ There are a huge number of UI libraries for the Web, which makes it difficult to choose one. How did Yayoi, makers of PC accounting software, choose one for cloud service development? We asked them that, and for some background information. Insider.NET Editorial Department Shinji Kawasaki If you are using cloud-based services, then you must also use Web standard technology, including JavaScript. In general, web technology works well with Open Source Software (OSS), so there are many libraries and frameworks being developed as OSS. Many of these are UI libraries. Because of such diversity, there are many people who are trying to figure out which UI library is most suitable for their requirements.

So, how should one select a UI library?

To answer this question, we talked to enterprises that are getting into cloud service development about their experience in selecting a library for themselves. We tried to get some detailed insight into this question. This time we talked to Yayoi Co., Ltd. (hereafter, referred to as "Yayoi") which develops business software packages like Yayoi Kaikei, a PC accounting software package. When it comes to "accounting software", Yayoi is the first name that comes to the mind of many people. Along with packaged versions of software, Yayoi also provides cloud services like "Yayoi Kaikei online", "Yayoi white return online"(Image 1) and "Yayoi blue return online". Yayoi White Return Online screen (Account settings) As you can see in the above image, the design of Yayoi cloud services is similar to a desktop-based application, for example, Microsoft Excel. Did they use an OSS based UI library which has high compatibility with Web standard technology? The answer is “No”. They selected a paid product called "Wijmo" by GrapeCity. Why did they opt for a paid library (Wijmo) rather than going for a free OSS UI library? According to Yayoi, their motive was “to achieve good quality services at low cost”. How did they consider the issues that they faced in introducing the same? For the answer, we talked to Mr. Takeshi Hashimoto, Mr. Tomoya Kubo, and Mr. Yoshitaka Sawamura from Yayoi's System Development team to find out about their Web service development, including how they made full use of specific JavaScript UI controls. (Interviewer: Insider .NET Editorial Department Kawasaki Shinji/Digital Advantage Co. Ltd. Ichiro Masahiko, Collaboration & Venue provided by: Microsoft Japan).

What is the reason behind selecting a paid library?

Mr. Takeshi Hashimoto, Senior Project Manager, System Development Team, Development Division, Yayoi Going right to the point, we asked why they selected the paid Wijmo library for cloud services. The first point that came up was the "time limitation in creating controls from scratch," (Mr. Hashimoto). Then he mentioned the "evaluation and research that was done on three libraries."

Merits of Wijmo

According to Mr. Sawamura, the selection process has been going on since Wijmo 3 was introduced. They focused on the following things at that time:

• Speed
• Appearance and functionality of controls
• Reliable support service
• Maintainability

In “Transaction Entry Screen (Image 2),” a large amount of data needs to be displayed in the grid. Hence, speed was an important aspect for us (Mr. Sawamura). Transaction Entry Screen Mr. Yoshitaka Sawamura, Engineer, System Development Team, Development Division, Yayoi We were also interested in "Reliable support service." "Though there are many software packages available in the domestic market, most of them are just Japanese versions of products created by overseas enterprises that have their sales office in Japan. Obviously, support services will be provided with any paid product. But, in the case of Wijmo, it is developed and sold by GrapeCity, which has headquarters in Japan itself. Their development center is overseas, but as their headquarters are based in Japan, I think their support for Japanese users would be exceptional as compared to other companies. We got an in-depth (smile) response for our technical queries, to an extent we can’t even imagine with other products. As far as the responsibility in development risk of the product is concerned, there is a sense of security." (Mr. Sawamura). How did you evaluate the purchase value of the paid product? "We had experience in developing some controls for another product in the past. On calculating the total cost performance including the time required for development, we decided that it was quite practical to go for a high performance paid product. Since the source can also be seen in case of a JavaScript library, this was another benefit as programmers can learn by looking at the high-quality code," Mr. Sawamura said.

Issues in introducing Wijmo

There were some concerns as well in introducing a third-party component.

• Blackboxing third party components
• Handling the bugs in components
• Whether replacements are available on every version upgrade
• Learning cost

Among these, there was no concern regarding blackboxing as "Wijmo itself can be customized,"(discussed in detail later). This characteristic exists because Wijmo is a JavaScript based library. As mentioned earlier, Yayoi said there were no concerns regarding bug handling in the library, as Wijmo has their base in Japan. "Obviously, they handled the bugs, but they were also quite open to listen to and to understand our needs, which is something that is definitely not there in the overseas products," (Mr. Sawamura). Wijmo licensing is on subscription model, so there is no cost of replacement on upgrade. As far as learning cost was concerned, Wijmo is so simple that all the controls can be displayed with just few lines of code. Then, we could reduce the effort of developing the client side in Yayoi by creating Razor helper methods internally (discussed later). After overcoming such issues, and "after considering the speed of maintenance and support in future," (Mr. Hashimoto), they decided to go for Wijmo in Yayoi.

Development Environment

Mr. Kubo said that they have the following environment for cloud service development in Yayoi.

• Language**：** C#/JavaScript/TypeScript
• IDE**：** Visual Studio 2015
• Web server/DB server**：** Azure
• Client**：** all-important browsers
• Framework**：** ASP.NET MVC 5, Wijmo etc.

Mr. Tomoya Kubo, Senior technical leader, System Development Team, Development Division, Yayoi Instead of using client side frameworks like AngularJS etc., we use a combination of ASP.NET MVC 5 and Wijmo for server side rendering of the UI which is quite distinctive (using Razor for view engine). I also asked them which controls and library exactly they used. For example, most of the parts in Yayoi's cloud service used the FlexGrid control (Image 3). By using FlexGrid, "we could do various things like merging the cells horizontally, showing multiple rows as a group, placing a check box in a cell, etc.," said Mr. Kubo. As shown in the example below, they have a screen which is comparable to the desktop version of application. Use example of the FlexGrid control To achieve this kind of screen, a lot of controls were customized at Yayoi. The Calendar was one such control. "An accounting software package needs to follow the accounting period of an enterprise, for example with April as the beginning and March as end. We have done customizations throughout the application as per the accounting process of Japan" (Mr. Kubo). The overwhelming part is how this ComboBox in image 4 has been extended to a dropdown. Dropdown customized by Yayoi There may be people who will think "where is the dropdown?" The maximum portion of the screen above is a customized dropdown (red highlighted box). "It is not that we built our requirements to fit in with the third-party component. User productivity does not go up if we try to match our requirements with the features of the control. The keystone of our product development is to provide added value to users by customizing the controls," said Mr. Kubo. Moreover, this dropdown seems to be "even more powerful than the packaged version." "There are many users who are used to the packaged version of Yayoi and they look for a similar experience in the cloud service as well. We have put in a lot of effort for this," laughed Mr. Kubo. Yayoi also uses a calculation feature (Shown in the red frame in the following image. The calculation result is displayed in the right pane). "This calculator is displayed with the help of Wijmo popup. We developed the rest on our own. That is because a calculator is simply essential in an accounting software," (Mr. Sawamura). Calculator functionality Yayoi also used the CollectionView class. This class is mainly for handling data on the client side and is used with FlexGrid, etc. "In the case of JavaScript, generally everything changes to a string format. Isn’t it so? There is a collection feature in Wijmo 5. So, if you store some data in the CollectionView object, a number remains a number and a date remains a date. It is great that the data type is retained when data is taken from there and is passed to a function. If the CollectionView class was not there, you wouldnt know when a numeric value is changed to a string and is passed to the function which takes a numeric value as an argument. So, from this point of view in Wijmo 5, it can work properly with the static typing of TypeScript and therefore, it was possible to do type-safe programming," said Mr. Sawamura. There are other merits as well to the CollectionView class. For example, the change tracking feature. "As CollectionView class has a change tracking feature, only the data changed in the grid is passed to the server. As compared to using the FlexGrid control itself, there are many benefits of changing the grid data source into CollectionView," said Mr. Sawamura. Next, we will discuss the knowledge required to use Wijmo in a real product and the techniques used to customize the controls.

Know-how about using Wijmo

As Mr. Kubo mentioned earlier, third party components must be customized for product development. The version upgrades for Wijmo also need to be tracked. Although it is not necessary to follow the components' version blindly, the newer version will introduce new features, support new environments (latest browsers etc.), and provide bug fixes etc., so it is better to use the latest version possible to improve the overall quality of the product. However, there is a trade-off. Earlier in Yayoi, we tried altering Wijmo for expansion (This benefit is something specific to a JavaScript library, and is different from components meant for native applications which are distributed as compiled files such as DLLs). "While expanding, if one alters Wijmo itself, then the same customization needs to be done with the newer version of Wijmo as well, which is not an easy task," (Mr. Kubo).

Customizing Wijmo controls by inheriting

To resolve this trade-off, Yayoi inherited Wijmo controls and then handled the customization through these inherited controls. Currently, “customized inherited controls" are being used throughout Yayoi. By bringing inheritance hierarchy into the picture, when Wijmo upgrades, the upgraded content can be reflected in the extended controls as well, just by replacing the Wijmo files. Wijmo controls depended on jQuery at the time of version 3. In version 5, Wijmo evolved by becoming compatible with ECMAScript5 and removing the dependency on jQuery, which made it an easily inheritable set of JavaScript controls. Mr. Sawamura mentioned that this change also proved effective in using inheritance throughout for customization of the controls. "We started with the idea of using inheritance throughout at the time of Wijmo 3, but at that time there were not many members that were good in JavaScript, and we ended up altering Wijmo itself. But, in the case of Wijmo 5, the base changed to TypeScript and the dependency on jQuery was removed, so the inheritance hierarchy came down by one level. This also strengthened the idea of using inheritance."

Using the helper methods

As mentioned earlier, Yayoi's developed their cloud service application using ASP.NET MVC 5. Mr. Kubo says, "We created helper methods to use Wijmo 5 controls easily through Razor, which is a view engine of Wijmo 5. Our engineers use these controls through helper methods only." There are some merits to this approach. Mr. Kubo first mentioned that using Razor makes it possible to restrict the editable properties and usable methods. "In real development, engineers can change in between development cycles, and not everyone is thoroughly experienced with the controls. In such a situation, restrictions can be added to the editable properties and usable methods so that usage of a control can be restricted to an extent. This way, incorrect use of the controls can be reduced. It is a main bonus in the team development environment." So, it is OK if programmers are not used to the client side, because they can call the helper methods in Razor," (Mr. Sawamura) Another benefit is that screens do not need to be changed while adding a feature to the control. "Most of the specification changes could be done by using control inheritance and helper methods. Along with that, we could also reduce the effort while maintaining the quality (Mr. Kubo).

.NET developers and TypeScript

Wijmo is a set of UI controls with a .NET background; to the extent that their documentation mentions "ICollectionView interface of Wijmo is almost the same as that of .NET" . In addition to that, if TypeScript is used, then Object Oriented Programming of a class base can be done in JavaScript through static typing. That means developers who have been using C# or Java will also find themselves familiar with TypeScript. When I asked Mr. Sawamura about this he replied, "Quite familiar, it is easy to write code yourself and to get into the detailed behavior of Wijmo after you introduce it. Since they have their source in TypeScript, it is easier to read than JavaScript code that uses a prototype-based inheritance. " I asked about Yayoi moving the code base to TypeScript from JavaScript. So, there should be no issues in moving the code base? "There is definitely an effort of re-writing the code, but JavaScript code can be transpiled (converted) by adding options to the JavaScript code. So, it is not much of an effort right now," (Mr. Sawamura). Mr. Sawamura indicated that the important point at the time of migration is differentiating between, "Common code in the application" and "Code for an individual screen." "It is difficult to estimate the impact if the areas containing lots of inheritance are re-written by engineer who is not thoroughly knowledgeable about the product architecture. The risk involved is high in this case. Obviously, a developer with good knowledge should convert the common portion. On the other hand, the individual screen code can be handled by the respective developer in-charge of that screen as the impact is limited to a particular screen," (Mr. Sawamura). Naturally, migrating the common portion to TypeScript should be the highest priority. "If the common portion has been converted to TypeScript properly including static typing, then it is OK to go slowly with the conversion of individual screens," (Mr. Sawamura). When you get to the stage of converting screens to the TypeScript base, and try to use the converted common part from the screen side, it gets easier to convert screens as you get to know "what went wrong" through the type errors etc. that occur during transpiling the TypeScript code. After that, "You can even go stage by stage once you have shared the conversion policy as 'Let us match to the function arguments and property types on the shared side as they have been already finalized,'" (Mr. Sawamura).

Selection of technology

Currently, you are using ASP.NET MVC in Yayoi’s cloud service. Didn’t you think about introducing the latest client side frameworks which are trending these days? "Can't really say after selection (laugh)," Mr. Kubo. "At the time we decided to introduce Wijmo, options like Angular, React etc. were not that practical," (Mr. Kubo and Mr. Sawamura). "We always do research about the future of the platform and technology. Developers generally like the latest things, right? Even though everyone might be fond of the latest technology, we need to see whether every engineer has knowledge of JavaScript and which type of JavaScript they know as there is so much variety. So, it would have taken time to write the code in unfamiliar JavaScript library. We are testing Angular 2 as well, but again it is not easy to shift completely from a server side technology, Razor, to a client side technology, Angular. These points also need to be considered to adopt the latest technology," (Hashimoto).

Conclusion

In this article, we talked to Yayoi's development team regarding the journey they took when selecting GrapeCity’s JavaScript control library "Wijmo". We also covered their reasons behind doing so, and their ability to use Wijmo in practical development. Wijmo addresses the issues like "blackboxing/ bug handling/ version upgrade/ learning cost" which are there in the paid third party controls as it provides "JavaScript based source which can be altered/ reliable support as it is a Japanese company/ subscription model/ low learning cost." Moreover, Yayoi has tried to reduce the development team’s burden of client side programming as much as possible by using control inheritance and helper methods. In doing so, they have created a stable environment in which to use Wijmo controls. Hope this article will be useful for the engineers who are struggling with the selecting a UI library for development of their Web based products or services. Read the original article here. Copyright© 2017 Digital Advantage Corp. All Rights Reserved.