Rails Rumble Winners - Gem Teardown(dwellable.com)
dwellable.com
Rails Rumble Winners - Gem Teardown
http://www.dwellable.com/blog/Rails-Rumble-Winners-Gem-Teardown
29 comments
Never making invalid markup is handy, and if you have easy access to attributes you can:
.a_class{ attrs } some text
<div class="a_class" attr="value" another="val" dont="forget to escape"> some text </div>
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.
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.
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:
@{
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 :)
@{
// 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 :)
https://github.com/stonean/slim#benchmarks
Slim is mentioned in the writeup. It's faster than Haml. I like it better.
Slim is mentioned in the writeup. It's faster than Haml. I like it better.
<%= content_tag :div, "some text", class: 'foo', html: attrs %>
Nice breakdown. Just a critique, I'm willing to bet that people were using therubyracer to compile CoffeeScript.
Actually, the twitter-bootstrap-rails[1] gem requires therubyracer[2] in order to compile LESS -> CSS.
[1] https://github.com/seyhunak/twitter-bootstrap-rails
[2] https://github.com/cowboyd/therubyracer
[1] https://github.com/seyhunak/twitter-bootstrap-rails
[2] https://github.com/cowboyd/therubyracer
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.
Edit: 9=>6 per the blog post
Edit: 9=>6 per the blog post
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.
Seeing it listed in this way reminds me of all the moving parts in actually getting an app online.
I'm glad I finally (mostly) have a grip on it all but boy did it take a while.
I'm glad I finally (mostly) have a grip on it all but boy did it take a while.
I'm an organiser of Rumble. If the writers are reading this, I am sure we could try and work out more if they ever want to play with more metrics. :)
Author here. Sounds like fun, drop me an email (in my profile).
Nine out of the ten winning teams wrote their JavaScript in CoffeeScript? Wow, that's pretty incredible -- I would never have expected it.
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:
gem 'sass-rails'
gem 'coffee-rails'
gem 'jquery-rails'Rats. I was rooting for Uptilt:
http://uptilt.r12.railsrumble.com/
http://uptilt.r12.railsrumble.com/
You and me both! But there were some fantastic entries this year.
Why is beanstalk often looked over? Has anyone ha problems with it before? Or is it just marketing problems..
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.
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.
It is an awesome piece of software. If you like it, I would love for you to check out https://github.com/nesquena/backburner which is a resque inspired project powered by beanstalkd. There is a great sinatra admin tool as well https://github.com/denniskuczynski/beanstalkd_view
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.
Ah, sorry about that, I meant beanstalkd, the work queue.
This is great. I am putting my own list of gems from all the participants, I will list it once done.
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.
Isn't Devise older than OmniAuth?
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.