This should probably be retitled; after playing with it for a bit BrowserCMS is really nothing like Drupal, nor is it meant to be a Drupal clone. Instead, it's a powerful general-purpose CMS that will easily manage both static and dynamic content. If you've looked at Radiant but thought it was too simple, take a look at this.
Most web design shops which build websites for clients will end up using some form of Content Management System, to allow those clients to maintain the site after launch. BrowserCMS is a solution to our firm's problem, which is wanting the productivity of Rails for building custom websites, but giving clients Web CMS tools to maintain the site after launch.
I'm the product manager for BrowserCMS, so hopefully I can shed some light on the 'whys' behind the project. It is certainly not to clone Drupal in Rails. Drupal is mentioned in the presentation because many developers are familiar with it, so the enviable first question I hear is 'How is BrowserCMS like Drupal?'.
Our intent with BrowserCMS is to provide a client friendly CMS. Making a site maintainable and understandable by non-technical users is the primary goal of the CMS. We also want to allow Rails developers to be able to customize sites. We do have a module system (different than Drupal's), which allows developers to build custom modules (News, Events Calendars, Blog, etc). The dynamic content can be placed by non-technical users on pages. Obviously, it's a new project though (still in Beta), so we are about ~4500 modules behind Drupal here.
It will take me some time to watch this. Anyone able to summarize right now why this thing is like Drupal?
("It's a CMS" is not enough. The word "CMS" has many meanings. And Drupal is arguably a CMS, but it is a specific flavor of CMS. For example: Does BrowseCMS have a module system reminiscent of Drupal's?)
So here's the thing: Rails plugins are for programmers. I'm no Rails expert, but I've never encountered a Rails plugin that was configurable without using Ruby. (Which is, of course, perfectly in line with Rails design goals and philosophy.)
The majority of Drupal modules are designed to be used without writing a single line of PHP code. (This is not to say that Drupal developers don't end up writing PHP code anyway... or that this design philosophy doesn't often lead to unusable confusion, or that it doesn't entail some big compromises, of which the tendency to have code stored in the database is one of the most annoying. But I have seen quite impressive Drupal sites built by people who refuse to touch PHP. That's a big selling point.)
So, no: This isn't Drupal. But we are getting there!
"Drupal works, lets rewrite it in Rails." Other than serving as a thought experiment on a grand scale where is the perceived benefit of trying to implement the feature set of an existing CMS in a slower language? Is this an example of language preference taking to an extreme or are there concrete benefits to this approach?
Ironically, the current version of Ruby (that is, 1.9.1) is faster than PHP by a good bit. So, actually they're re-implementing it in a faster language.
Whose language is slower, again? Show me the real-world benchmarks!
(If those results are true, and Yehuda didn't forget to carry a two or something, the people who you should be questioning are the inventors of CakePHP.)
It might be a mistake to assume actual FUD when simple ignorance is more likely the cause, and it was in this case, which is why I posted the question to begin with.
Yes. I didn't see a lot of equivocation there, so I didn't supply a lot in return. I apologize.
And I'm sorry if I have lost all patience with phrases of the form X is a slower language than Y. These catchphrases are everywhere, major technical decisions are often based on them, and they are often worthless. They are overgeneralizations.
To make such a statement meaningful, the least we need to know is: What problem did you try to solve? What languages did you compare? What frameworks, compilers, interpreters, libraries, helper applications, and/or platforms did you use? Can we see your code? And what are the numbers?
As Yehuda points out, when you leave these things out you end up with mindless 1-D generalizations like "Ruby is slow; ergo, all systems which have Ruby in them somewhere are slow". Which you never question or test. And then you mislead everyone. You even mislead yourself! And even if you happen to be correct, for a given problem on a given day, things can change by next week. For example: the Javascript interpreter folks are working wonders, speeding certain computations up by orders of magnitude. (The Chrome JS interpreter nearly made me weep with pure joy.)
I don't see how we're going to break people of this bad habit except by correcting them, one by one if necessary. We certainly won't learn from history: We went through all of this with Java, less than a decade ago. Java was famous for being "slow", until one day everyone realized that it wasn't "slow" anymore and that it hadn't been for a couple of years. Now people hold up the JVM as the canonical example of a fast thing! (And C, of course, is always assumed to be extra-fast -- as if every C routine in the world were written by Knuth himself, in flawless bug-free form, with optimum algorithms.)
All good points. I agree with the overgeneralizations, and usually just skip right over such simple statements.
Sounds like if you edited this comment, toned things down a bit, and added a solid conclusion, it'd make a good blog post. And a good starting point for informing discussion.
I see no need for an apology here. I should be the one apologizing for a poorly written comment. Fortunately it appears some good discussion has come of it.
If you've every worked with any large scale Drupal deployments, you'll know that its module system doesn't scale very well in terms of maintainability. You basically end up with thousands of functions in the global namespace with little to no abstractions. Rails and Ruby in general are well known for their syntactic sugar, allowing for more clear and maintainable code.
I have worked pretty extensively with Drupal and I don't agree with your assertion that the module system has maintainability issues. Performance issues, absolutely, but it's quite maintainable.
Any namespace issues are largely dealt with by naming conventions such as prefixing function names with the module name. For the 'hooks' that connect modules to the rest of Drupal this is compulsory. You can structure your own code pretty much however you want including using classes or whatever php allows etc.
So while it isn't perfect I don't see it getting in the way too much of module development. You could of course argue that Drupal would be more extensible if it did use OO or some other paradigm but I see that as a slightly different issue.
Grab the source at http://github.com/browsermedia/browsercms.