“Write once, Run Everywhere” Write once, Run Everywhere. React moved to MIT protocol. Unfortunately, React Native is still the same. When there was no RN, Weex was responsible for it. Not as cool as RN, but still a nice little brother.

A lot of people are probably asking why I’m switching from RN to Weex after all this time. Well, it’s a sad story

Why not use RN

Facebook didn’t migrate ReactNative to MIT protocol like React did, so using ReactNative to develop external products is still a patent risk. The general company actually does not have any influence, but my factory situation is more special, there are several core patent technology, the boss does not want to take this risk. Together with ali Weex next door push very fire, that use to see!

The React Patent License details please step outside and turn left to read my previous article: The React Patent License Study.

Advantages of Weex over RN

To be honest, dealing with ReactNative for so long, suddenly changing a younger brother, it is really difficult to adapt to, even a face of disgust. Weex and ReactNative have completely different design philosophies. RN focuses on Native and develops cross-platform apps in the way of React. It pays attention to Native’s exquisite user experience and powerful Native functions, and can independently develop an App with complete functions by applying ReactNative without even requiring Native engineers.

Web Development Experience

Weex is difficult to develop independently because its Native capabilities are not as powerful and comprehensive as RN’s. It pays more attention to Web development experience. As the name implies, it is to develop cross-platform App pages just like developing Web pages. Note that it is dominated by Web, so its design concept advocates lightweight + expandable (as for “high performance”, it is not much reflected than RN). It is also recommended to use Weex and Native to develop the App. That is, Weex is integrated into the Native App as a component instead of the traditional Hybrid mode.

No patent restrictions

Weex has joined the ASF and is not restricted by ReactNative’s patent agreement, so it can be used freely. Of course, some children will ask Weex is still using FaceBook Yoga engine, will there be a danger? We don’t need to worry about this in the short term, first of all, the problem itself is very vague, and secondly, a big factory like Ali will develop a similar engine sooner or later to replace it, a matter of time.

The three ends share code

Weex not only retains the flexibility of H5, but also endows it with Native ability. It communicates with Native directly through JavaSriptCore+JSbridge, which is much better than Hybrid WebView + URLScheme. It can even achieve the legendary “three-end fusion” — that is, the front-end of the Web, iOS and Android ends share a single set of code, eliminating the need for independent site construction and maintenance. It is worth mentioning that it integrates the base bundle into the SDK force, and the business bundle is very small and loads very quickly.

Of course, there are some gains and losses, and there are many holes in the three-terminal compatibility, not to mention the hack of various Android models. The Web terminal is actually a WebApp, and it needs to use the browser BOM and the three-party JS-SDK to complete functions other than DOM and HTTP. However, using Weex’s built-in tags and styles, it is easy to achieve a three-terminal layout style consistent with the basic behavior, which greatly reduces the workload.

The Weex layout unit is only px. The default display width (viewport) is 750px. Components use 750px as the full screen width, but you can manually specify the page width using meta.setviewPort ()

Type iPhone4 iPhoneSE iPhone8 iPhone8P iPhoneX
Physical pixel 640×960 640×1136 750×1334 1080×1920 1125×2436
Display pixels 750×1125 750×1331 750×1334 750×1333 750×1624
Pixel than @ 0.85 x @ 0.85 x @1x @ 1.44 x @ 1.5 x

Support for CSS3

Weex does some castration of CSS, but it retains more of it than ReactNative, and even supports a large number of CSS3 features, which is commendable. CSS3 as a powerful tool for Web development, it is a pity not to use it. Here are the differences between Weex and the standard Web:

  • To support theCSS3Features include: FlexBox, positioning, 2D conversion, transitions, linear gradients, shadows (onlyWebandiOS), pseudo-classes, custom fonts (iconFrontICONS can also be used.
  • Single class name selectors are supported, and no relational or attribute selectors are supported
  • Component-level scopes are supported in order to preserveWebandNativeCongruence, need<style scoped>Declare scope
  • Does not supportCSS3Animation (Please use Weex built-in animationanimationModules) and 3D conversion
  • Does not supportdisplay: none, using template syntaxv-ifSubstitute, not recommendedopacity: 0(NativeIt’s a little revealing.)
  • similarRNTo improve parsing efficiency, Weex style attributes do not support abbreviations such asfont,border,transfromCan’t abbreviations

Shortcomings of Weex

At the end of this section, I would like to make fun of a few shortcomings of Weex, hoping that the official can upgrade and improve as soon as possible:

Slow community building

This should be the most deadly, Weex from last year, the open source community today is so cold and cheerless unavoidably sad, though I know ali internal promotion is very big, but now that choose to open source, you should jump out of ali’s circle, some successful cases, mature solutions and excellent architectural design should not be hiding anything, otherwise it’s really hard to promote it. I don’t want to find a valuable solution after several rounds of Google, and I can’t get a satisfactory answer on GitHub for a long time (haha, it’s a little exciting to say, thank you very much for Mario’s answer to my question last time, I hope you can respond to the official document as soon as possible).

Native ability improvement

Weex’s full-page mode isn’t worth much without improving Native capabilities. I don’t want to cover everything, but I hope to add some common ones, such as statusBar control, location information, Android dynamic permission assignment, etc

Real machine debugging tool upgrade

Weex advocates Web development experience, so development and debugging are based on the Web, do static pages ok, but I want to debug Native terminal unique logic, need to integrate weex-DevTool in the Native terminal. This is definitely a new approach, but wouldn’t it be too much of a hassle to have to manually refresh the code every time you change it? Could we do something like Hot replace or LiveReload for RN?

File permissions on the Mac end are incorrect

If you use the Shell tool on the Mac to access the Weex directory, sudo permission is required for both NPM commands and git operations. I am very lazy, Weex in the creation of the file can help me to write permission to do the thing?

Haha, am I too stupid to understand the skills, wrong place welcome comment ha. But front-end engineers are picky, I hope Weex can continue to improve and improve!