As consultants, it is part of our job to recommend technologies to our clients for use in their projects. React Native is one such technology we consider to reduce development time and save clients money. React Native is great for certain use cases, so it’s a technology our web team has been learning. This blog post is not about React Native, however.

If you pay attention to JavaScript frameworks, you’ve probably heard of the new hotness, VueJS. It’s popular for its Angular-esque directives and React-ish components, as well as its speed and ease of use. A technology based on VueJS that could perform the same write-once-run-anywhere magic (As long as ‘anywhere’ is iOS or Android) as React Native would be exciting, indeed. Enter Weex.

Weex is a JavaScript library that tries to fill a React Native-sized gap in the VueJS ecosystem. I wanted to see if Weex might be a viable technology we could bring to clients. After a few days of experimentation, I realized Weex and its documentation were not yet developed enough to for us to use to deliver top-quality apps. This was my experience with Weex.

First, a few caveats. Significantly, I don’t speak or read the primary language of Weex developers. Weex was developed by a Chinese team, and most of the technical conversations surrounding Weex are held in Chinese. There is an English version of the documentation, and Google Translate helped cover for my monolingualism, but if you read Chinese, your experience could be very different from mine. Second, I don’t have any Xcode or Android Studio experience, which would have been very useful.

In other words, Weex has a high barrier to entry for web dev teams without Chinese literacy.

When I first tackled React Native (after the release of create-react-native-app), I was impressed by how easy it was to start developing. I entered my foray into Weex with expectations set by React Native’s high bar. It didn’t take long for me to temper those expectations. After creating my first project with the weex-toolkit command line tool, I found a breaking bug in the boilerplate project. It was a simple typo in Webpack’s config file, and it has since been fixed, but it was a good indication of the WIP nature of Weex.

Out of the box, Weex provides a browser-based app preview. Skipping mobile simulation keeps Weex lightweight and familiar, but VueJS code can render correctly in the browser when it doesn’t work on native devices. This means iOS and Android simulators are still necessary to fully test Weex apps. Still, the browser preview provides a nice, quick way to confirm that your code mostly works.

My next step was setting up the iOS simulator in Xcode. I followed the documentation to the best of my abilities, but was unable to get it working. I recruited one of our rock star iOS devs to help me uncross some wires and was rewarded with a simulator running a Weex project … that was different from the Weex project running in the web preview. I spent the next few hours figuring out how to connect my JavaScript project with the Xcode one.

After a full day of tinkering, I had a functional dev environment setup. It was a fun learning experience, but one of the things I learned was that the Weex docs were not yet developed enough to support our needs.

I started day 2 with the goal of building a basic goal tracking app. The Weex component library was barebones, and there were not many packages to flesh out the core offerings. The libraries that did exist were time consuming to setup and suffered from the same documentation limitations as Weex. At the end of the day, my ‘app’ was a single screen with an input box and a button.

Reflecting on two days of work, I decided the process had required too much effort without yielding enough results. True, I had worked through Weex’s biggest challenges in setting it up, and my development time would only increase as I became more familiar with it, but as of now it’s not a good fit for our work. We need to ensure our projects are easy for client developer teams to take over, and as Weex continues to grow and evolve, it’s hard to predict how that experience will change for new developers. When Weex has friendlier documentation and a gentler setup for new devs, we’ll revisit it as an option for future projects.

At Big Nerd Ranch we like to keep an eye on emerging technologies because, well, we’re a bunch of nerds, but also because we need to know what the best options for our clients are. If you’ve got a problem you want to solve, get in touch. We’d love to talk about your options.