In December 2019, I sadly dislocated my shoulder.

During the recovery process, as part of the therapy, my doctor recommended some exercises, but those were extremely boring. Subsequently, I decided to make the recovery fun and interactive.

Based on that, I took those exercises and mixed them with hardware and software to create a rehabilitation game. In order to make therapy fun, the application needed to transfer data in real-time to give the user a comfortable interaction with the game. A lot of references recommend Node.js and WebSocket for that, and many questions arose.

Why are these tools useful? What characteristics do they have? In which scenario is it recommended to be used? How do they help us in the process of building real-time applications?

The following article takes each tool, identifies the main characteristics, and explains how each concept works. Then, as a conclusion, you can learn how these pieces work together and highlight important considerations of their use.

Node.js

Node.js is a JavaScript runtime environment designed to build scalable network applications. Most of the time we used to hear the facts that Node is non-blocking, single-threaded, asynchronous, concurrent... But, what does it really mean in this context? Let’s discover it.

What is single-thread?

Node.js is single-threaded. One thread means one call stack, one call stack means one thing at a time.

Hmm, that's suspicious. If we want things in real-time, doing only one thing at a time does not sound like a good approach, right? Let's find out!

What is the call stack?

The call stack is a data structure that follows the LIFO approach (“Last In, First Out”), so basically what it does is push and pop different instructions read from the code. It is a very important piece of Node.js because it will store the execution order of the program and we should take special consideration with it because as there is only one if it is busy our application will be busy.

What is non-blocking?

Non-blocking is one of those concepts which are easier to understand if we understand first their opposite. Having said that, the concept of blocking refers to all those instructions that block the execution of others until that instruction finishes. Otherwise, non-blocking are instructions that can be done without blocking any other instruction.

Taken into consideration that our goal is to build applications that transfer data in real-time, the fact that JavaScript is a blocking language can surprise us. Fortunately, we can "make it” non-blocking by introducing the concepts of asynchronous and event loop.

What is asynchronous?

In JavaScript, asynchronous is the relation between now and later. But later does not mean after now. It means at one point in the future, a moment that you would not necessarily know when it will be.

Because of its definition and remembering what single-thread means if we don’t have certainty about when our asynchronous task will be done, having those into the call stack will slow down the performance of the application. For that reason, those are executed in the form of “promises” or “callbacks” out of the call stack by default.

When the asynchronous instructions are resolved, they need to return to the call stack, and for that, they follow a route that visits two other processes before: first the callback queue, and then the event loop.

What is the callback queue?

The callback queue is a “first in first out” (FIFO) data structure type that receives and stores momentarily, resolved asynchronous code and because of that, it is a crucial support to the event loop.

What is the event loop?

The event loop is a very simple but important part of how Node.js works. It is a continuously looping process where the main goal is to pass an instruction to the call stack from the callback queue but only if the call stack is empty.

What is concurrency?

Concurrency is when two or more processes run together but not at the same time, it means that the execution “jumps” between processes. Even when Node.js is single-threaded, it supports thousands of concurrent connections with a single server.

This happens because Node.js offloads I/O operations to the system kernel whenever possible and most of the modern operating systems’ kernels are multi-threaded. This way, Node.js can handle one JavaScript operation at a time but a lot of I/O operations at the same time.

Putting pieces together

Our applications can have tons of instructions, some of them could be “fast” to execute such as it is an assign (assigning a value to a variable) but there are others that can be kind of “slow” e.g. network requests.

Regarding the facts that Node.js is single-thread and JavaScript is a blocking language we could assume that if our application needs to make a lot of “slow” instructions, the call stack will be busy and the performance of the app will decrease, but there is where the relevance of Node.js lies because it brings a different approach to face that scenario based on its other features.

Taking into consideration the concepts of non-blocking and asynchronous, the “slow” instructions can be executed as promises or callbacks, and this way those will be taken off from the call stack and delegate the execution of them to “someone” with the capacity to deal with it.

Once the “slow” instruction is resolved, it will return to the call stack by the functionality of the callback queue and the event loop. Thus, the “slow” tasks can be done without saturating the call stack and without affecting the performance of the app.

Having described the principal parts of Node.js and how those work together, let’s do the same now with the WebSocket protocol.

WebSocket

WebSockets came to facilitate the process of building applications in real-time because it is a protocol designed to establish persistent bidirectional communication between a client and a server by a TCP connection.

Its functionality allows both parties to have a persistent “conversation” by first establishing a connection with an initial “handshake” and then by sending bidirectionally the packages to exchange.

Let’s detail other pieces related to this protocol such as its API, lifecycle, scalability, and more.

What is a protocol?

A protocol is a set of syntaxes, rules, and semantics that allow two or more entities or machines to transmit information. Communication worldwide will not be possible without those standards. Some of them are TCP, MQTT, HTTPS, and of course WebSocket.

What is real-time data transfer?

Real-time data transfer consists of basically delivered data immediately after collection without delays in the transmissions of them. It's very used nowadays in a lot of applications such as chats, navigation, gaming, tracking, and so on. By the persistent and bidirectional WebSocket’s connection, the exchange of packages in a few steps is possible, which facilitates the real-time data transfer between applications.

WebSockets’ connection lifecycle

The lifecycle of a WebSockets’ connection can be divided into 3 phases, the first step starts with requesting the establishment of a connection. Then, after the connection was established, the protocol is able to transfer packages bidirectional between sides. And at last, when for some reason there is not required to exchange more data, the connection needs to be closed.

Establish the connection

Before starting to exchange data is needed to establish the connection, it is known as an “initial handshake”. It consists of sending a regular HTTP connection with an “upgrade” header from the client to the server, which indicates the solicitude to change the protocol used. The server received it and in case it supports the WebSocket protocol, it agrees to the upgrade and communicates this through a header response.

After that, the handshake is done and the initial HTTP connection is replaced by a WebSocket connection that uses the same initial TCP/IP connection.

Use of the connection

At this time both sides are allowed to send and receive data by the WebSocket protocol. Packages can be exchanged bidirectionally anytime and are in this phase when more of the events and methods that the WebSocket API brings can be used in a practical way.

Close connection

In order to make smart use of resources, it is important to close the connection whenever it is not used anymore, for that, both sides have equal rights to close the connection, all it has to do is to send the request using the “close” method with two optional params who indicate, respectively, the closing code and the reason of the action.

WebSocket API

This protocol offers a simple but useful interface to interact with it. There are a total of two methods and four events.

• Send (method): send data
• Close (method): close the connection
• Open (event): connection established. Available via the onopen property.
• Message (event): data received. Available via the onmessage property.
• Error (event): WebSocket error. Available via the onerror property.
• Close (event): connection closed. Available via the onclose property.

Then, the API offers other attributes such as binaryType, readyState, or bufferedAmount that allow us to make custom logic implementations as for example a rate limit to prevent DoS attacks to the server. Also, there are many WebSocket libraries that facilitate this and other high-level mechanisms.

Encrypted WebSocket

Using the ws URL schema it is possible to establish a WebSocket connection.

let socket = new WebSocket("ws://nodesource.com");

But it is also possible using the ‘wss’ URL schema too.

let socket = new WebSocket("wss://nodesource.com");

The main difference between them is that there is an ‘s’ of more in the second URL schema but that change has more implications than just the addition of a letter. That “s” stands for “secure” which means that this connection is encrypted using WebSocket over SSL/TLS.

As an analogy, WSS is to WS the same as HTTPS is to HTTP because HTTPS is an encrypted version of HTTP. For security reasons, it is highly recommended to use the encrypted way in both protocols.

Scalability

Scalability is a crucial consideration to have in mind in the design process of an application because otherwise, we can face non-beneficent scenarios when the moment of growth comes.

In order to increase the capacity and functionalities of the app when it requires there are two approaches to apply: vertical scalability and horizontal scalability.

Vertical scalability consists of adding more resources to the server, as for example more RAM, better CPU, or so on. It is a fast way to grow but it has limitations because we can’t do that infinitely.

Horizontal scalability is about adding more instances of the server. It will require more configuration but it is a solution that can be implemented the number of times required. However, regarding the main characteristic of the WebSocket, which is the persistent bidirectional connection, we have that it is generated an important situation when we try to scale horizontally.

This happens because when the socket connection is established, it is bound to specific instances of a client and a server, and if we increase the number of instances in the backend, there is a possibility that the client requests a server's instance that has no idea about that connection established.

Anyway, there are alternatives to implement in order to avoid the situation explained, as for example, the implementation of a load balancer configured with a sticky-session. This way, those implementations will allow the client to request the correct server’s instance.

Conclusions

Node.js

Node.js is a relevant tool to develop real-time applications because, among others, it has the particularity to execute each instruction according to its characteristics and needs. It means that it can either execute tasks really fast on the call stack using synchronous code or delegate to someone else when it requires more processing power through the use of asynchronous code. This combination makes smart use of the resources and keeps in good shape the performance of the application.

We could get confused with some characteristics that at the beginning don't seem to be from a proficient tool for the development of real-time applications, such as the fact that JavaScript is a blocking language or that Node.js is single-threaded. But when we see the whole picture, we find other characteristics (for example, the asynchronous code and the event loop) that allow us to understand how Node.js works and how it takes advantage of its strengths and weaknesses.

It's important to understand too that because of all those characteristics we already mentioned before, Node.js is an excellent option not only for real-time applications but for applications that need to handle multiple I/O requests in general. Same way, it does not represent the best approach if it is required to deal with intensive CPU computing.

WebSocket

WebSocket is a protocol that establishes persistent bidirectional communication between parties. It provides a mechanism for browser-based applications that need two-way communication with servers that do not rely on opening multiple HTTP connections, which makes it a very useful tool in the development of real-time applications.

It presents an API that simplifies the interaction with the protocol but it does not include some common high-level mechanisms such as reconnection, authentication, or many others. However, it is possible to implement them manually or through a library. Also, the protocol offers an encrypted option for the exchange of packages and it is composed of a three-phase life cycle connection.

On other hand, it's important to have in mind that the horizontal scalability of an app with WebSockets will require extra steps, including adding more pieces to the architecture of the app and implementing configurations. Those extra steps are important to have in consideration in the design process of the app because, otherwise, it could represent non-beneficent scenarios in the future.

Finally, regarding my use case, the rehabilitation game consists of taking human movement and control in this way by running dinosaur game from Chrome. In that context, the WebSocket’s open connection allows exchanging, between the backend and frontend, the movements translated in data without the necessity to open a new HTTPS connection each time a movement is detected. About Node.js, its characteristics help the fast processing of the instructions which allows the real-time communication.

This blog post was first published in thedreaming.org blog.

I’m working on a reporting engine right now, and one of the requirements I have is to be able to export reports as PDF files, and send PDF reports via email. We also have a management page where you can see all the dashboards, and we’d like to render a PNG thumbnail of the dashboard to show here. Our back-end is all Node.js based, and you’re probably aware that Node is not known for it’s graphics prowess. All of our reports are currently being generated by a React app, written with Gatsby.js, so what we’d like to do is load up a report in a headless browser of some sort, and then either “print” that to PDF or take a PNG image. We’re going to look at doing exactly this using Playwright and Browserless.

The basic idea here is we want an API endpoint we can call into as an authenticated user, and get it to render a PDF of a web page for us. To do this we’re going to use two tools. The first is playwright, which is a library from Microsoft for controlling a headless Chrome or Firefox browser. The second is browserless, a microservice which hosts one or more headless Chrome browsers for us.

If you have a very simple use case, you might actually be able to do this entirely with browserless with their APIs. There’s a /pdf REST API which would do pretty much what we want here. We can pass in cookies and custom headers to authenticate our user to the reporting backend, we can set the width of the viewport to something reasonable (since of course our analytics page is responsive, and we want the desktop version in our PDF reports, not the mobile version).

But, playwright offers us two nice features that make it desirable here. First it has a much more expressive API. It’s easy, for example, to load a page, wait for a certain selector to be present (or not be present) to signal that the page is loaded, and then generate a PDF or screenshot. Second, when you npm install playwright, it will download a copy of Chrome and Firefox automatically, so when we’re running this locally in development mode we don’t even need the browserless container running.

Setting up and configuring playwright

In our backend analytics project, we’re going to start out by installing playwright:

$ npm install playwright

You’ll notice the first time you do this, it downloads a few hundred megs of browser binaries and stores them (on my mac) in ~/Library/Caches/ms-playwright. Later on, when we deploy our reporting microservice in a docker container, this is something we do not want to happen, because we don’t need a few hundred megs of browser binariers - that’s what browserless is for. So, in our backend project’s Dockerfile, we’ll modify our npm ci command:

RUN PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 npm ci && \
    rm -rf ~/.npm ~/.cache

If you’re not using docker, then however you run npm install in your backend, you want to add this PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD environment variable to prevent all the browser binaries from being installed.

We do want playwright to use these browser binaries when it runs locally, but in production we want to use browserless. To control this, we’re going to set up an environment variable that controls playwright’s configuration:

// Set BROWSERLESS_URL environment variable to connect to browserless.
// e.g. BROWSERLESS_URL=wss://chrome.browserless.io?token=YOUR-API-TOKEN
const BROWSERLESS_URL = process.env.BROWSERLESS_URL;

let browser: pw.Browser | undefined;

export async function getBrowser() {
  if (!browser) {
    if (BROWSERLESS_URL) {
      // Connect to the browserless server.
      browser = await pw.chromium.connect({
        wsEndpoint: BROWSERLESS_URL,
      });
    } else {
      // In dev mode, just run a headless copy of Chrome locally/
      browser = await pw.chromium.launch({
        headless: false,
      });
    }

    // If the browser disconnects, create a new browser next time.
    browser.on("disconnected", () => {
      browser = undefined;
    });
  }

  return browser;
}

This creates a shared “browser” instance which we’ll use across multiple clients. Each client will create a “context”, which is sort of like an incognito window for that client. Contexts are cheap and lots can exist in parallel, whereas browser instances are expensive, so this lets us use a single instance of Chrome to serve many users.

We’re also going to write a little helper function here to make it easier to make sure we always release a browser context when we’re done with it:

async function withBrowserContext<T = void>(
  fn: (browserContext: pw.BrowserContext) => Promise<T>
) {
  const browser = await getBrowser();
  const browserContext = await browser.newContext();

  try {
    return await fn(browserContext);
  } finally {
    // Close the borwser context when we're done with
    // it. Otherwise browserify will keep it open forever.
    await browserContext.close();
  }
}

The idea here is you call this function, and pass in a function fn that accepts a browser context as a parameter. This lets us write code like:

await withBrowserContext((context) => {
  // Do stuff here!
});

And then we don’t have to worry about cleaning up the context if we throw an expection or otherwise exit our funciton in an “unexpected” way.

Generating the PDF or PNG

Now we get to the meaty part. We want an express endpoint which actually generates the PDF or the PNG. Here’s the code, with lots of comments. Obivously this is written with my “reporting” example in mind, so you’ll need to make a few small changes if you want to give this a try; notably you’ll probably want to change the express endpoint, and change the dashboardUrl to point to whatever page you want to make a PDF or PNG of.

// We set up an enviornment variable called REPORTING_BASE_URL
// which will point to our front end on localhost when running
// this locally, or to the real frontend in production.
const REPORTING_BASE_URL =
  process.env.REPORTING_BASE_URL || "http://localhost:8000";

// Helper function for getting numbers out of query parameters.
function toNumber(val: string | undefined, def: number) {
  const result = val ? parseInt(val, 10) : def;
  return isNaN(result) ? def : result;
}

// Our express endpoint
app.post("/api/reporting/export/:dashboardId", (req, res, next) => {
  Promise.resolve()
    .then(async () => {
      const type = -req.query.type || "pdf";
      const width = toNumber(req.query.width, 1200);
      const height = toNumber(req.query.height, 800);

      // Figure out what account and dashboard we want to show in the PDF.
      // Probably want to do some validation on these in a real system, although
      // since we're passing them as query parameters to another URL, there's
      // not much chance of an injection attack here...
      const qs = new URLSearchParams({ dashboardId: req.params.dashboardId });

      // If you're not building a reporting engine, change this
      // URL to whatever you want to make into a PDF/PNG. :)
      const dashboardUrl = `${REPORTING_BASE_URL}/dashboards/dashboard?${qs.toString()}`;

      await withBrowserContext(async (browserContext) => {
        // Set up authentication in the new browser context.
        await setupAuth(context.req, browserContext);

        // Create a new tab in Chrome.
        const page = await browserContext.newPage();
        await page.setViewportSize({ width, height });

        // Load our dashboard page.
        await page.goto(dashboardUrl);

        // Since this is a client-side app, we need to
        // wait for our dashboard to actually be visible.
        await page.waitForSelector("css=.dashboard-page");

        // And then wait until all the loading spinners are done spinning.
        await page.waitForFunction(
          '!document.querySelector(".loading-spinner")'
        );

        if (type === "pdf") {
          // Generate the PDF
          const pdfBuffer = await page.pdf();

          // Now that we have the PDF, we could email it to a user, or do whatever
          // we want with it. Here we'll just return it back to the client,
          // so the client can save it.
          res.setHeader(
            "content-disposition",
            'attachment; filename="report.pdf"'
          );
          res.setHeader("content-type", "application/pdf");
          res.send(pdfBuffer);
        } else {
          // Generate a PNG
          const image = await page.screenshot();
          res.setHeader("content-type", "image/png");
          res.send(image);
        }
      });
    })
    .catch((err) => next(err));
});

As the comments say, this creates a new “browser context” and uses the context to visit our page and take a snapshot.

Authentication

There’s one bit here I kind of glossed over:

// Set up authentication in the new browser context.
await setupAuth(context.req, browserContext);

Remember that browserless is really just a headless Chrome browser. The problem here is we need to authenticate our user twice; the user needs to authenticate to this backend express endpoint, but then this is going to launch a Chrome browser and navigate to a webpage, so we need to authenticate the user in that new browser session, too (since obviously not just any user off the Internet is allowed to look at our super secret reporting dashboards). We could visit a login page and log the user in, but it’s a lot faster to just set the headers and/or cookies we need to access the page.

What exactly this setupAuth() function does is going to depend on your use case. Maybe you’ll call browserContext.setExtraHTTPHeaders() to set a JWT token. In my case, my client is authenticating with a session cookie. Unfortunately we can’t use setExtraHTTPHeaders() to just set the session cookie, because Playwright generates it’s own cookie header and we can’t override it. So instead, I’ll parse the cookie that was sent to us and then forward it on to the browser context: via browserContext.addCookies().

import * as cookieParse from "cookie-parse";
import { URL } from "url";

// Playwright doesn't let us just set the "cookie"
// header directly. We need to actually create a
// cookie in the browser. In order to make sure
// the browser sends this cookie, we need to set
// the domain of the cookie to be the same as the
// domain of the page we are loading.
const REPORTING_DOMAIN = new URL(REPORTING_BASE_URL).hostname;

async function setupAuth(
  req: HttpIncomingMessage,
  browserContext: pw.BrowserContext
) {
  // Pass through the session cookie from the client.
  const cookie = req.headers.cookie;
  const cookies = cookie ? cookieParse.parse(cookie) : undefined;

  if (cookies && cookies["session"]) {
    console.log(`Adding session cookie: ${cookies["session"]}`);
    await browserContext.addCookies([
      {
        name: "session",
        value: cookies["session"],
        httpOnly: true,
        domain: REPORTING_DOMAIN,
        path: "/",
      },
    ]);
  }
}

We actually don’t have to worry about the case where the session cookie isn’t set - the client will just get a screenshot of whatever they would have gotten if they weren’t logged in!

If we log in to our UI, and then visit http://localhost:8000/api/reporting/export/1234, we should now see a screenshot of our beautiful reporting dashboard.

Cleaning up site headers

If you actually give this a try, you might notice that your PDF has all your menus and navigation in it. Fortunately, this is easy to fix with a little CSS. Playwright/browserless will render the PDF with the CSS media set to “print”, exactly as if you were trying to print this page from a browser. So all we need to do is set up some CSS to hide our site’s navigation for that media type:

@media print {
  .menu,
  .sidebar {
    display: none;
  }
}

An alternative here might be to pass in an extra query parameter like bare=true, although the CSS version is nice because then if someone tries to actually print our page from their browser, it’ll work.

Setting up Browserless

So far we’ve been letting Playwright launch a Chrome instance for us. This works fine when we’re debugging locally, but in production, we’re going to want to run that Chrome instance as a microservice in another container, and for that we’re going to use browserless. How you deploy browserless in your production system is outside the scope of this article, just because there’s so many different ways you could do it, but let’s use docker-compose to run a local copy of browserless, and get our example above to connect to it.

First, our docker-compose.yml file:

version: "3.6"
services:
  browserless:
    image: browserless/chrome:latest
    ports:
      - "3100:3000"
    environment:
      - MAX_CONCURRENT_SESSIONS=10
      - TOKEN=2cbc5771-38f2-4dcf-8774-50ad51a971b8

Now we can run docker-compose up -d to run a copy of browserless, and it will be available on port 3100, and set up a token so not just anyone can access it.

Now here I’m going to run into a little problem. The UI I want to take PDFs and screenshots from is a Gatsby app running on localhost:8000 on my Mac. The problem is, this port is not going to be visible from inside my docker VM. There’s a variety of ways around this problem, but here we’ll use ngrok to set up a publically accessible tunnel to localhost, which will be visible inside the docker container:

$ ngrok http 8000
Forwarding                    http://c3b3d3d435f1.ngrok.io -> localhost:8000
Forwarding                    https://c3b3d3d435f1.ngrok.io -> localhost:8000

Now we can run our reporting engine with:

$ BROWSERLESS_URL=ws://localhost:3100?token=2cbc5771-38f2-4dcf-8774-50ad51a971b8 \
    REPORTING_BASE_URL=https://c3b3d3d435f1.ngrok.io
    node ./dist/bin/server.js

And now if we try to hit up our endpoint, we should once again see a screenshot of our app!

Hopefully this was helpful! If you try this out, or have a similar (or better!) solution, please let us know!

Mobile app development is time-intensive and complex. For developers, it’s a challenge to build an app that’s efficient and could also run on several platforms. Cross-platform app development helps organizations have a better reach to the target audience.

Cross-platform is a framework through which a mobile application runs on various platforms. Developers should write code just once and run it anywhere for any platform of choice. Cross-platform application development has its own merits, which play a critical role in its popularity today.

As its reach grew, several development tools and frameworks started coming out in the market. Gradually, and then suddenly, mobile app developers, including a Nodejs development company are trying their hands at this one-of-a-kind technology.

The Pros Of Cross-platform Apps

1. Reusable codes. Rather than writing fresh codes for each platform, developers could reuse the same code across platforms. Furthermore, this cuts down on tasks that are repetitive, eliminating hard work. This however is not a new concept. It’s been used in software development for several years now, and the benefits of being able to reuse code have been witnessed too.

2. Faster development time. Developing cross-platform apps is quicker when a single script is deployed. On the other hand, increased speed in development results in a product reaching the marketplace much sooner. Time could be allocated on working out codes for a brand new app. The situation is a win-win for all concerned, such as developers, marketers, and users.

3. Seamless implementation. Today, many technologies offer cross-platform solutions, making it easy for developers to do changes. A tool like Appcelerator for instance is used, codes could be written easily in HTML5, and converted for various platforms. This makes app development faster, and also easier to synch updates across different mobile devices.

4. Cost control. Thanks to cross-platform mobile application development, and the services of developers, like for instance NodeJS development services, companies now only need a one-time investment to have their app developed, in contrast to earlier times when they need to heavily spend on various technologies and tools. They need not spend on separately developing apps for every platform. Furthermore, the same team could be made to work on different platforms for app developers.

Top Ten Cross-Platform App Frameworks 2020

As technology continues to evolve, the IT field and business organizations need to keep up with the changes to remain relevant. When it comes to developing cross-platform apps, there are numerous frameworks to choose from. Here, I have gathered an in-depth view of the top cross-platform app frameworks that are highly used by service providers.

1. React Native

When it comes to cross-platform app development, it’s not easy to not include React Native. Created on JavaScript, it’s great for writing real code and providing a native-feel to mobile apps.

Features

• Has huge community support, boosting it via introducing and improving features, and bug fixing.
• The one-time coding reduces development time instantly, along with keeping the cost at its lowest.
• No need to require developers to separately code twice for the same application on various platforms.
• To a big extent, focuses on the UI, rendering an interface that’s very responsive.

2. Ionic

One of the most popular and astonishing cross-platform app frameworks, which is AngularJS-based. Developers could combine several languages. Moreover, developers could build a flawlessly creative UI, along with adding features that are user-friendly.

Features

• Based on a SAAS UI framework, it’s especially designed for mobile OS. It provides several UI components for robust apps development.
• A front-end and open-source framework, which means that it enables code structure alterations, suitable to every developer and saves time.
• AngularJS-based offering HTML syntax extensions is easy.
• Provides a native-like feel to the app, making it a favorite among developers.
• Utilizes the plugins of Cordova, allowing access to built-in features of a device, such as camera, GPS, and audio recorder.

3. Xamarin

Is considerably different from the other frameworks discussed so far. It’s a simplified framework for the development of Windows, iOS, and Android, with the help of .Net and C#, rather than HTML and JS libraries. Developers are able to use 90 percent code to build an app for various platforms.

Features

• Apps are built using C#, a modern language with leverage over Java and Objective-C.
• Reduces cost and time of development since it supports WORA, or the write once, run anywhere, and with humongous class libraries collection.
• Has an astounding native UI and controls assisting, enabling developers to design a native-like application.

4. NodeJS

For developing cross-platform apps, this is a wonderful framework. Essentially, it’s a JavaScript runtime framework made on the JavaScript Chrome V8 engine. An open-source environment, it supports developer scalable and server-side networking apps. A NodeJS development company could develop highly effective solutions using the numerous rich libraries of JavaScript modules, which simplify web apps development.

Features

• Amazingly fast library in the process of executing code, because it’s built on the Chrome V8 engine.
• Apps don’t buffer, but instead it output data in chunks.
• Deliver perfect and smooth functioning apps. It makes use of a single-threaded model that has an event looping functionality.

5. NativeScript

A free, terrific cross-platform framework, which is based on JavaScript. It’s right to say that it’s the preferred option among developers looking for a WORA functionality. It moreover offers all native APIs in which developers could reuse existing plugins right from NPTM towards projects.

Features

• Renders accessible, beautiful, and platform-native User Interface. It only requires developers to define once and allow it to run everywhere.
• Gives developers a complete web resource, packed with plugins for all sorts of solutions. This inevitably eliminates third-party solutions.
• Provides the freedom of accessing native APIs seamlessly, meaning that developers need no further knowledge on native development languages.
• Uses TypeScript and Angular for the purposes of programming.

6. Electron

Electron, a wonderful framework for building desktop apps with all emerging technologies today, which include HTML, CSS, and JavaScript. The framework basically handles all the difficult aspects so you could concentrate on the core of the app and make a design that’s revolutionary. Designed as an open-source framework, Electron combines the best web technologies today and is also a cross-platform, which means that it’s very compatible with Windows, Mac, and Linux.

It has automatic updates, notifications, native menus, and debugging, crash reporting, and profiling as well.

Features

• Helps in developing feature-loader, high-quality, cross-platform desktop apps.
• Support for the Chromium engine
• It’s app structure and business logic.
• Secure access to storage.
• Hardware-level APIs of high-quality.
• Seamless management system.
• Support for different UI/UX tools.
• Compatible with the different libraries and frameworks.

7. Flutter

Flutter, an impressive cross-platform app framework was introduced by Google in 2017. It’s a software development kit that’s designed to help in iOS and Android app development.

Features

• Does not need to manually update the UI, since it has a reactive framework. Developers only have to update variables and changes in the UI becomes visible after.
• Poses as the perfect choice for the development of MVP, or Minimum Viable Product, since it initiates a fast development process and cost-efficient as well
• Promotes a portable GPU, rendering UI power, allowing it to function on the current interfaces.

8. Corona Software Development Kit

The framework lets programmers develop 2D mobile apps for all major platforms. Furthermore, it provides ten times faster mobile and game application development, delivering remarkable results. The focus of the framework is on the key elements of development, namely, portability, extensibility, speed, scalability, and usage ease.

Features

• Responds to changes made in code almost instantaneously, while providing a review of app performance in real-time, the same as on a real device.
• Provides developers the ability to sprite music, audio, animations, and so on with more than 100 APIs.
• Supports nearly 200 plugins, which include analytics, in-app advertising, hardware features, and media.

9. PhoneGap Framework

One of the cross-platform frameworks that’s flawless for mobile apps development using HTML5, JavaScript, and CSS. Furthermore, it has a cloud solution for developers with an option to share apps in the development process to derive feedback from other developers.

Features

• Considered a great cross-platform framework since it enables creating cross-platform apps with existing web technologies.
• Follows an architecture that by nature is plugin-able, which means that access to native device APIs is possible and could be extended modularly.
• It has support for the use of a single code base to build apps for various platforms.

10. Sencha Touch Framework

The framework is great for the development of cross-platform, web-based applications, which are typically used to create efficient apps with hardware acceleration methods. With Sencha Touch, developers could build securely integrated and well-tested UI libraries and components.

The features

• Known to provide themes that are built-in and native looking for all the major platforms.
• The Cordova support is one of its most celebrated features, for native API access, along with the packaging.
• Created with an agnostic backend data package that’s effective.
• Packed with customizable and over 50 built-in widgets.

Conclusion

The top ten frameworks mentioned here are just among the many frameworks you can choose from to develop cross-platform app frameworks. With the continuous evolution of technology and the constant updates, new frameworks would soon emerge. In the meantime, for all your cross-platform app development requirements, the ten that are mentioned here are among the best you can find available nowadays.