Technology selection is a big topic. For startups, in order to adapt to the pace of business, “flexibility” and “high development efficiency” are the two most important points in technology selection. These are two of the problems that have been most addressed by new technologies emerging during the boom years of front-end technology. However graphite as a document with a lot of rich front-end application of enterprise users, complex forms, documents, and offline synchronization logic makes us for front-end technology stack engineering and requires a high degree of stability, considering too much new technology often ecology is not yet perfect and related “best practice” lack of validation, our choice of these technologies is relatively cautious. All the technical selection of graphite document front end team is also considered around the above two points.
Technology stack selection
Graphite docs front-end team includes both desktop and mobile Web front-end engineers, as well as iOS and Android App developers. The following sections describe the stack currently used by the graphite documentation front end team.
Site: the React
Graphite Documents is an online office platform that allows users to write, chart, share and discuss in real time. As figure 1 shows, the web version as a whole is relatively focused but very complex. Graphite Document Web edition was a non-single page application built on jQuery before 2015, and the user had to reload the entire page with every click, which was a very bad experience. Moreover, libraries like jQuery have a low level of abstraction, and their complexity increases exponentially as the amount of code increases. They are not suitable for large projects, so we decided to introduce a framework to solve these problems.
The framework of The Three Kingdoms
At that time, JavaScript front-end frameworks showed a three-way rivalry: Angular, React, and Vue all held the mainstream position despite their different development trends. Therefore, we hope to select the core of the front-end technology stack of the future graphite document web version from the three frameworks, which can not only improve the development efficiency and reduce the maintenance cost, but also ensure that the new technology stack is relatively popular in the future and easy to recruit talents.
Angular is the most widely used of the three, and several members of the team have Angular development experience. But on closer analysis, Angular 1 already smells a bit of decline, and Angular 2’s future is unclear. Vue, by contrast, was on the rise and showed great potential, but the ecosystem was still immature at the time, making it a risky choice as the core framework for the Web version. React, which has good potential and a relatively active community, became our last choice. In addition, React Native had been released at that time, and the related ecosystem was developing rapidly and gradually prospering, which became a significant weight in favor of React.
React changes
React requires a higher level of JavaScript engineers than Angular and Vue. Especially in large projects, it is easy to write code that is difficult to maintain or performs poorly if you are unfamiliar with React. In the early days of the React migration, only a few people on the team were exposed to the framework, so we went through a period of “pain”. For example, the incorrect use of shouldComponentUpdate made some errors difficult to track and debug. However, with people’s continuous practice, React has gradually brought a very positive impact on project development. The efficiency of developing new features is significantly improved, and with componentization, the division of labor between teams is clearer and the code is easier to maintain.
Mobile: React Native
React Native had just been released when the team decided to go all-in on React in 2015. Although React Native is not the final reason for us to use React, it also foreshadows the selection of mobile terminal technology and the construction of graphite document front end team.
React Native to React Native
In 2016, both our iOS and Android apps were developed using native languages (Swift and Java). With the increasing number of users, users have more and more functional requirements for the App, one of which is offline support. Offline support is a very complex feature for the graphite document scenario, dealing with moving, creating, deleting, and synchronizing permissions of multi-tier file structures while offline. When discussing the technical solutions, we found that it would be very expensive to re-implement it on every platform (including our website).
At that time, we were doing the new version product design of mobile App, which involved a lot of product changes. At that time, the back end was also undergoing data interface reconstruction, which also depended on many changes of mobile terminal. Therefore, we came up with a plan to use React Native to rebuild the existing App and started the investigation immediately. The results of the survey were very optimistic. Although many people claimed that React Native had many problems, we also saw some exciting successful cases. Considering that the technology accumulation of the whole front-end team was in the React stack at that time, and our mobile App development engineers had a good front-end foundation, we finally decided to completely switch to React Native.
React Native is right and wrong
The React Native graphite document has been available for iOS for three months, and the Android version has been available for one month. During this short period of time, we received a lot of positive feedback from our users. As heavy users of Graphite document, we often use graphite document mobile App when we write technical documents, read and comment on product requirements. In terms of actual experience, the version developed by React Native is not weaker than the previous Native App in terms of fluency. At least in normal use, the performance difference is not noticeable to the user.
As for React Native pit, the actual development was smoother than expected due to too much listening during the previous technical research. There are two main problems: one is performance. For example, we used NavigationExperimental before. In a recent reconstruction, we fork the React-Navigation and add some expansions on the basis of the original functions to adapt to our complicated navigation requirements. The refactoring works well on most models, but on some low-end Android phones there is a noticeable difference in performance compared to native components. This component is now open source on our lot: https://github.com/shimohq/shimo-navigation.
Another performance issue we encountered was caused by the list component, where the officially provided ListView and FlatList could easily become a performance bottleneck in the case of large data volumes (the file list entries on the desktop in Figure 2 can sometimes be quite large). For this reason, the current file list is developed using native code, and we will do a generic native side template rendering component to render the list shortly. However, in general, React Native’s performance is satisfactory, and it can be optimized in some slow places.
In addition to performance problems, the React Native interface is often not provided by third-party SDKS. That’s when we need to do some bridging on our side. The process itself isn’t that complicated, but it might be a bit of a struggle if React Native engineers don’t have any Native development experience. Therefore, in terms of team composition, although we no longer need full-time iOS and Android development engineers, and all new business functions can be realized by JavaScript engineers, we still prefer React engineers with native application development background when recruiting. At present, many of the engineers in our mobile client group are good at React/Redux as well as native development knowledge on iOS or Android platforms.
Packaging tools: Webpack & Rollup
The packaging of the graphite document master site is achieved through Webpack. Webpack provides a powerful one-stop solution that enables static resources such as JavaScript, CSS, and images to be integrated or unpacked with simple configuration.
Some independent internal libraries are packaged using Rollup, which supports Scope reactive, and generates significantly more readable code, but more importantly, smaller code packages and faster (though negligible) runtime. However, Rollup still falls short in some areas (especially in development and debugging), making Webpack our default choice for new projects.
We’re also keeping an eye on Facebook’s recent announcement of Prepack, a JavaScript code optimization tool. Through experiments on several internal projects, it has been shown that it can improve the performance of specific code fragments. We didn’t use it in production because it was still in early development.
Code specification: Standard
To improve the productivity of a team, it is necessary to improve the way the team works together. Uniform code specifications can greatly improve the efficiency of code communication within teams. On a team, different engineers have different coding preferences, such as the classic JavaScript question of whether to write semicolons or not. In fact, these code style debates don’t mean much. What really matters is the determination and strict enforcement of a uniform code style. A uniform Code style can significantly increase the speed at which everyone on the team understands Code, leading to efficient Code Review. When multiple people are working on the same project, there are no meaningless Pull requests to change the code style.
In the graphite document, we used Standard as the benchmark specification. The idea behind Standard is not to configure and stop arguing. It specifies a number of code specifications, such as the absence of semicolons and the uniform use of single quotation marks around strings. The reason we use Standard as the benchmark specification rather than using it directly as a lint tool is because standard doesn’t impose stricter rules on certain rules, such as whether or not Spaces are needed inside braces, so we define a number of additional rules based on standard rules. The goal is to allow everyone on the team to understand the code without being distracted by the noise introduced by subtle differences in code style. Of course, when specifying these additional rules, we agreed that “new rules should not conflict with Standard’s rules,” which kept us from getting bogged down in endless discussions about code style.
Technology stack and team building
The technology stack and team building interact. The technical selection creates the functional structure of the team, and conversely, the specific situation of the team will put forward different requirements for the technical selection.
Prior to embracing React, at least three developers (i.e. website front end, iOS engineer, and Android engineer) were needed when developing any new features. Everyone’s understanding of requirements may have some deviation, resulting in relatively high communication costs. With React, because all three major platforms used the same technology stack, a lot of code was reused and shared, allowing us to explore new team building models. Currently, the graphite documentation front end team is gradually becoming a cross-platform team. Specifically, each product requirement is handled by the same front end engineer, who is responsible for the development of the web, iOS and Android versions of the requirement. In this way, the efficiency of both early requirements discussion and post-development validation and QA process can be greatly improved.
With the rapid development of the graphite documentation front end team, we have been thinking about how to better adapt the technology selection to the current situation of the team. In addition to using Standard to unify team code specifications, TypeScript is also a technical direction we are investigating. TypeScript’s static typing is better for building large applications than JavaScript, which is what appeals to us.