Modern web development is hard. Long gone are the days of opening up your text editor, writing some HTML, CSS and JavaScript, saving it to an index.html
file, and loading it in your browser.
These days, starting a project involves setting up a lot of tooling, from bundlers to test runners, and linters to type checkers. All of this tooling takes so much expertise to set up that we tend to forget that it can also be complicated to use.
You might ask, "What do you mean? You just fire up your terminal and npm run build
. Easy peasy."
For many of us, fiddling with package.json
and interacting with the terminal seems easy, because we've done it for a long time. But do you remember how you felt the first time you were faced with a terminal?
CLIs are actually hard
The requirement for developers to learn how to navigate the command line is especially problematic for new engineers who are starting off their web development journey, and for less technical team members like designers, product owners, and testers. The mental overhead of having to learn necessary CLI commands before being able to run your application can be overwhelming, leading to confusion and frustration.
Being a coach at Codebar, a non-profit that helps underrepresented people to learn programming, has allowed me to witness this exasperation first hand. I can confidently say that I do not envy the new developers who just want to learn how to design and develop web apps in 2019.
Commands, commands, commands
A number of tools exist to help alleviate the pain of getting started on a modern web stack—tools like Gatsby and create-react-app
aim to be low-friction ways of bootstrapping new projects with useful defaults and automatic dependency installation.
However, all of these tools are command line-based and come with bespoke commands to help interact with the bootstrapped project, requiring developers to learn and remember more commands for common tasks. For example, create-react-app
comes bootstrapped with a whole host of extra command line scripts (start
, build
, eject
etc.) that are required for development on the project.
Almost inevitably, they don't provide exactly what is required for your project. And guess what? Installing and removing dependencies the correct way requires learning even more terminal commands!
After my experience coaching junior developers and remembering my own beginnings, I began to wonder, could the overhead of these processes be reduced by providing a visual means of interacting with the project?
Why, as an industry, are we obsessed with creating CLI tools when our day jobs are concerned with creating GUIs?
Introducing Glicky
Glicky is an in-browser task runner for modern web development that can be installed simply by running npx glicky
inside of your project root directory.
Glicky is hosted on NPM and runs in your browser, allowing for easy installation and fast startup times on any platform.
Here are a few of the problems I wanted to solve with Glicky:
- Adding, removing & executing npm scripts: When running npm scripts, it can be hard to visualise the state of any given script. Scripts that have resulted in an error or need restarting could be left unattended, leading developers to wonder what's happened. With Glicky, however, we can display different visual states given the output of an executing script. Further, we can show an alert when a process has output an error, and provide a restart button when a script has stopped due to a fatal error.
- Parallelizing tasks: Running multiple scripts is also tricky within a command-line environment, each process usually requires a new tab in your terminal, leading to an unnecessary context switch when attempting to understand the output of concurrent scripts. However, with Glicky, we can group these scripts and their output together on the same page, allowing developers to quickly scan what is executing, how it is performing and anything that may have gone wrong.
- Managing dependencies: Dependency installation and package discovery is also something a GUI can provide. A type-ahead component could be a perfect fit for newer developers attempting to find and install dependencies, allowing users to browse packages without having to know the exact name of the dependency they need. Vague command line arguments can be made obvious, replaced by visual components that allow dependencies to be defined as for development or optional.
Overall, Glicky aims to make everyday development workflows more intuitive and ergonomic.
Because we don't want to introduce even more commands and configuration files, Glicky is zero-config and doesn't pollute your project with configuration files. It is also framework-agnostic; as long as your project contains a package.json
, you should be good to go, whether you're writing apps for the browser or Node.js!
Oh, and Glicky comes with a light and a dark theme, in case you're into that type of thing!
Check out Glicky on GitHub or give it a spin with a simple npx glicky
in your project!
What is this magic?
I did some research into existing graphical developer workflow tools and found ones like Guppy by Josh Comeau and JSUI by Kitze. They serve slightly different use cases, but I thought I could learn from how they work.
Both of the these projects are open source and written in web technologies, built with Electron so that they may execute native tasks (file access, running CLI commands, etc.).
The problem with Electron apps, however, is that because they are bundled as desktop apps, they result in large downloads and require installation via native package managers (such as Homebrew), and require you to provide an update mechanism to keep the user on the latest version.
Instead, I wanted Glicky to run in the user's default browser. This required me to figure out if a browser could execute and display the output of terminal commands. How could a browser-based tool access and modify the file system?
The trick behind Glicky lies in WebSockets. When you run npx glicky
inside your project, we spin up a local Node.js server and launch the Glicky client in a new browser tab.
When launched, the browsers opens a WebSocket connection with the server via socket.io, which it then uses to communicate with the server and request platform-specific resources (like executing a command line script, installing dependencies, etc.)
WebSockets are a perfect medium for such constant client-server communication as they provide a keep-alive mechanism out of the box, providing a low latency environment for the client to talk to the server. After experimenting with this, I found that the latency was so low when running the server on your local network that it can feel like you are running server commands directly on the client!
The future
Currently, Glicky provides helpers for common tasks inside projects that have already have a package.json file.
In the future, Glicky hopes to include an onboarding process for projects that do not contain a package.json. This would provide a visual means of guiding the user through the npm/yarn init
process and bootstrapping the project with desired dependencies, or initialising a given boilerplate (Gatsby, create-react-app, etc.).
Certain boilerplates could also include custom UIs to help perform tasks specific to their environment (an eject mechanism for create-react-app applications, for instance).
I'd love to hear your feedback over at Glicky's GitHub repo or on Twitter!
Happy coding!