January 19th weeX team held weeX Conf in Hangzhou. The semi-closed invitation system, because I tried to access weex in my previous project, I happened to be unemployed and had time at home, so I signed up with Bing Shuang.

Although the scale of the meeting was not large, with less than 100 people on site, it seemed that only those who had used WEEX in the project were invited. There were also some large companies such as Tencent, netease and Mogujie, so the atmosphere of the discussion was quite good. The speeches in the afternoon were all about the practice summary of weeX used by their teams, which gave me a clearer understanding of the current situation of WEEX. Sum up my feelings at the end of the day.

Weex next step: Rewrite the kernel to get rid of JavaScriptCore dependencies

The idea of multi-terminal operation of a code is that the logic is written in JS, the JS file is dynamically synchronized to the local, and then the local JS engine executes the JS code and realizes the business by calling the native function registered in advance. A more abstract step would be to agree on a syntax format (DSL) against which the response logic is executed by different platforms. A bit like the compilation process, parses custom strings into the corresponding code. In the early days, there were JS and JavaScript Core, which naturally took advantage of the existing technology.

So what are the weaknesses of the existing system?

  • Communication performance problems between JS environment and native environment

    The JS runtime is inconsistent with the local runtime. There is a significant performance penalty when the two environments call each other. It was mentioned that the local GPS location is continuously passed to the JSC, and the function response process can take tens of milliseconds. While this kind of continuous function call is not a common scenario, this scenario highlights the inherent weakness of this pattern.

  • Dependencies on JavaScript Core for different platforms

    On iOS, weeX uses the JavaScriptCore Framework of iOS. Android originally used a V8 engine, which was later replaced by JavaScriptCore. The JS engines on both ends have different code, and the JSC on iOS is closed source. If the same JS code, two ends run different results, debugging is very difficult.

Reasons for choosing WEEx

Support web

I was actually going to use the word “blow” because RN doesn’t support the Web at all. I saw ctrip and JINGdong mentioned in the technical conference that they plan to maintain a set of tools to support RN’s Web capabilities. But small teams don’t have that kind of r&d power. Weex, because of the demand from its own (Taobao) Web side, so at the beginning of the support of three terminals. The Web side is just so-so, but it still works. This is a real pain point, and many teams in the field choose WEEX because they need to support the Web side as well.

Blessing of vue

The pros and cons of front-end frameworks are irrelevant, but personal preferences do vary. After hearing that we were familiar with Vue and didn’t want to be exposed to react, the on-site team chose WEEx.

Ali has become deeply dependent

Weex’s original mission, after all, was to solve its own development efficiency problems. Alibaba’s internal approval is critical to the stability of the project. With weex’s improved performance, thousands of pages of Taobao’s Singles’ Day venue are implemented using WEEx. It looks stable.

It was interesting to hear a shared business scenario mentioned by the Flying Pig team. Half of Feizhu’s traffic comes from other Arabic apps (taobao, etc.), previously through Hybrid’s web pages. But the shortcomings of web pages are well known, slow loading and poor interactive experience. Now because other apps are equipped with WEEX, so the convention of some modules can be very convenient to support other apps to embed their own business.

In short, Alibaba’s internal weex has valuable recognition. Okay, well, I don’t really care about that either, as long as I know the Weex team won’t break up tomorrow.

The biggest bottleneck: community activity

The Weex developer community’s activity is dismal compared to RN’s. It’s the kind of sentiment that two developers would smile at each other if they knew the other was using Weex, then hug and cry.

Inactivity in the community raises a lot of barriers to technology use.

For example, one thing I saw was that after WEEx was transferred to Apache, the original RepO on Github was no longer maintained. There is no way to mention issue on Apache. Developers are also generally uncomfortable with Apache’s email approach. So a developer with a problem with WEEx doesn’t know who to go to. On some websites, there are only a few answers after months. To popularize a technology, the threshold must be low. Can not hope to use the team technology has a first-line Internet company’s level, can see their own source solution; Or have access to Ali’s friends to help solve the problem.

The community is less active, and there is less hands-on information about the technology. If you use RN and want to do routing, you can search for several solutions. Even print books from publishers, RN has a lot of them. However, searching for how Native sends values to Weex takes a long time.

Rome was not built in a day. If weex goes into the hole, be prepared that the community, while getting better, may not be as active as the mainstream framework.

conclusion

Who wouldn’t want to see a technology solution developed by a Chinese team move onto the world stage?

Bring a weex job with you

Taobao -Weex kernel research and development technical expert

Welcome to my micro blog: @Zhuo who has no story

Nuggets blog: juejin.cn/user/192600…

If you want to talk to me more closely, you can also join my little secret circle: The Programmer’s Survival Guide