In this post, we’ll introduce Ionic 4, learn about its new features and finally show you how to install and use the Ionic CLI v4 to generate a new Ionic project based on Angular 7.

We’ll also introduce the new Ionic 4 ecosystem comprised of new tools like Stencil, Capacitor and modern browser technologies such as web components, shadow DOM and CSS variables.

Ionic 4 is the latest version of Ionic and the best Ionic yet! It’s a mobile UI library that embraces modern browser technologies but also the new Angular 7 tooling and features.

Ionic 4 lets you use your preferred JavaScript or TypeScript front-end library or framework such as Angular, Vue, Preact, React or jQuery to build mobile applications so you are no longer forced to use TypeScript and Angular.

While Ionic is now framework-agnostic, Ionic developers that still want to use Ionic with Angular will get support from the Ionic team with the ionic/angular package, just like Ionic 3 and the previous versions.

Now, let’s introduce the technologies behind the new Ionic.

Stencil

Stencil is an open-source tool created by the Ionic team to help them easily build the Ionic Core with standard compliant web components.

Stencil is a web components compiler which allows you to use framework-like constructs such as JSX templates, routing, data binding and TypeScript classes and decorators to easily build web components — but your final application is completely based on web components that run natively on modern browsers.

The new Ionic uses Stencil behind the curtain — which means you don’t need to use it when developing Ionic apps but you can use Stencil to author web components or create full Progressive Web Apps with or without the Ionic UI components.

Web Components

Web components are a series of standards defined by the W3C. They allow front-end developers to build components that are natively interpreted by modern web browsers.

Among the technologies related to web components are Custom Elements and Shadow DOM.

Custom Elements

Using Custom Elements, you can extend HTML and create new tags or reuse and extend the components authored by other developers. This native browser API is the base of web components. It provides a native way of creating reusable components using vanilla JavaScript with HTML and CSS.

Thanks to Custom Elements, we can re-use Ionic UI components in modern web browsers natively without any frameworks or run-times.

Shadow DOM

Shadow DOM is another native browser API that allows the encapsulation of DOM elements and CSS styles independently from the other code in an HTML document. It provides a way to attach a hidden DOM (called shadow root) to an element using the Element.attachShadow() method.

Using Shadow DOM helps to easily consume Ionic UI components from any web application by encapsulating the CSS styles.

CSS Variables/Custom Properties

Just like typical programming languages, where variables are used to hold typed values, they can similarly be used to store values in CSS such as colors, widths, heights and font properties, among others. Developers are now able to define CSS variables, then reference and reuse them throughout the document. They can also be accessed from JavaScript which can be further explored to add advanced features such as dynamic theming. Although most developers call them CSS variables, they are actually Custom Properties.

In Ionic, CSS Variables are the core of the components theming. Developers can easily modify the overall look and feel (or themes) of the application UI just by changing a few variables, without resorting to Sass and complex build tools.

Ionic Native

Ionic Native provides a TypeScript wrapper for Cordova plugins for easily adding native device (Android and iOS) functionalities into your Ionic mobile application. It’s basically a set of community maintained plugins.

Starting with version 5, Ionic Native is also framework independent. That means you can now use the wrappers outside of Angular. Check out the new Native API Docs.

Migrating to Ionic 4

You can migrate your existing Ionic 3 application to Ionic/Angular v4 by following the migration guide and use this official migration tool by Ionic which automatically detects most of the breaking changes and automatically fixes some issues.

Generating a New Ionic Project with The Ionic CLI

The Ionic Command Line Utility or CLI is the official and primary tool — provided by the Ionic team — to create and build mobile apps based on Ionic and Cordova (or also Capacitor).

You can use the Ionic CLI to generate a project based on many starters. It is also used for:

• serving apps locally;
• running apps in emulators or actual devices;
• building the final packages;
• generating various features such as pages;
• connecting to Ionic Pro services.

The Ionic CLI v4 comes with new features, such as experimental support for Capacitor — a new alternative to Cordova built by the Ionic team to create cross-platform apps for mobile (Android and iOS), desktop (thanks to Electron) and the web (as PWAs).

Installing The Ionic CLI v4

To generate Ionic/Angular v4 projects, you need to install the Ionic CLI v4. Before installing the CLI, make sure you have the following requirements:

• The latest version of Node.js and npm. You can run node --version to check if Node.js is installed. If not, simply head to the official website and grab the binaries for your system.
• If you want to target Android, you also need Java and Android SDK installed. You can download JDK 8 from the official website and Android Studio — which is used for downloading the Android SDK — from its official website. Also, make sure you configure environment variables such as ANDROID_SDK_ROOT.
• If you want to target iOS, you need to have a macOS with the Xcode IDE. You can download Xcode from the official website or through the Apple Store.

Now, you can install the Ionic CLI globally from npm using the following command:

npm install -g ionic

Depending on your npm configuration, you may need to use sudo on Linux/Mac or use an Administrator command prompt on Windows if you want to install packages globally.

Creating a New Project

After installing the Ionic CLI v4, you can create a new Ionic project using the ionic start command and specifying the name and a starter template such as:

• the blank starter: A blank project with one home page;
• the tabs starter: A simple project with tabs;
• or the sidemenu starter: A simple project with a side menu.

You also need to specify the type of framework to use with the --type=angular option, which is new in the Ionic CLI v4 (for now, the CLI supports only Angular).

Head over to your terminal and run the following command:

ionic start myApp blank --type=angular

The CLI will ask you if you want to integrate Cordova. Answer Yes if you want to target native iOS and Android or No if you just want to create a Progressive Web App with Ionic.

This is a screenshot of the directory structure:

Most work you’ll do will be inside the src/app/ folder, which contains the root app component and module and any other directories for pages and components.

Serving the Application

You can run and debug your Ionic application right in the browser using the ionic serve command. This is one of the benefits of hybrid mobile development — you don't need to use emulators or actual mobile devices until you need to test native device features (presuming you can't mock the feature in the browser).

Head back to your terminal, navigate inside your project and serve your application using:

cd myApp
ionic serve

Your application will be available from localhost:8100.

You can also use the ionic build command for building the final application. Check all the available commands from the docs.

Conclusion

In this post, we introduced the new Ionic 4 library and its new ecosystem, which comprises the tools and technologies behind the new powerful features. We also installed the Ionic CLI v4, created and served a new project based on Angular. Similarly, you should now be able to create a new Ionic 4 app and use the Ionic CLI v4.

If you’re building Ionic applications with sensitive logic, be sure to protect them against code theft, tampering, and reverse-engineering by following our guide.

Originally published on the Jscrambler Blog by Lamin Sanneh.

Introduction to Ionic 4 was originally published in hello JS on Medium, where people are continuing the conversation by highlighting and responding to this story.

JavaScript is now stronger than ever. The numbers say it all: JavaScript developers are the second most sought-after (going head to head with Java) and JS completely dominates GitHub in terms of pull requests.

Part of the reason behind JavaScript’s success is its active community. JS developers are masters in collaboration, not only in terms of pull requests but also by setting up meetups and conferences. With JS frameworks surging in popularity, they now have their own conferences across the globe.

As a JavaScript developer, you should really consider attending some of these conferences. In this article, we highlight 14 unmissable JavaScript Conferences in 2019, ordered by date.

EmberConf

This Ember.js conference is “a gathering of the uniquely ambitious”. The 3-day event brings to stage the Ember Core team, leading community contributors and the visionaries that keep shaping Ember’s horizon.

If the event is anything like the framework, expect it to be solid, well-mannered, and a place to get things done.

• March 18–20 | Portland, OR, USA
• Website | Twitter

VueConf US

Vue has been a GitHub rising star since 2017. Many have dubbed it the React-challenger and its community has grown into a thriving one. VueConf US goes beyond talks, challenging developers to present their projects in lightning talks and participate in workshops.

In case you’re building with Vue (or planning to), don’t miss the chance to hit Tampa and join in the fun.

• March 25–27 | Tampa, FL, USA
• Website | Twitter

ng-conf

“The world’s biggest Angular conference”, ng-conf quickly leads attendees from dev mode to full-on party mode. In 2018, the event’s opening keynote revealed new Angular features, and the after parties included a movie night and the famous ng-party.

ng-conf truly sets itself apart from other events by challenging attendees to engage with several “UnConference” activities, including an escape bus, ng-yoga, and countless quests.

• May 1–3 | Salt Lake City, UT, USA
• Website | Twitter

React Europe

Europe’s original React conference, React Europe brings together the most passionate people from the core team and the coolest people from the community.

With React still being the #1 choice for front-end JS frameworks, the event focuses on the horizon, bringing to discussion how futuristic tech will empower the new generation of web apps.

• May 23–24 | Paris, France
• Website | Twitter

JSConf

Rather than being a single conference, JSConf spans across different countries and dates. The most notable events include:

JSConf EU — brings the “labour-of-love” for the JS community with memorable speakers while providing visitors with several side “quests”. It also brings a scholarship program for individuals from underrepresented groups.

• June 1–2 | Berlin, Germany
• Website | Twitter

JSConf Asia — Southeast Asia’s largest web developer conference and the meeting place of tech giants, JS/CSS masters, and notable influencers. In 2018, it featured the likes of Jake Archibald, Una Kravets, and Tim Holman.

• June 14–16 | Singapore
• Website | Twitter

JSConf US — held in sunny Carlsbad, California, encourages attendees to venture outside their comfort zone. The event features a “choose your own adventure” program, which enables visitors to go surfing, golfing, and even riding a helicopter.

• August 11–15 | Carlsbad, CA, USA
• Website | Twitter

Chain React

React Native keeps growing as developers’ framework of choice for building cross-platform mobile apps. Chain React, promoted by Infinite Red, started in 2017 as a meeting place for React Native enthusiasts, but quickly grew in popularity.

In 2018, the event attracted 500 attendees and notable speakers, including Radek Pietruszewski, Kenza Iraki, and Brent Vatne. In 2019, the event is expected to keep growing, with more attendees, speakers, and vendors.

• July 11–12 | Portland, OR, USA
• Website | Twitter

JSCamp

A great excuse to visit sunny Barcelona during summertime, JSCamp is a JavaScript event built by developers for developers. The event begins with a day filled with workshops and activities, which is followed by the two-day single-track conference.

JSCamp is all about connecting with other developers and refreshing ideas — open source, JS frameworks, and much more.

• July 18–19 | Barcelona, Spain
• Website | Twitter

Node Summit

Node.js is pretty much everywhere. Enterprises, developers, decision-makers, and enthusiasts gather in San Francisco’s Node Summit to push the boundaries of the industry.

With more than 1000 attendees and 80 speakers, the conference goes on for two official days (plus a zero-day for early bird tickets). With trainings and multiple tracks, the event provides a great opportunity to evolve technical skills.

• July (TBA) | San Francisco, CA, USA
• Website | Twitter

BrazilJS Conf

The Brazillian JavaScript community is huge and has a major presence in online channels. BrazilJS packages all this enthusiasm into a single major event where the community comes together.

The conference has roots dating back to 2011 and has grown with the mission of bringing the highest quality content to Brazil. The 2012 edition hosted Brendan Eich, and the event has since brought several high-profile speakers, including Yehuda Katz and Guillermo Rauch.

• August (TBA) | Porto Alegre, Brazil
• Website | Twitter

AngularConnect

Europe’s largest Angular conference, AngularConnect does its name justice by marking the meeting place for Angular developers, industry players, and core members of Google’s Angular team.

Angular Connect is also a strong contributor to the Angular community, sponsoring several meetups. If you’re considering joining them in London in 2019, apart from all the networking and learning, expect a healthy dose of chilling and… dinosaurs.

• September 19–20 | London, UK
• Website | Twitter

ReactiveConf

At the heart of Europe, in the city of 100 spires, functional programming gets Reactive in a three-day long festival where innovation is the keyword.

The event’s unique format consists of 2 conference days across 2 stages and a festival day. The conference will host over 60 speakers, which will deal not only with React, but with all cutting-edge mobile and web tech stacks. There will be plenty of time to explore Prague and join parties.

• October (TBA) | Prague, Czech Republic
• Website | Twitter

JSFoo

JavaScript is hugely popular in India, and its community thrives both digital and offline. JSFoo has been around since 2011 and has grown into a cornerstone of the Indian JS community. Besides the Bangalore event, HasGeek (the organizing community) has expanded JSFoo to Pune in January and organizes ReactFoo in March.

The event usually goes on for two days filled with talks that cover both the front-end and back-end ecosystems and also feature case studies of Vue.js, GraphQL, ReasonML and others.

• October (TBA) | Bangalore, India
• Website | Twitter

NodeConf EU

Europe gets its largest Node.js event in Ireland. Mostly attended by developers and engineers, the conference is a must-attend due to its abundance of quality speakers, workshops and friendly atmosphere.

NodeConf EU is all about the community. Chances are you will surely meet in person some legendary members of the JavaScript development scene.

• November 10–13 | Kilkenny, Ireland
• Website | Twitter

dotJS

The dot conferences movement spans several topics — security, AI, CSS, and JS. This unique conference format seeks to be TED-like in its quality and delivery. All talks are highly curated, with past speakers the likes of John Papa, Anders Hejlsberg, and Lauren Tan.

dotJS also brings training for emerging technologies such as Vue.js and GraphQL, seeking to inspire JavaScript developers to keep innovating.

• November (TBA) | Paris, France
• Website | Twitter

With dozens (possibly even hundreds) of JavaScript events sprouting all over the globe, the future of JavaScript looks brighter than ever. All of the events we feature on this list have great feedback from the community, so definitely consider attending some in 2019!

If you’re looking to improve your own JavaScript skills, be sure to check out our multiple tutorials on React, Angular, Vue, Node.js, Mobile Development and other web resources.

Also, if you’re building apps with important logic or intellectual property, learn how you can protect them against code theft and reverse-engineering.

Originally published at blog.jscrambler.com.

14 JavaScript Conferences in 2019 Every Developer Should Attend was originally published in hello JS on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are quite a few reasons to use cross-platform or hybrid frameworks. For starters, it’s easier to maintain a single code base. Also, existing developer skills can be leveraged to develop apps. Quite a few hybrid frameworks are available for developers. The majority of those are based on Apache Cordova or WebView-based. Then there is C# based Xamarin which is a cross-compiled framework. NativeScript is one such platform.

NativeScript is developed and maintained by Progress Telerik. It is a JIT compiled framework and its code runs inside a JS Virtual Machine, which is bundled together with the application. It uses v8 runtime for Android and JavaScriptCore for iOS. As a reference, React Native uses JavaScriptCore on both Android and iOS platforms. If you’re interested in a comparison between NativeScript, React Native and Ionic, see our practical guide.

NativeScript uses a combination of XML, JS and CSS for development. Official Support for Angular and TypeScript is also available. At the time of writing, community support for Vue is available.

It currently supports the following stacks:

• JavaScript
• TypeScript
• Angular
• Vue

Details regarding the starter templates for each stack can be viewed here. For the purposes of this tutorial, we will consider the Angular stack from this point forward.

NativeScript 5.0

Recently, NativeScript 5.0 was released by Progress Telerik. Improvements in this version are more relevant to tooling and developer experience. Features in this version are listed below:

• Hot Module Replacement (HMR).
• Interactive tns create command.
• Safe Area support in iOS.
• Create plugins with tns plugin create
• Support for different app IDs for iOS and Android.
• Vue.js support for all NativeScript UI components.
• (breaking-change) Migration to support Android library APIs v28.
• (breaking-change) Dropped support for X-Code 8 & iOS 10.12 Sierra.

Tooling

This the area where NativeScript shines. NativeScript has an outstanding tooling support.

You can work with NativeScript in 2 ways.

On a Local machine

• Install CLI / GUI Tool
• Setup Work Environment (Android/iOS works).
• Fire your favorite IDE (NativeScript has good support for Visual Studio code).
• Code — Debug — Test on Live Device/Emulator.

We can install NativeScript using the following command

npm install -g nativescript

The CLI can perform the following tasks:

• Create project from templates (tns install)
• Run project on devices (tns run)
• Debug applications (tns debug)
• Manage Platforms (tns platform)
• Manage Plugins (tns plugin)
• Check work environment (tns doctor)
• Setup work environment (tns setup)
• Support for ChromeDev Tools & Safari Inspect

You can also use NativeScript Sidekick to manage projects. Sidekick is an Electron app which provides a GUI interface for the NativeScript CLI. As with most Electron Apps, memory consumption is an issue. It is recommended to have at least 8 GB of RAM.

Using a WebIDE

Alternatively, NativeScript has a WebIDE known as NativeScript PlayGround. On this site, you can:

• Create Apps from Templates.
• Drag and Drop Interface for UI Components.
• Generate Wrapper Code for UI components.
• Open App in local Devices Akin to Expo(React Native) and Ionic View.
• Hot Reload & debug on Devices.
• Manage Projects.

This is very handy if you want to give NativeScript a test run. To test the project, download the Playground Apps for Android and iOS and scan the QR codes.

Project Structure

To create a project from a template directly, use the create command with --template param:

tns create SampleProject --template tns-template-blank-ng

This will create a project named SampleProject based on the blank angular template. For a complete list of arguments, use:

tns help create

Interactive Project Creation

NativeScript 5.0 allows you to create projects interactively. Invoke tns create without any Params.

tns create

The interactive project creation is straightforward. In the first step, set your app’s name (we will name it “Sample Project”); then, choose a stack (we will choose “Angular”); finally, pick a template (in our case, “Hello World”). This will generate our project folder.

This is the standard project structure of a NativeScript App.

├── angular.json
├── App_Resources
├── CODE_OF_CONDUCT.md
├── hooks
├── LICENSE
├── node_modules
├── nsconfig.json
├── package.json
├── package-lock.json
├── platforms
├── README.md
├── src
├── tsconfig.json
├── tsconfig.tns.json
└── webpack.config.js

The package.json file has a key known as "id". This is your Application Identifier or Package Name. To publish your app to the Play Store or iTunes, you are required to have a unique id.

"id": "org.nativescript.SampleProject",

With NativeScript 5, individual App IDs can now be specified as below.

"id": {
            "ios": "org.nativescript.SampleProjectIOS",
            "android": "org.nativescript.SampleProjectAndroid"
        }

The source code of the application is in the src folder:

├── app
│   ├── app.component.html
│   ├── app.component.ts 
│   ├── app.module.ts
│   ├── app-routing.module.ts
│   └── home
│       ├── home.component.html   
│       ├── home.component.ts
│       ├── home.module.ts 
│       └── home-routing.module.ts
├── app.css
├── main.ts
└── package.json

Depending on the templates, you will have TypeScript files, JavaScript Files, XML files and CSS/SASS files.

Run the app on an Android device using the command

tns run android

This will initialize the app in an Android device.

UI: Layouts and Styling

Layouts

As mentioned before, NativeScript uses XML as a layout template. The child components/widgets are arranged in Layout containers. By default, 6 Layouts are available:

• StackLayout: Elements are stacked horizontally and vertically.
• GridLayout: A rectangular grid with rows and columns.
• AbsoluteLayout: You can set the location of child elements exactly in this layout.
• FlexLayout: This is based on CSS Flex Layout. However, it is non-conforming.
• DockLayout: Elements in dock layout are positioned on edges. The last element takes up remaining space.
• WrapLayout: Elements in WrapLayout are arranged in a grid of rows and columns. If space runs out, the remaining elements are placed in the next row/column depending on orientation.

You can read more about layouts in the documentation.

Styling

NativeScript elements are styled using CSS. However, the properties which can be styled are limited. Here is the complete list of properties which can be styled.

CSS properties can be declared

• Application-wide
• Inline on elements
• Page Specific CSS

Interacting with the Backend

Currently, the Angular template of NativeScript comes with Angular 6.1. We can use HttpClientModule to interact with a web service.

Altrnatively, we can also use fetch or tns-http to interact with web services.

Debugging

Web Browser Inspect

We can debug the application using Chrome Inspect (For Android) and Safari Inspect (for iOS). To run the application in debug mode on Android, use the command

tns debug android

A URL will be generated in the terminal window. This URL will provide you with a console and debugger.

Hot Module Replacement

Webpack’s hot module replacement was introduced in NativeScript version 5.0. Previously, changes would be reflected in the device/emulator with an app reload. With hmr the changes are updated live without app reload, i.e. they are reflected instantly.

Currently, the feature is beta and requires the nativescript-dev-webpack dependency to work. This reduces development time drastically.

To use hmr, you will have to update the CLI to version 5.0 and install nativescript-dev-webpack in the project folder (if not present). Additionally, Angular projects require additional steps as outlined here.

npm i nativescript-dev-webpack --save

After installation, use the flag --hmr with tns run command to start the app on a device/emulator.

tns run android --hmr

tns run ios --hmr

tns Preview

Preview mode was introduced in version 5.0. tns preview bundles the app and generates a QR code like NativeScript PlayGround. You scan the QR code and load app via NativeScript Playground App. This is very handy if your development machine is non-macOS and you want to test the App in an iPhone. As with playground, plugin support is limited in preview mode.

tns preview

Extending the project with plugins

The default project template has limited features and functionality. We can extend the functionality using NativeScript Plugins. The NativeScript MarketPlace provides you with a list of published plugins. An individual plugin page has information about:

• Platform (Android / iOS / Both)
• NativeScript Version (2 / 3 / 4 / 5)
• Webpack Support
• Demo App in Plugin Page
• TypeScript Support
• License Information
• Travis CI Support

Verified plugins have support for the latest Android & iOS versions, support for latest NativeScript platforms, Weekly Travis CI Builds, support for all NativeScript templates and demo apps in the plugin repository.

Plugins can be managed using Sidekick. However, they are not available in the Playground. Some common plugins are listed below.

Plugins can be installed using the following command.

tns plugin add plugin_name

Since NativeScript plugins are available in the npm repository, you can also use

npm i plugin_name --save

Conclusion

This was a brief overview of the framework. We would suggest you to take NativeScript for a spin using Playground.

If you encounter any issues getting started with NativeScript, be sure to refer to the official documentation or join their Slack community.

Originally published at blog.jscrambler.com by Karan Gandhi.

Introduction to NativeScript was originally published in hello JS on Medium, where people are continuing the conversation by highlighting and responding to this story.

JavaScript is characterized as a dynamic and weakly typed programming language. The ability to manipulate DOM elements in a dynamic way is empowering to the developer. At the onset, it seems like dynamic typing frees the developer from extraneous code. To some, adding a stricter type system becomes an impediment to developers’ productivity.

In the early web, JavaScript was scarce. The demand for rich user interaction didn’t make sense for static web pages. JavaScript’s footprint was often dwarfed by CSS and images. In more recent years, this demand for rich client-side interfaces has exponentiated. It is safe to assume JavaScript is the programming language of the web.

But, as code bases grow, and more contributors add to its complexity, can a type system start to make sense? As bugs and complexity increases, code quality becomes the focus on how fast a team can deliver.

What Is A Type System?

In JavaScript, a type system adds type safety checks to a program. This can happen at compile time or during the execution of the code. Given the dynamic nature of JavaScript, you can assign a string to a variable then use this same variable like a number. A type system will flag these programming mishaps and let you know of a possible error.

A type system can look like a data contract. The programmer specifies what a variable is for. This enables code readers to know what the original author intends. Imagine a type system as a formal contract and an effective way to communicate program specs.

A type system is much like a mini unit test. The type checking system lets the programmer know whether the test passes or fails. This frees the original author from having to specify type intent in an actual unit test.

You can use a type system to automate type safety checks. This becomes your first line of defense towards thwarting bugs in the code.

Why Does It Matter?

Dynamic or duck typing is great for prototypes and quick proof of concepts. Prototype code increases the productivity of a single developer. When a prototype comes from a small team, the velocity is high, because communication is much easier. Once this makes it to production, however, it can grow into a maintenance nightmare. There is a point where bugs can bring any software project down to a crawl.

There is value in defining a specific type to a variable and having a system that validates types. Any programmer unfamiliar with the program can read and understand type definitions. The type system is the data contract to communicate program specifications to newcomers. As more contributors add to the program, data types form a way to validate assumptions.

Type systems build the architecture necessary to communicate intent and clean design. Beauty is in code built around strict data models that meet business requirements.

Think of a type system as a safety net and a communication tool. Having explicit types with validation adds accountability to a team of programmers. When type checking is part of the build, it shields the code base from many bugs.

Empirical evidence suggests a 15% bug reduction by adding a type system. So, when facing a large enterprise-grade JavaScript project, it is a good idea have one — as it is an effective way to increase code quality and deliver faster.

Type Safety Checks

Time for the code. Let’s demonstrate a type system using React PropTypes without React. To illustrate the issue, I’ll fabricate a bug that can happen to anyone. Say we have a component for adding two numbers. Due to changes to the team, the original intent of the component gets forgotten. Dynamic typing can build tribal knowledge around data contracts which turn into a myth.

For example:

const props = {
  x: 1,
  y: '1'
};

function addNumbersComponent(props) {
  return props.x + props.y;
}

addNumbersComponent(props);

JavaScript allows this behavior and even gives you a return value too. It may not be what you expect but it does work without throwing any errors. There is permissiveness here that should make programmers pine for basic type checking.

To quell this behavior, one can do:

const propTypes = {
  x: PropTypes.number,
  y: PropTypes.number
};

PropTypes.checkPropTypes(propTypes, props, 'props', 'addNumbersComponent');

PropTypes build a line of defense against type mishaps and gives you feedback. Having basic type checking warns you when there is a programmatic error. One idea is to fail the build when these warnings crop up in your JavaScript code.

This is the message you see when there is a warning with a type:

There is value in this feedback because it automates type checking. In programming, the job is often to automate as much as possible and this includes type checking. The feedback loop can be shorter when type checking is part of the build. Note that this warning does not show up in a production build. Consider adding type checking as part of the unit tests to fail the build.

Feel free to play around with the sample code, it is out on CodePen.

Conclusion

A type system can be your first line of defense against bugs in production. Dynamic typing is good for prototypes with small teams but can fall short in enterprise-grade software. Large projects with poor coding architecture are at risk when documentation is lacking. A type system reduces risk, is a communication tool, and enhances the architecture.

As JavaScript code bases grow both in size and complexity, there is value in type checking. A good type system builds on top of JavaScript native types and does basic type checking.

Consider adding type checking as part of a build to shorten the feedback loop. The less time it takes to get feedback, the faster you can thwart bugs.

Originally published at blog.jscrambler.com.

Type System in JavaScript: What It Is and Why It Matters was originally published in hello JS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Vue-form-wizard is a dynamic wizard with a simple interface for splitting forms without external dependencies, which makes it easier to manage tab wizards for larger forms & processes. The vue-form-wizard provides you with built-in functions by just setting up the dependency which helps build quizzes, Q&As, multiple page forms, and more!

So, how can you start using vue-form-wizard on your next project? Here’s how:

How to Install Vue-form-wizard:

1. Install vue-form-wizard:
   Vue-form-wizard can be installed by using the command:

npm install vue-form-wizard

1. Import the package in your current project:
   Import the package in your current project to include and fetch its style we need to add the following:

//global registration
import VueFormWizard from ‘vue-form-wizard’

Vue.use(VueFormWizard)

1. Include Styles
   Don’t forget to include the styles. You can customize them according to your requirements.

import ‘vue-form-wizard/dist/vue-form-wizard.min.css’

1. Add Tags in Your Template
   Finally, to see the basic form wizard in action, put a <form-wizard> tag in your template at the required section in your app and include <tab-content> tag on the number of slides you need on your wizard.

<form-wizard>

<tab-content title=”tab1">

First tab

</tab-content>

<tab-content title=”tab2">

Second tab

</tab-content>

<tab-content title=tab3">

Last tab

</tab-content>

</form-wizard>

The above code will display a basic form wizard with three steps “tab1”, “tab2” & “tab3” with its default settings. This form wizard component comes with a set of different options. You can customize those according to your needs like

<form-wizard shape=”square”>

<form-wizard shape=”tab”>

If the number of slides are dynamic, you can loop through the tab-content tag.

<tab-content

v-for=”(slide, index) in slide_data”

:title=”slide.title”

:key=”slide.id”

:before-change=”validateBeforeSubmit”>

</tab-content>

Note: “slide_data” is the object that you need to loop through for fetching the slides.

Useful Form-level Props in vue-form-wizard

Similar to props at the component level in vue.js, form-wizard offers some built-in props at the form level and the tab level.

Title: accepts a string value

StartIndex: This allows you to customize the form-wizard and change the start index. In other words, the form-wizard doesn’t always have a start index of 0. This can be helpful when integrating with multiple form-wizards without a break.

Shape: This allows you to custom the shape of the form.

Color: This allows to use a custom color for the tab and its buttons in the wizard.

Title: requires a string to provide a title for an individual tab

before-change: one of the most useful props for a tab is the before-change function. This function is defined at per tab-content level and can be used to validate a specific tab. It is triggered before moving to the next tab.
Example:

<tab-content :before-change=”validateTab” ></tab-content>

validateTab:function(){

alert(‘triggered before jumping to next tab’)

}

This function needs to be returned true to proceed to the next tab. If it does not return anything, its defaults to false and the tab is not changed. In such a situation, to force change the tab, you can use changeTab (oldIndex, newIndex).

Example: this.$refs.wizard.changeTab(0, 3)

Useful functions provided by vue-form-wizard:

on-change: This function is at a form-wizard level. It is triggered at on change of every tab and returns parameters: prev-tab, next-tab.

Example:

if (prevtab > nexttab) { alert(‘going backward’)}

If(nexttab> prevtab){alert(‘going forward’)}

on-loading: This event triggers before and after before-change props is triggered. Although it does not return any value, any action can be added in this event.

on-validate: This function is triggered after before-change, but also returns a boolean value of the validation and the tab index.

on-error: This event works along with async validation and if Promise function is used. If the promise is rejected the on-error event will return the error message, else it will not be triggered.

on-complete: This function is at a form-wizard level. It is triggered when on the last tab the next/finish button is hit to trigger the last action needed after the wizard is completed. Additional vue-form-wizard Functions

Async validation: This feature can be paired with the tab level before-change. Async allows the validation to respond to a callback function like a response from an API call to check the validity of the tab moving forward. Here is an example of async validation

Element UI integration: Using the UI integration lets you use the built-in styling and form structure. Reusing the components let you build a complete application faster.

Therefore, Vue.js form-wizard covers all the action or function which one might require while building an application.

Using Vue.js form-wizard was originally published in hello JS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Now, as an accomplished programmer (*cough* hubris *cough*), I think it’s time to improve further. I’ve search for a loooooooong time. And after a week of thinking (*cough* impatience *cough*) I’ve decided to talk to you about the fourth virtue of the programmer.

The fourth virtue that’ll make you a more productive programmer is consistency.

Let me show you in this article how to apply consistency for your profit easily (*cough* laziness *cough*).

Find your rhythm and stick to it

Your mileage may vary, but for most people, being consistent in the time you allocate to a project/task will boost your productivity.

Don’t take my word for it, but make an experience:

• Code one day a week on a project for one month.
• Code 1h a day for one month on another project.

On which one will you be the most productive ?

Even if some tasks are hard to do in one hour, I bet a consistent work will boost your enthusiasm, ease your work and in the end make you more efficient.

Of course you probably work on several project at a time, and external factors might break your chosen rhythm. But as long as you try to be regular in your work you should see improvements.

Find your style and stick to it

Consistency in the way you write your code is a well known quality metric: It improves readability, ease the maintenance/evolution and reduce the probability of bugs.

If choosing the coding style was easy when I was coding in Perl (Larry Wall then Damien Conway paved the way) it can be much difficult depending on your language of choice: The choice is not the same for a JavaScript/PHP programmer or a Python/Go programmer.

But whatever the abundance of choice or not, it doesn’t really matter what style you pick as long as you pick one coding style.

And once you’re picked one, ensure you enforce it in your usual editor.
(It’s just a matter of few lines in my vim config file to have the airbnb style enforced on all my javascript files or gofmt run on my Go file)

Ensure you have consistent goal and consistent results

Use tests!

Let’s say the truth: Testing is our dark little secret, we wish we’d do it more, but in dark repositories that we don’t make public there are stills many places where a test directory is missing.

However we all know that the tests is the minimal architectural work we have to do: How can we achieve our goals if we don’t define them ?

We all know that tests are the required safety net to refactor our code with confidence.

So stop beating about the bush, choose your framework and use it in all of your projects.

Be consistent in your process

We all have some habits/tricks that make us more efficient. As soon as you’ve found one, use it consistently.

For example, I try to drop a LAB_BOOK.txt file in my working directories, to store tips/hints related to the current project: It can be as simple as basic commands to start/stop services, or command line examples of some unusual tools or data/steps to test/improve my code. It might seem useless, but those files prevent me from wasting precious time when I get back to a project after a long halt. Being consistent in the use and the naming of this file is what prevent me from wasting time.

I also try to store whenever possible all the private data (login/pass/ports…) in a separate file named the same way across my repos to have it protected from unwanted disclosure (thanks to specifically modified .gitignore).

We all have coding habits: whatever the way you work with your SCM, name your file, organize your repositories, document your project, try to be consistent; it will save you time and fatigue.

I was not a big fan of generators until lately where I realized how yeoman could be used to enforce most of the above mentioned good practices.

I’m still working on it, but having default layouts for my project is definitely a good way to boost productivity by reducing the initial friction and improving overall quality.

Be consistent in applying what you’ve decided

Once you’ve found a good practice: automate it!

Your tool will never forget, will never be lazy, will never make an hazardous change and will never forgive :)

Your SCM hooks can be handy to autoupdate the Changefile or do some testing.

Common operations on files (conversion, generation) should be scripted.

In fact if you’ve done the same simple task more than 2 times, you probably should script it.

Conclusion

I hope this rant will give you ideas to improve your coding habits. As usual I’d be glad to have your feedback/comment/suggestion on the topic. Don’t hesitate to leave a comment or contact me by mail (arhuman (at) gmail dot com)

The fourth virtue of the programmer was originally published in hello JS on Medium, where people are continuing the conversation by highlighting and responding to this story.

CSS was designed for documents, what the “old web” was expected to contain. The emergence of preprocessors like Sass or Less shows that the community needs more than what CSS offers. With web apps getting more and more complex over time, CSS’ limitations have become increasingly visible and difficult to mitigate.

Styled-components leverages the power of a complete programming language — JavaScript — and its scoping capabilities to help structure the code into components. This helps to avoid the common pitfalls of writing and maintaining CSS for large projects. A developer can describe a component’s style with no risk of side effects.

What’s the Problem?

One advantage of using CSS is that the style is completely decoupled from the code. This means that developers and designers can work in parallel without interfering with each other.

On the other hand, styled-components makes it easier to fall in the trap of strongly coupling style and logic. Max Stoiber explains how to avoid this. While the idea of separating logic and presentation is definitely not new, one might be tempted to take shortcuts when developing React components. For example, it’s easy to create a component for a validation button that handles the click action as well as the button’s style. It takes a bit more effort to split it in two components.

The Container/Presentational Architecture

This is a pretty simple principle. Components either define how things look, or they manage data and logic. A very important aspect of presentation components is that they should never have any dependencies. They receive props and render DOM (or children) accordingly. Containers, on the other hand, know about the data architecture (state, redux, flux, etc.) but should never be responsible for display. Dan Abramov’s article is a very good and detailed explanation of this architecture.

Remembering SMACSS

Although the Scalable and Modular Architecture for CSS is a style guide for organizing CSS, the basic concept is one that is followed, for the most part automatically, by styled-components. The idea is to separate CSS into five categories:

• Base contains all the general rules.
• Layout’s purpose it to define the structural properties as well as various sections of content (header, footer, sidebar, content, for instance).
• Module contains subcategories for the various logical blocks of the UI.
• State defines modifier classes to indicate elements’ states, e.g. field in error, disabled button.
• Theme contains color, font, and other cosmetic aspects that may be modifiable or dependent on user preference.

Keeping this separation while using styled-components is easy. Projects usually include some kind of CSS normalization or reset. This typically falls in the Base category. You may also define general font sizing, line sizing, etc. This can be done through normal CSS (or Sass/Less), or through the injectGlobal function provided by styled-components.

For Layout rules, if you use a UI framework, then it will probably define container classes, or a grid system. You can easily use those classes in conjunction with your own rules in the layout components you write.

Module is automatically followed by the architecture of styled-components, since the styles are attached to components directly, rather than described in external files. Basically, each styled component that you write will be its own module. You can write your styling code without worrying about side effects.

State will be rules you define within your components as variable rules. You simply define a function to interpolate values of your CSS attributes. If using a UI framework, you might have useful classes to add to your components as well. You will probably also have CSS pseudo-selector rules (hover, focus, etc.)

The Theme can simply be interpolated within your components. It is a good idea to define your theme as a set of variables to be used throughout your application. You can even derive colors programmatically (using a library, or manually), for instance to handle contrasts and highlights. Remember that you have the full power of a programming language at your disposal!

Bring Them Together for a Solution

It is important to keep them together, for an easier navigation experience; We don’t want to organize them by type (presentation vs. logic) but rather by functionality.

Thus, we will have a folder for all the generic components (buttons and such). The others should be organized depending on the project and its functionalities. For instance, if we have user management features, we should group all the components specific to that feature.

To apply styled-components’ container/presentation architecture to a SMACSS approach, we need an extra type of component: structural. We end up with three kinds of components; styled, structural, and container. Since styled-components decorates a tag (or component), we need this third type of component to structure the DOM. In some cases, it might be possible to allow a container component to handle the structure of sub-components, but when the DOM structure becomes complex and is required for visual purposes, it’s best to separate them. A good example is a table, where the DOM typically gets quite verbose.

Example Project

Let’s build a small app that displays recipes to illustrate these principles. We can start building a Recipes component. The parent component will be a controller. It will handle the state — in this case, the list of recipes. It will also call an API function to fetch the data.

class Recipes extends Component{
  constructor (props) {
    super(props);
    this.state = {
      recipes: []
    };
  }

  componentDidMount () {
    this.loadData()
  }

  loadData () {
    getRecipes().then(recipes => {
      this.setState({recipes})
    })
  }

  render() {
    let {recipes} = this.state

    return (
      <RecipesContainer recipes={recipes} />
    )
  }
}

It will render the list of recipes, but it does not (and should not) need to know how. So we render another component that gets the list of recipes and outputs DOM:

class RecipesContainer extends Component{
  render() {
    let {recipes} = this.props

    return (
      <TilesContainer>
        {recipes.map(recipe => (<Recipe key={recipe.id} {...recipe}/>))}
      </TilesContainer>
    )
  }
}

Here, actually, we want to make a tile grid. It may be a good idea to make the actual tile layout a generic component. So if we extract that, we get a new component that looks like this:

class TilesContainer extends Component {
  render () {
    let {children} = this.props

    return (
      <Tiles>
        {
          React.Children.map(children, (child, i) => (
            <Tile key={i}>
              {child}
            </Tile>
          ))
        }
      </Tiles>
    )
  }
}

TilesStyles.js:

export const Tiles = styled.div`
  padding: 20px 10px;
  display: flex;
  flex-direction: row;
  flex-wrap: wrap;
`

export const Tile = styled.div`
  flex: 1 1 auto;
  ...
  display: flex;

  & > div {
    flex: 1 0 auto;
  }
`

Notice that this component is purely presentational. It defines its style and wraps whatever children it receives inside another styled DOM element that defines what tiles look like. It’s a good example of what your generic presentational components will look like architecturally.

Then, we need to define what a recipe looks like. We need a container component to describe the relatively complex DOM as well as define the style when necessary. We end up with this:

class RecipeContainer extends Component {
  onChangeServings (e) {
    let {changeServings} = this.props
    changeServings(e.target.value)
  }

  render () {
    let {title, ingredients, instructions, time, servings} = this.props

    return (
      <Recipe>
        <Title>{title}</Title>
        <div>{time}</div>
        <div>Serving
          <input type="number" min="1" max="1000" value={servings} onChange={this.onChangeServings.bind(this)}/>
        </div>
        <Ingredients>
          {ingredients.map((ingredient, i) => (
            <Ingredient key={i} servings={servings}>
              <span className="name">{ingredient.name}</span>
              <span className="quantity">{ingredient.quantity * servings} {ingredient.unit}</span>
            </Ingredient>
          ))}
        </Ingredients>
        <div>
          {instructions.map((instruction, i) => (<p key={i}>{instruction}</p>))}
        </div>
      </Recipe>
    )
  }
}

Notice here that the container does some DOM generation, but it’s the only logic it contains. Remember that you can define nested styles, so you don’t need to make a styled element for each tag that requires styling. It’s what we do here for the name and quantity of the ingredient item. Of course, we could split it further and create a new component for an ingredient. That is up to you — depending on the project complexity — to determine the granularity. In this case, it is just a styled component defined along with the rest in the RecipeStyles file:

export const Recipe = styled.div`
  background-color: ${theme('colors.background-highlight')};
`;

export const Title = styled.div`
  font-weight: bold;
`

export const Ingredients = styled.ul`
  margin: 5px 0;
`

export const Ingredient = styled.li`
  & .name {
    ...
  }

  & .quantity {
    ...
  }
`

For the purpose of this exercise, I have used the ThemeProvider. It injects the theme in the props of styled components. You can simply use it as color: ${props => props.theme.core_color}, I am just using a small wrapper to protect from missing attributes in the theme:

const theme = (key) => (prop) => _.get(prop.theme, key) || console.warn('missing key', key)

You can also define your own constants in a module and use those instead. For example: color: ${styleConstants.core_color}

Pros

A perk of using styled-components is that you can use it as little as you want. You can use your favorite UI framework and add styled-components on top of it. This also means that you can easily migrate an existing project component by component. You can choose to style most of the layout with standard CSS and only use styled-components for reusable components.

Cons

Designers/style integrators will need to learn very basic JavaScript to handle variables and use them in place of Sass/Less.

They will also have to learn to navigate the project structure, although I would argue that finding the styles for a component in that component’s folder is easier than having to find the right CSS/Sass/Less file that contains the rule you need to modify.

They will also need to change their tools a bit if they want syntax highlighting, linting, etc. A good place to start is with this Atom plugin and this babel plugin.

Styled-Components: CSS-in-JS Library for the Modern Web was originally published in hello JS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Vue.js is a great framework for developing different kinds of web applications, however, it has a problem with SEO: the asynchronous content of an application can’t be optimally crawled by search engine bots, so it could be a huge problem for your business. In this article, we will tell you about one of the easiest ways to resolve this problem and, at the same time, to improve the UX of your application. Yes, we will talk about prerendering.

Prerendering is a process to preload all elements on the page and generate the static HTML of your Single Page Application.

Advantages of prerendering

The usage of prerendering has the following benefits:

1. SEO. Yes, finally, we can solve the problem of SEO for sites with asynchronous data: all such data will be preloaded before the crawler will index your site.
2. Speeding up page content loading. The user can get an access to your application even before the entire JavaScript loads which significantly improves the UX of your application. No one likes to wait a long time.
3. Cheap graceful degradation. This point follows the previous one. Now even users of old browsers or users with a disabled JS or a slow device have the access to your application. Of course, they are not able to fully interact with it but they can access important information instead of seeing an empty page.
4. Rich Previews. All unique OpenGraph metadata are prefetched correctly now. Share your site on the Facebook and other socials, to expand target audience.

The official Vue documentation proposes to use the prerender-spa-plugin for prerendering. In common, the plugin does the following steps:

1. It creates an instance of Phantom JS and runs the application.
2. Takes a snapshot of the DOM.
3. Outputs the snapshot to an HTML file in our build folder.

All right, let’s see how it works in practice.

Practice: prerendering in a Vue.js application

For demonstration, I will use the application which was created in our previous article about a single page Vue application. Get familiar with the project and start with building a simple SPA following the guide in the article, or, if you want to continue right now, just clone the repo and jump to the step 4 in that guide:

Now install the plugin:

After that, we need to configure the plugin for the correct work. Let’s go to webpack.conf.js and add the following settings:

Here we specify a directory from which we want to get a page for prerendering. In our case, this is the root directory. Also, we should add a list of routes which we want to prerender. For demonstration purposes, I will take just first four posts.

We should also take into account that we get data asynchronously, so if we carry on building the app following this approach, we’ll get a generated HTML with no content. To address this issue, the plugin offers three next options (check the documentation for more info):

That’s all, folks! Now if we build the application, we get a prerendered HTML. If you want to manage metadata, you can use one of the available plugins for Vue, for example, vue-meta. For instance, let’s add a unique title for each page. We need to install the plugin for this.

Add it to main.js

And insert the following into src/components/Post.vue

It’s enough to make the content of the application indexed and also available for users with a disabled JavaScript. Now search engines and social networks can read meta-information of our site. Also, we succeeded to reduce the load time to the FMP (first meaningful paint), the browser doesn’t wait for the full load of JavaScript but starts rendering our page as soon as HTML is loaded. As a result, a user can start receiving information from our site earlier.

When you don’t need prerendering

Using the simple plugin prerender-spa-plugin on a build step you can easily improve search engine optimization and create the better user experience of your Vue application. Unfortunately, there are few cases when using prerendering is inappropriate.

1. User-specific content: some page’s content, e.g. user profile page content, should be shown only for a specific user. On the build step, we don’t know who exactly will open this page, so we can’t prerender it. Anyway, if we did it, we would open user’s private information to everybody.
2. Frequently changing content: if you work on something like a chat or some online trading application or real-time game where content must be always relevant, usage of prerendering might be ineffective as it displays an old content until a client-side JS takes over with the latest data. As a potential solution, you could set your build to re-prerender every time as data changes, or often enough to be sure that content is relevant. But it might be very resource-consuming for the server. For the data that is updated even more frequently than every minute, you should avoid prerendering.
3. A large number of routes: it is not a good idea to prerender thousands of routes as this will take a lot of time to build your application.

In these cases, the best way is to use server-side rendering which you will be told about in the future article.

Useful links

The official Vue documentation
The Prerender SPA Plugin documentation

Originally posted at the ADCI Solutions website.

The autor is Dmitry Chuchin, Front-end Developer at ADCI Solutions

Dmitry demonstrates an astonishing ability to learn new technologies. Moreover, he strives to share his experience by teaching novice developers and delivering sessions at educational events. Also, he loves snowboarding and mountain biking.

Follow us on social networks: Twitter | Facebook | LinkedIn

Top 5 modules by the ADCI Solutions team

The easiest way to improve your Vue.js application. Part 1 was originally published in hello JS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Is it possible to create an operating system using only Node.js?

What is the big deal?

First of all, think about the progress Node.js has made in the short time it’s been around. Now, think about the same thing happening with an operating system. Then, let’s add some cool stuff to it.

Per-user independent and isolated root filesystem

NodeOS introduced an interesting paradigm: If all users have an isolated filesystem, it gives them a simple filesystem hierarchy to work with. Since their “home folder” is, in fact, the root of their own filesystem hierarchy, they can install packages globally without requiring special permissions and not need to configure anything since they are installed in their home directory by default. Also, it provides a good deal of security; if a hacker finds a way to get inside a particular account in the operating system, the only partition that s/he can access is the partition of that user. The end result is hacker cannot compromise the whole system.

Node.js and NPM

If you think about it, an operating system that uses Node.js means that any package available in NPM is, at the same time, also a NodeOS package. At the time of writing, there are 210,735 packages; since the number of NPM packages grows every minute, it would not be strange if, in a few years, NodeOS has a million applications.

It is based on the Linux kernel

This might not seem like a big deal, but Linux is the most-used server operating system. Since NodeOS is based on the Linux kernel, you could run every application written for other Linux distributions with minimal changes.

The downsides

As much as I would like a finished NodeOS, it is not there, yet. It’s still missing many key functions for a server operating system. For example, the whole BASH toolset is missing, including ps, tail, nano and grep. Furthermore, you cannot run it as a desktop operating system since it has no GUI. Sure, you can implement some of the missing features fairly easily using a bit of JavaScript, but the fact all the mentioned features are not available by default, is not good.

So, how can I try out NodeOS?

Using Docker

The easiest and quickest way to try out NodeOS is by using the following:

1. A computer with either Mac OSX or Linux. It might work with Windows, but I did not try it.
2. Docker.

Once you installed Docker, running an instance of NodeOS is easy. All you need to do is execute the following command, and Docker does all the magic:

sudo docker run -t -i nodeos/nodeos

The easiest and quickest way to try out NodeOS is by using Docker.

When you run the aforementioned command, Docker automatically downloads the disk image for NodeOS from a repository and performs the installation of NodeOS inside a virtual machine. Once the installation is completed, it opens an SSH session to the NodeOS shell.

Without docker

There are some reasons why you would want to avoid using Docker, and one being the latest NodeOS version. At the time of writing, the last change to the Docker image of NodeOS was performed two months ago, while the development version was updated six days ago. So, if you want to use the latest version you should definitely get the source code. That’s not too difficult, but it takes a long time. You will need:

1. A computer with Linux. You can compile it on OS X, but it will take longer since it has to make a cross compilation. The same goes for Windows.
2. The Linux build utilities (make, g++, gcc, autoconf).
3. Qemu.
4. Time. Seriously, a lot.

Once you have everything, you can proceed with the source code compilation:

1. Download the project source code: bash git clone git@github.com:NodeOS/NodeOS.git.
2. Compile it by running following commands: cd NodeOS and npm install.
3. I am going to quote, word by word, the official documentation: “Pick some microwave popcorn and go to see a movie. No, really, do it.”. Yes, it will take that much time, so do something interesting in the meantime.
4. Run bash npm start to run NodeOS inside Qemu.

Is it working?

Once the installation is completed, we can check if it is working by executing inside the NodeOS shell the command ls. An output like this should show up:

[ 'etc', 'lib', 'lib64', 'root', 'bin', 'sys', 'usr', 'share', 'proc' ]

If it does, it means some basic commands are working. But, what if we want to display the network card’s IP address? Under Linux, there’s a command called ifconfig that does just that; let’s try it:

command not found: ifconfig

It looks like the command ifconfig is missing. That is because NodeOS does not have a default ifconfigcommand. Now, what? Well, it is simple; NodeOS has an integrated package manager (like apt or yum), called npkg, which is based on Node’s NPM and is easy to use. Installing ifconfig is as simple as running the following command:

npkg install bin-ifconfig

If all went well, the command ifconfig should now be available in the shell. If we try to execute it again, an output like this shows up (I put a random MAC address and IP address for obvious reasons):

eth0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  ether 01:23:45:67:89:ab 
  inet6 f0cd::ef01:0203:0405:181%en1 prefixlen 64 scopeid 0x5 
  inet 192.168.0.21 netmask 0xffffff00 broadcast 192.168.0.21
  nd6 options=1<PERFORMNUD>
  media: autoselect
  status: active

If your output looks kind of like that, then it is working. You’ve successfully installed your first NodeOS application: ifconfig.

It is working. However, what do we do now with the OS?

What is the point of having an operating system written in Node.js if you can do the same things (or even fewer things) that you can do on Ubuntu or any other Linux distribution? Well, the whole point is everything is developed by using nothing more than Node.js. It also means we can develop our applications using nothing more than Node.js. For example, NodeOS does not have a default implementation for the command man, which is used on Linux to display manual pages of other commands. Fear not, implementing it is easy. How, I hear you ask? Simple.

First, let’s install a text editor called Hipster so we can create and edit files by executing the following command: npm install -g hipster@0.15.0. This file editor is simple, and definitely not something I would use as an editor for anything else, but it is good enough in this case. Creating files with Hipster is really simple, just run hip filename, like hip package.json; to save press Ctrl + s and to exit press Ctrl + q. For this example I am going to use a code developed by one of the main NodeOS developers, I have not actually implemented it, myself. The original code for our example can be found in the node-bin-man Git repository.

Let’s get back to creating our first NodeOS application. As with every Node.js application (or NPM package), we start by creating a package.json file, as in the following example:

{
  "name": "bin-man",
  "version": "0.0.1",
  "description": "Format and display manual pages",
  "bin": {
    "man": "man.js"
  },
  "repository": "https://github.com/groundwater/node-bin-man",
  "author": "groundwater",
  "license": "MIT",
  "dependencies": {
    "blessed": "~0.0.22"
  }
}

The parameters name, version, author, repository, license, and description are self-explanatory. The bin collection is a JSON key/value object containing the command name and an associated JavaScript file. In our example, the man command is associated with the file man.js. The collection, dependencies, contains a list of NPM packages that are needed to use this application. In our example, the author of the code included Blessed, a curses-like library with a high-level terminal interface API for Node.js.

Now let’s go to the main part, the actual code.

#!/usr/bin/env node

This part is called “shebang”. It is not actually required by NodeOS, but it tells an operating system how to execute the following code. In our case, it tells the interpreter that everything needs to be executed with the command /usr/bin/env node.

var fs = require('fs');
var blessed = require('blessed');

Just like in Node.js, the function require() loads the selected package into memory and saves it to the specified variable.

var arg = process.argv[2] || 'bin-man';

The standard behavior of a man command is to tell a manual about itself if no other command is specified. Our code example is doing the same: If no argument is specified for the second parameter (the first being man itself), it defaults to bin-man.

var path = process.env.HOME + "/lib/node_modules/" + arg + "/README.md";

try{
  var readme = fs.readFileSync(path, 'utf-8');
}catch(e){
  console.log('No README.md for Package ',arg);
  process.exit(-1);
}

At this point, the program checks if a readme file exists for the given application. In NodeOS, the installation path of every application is the home directory (or /) followed by the directory lib/node_modules. If the file README.md exists, it saves its content inside the variable readme. Otherwise, it shows an error and exits the process.

// Create a screen object.
var screen = blessed.screen();

var box = blessed.box({
  content: readme,
  alwaysScroll:true,
  scrollable: true,
});

// Append our box to the screen.
screen.append(box);

Blessed has a really simple API; showing the content of a file is as easy as telling it to create a box and loading the content.

screen.key(['escape', 'q', 'C-c'], function(ch, key) {
  return process.exit(0);
});

Now, let’s create a way to exit the man application. We combine the keys escape, q or the emacs-style combination C-c to exit the process.

screen.key(['space','f','j','n'], function(ch, key) {
  box.scroll(box.height);
  screen.render();
});

screen.key(['down'], function(ch, key) {
  box.scroll(1);
  screen.render();
});

screen.key(['up'], function(ch, key) {
  box.scroll(-1);
  screen.render();
});

screen.key(['b','k','p'], function(ch, key) {
  box.scroll(-box.height);
  screen.render();
});

We use the directional keys to scroll up or down one row and the keys space, f, j or n to scroll down a page (as many lines as there are on the screen). Use b, k or p to do the reverse.

box.focus();
screen.render();

Finally, we tell the application to focus on the box we created and render the whole thing. Let’s put those files in the directory /lib/node_modules/bin-man and let’s add a simple README.md, something like this:

# Man

Author: @groundwater

## Install

npkg install bin-man

## Usage

```
Usage: man PKGNAME

Display a packages README.md file
```

We are almost done with our first custom application for NodeOS. Only one last small step remains; we need to create a config file since it is a requirement for NodeOS applications. It is as simple as creating a file in the path /etc/bin-man/config.json with the following content: {}, an empty JSON object. Now, we can try our new application. Running man inside the NodeOS shell should show the readme file we created earlier.

Conclusion

As you can see with our simple code example, implementing anything in NodeOS is an easy task, you only need to know Node.js.

NodeOS has plenty of potential, and I think it could become a great operating system once additional features are implemented. It still needs work, but as a result of the popularity of the whole Node.js-based ecosystem, I would not be surprised if it quickly becomes a popular operating system quickly. What do you think about it? Let me know in the comments.

This post was written by Danny Morabito, PHP Developer for Toptal.

NodeOS: The JavaScript Based Operating System was originally published in hello JS on Medium, where people are continuing the conversation by highlighting and responding to this story.