I consider myself a well trained WordPress template developer, and i recently started to read books and documents about web app frameworks, particularly Django and Ruby on Rails. I didn't know any of the two languages, but i have no problems to learn another one or two. I really don't get the real benefits of using a framework, because i feel very confident about the power of WordPress. So, can anyone tell me the real benefits of using a framework? For example, Pinterest is made using Django, but i think that i can achieve the same results with a WordPress template using Javascript and CSS3. Can anyone tell me the differences/benefits of using a framework in that particular case?
You can achieve the same frontend with Wordpress, but what you will not be able to achieve is the speed and scale - and most importantly, maintainability - of an application based on a more application-oriented architecture.
Wordpress is highly flexible, but it's also slow, and needs an awful lot of TLC to be able to operate at any kind of significant scale. Its design allows for very flexible runtime modification of behavior, but this is also a bit of a Pandora's Box, since it means that code can end up running all over the place for any given page, which makes maintenance a nightmare.
Wordpress is extremely good at being a CMS, but once you start to push it outside of those bounds, you get into trouble, and find yourself having to write your own more abstract framework that runs inside of the context of Wordpress to be able to fulfill your application's needs.
That said, if you have an application that you can build in the context of Wordpress, I'd say go for it! Wordpress can be a wonderful tool for building a proof-of-concept or MVP. If it gets you up and running, then it may be the right choice over writing a full application. However, just be aware that you're going to hit some brick walls as your product design matures and your audience grows, unless your application fits within a rather narrow set of design requirements, so long-term, you may find yourself having to move to a custom application.
Credentials: I've spent the last couple of years maintaining a Wordpress install that served over 25 million monthly uniques, and we had to get very clever to keep it running. We've since replaced it with a Rails application that serves pages somewhere on the order of 10x-30x faster, and is significantly more extensible as an application, allowing us to start exploring application potential that we really couldn't get with Wordpress.
I once made the decision while working in some start-up to choose WordPress for an advanced e-commerce, community-driven marketplace.
It was an awful decision
This is how I was feeling:
At the beginning, it was looking good - you have an amazing community, plugins for everything etc. But sooner than later I hit the wall - at it's root - WordPress is a blogging platform!
Every piece of content technically is a post.
It's really hard to create advanced item relationships
Functionalities are not consistent. Some functions work one way, while others that seems to be very similar work in a different way. Sometimes you need some weird hacks to achieve task that seem to be simple. It makes you read the docs very often to see how a function that you're using for the 1000th time is working. (However, to be honest, I need to say that the WordPress documentation is great!)
The WordPress community is doing a great job, but compared to any regular Framework there is one main difference - Frameworks are just frameworks - they're a set of tools and those tools are there to help you do your project. WordPress already is trying to be something that you might then change.
I'll never again use WordPress for anything that needs some organised, custom functionality.
I'm actually quite impressed with what people has created with wordpress - so if you want to, it is possible and good luck!
It however often feels like buying a truck and rebuilding it to be a house. There are better ways to build a house.
I want to offer a dissenting opinion, even though I upvoted the top answer.
Is Rails really special?
Rails was created by David Hansson who extracted it from Basecamp, software that's replicated in a free Wordpress plugin, WP Project Manager. I think that's a pretty good indicator that Rails developers are underestimating PHP and Wordpress.
MVC and WP
True, it doesn't follow an MVC pattern. But if you use hooks, separate logic (in plugins) from views (in templates), then you'll have good code separation. (Also hint: custom post types are like models.)
Framework vs Application
As you can see, Wordpress can be treated like an application or a framework. It is an application, with all the components you'd expect to find in a framework. Right out of the box you have security, authentication, and extendibility. And it's meant to be extended.
Scaling
WP powers 18% of the internet's websites, including TechCrunch, Smashing Magazine, and (parts of) CNN. Seems there are ways to make WP scale. Disclaimer: I have no experience working on megasites like these, so I'm offering mere conjecture.
WP Future
The current abition of the WP community is to shift WP from a CMS to a framework. I think it's a natural progression considering that all the pieces are in place. And the Wordpress community is going strong.
Not really an answer, but a hint:
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
As if you can replace it completely... I think it is mostly a matter of logic flow. It depends how much imperative (Ruby on Rails) vs. descriptive (WordPress) programming you intend to do.
I don't think wordpress can replace rails, because wordpress have limited set of API and support as you compare it with RoR. Though wordpress is powerful tool for blogging application, but the same effect can be achieved with rails using gems like,
Radiant CMS,
Refinery CMS,
Locomotive.
Adding the power like ttd that can be done vary easily with rails is very difficult with wordpress.
Same with authentication and authorization mechanism like devise and cancan. There is no easy option to do the same with wordpress.
Rails make the programmer's life easier. For whole web app I will always prefer to go with the rails.
Wordpress cannot replace X framework, but the two can certainly complement each other.
For example a WP front end serving up CMS content with an attractive theme is pretty hard to beat; proxy to a back end server for custom content and voila, best of both worlds. Otherwise, WP will inevitably fall short of meeting every requirement and you'll find yourself going down the square-peg-round-hole rabbit hole, a painful place indeed; that's where X framework comes in, filling in the WP gaps.
The notion that WP does not scale may have some truth to it, but for the general case, the 95%, it will handle whatever you throw at it, particularly with WP Cache or other caching plugin thrown into the mix.
Some may say, well, you can build WP with Django or RoR! Heh, heh, you first ;-)
FWIW, I avoid dynamic language frameworks in favor of their statically/strongly typed counterparts. Use WP for the bling, and static X framework for the speed/scalability/safety. Of course, that's a matter of preference, clearly some prefer runtime flexibility over compile time safety. I'm fully in the latter camp these days...
In the simplest term,, I always want to put it like this...
You can use a framework to make WordPress it self and better
But you can't use WordPress to make a framework
Wordpress is a great CMS any way
Pros
1. We can easily set up a website using free themes and plugins
2. There are numerous number of plugins to extend our website functionality
3. Excellent Community support
4. The CMS uses PHP and MySQL, somewhat easy to lean
Cons
1. Updating plugins and themes regularly.
2. Slow
3. Malicious files can be easily injected.
Related
Just curious: I have to do a mini-CMS that allows users to add "pages" using a template. Each of the produced pages has/is an entry form and a "received" page.
I can visualize this in Rails pretty easily, but I'm wondering if there's any advantage to using a CMS like Refinery. Thoughts?
I was supprised to see Phil Arndt's answer voted down - I guess that it's hard to gain trust if you're involved in the product you discuss.
As for your question: sure you can build that site yourself, and most likely it will be simpler and will cost you less time than diving into the RefineryCMS documentation.
However most likely this site will evolve, your client will come up with more requirements, and it'll become harder to keep up with the complexity of the project.
Further more, you'll get more similar questions from other clients. Similar, but not identical, an you'll have to start from scratch every time.
A cms framework such as Refinery becomes an interesting choice at that moment. A framework gives you bigger building blocks than the Rails framework itself, so you can build faster. You won't have to reinvent the wheel for every customer request, since it will often be similar to what other people have built and shared (the "engines" in the case of Refinery). So the time you invest to learn to use the framework will pay off.
So in your case, even if you've already implemented your mini-cms, I'd consider redoing it in refinery or another framework CMS before you end up building your own CMS in which you'll have to duplicate all of the work already done for other CMSes...
One advantage to Refinery is that it has a very active (and growing) community of developers with an increasing number of 'engines' built to handle custom requirements. Also, by using an open source solution you have the opportunity to join in by providing patches for anything you think could be improved.
Another new advantage to Refinery is that it can hook straight into an existing application by following the very few steps in the integration guide.
Of course, this is all in addition to the fact that it aught to save you a lot of time as this use case has been carefully thought out over years of development with over 105 contributors and a large number of websites running smoothly in production.
Cheers,
Phil
For the first time I'm creating a quite complex Rails app.
I'd like to know what's the best way to organize that app by folders. Until now, I'd do everything under one app (all the models, controllers, etC) but reading some open source code I realize that they put everything under different apps.
Like for example Spree Commerce. They have a general folder and inside that they have different apps (API, core, admin, etc). How is that done and is that the best way to do it?
I'd like to get pointed to the best way to do it (a book, blog, anything) so I can understand how I can architect my app for future maintenance.
thank you
As an aside I think the title of your question is a little confusing. Rails, by using convention over configuration, defines 'how to organise a Rails app'. I think your question is rather about how to architect your application as opposed to anything Rails-specific. Maybe tweak the title?
That aside, without knowing any more detail about your project it's a tricky question to answer, but I'll give it a go.
All applications should start off simple, if you believe (like I do) that you should start by building the simplest thing that could possibly work. Given this, since you're using Rails, then in all likelihood the simplest thing would be to structure your app as a vanilla Rails 3 application. This will probably (I say 'probably' because I don't know any specifics about the app) allow you to get a beta version of your app up and running pretty quickly without worrying about complexities which at this stage in the development of your project are not a problem.
If you need to create an XML or JSON-based API then Rails makes this really easy using the standard framework, which will allow you to spend more time thinking about the API design than how to code it, and it's the API design which is the most important thing to get right in the first instance.
Similarly, your Admin site can be part of the same app just in a different namespace. If you find later down the line that you want it as a separate app, you can do this (maybe you could use the awesome API you designed to facilitate this), but why bother designing it with this added complexity (and hence extended development time) in the first place if you don't have a good reason for doing so?
Once you have your app up and running and people are starting to use it, you start to get a picture of where the bottlenecks are and where the design could be improved. At this stage, if there's a need, you can start to move parts of the app to scalable solutions, such as running your API as a standalone service, introducing caching, changing data stores and other improvements and optimisations.
Even if your app is as wildly successful (and I hope it is!) then re-architecting your application whist continuing to run the existing service is still entirely possible, as Twitter have proved. Just stick to Knuth's statement and you'll be alright.
Regarding reading material, that's a tricky one. For me a lot of the XP and agile development classics taught me a huge amount about how to approach program and app design. I'd also check this StackOverflow topic for book inspiration.
Good luck!
Spree uses Rails' Railties (Rails::Engines). Railties are introduced in Rails 3 to make it more modular and easy to extend. Rails 3 itself is a collection of Railties (ActiveSupport, ActiveModel, ActiveRecord, etc.).
If you are developing a complex app I would suggest spending some time planing its' architecture. Designing a complex app without any initial planning would definitely end with a maintenance nightmare down the road. It also introduces a huge learning curve for the new team members, slow down your new feature introduction and of course, frustration.
Anyway, don't over optimize, but don't forget to design your architecture for your needs.
IMHO, I will create very complex projects as one app. I have reason to believe that Spree and Radiant build under seperate apps so that under the pretense of their open source communities, contributors can contribute code easily without tampering with the core data, and the core workings of the application.
Otherwise, you should be alright just building it as one app. Just keep it neat.
Here is what have kept me sane for several years of RoR development:
I use Rails Engines, but keep them in same codebase as the main app. Here is good starter for modular Rails app:
https://github.com/shageman/the_next_big_thing
Wherever I can I try to reduce coupling and use composition to make things easily testable, reusable and maintainable. This helps to eventually extract module or engine as separate gem. Composition is done by routes (mounting), directory overlaying (assets), dependency injection or configuration.
If I don't need to re-use an engine I put it in the same code base as the main app which is single deployment unit. Thanks to that I don't need to switch between projects in my IDE. While in development environment any changes to the engine code are instantly picked up by Rails reload mechanism.
I want to make a community based site, which is Drupal's strength. However I also want to try other frameworks, especially Rails.
One of the best things about drupal is its huge modules library. If I were to switch to Rails, would I be able to find similar functionality freely available as plugins, or would I have to rebuild?
Does Rails have the equivalent of (as plugins or gems):
CCK/Fields?
Node Reference?
Views / Views Relationships?
PathAuto?
Threaded Commenting?
Multisite Functionality?
Apache Solr (or equivalent) Integration?
Thanks.
I'm afraid you'll probably hear this answer a lot, but it's not a suitable comparison.
Drupal is a ultimately a CMS, Rails is a framework. Apples to oranges, or perhaps even Apple Juice to oranges. Out of the box, you fire up Drupal and it does 'things': it has a database structure, the concept of nodes, interfaces blah, blah. If you fire up Rails you have an empty project.
As far as I know there isn't a "Drupal-on-Rails" project that would be a suitable equivalent. However, I can attest to the fact that there is an awful lot of Ruby/Rails community and O/S work out there and you might find something suitable. I'd also say that the level of modularity in Ruby and Rails tends to mean that the range of plugins/modules/gems one can use is much greater.
My personal $0.02. If Drupal does what you need, just use Drupal: it's mature and has a great community. It's never a good idea to try to port Project X over to a new language as a learning exercise because you'll inevitable fall into the "Well that's how it's done in language X!" trap and become disenchanted with the new system.
If you're wanting to learn Rails (which you should, it's awesome) I'd suggest you'd be best working on a small project and seeing what the ecosystem offers before deciding if it's suitable for the needs of your bigger projects.
I have to second what Govan said, but add to it.
With Drupal, unless you really want to get into building your own modules and extensions you are really interacting with an application. Even when you start using CCK, all you are really doing is flipping switches, filling in forms and defining new options for content on the site.
Ruby on Rails is two things, and neither of them bares much similarity to Drupal. You asked "How hard is it really?". To answer that you need to understand what both Ruby and Rails are. Ruby is a programming language designed to make the life of the object purist programmer simpler and more pleasant. So, the first part of how hard is it is simply to answer "how long do you feel it would take you to learn a completely new programming language, like PHP but different".
Rails is an 'opinionated' framework. It's opinionated in that it lays out how a Ruby web project should be structured, as well as providing multiple APIs for everything from database access to web presentation. To answer the "how hard is it" question for Rails then (assuming you know Ruby by this point), you have to answer how much do you need to learn about cacheing, database design, page design, RESTful programming etc etc.
It's not a short journey. you asked if there is an equivalent to CCK for Ruby and Rails which implies to me that at this point your knowledge of programming is somewhat limited. Ruby and Rails interact with the database. CCK lets you define things in a database. Thus, with Ruby and Rails you are effectively bypassing the wonderful dialogs and forms that CCK provides you with and doing the data definition bits yourself, by hand, in code.
From experience, when I've hired experts in another programming language and framework into my Rails teams, it has taken them between 1 and 3 months to get productive, and a further 3 to 6 months for their productivity to start to raise and approach that of the Rails experts on my team.
Thus, in your particular case, I would not recommend a switch away from Drupal to Ruby on Rails.
Drupal (core) on ohloh (130k lines of code) is estimated to be 34 years of work worth.
Drupal (contributions) on ohloh (modules for Drupal 4-6 (7M lines of code)) is estimated to be 2113 years of work.
That is the power of a community, and that is something that you can never replicate. I remeber there was a guy, who tried to port Drupal to python calling it drupy, but that project died before something useful ever came out of it. Even if you copy the code, you can never copy the community.
The thing you need to realize, is that each community is different. So even if you find a project that can solve your code needs in a RoR or a different language/framework, it will never be like Drupal and vice versa.
So don't try to find a replacement for Drupal, but go explore and try new things. You might end up learning new things, that you can use for your Drupal projects.
I've read this times and times again that people saying comparing drupal an ror is comparing apple to orange which is wrong.
I think the saying itself BS. Yes we want to compare apple to orange and find out which is better. We even want to compare apple to steak. Said that, they are different. Yes, we all know. I have limited experience with either. I first thought Drupal was great and can help me build the website I wanted overnight (or over a week or month) then it didn't happen (not blaming Drupal).
My impression is that, Drupal maybe still great but it has a learning curve and needs a lot of other knowledge or talents to use it well and tweak it. RoR on the other hand is a more general framework and needs programming (Drupal needs too actually).
If you are more of a web designer person with a little PHP maybe Drupal is better fit.
If you are more of a web developer type don't want to spend time looking for modules and make them work but rather do them yourself (not really from ground up) then maybe RoR is for you (with the same amount of learning). So yes they are both good for different purpose, background, etc.
For now I will go with RoR (or dJango and other ORANGEs). My 2 cents.
Rails, since version 3.0, has officially adopted the once-controversial engine way of incorporating third-party apps. this is roughly the equivalent of Drupal's modules/plug-ins, from a 10k foot perspective. To build a community-based site, you could make use of an engine called, appropriately enough, "Community Engine." http://communityengine.org/features.html"
The Rails ecosystem doesn't have anywhere near the same number of modules Drupalists have available to them, but there are enough good quality ones to cover the chief basics.
Drupal has so many strong areas, its hard for just one or two people to recreate it in a decent amount of time with any language. PHP, Ruby, Python, etc.
You have the core node system, taxonomy, aliasing, menus, users, permissions, and modules, the database api, and form api, among others.
You'd have to know how to assemble all these pieces independently and create the structure necessary for it to all work together.
It would take more than 'a few hours'. I would say, even if you are a ROR master, you're looking at a year to two years of solid consistent work to get the best parts of Drupal for a new system.
I just saw that whitehouse.gov is using drupal as a CMS and portal technology.
One of the advantages of drupal seems that it is easy to add plugins and that programming is minimum, i.e. that re-inventing the wheel is at minimum. That is actually exactly the DRY philosophy of Ruby-on-Rails. So:
What are the drawbacks of drupal?
What would Rails or other Ruby based technologies disqualify as portal technology for whitehouse.org (or other CMS portals) ?
What are the drawbacks of drupal?
This is really a quite subjective question in relation to Ruby and Rails. Drupal is a solid content management option and really shines for community-oriented sites. It is useful for general purpose content management for non-portal sites as well. The drawbacks would be that it is built on PHP, if you are a Rubyist then that is a significant drawback. Additionally it is a beast of a project if you are looking at just the core. The API is quite large which is fitting for a project like Drupal, but this can make getting substantial customization done into a lot of coding work. Also, because of the whole architecture of Drupal there is no clear separation of data types unless you write a custom module that makes a clear separation and while this is in keeping with the "Drupal way" it is a little odd to some to think of EVERYTHING as a node or within the structure of Drupal's Taxonomy system or the like.
The biggest drawback to Drupal really can be best summed up this way: in order to make effective use of Drupal you really need to know and understand Drupal in a way that you don't for a CMS system like Radiant; but Radiant is nowhere near as complex as Drupal.
What would Rails or other Ruby based technologies disqualify as portal technology for
whitehouse.org (or other CMS portals) ?
Rails is rather dissimilar from Drupal in that it is not really a content management system at all but a more general purpose application framework. You can use Drupal in ways similar to Rails, but Drupal is really much more than what Rails is. Better comparisons could be made between Drupal and say Radiant or BrowserCMS or some of the other Ruby/Rails CMS packages. There are Ruby/Rails portal systems out there but few match the bulk of Drupal and it's community. The most comparable options in the Ruby ecosystem only match bits and pieces of what Drupal can do, but that is because Drupal is that massive a project and a community. Drupal is a swiss army knife plus some for doing sites on the web. Ruby doesn't have a truly similar project out there because most Rubyists don't see any reason to duplicate Drupal's girth.
I would recommend the following projects as things to look at if you are considering use Ruby in place of Drupal (most of these Ruby projects will cover less than Drupal but fit closer with your site's actual needs):
Radiant
BrowserCMS
Lovd by Less
Community Engine
Quite subjectively, I find the Drupal administration interface a bit clunky. You can try it out for yourself without actually installing Drupal at opensourcecms.com. That being said, there seem to be a great momentum in Drupal community at the moment, and it's starting to become a really full-featured CMS.
Comparing Rails to Drupal is somewhat like comparing apples to oranges. Rails is an application framework and Drupal is a CMS (although with a kind of application framework included).
allesklar, what is wrong with the extension system within Radiant? There are plenty of Rails CMS out there already. I suspect contributing to an established system to improve it would be more productive for the community at large than creating yet another niche CMS.
I'm a Rails developer so I'm all for Rails solutions but presently there is no Rails CMS that comes any close to a CMS such as Drupal in terms of functionality and plugins.
I attribute this partly to the 'less is more' philosophy advocated by 37signals.
Wordpress, Drupal, and others go for 'as many features as possible' and doing such end up attracting masses of users who will find that these products do answer their needs.
I've been playing with the idea of, like many others, starting a Rails based CMS system with plenty of features and a good plugin architecture. No time to work on this yet though between client work and development of an hosted application I'm working on.
I just found this site:
drupal and rails
If you are looking for portal technology built in Ruby, a relatively new candidate to consider would be EngineY. EngineY was originally built as a social networking framework but also has features that make it a viable candidate as a traditional portal. EngineY's concept of a 'widget' is similar to a traditional portal's portlet. There is a Managed Content widget included with EngineY that lets you create a portal made up of managed content. Best of all is that EngineY is very actively maintained and is evolving and improving daily.
In my next rails project I'm going to need blogging functionality. I'm wondering whether anyone has any good suggestions, or should I just roll my own? (Probably not in 15 minutes)
I think the most important feature will be to display code samples elegantly.
How's your free time?
Five years, that's how long that little idea took. Plus 2 years of adding bells and whistles. And that, folks, is why I'm giving in and using a blog host. Because I have lots of ideas, lots of things to say and to explore, but only a few dozen years left at best. I can't afford to go chasing every 5-year idea that springs to mind. After due consideration of the crap web frameworks and crap blog packages out there, I decided that I don't want to spend my next 5 years implementing my vision for a decent self-publishing system. Someone else can do it.
http://steve-yegge.blogspot.com/2006/03/blog-or-get-off-pot.html
It's a classic build-versus-buy (or, in this case, download for free) decision isn't it?
Write up the feature set of what you are looking for.
Survey the offerings out there to see how close a fit you have.
For the one or two products that is the closest fit, evaluate whether or not it would be less effort to write your own solution or customize the offering to do what you need.
If all you need is a blog site, then this is a no-brainer. Use WordPress and that's it.
If there are other features for this app and blogging is just one of them, then consider writing an app around WordPress. It is just a PHP application using MySql after all.
If WordPress has features or does things that you don't want, then maybe you do need to roll your own.
If the most important feature for this site is that it is to be written in RoR, then roll your own or find a RoR based blogging app as WordPress is not written in RoR. I haven't really done the homework on this but I would imagine that getting PHP and RoR to share session state would be a time consuming hack.
Rolling your own blog is a great project (and quite fun too!), but for practical usage, using something pre-made is going to be more secure, have more cool features, etc. etc. Unless you're incredibly dedicated, you'll probably end up cutting corners and end up with something that isn't quite what you want.
Despite being a Rails guy myself, I'm a huge fan of Wordpress. If you're looking for Rails-based blog engines, I've had luck with Mephisto, although the documentation leaves something to be desired. Radiant CMS is another CMS/Blog system that might be worth looking at.
A lot of Ruby/Rails developers have actually gone the route of using static website/blog generators. This has a few advantages. First, the pages are static HTML with no dependency on a database. This means they can be served by your front-end Web server (Apache, Nginx, etc.) faster than if they were to go through Mongrel, Thin or Phusion Passenger. Secondly, the pages will be easier for search engines to index. Finally, and probably most importantly, you can easily version control your posts using Git (or your favorite SCM)
I switched my blog over to a static model after development on Mephisto seemed to stall. I am using Tom Preston-Werner's Jekyll and Disqus for the comments. Works great. Give it a try!
If you are just looking for a project, then building your own blog engine is a good start.
Personally, though I have been a full-time Rails developer for the past 3 years, I still use and recommend Wordpress for myself and others.
If the project is to write a blog, don't roll your own. There are plenty solutions out there that will solve this problem for you while you worry about pumping out great content.
You will end up spending to much time futzing with the little things that don't really matter.
Probably there are tons of those.
For example, Rastafari, or Enkiblog.
In my next rails project I'm going to
need blogging functionality. I'm
wondering whether anyone has any good
suggestions, or should I just role my
own? (Probably not in 15 minutes)
I wouldn't recommend rolling your own blog system. You should look into using Radiant CMS with a blog extension.
I think the most important feature will be to display code samples elegantly.
For this I can recommend looking into SyntaxHighlighter.
All depends on your goal:
If it is for learning purposes and it's for fun, code it from scratch. Also, try to add new functionality that you will not find in current blogging platforms. For example, make in a way that is easy for a developer to blog tutorials or screencasts.
If it's for a client or just to blog, use wordpress. You can have your site in ruby and then link to wordpress. Think about it, how many human hours are behind wordpress so for you to match that you will need to work full time on it for 8 years.
Wordpress will work out of the box and then periodically you can tweak it, depending on future needs.
I agree, for fun and learning, code from scratch. But consider coding something people really need and don't already have. Innovate.
There are so many excellent blog platforms out there, and some (like Wordpress) have active developer communities writing hundreds of useful and powerful plugins. And that includes some excellent support for code samples.
No need to reinvent the wheel.