Next Generation Hammer



So what’s next for Hammer?

This is a question I’ve been asking myself for a while, in fact, ever since I took over the full responsibility for the product in 2015.

Whilst I had to invest quite a bit of energy to update the current application, release new features, restyle it, change its distribution method, this has all really been focussed on keeping the product alive and relevant, rather then enabling it to truly flourish as a product that many people, including myself, continue to adore.

The spirit of Hammer is unbroken, resolute, steadfast.

Times Have Changed.

##The Rise of the Static Site Generator and Build Tools

Hammer was initially released back in 2012/3, when although static site generators were certainly available, they were not as prevalent and widely adopted as they are today. The original product team built both a solid compilation tool, the Hammer Gem and a native client application wrapper for MacOS. What was created was a solution admired and praised for it’s elegance, simplicity and intuitiveness, compared to the tricky, confusing and sometimes scary command line applications.

Yet today, still, it’s the command line tools that dominate the static site generator space. These are the Open Source static site generators, ranked by Github stars.

Jekyll - :star: 31,798
Hugo - :star: 20,865
Hexo - :star:19,117
Gitbook - :star: 16,724
Gatsby - :star: 14,868
Nuxt - :star: 7,564
Pelican - :star: 7,400
Metalsmith - :star: 6,354
Brunch - :star: 6,230
Middleman - :star: 6,052

In addition to these, we also have build tools, like Grunt, Gulp and Webpack.

It’s fair to say that there’s significant investment of time and expertise that goes into the development of these tools is way beyond what Beach can commit to purely developing the Hammer product and in particular, Hammer’s ruby-based compiler, alone.

Questions I ask myself are.

  • What do these build tools and static site generators offer users that hammer does not?
  • How do these tools support different use cases e.g. simple static sites, SPA’s (single page applications), javascript frameworks, etc.
  • How do they handle dynamic and static data?
  • What performance metrics do they excel at?
  • What is the core underlying technology, programming language?
  • Which is likely to stand the test of time :crystal_ball:?
  • How easy are they to get started with?

Cross Platform Desktop Apps

One of my absolute favourite tools right now is Abstract. It’s Git for artwork, mostly for me, my Sketch designs.

Abstract’s client app is built using Electron, so it’s quite likely to be heavily focused on javascript, but they do such a great job because they balance it with some attention to the native parts, with Objective-C / Swift. According to this job post, anyway…

Being able to more easily provide Desktop applications for more than one platform is pretty important, in my view. Whilst I still believe that being Mac-first really challenges us to focus on the product usability and aesthetics, I don’t want to be constrained by our technology choices.

Future Hammer should try to be more inclusive for additional platforms and whilst tools like Electron are far from perfect, I think if done well, we could move this way.

Certainly, focussing more on our javascript tool chain, an area where the Beach team has much more resource and experience - essentially, I have been the only Objective-C dev so far on Hammer - would be much more efficient.

Product Integrations and Services

Beach’s suite of tools - which include Hammer, Forge, Anvil and Chisel (a free and open headless CMS) - make for a potent workflow.

Future Hammer should be developed with this workflow at it’s heart, with seamless integration and transition from one service to the next. Whether it be using Anvil to run a site locally on local config-less dev server with a .dev url, to deploying a site to a private staging environment where it can be iterated with team-mates or your clients, to world-class production grade continuous deployment and CDN-based hosting services, to pulling in content from your custom content model into your site, then Beach has a workflow to suit you and Hammer has an important role to play.

Hammer sits on your computer. It talks with and responds to your file system, your local server and browser. It also has the ability to talk to these remote services and any others that add value to the workflow, without distracting the user with unnecessary complexity.

Pricing & Commercials

Current Hammer is very much a tool for individuals. Collaborating with team members, through Hammer alone, is nearly impossible.

With Git and a remote repository, it’s at least bearable.

The lack of cross-platform support however, has really prevent adoption of the tool within larger teams.

In order for Hammer to flourish, it has to evolve from a very targeted niche tool for individual mac users, who are typically “creative developers” or “technical designers” to be able to accommodate the needs of groups of these people working together on web projects.

Selling Hammer for a one-off fee < $20 is not sustainable in the long run. To justify our customers paying $20 annually, requires a healthy development workflow of new features released each year. Paying $20 a month requires a different value proposition entirely, one that is aimed at groups, teams and organisations.

Beach doesn’t have bags of cash to spend on advertising, nor do I believe that is the way to achieve long term success with products. We need our products to do the leg work of turning one passionate customer into 5. Or 10.

To do this, our products need to be obviously brilliant for the individual, but super-charged when used as a team, that on-boarding additional Seats becomes a no-brainer. We need a toolchain that empowers our core product teams and the community to contribute more frequently to new developments, as the industry doesn’t sit still for very long, how can we?

Web Projects - The SPA and Javascript Frameworks

We all know what the javascript landscape looks like…

But within all the chaos there are some real gems, tools that can really supercharge and extend the capabilities of development teams.

Angular.js / Angular 2

React, in particular is a favourite of ours and where we have most hands on experience in the real-world / production sense.

But the tools used for building these, simple or complex, applications are very similar to those used for building simple HTML websites. Certainly the tool chain, from local dev server, to build tool, to continuous deployment processing, to server side rendering and production hosting, is already in place.

We have been using the Beach products for years now, to build our customers projects. We’ve learned a lot about how the products are already great for this and importantly, how they could be improved to make building richer applications as easy and intuitive experience as it could possibly be.

All of this is to say, I have started to put this thought process into action and our challenge to the end of the year to is to really step into the process and start to validate some technical approaches, concepts and open the discussion with the team and with our community.

That is what this topic is for, I hope you’ll participate.


Our first hypothesis, is to explore the Electron route.

That is to say, it would be relatively straight forward to reproduce Hammer’s existing UI with React.js. But how will it perform? Will the non-native elements be good enough? Certainly the Abstract app is great and gives me confidence.

We also need an engine. The initial thinking is that, instead of porting the existing Hammer engine into the new app, we think about whether we can use an existing build tool as a basis which is performant enough, more so than the current Hammer gem, extensible enough, well supported. It is also likely, given these factors, that the build tool will be powerful and likely, quite complex to use, such that our audience may find barriers to using it directly. You can almost guess where I’m going with this.

I’d like to see if using Webpack as a base engine within our application, can give use the freedom to explore the different use cases we’re interested in, without the burden of building essentially another webpack…

@boris @rkolpakov I invite you to provide a summary of your thoughts and explain your approach so far…


A couple of brief notes on this, Steve, and please note that some of these are just details or minutiae that I think warrant flagging now so they factor into future engineering decisions.

  1. Re: .dev domains for local development – This is no longer a good practise owing to Google buying up the .dev tld and forcing it over https in their newer versions of Chrome. The fact that .dev is now a valid tld makes it unwise to use as a local development domain, and the https requirement makes it impractical without people setting up LetsEncrypt on their development machines. The .test tld is a reserved name, so it should be futureproof, or I’ve recently taken to using .d for my projects as a kind of shorthand to the old .dev days. Just a thought.

  2. As far as an engine goes, Webpack seems to be the tool of choice at the moment in this space, and I can see why it makes sense to adopt it moving forward. Using Webpack under the surface, and having Hammer serve as a kind of configuration UI system for it, allows experienced developers the flexibility to continue to work using the tools and workflows they are already comfortable with (and which are rapidly becoming convention in a great many places). The obvious ramification of making this decision is that it restricts choice – This could be seen as a bad thing but, in reality, its not going to be possible to please everyone with a piece of software like this. Using webpack under the surface essentially counts out enabling non-js-based generators and tools such as Hugo (I am aware that there are projects to bind Hugo and Webpack together, but the main Hugo binary is still Go, and will stay that way). Restricting user choice and going instead for some level of convention makes for a more polished user experience in general. There will always be other tools, and there will always be tools that aren’t compatible with others. That’s just a fact of the web dev community. I would focus on a few tools and conventions you like, and concentrate on making the best experience possible for them. People who share your opinions will be happy to use the app, others will go a different way. Such is life.

  3. Re: Benefits of command-line tools – I think a lot of this comes down to configurability and flexibility over a pretty UI and low barrier to entry. You’re dealing in a tough market here; front-end developers are more comfortable than ever with the command line, and many have been regularly using command-line tools for a number of years now. You would probably have to present a pretty compelling argument to these people to convince them to move away from the (free) tools they are perfectly comfortable with and over to a (paid) app with a pretty UI. There are other little tools around that some of us use on a regular basis, too, such as Hotel, which allows for binding of command-line tooled websites to local domains easily and without the need to manually start up the project when you want to work on it. That’s pretty useful functionality to consider including.

  4. You forgot Vue.js :wink:

  5. What if the right way to go with Hammer is to fundamentally change the way it works? Local development is great and all, but it has its bugbears. What if the right thing to do is to leverage some of the infrastructure that you already have in place with Forge and make a product that moves developers’ local development builds to the cloud, with zero (or near-zero) configuration? These development servers can be secured for access only from a particular network (based on where Hammer connections are originating), or with username/password from outside. A front-end focused tool is going to be updating mostly very small files, and mostly one or two at a time after initial deployment, meaning a relatively seamless experience with a remote dev box should be easily achievable. Moreover, moving to a service-led business model like this, with a supporting desktop companion app for configuration, monitoring etc, justifies the repeated subscription pricing to a greater degree than a standalone app does. Engineering the system to work with multiple users on the same project won’t be without its challenges, but if development hosts are set up on a per-user basis, and existing Git flows are used to manage syncing of changes between team members, you don’t have to worry about that particular issue.

Just a few thoughts. You’ve probably already had most of them and have them covered or dismissed somewhere, but I thought I would put my £0.02 in now, just in case there are ideas in there that you haven’t had yet. I’ve long been a user of various products from your catalogue, although I moved away from Hammer in favour of the aforementioned command line tools some time ago, and I would like to see continued success from the team.

Good luck to you on the next leg of this journey. I’m always happy to talk and bounce around ideas etc should you want to.




Great reaction Dave! Thanks for the detailed response.

Re: .dev domains for local development – This is no longer a good practise owing to Google buying up the .dev tld and forcing it over https in their newer versions of Chrome.

Good point…

Sums it up pretty well, I think. You can’t please everyone, but we can make a great product better for more people whilst giving ourselves a better chance of supporting that tool long term.

I think that’s the wrong approach anyway, it’s more how many people aren’t leveraging these tools because of the barriers to entry posed by command line tools. None of these tools have reached market saturation, designers will code more, the landscape will evolve.

Shit! Amended.

I have something like this in mind, not moving entirely away from local, far from it - it has to work locally, I believe, to be fully productive - when you’re on a train, working from the beach or countryside. But synchronisation is key.

I think the time is right for Git to be embedded in the system, much like Abstract.

Thank you David, it’s really appreciated!


Been meaning to write an update on this for a while…

I set the challenge for a couple of the guys in our team to start playing with some of these new ideas for Hammer. @rkolpakov and @bulbozaur took up the challenge wholeheartedly, I’m pleased to say and have already made great progress.


We decided to go down the javascript route, building the UI with Electron and React.js and a separate Engine, powered by Webpack.

Electron, though not the perfect solution, gave us the ability to rapidly prototype the UI for Mac, Linux and Windows platforms simultaneously. Electron also gives us a node.js runtime, of sorts, so we don’t need to worry (we thought) about accessing global node.js as a dependency.

In this regard, it’s pretty similar to the existing Hammer for Mac app architecture, where we have a native Mac client and a ruby based compiler engine.

We’ve now got to the point where we have both of these core elements developed sufficiently and brought together to validate the architecture, though it wasn’t without some difficulties. The Electron JS runtime is all well and good, but super difficult to debug issues with.

We are considering whether it wouldn’t make more sense to instead use node.js outside of Electron and bundle it as an executable, like we did with our early Coinstash app version, using the pkg binary compiler. Still deliberating…

Client App

To start with, we’re not thinking about the UI at all, so we’ve just kind of used the existing Hammer app design as a basis and have worked to get the fundamentals of the existing Hammer app in place.

Here’s what we’ve done so far…

As you can see, the app looks pretty familiar and already, the main features have been realised…


:white_check_mark: Create New Project

:white_check_mark: Edit Project details

:heavy_multiplication_x: Assign Existing Directory to new Project

:heavy_multiplication_x: Drag and Drop sort Projects List

:heavy_multiplication_x: Create project from Template

:heavy_multiplication_x: Delete project

Project Detail

:white_check_mark: Present Project directory

:white_check_mark: Select Text Editor

:white_check_mark: Present Build Directory

:white_check_mark: List Project files

:white_check_mark: Project File filters

:white_check_mark: Hammer Ignore options

:heavy_multiplication_x: Todos List Filter

:heavy_multiplication_x: Ignored Files List Filter

:heavy_multiplication_x: Errors List Filter

:heavy_multiplication_x: Open File from list in Browser

:heavy_multiplication_x: Reveal file in Finder / Explorer

:heavy_multiplication_x: Open File from list in Text Editor

Export, Deployments & Hosting

:white_check_mark: preview service

:white_check_mark: Forge production hosting service

:white_check_mark: Export Build directory as .zip archive

New Project

Select Text Editor

Hammer Ignore

New Feature - GIT Built In

One of the things I am very keen to enable, in pursuit of better collaboration options for teams and improved workflows all round, is a simple GIT interface within Hammer.

We’ve been working on a technical proof of concept, again to reiterate, without much attention to the UI just yet.

Here’s a look at how the flow might work in the new Hammer app.

Clicking on the GIT icon in the Projects list, you can access the GIT view for your specific site.

No GIT repository initialised

So to initialise our Project with GIT, we just hit the Init button.

Now we can see our Project’s files listed in the Stage area, ready to be added to a commit.

I can select all of the files by clicking the Not Added button, or select individual files. I’ve added all of them with one click.

Now it’s time to make my first commit on the Project, adding all of these files. Click the Commit button and add a message like "Initial Commit"

Having Committed these files, the Master branch is automatically created and selected for us.

The Stage tab is now clear as there are no changes to files and so nothing further to commit for now… If I click on the Log tab, however…

We can see our initial commit has been made.

Now we want to make further changes…

Time to create a new Branch…

I then can open my text editor and make my changes. In this case I’ve made a simple text change in index.html. When I save this file, I can see that index.html is now visible in the stage tab, ready to be committed.

I have selected the index.html then head to Commit button and add my message like before…

And voila, my latest commit to the new features/new-feature branch is successfully logged.

Next, I may want to Merge this into Master… and for now this is where our journey ends, as we’re still working on some of the more advanced GIT commends :slight_smile:

But what do you think so far?? Pretty neat, huh?


Everything you saw above was all screenshot from my Macbook Pro. Yawn. Hammer’s always been Mac. That’s not new…

Well, what about this?

A sneak peak of Hammer running on my Windows 10 Machine.

Engine Functionalities

The features don’t end there, my friends! We haven’t even talked about the new Webpack-based Engine.

Aside from the initial focus on the actual architecture and getting the Engine to play nice inside the client app / Electron environment, @rkolpakov and @bulbozaur have been busy adding initial support for all the baseline Hammer features.

Hammer Tags

What would hammer be without it’s core syntax for supercharging your HTML, CSS and javascript.

:white_check_mark: Includes e.g. <!-- @include _header.html -->

:white_check_mark: Clever Paths e.g. <!-- @path icons.png -->

:white_check_mark: Variables e.g. <!-- $foo bar --> <p><!-- $foo --></p>

:white_check_mark: Auto-reload - this is now enabled by default!

:white_check_mark: Todos e.g. <!-- @todo Rewrite all of this -->

:white_check_mark: Image Placeholders e.g. <!-- @placeholder 300x400 -->

:white_check_mark: Stylesheets e.g. <!-- @stylesheet normalize main -->

:white_check_mark: Javascript e.g. <!-- @javascript jquery main -->

Template Engines

Existing Hammer for Mac supports, in addition to the default HTML, the popular ruby-based templating languages HAML and Slim.

Well, now that we are in Javascript land, it means that the new template language of choice will be something like Jade, very similar in many ways to Slim, and we’ve already added a Jade loader to the engine.

What about all my old Hammer projects written in Slim and Haml?

Good question! Well, the good old JS community has created Webpack loaders for Slim and Haml, so we’re including them too. There’s a bit of a question mark about the long term support of these libraries, but they seem to work ok and I’m keen on ensuring backwards compatibility.


Of course the plan is to support the existing SASS and Coffeescript pre-compilers that existing Hammer provides. We’re having some issues with cross-platform compatibility of lib-sass but I’ll let @rkolpakov explain more about that if anyone is interested.

In theory, it also means that it would be more straightforward to also support Stylus, LESS etc. but we also like PostCSS and would be planning broad support for PostCSS going forward.

Overall it’s been a really great start to some exploratory work for the future Hammer and I’m really excited to see where it leads. I’m very excited that the tool already looks to be a more effective options for teams that want to use the Hammer workflow and can do so regardless of which OS the individuals choose to use and with industry standard version control through GIT.

The team of myself, @rkolpakov and @bulbozaur, along with wider input from @boris know that this is just the tip of the iceberg and we’ve got some great new ideas that I’ll be sure to share and explore in later posts…

We publish and share builds internally on a weekly basis, if you’d like to join the distribution list and get involved at this raw and early stage, helping with testing, debugging and ideas, let me know and I’ll see how I can manage it…



We paused the work on the new Hammer for a while whilst we were busy on some large client projects, but we’re back and keen to get an initial version out into your hands.

Here’s some of what I think are needed to make this happen and will drive us forward in the next product sprints.

New Hammer GUI

The New Hammer will be Dark Mode enabled by default.

Animations & Interactions

This early version requires attention to some interaction details, animations - such as loading states and progress bars, etc.

Projects & Environments

In-line with new features we’re adding to Forge, we’re moving away from a rather restrictive single site model, to a more flexible and more realistic for real-world team use, a Projects & Environments model that enables you to have multiple sites in a project and different environments mapped to your deployment & hosting process.

In the context of Hammer, I’m still to settle on exactly how this will work, but I feel like User will assign a Git branch to an environment (if using Git) or they will just have one master code source and the environment will be mapped to a Hosting destination (if not using Git, we wont be managing versions using environments alone, that would be urgh).


We are re-architecting our backend APIs across our products, and as part of this, we will have a single identity system and account for all Beach Products, which will also simplify User account managements, subscriptions and billing. It will also really help us to improve support and new options for you (more on that to come).

Cloud Sync

As we move to the new backend, we will also be enabling you to sync your local projects, sites and git repos to our Cloud Service, so that they are accessible from whichever device you are logged into Hammer on and fellow collaborators also have access to the same files, backed up by the Git version control system. replaced by Forge

Instead of two separate hosting services, we will consolidate this into one. Hammer users will have access to Forge’s hosting service and the Dev environment will replace the

Further Improvements to Git process

We need to find a balance between the power of Git and the basics needed for effective Git workflows between collaborators. I really like the way Abstract handles this in it’s branching controls and we’re not there yet.

New Feature MVP’s

NPM / Yarn Modules

Easy option to search & browse modules and add them to your projects.

Chisel CMS Integration

Ability to easily map content types from Chisel into your static projects and create Headless CMS driven content sites using static site technology.