Hybrid Desktop Applications – Another part of the JavaScript ecosystem?

WRITTEN BY GARETH DUNNE @DUNNEDEV

JavaScript hybrid mobile applications having taken the spotlight for the last few years with the idea of writing code once and using it among many platforms.

These hybrid application frameworks such as Ionic, use HTML, CSS and JavaScript to build versatile WebView mobile applications. This exact same stack is also available to be used to build desktop applications.

Specifically, the platform Electron is the leading framework for building hybrid desktop applications in this fashion.

Check out this Git here and a great introduction here.

Interestingly, this is yet another way for JavaScript developers to utilise their own array of tools to avoid native platform specific desktop programming languages such as C# and Java and to instead use Angular to create desktop based application that can be deployed onto OSX, Windows and Linux.

Popularity

First of all, you might be wondering if anyone is actually using technologies like Electron? You might be surprised, when looking at some well established products and applications that are using this hybrid tech stack I came across the following notable players:

Personally, I use at least two of these on a daily basis. Its quite impressive that some of these big names have already adapted Electron so quickly.

Most notably, however, is that Visual Studio Code (my favourite code editor to use) was built in Electron. This a text editor that is on par with its IDE counterparts in terms of functionality.

It is reassuring to know that there are already well-established applications out there but what advantages could Electron have provided them?

Productivity

To be honest, this is always going to be where a hybrid framework shines. In terms of managing resources, a dev team with the same skillset (HTMLJavaScript, Angular, CSS) can be spread out between web applications and desktop applications that can written once and deployed to multiple operating systems.

Cross platform sharing of code is always going to help a developer or teams productivity. Electron lowers barriers to entry for desktop development by providing these familiar tools for web developers. Their familiarity with these tools will in turn increase their work output and productivity.

Say what you like about how it fares against its native competitors, however, you must admit any company will be intrigued by that productivity boost alone.

For some companies this is enough of a compelling case to use it, despite some performance and stability trade offs.

Performance

This is quite possibly the most controversial aspect when Electron is compared to native desktop programming languages.

Some articles such as this would really try and put the nail in the coffin of frameworks like Electron before its given its fair share as an alternate way to create performant desktop applications.

And while the title of the article is offbeat and bit outlandish there is certainly a very good argument to say that hybrid desktop applications will never compare to its native counterparts due to things like having to use a web browser in a desktop app which puts a strain on resources as it is.

However, why exactly do hybrid applications have to match native performance? As memory allocation in our hardware is consistently getting better I see no problem creating apps in Electron. It can be a lot more efficient then natively developing every single possible version of an application that needs to be on OSx, Mac and Linux.

Again, I want to use Visual Studio Code as a focal point here. It of course is built using Electron and makes a strong case for being a tight competitor to major code editors like Atom and Sublime.

In terms of functionality it is as robust as major text editors such as Atom and Sublime, with seamless Git integration and an extension package window to boot.

Getting Started

I’m no expert on Electron and hybrid desktop applications in general. So this post just sums up what I’ve noticed so far. It really seems very promising and yet another way to hone your JavaScript skills and apply them to a new area of app production.

How it compares to natively developed desktop apps should only hold huge weight at a more enterprise level and even with this in mind, it doesn’t seem to stop some very big names for utilising it for major enterprise apps.

The most important thing to take away from this as a frontend dev is to know that you have yet another big section of tech product development that you can move into. Making us in more versatile in what we can achieve.

Ultimately, I suppose you have to ask yourself when will this JavaScript growth start to plateau? How many sections of development can JavaScript be adapted to? So many years ago it was boxed off as just a web-focused technology in conjunction with HTML and CSS, but its meteoric rise in other areas is now undeniable.

It’s unclear whats going to happen next but it is on a upward spiral so the future looks very promising. It may not be for the native purists because a lot of web based programming goes against what makes native languages for desktop great.

For such a promising framework such as Electron I haven’t found too many learning resources for it. Here are some of the best I’ve found so far.

I hope to cover more of this framework in the future.

Ionic vs React Native – What is the best choice for your mobile app?

WRITTEN BY GARETH DUNNE @DUNNEDEV

The mobile app development market isn’t what it used to be for developers. In contrast to 5 or 10 years ago, the Android and iOS stores were locked to you as a developer depending on your ability to learn the native languages related to either option.

We are now given a plethora of choices when it comes to determining the right technology that you want to create your applications with.

Technologies that allow you, as a developer, to be no longer restricted to one store depending on what language that you know.  Mobile development using JavaScript opens up so much more opportunity for a developer or a team seeking to finish their own ideas while also having a much broader market to publish it to.

These choices are usually categorised as either WebView app development (Ionic, Xamirin) which runs an app through a web browser on a mobile phone. Or native app development (React Native, NativeScript) which use core native components through an API to run in a mobile application.

In this post, I want to compare Ionic to React Native, as personally, I would consider both to be key frameworks in each of their respective fields of hybrid app development.

If your looking for a learning resource for React Native you can look here.

I have also published my Ionic app to the Android store (soon to be iOS as well) so fell free check it out if your keen on seeing an Ionic app in action.

Android Coffee Finder Application CoffeeTrail
CoffeeTrail

Language

Both of these technologies are built around using JavaScript. Ionic is based around the Angular 5 framework. This is quite beneficial as you have full access to the Ionic CLI to scaffold a project, generating your components/pages/services via the command line.

Ionic’s combination with Angular means that you will be using TypeScript by default which is an awesome subset of JavaScript and allows you to define types while having object oriented JavaScript code.

TypeScript can also be used in React Native but will take another step to setup initially or you could just check out this template here.

React Native is based on React.js a very popular frontend development library. Its focus is on its reusable components that are shared between mobile and web versions.

Both frameworks use the latest in ES6 practises including classes, arrow functions, templates string etc. Basically, on a core JavaScript level they are both stacking the latest and greatest.

I wouldn’t be too concerned either way here, if you are a fan of Angular and how it scaffolds its projects, services and components then Ionic might be more appealing.

On the flipside if your already familiar with React.js’s style of functional programming than React Native will just be a continuation of that with its own style of native mobile components.

Ease of use

A lot of the ease of use of an Ionic application can to attributed to the readily available list of Native Components and its CLI generator.

Ionic provides these native components plugins such as Geolocation or Google Maps with relative to ease to install.

Simply add them using Cordova (which comes with the Ionic framework)

And then import them into your project using ES6 import syntax.

The documentation for these native plugins is actually quite verbose and its clear how you can utilize various additional methods to get the most out of your desired plugin.

In contrast to this React Native uses APIs that are accessed through the global navigator object. You can then call any relevant methods that are related to the native functionality that you want to use.

For example:

On the navigator.geolocationobject you can call any of the following methods getCurrentPosition(), watchPosition(), and clearWatch().

Check out the full list of React Native API’s here.

Overall, I think I’d edge towards Ionic on this one. Apart from the wide range of documented plugins. The core CLI in combination with Cordova gives you plenty of commands and tools to generate resources, splash images, building tools as well the recently released Ionic Dev which provides you with an app to test your creation on any device you want.

For me, these testing tools allow a dev to access a wide range of devices and increases the accessibility of using Ionic over React Native.

Performance

Perhaps the most defining aspect when comparing both of these technologies, performance is always a big worry when dealing with hybrid mobile applications.

This is where React Native truly stands out. React was fast to begin with and was even comparable to natively developed app speeds for the most part. However with the release of React Fiber  it is now much more responsive to browser events.

Not only this but Fiber assigns different priorities to different types of UI updates with the more important ones taking priority when React re-renders.

For a more detailed guide to React Fiber I’d recommend this post here by Mark Cruz.

To summarize, React Fiber works smarter, not necessarily faster. The priority given to more important tasks results in a faster application.

In comparison to this Ionic is still not bad performance wise. In fact, it has come an awful long way since its first version.

Ionic 3 was released with lazy loading modules taken from Angular. This has certainly increased initial loading times of the application as well as subsequent loading of pages and assets.

Lazy loading enables the app to only load the modules that it needs at any given time.  A great feature undoubtedly but still isn’t up to snuff when compared to React Native’s native component library.

Maintainability

Due to of some platform specific code segments of React Native, the ability to maintain an application is a bit more difficult. Whereas in Ionic, a functionality change for example, will be reflected in both iOS and Android builds, for the most part anyway.

Here is a snippet of how to target Android exclusively in React Native:

Importing and using the Platform module is probably the exception rather than the rule here, the majority of React Native components have both an iOS and Android equivalent so in most cases this shouldn’t be necessary.

Its definitely not difficult to target platforms like this but it seems more frequent in comparison to Ionic where I very rarely found myself using platform specific code with the exception of styling some components.

Size

The bundle size of your application plays a big role in defining how big or small your .apk and .ipa files will beI found Ionic to have smaller bundling size overall.

Without doing statistical comparisons for both on compilation code and bundles (which I’ve struggled to find in 2017) theres not much to say here really, React Native’s component library tends to be heavier and this is the price for a faster and closer to native application.

Which is best for you?

Overall, theres quite a lot to digest here. While both are great platforms to launch your app the overall performance benefits for React Native as well as its recently released fiber potential really edges for me.

This really opens up how powerful React Native can be with significant performance enhancements when compared to Ionic.

But don’t get me wrong Ionic really shines in its own way, its fundamental paradigm of write once, use everywhere allows you to usually have consistent code between your iOS and Android versions.

In this way, React Native is more work for its platform specific code but even with this in mind, for me, the performance of React Native still outweighs this benefit.

I have had much more exposure to Ionic thus far but with my recent projects using  React.js and Redux,  I’m really looking forward to applying this way of functional programming to create apps.

At the end of the day, you can use both platforms to achieve your hybrid application goals.  They certainty differ, with React Native really nailing performance and Ionic providing more accessibility.

They both also have a great communities to boot so until one becomes miles ahead of the other your not doing yourself any disservice to your future applications by picking either one.

So if you feel like getting started on either one, I’ve included some sample tutorials that I’d recommend:

 

Angular 5 Released

WRITTEN BY GARETH DUNNE @DUNNEDEV

As of 1st of November,  the latest version of Angular (Angular 5) has been released.
The release is named Pentagonal Donut and is the latest of Angular releases in its semantic versioning release schedule. The release details many additional features which I want to cover here.

Much to the dismay of some of the web dev community the semantic versioning of Angular is to continue with each release being marketed as a brand new version. I personally don’t have too much of a problem with it changing every 4 or 5 months but I completely see why the new iterations may confuse and annoy devs within the frontend community.

Similar to the way that I’m detailing Angular 5 in this post, this release provides an opportunity for those to remarket their courses and tutorials with the shiny new version of Angular.

I haven’t found any specific Angular 5 learning material but this might suffice until there are any updated learning resources.

While I’m sure plenty will cover the new features in great detail, I wouldn’t worry about feeling compelled to learn this completely new version of Angular because in reality these releases don’t tend to be groundbreaking and usually have minor breaking changes to previous versions.

Lets highlight some of the new features.

AOT

During the build time of your Angular applications you had to previously specify AOT (Ahead Of Time compilation) like so:

This is now occurs by default so you now longer have to specify the ng build.

Performance of AOT has also been increased with faster rendering, less asynchronous requests and an overall reduction of download sizes. This added feature really aims to improve the speed of Angular bundling in development and production and is welcome improvement to AOT.

An interesting watch mode command has also been added.

The idea of this command it to enable your application to only recompile when absolutely necessary. Therefore it will be much easier to use AOT in development mode rather than just production mode because previously, the whole application would recompile when a change was made making it only useful for production.

Forms

Some small changes having been made to the forms API. You can now specify to run validation on submitting a full form rather than it occurring on individual input fields.

We also now have the option to specify when to update a inputs fields value or validation state.

For more Angular 5 form examples check out this post here.

Animations

A small change has been added to animations for your application.

You can now invoke an animation when a desired value is incremented or decremented. 

This is a very handy feature as many use cases of an animation can depend on a value changing but having two new aliases in :increment and :decrement allows us to apply a specific animation to a value going up or down, in this case we want the font size and color to be affected.

Http

There has been some minor changes here, including the deprecation of the HTTP API. @angular/http which has now been replaced by @angular/common/http.

Pipes

Pipes have been overhauled and no longer rely on the Intl API. The most common pipes that you might have used that would rely on this are number, percent, currency etc.

The currency pipe now takes a string as a second parameter.

If you don’t want to use the new pipes you can still get access to the older versions by importing DeprecatedI18NPipesModule .

These are just a small snippet of the changes. For an extensive look at all updated pipes have a look here.

Conclusion

While the ever changing semantic versioning may get on the nerves of some of the dev community, Angular 5 a pretty nice update overall.

These frequent big updates are a smart move on behalf of the Angular team. It increases the marketability of the framework and also constantly keeping it in the limelight each time while not providing anything too earthshattering.

I’ve only covered some of the new features here, feel free to check them out in summary by Traversy Media.

I’m also still a big fan of Gary Simon’s content from Coursetro. So feel free to check that out too.

Feel free to check out the Angular release schedule here as well.