April 27, 2020
The Mimix Nebula system of software deployment simplifies the packaging and distribution of cross-platform applications built with NodeJS, HTML, and WebSockets.
Today, we’re making available an early version of our Nebula deployment system for cross-platform applications. Nebula is an open source product, available free under the Blue Oak License and ready for you to customize to deploy your own HTML-based desktop applications with WebSockets on Windows, Mac, and Linux.
Get the Download
There are four ways you can get the free Nebula software:
- Download the Windows installer.
- Download the Mac installer.
- Download the AppImage for Linux.
- Download the source zip or tar and build from instructions.
The Nebula installer contains everything you need to experiment with creating and modifying a Nebula app without any “building” steps. Simply use your favorite text editor to modify the HTML/JS files. Note: The current release is not digitally signed. Click “Yes” in the Windows installation dialog to allow an “Unknown Publisher” (The Mimix Company) to install the app.
You can move to building from source when you’re ready to design your own back-end server or use a different set of frameworks than we include.
Before You Begin
We recommend reading Nebula: Simple & Flexible Applications with MSL Data before working with the Nebula download. It provides the background information and jumping-off points to help you think about the new kinds of applications you can build with Nebula based on the tools and frameworks you already know.
Disclaimer of Warranty
The Nebula software is licensed to you without cost on an as-is basis and without any warranty, express or implied. This free license does not include access to tech support. Bug fixes and upgrades, when and if they become available under this license, are your responsibility to install or integrate.
HTML applications offer a wealth of frameworks and tools for generating cross-platform user interfaces. Each developer has his or her own favorite code editor, web UI framework, and hosting solution. Where all of these fail to deliver is in packaging an application so that it can fully benefit from its cross-platform nature on all three desktop operating systems: Mac, Windows, and Linux.
The Nebula solution brings together the foundational elements needed to build a modern web application with HTML that can be rapidly deployed to any user desktop — without requiring a developer account signup anywhere and without committing to any specific UI framework or backend.
Here are the components we’ve packaged for you to build with. All of them are also open source and you can plug-in other packages or tools you prefer:
- Built-in local NodeJS webserver.
- Built-in Chromium browser.
- Built-in WebSocket server and receiver.
- Built-in “Local World,” an easy-to-edit HTML home page.
- Built-in data-binding, routing, and commanding (AngularJS).
- Built-in Bootstrap UI components.
- Built-in Bskit UI components and themes.
- Built-in MDI icon sets.
- Built-in custom color names.
- Access to local (packaged) or remote web pages.
- Access to any NodeJS service via WebSocket.
- All packaged in an Electron-based, one-click desktop executable for Windows, Mac, or Linux!
The Nebula tech stack was designed to fulfill our requirement that our apps be able to run locally on any platform or be hosted in the cloud. We also wanted our app to have a simple way to communicate with a server or another instance of itself over a network, or within the same machine.
These goals were achieved by stacking the Electron packaging system with an AngularJS front end. We chose AngularJS because of our experience with the framework and the body of our existing code that could be used to scaffold the app’s interface. You can use Nebula with any framework of your choice by simply substituting the AngularJS index.html file (and its supporting dependencies which are installed with Nebula) with an index.html and the appropriate dependencies for the framework(s) you want to use.
Because all HTML/JS frameworks work in a server/browser environment and Nebula provides both the built-in web server and browser for all platforms, all HTML/JS frameworks will work with Nebula.
Being regular HTML/JS apps, Nebula applications can communiciate using any standard protocol or API supported by the Chromium browser. We’ve included special scaffolding for WebSocket applications, a simple text-based, always-on communciations channel we use to let our app talk to a local or remote server or to another instance of the app itself.
We chose WebSockets because the format is pure text without API restrictions. This means you can send messages over WebSockets which use any existing API syntax — or you can make up an entirely new one to fit your application. Since our applications speak the MSL language, we use this wire to communicate MSL between our viewers and servers, but you could use the wire for anything — even a group chat.
Using WebSockets as data wires, separate from the HTML/JS user interface itself, opens up Nebula applications to a new kind of communication and UI paradigm.
Desktop apps communicate with data sources using the same monolithic app that draws the UI. Web applications rely on a remote server to perform any backend communications and to provide a renderable interface.
Nebula apps are enabled for a third kind of architecture, shown in the diagram. In this design, UI elements are delivered via HTML/JS while data is delivered on separate WebSockets for each source. This allows hot-swapping an interface over data, or vice-versa.
Components & Data Binding
We’ve chosen to include the Bootstrap UI components because they cover most of the requirements of modern UI design. Our Nebula app also contains many examples of data binding where application values are shown inside UI buttons or other elements, or where the appearance or functions of UI buttons are changed based on program values or values received over the WebSocket wire.
Using our sample code, you can quickly build a non-trivial AngularJS application, or you can replace our AngularJS components with your own components from a different framework.
Routing & Commanding
Because routing (figuring out what page to display) and commanding (executing a function in response to a button or menu item) are two of the most tedious parts of application design, we’ve scaffolded these into Nebula for you to use as a starting point. By examining and modifying our code, you’ll be able to connect your app’s buttons and menus to the back-end functions they need. We’ve also provided examples of how to make UI elements send data over WebSockets and how to respond to incoming WebSocket messages and update the UI.
After downloading the Nebula app for your platform (Windows, Mac, or Linux), you can experiment with the built-in controls before modifying the app to suit your needs.
Nebula installs a local WebSocket server which you can connect to using the Local Mimix button in the interface. The local Mimix service provides an echo of whatever you send it. You can also connect to two public WebSocket servers which also echo what you send.
Once connected, use the Send button to send text over the WebSocket. The examples show MSL text from our programming language, but you can modify these in the source code.
Websocket messages you send and receive are shown in the UI in the order in which they took place. The Clear button erases the input text box and the Auto checkbox does so automatically after each WebSocket message is sent.
We’ve provided the scaffolding to easily modify this code to use WebSockets from any set of servers. The interface updates automatically to show Connect buttons for all the servers you define.
In addition to a standard WebSocket wire, we’ve provided a separate admin wire on a different port which your application might find useful. In Mimix, this wire is used to send admin commands to the server which are separate from the data, and you might find a simliar use for an admin wire in your app. Admin wires are defined in the built-in scaffolding. We use them to increase security by ensuring that user-facing applications simply don’t have the wiring to communicate with admin servers.
Commanding & Data Binding
Most of the buttons in the sample UI contain examples of data binding and commanding. The orange Connect buttons, for example, are labeled with the server names which are dynamically taken from the list of WebSocket servers you define in the source.
When a WebSocket server connects successfully, the Send button is automatically updated with the server name and the button color is changed. Connecting also updates the banner component which opens the page, changing it from “Not Connected” to the version number of the connected server. This is an example of an AngularJS service updating the bound values for a separate UI component, in this case the banner. The banner detects the changes in the bound values and updates automatically without explicitly being called.
When data is received, the scrolling list of received messages is updated in the UI. You can move between servers sending different messages and the code is smart enough to preserve the “always-on” connection if it already exists or to start a new one if it doesn’t, using the same UI button.
While these examples are trivial, your application can use the same commanding and data binding methods to communicate with any kind of server and update the UI appropriately.
Navigation & Routing
The Nebula app includes built-in features for navigation and routing. The menu displayed across the top right is made of easy-to-edit JSON. AngularJS pages are contained within views, each view being made up of directives or custom HTML components with code behind them in controllers. Straightforward file organization inside the app’s folders makes it easy to find and edit the views or directives you need to build your app.
Fonts, Icons, & Colors
Icons and colors are often frustrating to add or edit inside non-trivial apps. The Nebula sample app includes a custom color naming system, making it easy to design named colors and apply them to all of your UI elements. On the home page, for example, you can click a color name to apply that color to a large icon on the page. We’ve included a custom font and the MDI icon set, too, as jumping-off points for you to choose your own fonts and icons.
Global and Scoped Data
Finally, we’ve included examples of both globally and locally scoped data, often a point of confusion in AngularJS apps. The version information shown on the app home page, for example, is a global value passed to the directive which displays it. The WebSocket messages on the same page are lexically scoped and visible only to the component that displays them. You can use these examples to build similar components in your apps without digging through documentation for working examples.
Other Scaffolding in the App
The Nebula app contains other functions it inherited from another product of ours. These are not utilized or documented in this release. However, an inspection of the source code will reveal the following ready-made and working features which you can use in your own Nebula app:
- JSON-based data from local files or Firebase
- User and app configuration settings
- Protected routes with Google authentication (no keys/ids in app)
- Page-style CMS with named, routable pages and JSON contents.
- Blog-style posts with named, routable posts and JSON contents.
- Modular components for displaying products and profiles.
Note that this version of the Nebula app will show console logs and error messages and also displays broken links and missing page content. The content was removed from this open source version because it contains code that is the subject of a US patent application.
You can visit the Ungallery app from which Nebula was built to see these features working in a production alpha.
Index to Source Files
The Nebula installers create the following folder structure under the directory where you choose to install this product. These examples (installation directory: c:\Nebula) are for Windows but the same structure applies under the installation directory for all platforms.
Contains nebula.exe, the desktop executable. For diagnostics, Nebula can be run from your own browser. See the documentation to start the local web server and for more information about building your own Nebula app from source.
Contains index.html, the app home page.
Contains folders for the custom controllers, css, directives, images, json, services, and views which comprise the AngularJS app. The AngularJS functions used to build these components are documented here. Notice you do not need to download or install AngularJS in order to begin coding with the installed app.
Contains one folder for each framework used by the app.
Contains the back-end servers for the app. Currently compiled, these will be released in open source later. You can replace the streams module with your own back-end and rebuild the app. For testing, simply run your server in a separate process and change the ports in the app to test from a browser.
— D 4/27/2020
April 27, 2020
Note: While preparing our new Nebula tool for release, I came across this unpublished post about tooling that I’d written two years ago when we started the company in November, 2018. Sprint, mentioned here, has since become a nothing-burger sub-brand of T-Mobile. Their tooling is one of the reasons they failed.
Thanksgiving is almost as famous for the dinner conversations as for the dinner itself. This year, while discussing geeky stuff with my cousin, he asked me about the latest Intel Core i9 processors and how they fit into our hardware plan. I told him that I like to buy the fastest processor I can get at the time because it lasts longer. In my experience, the very best equipment costs about half again as much as the next tier down but performs well far longer. I said, “Most people are on a three year upgrade cycle but with this approach you can get to a…”
“Five year cycle,” he said, as we finished the sentence together. Xavier was a VP of Operations for a major worldwide airline. He knows a lot about procurement cycles and getting the most out of expensive hardware. And PC hardware is expensive, there’s no doubt, which is why many companies avoid spending what they should on IT.
When I was a mainframe programmer at IBM’s Santa Teresa Laboratory, we had a zero-day upgrade cycle. You could get anything you needed immediately. IBM operated a PC Store on campus just for employees. With nothing more than a manager’s signature on a tiny scrap of paper, you could stroll into the PC Store and get whatever you wanted. There was no drawn-out requisition process. I didn’t even have to specify a model or a price. Your ticket would say something like “PC Desktop” and a signature and you’d just pick out what you need. Needless to say, this was a geek’s dream come true. No having to explain your equipment requirements to people in suits. No arguments about how much it cost to have good tools.
Now you may say, “Well, IBM has a lot of money and they make computers and they could afford to do that.” Of course, those things are true. But there’s another reason for IBM’s generosity when it came to computer hardware and software. It’s because the company figured out that such an approach would actually save them a huge amount of money.
You see, IBM is very studious. They don’t do anything without having a PhD chart it out first. Years ago, they asked some smart guys to see if the computers and software tools available to programmers made a difference in their productivity. They used a simple metric: the responsiveness of the computer vs. the number of lines of code minus the lines of errors that the developer produced. Using their own worldwide network that predated the internet, it was easy to measure the computer’s responsiveness — down to the millisecond. Likewise, it was easy to correlate every programmer’s output with how many lines of ‘good’ code and how many lines of errors he or she wrote.
If you’ve ever written code, their findings won’t surprise you. Every millisecond of delay in the developer’s computer was costing the company money in reduced output and increased errors. With what IBM was paying programmers then (and what they cost now), it was simply cheaper to make the computers as fast as humanly possible in order to allow the developers to be as productive as possible. When programmers leave the flow state, as Mihaly Csikszentmihalyi calls it, there is a time penalty to recover. Any delay in the hardware or software could result in losing the programmer’s attention and taking him or her out of flow. Hence their willingness to let us have any tech tools that we needed for our jobs.
Taken from a 30,000 ft. view, this concept applies to everyone in your organization — not just programmers. In an earlier post, I alluded to a brief stint I did at the Sprint store. Let me tell you, Sprint has shockingly bad IT. Shockingly. Bad. It’s clear that no one at Sprint has studied how much time their employees spend fighting with the company’s outdated hardware and software. It’s time they’re not spending on getting new customers — or making the current ones happy, which is even more important. Anyone who watches Undercover Boss can tell you the same thing. Old, slow computers and outdated software waste your employees’ time but, worst of all, they hurt your product and your customer service quality.
In addition to making the programmers more productive, having better computers made working there a lot more fun! I’ve always thought that one of the best perks of being in the computer business is that you get to have kick-ass hardware. It’s quite possible that the enjoyment of having performant hardware and software contributes just as much to programmer productivity as response time. People should have the tools they need and the tools they want in order to do a great job. At IBM, this required a $40 million mainframe which they also let me access from home. How many nights I spent volunteering to learn about work hardware and software because it was simply awesome — versus being frustrated all the time with crappy tools and trying to avoid them. Today, I use a $2,000 laptop for the same reason.
IBM had another brilliant way to spread tools around to those who needed them: an early internal version of eBay where anyone could post hardware they didn’t need and any other employee could take it from them. All that was needed to complete a transaction was the signature of the manager in the listing department and the signature of the manager in the receiving department. The surplus hardware was then shipped via the company’s internal shipping mechanisms to the loading dock nearest the new “buyer.”
What a brilliant way to reuse equipment within the company! At IBM, we called this spending Blue Money, money that had already been spent and now should be maximized and used again as many times as possible since it wasn’t costing the company anything with outside vendors. Perhaps there is some “Blue Money” in your organization that could be better utilized somewhere else.
At The Mimix Company, we’re working hard to invent the next generation of reading, writing, and research tools for computer workers of every kind. We believe that better tools give better results. We invite you to check out the whitepaper and join our efforts!