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.
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.
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.