This is my impressions about Rails after rolling out an Issue Tracking system in 1 week (I might put it on tamersalama.com for a taste of what can be accomplised in 1 week).
Likes:
- Ease of use.
- Help developers focus on business aspects rather than configuration, integration issues.
- Smooth learning curve.
- AJAX wowing helpers and js libraries.
- The power of being agile and getting things done, fast.
- Simple APIs with powerful methods.
- No need for an IDE (a text editor is enough), while in Java an IDE is an absolute must.
- Convention: cars table is mapped by default to car model, placements in directory structure.
- Everything under the same hood:
- Persistence framework (ActiveRecords). In Java one have to learn Hibernate, Config, Mapping files and a new API.
- Simple configuration is done via Ruby with no need for XML (one doesn’t bother about XML and “Spring”ing files which is almost like learning a new language).
- Templates use rails functions (No need to learn JSTL EL syntax or struts tags).
- Helpers, similar to writing Tag libraries but with no need to extend BodyTagSupport, write tlds, and understand weird-named variables like EVAL_BODY_INCLUDE, etc….
- ActionMailer is simple and powerful.
Dislikes
- Ease of “abuse”. Model 1 anyone?
- Although touting the DRY principle, yet, validating DB stuff (like NOT NULL fields, uniqueness, etc..) is repeated in the model (I’ve read somewhere about an intention to leave such simple validation to the DB – but not sure how serious or how feasible). A note on this: it’s really not too much work including “validate_presence_of” line in the model but, still, it’s not DRY.
- Tying the validation mechanism to the persistence layer (model) – what if there’s a need for simple validation of other input (I’ve read also about other work arounds but haven’t tried them).
- List of reserved keywords (this is non sense: words like System, Task, Class, Transaction shouldn’t be used as entities?!).
- Docs (again), but “