Slack Native app was born as a experiment
I recently went through the great read that is Electron is Flash for the Desktop. And Seph, the author, is absolutely right.
I am no hater of Electron. It has incredible benefits within a simple API and great mantainers. It, as a fact, enables us –developers– to create and maintain better user experiences through multiple platforms. You will realize with just a glance, that the majority of the apps you are using, are indeed, webapps:
263MB and 58 threads for a text editor.
315MB and 64 threads.
I also gave up on using Slack and Spotify so called apps. I directly access the services on Firefox too, which did actually improve the computer performance. Now it’s rare to hear it hyperventilate.
The laptop was not a bargain, it used to be latest edition Macbook Pro 3 years ago, but I always sacrificied disk space to take down the price of the thing. Now I need it more than ever because I need lots of swap space. The machine is alright, therefore, the solution (if I still want to enjoy installed apps) must be in the software.
Out of curiosity I asked on Reactiflux Discord’s channel about a possible solution (or workaround, by the moment) I had in mind:
So we have something to work on, now. Without having to wait for our favourite services to start developing native apps. However acceptance tests and so suppose much more work — and this is just a little experiment, so won’t be writing about this for the moment.
Bringing apps to Native
We must not resign the benefits of electron, but we can use the latest paradigms out there to create great software experiences. As it is mentioned in the Electron is the new Flash article, we could take advantage of React Native (e.g. I am sure there are other alternatives with the same focus, as NativeScript may be).
So I did a very brief experiment. Since the Slack desktop app is very similar to the web, I just decided to embed the service in a webview that uses a native component instead of electron. The result is Slack Native. It certainly still misses many functionalities, as notifications, and multiple teams, but it would not be difficult to implement those adhoc using slack API.
The result is, as expected, almost identical to the electron version (in the end both rely on very similar engines) but with less than half the RAM being used at the same time. SlackNative is the name of the process running on a `react-native-macos` webview.
There you have Electron with all those misterious helpers
You can find the repo where we can take the effort of making Slack just a bit more native here: https://github.com/jsdario/SlackNative. We could also fork this to windows using react-native-windows, so the same codebase (which by the moment is a webview only) could supply for both major operative systems.
I would like to see more people replicating this effort to bring to the native world Spotify, for example, or, above all: Atom. Which, in the beginning, was to be the objective of this experiment. However Atom is not entirely a webapp, it is just made using web-coming technologies. It should be extra interesting to work on a way to make Atom be more native (have faster response, a more sublime like experience) without sacrificing the flexibility, the plugins and the so-called hackability.
Dear reader, you should be eskeptic about the results of this experiment. I did not further implement better proof that this is the way to go. This post is more about the problem than the solution. Anyway, it is relevant that 5 lines of code would so highly reduce RAM usage. It is more of a prove of two hypothesis:
- We need, and will use web technologies to create crossplatform apps until a new solution comes to town.
- To recreate a full browser to use web tools is a good workaround but can’t compete at the moment of the writing against a native implementation.
So it would make complete sense to separate completely business logic (or use case logic) from presentation. It fits naturally that physical devices with different forms and sizes invest in their own displays: a Pebble must not offer the same UI or user level API than an iOS device or an Android TV. React Native mission is that you can learn once write anywhere. This means that the model that represents component logic must be offered in a language or interface easily accesible to all developers (if you want them to create apps that are native to your platform). It does not mean that vendors renounce on which OS level apparel they want to provide.
I guess that all the point of the article is: the paradigm has shifted, but the objective is the same. We can either build entire runtimes that support our webapps on (Electron) or we can build environment and tools that understand our webapps and give birth to a native one.