Great job. I'd recommend a design/UX overhaul though, it is quite antiquated. Check out some of the awesome "admin" designs on https://wrapbootstrap.com.
Before you enter the demo they say "(Read only! You'll get an error if you try to save anything. A complete and fully working example is included in the source distribution.)"
As someone that have worked in the CMS space for quite a while (and ended up implementing a couple from scratch) I welcome any new solutions that are not antiquated.
One thing that I've learned during that time (and does not apply only to CMS's but that the time I fully realized it) is that everything you build in your CMS should always keep in mind who is the main user and who is the main consumer. The first one I've developed focused on the consumers. And every content creator hated me sooooo much. I went back to the drawing board... no actually I sit with almost each editor and looked at how they bitched and tried to find workarounds. It was an eye opening experience.
CMS's are one of the easiest pieces of software to naively throw a beefy caching server in front of.
Not saying performance should never be a consideration, but for the vast majority of websites, especially "personal, small business, or small NGO websites" that should be all you really need.
The issue with most Unixy mail kits, is it's a collection of software that isn't always well coupled, and bundled together in really haphazard ways...
Many people want a simple interface that gives them administrative control (separate from physical accounts on the machine) that upgrades as a complete set...
With Unixy mail systems, you update dovecot, crap, something else breaks.. you have an older mysql backing it, crap, everything breaks when you upgrade... there's too many disconnected pieces for someone that isn't a full time mail admin to effectively keep up with.
I believe the original request is for something similar to say SmarterMail but open-source and free... something easy to setup, cross platform and packaged in a modern approachable language.... If I didn't have to work, I've often thought about doing something similar with Node.js
Yes, definitely. Try to set up the whole email pipeline in Linux/*BSD. You need dozens of programs including sendmail/postfix and each has its own config format. Many of these programs had their first release in the late 1970s or 1980s and probably no one understand every flag anymore. It's very time consuming (at least 4 hours) to config all packages.
How would a new implementation in Go help? It would be a clean break. Less features but a stable high performance implementation would be a win. Go is the ideal language for that task.
I love Go too, but I have to disagree with you about Postfix -- it was first released back in 1998, it has a very sane config file format, and it definitely does not take 4 hours to configure. Actually it only took me a couple of minutes last time I did it for a client.
Please don't mix up things. I wrote "You need dozens of programs including sendmail/postfix and each has its own config format." If you only send emails, you only need one application sendmail or a clone like postfix. (postfix was indeed created to fix some of the annoyance of sendmail) It's easy enough to set up. But if you need an inbox so that you can receive emails too, you need the whole bunch of applications that will require you to install craylists, antivirus (claimav), etc. - I doubt that this process takes you just a couple of minutes. Or do you work for an email hosting provider with a bunch of proprietary scripts?
Well, this was sort of what I was getting at: things like antispam and antivirus are plugins that are inherently high-configuration.
You could Apple-ise the process by making a single suite of software that installs as a unit and gives you a system that can receive inbound mail, store in a DB (ie, ditch mbox and maildir), make it available over IMAP, POP and some JSON API. Then all you'd have to do is give it a list of domains and users for those mail domains. That's the 80% solution. But I guarantee people will start campaigning for features which require configuration complexity.
Ah, I assumed you meant only the SMTP pipeline - my bad. But what you said was like saying setting up a Web site is hard because you need to deal with haproxy, nginx, hooking up recaptcha, implementing OAuth2 and so on. I don't think rewriting everything in Go is going to help.
I did work at an email service provider years ago though, so I concede I might be more familiar about email than most people.
> I don't think rewriting everything in Go is going to help.
I meant a single Go executable that provides most functionality of a common email server (SMTP, POP3, IMAP, inbox, web admin interface, webmail). (anti-virus, anti-spam, ... would still be external third party processes)
A Go executable would be easy to update and can be compiled for many platforms. Updating a unix style mail server with like a dozens of programs that call each other in a pipeline style way is non trivial - except you do it as your main work. The same goes for the configuration of each component so that everything works together.
Couldn't agree more and have considered building something similar in the past. Seems like such a gigantic project though.
I'd probably host my own mail if it were a matter of installing one server, hooking it up to a database (much prefer the idea of storing email in a database than mbox files) and giving it a few details. Even better if it came with a simple web interface for viewing email and for configuring.
I've set up mail servers in the past but I've always been left a bit uneasy, as if there's a possibility I've not quite set it up right.
I did write an SMTP and POP3 server to learn Go a while ago - I was still learning the language, so the code is messy and terribly designed, but it works for receiving and reading emails. Together with a sendmail wrapper, I have been using it instead of postfix/dovecot due to my naiveness to write postfix config files:
For "heavy" stuff that requires indexing (and where indexing using directories doesn't fit), Monsti might use a technology like Xapian. It might even use a database for this. But always on top of the "real" data that stays on the filesystem. But it's not impemented yet and plans might chance.
Recently I've noticed a kind of a strange fashion in the way of advertising new software projects on HN.
The most important information is not what cool things given project does, or what unique features it has but what programming language it is using.
There is a lot of posts "New blog engine in Clojure", "Amazing email server written in Haskell", "Text editor in ECMA Script version 9", etc.
Sometimes there is more to that: new project comes with better performance, easier code maintenance, clever algorithms used, novel architectural solution developed - stuff that really matters, but Monsti is an pathological example.
The first sentence on their web page says that it is written in Go, as if it mattered for their potential audience, that is "personal, small business, or small NGO websites".
Why should I choose Monsti over Wordpress? Is the installation easy? Does it work on a cheap website hosting? Can it survive Slashdot effect on that cheap hosting? How about comments spam protection? Is creating templates/themes super easy, maybe I can reuse the ones created for Tumblr? And so on.
Programmers might want to know if the GO API is particularly well designed or maybe we can create hooks to customize some functionality or maybe there is some utility to monitor Monsti site statistics.
Who cares that this stuff is written in Go and WordPress in non-fashionable PHP, while the latter offers something that is actually important for programmer, admin and site owner?
It's because it's "Hacker News". The main audience here is hacker types who care about language. The main people to target with an open-source CMS, or with an email server or blog engine or whatever is the people who are going to want to hack it, and actually get involved in the project. Finding new contributors is really hard and important in a new open source project, and so advertising to find the kind of people who'd be interested in actually helping to write it is very important.
Once a project is big enough, then sure, drop the language stuff down to page 3 or whatever. But until you've got a community of passionate developers, it's a key concern.
A couple of years ago, we moved off of wordpress precisely because it was written in php. Once you're trying to do anything reasonably complex in a CMS, the architecture and the programming language matter, because you have to extend the CMS in some manner. For us, wordpress wasn't extensible enough - and php wasn't pleasant enough - to justify continued use of it. I imagine people in a similar position who want to use Go would give this a serious look.
I'm not. We weren't fans of php either. Even if you buy into the philosophy that all languages are technically equal, that still doesn't make them pragmatically equal.
It was probably our network, but we had a very hard time finding good php engineers, and a much easier time finding good python engineers. So that won.
It's incredibly useful to know what language something is written in.
First and most important, a CMS almost never does what you want out of the box, so you're going to have to customize/extend it in whatever programming language it's written in.
Second, the language tells you a lot about the mindset, ecosystem, type of design that you're likely to encounter when reading the code or even using the product.
Third, the language gives a lot of hints about the deployment environment you're likely to need. Java is going to need JVMs and people who know how to deploy and tune them. C# is going to need Windows, or someone experienced with Mono. Python/Ruby/PHP/etc. are going to need runtimes and pip/rvm/whatever. Go or C/C++ are likely to have simpler binaries, statically-compiled in the case of Go.
And fourth, as has been said better in another comment, this is hacker news. We're hackers. We like our programming languages, so we care. :-)
I should write a definitive blog post about this, and get it ranked on hacker news, just to defuse the "why is hacker news always saying 'in go' on story titles?" questions.
Valid points. The customer shouldn't care if it's two tin cans and a piece of string, but developers do, and that's why I watch HN. Frameworks are where the innovation is at, and Go is a relatively new language with few frameworks. So, I am very interested in frameworks around new languages that speed development and facilitate good design and maintainability. I keep my eye out for Go and Elixir framework innovation, so I find these types of posts very useful.
Go tells me that it's likely one self-contained portable executable. While wordpress and other php solutions can require quite a few dependencies. Saying it's 'easy to install' can be misleading. Some peoples definition of easy to install is curl | sudo bash or run this chef cookbook. Which actually tells me that the installation is so complex that it couldn't be done in a typical package manager.
Monsti is not WordPress and can't replace it. In fact, I use WordPress for my clients and Monsti for experimental projects only. And I like WordPress being so damn user friendly. But its implementation just sucks. Which matters for clients if I need more time do develop new functionality (Most WordPress plugins suck compared to WordPress core). And its slow and hard to maintain (especially if you use plugins).
Beware that Monsti is still in an early stage of development. The main reason to be interested in it is that it is written in Go. And that it is resource friendly and fast. I wrote it because the last Python-CMS I used consumed some hundreds of megabytes of memory for one simple site, and I could not run more that one site in parallel (in the same interpreter) because of it and some Python libraries using globals and monkey patching.
Can anyone explain the significance of the @@ characters in some of the urls here? I've not seen these in urls before and wonder if there's a specific reason why they're there.
That's the case. Monsti is influenced by Kotti which is influenced by Plone which is based on Zope which uses @@ for "actions" (or whatever they call them). Monsti uses @@ to distinguish actions from regular URLs.
46 comments
[ 4.2 ms ] story [ 94.7 ms ] threadOne thing that I've learned during that time (and does not apply only to CMS's but that the time I fully realized it) is that everything you build in your CMS should always keep in mind who is the main user and who is the main consumer. The first one I've developed focused on the consumers. And every content creator hated me sooooo much. I went back to the drawing board... no actually I sit with almost each editor and looked at how they bitched and tried to find workarounds. It was an eye opening experience.
I wish I could come up with such cute logos for my side projects. Would make life all the more interesting :D
- What is the memory and cpu usage when you get something like 500+ concurrent users?
Not saying performance should never be a consideration, but for the vast majority of websites, especially "personal, small business, or small NGO websites" that should be all you really need.
I always hate how complicated and time consuming the configuration is of the good old postfix and the various other packages.
[1]: https://www.opensmtpd.org
The issue with most Unixy mail kits, is it's a collection of software that isn't always well coupled, and bundled together in really haphazard ways...
Many people want a simple interface that gives them administrative control (separate from physical accounts on the machine) that upgrades as a complete set...
With Unixy mail systems, you update dovecot, crap, something else breaks.. you have an older mysql backing it, crap, everything breaks when you upgrade... there's too many disconnected pieces for someone that isn't a full time mail admin to effectively keep up with.
I believe the original request is for something similar to say SmarterMail but open-source and free... something easy to setup, cross platform and packaged in a modern approachable language.... If I didn't have to work, I've often thought about doing something similar with Node.js
Yes, definitely. Try to set up the whole email pipeline in Linux/*BSD. You need dozens of programs including sendmail/postfix and each has its own config format. Many of these programs had their first release in the late 1970s or 1980s and probably no one understand every flag anymore. It's very time consuming (at least 4 hours) to config all packages.
How would a new implementation in Go help? It would be a clean break. Less features but a stable high performance implementation would be a win. Go is the ideal language for that task.
You could Apple-ise the process by making a single suite of software that installs as a unit and gives you a system that can receive inbound mail, store in a DB (ie, ditch mbox and maildir), make it available over IMAP, POP and some JSON API. Then all you'd have to do is give it a list of domains and users for those mail domains. That's the 80% solution. But I guarantee people will start campaigning for features which require configuration complexity.
I did work at an email service provider years ago though, so I concede I might be more familiar about email than most people.
I meant a single Go executable that provides most functionality of a common email server (SMTP, POP3, IMAP, inbox, web admin interface, webmail). (anti-virus, anti-spam, ... would still be external third party processes)
A Go executable would be easy to update and can be compiled for many platforms. Updating a unix style mail server with like a dozens of programs that call each other in a pipeline style way is non trivial - except you do it as your main work. The same goes for the configuration of each component so that everything works together.
I'd probably host my own mail if it were a matter of installing one server, hooking it up to a database (much prefer the idea of storing email in a database than mbox files) and giving it a few details. Even better if it came with a simple web interface for viewing email and for configuring.
I've set up mail servers in the past but I've always been left a bit uneasy, as if there's a possibility I've not quite set it up right.
http://github.com/trapped/gomaild
https://github.com/flashmob/go-guerrilla
Edit: The two hard things about writing email servers are that its incredibly boring and there is a lot to write.
By the way, there is a rather popular static site generator written in Go: http://gohugo.io/
I'm the creator, I hope it's OK to post it here. It seems fitting.
Filesystems are the new database.
So does this CMS support search?
How does it manage permissions?
I found the docs to be a little light on details. I guess that will change in time.
The most important information is not what cool things given project does, or what unique features it has but what programming language it is using.
There is a lot of posts "New blog engine in Clojure", "Amazing email server written in Haskell", "Text editor in ECMA Script version 9", etc.
Sometimes there is more to that: new project comes with better performance, easier code maintenance, clever algorithms used, novel architectural solution developed - stuff that really matters, but Monsti is an pathological example.
The first sentence on their web page says that it is written in Go, as if it mattered for their potential audience, that is "personal, small business, or small NGO websites".
Why should I choose Monsti over Wordpress? Is the installation easy? Does it work on a cheap website hosting? Can it survive Slashdot effect on that cheap hosting? How about comments spam protection? Is creating templates/themes super easy, maybe I can reuse the ones created for Tumblr? And so on.
Programmers might want to know if the GO API is particularly well designed or maybe we can create hooks to customize some functionality or maybe there is some utility to monitor Monsti site statistics.
Who cares that this stuff is written in Go and WordPress in non-fashionable PHP, while the latter offers something that is actually important for programmer, admin and site owner?
Once a project is big enough, then sure, drop the language stuff down to page 3 or whatever. But until you've got a community of passionate developers, it's a key concern.
IMHO.
It was probably our network, but we had a very hard time finding good php engineers, and a much easier time finding good python engineers. So that won.
First and most important, a CMS almost never does what you want out of the box, so you're going to have to customize/extend it in whatever programming language it's written in.
Second, the language tells you a lot about the mindset, ecosystem, type of design that you're likely to encounter when reading the code or even using the product.
Third, the language gives a lot of hints about the deployment environment you're likely to need. Java is going to need JVMs and people who know how to deploy and tune them. C# is going to need Windows, or someone experienced with Mono. Python/Ruby/PHP/etc. are going to need runtimes and pip/rvm/whatever. Go or C/C++ are likely to have simpler binaries, statically-compiled in the case of Go.
And fourth, as has been said better in another comment, this is hacker news. We're hackers. We like our programming languages, so we care. :-)
I should write a definitive blog post about this, and get it ranked on hacker news, just to defuse the "why is hacker news always saying 'in go' on story titles?" questions.
Beware that Monsti is still in an early stage of development. The main reason to be interested in it is that it is written in Go. And that it is resource friendly and fast. I wrote it because the last Python-CMS I used consumed some hundreds of megabytes of memory for one simple site, and I could not run more that one site in parallel (in the same interpreter) because of it and some Python libraries using globals and monkey patching.
Example: http://demo.monsti.net/@@login