Very interesting information. Definitely going to have a look at a few gems after this. Thanks for sharing.
On a side note, HAML is the best example of technology for technologies sake. It adds a small amount of value while adding the complexity of a new language. I've never felt the "juice was worth the squeeze" so to speak. Curious as to why it has the following that it does.
Never making invalid markup is handy, and if you have easy access to attributes you can:
.a_class{ attrs } some text
which can save a lot when you would otherwise have to write:
<div class="a_class" attr="value" another="val" dont="forget to escape"> some text </div>
The never-invalid markup is probably the bigger win, though. Primitive type checking for your HTML is arguably better than none. What I would really like is something similarly terse but faster - HAML can get pretty slow.
I cannot say I have had many problems with incorrect HTML. Since using HAML, I have had tabbing issues, inline javascript issues, a new syntax to learn (and translate). The last one is my main issue. 80% of your time spent with HTML is in the browser, the mental translation is more of a tax than anything.
I have used HAML on three projects and it always feels like it gets in the way more than it helps.
On a couple big projects, I've generally liked it - since there's less boilerplate ("<>" and closing tags in particular) and the primary identifying bits (- or %ul or .class) are at the far left of each line, I can generally read things more quickly and more easily than e.g. straight HTML or ERB's <%= %>.
But that comes from rather extended use, I'm definitely not claiming it's the best. There are plenty of things I dislike about HAML, but it does mean I read less, and I spend quite a bit of time reading and writing view code.
Mind if I ask if you've done PHP programming? If you have, ERB's <% would seem to be a tax you've already paid.
I am from a dotnet background originally, only created one php app back in my school days. For me, it is less about liking ERB and more about preferring the medium I am working in (HTML). If I could pick anything, it would be razor. It is similar to ERB in that you use HTML, but the painful percent brackets are replaced by a single @. Code blocks are as follows:
@{
// code
}
another example:
<div>@user.Name</div>
It feels very natural to write and is simple to read/pickup. Now that microsoft has open sourced it, someone should make a version in ruby. Might be a good side project for me actually :)
It depends on how you integrate bootstrap: there's a SCSS conversion of Bootstrap that avoids the dependency on therubyracer, (it just requires sass):
https://github.com/anjlab/bootstrap-rails
Yes, I recognize that. Perhaps I didn't explain it clearly in the post. Nine of the teams used coffeescript, but only six used therubyracer. What did they use for js if not therubyracer? I'm guessing node.
I put this together yesterday, with help from the ten winning teams. It's kind of like the occasional HN post that looks at hosting decisions made by YC companies. Maybe I'm just a gems geek, but I find this sort of thing fascinating.
I would also throw out that the Rumble provided a server setup script that automatically used Capistrano and MySQL, so it would hurt your time a little had you not used what they provided. That may have skewed the deploy/database usage results a bit. The only reason I used MySQL was that I essentially got it for free through the setup script.
The CoffeeScript gem is included by default in new rails installs, and some js.coffee files are created, so you'd have to explicitly remove it - most people won't bother even if they are writing most of their js without it. The following gems are included by default, which perhaps makes the usage in these apps (done in a hurry) not very surprising:
I think part of it is a marketing and documentation issue. I have been working to help get beanstalk into a better place specifically around ruby tooling and overall documentation. Check out https://github.com/nesquena/backburner for my solution for a 'resque' inspired DSL for using beanstalkd. We are using it in multiple projects. Also, I have been working to improve the ruby beanstalk client. Expect more news soon.
I used Beanstalkd for a few years and I can testify that it's an awesome piece of software.
That said, that was before Resque and Sidekiq existed. I now use Sidekiq for my new project since I'd rather not reinvent the wheel. I suspect most people think the same way.
The collaboration and navigation tools of Beanstalk are not up to par, last I checked. The file browsers on GitHub and Bitbucket are very responsive. The "pull request" feature is extremely useful for managing large teams where features are being developed concurrently. Beanstalk's best feature is its automatic deployment, but you can duplicate this in a more powerful way with post-commit hooks or continuous integration processes.
jquery and bootstrap are great for putting together a rails app really quick, but I wish there was a better way that didn't add bloat. I find that jquery and bootstrap add significant download latency to a webpage even if they are gzipped.
On a side note, HAML is the best example of technology for technologies sake. It adds a small amount of value while adding the complexity of a new language. I've never felt the "juice was worth the squeeze" so to speak. Curious as to why it has the following that it does.