What is Middleman and what are its top alternatives?
Top Alternatives to Middleman
- Jekyll
Think of Jekyll as a file-based CMS, without all the complexity. Jekyll takes your content, renders Markdown and Liquid templates, and spits out a complete, static website ready to be served by Apache, Nginx or another web server. Jekyll is the engine behind GitHub Pages, which you can use to host sites right from your GitHub repositories. ...
- Hugo
Hugo is a static site generator written in Go. It is optimized for speed, easy use and configurability. Hugo takes a directory with content and templates and renders them into a full html website. Hugo makes use of markdown files with front matter for meta data. ...
- Rails
Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern. ...
- Gatsby
Gatsby lets you build blazing fast sites with your data, whatever the source. Liberate your sites from legacy CMSs and fly into the future. ...
- VuePress
A minimalistic static site generator with a Vue-powered theming system, and a default theme optimized for writing technical documentation. It was created to support the documentation needs of Vue's own sub projects. ...
- Hexo
Hexo is a fast, simple and powerful blog framework. It parses your posts with Markdown or other render engine and generates static files with the beautiful theme. All of these just take seconds. ...
- Astro
It is a new kind of static site builder that delivers lightning-fast performance with a modern developer experience. It combines decades of proven performance best practices with the DX improvements of the component-oriented era. Use your favorite JavaScript framework and automatically ship the bare-minimum amount of JavaScript—by default. ...
- Gridsome
Build websites using latest web tech tools that developers love - Vue.js, GraphQL and Webpack. Get hot-reloading and all the power of Node.js. Gridsome makes building websites fun again. ...
Middleman alternatives & related posts
- Github pages integration74
- Open source54
- It's slick, customisable and hackerish37
- Easy to deploy24
- Straightforward cms for the hacker mindset23
- Gitlab pages integration7
- Best for blogging5
- Low maintenance2
- Easy to integrate localization2
- Huge plugins ecosystem1
- Authoring freedom and simplicity1
- Build time increases exponentially as site grows4
- Lack of developments lately2
- Og doesn't work with postings dynamically1
related Jekyll posts
I've heard that I have the ability to write well, at times. When it flows, it flows. I decided to start blogging in 2013 on Blogger. I started a company and joined BizPark with the Microsoft Azure allotment. I created a WordPress blog and did a migration at some point. A lot happened in the time after that migration but I stopped coding and changed cities during tumultuous times that taught me many lessons concerning mental health and productivity. I eventually graduated from BizSpark and outgrew the credit allotment. That killed the WordPress blog.
I blogged about writing again on the existing Blogger blog but it didn't feel right. I looked at a few options where I wouldn't have to worry about hosting cost indefinitely and Jekyll stood out with GitHub Pages. The Importer was fairly straightforward for the existing blog posts.
Todo * Set up redirects for all posts on blogger. The URI format is different so a complete redirect wouldn't work. Although, there may be something in Jekyll that could manage the redirects. I did notice the old URLs were stored in the front matter. I'm working on a command-line Ruby gem for the current plan. * I did find some of the lost WordPress posts on archive.org that I downloaded with the waybackmachinedownloader. I think I might write an importer for that. * I still have a few Disqus comment threads to map
Earlier this year, I migrated my personal website (dzello.com) from Jekyll to Hugo. My goal with the migration was to make the development environment as pleasant as possible and to make it really easy to add new types of content. For example, I knew I wanted to add a consulting page and some portfolio-style pages to show off talks I had given and projects I had worked on.
I had heard about how fast Hugo was, so I tried it out with my content after using a simple migration tool. The results were impressive - the startup and rebuild times were in milliseconds, making the process of iterating on content or design less cumbersome. Then I started to see how I could use Hugo to create new page types and was very impressed by the flexibility of the content model. It took me a few days to really understand where content should go with Hugo, but then I felt very confident that I could create many different types of pages - even multiple blogs if I wanted - using a consistent syntax and with full control of the layouts and the URLs.
After about 6 months, I've been very happy with the results of the migration. The dev environment is light and fast and I feel at ease adding new pages and sections to the site.
- Lightning fast47
- Single Executable29
- Easy setup26
- Great development community24
- Open source23
- Write in golang13
- Not HTML only - JSON, RSS8
- Hacker mindset8
- LiveReload built in7
- Gitlab pages integration4
- Easy to customize themes4
- Very fast builds4
- Well documented3
- Fast builds3
- Easy to learn3
- No Plugins/Extensions4
- Template syntax not friendly2
- Quick builds1
related Hugo posts
There’s no doubt WordPress is a great CMS, which is very user friendly. When we started the company, our blog wasn’t really our top priority, and it ended up being hosted on a fairly obscure server within our setup, which didn’t really change much until recently when things become harder to manage and make significant updates.
As our marketing team increased, the amount of traffic that found us through our content marketing increased. We found ourselves struggling to maintain our Wordpress install given the amount of theme updates, plugins and security patches needing to be applied. Our biggest driver to find an alternative solution however was just how slow Wordpress is at serving content to the end user. I know there will be die hard fans out there with ways to set things up that mean WordPress sites can load quickly, but we needed something a lot more streamlined.
We could see in our own Real User Monitoring tool that many users were experiencing page load speeds of over five seconds, even longer in worst case scenarios. Hugo is an open source static site generator that has enabled us to reduce load times by over 500% and make our blog far more maintainable across the whole team.
The Raygun marketing site runs on a .NET CMS called N2 but we plan to swap that out with Hugo as well in future.
#StaticSiteGenerators #SelfHostedBloggingCms #SupportSalesAndMarketing
Earlier this year, I migrated my personal website (dzello.com) from Jekyll to Hugo. My goal with the migration was to make the development environment as pleasant as possible and to make it really easy to add new types of content. For example, I knew I wanted to add a consulting page and some portfolio-style pages to show off talks I had given and projects I had worked on.
I had heard about how fast Hugo was, so I tried it out with my content after using a simple migration tool. The results were impressive - the startup and rebuild times were in milliseconds, making the process of iterating on content or design less cumbersome. Then I started to see how I could use Hugo to create new page types and was very impressed by the flexibility of the content model. It took me a few days to really understand where content should go with Hugo, but then I felt very confident that I could create many different types of pages - even multiple blogs if I wanted - using a consistent syntax and with full control of the layouts and the URLs.
After about 6 months, I've been very happy with the results of the migration. The dev environment is light and fast and I feel at ease adding new pages and sections to the site.
- Rapid development856
- Great gems652
- Great community606
- Convention over configuration484
- Mvc417
- Great for web348
- Beautiful code343
- Open source310
- Great libraries270
- Active record261
- Elegant108
- Easy to learn90
- Easy Database Migrations88
- Makes you happy82
- Free75
- Great routing62
- Has everything you need to get the job done54
- Great Data Modeling41
- MVC - Easy to start on38
- Beautiful38
- Easy setup35
- Great caching26
- Ultra rapid development time25
- It's super easy22
- Great Resources17
- Easy to build mockups that work16
- Less Boilerplate14
- Developer Friendly7
- API Development7
- Great documentation6
- Easy REST API creation5
- Quick5
- Intuitive4
- Great language4
- Haml and sass4
- Easy to learn, use, improvise and update4
- Metaprogramming2
- It works2
- Jet packs come standard2
- Easy and fast2
- Legacy2
- It's intuitive1
- Convention over configuration1
- Easy Testing1
- Cancan1
- Too much "magic" (hidden behavior)24
- Poor raw performance14
- Asset system is too primitive and outdated12
- Heavy use of mixins6
- Bloat in models6
- Very Very slow4
related Rails posts
Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.
But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.
But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.
Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.
StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.
Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!
#StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit
Gatsby
- Generated websites are super fast28
- Fast16
- GraphQL15
- Progressive Web Apps generation10
- Easy to connect with lots of CMS via official plugins9
- Reusable components (React)9
- Allows to use markdown files as articles7
- Static-sites5
- All the benefits of a static website + React+GraphQL5
- Images5
- List of starters as base for new project4
- Easy to connect with Drupal via official plugin3
- Open source3
- Gitlab pages integration1
- Incremental Build1
- No ssr6
- Very slow builds3
- Documentation isn't complete.3
- For-profit2
- Slow builds2
- Flash of unstyled content issues2
- Problematic between develop and build commands1
- Difficult debugging1
- Too many dependencies1
- Plugin driven development1
- Difficult maintenance1
related Gatsby posts
I was building a personal project that I needed to store items in a real time database. I am more comfortable with my Frontend skills than my backend so I didn't want to spend time building out anything in Ruby or Go.
I stumbled on Firebase by #Google, and it was really all I needed. It had realtime data, an area for storing file uploads and best of all for the amount of data I needed it was free!
I built out my application using tools I was familiar with, React for the framework, Redux.js to manage my state across components, and styled-components for the styling.
Now as this was a project I was just working on in my free time for fun I didn't really want to pay for hosting. I did some research and I found Netlify. I had actually seen them at #ReactRally the year before and deployed a Gatsby site to Netlify already.
Netlify was very easy to setup and link to my GitHub account you select a repo and pretty much with very little configuration you have a live site that will deploy every time you push to master.
With the selection of these tools I was able to build out my application, connect it to a realtime database, and deploy to a live environment all with $0 spent.
If you're looking to build out a small app I suggest giving these tools a go as you can get your idea out into the real world for absolutely no cost.
A few months ago we decided to move our whole static website (www.algolia.com) to a new stack. At the time we were using a website generator called Middleman, written in Ruby. As a team of only front-end developers we didn't feel very comfortable with the language itself, and the time it took to build was not satisfying. We decided to move to Gatsby to take advantage of its use of React , as well as its incredibly high performances in terms of build and page rendering.
- It's Vue4
- Created by the vue.js developers2
- Built in text search feature2
- Its Vue3
related VuePress posts
I want to build a documentation tool - functionally equivalent to MkDocs. The initial choice ought to be VuePress - but I know of at least one respectable developer who started with VuePress and switched to Nuxt.js. A rich set of "themes" is a plus and all documents ought to be in Markdown.
Any opinions?
- Ease of deployment18
- Uses NodeJS and npm13
- Easy GitHub Pages publishing12
- Powerful templating10
- Useful tools and plugins7
- Easy intergrating with js4
- Open source3
- Blazing Fast3
related Hexo posts
related Astro posts
Gridsome
- Vuejs16
- GraphQL10
- Starter kit as a base for new project6
- Reusable components (Vue)5
- Open source4
- Allows to use markdown files as articles3
- Static-sites3
- Generated websites are super fast2
- Blogging website2
- Webpack0
- Open source1
- Still young1