We are using server side handlebars in a backbone single page app rails project in a high traffic environment and we are finding that our rendering speed increased by 100%. We are using the sht_rails gem which appears to be well coded and simply handing off the rendering of the template to v8/execjs/rubyracer. After going live our GC increased a ton and we've tried various cacheing strategies to alleviate the issue but it's not going to work for us and we're about to bail on the idea of shared handlebars templates even though the benefits have been great from an seo/shared code standpoint.
Short of going with ruby ee, is there anything else we can do to fine tune/speed up this process? Or is it just the nature of the beast handing off strings to javascript serializing/deserializing and so on.
From our experiences it seems as though this server side rendering is not ready for production rendering. Anybody have any experience with this?
We ended up creating a node renderer service and handed the template rendering off to it instead of using the rails based ruby racer etc. Solved our problem for now. In the end it would have been nice to use node full stack to get better isomorphic support but we are a rails shop so this is where we are.
Related
Up to now I've always used PHP with or without a framework but a month ago I decided to start something new: Ruby and Rails, I found them quite easy and similar to PHP and some PHP frameworks in how they works but using a simpler syntax and many other advantages.
Some days ago I started reading about Node.js, Node.js vs Rails, "why node.js is better"...
I'm a bit confused but my objective is to learn something modern that will not become obsolete in a few months so:
What are the main differences between Rails/Ruby and Node.js and a framework based on it like Express.js (except that one is written in JS and the other in Ruby)?
What are the main advantages/disadvantages of using Node.js and framework based on it instead of a Ruby based solution like Rails?
Thanks!
There aren't enough differences between Node.js and Rails for it to practically matter.
A lot of what Node.js can do can be pulled off in Rails with things like EventMachine and Pusher. So unless you are really familiar with Rails' limitations, and know you'll be pushing the boundaries, you'd be hard pressed to make something a seasoned Rails developer couldn't do.
Having built apps in Node and Express I can say that they alone aren't enough to make a sexy application. They can seem just as old and stale if you don't have an outstanding frontend UI to facilitate the backend possibilities. Instead of comparing backend servers, I think the real future of doing amazing things is in front-end JavaScript frameworks like Backbone.js that use Express/Rails/Node.js on the backend.
I have chosen to go in the direction of Backbone.js with Rails as my backend API server. Because it's so easy to rapidly create a very nice RESTful backend server in Rails. Rails also makes working with CoffeeScript and precompiling/organizing Backbone code a breeze. There are already decent Backbone.js gems out there for Rails.
The Rails core is also able to acknowledge and embrace the fact that frontend JS MVCs are logically a good next step, and they have been working to strengthen the bond between the two. For those same reasons they have also worked to make Rails an even better API server so that it can work with frontend JS easier. Node.js and Express aren't putting as much effort to coordinate with frontend JavaScript MVCs as the Rails community is.
Being good with a JavaScript frontend MVC and Rails as a backend makes you also great for both worlds in terms of getting a job. You will easily be able to hop onto a Node.js project and add value to that team with your superior frontend experience, and you can also roll with the punches on a Ruby on Rails team and add value to them as well.
As official Node.js website explains it:
Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
On the other hand Ruby on Rails official website says:
Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.
Given this I guess that it is more appropriate to compare Ruby and Node.js, but even this is not quite right given that Ruby is programming language and Node.js is NOT. You could probably compare JavaScript with Ruby but I guess that is not what you meant to ask with this question :)
So, for me, key point in understanding what Node.js truly tries to accomplish is well described on Node.js about page. Key Node.js idea (for me) is described in this sentences:
Node is similar in design to and influenced by systems like Ruby's Event Machine or Python's Twisted. Node takes the event model a bit further—it presents the event loop as a language construct instead of as a library. In other systems there is always a blocking call to start the event-loop. Typically one defines behavior through callbacks at the beginning of a script and at the end starts a server through a blocking call like EventMachine::run(). In Node there is no such start-the-event-loop call. Node simply enters the event loop after executing the input script. Node exits the event loop when there are no more callbacks to perform. This behavior is like browser javascript—the event loop is hidden from the user.
What this should enable you, is that you should be able to easily write highly concurrent programs without even thinking about concurrency using JavaScript syntax and callback functions as basic concurrent runnable units.
Your fear that either Rails or Node.js will be gone in a week is unfounded. Rails has a large community and will be around for a very long time even though currently (early 2012) it's getting a bit of hate thrown its way. Node.js is just getting started and has so much attention I don't think it will have any problems getting to the Rails level some day.
That said I've been evaluating Node.js and Rails as options for a project and the reasons I choose Node.js over Rails are:
"The Rails Way" - In my (admittedly limited) experience with Rails it really seems like you either do it the Rails way or you are going to be in for a world of pain. A big part of the Rails way is to use the ActiveRecord model. The advantage of this is that there are a lot of gems that work with your code happily because they know you'll be using ActiveRecord. The disadvantage is you are mixing your data access & model. I am not a fan of this idea so the Rails way for me still seems a bit.. off.
JavaScript is a key part of client side web development and the idea of using it on the client and server is interesting. I'm not super strong at JavaScript and I can't imagine a better way to get better then to have to use it everywhere.
My project has real time communication needs which while I'm sure can be done in Rails there seems to be quite a bit of positive mention on Nodes ability to handle this with socket.io being the front runner option.
At the end of the day no matter which you choose you will have a great time & learn a ton of new stuff that will change how you write code. If you're not on a big time crunch I'd recommend building a small project management tool in both and see which you prefer.
Either way.. Good Luck!
2 things - performance & productivity.
Performance (more details here)
(source: jslang.info)
Productivity (how fast you can build that app)
Ruby on Rails is specialized and highly productive tool for creating so called Web 1.0 and Web 2.0 applications (99% of internet sites are such apps). In my subjective judgement and experience in this area Rails about 2-4 times more productive than node.js or express.js.
For Web 3.0 apps (realtime things, client-side MVC, etc.) this isn't true, RoR doesn't keep its advantage there.
So choice depends on use case and priorities.
I know a lot more about Node.js than I do about Ruby. That being said, Ruby is much more widely adopted. It is currently a very hot skill to have in the work place. Some may argue with me on this but I think that Node.js is still "under development" and will be for a little bit longer. It has a lot of promise but just hasn't been adopted by many companies and projects yet.
I am writing an application where the webapp will be rails and it will allow a user to input rules/ruby-logic and save them to the database. Later on, Java will come along and grab these rules (if/else/elseif) and will execute them via jruby engine. I am wondering of the negatives and possible side-effects of this? And having two languages here?
I want to do rails front-end because the available plugins, and speed of development of webapps. For example, groovy doesnt have as many plugins and i believe that it's much slower in development.
Am I missing anything, or possible logic that may be hurtful in the future if I choose this solution?
In addition I think since ruby is dynamic it will be easier for the user to input rules via a 'ruby' syntax instead of another third-party library like bean shell.
I feel like most complex applications end up needing several languages eventually, usually interfacing through the DB as you're planning. I'm not sure what constraint leads to you Java on backend rather than ruby (guessing legacy or performance), but if that's a requirement then your plan sounds reasonable.
As far as negatives/side-effects, Jruby seems to lag a bit behind the latest ruby, but that's not generally a big deal as long as you match versions for the UI & backend. I can't think of anything that would be harmful in this off the top of my head, but the devil is always in the details ;-)
I've been playing around with Rails (version 3) for a few months now and I understand the framework fairly well. However, I have yet to develop a large website which offers lots of database access and user interaction.
I'm fairly skeptical of the following:
The Speed and Scalability of Ruby (I've heard that its up to 10 times slower than most other server-side languages).
The extra background processing that Rails as a framework (multiple levels of abstration).
The lack of enterprise-level web apps that run on Rails (the only ones that I can think of Groupon, Github and Hulu).
The complexity of the environment (nginx > mongrel > rails > ruby > website).
The behind-the-scenes SQL operations (I know that these can be optimized, but I'm sure that I'll miss some).
For these reasons, I'm unsure whether to continue using Rails or to switch to something that is built ontop a more performant language .. say Java Spring.
Please advise :)
There are tons of large sites and infrastructures in production that use Rails. This question has also been asked to death over the years of Rails being actively used for all manner of web apps, large and small.
Short version is that it is not the fastest language around but despite that scales fine if you know what you are doing. And you should have enough money to hire people that know what they are doing if you actually have any problems of scale.
Scaling any webapp is hard, use the language/framework you know. Programmer happiness is king.
You can get good performance with Ruby. Easy:
require 'inline'
inline :C do |builder|
builder.c <<-C_CODE
void run() {
// Write your entire application in C here
}
C_CODE
end
run
Problem solved ;)
Not the speed and scaling discussion again?
In webdevelopment the things that are the slowest is the network communication (receiving the request, getting al your data back), the database (getting all your data from the database), and most of the times it is not about the computation time at all.
While it is true that Ruby and Ruby on Rails seem more focused on programmer happiness, I think that every decent web-application built in .NET or Java has as many levels of abstraction.
The complexity of the environment? I think you mean deploying? There are a lot of options, but the most used options are Passenger (very easy deployment on top of an apache or nginx), or Torquebox.
Torquebox for the moment is the fastest, best scaling solution (based on JBoss Application server), and several big names in the Ruby community are calling Jruby the implementation of choise to deploy your applications. While AFAIK the commonest deploy still is using REE (Ruby Enterprise Edition) and Passenger.
Unless you know you are going to have to do serious mathematical, cpu-intensive operations, I think the question you should ask yourself is: which framework/language will give me the quickest result?
If you are very proficient in Java/Spring, that might be the answer for you. But if your only worry is performance in general, I would say: do not hesitate and go for Ruby on Rails. It is a pure joy to develop in. The ruby community is really awesome if you would encounter any issues: support is just a post away.
And to conclude, I want to add a few very big sites using Rails: LinkedIn is using rails (and jruby), and Twitter still is using Rails for their frontend.
I'm lately more and more into Ruby on Rails and i have actually started coding a browser RPG. Do you think it's a good idea to code such a game using a framework like Rails ?
I've tried to do this in PHP in the past, but the workload was amazingly big. On the other hand, doing it with Rails is a hell lot faster.
The question is, though, is performance going to be ok ? What are your thoughts on this ? Would you do something like that in RoR ? Would it scale well ? It's important for me to know if it can be done in a good manner.
Use rails to manage users and data and build the game in flash. When HTML5 and javascript catches up I think it might, and that is a maybe for sure, be possible but it's seriously a headache. I think the future will be with node.js and frameworks like rails for managing games but right now its still flash pulling the graphics along.
You want to use the Midnight Coders plugin to connect flash and rails.
I have been playing with Haml recently and really like the way the resulting code looks to me...the developer. I'm also not too worried about a designer being able to consume or change it...we're a small team.
That said, beginning work on a project we believe will generate quite a bit of traffic (who doesn't?). I'm concerned that there are things I just don't know about haml. Is there anything erb can do that haml can't? Does haml have a negative effect as a project grows? Are there other things that should be considered?
And finally...how does Haml compare speedwise to erubis? I see that it supposedly beats erb and eruby now...
Thanks!
Haml rocks. I haven't seen any recent performance numbers but it is pretty close to erb these days. I think that it might be faster than erb if you turn on ugly mode (which prevents the pretty indentation) We're doing 2.8 million pageviews a day with Haml.
There is a benchmarker checked into the Haml source tree:
http://github.com/nex3/haml/tree/master/test
Update November 2009
Nathan (Haml's main developer) published some Haml 2.2 benchmarks on his blog. You can see the exact numbers there but in short:
Normal (pretty printing) mode = 2.8 times slower than ERB
Ugly mode (no pretty tabs added) = equal to ERB
You can enable ugly mode by placing Haml::Template::options[:ugly] = true in an initializer or environment file. Note that ugly mode isn't really that ugly - the resulting HTML is actually much prettier than ERB - it's just not indented nicely.
If you use Rails, the performance difference between Haml and erubis is negligible: templates get compiled and cached after the first hit, anyway. Combine this with fragment and page caching and you can rest assured that views are not the performance bottleneck of your application.
The question you should be asking yourself is: do you like writing Haml? Does it make you more productive? Then you can decide easier.
I love HAML since it is a good tool for easily writing structured HTML, and generally it is just a joy to use. But it has very little to do with choosing a tool based on the amount of traffic a site might have.
If you are worried about traffic, you should worry about using caching properly. And then you need to apply the principles of general web-application performance - the result is that you will have super snappy responses to page loads. Which is what a high-traffic website really needs.
A couple of presentations that show how to improve website performance can be found here:
Michael Koziarski speaks about Rails Performance on 2008 Paris on Rails
Jeremy Kemper talks about Performance on Rails on RailsConf EU'08
And the best place that I know of to learn how to use rails caching properly is:
Rails Caching PeepCode screencast
I think it's entirely a matter of personal preference and maintainability. For me, Haml makes the templates easier to read and understand, and the performance is very acceptable. In the end, the templating language is unlikely to be the place where you need to optimize -- more likely database queries, view or object caching, etc.
However, in the case of ERb templates, you will get better performance essentially for free if you use erubis.
If you like how haml works from a coding point of view, don't worry about the performance of the templating engine too much. (Though, as you've pointed out, it's now fast.) It can definitely generate any output the other engines can.
Generally, it's more profitable to put your energy into setting up caching than worrying about your templating engine where you're having performance problems.
I would personally recommend us erubis in precompiled templates.
Especially if there's no need for dynamic templating. Then your biggest slowdown will be limited by the speed at which ruby can parse ruby.
I'd probably set up a small cron job that just monitors for changed source templates and autocompiles them on-change that you can turn off when not in use.
Compile once, use many.
Oh, and if you're really concerned about speed, Tenjin may be worth a look too ( same creators as erubis )
http://www.kuwata-lab.com/tenjin/rbtenjin-examples.html
Well, Haml performance continues to improve with each release. Is it at an acceptable place at the current time? That's for you to decide (I'm inclined to say "Yes", but it's your choice based on your needs). If you like the templates and the readability they provide, then the performance drop (however negligible) should really be the final factor in your decision.
One of the other tools you should consider using in conjunction with Haml is make_resourceful, another gem by the maintainer of Haml (Nathan Weizenbaum) that simplifies a lot of the RESTful things in a Rails app.
If you have any further, more specific questions about Haml (and m_r), I'm sure Nathan would be more than happy to answer them. He can be reached via Jabber/XMPP and email. His contact information can be found here.