Please note: this article discusses the technical differences and how exported apps function on devices. It does not cover value-added services, plugins, backends and so on.
There are a lot of different frameworks and tools out there for building mobile apps and one of the most common questions we get is “How is Fuse different from <some framework>?”
Sometimes it’s as simple as explaining the difference between hybrid HTML-apps and native ones (Fuse exports native apps), or between prototyping and building full apps (Fuse actually lets you do both, moving seamlessly from prototype to finished app), but often we have to elaborate further.
We tend to talk about the philosophy and vision behind Fuse. That is: rather than digging into tech details we look at the higher-level goals for Fuse and how it should help the users.
This includes such things as:
- Fuse is for both designers & developers. We want to help the two groups work better together while still doing what each of them knows best.
- New and better workflows. Working with Fuse should be more efficient and more fun.
- Flexibility — to create exactly what you want, using the features you want. Fuse should not feel like a toy or a sandbox.
- Front-end & user experience focus. Apps built in Fuse should look & feelbetter than what you achieve with other tools.
However, philosophy is only good if it leads to tangible results, even more so when dealing with development. :)
This is why I wanted to take a closer look at some features of Fuse and explain how they differ from two frameworks we often get questions about, namely React Native by Facebookand NativeScript by Telerik.
Now, before we get started I’d like to say that while I’m obviously biased towards Fuse (I think it’s great and it’s what I’d use to build apps even if I didn’t work here!) I’m definitely not aiming for flame bait here. The main point here is to provide some more insights on Fuse by contrasting it with some other well-known technologies, with the goal of helping out anyone trying to decide which framework to go with.
The basics
From a distance Fuse, NativeScript (NS) and React Native (RN) may seem similar since they all:
- Run JavaScript in a VM
- Access platform APIs and UI components
- Offer a level of cross-platform abstractions, as well as direct access, to native UI
- Provide some form of markup for building and styling UIs
However, when you take a closer look Fuse is quite different in both what it aims to be and how it achieves this.
Native code vs JavaScript
A key difference is that Fuse uses JS exclusively for app logic while producing native code for everything else, including population and manipulation of the UI.
When you export an app from Fuse it converts all the frameworks and markup you’ve used into C++ source code which is then compiled using the native platform tools (Xcode and the Android SDK/NDK). You can also drop Java and Objective-C code into the same project and have everything compile together, or simply link in native libraries.
In contrast to this, NativeScript and React Native depend much more on JavaScript execution for everything they do. NS works by exposing native APIs directly in JS, dispatching calls and converting data on the fly. RN works similarly but instead calls out from JS to slightly higher level functions implemented in native code.
You could say that RN & NS are built top-down: they started with the JavaScript requirement and then filled in the rest. Fuse, on the other hand, is built bottom-up: we started out with cross-platform native code and high-end UIs and then added JS as a way to easily build apps with that.
The main reason why we feel that “more native is better” is quite simple: performance.
While it’s true that JavaScript VMs have become fast they are definitely not faster than compiled native code, and this still matters. More efficient code means that you can do cooler stuff in your app, that it runs well on older and lower-cost devices, and that it doesn’t drain your battery.
This leads on to a closely related point…
JavaScript execution and UI performance
If you want smooth visuals at 60 frames per second it is crucial to never let anything (such as slow JavaScript execution) block your UI updates.
In Fuse, this is solved by having the business logic in the JavaScript VM on one thread, while all UI work is running independently, in native code, on another thread. Communication between the two worlds happens through reactive data binding which gives a clean separation of responsibilities.
Since the UI itself knows how it should navigate to a new page on a button press, or how it should animate a list when new data is added, it never has to stall while waiting for JS to complete other work before performing visual updates. (The reason the UI knows all of this is because it’s defined in UX markup. More on that further down!)
For comparison: NS runs everything from a single thread, in JavaScript. This makes sense given how it accesses the low-level platform APIs, but also means that you can easily get lag and jitter when UI updates are blocked by other JS work.
RN utilizes more threading than NS but also here everything that goes on in the UI layer is much more dependent on JS code than what is the case for Fuse. The whole process of maintaining & diffing RN’s virtual UI tree, as well as frequent serialization and deserialization of data due to communication between the threads, can also introduce additional JS work which might reduce some of the multi-threading benefits.
Declarative markup
All three solutions offer some form of markup language for working with UI, but the difference between them is huge. This is probably the area where it becomes most apparent that Fuse is for *anyone* building apps, whereas the other two are mainly targeted at JS-developers.
UX markup is the central piece in how UIs and user experiences are created in Fuse.
It’s a declarative markup language specifically designed for working with layout, animation and user input, while being intuitive and easy to learn, also for non-programmers.
Since UX is used to define everything visual and interaction-related it provides a lot more control over the look & feel of the app. NS and RN instead rely on CSS-subsets and more traditional XML for relatively basic styling while also being a lot more entangled with code.
In other words: Fuse lets you create much more of the app without touching any code, using a markup language that’s tailor-made for front-end.
This isn’t just a huge benefit for designers but also for developers who’d like to build better-looking things, or simply just iterate on the UI and business logic independently.
And as already mentioned, everything you create using UX markup becomes native C++ code in the final app, running completely independently of the JS. This is in contrast to the other two solutions which parse XML from JS at runtime (or translate JSX to JS).
OpenGL UI
The native stock controls are great, but they also represent a challenge for designers. The problem is that they look and feel different under different devices, OS’es and settings. In particular on Android, where fonts, colors and design can vary greatly and unpredictably.
Quite often, designers want to implement av very specific design or animation, with precise control.
With the option to use OpenGL based UI components, Fuse is the only of the three platforms that offer a reliable “write once, run everywhere” approach where designers can control responsive layout, look and feel down to points, pixels and percentages, keyframes and easing curves.
There is nothing extra to learn. In both cases, responsive layout and animation are defined in intuitive UX markup tags.
What it means is that you can create fully customized UIs that look exactly the way you want and still run smoothly at 60 FPS. You can even add real-time visual effects like dynamic drop shadows, blur and glass panels (even on top of video), and much more.
Fuse lets you build things that simply would not be feasible with standard platform UIs, or HTML for that matter.
These UIs can look the exactly same on all platforms, or you can specify Android- and iOS-specific variations inside the same project. In this way you get the maximum amount of code sharing, also for the front-end.
You can even combine native platform components with custom ones. For instance by using native maps in an otherwise completely custom app. Or having one special (very fancy!) view inside a standard native UI.
An added benefit of working with this type of UI is that you can use our lightning fast desktop preview window while editing your app.
Visual tooling & design tool integration
Fuse is also intended for designers and although many of them are very comfortable working with markup languages, there are even more who’d rather have visual tools. Additionally, the ability to import designs & assets from other tools is useful to all of them.
And of course, front-end work is an iterative process for everyone. Even the most hardcore text-editor-and-terminal coders among us should see the benefit of a color-picker or a slider that adjusts font sizes in real-time. We, like others, have been inspired by Josh Puckett’s series of posts on modern design tools and Bret Victor’s great talk “Inventing on Principle”. If you want to know where we’re headed, take a look at those.
Some early versions (well, prototypes) of this have been included in Fuse for quite a while now. More specifically: the Inspector, which gives you a GUI to tweak UX properties in real time, and the Sketch importer. However, this is only the beginning. :) We are currently building a larger tool suite to enable a fully visual workflow for building UIs in Fuse, from layout to animation, gestures and navigation.
As far as I’m aware there’s nothing similar to what I’ve sketched out above available for NativeScript or React Native.
Also, while I’m obviously biased, I’d say that the architecture of Fuse is what makes it possible to do this. Since “everything visual and interactive” is accessible through UX you can have very powerful tools that are basically (fancy) WYSIWYG XML editors.
This is obviously connected to my next point..
Live reload / real-time editing
All three solutions have some sort of live / hot reload functionality which automatically notices any changes you do to the source code and applies those to the app running on a connected device. This is obviously very useful when working on the app and provides a much smoother workflow than traditional change-recompile-deploy-test-repeat cycles.
However, once again Fuse does this a bit differently and takes the concept further.
First of all, in addition to JavaScript updates, Fuse does the same thing for UX markup. This means that even though it’s all native code you can still work with animation, navigation, effects and everything else UX has to offer, without any recompilation!
The details of how this is implemented should be discussed in a more technical post, but basically, it’s achieved by a small module which Fuse inserts when you build in preview mode. This module receives updates about changes to UX files and automatically instantiates new native classes and re-populates the UI.
Secondly, this also means that it’s possible to edit everything in real time, without even restarting the app! The difference between the two is quite staggering:
- Hot reload: changing something in a text editor, saving the file and having the app restart with the changes applied (and maybe having to manually navigate to where the change is visible).
- Live editing in Fuse: dragging a slider back and forth while inspecting how the UI layout works as you change the size of a font or an image on multiple devices with different form factors, all at the same time. Instant feedback.
Right now this is demonstrated in the Fuse Inspector, and it’s, of course, the basis for a lot of the new visual tooling mentioned above.
Again I think this demonstrates the difference in philosophy between the frameworks quite well. Fuse aims to give you a more streamlined way of working on apps that go far beyond simply “saving the developer from recompiling”.
Conclusion
Hopefully this has provided you with a bit more information about what Fuse actually is and how it differs in many aspects from other app development solutions out there.
While I didn’t set out to claim that “Fuse is best!” I do hope this post at least gives you an idea about why we think it’s worth building.
The best way to summarize it might be this:
While React Native and NativeScript exist to let JavaScript developers write apps using native UIs (which is a great thing in itself), Fuse is about providing much better overall workflows for both designers and developers, with a very strong focus on user experience and front-end.
It’s a fairly ambitious goal but we think we’re on the right way. We would definitely like to hear your opinions on it as well, so, unless this post has scared you too much, grab it from fusetools.com/downloads and give it a go!
And of course, this post doesn’t come anywhere near covering all the differences or technical details so please let us know if there’s anything else you’d like to know about Fuse.