Today I refactored and consolidated all HTML/Templates/Partials/Helpers. I guess I’ve never mentioned how I’m building any of this stuff before. So…OK… let me back up a bit…
- All of the UI is built from simple HTML templates using Handlebars.js. I could have used the latest React stuff. It’s crazy popular, that comes with a lot of advantages, and I should be learning that too — but it also comes with the same Boil-The-Sea approach to everything from the Meno Park over-engineer-al-of-the-things company. I’m trying to consciously choose simplicity and fun whenever possible. My experiences with React so far have been pretty much the opposite of simple and fun.
Handlebars.js (a variant of Mustache templates) are about as simple as simple gets and much to my delight they seem to play nicely with Electron. Like they might as well have been designed for this, it’s that good.
I’ve been using Handlebars templates in nearly every web-related project I’ve worked on for the past four years or so:
- The YourHead.com website uses handlebars on the frontend to build the download, release notes, and other repetitive and dynamic pages.
- The site also uses handlebars running in Php on the backed to fill in the content of the main pages (which are designed in Stacks of course).
- Markedly, my unreleased markdown editor, processes handlebars in user files as well as using some handlebars for its own UI.
- I also have an Obj-C implementation of Handlebars. It’s not quite as perfect or complete as the JS variant, but it is very very fast. I used it as part of fun RapidWeaver plugin I build called “Brackets” that you’ve never heard of. — Sidenote: I was getting close to release, but after some user testing I decided not to. :-( It was just a bit too much code for RapidWeaver users. And in the end I decided a dud product was worse for my primary business than not releasing anything at all. I just decided to put it on a shelf and move on.
- So… I have versions of Handlebars in use for: Frontend JS, node.js, Php, and even Obj-C. If I can get a Swift version going I’ll complete the series.
The handlebars system dynamically loads templates, partials, and helper functions from files in the project directory, in the front-end page, or even created dynamically. But for a desktop application the best bit is that we can “compile” the templates to a JS function and load that with the normal Common-JS tooling. Precompiling is actually a big deal, Electron is essentially a web page with full node.js access to the file system. Disabling all forms of dynamically created, remotely loaded, or eval’ed scripts is the first step to securing an app.
In AppKit we have NSViews, Nib files, and bindings to construct a simple MVC app. I now have something that roughly approximates each piece for Electron. I’m using Handlebars templates as the nibs. It’s just a rough first-order approximation, but it’s made light work of this little app.
### Flow Types - Complete * The integration of Flow type annotation and tooling is all working very nicely now. I’m posting the blog entries just a day apart, but there were actually several days in between. My blog entries are actually running a few days behind. It was a quite a bit of work to get all the tooling smoothly running in Atom, get live reloading working smoothly, and back into building features instead of futzing with type annotations, but it’s all done. Checked in. Branch merged. Phew. * Lots and lots of little refactors were done to support type checking. But the good news is that it’s already paying back some dividends. I caught a couple significant bugs just by the fact that they couldn’t be annotated. It’s also made me very aware of how much error checking I’m not doing currently. LOL. I’ve been seat of the pants coding for a while now — like the longest hackathon ever. If I ever release this I’m going to have hell to pay fixing that up. For now though, fun code means i don’t care about errors… weeeee!!!!
What is this: these are random snippets from my dev journal working on a simple client app for fun. This is a non-serious side project, progresses very slowly, and will probably never see the light of day. The images may not perfectly correspond to the journal entry. In most cases I’ve added them later based on the relative time of git checkins.