This article was peer reviewed by Edwin Reynoso, Tim Severien and Divy Tolia. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!
In the past, cross-platform software development often meant writing the same application in different languages for different operating systems. As you can imagine, this was a difficult situation for project managers, developers and customers alike.
Then, in 2011, Roger Wang introduced something called Node-Webkit. Node-Webkit (which has since been renamed to NW.js) is a combination of Node.js and an embedded WebKit browser which allows developers to use web technologies (i.e. HTML, CSS and JavaScript) to develop native apps. Yes, that’s right! We get to write native apps, using all the goodies that are supported in our modern browsers. For example, CSS3 animations, WebGL, WebRTC, video, audio, and plenty more can all be incorporated into a native application.
In this tutorial, I am going to demonstrate how to harness the power of NW.js to make a tabbed browser, which can be deployed on all major operating systems. As ever, the code for this tutorial can be found on our GitHub repo.
[author_more]
As the name suggests, NW.js is based on Node, so you’ll need to have that installed on your operating system. We’ll also be making use of npm (the Node Package Manager). If you need help getting either of these things set up, then check out our tutorial: A Beginner’s Guide to npm.
Next we’ll need a folder for our project:
mkdir sitepoint-browser && cd sitepoint-browser
We’ll also need some dependencies that should be installed globally (namely, Yeoman, Grunt and Bower):
npm install -g yo grunt bower
Of these, Yeoman (AKA Yo) is a tool to scaffold everyday projects dynamically, thereby avoiding the hurdles of always having to create reusable project structures manually. Grunt is a task runner which Yeoman uses. It also uses npm and Bower to install required dependencies.
Next, we’ll install Yo’s generator-wean. You can either do this globally or locally. Here I’ll do it globally:
npm install -g generator-wean
NW.js itself has a handful of generators but generator-wean (authored by me) comes bundled with ExpressJS and AngularJS which eases the stress of installing and configuring them. WEAN stands for Webkit, Express, Angular and Node just like the popular MEAN.
Now our skeleton app can be generated with one command:
yo wean
Yo is an interactive guy and the generator will ask you some questions in order to assist in making a project that best suits what you want. Here you can just accept the defaults.
The folder structure will look like so:
.
├── app
│ ├── app.js
│ ├── index.html
│ ├── public
│ │ ├── css
│ │ │ └── app.css
│ │ ├── js
│ │ │ └── app.js
│ │ ├── libs
│ │ │ ├── angular
│ │ │ ├── bootstrap
│ │ │ └── jquery
│ │ └── partials
│ │ └── header.html
│ ├── routes
│ │ └── index.js
│ └── views
│ └── index.ejs
├── node_modules
├── bower.json
├── Gruntfile.js
├── package.json
└── README.md
For this project, we are interested primarily in the contents of the public directory. The generator will have filled these files with a bunch of boilerplate (a very simple Angular app), but we will be addressing that as we go.
We can now run the skeleton app using:
grunt run or just grunt
This command can be used at any point in the app development to preview changes. It executes the NW.js project which in turns uses Express for routing just as you would when making a web application. This is a good example of how we can use Node modules in NW.js by injecting them in the app/index.html after initializing.
NW.js also has developer tools and toolbars where we can find controls to refresh, debug, inspect, log, etc just as we do when building a web application in Chrome. You can access these by clicking the hamburger icon in the skeleton app.
The most important aspect of this tutorial is to be able to surf the internet from our native application. The webview and iframe tags are perfect candidates for our plan. The webview tag is effective but quite new to the game as it was only recently added to NW.js. The iframe tag, however has been around since HTML 4 and has wide support. We will use it because it is well-known to most developers.
Bootstrap will serve as the base for our UI. We will use a custom bootstrap theme named Slate from Bootswatch. Download Slate and place it in app/public/css/bootstrap.css.
For our icons, we will make use of Font Awesome. From the project root run:
bower install --save fontawesome
This will download Font Awesome to our libs folder just like other bower dependencies. This is because we specify the following line in the .bowerrc file in our project root (the default is otherwise bower_components).
{
"directory" : "app/public/libs"
}
Fortunately, Bootstrap will handle most of the UI tasks but we need to tweak some of the components and contents to actually make a browser that looks good. To achieve this, we will write some simple and short CSS and place it in app/public/css/app.css:
html,
.tab-content,
.tab-pane,
body > div {
height: 100%;
}
iframe {
background: white;
}
.controls {
position: fixed;
top: 10px;
right: 8px;
}
.controls > i {
padding: 0 3px;
}
.controls > i:last-child {
color: red;
}
.controls > i:hover {
color: white;
cursor: pointer;
}
.close-tab:hover {
color: red;
cursor: pointer;
}
The html, body, tab-content and tab-pane height are set to 100% to ensure that regardless of the size of our browser app, the content should fill up the height of the window. By default, width is 100% so there is no need to explicitly specify it. We also give a minimal style to our browser controls which we will be seeing in a while.
Continue reading %Create a Tabbed Browser Using Node-Webkit and AngularJS%
An interactive website needs to be able to interact with user input, which is commonly in the form of form submissions. A WordPress site is no exception to this rule. There are various interactions happening on a website on a daily basis. For example, subscribing to a newsletter, sending a message to the site owner and filling in an order form. All of these usually happen from POST requests during a form submission.
In this article, we're going to take a simple example of handling a POST request from a user, which is submitted via a contact form. We are going to use an internal WordPress hook to properly get the data, process it accordingly and redirect the user back to a specific page.
This article assumes you have a basic knowledge of the WordPress Plugin API. If you’re not familiar, it’s highly recommended to become review the Codex page first.
WordPress is based on an event driven architecture. This means internally, WordPress core is filled up with various actions and filters to modify the program execution or to alter the content during runtime. Examples of actions that are running during program execution are init, wp, template_redirect and wp_head. Many plugins utilise these actions and filters to modify how WordPress works.
It is no different with what we are going to achieve. All we need to know is the proper hooks needed for the POST request and to modify our code accordingly. This is possible by pointing all our form submissions to a specific file in the wp-admin directory called admin-post.php. If you have experienced integrating your application with WordPress internal AJAX API, then you will notice that the basic structure of admin-post.php is not much different to the admin-ajax.php counterpart.
Continue reading %Handling POST Requests the WordPress Way%
I've been thinking a lot lately about all the small utility apps I've programmed over the years and how I could have designed them better.
I loosely define a utility as any project designed to solve a singular and specific problem for a certain situation or business process.
For example, I built a small PHP application that accepts an export from an ecommerce store and parses the data into another format needed for a specific business process.
I normally build a utility by having an idea of a problem to solve, and I jump right in to an editor and start typing.
Some time later, I find myself wanting to steal functionality from old utilities, but when I go to reuse some code, I find out how badly I programmed the thing! Generally I don't spend a lot of time on small utilities, so they are programmed without classes, namespaces, or even OOP. Procedural FTW!
It's made me think that I should be more organized, even in tiny projects.
Here are some issues I now consider before starting any new project.
Regardless of how tiny the utility is, practice good programming! Use proper source formatting, naming conventions and commenting. Another developer should be able to see what's going on in the code with little effort.
Avoid procedural coding where possible.
I no longer allow myself to write sloppy code, even if the project is tiny or of limited use.
It doesn't matter if the utility has a single function to perform: it should be well defined before coding begins. The definition of the app will include basic declarations, like who will use it, what data it will expect, and what output it's supposed to give.
Define data sources, security concerns, and whether the app will grow with more functions over time.
Where will the utility be hosted?
The more detailed the definition, the easier it is to pick tools and stay in scope while programming it. This is especially true if you're programming for someone else!
If other programmers will be involved, increase your documentation and commenting. Use source control, and focus on separation of concerns in your classes and methods.
If no programmer will ever need to read your code or work on it except you, keep to the basics and don't overwhelm yourself. Just make sure you can still make sense of it!
Depending on the context of the utility—such as if it is an internal project for an organization that will own the work—the code may be hosted in a public repository. If so, increase documentation; add a readme.md file; add DocBlocks to define ownership of the code, and use Semantic Versioning.
If there are concerns about intellectual rights and who owns the code, this would require you to throw a license in there.
If you foresee future development, assume that others will work on the app, and that it therefore needs source control, improved documentation, and a license attached.
You may not be the person to maintain future versions if the app is internal to an organization. It's better to spend the extra time on these chores than for future programmers to dismiss you as a poor programmer.
If you write well-documented code, you may be able to come back later for a letter of recommendation. (You can't take company-owned code with you, but at least you'll have a letter confirming all your work was good!)
Continue reading %13 Tips on Designing and Building Apps More Efficiently%
Digital Marketing Agency in Bristol, UK.
