Which are the similar features and differences between ASP MVC and RubyonRails?
They are similar not only in that they follow the MVC pattern but also in how they do it. There are many points very similar, but there are a lot of differences too.
From a purely subjective way I can say that Ruby on Rails is much more mature and there are lot's of things to easy the task of building a web site. I moved from ASP.NET MVC to Ruby on Rails and this is the list of advantages I've seen (some of them really subjective):
Due to running on Linux servers:
Servers are cheaper.
Configuration is re-usable, we can re-build a server in 30 minutes. Puppet.
There are more than 10000 libraries, called gems, all installable and updatable in the same simple way. http://rubygems.org/
Several re-usable authentication systems, including the one I've wrote; ubiquitous_user + rails_openid.
Migrations. This is very important!
Unit testing of models with a real live database. It works beautiful.
Functional testing of controllers with very powerful assertion systems.
Platform independence. You use Windows, I use Mac.
ActiveRecord (better than EF or any other ORM out there I've seen). Degrades gracefully allowing you to add more pieces of SQL until you write all in SQL. You'll love it.
Command line tools are easier to install and maintain updated (think ssh, sftp/scp to copy and synchronize files, lame, sox, etc).
Passing data from the controllers to the views is not a pain in the ass because Ruby is dynamic and C#/ASP.NET MVC isn't.
Nice libraries for geolocation.
Nice integration with Sphinx.
Community #ruby and #rubyonrails in FreeNode (bigger than ##csharp y ##asp.net).
Concatenate all stylesheets and javascripts in two files.
Timestamp all files, by default.
Environments: different settings for development, testing and production (no more web.config madness). More environment possible.
Deployment with capistriano. Deploy with one command, everything; very repeatable and can be rolled back easily; takes care of database migrations; can deal with deploying to various servers or set of servers at once (if you have more than one front-end or you have production and staging respectively).
MySQL natively. Has clustering capabilities which might come handy (I already used them, to have read-only mirrors)
Routing is more powerful, RESTful built in, trivial to use. Namespaces, sub-resources and many other features.
No need to compile, very nice when deploying to the server.
Various implementations: JRuby in Java, it might be faster, work on Java servers like tomcat. Rubinious, Ruby with JIT compiler.
Heroku: an app server, like google apps, but for Ruby on Rails. Might be a good resource or not. They escale quite well.
Very nice tools to analyze source code and find potential problems. A small example: http://getcaliper.com/caliper/project?repo=git://github.com/pupeno/ubiquitous_user.git
TDD is not only possible, it's easy. Mix of dynamic language with amazing testing framework.
Much better linking methods
Very nice form generator: formtastic. Can generate a form in one line.
Scaffolding.
Admin tools.
A sane translation system, gettext.
Similarities are primarily related to design decisions (the decision to use MVC patterns, etc.). Differences include the languages (Ruby vs. C# / VB), the development environments (Windows vs Multi-Platform), and the tools. Ultimately the similarities and differences are too numerous to list. Can you be more specific?
Related
I'm new to Ruby on Rails and have been seeing people use auto boilerplate generators like Rails Brick or Rails Composer to create boilerplate user-management systems, etc. Coming from a background that doesn't trust auto-generated code, is it good/legitimate practice in Rails to use such systems. Also, I'm working on a project with a startup. Is it fine to use such generators and how widespread a habit is this.
P.S. Mods please note that this is not a question asking comparisons/opinions/disputes. I'm curious about the general practice in Rails and how often is this used in production.
I'm the maintainer of Rails Composer so I believe I can answer this question with authority.
I respect (and share) the urge to build from scratch. That's a healthy impulse. Rails includes a facility for application templates (Rails Composer is an application template) because automation saves time and effort. For people who build many web apps, a time comes when you decide to automate the process.
Rails Composer offers an advantage over roll-your-own application templates because it is open source, used by thousands of developers with code contributions by many. As Rails and gems change, Rails Composer gets updated so you get a current "reference implementation" every time. It gives you well-tested starter apps that integrate all the bits and pieces that require tweaking, like RSpec plus Capybara and FactoryGirl, flash messages and navigation with either Bootstrap or Foundation front-end frameworks, Devise or OmniAuth for authentication, Pundit for authorization, and many utility gems that developers like to add (Guard, Pry, etc.). It lets you choose your stack (for example, ERB, Haml, or Slim), offering choices to the extent that the community has contributed options.
If you're concerned about the safety of running an install script, the code is open source and used by thousands of Rails developers (you can see over 2000 watchers on the GitHub repo). It's purely an application template using the Thor library, and though in theory someone could contribute code that tampered with your files, we'd never accept a pull request like that. Rails Composer only offers well-known popular gems, so you are not exposed to potential risk of using unknown gems.
Rails Composer is widely used, particularly by consultants who build lots of apps. Many of the prominent consulting firms have an in-house application template (Thoughbot Suspenders, for example) and some use Rails Composer or the rails_apps_composer gem that generates custom application templates. Developers who work on on only one application regularly (maintaining a big project, for example) tend to be less familiar with application templates like Rails Composer, but it is popular with developers who start a lot of apps.
Stack Overflow is not a place for opinions, so if you want a range of opinions or debate about the merits of Rails application templates, Reddit or Quora might be a better place to ask.
Welcome to Stack Overflow! I hope all your questions will be answered accurately and timely.
I'm the developer of Prelang which is similar to the generators you mentioned. It differs by adding data modeling, GitHub integration, and deeper configuration for some features. Like Daniel, I believe I too have some authority on this and agree with his very complete answer.
To answer your question, Prelang is newer but it's already used by thousands of developers ranging from beginners to dev shops.
I'd like to note that Prelang (and the other builders) are different than what you traditionally think of when you hear "code generation". When working on Prelang, my goal is to automate "everything that a Rails developer would have done anyways". Prelang does generate methods/code but mostly it's automating install processes of Gems, setting configuration values, creating models, and running rails commands. That said, Prelang is opinionated in terms of which gems it uses but I've selected the most popular gems for each feature and will give the flexibility to choose between multiple routes once I get a little more traction.
Prelang also makes real Git commits so you can look through every commit after your project generates giving you full visibility into your codebase. This is intended to further ease concerns relating to generated code.
Erik
Most gems are so easy to set up nowadays, that I think you won't need such a generator. After all it's just a question of taste – I like using the command line, and I like knowing exactly what's in my codebase. From my personal experience, I have never seen someone use such a thing in professional Rails development, but clearly there are people out there who use them.
The one case I can think of where these generators make sense is when you're bootstrapping projects very frequently. In this case however, I find the existing generators not to be flexible enough. Thoughtbot for example has built their own app generator called Suspenders, which of course includes a very opinionated set of gems etc. but it gives them exactly what they need.
As a side note regarding your security concerns: for me, the dependency trees that are spanned up when you use many gems are a far worse security threat. For example in a medium sized Rails project it is not uncommon to depend on 100+ Gems; no-one can read all of them. You'll have to trust all of those as well.
I have a Clojure back-end that I want to put a Rails front-end to. How should I connect them, and how specifically do I do it?
Off the top of my head, there are two ways:
run Jruby on rails, in the same process as the clojure app
run normal Ruby on Rails, and connect it to the clojure backend through a message queue, web hooks, and through a joint DB.
Both seem to have disadvantages. In the former, it seems that running jruby will limit the gems we can reuse and otherwise cost us productivity when library authors have not made something perfectly compatible. In the latter, I imagine we'll miss out on code reuse - possibly having to implement the same thing twice in some cases - and that the more complicated interfaces (web hooks instead of just function calls for example) will cost us.
Finally, in the case of JRuby, it's unclear how to actually connect the two. Both come with management scripts: rake and leiningen, and specific repository layouts. I don't really how to start joining them together. Advise and war stories welcome.
I think if it were me, I'd definitely use message queues to communicate between those services—though JRuby really is a good choice on the front-end as well (I think most gems are fairly compatible at this point, even those with native extensions.) Ultimately, you can use elements of both approaches.
What you're talking about is a fairly typical SOA set up, and that's one of the great things about SOA—you can leverage different languages and platforms where they do best. Trying to use clojure within a jruby-on-rails setup is likely to lead to much pain and misery, and IIRC it'll taint some of the benefits of using clojure in the first place.
Unfortunately I don't have any war stories that precisely match up to what you're trying to do, but I'm in the middle of such an architecture right now and its working out great, using RabbitMQ to let MRI 1.9 talk to backend workers running JRuby. Not sure how you'd consume messages in clojure, but I imagine there's got to be docs on it somewhere, and you'll be able to maintain clean separation. If you were to run your front end on jruby, you can still share code between the jruby process and clojure backend without having to put them in the same process.
I haven't done anything yet with Clojure + JRuby, but I have tried out JRuby + Scala/Java.
Scala/Java side works as the service layer and JRuby on Rails sits on top of it. Both projects are managed separately: Scala/Java project is compiled via Maven into a JAR which is then added as a dependency to the Rails application.
This seems to work quite nicely and I guess Clojure would work even better, because Clojure collections implement the interfaces that JRuby consumes, in Scala I had to tweak the service layer interfaces.
Disclaimer: I haven't done this with Ruby, but have quite a bit of experience mixing Clojure and Java modules in the same application and it works pretty well.
If you can make it work, I'd strongly recommend going the JRuby route for the following reasons:
Less dependencies for deployment - you just need the JVM and your relevant jars/wars
You'll get better performance by using in-process communication than you will with queues etc.
Architecturally it will be simpler and easier to maintain
You'll get access to all the Java library ecosystem from JRuby - depending on your precise needs, this could easily make up for the gems you lose through compatibility issues
You'll be able to use the same classes and common libraries from both environments
As for project layouts, I expect the simplest approach will be to create two different projects, package one as a jar and include it as a library for the other.
I have mainly developed in the .NET world, but I have a project coming up which needs to really favor the front end. Lots of UI love.
Is there value in using to Ruby On Rails instead of MVC3? How should I go about choosing between the two? Are there other options worth looking at?
I know Ruby On Rails is pretty popular, but how does it differ from MVC3?
Is there value in using rails instead of mvc3?
YES. If nothing it will give you a different perspective and broaden the way you think about programming problems. There's something about the terseness of ruby, usefulness of blocks, and dynamic behavior of the language that allows you to really think differently.
How to choose between the two?
If the project is a short one then stick with what you know. But if it'll end up being a longer project it might be worth the effort to start digging into the learning curve of rails. Most people will tell you that rails is faster to develop in than .net mvc. If the project is long enough, you might end up being able to develop faster on rails once you get comfortable with it.
That being said, the learning curve for a Microsoft programmer can be STEEP! If you're a unix guy then it wont be so bad but if not, get ready to learn about a LOT of different topics. The command line and your shell, TDD, homebrew or macports, git instead of subversion, gems, bundler, rvm, rspec or some other testing framework, etc.
Also, if you don't own a mac or aren't on some flavor of *nix then you might want to stick with .net. From what I hear it's a painful experience developing rails on windows.
If TDD is important to you then rails is the way to go. Also deployment is much easier on rails.
The ecosystem is something that might be a factor if you like to use tools built by others. Rails has a huge base of open source developers that contribute a lot back to the community. If you want to compare take a look at github.com (for rails) and codeplex (for microsoft). However, with Microsoft's NuGet system maybe the Microsoft side will start creating a better ecosystem. But right now it's not even close.
Other options worth looking at?
If you need to develop a pretty dynamic, database backed website then rails or .net mvc are good options. If it's something much simpler/smaller then some simpler/smaller frameworks are sinatra (for ruby) or webmatrix for .net. You'll be able to get up to speed much quicker with these frameworks.
How do the two frameworks differ?
The biggest difference I notice are from the underlying langues, ruby for rails and c# for .net mvc. Ruby is dynamic while c# is static. Rails is not compiled while .net mvc is. You'll get more raw performance out of .net mvc.
Rails is really built with TDD and BDD in mind. The last time I used .net mvc 1.0 it was really hard to do TDD.
When developing, pretty much everyone on .net mvc will use Visual Studio but I'd say most rails developers don't use an IDE. They just use a simple text editor (textmate, vim, emacs) and debug using the console.
EDIT:
*Bonus tips*
If you want to get started with rails (which I highly recommend) the easiest and most thorough way is to go through the rails tutorial by Michael Hartl. In it you'll learn about ruby/rails along with the following
git - source control
rvm - for running different versions of ruby on the same computer
rspec - for TDD
heroku - free web hosting with SIMPLE deployment
Once you get a good understanding of rails you'll want to improve your ruby skills to really become a good rails developer.
Ruby and RubyOnRails sounds like it would fit the bill.
And if you really wanted, you could use IronRuby for .NET goodness.
As for justification - many successful sites have been written with the framework. It has a proven track record over MVC3.
I have little experience with ruby itself. I am going to hire somebody to write a web based application and I wanted it to be written in RoR but I was recommend mono. I guess because they like mono and because they think the RoR is slow.
The whole application would be some kind of social media meta management tool. There will be front end web based part and then back end doing the 'real stuff'.
I have no experience with mono at all and I am not experienced enough to comfortably say that RoR is the best choice.
I understood that if RoR is configured properly it could be pretty fast. I read that RoR has some troubles with scalability. I will start the application small and if it's successful I need to scale it up.
What would you recommend?
in the light of
performance
scalability
easiness to test
easiness to maintain, develop code/project
( I like ruby but I am not going to be the developer myself. I prefer to choose the 'better' option if there is such answer to that question)
please feel free to suggest anything else ...
If you are not going to write it yourself, you may want to go with what the person who will write it is most comfortable with.
Full disclosure: I have developed several sites now using Mono and I love it. I have used Ruby-on-Rails but not for anything nearly as big as what I have done in Mono. Keep that in mind.
Quick answer: In the greater scheme of things, Ruby-on-Rails and ASP.NET MVC have more in common than not. My choice would be ASP.NET MVC on Mono but I doubt you would regret choosing either.
Architecture: If you want one way of doing it out of the box, choose Ruby-on-Rails. If you want to be able to choose what you feel are the best-of-the-best technologies from a range of choices, choose .NET (Mono).
Ruby-on-Rails is more of a turn-key solution in that it provides a standard way of doing pretty much everything you need out of the box. .NET (Mono) offers a lot more power (my opinion let's say) but there are a lot of different pieces to choose from and you have to choose a technology stack yourself. As an example, RoR has a standard way of accessing databases while .NET Mono let/force you to choose from a dozen different ways to do that.
Mono and .NET generally have a little better separation of concerns so the purist in you might like that. If not, you actually find the roll-up-your sleeves and get it done attitude of Ruby more to your liking.
Performance and Scalability: This should clearly go to .NET and Mono. In fact, I believe the fastest way to run Ruby-on-Rails is to use IronRuby to run it on .NET. StackOverflow is written in ASP.NET MVC and, given the amount of traffic, it obviously performs great. Proof is in the pudding. That said, the performance bottleneck will probably not be your choice of framework.
Testing: Old style ASP.NET (now called WebForms) is considered pretty hard to test. The newer ASP.NET MVC was designed to be easy to test and is similar to RoR. One major factor is that in Mono you will probably be using a statically typed language (like C#) while Ruby is of course a dynamically typed language. You have to write more tests in a dynamic language (because the compiler/interpreter will not catch type problems) but it can also be easier to write tests if you are not fighting the compiler. I think it is a matter of taste and style (I like static) but this is a major factor in answering this question.
Of course, since .NET/Mono is a multi-language platform, you could always write your ASP.NET MVC tests in a dynamic language. You could even do it in Ruby (IronRuby). Perhaps that would be the best of both worlds (static checking on your real code and flexible dynamism in your tests). I have considered doing this myself using IronPython for tests.
Maintenance and development: This is a tough one. It depends what you are writing, what third-party libraries you might need, and what tools you are going to use. I would say that RoR is probably the more advanced MVC framework. My own thoughts are that Ruby-on-Rails is probably a shade easier to write but a little bit harder to maintain.
Community: I like the Ruby community more than the .NET one but I think I like the Mono one the best. That makes it a little confusing. The core Mono guys (like Michael Hutchinson that answered here) are simply awesome. I really like MonoDevelop as a tool (IDE) as well. It just keeps getting better and better. Michael, thank you for Git support if you had anything to do with that. :-)
Tools: If you are writing for Mono you can use the whole universe of .NET tools (VisualStudio, ReSharper, Reflector, etc) so that is pretty hard to beat. That is assuming you develop on Windows of course. On Linux or Mac the tool of choice for Mono would be MonoDevelop. It supports version control, a software debugger, and NUnit tests right in the IDE and is completely cross-platform.
It seems like a lot of Ruby folks just use a simple text editor. This may just be because an IDE just does not have as much to offer a dynamic language as it does a static one. Here is a SO question on what people like for Ruby:
What Ruby IDE do you prefer?
EDIT: Just to make things confusing...there is another MVC framework for .NET/Mono that is even more like Ruby-on-Rails; MonoRail even has an implementation of ActiveRecord. MonoRail has actually been around longer than ASP.NET MVC but I would stick with ASP.NET MVC these days as that is where the future lies. ASP.NET MVC is open source by the way and ships with Mono out of the box (the actual Microsoft code).
I can speak more to Rails than Mono. RoR is pretty scalable these days with all of the cloud hosting services available. Web applications query data and render web pages using that data, which really isn't that big of a deal. Most performance issues are caused by database and schema design issues, not the web framework. Typically, database response times dwarf other portions of server processing. RoR is also very easy to test. Testing is a more natural part of development than in other languages that I use. When I started RoR programming I was used to the much more structured world of Java, and the more dynamic Rails won me over for web development.
Firstly, I work on MonoDevelop, a crossplatform IDE for Mono (including ASP.NET & ASP.NET MVC), so feel free to consider my answer biased, but hopefully it will be helpful anyway.
Performance: a decent JIT compiler (Mono) should be much faster than an interpreter (Ruby). But it depends on the programmer's skill too - well-written Ruby could be faster than really badly written C#. The libraries and database and caching mechanisms you use will be a big factor too, but these aren't fundamental to the languages/frameworks.
Scalability: AFAIK there is no magic bullet for web app scalability, and although I don't have practical experience in this field, here's some info I've picked up. It really depends on your database usage, how your session state is stored, and how caching is implemented. This isn't really fundamental to either framework - once you start scaling to multiple machines, you'll probably have many machines/processes for database servers, cache servers, message queues, frontends, servers for static content, etc. Likely only the frontends will be ASP.NET or ROR, and if they're stateless, you can simply clone them and handle the scalability problems on the backend.
Testing: I can't speak for Ruby, but ASP.NET MVC (but not vanilla ASP.NET) was designed to be easily testable using .NET testing tools such as NUnit (Mono's own unit tests use NUnit).
Maintenance and development: Again, I can't really speak for Ruby, but it's pretty much a given that it will be easiest to develop (at least initially) in the language & framework that the developer already has experience with. Also, .NET has some amazing development tools on Windows - Visual Studio, ReSharper, etc. - and there's a huge pool of experienced C# and ASP.NET developers you can hire, though few of them will know Linux/Mono.
Also, StackOverflow uses ASP.NET MVC :)
To introduce a little levity...
How about DOS on Dope: the last MVC web framework you will ever need?
There are of course a dizzying array of choices but another nice alternative is Django.
It is basically Ruby-on-Rails for Python so most of the comparisons of RoR vs. ASP.NET MVC would apply. Depending on what kind of site you are building, the really interesting feature of Django is the automatic admin interface.
If you need to be up and running quickly, I would go for RoR. Scaling rails is becoming easier with time and you have a big range of ruby runtime environments to choose from MRI 1.8, 1.9, REE 1.8, JRuby (run on java VM), Rubinius.
ASP.NET MVC is nice, but I still think it has some way to go before it offers the same speed of development as RoR.
Are there any important features in Rails or Django which do not exist in the other framework?
Is there anything important missing - for an enterprise web app - in either one?
This question is not intended to be argumentative - I am trying to make an informed technology decison for an upcoming project. Two of the concerns I have, with regard to choosing one of these frameworks, are:
Integration with external systems (Java, .Net, SAP, etc)
Reporting - would there be any difficulties producing sophisticated reports/charts (financial) using either framework. This would require multi-table joins, custom sorting, pagination (w/ajax) and printing for different devices.
Django on Jython is running nicely so Java integration shouldn't be a problem.
In terms of integration in general don't forget that Django is also Python so you have the massive support of the standard library plus all the other mature well supported Python projects out there. Integrating 3rd party Python code into Django projects is usually trivial.
At the risk of getting evangelical I would list the following Django killer features:
The admin
The documentation
Python ;-)
Django also has GeoDjango. The NY Times chose Django over Ruby for their Represent project for easy mapping support:
"We built Represent with Django, the Python web framework. Although we do most of our work with Ruby on Rails, we chose Django for this project so we could use GeoDjango, an add-on that supports geometry fields and extends the ORM to allow spatial queries."
My experience/opinion is that Rails is much more flexible and has a more diverse ecosystem and is developing faster while Django is more stable, slower changing, better documented.
Rails has a huge advantage for integration with other systems via JRuby. You can give rails access to the entire Java ecosystem and run it on the JVM.
Django might be able to take advantage of .Net via IronPython (I don't know anything about this other than that IronPython exists - while IronRuby is only on the way but not here yet)