Slack Native app was born as a experiment I recently went through the great read that is And Seph, the author, is absolutely right. Electron is Flash for the Desktop . 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 . I directly access the services on Firefox too, which did actually improve the computer performance. Now it’s rare to hear it hyperventilate. so called apps 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 article, we could take advantage of Native (e.g. I am sure there are other alternatives with the same focus, as may be). Electron is the new Flash React NativeScript So I did a very brief experiment. Since the Slack desktop is very similar to the web, that uses a component instead of electron. The result is It certainly still misses many functionalities, as notifications, and multiple teams, but it would not be difficult to implement those using slack API. app I just decided to embed the service in a webview native Slack Native. adhoc 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. is the name of the process running on a `react-native-macos` webview. SlackNative 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: . We could also fork this to windows using so the same codebase (which by the moment is a webview only) could supply for both major operative systems. https://github.com/jsdario/SlackNative react-native-windows, I would like to see more people replicating this effort to bring to the native world Spotify, for example, or, 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 (have faster response, a more sublime like experience) without sacrificing the flexibility, the plugins and the so-called hackability. above all: Atom . native 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 but can’t compete at the moment of the writing against a native implementation. workaround 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 . 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. learn once write anywhere 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.
