Skip to content
On this page

Zhao Jinjiang / 赵锦江

Frontend Engineer & Scrum Master & Team Manager.


Frontend dev for over 15 years. Also experienced in scrum and team management. Love coding and making. Open source enthusiast. Living in Singapore. Husband. Father of two. Football fan. Learning piano in spare time.

Vue.js core team member. Ex-employee in Shopee, Alibaba Group, and Maxthon. Ex-co-chair of W3C HTML Chinese IG.

Working experiences

1. Shopee (👤40000+)

2019 - 2022, Singapore

A Singaporean multinational technology company that specializes in e-commerce.

1.1 Frontend PIC (Person-in-Charge) of the Tech Committee, Engineering department

2021 - 2022

🎯 Tech stack review for all frontend teams, and further alignment with them.
🎯 Roadmap planning for company-wise tech evolution.
🎯 Key projects mentoring.
🎯 Rank system maintenance and promotion review.
⭐️ Merged diverse UI design systems and component libs into 3 eventually (consumer-facing, seller-facing, and internal).
⭐️ Made company-wise guidelines for such as tech design, FE x BE collaboration, etc.
⭐️ Co-organized internal sharing events like Shopee Tech Summit.
💪 What I learned: company-wise collaboration, how to smoothly converge and merge diverse tech stacks in large scale, indirect leadership and management.

1.2 Manager of the Frontend Team, Marketplace, Engineering department

2019 - 2022

🎯 Frontend engineering for the Shopee web app.
🎯 Long-term tech evolution & engineering management.
🎯 Hiring & career development for team members.
⭐️ Team size grown from 10+ to 150+. And the team structure was able to vertically scale in an easy way.
⭐️ Micro-frontend practice in Shopee web app, including server-side rendering logic.
⭐️ Built a new FE tech stack from scratch for internal admin portals called "Toastack".
⭐️ Introduced an iteration pattern named "Patch-Upgrade Circle" to the team for multi-layer tech collaborations.
⭐️ Set up the whole hiring process, including onboarding and probation experiences.
💪 What I learned: team management, knowledge system and its maintenance, micro-frontend practice, how to build bottom-up initiatives in a team, how to build team culture, WFH experiences during the pandemic.

2. Alibaba (👤250000+)

2013 - 2019, Hangzhou, China

A Chinese multinational technology company specializing in e-commerce, retail, Internet, and technology.

2.1 Frontend Senior Expert in the Dev Experience team, AlibabaCloud

2017 - 2019

🎯 Trying some experimental frontend stuffs with designers together.
⭐️ Flexible design system and UI solution.
⭐️ Accessibility practice in cloud consoles.
⭐️ Cloud consoles in VR devices.
💪 What I learned: design system knowledge, W3C accessibility knowledge, 3D graphics programming, Web VR knowledge.

2.2 Frontend Senior Expert in the Frontend Infra team, Taobao Mobile

2013 - 2017

🎯 Tech lead of 20+ frontend devs.
🎯 HTML5 feature deliveries for Taobao mobile app.
🎯 General frontend project manager of 11.11 Shopping Day for Taobao mobile app in 2014, 2015, and 2016.
⭐️ Led the development of Weex, a dynamic UI rendering engine in iOS/Android, and open-sourced it.
⭐️ Created JSON butler, a GUI JSON editor written in an early version of Vue.js.
⭐️ Developed a fundamental JS toolkit for mobile web dev.
💪 What I learned: HTML5 knowledge and experiences for mobile, open source experiences, Vue.js experiences, frontend engineering in large scale.

3. Maxthon (👤100+)

2007 - 2013, Beijing, China

A Chinese web browser company.

3.1 Tech lead of the Frontend team

2007 - 2013

🎯 Frontend engineering for the browser and websites.
⭐️ Participated in the design and development of browser UI & theme system.
⭐️ Participated in the API design of browser extension system. Maintained the docs for 3rd-party developers.
⭐️ Developed builtin browser pages like start page, bookmark manager, account panel, history manager, settings, etc.
⭐️ Developed websites like homepage, multi-search page, Chinese navigation site, extension center, etc.
💪 What I learned: plenty of frontend development knowledge and experiences, problem-solving skills, communication skills, teamwork, how a startup company roughly runs.

3.2 W3C contact


🎯 Helped the company to join W3C and kept in touch with them.
⭐️ Learned the latest knowledge of web standards and bring them into the company.
⭐️ Built a good relationship with W3C China office.
💪 What I learned: plenty of web standards, how W3C roughly runs, international communication skills, English and translation skills, western culture.

3.3 Scrum master


🎯 Introduced scrum into the company.
⭐️ Several scrum knowledge sharings.
⭐️ Being a scrum master in the first scrum project in the company.
💪 What I learned: scrum knowledge and in actions.

Community participations

4. Vue.js - core member

2015 - now

🎯 Weex renderer for Vue 2.x.
🎯 vue-loader 13.x maintenance.
🎯 Chinese official website and docs translation.
💪 What I learned: open source practice, how to build a JS framework, English and translation skills.

5. W3C HTML Chinese Interest Group - co-chair

2014 - 2018

🎯 Encourage and organize discussions in Chinese community, both online and offline.
⭐️ Organized the early stage work of Requirements for Chinese Text Layout.
⭐️ Organized and participated in Chinese translation of W3C specs.
💪 What I learned: how a W3C doc is made out, communications skills in emails and IRCs.

Personal projects

🛠️ zhlint: A linting tool for Chinese language.
🛠️ v-a11y-utils: Utilities for accessibility (a11y) in Vue.js
🛠️ v-mark-display: A Vue Component for Markdown-based Slides.
🛠️ v-dynamic-island: A Vue (3.x) implementation of Dynamic Island.
🛠️ v-keyboard-over: A Vue component that displays pressed keys on the keyboard by the user right now.
📕 Translated Sass and Compass in Action into Chinese.

Education background

Northwestern Polytechnical University, Xi'an, China

2003 - 2007

Bachelor of Software Engineering

Detailed projects & achievements

1.1 In Shopee Tech Committee

Following the fast expansion, the whole engineering department faced some company-wise challenges:

  1. Duplicated infra constructions by different engineering teams.
  2. Loosen focus on key projects.
  3. Loosen focus on high difficulty tech issues.

So this committee was initialized by the Head of Engineering, to address these issues.

The committee had 10 members, who covered tech directions such as web frontend, native (iOS & Andriod), backend, and QA. At the same time, the committee kept connections with 20+ engineering sub-teams from all the product lines. The committee didn't have extra manpower or coercive power to engineering sub-teams. So to push things forward, we have to negotiate with engineering sub-teams sufficiently or, if necessary, raise issues up to the head of engineering to decide. I was the frontend PIC of this committee representing Singapore headquarter, whilst there was another frontend member from Shenzhen office working closely with me for the frontend tech direction together.

1.1.1 Merged diverse UI design systems and component libs

  • 🚧 There were more and more new product lines being created, however their frontend sub-teams didn't have fundamental UI building blocks to start with. At the same time, some of the teams were trying to build their own design systems and component libs. They looked quite similar, however, each of them was hard to maintain in the long term due to limited resources. Another challenge was the corresponding design systems were also maintained by several small design teams and they didn't belong to the engineering department. It caused collaboation barriers.
  • 🎯 Our goal was trying to help new product lines to quickly get started to build their product UIs in a consistent way, at the same time, to help existing product lines to maintain their design systems and fundamental component libs with less effort but better quality.
  • 🔑 To deal with this, we deeply studied the requirements and existing states of each frontend sub-team. Also, we reached out to the design teams and discussed it together. Then we shared all the information above to every team to further negotiate.
  • 🔑 After multiple rounds of negotiations within several months, all the frontend and design teams came to an agreement, which was:
    • Categorized all the UI into 3 types (consumer-facing websites, seller-facing websites, and internal websites).
    • Kept one existing design system and component lib for each type.
    • Every frontend team can freely pick up and contribute to any of the design system and fundamental component lib.
  • 🚀 As a result, every product-line frontend team could focus on their business-level delivery with high efficiency and consistency.

1.1.2 Company-wise FE tech design guidelines

  • 🚧 We found the frequency of the re-design and re-implementation in product line iterations were a little bit high, which affected their productivity a lot. At the same time, different teams and projects had different tech design formats and styles, which confused new members from another project or team. This was actually not only for frontend direction, but for all the tech directions in Shopee.
  • 🎯 Our goal was trying to make some tech design guidelines for each tech direction. And I was responsible for making the frontend one.
  • 🔑 To achieve that:
    1. First of all, I did case studies from several frontend teams to know the existing ways people did frontend tech designs. At the same time, I knew which parts and what kind of details would usually be often re-designed or re-implemented.
    2. Then I tried to draft a flexible tech design template to conclude the existing ways as much as possible. For the high-frenquently modified points, I added more detailed guidelines and suggestions.
    3. After that, I reached out to some projects for multiple-round trials of practicing tech designs through the template and kept improving it.
    4. Eventually, I finalized the template. Based on that, I also proposed a general tech-direction-agnostic tech design template to the committee for further discussions.
  • 🚀 This frontend tech design template took the existing projects and teams for a little while to adopt it. However, more design flaws were found in the early stage of iteration, which pushed the project into higher quality and better productivity. People could also participate in an unknown project with more confidence and satisfactions.

1.1.3 Company-wise FE/BE collaboration guidelines

  • 🚧 In Shopee, frontend devs and backend devs were usually in different engineering sub-teams, even they worked on the same project. We found more and more conflicts between frontend devs and backend devs during the project iterations due to lack of docs, communications and conventions.
  • 🎯 Our goal was trying to make something, not limited to guidelines or tools, to improve the FE/BE collaborations.
  • 🔑 To achieve that:
    1. As a frontend dev, I did some case studies in multiple projects. Also, I initialized a brainstorm and invited frontend devs as many as possible to come up with some ideas and suggestions to improve that.
    2. After that, I drafted a frontend dev "wishlist" to record all the pain points + corresponding proposals, and shared it with some backend managers for further discussions and trials.
    3. At the same time, we also received some feedback and suggestions about the pain points from the backend side.
    4. Eventually, all the things above became a collaboration guideline betwene FE and BE.
    5. We also built some tools with backend devs together like "API toolkit", which was used to generate TypeScript code from backend API descriptions.
    6. In the end, we practiced the guidelines and tools in several projects with FE and BE together.
  • 🚀 The guidelines and relevant tools were practiced in many projects. The conflicts and complains from both FE side and BE side were far reduced after that.

1.1.4 Others

  • Tech stack review and alignment across product lines: In order to find the potential challenges and problems, when the committee was firstly built, we walked through every frontend sub-team to learn their frontend tech stack, including commonly used frameworks, libs, utils, toolchains, platforms, and services. Besides that we also collected the main challenge and new ideas from each of them. In the end, we wrote a report to record everything above and shared with all the sub-teams and engineers.
  • Key projects mentoring: For all the company-wise key frontend projects, kept them on track and provided help and suggestions. Those key projects include a user tracking & monitoring platform, a JS SDK for native bridge, and an API collaboration platform for FE x BE.
  • Title/rank system: Built up a frontend-specific title/rank system based on general engineering title/rank system. The system provided a more accurate and measurable description for each frontend title and rank.
  • Co-organized Shopee Tech Summit: Built an internal activity for all the engineers to learn what and how the other sub-teams did. I participated in the preparation of the frontend direction, including collecting 10+ topics, helping to review and rehearsal them, and the schedule on that summit day.

1.2 In Shopee Marketplace FE team

At very beginning, Shopee Marketplace FE team, which focused on the frontend development of the whole Shopee website, was one of the 2 largest FE teams in Shopee, while another one was the Seller Center FE team, which was responsible for the Seller Center website.

Regularly, following the growth of the business:

  1. There were more and more features became an independent product line, such as search, promotion, ads, etc.
  2. Some of them had their own sub-engienering teams.
  3. There were more internal admin portals to build and maintain, such as order admin portal.

So, I eventually converted the team structure:

  • An Internal System frontend team was built from scratch by myself.
  • 3 frontend infra teams focusing on different fundamental-level frontend infra: Marketplace infra, Seller Center infra, and Internal Systems infra. The first one and the third one reported to me. The second one was the existing Seller Center FE team.
  • Multiple frontend teams for different product lines were built to focus on the feature deliveries on all the 3 infras. Initially there were 3 product lines reporting to me. In the end, there were more than 8, and reported to product line engineering manager independently. I was responsible to incubate these product line teams and then transfer them to product lines from me.

1.2.1 Frontend engineering of the marketplace feature deliveries

  • 🔑 I kept aligning the roadmap of each feature line with their product managers and engineering teams periodically.
  • 🔑 During all the project iterations, I was responsible for unresolved daily conflicts at the frontend support, such as miscommunications, human resource bottlenecks, quality issues etc.
  • 🔑 I tried all kinds of things like smooth tech evolution, better engineering management, better team structure etc., to keep improving the productivity at the frontend side.
  • 🚀 During the 3 years, the average productivity per man per month has been improved from 0.6 releases to 1.0 releases.

1.2.2 "Verticalized" team structure for large scale

The "verticalize" means to split a large frontend team, which was originally responsible for all the frontend tasks, into small sub-teams, each of which could focus on a certain product line.

I thought it was time to do that due to 3 main factors: large business scale, stable frontend infra, and micro-frontend architecture.

  • 🔑 Besides building and stablizing the frontend infra, including the micro-frontend architecture, I regularly splitted the whole team into small teams, made them self-independent, and incubated frontend managers for each of them. I also re-organized the content structure on internal platforms such as GitLab, Confluence, JIRA to match the transition. For the concerns about potential collaboration barriers between product line teams and the frontend infra teams, I restructed the technical projects and their ways of iteration, contribution, and intercommunication.
  • 🚀 Eventually, all the frontend engineering for the product lines went to corresponding sub-teams. At the same time, the frontend infra teams could more focus on the infra iteration. And they also found effective practices to keep in touch with product lines and the requirements behind.

1.2.3 Micro-frontend practice in Shopee web app

  • 🚧 Initially, the codebase of Shopee web app was a monorepo, which has contained hundreds of packages inside. That caused long build time and slow CI/CD pipelines. At the same time, there were hundreds of git branches and open tickets, including ongoing and inactive ones. People sometimes got confused in who was responsible for a certain ticket or branch, and whether a certain branch or issue could be removed or closed. Third, the relationships between packages were not well-decoupled. This caused long-term maintenance and engineering problems and it was getting worse and worse.
  • 🎯 Our goal was keeping the whole web app still maintainable in large scale, according to those issues above.
  • 🔑 We were planning to introduce micro-frontend architecture into this large web app, at the same time, split the monorepo into small pieces, which was called polyrepos.
  • 🔑 To achieve that:
    1. We further decoupled the whole app into several package groups. Then regularly migrated these package groups out as independent repos one by one. During that, we re-designed the core architecture of the web app and introduced some global APIs, such as i18n utils and stat utils, to ensure the codebase could be decentralized in both development and deployment aspects.
    2. Additionally, for server-side rendering logic, we created a solution called "TreeWalker", which supported Promise logic in server-side rendering and was able to generate and fetch virtual DOM rendering result as a fragment remotely. This helped server-side rendering logic be produced and consumed in a decentralized way, but eventually be combined together as a whole piece to output.
  • 🚀 With those effort above, most of the existing product lines had adopted this architecture and migrated their codebases out of the monorepo. For the newly created product lines and projects, they could also easily followed relevant docs to integrate their own products into the Shopee web app.

1.2.4 "Toastack"

A new frontend tech stack from scratch for internal admin portals, which included a fundamental component lib, an SPA scaffold, an upper-level code-sharing platform, and several small relevant libs.

  • 🚧 At that time in Shopee, there were more and more requirements of internal admin portals upcoming, such as order admin portal. However, we always built them from scratch, which was not economical. There wasn't any fundament and infra for that. Another matter of fact was, as a product line team, with limited resources and time, it was always worthy to spend more time on the user side projects rather than internal ones. So how to build tons of internal admin features in a minimal way became a big challenge.

  • 🎯 We tried to build the fundament and infra for internal admin portals to save their time and effort.

  • 🔑 To achieve that:

    1. First of all, we chose an existing open source fundamental component lib to use which was called "Ant Design".
    2. Second, we built a minimized SPA scaffold called "Kaya Toast". To minimize things as much as possible, we removed a lot of mainstream concepts and features that we thought over-designed/over-engineered for admin portals, such as dynamic route paths, customized build process, centralized state management, etc.
    3. Third, on top of them, we provided a lightweight code-sharing platform called "Toastbox", comparing to a private npm registry. It stored the source code instead of the generated code of upper-level reusable components as "boxes", and provided additional features like box collections, box online preview, etc.
    4. Fourth, for most commonly appeared page types like tables and forms, we provided a top-level page generator to quickly build them up with very little config.
    5. At last, we prepared comprehensive docs to help developers, even backend devs to get started.
  • 🔑 Besides the build and practice of Toastack, we also tried some experimental things called "Open Routes" to explore its future potential:

    1. We developed a state manager called "dedux" to maintain and share state in page granularity.
    2. Correspondingly, we also developed a build process to build the web app in page granularity.
    3. We also developed a dependency manager in the browser runtime called "bpm (browser package manager)".

    With these 3 things together, developers could dev, build, deploy and maintain an admin portal as independent pages. They could also reorganize the repo of an admin portal into multiple polyrepos if necessary when it scales.

  • 🚀 As a result, all the new admin portals had been created on "Toastack". And more and more existing admin portals were also migrated to Toastack from legacy tech stacks. At the same time, 2 large admin portals has practiced "Open Routes" to decentralize their monorepos and deployment pipelines. So their admin portals were able to be maintained by multiple frontend sub-teams now.

1.2.5 Knowledge management

  • 🚧 In Shopee, we had multiple internal platforms people produced and consumed knowledge everyday, such as GitLab, JIRA, Confluence, IMs, etc. And there were all kinds of events and activities, too. Regularly, we faced some knowledge maintenance issues like content out-of-date, people outside a project were hard to follow the progress, some knowledge was hard to look up in a systematical way, etc.
  • 🎯 I tried to manage both of the ways people produce and consume the knowledge around the team, and well-maintain it in the long term.
  • 🔑 To achieve that:
    1. First of all, I analyzed the whole knowledge flow as a graph. So I could easily figure out what knowledge could be missed or lost of recording eventually. For each point, I added a process in actions to keep them transferred and recorded properly.
    2. Second, usually for most of the knowledge of a certain thing, it had two aspects: the progress (which I also called "timeline") and the latest state. It matched 2 different types of knowledge consumptions. So I figured out for a certain thing, which part of knowledge was missing, and then added them up.
    3. Third, for the Confluence space of our team, we rearranged the content in a user-centered way, and reorganized it into 4 parts: for public, for team members, for a certain project, and archives.
    4. At last, we intentionally kept doing knowledge "housekeeping" every half a year, just in case something were out-of-dated.
  • 🚀 After those actions above, the team knowledge was well-maintained, and friendly to look up by all the people. Technically, through the team Confluence space, people can find out everything about our team.

1.2.6 Others

  • Introducing "Patch-Upgrade Circle" for multi-layer collaborations:

    1. When a requirement of updating lower-level dependencies comes, the upper-level projects are recommended to make a patch first and report the issues to the lower-level project immediately.
    2. Then after the issue is fixed from the lower-level, the upper-level could remove the patch and upgrade the dependency to the new version.
    3. During this circle, packages at all layers must be easy and flexible enough to patch on top. We also introduced patch-package to the team at this point.

    This iteration circle was able to decouple cross-level issues and ensure both: 1) efficiency on the upper-level to move forward and 2) enough time and space on the lower-level to elegantly solve the issues.

  • FlowType-to-TypeScript migration: In order to keep the codebase highly maintainable, the team took 1.5 years to complete the migration of more than 500+ packages.

  • Monorepo-to-polyrepo migration: In order to decentralize the codebase, the team took 2 years to divide the whole monorepo into 50+ polyrepos, then migrated relevant development process and CI/CD pipelines accordingly.

  • Building team culture: Tried multiple ways on encouraging knowledge sharing, bottom-up initiatives, and informal communications.

  • Engineering management: Introduced common practices and patterns to the team such as tech design, git branching, code review, auto-testing, etc.

  • Hiring: Designed the whole process, including multi-rounds interviews and interview questions. Did salary review for each candidate and team member. Designed the onboarding & probation guidelines for new team members and their mentors, tech leads, and managers.

2.1 In AlibabaCloud

The Dev Experience team was responsible for the design and frontend dev support of all the cloud consoles in AlibabaCloud. The team size is about 100+. My personal job was exploring the future possibilities of cloud consoles. Most of the outcomes at that time were experimental prototypes and demos.

2.1.1 Accessibility practice in cloud consoles

  • 🚧 At that time, most of the cloud consoles were mainly designed and built for mouse-friendly interactions. However, it would become a trouble when things went to iPad users and high-end users who prefer keyboard shortcuts rather than clicks. Also, we met more and more small design issues on edge cases like lost of focus control, user flow blocks, design inconsistency, etc. All of these above were related to accessibilty knowledge and practices.
  • 🎯 I tried to improve the current design system and frontend practice to make cloud consoles more accessible and systematical.
  • 🔑 To achieve that:
    1. I learned a11y-related W3C specs and their recommended practices in vanilla JS.
    2. Then I figured out the ideal practice for us into 5 parts: color patterns, full-accessible fundamental component design, page flow guidelines, and common relationships among components.
    3. After that, I found all the missing part and collaborated with some designers on improving them. We improved the color patterns and fundamental component designs. I also concluded 5 common page types in cloud consoles and made templates and guidelines for each of them.
    4. Additionally, I initialized the collaborations between AlibabaCloud and some accessibility communities in China. They introduced some experienced people to help us on the accessibility testing/QA jobs.
    5. As a side-project, I also open sourced a util lib in Vue.js called vue-a11y-utils.
  • 🚀 With those effort above, the user interactions and accessibility of the cloud consoles were far improved. More importantly, people started to keep accessibility in mind and paid more attentions on that.

2.1.2 Others

  • Flexible design system and UI solution: Studied all the existing cloud console designs then made a report. The report summarized the main layout and 4 types of pages. Also, it concluded commonly-used data visualization scenarios into several categories. Based on different screen sizes and preferred user interactions, it provided purpose-driven alternative components for different device platforms, such as date-pickers. For newly created pages in the future, it was an important reference to start with.
  • Cloud consoles in VR devices: Built an experimental cloud console prototype in a 3D world, with unlimited-sized screen, switchable working background, and new creative input ways.

2.2 In Taobao Mobile

Taobao Mobile was a business unit of Alibaba Group since 2013 to 2018. It was dedicated on Taobao mobile app and the infra for all mobile apps in Alibaba. My job there was half-coding & half-team-leading. After 2018, the business unit was merged into Taobao (desktop website) business unit.

2.2.1 The "Weex" project

  • 🚧 In the Taobao app, there were a lot of dynamic content to display, such as ephemeral promotion information. And there was a long-time debate between the usage of native UI and HTML5 UI. The former one had better performance, while the later once had better efficiency and dynamics, plus better compatiblility with its web version.
  • 🚧 In 2013, the native engineering team created a project named "weapp", which was able to parse a JSON object into native views. So the app was able to load a dynamic JSON file from the server and render it into a native view lively. However, it was hard to handle complex logics and user interactions due to the limitation of the JSON structure. Also, the in-house JSON format didn't follow any existing standard, which was hard to learn and easy to make mistakes.
  • 🚧 In early 2015, React Native was open sourced by Facebook, which seems better to solve this problem. However, after some trials, we found the project was a little bit unstable and heavyweight for the dynamic content.
  • 🎯 As a frontend dev, I initialized a project called "Weex", which aimed to provide a rendering engine in a lightweight, high-performance, and high-efficiency way.
  • 🔑 We reused existing native view components in "weapp" and css-layout in React Native. We also introduced a JS runtime like React Native did, but instead, I hacked Vue.js 1.x and replaced the DOM APIs into native view APIs. Besides that, I also hacked vue-loader to enable frontend developers writing Weex components in a Vue SFC (Single-File Component) way. After 2 months, which was 4 scrum springs, the first version of Weex was shipped and was firstly used in the homepage of Double-11 Shopping Day 2015.
  • 🚀 As a result, in Double-11 Shopping Day 2015, it served the homepage with high traffic, with fast loading time (averagely less than 1s), small memory usage, small CPU consumptions, and high fresh-rate.
  • 🔑 In 2016, the company decided to put Weex to open source community. That was the first open source project in Alibaba in such an active way. We also had an official integration and collaboration with Vue.js.
  • 🚀 In Double-11 Shopping Day 2016, Weex served 100+ pages and took most the mobile traffic with high performance and efficiency.
  • 💪 Besides the development and lead of the project, I practiced open source and tech advocating a lot. I also learned a lot from the community and indepednent developers. My presentation skills and communication skills were far improved, too.

2.2.2 Others

  • Feature deliveries of the Taobao app: The whole product was divided into 4 feature lines. Each feature line had its own roadmap and headcount. It was the first time I behaved as a tech lead role.
  • General frontend project manager of 11.11 Shopping Day in 2014, 2015, and 2016: Usually it was a 3-month ahead preparation process each year, from product design, development, delivery. And on that day we also did the full-day monitoring and business logic adjustment accordingly. Learned a lot about project management, negotiation skills, and engineering management for big events.
  • JSON Butler: A GUI JSON editor, which supports nested arrays and objects. It was used in an internal CMS system that managed a lot of product operation & promotion pages. The editor has 2 parts: a schema editor for the admin and a data editor for the local operator. It was based on Vue.js 0.x. And it was my first project that practiced component-based frontend development.
  • Fundamental toolkit for mobile: A toolkit for mobile web development. It included a flexible CSS length solution based on rem unit, a touch event lib to support advanced gestures like tap/pan/rotate/scale, a SPA router, a JS SDK for Taobao API gateway, a lib to send stat information Taobao stat server, etc. Most of the APIs could automatically detect whether to call it to a server directly or through the native-JS bridge in the mobile app. I participated in all of them. Part of the libs were open sourced on GitHub.

3.1 In Maxthon

Maxthon is a browser company since 2005.

The Maxthon browser was the first widely-used multi-tab browser (v1). It also firstly provided cloud services (v2) like account system, online bookmarks and history records. And it was the first dual-core engine browser (v3) for both modern web pages & legacy IE-only web pages.

I was the No. 6 employee of Maxthon as a frontend engineer at very beginning, and eventually became the frontend tech lead of 15+ members. For frontend, Maxthon was the first browser which had plenty of HTML5 builtin UIs such as settings, account panel, bookmark manager, history manager, etc, in the early-jQuery (first release in 2006) era. I am proud working there as my first career job for over 6 years.

3.1.1 Builtin browser pages

They were all kinds of builtin web pages in the browsers. They called APIs from the native side of the browser. Some of the pages had an online version which called APIs from the server. All the stuffs were built in vanilla JS.

  • Start page: The blank page of each time the user created a new tab. It provided customized website links with tile images, theme, and background. It get and set user config via JS APIs from the native side. The page load process was eventually optimized in less than 100ms.
  • Bookmark manager: A web page to display and manage user's online bookmarks. It had both in-browser version which communicated data with native APIs in the browser, and online version which communited data with server. For user with large amount of bookmark data, we supported lazy-load for sub-folders. The bookmark manager also supported high-efficient interactions like drag-n-drops and full-featuerd keyboard shortcuts and focus control.
  • History manager: Quite similar to the bookmark manager, however, for business reasons, we didn't provide an online version.
  • Settings: A builtin web page to display all the settings to the user. We worked closely with the native engineers for every config field and corresponding native APIs. We also developed a fundamental control libs for all the inputs and outputs. Since some of the settings were in an async way, we provided intermediate state for some controls like checkbox.

3.1.2 Others

  • Browser UI & theme system (v3): Based on HTMLayout, a lightweight HTML rendering engine. The main browser UI was developed in HTML and CSS upon this engine. The theme system was also based on that to enable 3rd-party developers making personalized browser UI. I participated in the main browser UI development and theme system design.
  • Browser extension system (v3): A browser extension can run JavaScript code on web pages and show some entry points on the main browser UI like toolbar and sidebar. I participated in the JS API design and documentation authoring.
  • Developed some websites such as Maxthon homepage, Maxthon multi-search page - a page to quickly search keywords in multiple search engines, and Maxthon Today - a comprehensive Chinese navigation website with a CMS under the hood.
  • Scrum master: I introduced scrum into the company in 2013, and became the scrum master of Maxthon Today project, the first scrum project in Maxthon. Beside me, the project has 2 product owner, 1 designer, and 4 dev team member. The length of each sprint was 2 weeks. It helped people worked like a real team with less disruptions and high efficiency. After that I also coached several scrum masters in more projects.

4. Vue.js

I knew Vue.js in early 2014, where I was searching for a lightweight alternative of Angular.js for mobile web apps. Then I started to use it, introduced it to people around me, and regularly participated in. It was the same story where some people knew me through Vue.js: The Documentary.

  1. Weex renderer for Vue 2.x: I officially became Vue team member in the early stage of Vue 2.x. At that time my company was collaborating with the Vue team for integrating Weex and Vue.js into each other. As a person who was familiar with the both sides, I finished the main part of the Weex renderer and the integration with Evan You, the creator of Vue. With this integration, Vue developers can easily build Weex pages in Vue SFCs.
  2. vue-loader maintenance: Before Vue CLI v2 and Vite were introduced, vue-loader is the only official and easiest way to enable Vue developers to write SFCs (Single-File Component). I maintained vue-loader and handled related webpack, CSS pre-compiler, JS pre-compiler issues during that period.
  3. Chinese translation of the official docs: I keep translating Vue docs since 0.x till now. Besides that I also handled some other localization and deployment issues. Now this job was regularly handled by a group of people together as a team. We also provided some feedback to the English docs, and shared our knowledge and experiences to the translators in other languages.

5. W3C HTML Chinese Interest Group

This Interest Group was closely related to W3C HTML Working Group. It focused on HTML5 spec discussions in Chinese community and gathered comments and questions back to the W3C HTML Working Group.

My job as a co-chair was to facilitate the discussion and feedback. To achieve this:

  1. We organized a spec translation group to translate new HTML5 specs into Chinese.
  2. We initialized the Requirements for Chinese Text Layout.
  3. We organized some sharing events to talk about HTML5 specs.
  4. We created a GitHub org and a wiki site to record everything up.

Later in 2018, this Interest Group became a new Chinese Web Interest Group, with a mission of enhancing the participation in Web standards work from Chinese Web community.