I’m Aligord, who started on October 22, 2020, and will be a year old tomorrow. But also these days, I mentioned leaving. As a matter of fact, I was torn about making this decision. I gave up a lot of things, but I still decided to leave. This article will talk about why.

Review the year of Gaud

What does the Autonavi Cross-end Engine team do

I joined the cross-end engine team. Autonavi has its own cross-end engine, which extends many apis for v8 and javascript core through c++. These apis are implemented by android and ios respectively, including rendering dom and CSS, and using various device capabilities.

Because the JS engine implements w3c standard DOM APIS and CSS, it is possible to run HTML, CSS, AND JS code on the cross-end engine, organize logic through them, and then render and interact with Natvie.

There is also a react like front-end framework, which we have modified, and the dom API used for final rendering is the one provided by the cross-end engine.

In this way, lines of business can organize pages through react components, and complete page interaction and business logic through apis provided by various cross-end engines.

The code running on the cross-side engine has its own set of specifications. Line-of-business code is written in less, typescript, ES Next, etc., and then converted to cross-side engine support, so you need to develop your own compiler to do the conversion.

We implemented the compiler based on Babel, less Compiler, recursive analysis dependencies, compiled each file, and then packaged it together. We don’t need chunks like Webpack, because it’s not a browser platform, we just need to compress them together. The packaged product is a binary file called a bundle.

Compilation only allows the source code to run on the cross-end engine, but after running, there will be logs, error messages and other information, will need to do DOM, CSS debugging, JS debugger and so on, which needs to develop debugging tools. We implemented our own debugging tool based on Chrome DevTools Protocol.

Compilation and debugging are strongly related to writing code, so we customized IDE based on VScode, integrated with self-developed compiler, self-developed debugging tools, etc., and also implemented a lot of vscode plug-ins related to writing code, such as path tips, JS, CSS intelligent tips, etc. Because the styles and JS apis supported by cross-end engines are different, you need to implement them yourself.

The code on a cross-end engine exists in the form of bundles, and there are dependencies between bundles. Because the running platform is a self-developed cross-end engine, node_modules is not supported, so we develop dependency management tools. This includes declaring dependencies via a bundle.json, recursive downloading dependencies, global caching, etc.

In addition, the various apis provided by the cross-end engine should be consistent for c++, android, ios, and documentation. How to ensure uniformity? We describe documents and interfaces through TS as DSL, and then compile them into Java, OC, Markdown, etc. In this way, we complete the unification and compilation of multi-terminal API and documents.

In addition to these, there are dependency analysis tools, analysis of all cross-end engine related source code, including android, ios, c++, js code, extract a variety of data for analysis.

The cross-end engine is maintained by c++, android and ios, while the compiler, ide, debugging tool, dependency management tool, multi-end API and document unification tool, and dependency analysis tool are all maintained by our front-end classmates. That’s what I’ve been maintaining for my first year.

What did I do this year

In fact, a careful look will find that the extension of JS engine, source code to source code compilation, TS to multi-terminal code and documents, dependency analysis and compilation technology are strongly related, this year I in the front-end field of compilation technology improvement is particularly large.

I did the compiler’s sourcemap unification:

Each step of the previous compilation was split, that is, each step is JS/TS code parsed into AST, converted into a new AST, regenerated into JS code and sourcemap and so on, but there is no association with the sourcemap generated in each step. As a result, the code that ends up running in the cross-engine is not mapped to the source through Sourcemap.

I changed the entire compilation process, passing the AST along at each step, so that after the modification, the sourcemap was regenerated, and the sourcemap could be mapped to the source code, and the source code could be debutted directly.

I made an upgrade that relied on the installer:

The original dependency installation tool was to parse bundle.json, recursively parse dependencies and then download them to xxx_modules. There was no global caching, and as a result, multiple downloads of a dependency took the same time. In addition, we will modify the downloaded dependent bundles. The same bundle of multiple projects needs to be modified separately, not just one.

I do global cache, the first download will cache the dependency to the global directory, and then copy to the local, subsequent downloads of the dependency directly from the cache, improve the download speed. I made the dependency promotion to the parent directory, and then linked it locally, so that multiple projects changed the same bundle.

I made CSS smart hints and color previews:

The CSS supported by the cross-end engine is a subset of the W3C standard, and there are also some differences. Business development students need to check the document frequently, and accidentally write wrong, affected by these, the efficiency of WRITING CSS is not high.

So I did the compiler’s CSS Lint feature to check for errors during compilation and thought, why not go ahead and write the code? So made a VScode plug-in, based on language Service Protocol to achieve the language service, support CSS prompt, error check, hover display documents, so as to avoid the document. Also made a color preview plug-in, give us support for some color constants directly display color, more intuitive.

I made updates to the API and document generation tools

We describe the interface through the namespace, module, function syntax of TS, and then compile into Java, OC, Markdown and other files to do multi-terminal API and document unification. We made a command-line tool that parsed the TS specified in the configuration file, did a series of analyses on the AST, and then generated various code and documentation.

I have extended the syntax support to realize the parsing of enum, interface, class and other syntax, so that the interface description is more diverse. Changed the format of markdown documents to make them more readable. Also made a local preview function, can locally generate markdown to see the effect, previously not supported.

other

This year is mainly about these, but of course there are some other features, compiler, IDE, etc. In fact, over the past year, I have gained a deeper understanding of the compilation technologies in the front-end domain, including Babel, typescript, PostCSS, ESLint, Terser, etc., and become more comfortable with Node.

In addition to my work, I also wrote a small volume of “Babel Plug-in Secrets”, went to early chat, byte, nuggets, Huawei and so on to do some sharing, founded the “Shenguang programming secrets” public account, wrote a lot of original articles. I also decided to write a book on front-end compilation within three years.

Leaving reason

In fact, I am very satisfied with the current work content and learning status, but I still choose this time to quit.

Why is that? This leads to a subplot.

Back in February, I asked a question in zhihu: is it feasible to convert front-end to c++ compiler development? At that time, I found myself very interested in compilation technology, but because I was far away from it, I didn’t know how to transition.

Got a lot of big man’s suggestion, among them have Yang Hailong big man of Huawei. I also went to Huawei deeplang community to share, talking about the front-end field of compilation technology. Then I also added the wechat account of the person in charge of the programming language lab.

Just recently, the programming language lab at Huawei contacted me and said there were some positions open there and asked if I would be interested.

I thought about it, and if I stayed at Autonavi, the story would go something like this:

Wrote eslint, typescript source code, postcss, etc., wrote vscode plug-in volume, two years later wrote a book on front-end compilation. I became more familiar with vscode, compiler related tools and debugging related tools, and made many important functions. Then I was successfully promoted to p7 and accumulated certain influence in the community.

These are very deterministic.

If you go to Huawei, there are three differences:

  • Working in the top programming language and compiler team in China can greatly improve the understanding and mastery of compile-related technologies. In addition to the minor trouble of translating source code into source code, I can also go deep into interpreter and compiler technologies. These are not available in Autonavi.

  • I can get deep into c++ and other programming languages. Learning by myself is different from writing relevant codes in the company. There are scenarios where I can get deep into c++ and become a c++ engineer.

  • What I do there is also compilation, although I guess it is not writing JS code, but the idea is not much worse, so I plan to write front-end compilation related books and books do not need to leave, can continue to work.

But going to Huawei is highly uncertain.

Let alone whether I can successfully pass the algorithm interview, I may not be able to do well if I successfully go there. Besides, there are many teams with master’s degrees and doctoral degrees, and many top talents at home and abroad. Most of the chances are that if I go there, it will only be a small transparent.

However, I still plan to abandon my future in Autonavi and explore new possibilities in Huawei. Life is only wonderful when there are some uncertainties, right?

So when I was at Ali for a year, I left.

In the future

The subsequent public number will write some c++, write some compiled content, these and the front end of the relevance is not big, but I will try to and front end associated to write, will try to write some easy to understand. Interested students can continue to follow. Later I will not just rice, concentrate on writing technical articles, because the total feeling of sudden transformation is not responsible for the public number of fans.

This is my year at Autonavi and the reason for my departure.

Looking ahead to October 20, 2021, the future is still full of uncertainty, but also full of hope. Keep going. Believe in yourself, also believe in the future.