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 - 31,798
Hugo - 20,865
Hexo - 19,117
Gitbook - 16,724
Gatsby - 14,868
Nuxt - 7,564
Pelican - 7,400
Metalsmith - 6,354
Brunch - 6,230
Middleman - 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 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 ?
- 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.
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.
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?
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.