Sustainable Node.js development with only a browser
Wednesday, December 12, 2018 by Anton Kosyakov
Wednesday, December 12, 2018 by Anton Kosyakov
Nowadays, there are many collaborative platforms for showcasing JS code snippets and frameworks. Most of them run in your browser, some even manage to magically run Node.js applications in the cloud. They abstract away many possibilities in order to focus on prototyping and learning.
This simplification (or even magic) eventually turns out to be a hard wall. Once we leave the prototype stage, we need to be able to control and freely combine different versions of frontend and Node.js frameworks, connect to the database that best fits our use case, use different JS flavors and deployment services.
In this blog post, I will show you a transparent way of getting started with Node.js easily without the magic. The approach taken provides a low entry barrier without the wall once you grow out of it. You will learn how to write Node.js applications in a browser-based environment, that has all the depth of a full local dev environment with VS Code but the friendly onboarding of JSFiddle. These environments can be freely shared to work together and showcase your applications.
The dev environment is called Gitpod and is entirely free for open-source development.
Let’s get started by developing a simple “Hello World” application and learning the basics of Node.js development.
Gitpod treats any GitHub repository as a project which can be opened. Let’s start by creating a new repository for our Hello World project:
Now, we can open the created project in Gitpod. You can do it by simply prefixing the repository URL with gitpod.io/#. For example, I’ve called my repository node-hello-world and it can be opened in Gitpod with gitpod.io/#https://github.com/akosyakov/node-hello-world.
The first time, you will need to sign in Gitpod with your GitHub account. GitHub will ask you to authorize read access to your email address. Write access to repositories can be granted later on your access control page.
Gitpod starts a new workspace, which is a Linux-based cloud container, and provides access to it via a VS Code powered online IDE. Workspaces are started on demand and automatically shut-down if you don’t use them. They are continuously replicated and never deleted, so you always can restart a workspace later from your Gitpod dashboard.
If you don’t want to create a new project from scratch, click on a snapshot link of my workspace to try Hello World application. I will cover later how one can make a workspace snapshot.
By default, each workspace is preconfigured with standard tools like Node.js, npm, yarn and nvm. Later we will learn how to change the Node.js setup. Now, let’s code something and run it:
create a new file with app.js name and type the following content:
const message = ‘Hello World’;
console.log(message, ‘from Gitpod!’);
As you type, you can see that Gitpod validates your code. It also provides you with smart completions and documentation on hover.
In order to run the application, type node app.js into the terminal.
Of course, you can have more than one terminal to your cloud workspace.
Next up, let’s see how we can debug the application:
Our program should run, and when a breakpoint hits you can inspect call stack, variables and even use the debug console to evaluate expressions.
Let’s have a look at how we can share our changes through Git. Open the Git view, stage your changes, enter a commit message and click commit. You can also open a diff editor by clicking on changed files and push new commits to GitHub with Git: Push… command.
If you have not granted write access to your repositories yet, Gitpod will ask for it. Grant permissions and try to push again.
As mentioned above each workspace by default is preconfigured with standard tools, like Node.js 8.x.
Let’s assume that we agreed on using Node.js 10.x for our project instead. Usually, all developers have to update their local Node.js versions and often switch between them depending on what project or branch is used.
With Gitpod, it is different. You can configure a workspace with a specific Node.js version for each branch via Docker images, without changing the local setup for any developer at all.
The easiest way to initialize the config is to use Gitpod’s CLI. The CLI will walk you through the most important configuration options and create a .gitpod.yml file that is located in the root of your repository.
In the terminal type gp init.
The created files will be automatically opened in the editor. Let’s change the config so that it starts two tasks in separate terminals:
image: file: Dockerfile tasks: - init: node --version - command: node app.js
And change the Dockerfile to use Node.js 10.x as the base image:
To try it our we need to push the config back to GitHub and open a new workspace. Let’s do this through a pull request, so we learn about the GitHub integration on the way.
Gitpod provides seamless integration with GitHub features like creating and reviewing pull requests.
Let’s open a new pull request from Gitpod:
As I’ve mentioned at the beginning Gitpod treats each GitHub repository as a project. Actually, it is even smarter and can figure out from any GitHub URL which branch should be opened and how.
Let’s go to the pull request page on GitHub and prefix its URL with gitpod.io/#, just like we did initially:
Opening a PR with new workspace image can take some time since Gitpod needs to build the image. But it is only rebuilt when changed.
As you can see, Gitpod opens with a branch for your pull request. PR file changes are presented on the left sidebar to review. Our init and command workspace tasks are executed in terminals, Node.js is 10.x now, and Hello World is printed.
While reviewing in Gitpod, you can comment, change the code to address comments, suggest new changes, etc. When you are done, merge your pull request from Gitpod as well.
Since Gitpod workspaces are running in the cloud, we can share them in similar ways how you share documents in Google Docs.
You can share you running workspaces with colleagues to collaborate on exactly the same codebase, development tools, running terminals, and applications. It is particularly useful to assist each other on some tricky configuration, dependency or code problem.
In order to share a running workspace: click on your account avatar, select Share Running Workspace, enable sharing, copy a link and share the copied link with your colleagues.
Both users use exactly the same workspace and see the shared output in terminals.
You can take a complete snapshot (clone) of your workspace, even including your IDE layout, and share it as a link. Think about workspace snapshots like code snippets on JSFiddle. It is useful in the same way: to share reproducible examples on issues, Stack Overflow answers, for tutorials and workshops. But at the same, you share the complete development setup and present it in the appropriate way.
In order to share a workspace snapshot: click on your account avatar, select Share Workspace Snapshot, copy a link and share the copied link where you want.
The shared workspace snapshot preserves not only the development setup but the IDE layout and even selection in the editor.
So far, we’ve only had a look at a simple Node.js application. In case you wonder whether it will scale to sophisticated applications you can try any of the following repositories:
Gitpod provides the complete Node.js development experience right from a browser. It enables you to automate your development setup, quickly onboard developers, streamline code review and testing processes on GitHub, help each other in real time, showcase your applications and setups. Also, it is entirely free for open source development!
If you have any questions, join Gitpod Community on Spectrum! We are listening intensely to all feedback.