Related
Just got a new website project for my company internal use. The whole website isn't that complicating but requires quite a lot of real time interaction. Basically, it's an interactive time line table where we can freely drag and drop each elements to move and resize them.
At first I wanted to use this opportunity to learn Python+Django (I'm given a huge amount of time) but then I read around and a lot of people mentioned Rails is better for creating rich interactive website.
So, for a website with a lot of drag & drop interaction like this, is Rails really the better choice? Is Rails built-in ajax that much easier to work with compare to Django+jQuery? How flexible and customizable is Rails' built-in ajax? I want to learn RoR just as much as Python by thee way.
I don't think AJAX functionality will define which framework you find yourself preferring.
I can't answer most of your question relating to ajax, but still think this post could be useful for you: it's highlighting a huge difference between ROR and django -- mainly RoR uses magic, django doesn't.
I prefer django for exactly that. Others may prefer RoR for the same reason I don't.
What's wrong with "magic"?
Rails' developers are of the opinion
that this sort of "magic" is a good
thing because it makes it easier to
quickly get something working, and
doesn't bore you with lots of details
unless you want to reach in and start
overriding things.
Django's developers are of the opinion
that this sort of "magic" is a bad
thing because doesn't really save all
that much time (a few import
statements isn't a big deal in the
grand scheme of things), and has the
effect of hiding what's really going
on, making it harder to work out how
to override stuff, or harder to debug
if something goes wrong.
Both of these are, of course, valid
stances to take, and generally it
seems that people just naturally
gravitate to one or the other; those
who like the "magic" congregate around
Rails or frameworks which try to
emulate it, those who don't congregate
around Django or frameworks which try
to emulate it (and, in a broader
sense, these stances are somewhat
stereotypical of Ruby and Python
developers; Ruby developers tend to
like doing things one way, Python
developers tend to like doing things
another way).
So I think one will click for you regardless of out of the box ajax support.
Speaking as someone who mostly works on Rails, I would say take a day with each framework, follow a "getting started" screencast or tutorial, or pick up a book. ( For rails, I recommend Beginning Rails 3 ). Then, keep going with whichever one you feel more comfortable with.
One amazing resource rails has is Railscasts. Railscasts almost single-handedly converted me from PHP to ROR. I don't know if Django has a similar volume of quality screencasts available or not.
All frameworks are pretty heavily focused on the server-side of the equation. Now, Rails has a lot of things that help make writing views (your drag and drop stuff) nice, such as HAML (a fantastic template language)... and while I don't know enough to post links I'm sure Django has similar helpers. It's worth noting that both Django and Rails can use jQuery or any other javascript framework.
But, in the end, just by the nature of the web as stateless, there's going to be a degree of independence between your client-side templates and javascript, and what's serving that from the server side.
The real question you should probably be focused on is: Do you want to become a jQuery ninja, or do you want to scale up a notch and focus on Javascript itself, perhaps using tool suites like MooTools or Prototype. Your drag and drop stuff is client-side, so that's where your toughest decisions will have to be made.
Good luck!
I used to worry about things like this and would try new frameworks all the time because people would say it was a big improvement over the last one I was using until I realised I wasn't doing anything. Now I just pick one and stick with it. The fact that I know it much better than any others means I am more productive, even though the other frameworks probably include nice little tricks and shortcuts, and because I know it better I can debug problems faster.
Basically what I am trying to say is that just about every popular web framework can do everything that you want it to. Some are better than others but what really matters is that you become an expert in at least one of them. Being able to dabble in lots is not helpful, you really need to know one inside and out. Committing some code to the project helps this process.
Mainly depends on which programming language you prefer to work and most comfortable with. Some prefer the flexible syntax of Ruby others like the cleanliness of Python. Also need to take into consideration the production environment (aka what OS is it going to be hosted on).
Django does not do interactive web applications, it is agnostic to the whole "frontend" part, this is done in Javascript with little to no support from Django (except for transferring data from AJAX calls).
So if you want to use Django for this, you will have not only to learn Python but also to learn loads of Javascript.
I like this solution as hand-written Javascript feels a lot clearer than any of these generating tools to me, plus there are plenty of libraries that make writing advanced Javascript GUIs a breeze these days, check out Jquery UI or ExtJS.
From there, the server side will only be AJAX calls that (de)serialize data in JSON, nothing else.
Both Rails and Django are good. Try them both out and see which you like better.
I'm working on a application that requires a feature-rich media view, including images, videos, and smooth sequencing based on capture time. The backend is currently written in Rails.
What's currently the best, most mature option for implementing RIAs with Rails on the backend? I've looked at Flex, Laszlo, and ExtJS. ExtJS is interesting to me because I'm really not a fan of pure Flash UIs, but it seems highly targeted towards business apps, not entertainment applications like this.
Any suggestions or insights from others doing similar efforts will be very much appreciated.
Thanks!
I second zdmytriv for that book Flexible Rails, it's awesome. It's fairly outdated now though but lays out how simple it is to create a solid Project Management application with Flex and Rails. Everything in there has now become "RestfulX".
Check out RestfulX, it's a must. The RestfulX Google Group is very active too and they've made a lot easy.
We built this website in Flex with RestfulX and it was very easy. That application uses the Rails Paperclip gem to do image processing in a Flex admin panel like ScrapBlog (Scrapblog was built in Flex), and we could use some cool layout effects built into Flex 4. RestfulX made that pretty easy, and the gems made it even easier :p. They have generators too like Rails so it's real easy to get up and running with a DataGrid/CMS-like interface in 5 minutes.
I don't know anything about the other things you've mentioned, but I do know that it's pretty fun and easy to integrate Flex with Rails now-a-days.
As a side note, you can do hardcore SEO with Flex and Rails too, thanks to SWFAddress. We're doing that with that site above.
Cheers
I can recommend Flex and also this book Flexible Rails, whole book dedicated Flex with Rail cooperation. List of sample applications from the book here
Flexible Rails http://ecx.images-amazon.com/images/I/51QysfVDlVL._SL500_AA240_.jpg
If you're serious about considering Ext as an option, you should really search and maybe post in their forums about others using Rails, I know there are quite a few doing so successfully. I just ran across this example that seems like a pretty fully-baked app doing just that, so it's definitely possible.
Without knowing exactly what you're trying to do, I think that saying Ext is "targeted towards business apps" is a fair general statement, in terms of the widgets that come with it out of the box. It's highly geared toward window/form-based Ajax apps. That said, Ext Core is very similar to jQuery and other core frameworks, and everything in Ext is built to be highly extensible (hence, "ext"). In terms of being able to build what you need off of it, it is very powerful and flexible. You can certainly implement a flash viewer easily, and there are existing plugins that will do exactly that.
Sounds like Toby had a bad experience with Ext, but many other people enjoy it and find it very natural to code in. The syntax definitely has a Java/C# flavor to it in some ways (although it's really hard to directly compare any JS framework to a static language), and it has roots in YUI (which is even more verbose). For someone coming from C-ish backgrounds, it will likely feel very comfortable. If you're more used to Python or Ruby or something else, then it might not be as enjoyable, I don't know. Something you'd have to try for yourself.
Take a look at WebOrb from themidnightcoders.com. Among many features, it allows for AMF protocol for serialization of data. It is smoking fast.
IMO, if you want a true RIA experience, you'll need to focus on either Flex or Silverlight. There are pros and cons to each.
I did a GWT project a while back and am working with Ext right now. I have some C# / Swing GUI experience, none in Flash.
I like Ext a lot. It looks great, and I found the programming model close enough to the C#'s and Swings of the world as to be familiar and fairly pleasant. The documentation is not excellent, but definitely good enough. For Java at least, there is a solid remoting mechanism (third party, called DJN... most likely there are others, too). A couple of minor bugs here and there.
The major negative is support. They have a forum but there are a distressingly large number of questions and problems that go unresolved. They have paid support in theory, but were sufficiently unresponsive to basic 'how does your paid support work' type questions that I was not encouraged to buy any. There is only one book that I know of, it looks promising but it is not out yet.
I found GWT impressive and had no real problems, but at the end of of the day I am much happier with Ext.
Have you taken a look at Google Web Toolkit yet? In my opinion it's a great way to build rich and performant web applications. The toolkit is quite mature (Google Wave is build with it) and has a lot of good tools to make development easy.
Here's a previous Stakoverflow post.
I don't know about best, but I did a project using ExtJS and hated every minute of it. Frustratingly verbose code, overly complicated programming model, confusing documentation, and difficult to make it do anything it didn't want to.
That said, it looks very awesome, has incredibly powerful widgets and the client and users loved it.
I haven't helped at all, have I?
I think if you requirements include doing anything with video and audio, you are going to need a Flash solution.
Take a look at netzke -- client-server components with Sencha Ext JS and Ruby on Rails.
Netzke is a framework that allows for a beautiful blend of client- and
server-side code (JavaScript and Ruby, respectively) into ready-to-use
GUI components. It's most useful for creating complex data-rich
backend applications with Ruby on Rails on the back end, and Sencha
Ext JS in the browser.
I've been reading up about HAML/SASS lately and I'm not quite sure why any one would not want to use it. It seems to be very easy to switch, makes things cleaner and more efficient.
Update:
What about using one or the other? Most of the complaints (the few complaints there are) I hear seem to be about HAML, would there be any problems mixing and matching XHTML/HAML and CSS/SASS?
Update:
Sorry, one final update to the question. It seems to me that switching back from SASS to CSS is painless and simple. What about switching back from HAML to HTML?
If you're using Rails, yes. Go for it. Some issues you will hit, though, will be that any other developer brought onto the team later will have to learn it, as well. If you're already working with a big Rails crowd, that's fine, but HAML/SASS may confuse a designer who's worked with pure HTML/CSS for years.
If you're not using Rails, though, a good HAML/SASS integrated system is hard to come by. There are a few out there, but I imagine they're not as well-supported or as far along with the spec.
But, yeah. HAML/SASS is definitely worth it. The only real issue you'll hit is that it's not yet standard.
As for mix-n-match, HAML and SASS are so similar in style that I'd say go for both, but it, again, comes down to personal preference. Try using both for a day, and if you don't like one of them, switch back. There's no technological issue about it, so do what you prefer.
There are lots of tools for working with HTML and CSS. The syntax isn't pretty, but the improvements from HAML and SASS don't seem that dramatic to me, and for many they're not worth the trouble. Of course, for those developing web application with widely differing frameworks (differing from Rails that is) it's even harder to find a reason to go to the pain of integrating something so foreign. (Example: care to explain what I'd have to do to integrate SASS into my Java/Stripes/JSP environment? :-)
I've been on volunteer projects where HAML's syntax curve (syntactical whitespace, the automatic generation of tags etc) has been seen as a barrier: one more thing for a programmer new to the project to learn.
Personally, I think SASS is worth it, but I'm up in the air about HAML: having debugged HAML templates before it seems like the typing you don't have to do with HAML is overcome by the time you spend debugging why there's an error on your templates. This could be a (HAML) newbie's perspective though.
I'm inclined to agree with the question; it is easy to switch, the syntax isn't that complicated, and it does make things cleaner and more efficient. It also makes it harder to unwittingly generate invalid HTML.
I also think the learning curve is shallow enough that a programmer that can't handle it, is probably a programmer you are better off without on your team. That might sound harsh, but I believe it.
The only cons I can see would be if you are developing in ASP.NET or something where retrofitting Haml and Sass would be a pain, is way unexpected for anyone else used to the platform, and possible a chore to maintain in a production environment. On Rails though, go for it.
I don't think that using HAML ever adds much benefit to a project.
SASS, on the other hand, effectively introduces variables and computations and other really useful features that save you time and effort in the long run on larger projects.
Using SASS is incredibly smart with any project that's larger than just a simple one-page form.
I tried using SASS but found that editing CSS using MacRabitt's CSSEdit (Mac Only) was way easier and more efficient for the way I work. I'm a very visual person and like to have a live preview when making changes to style sheets and didn't feel like investing a ton of time into something I wasn't having a problem with.
One thing most people don't realize is that HAML sucks for content. It's great for structural markup, but don't try and push it too far. (You can mix & match HTML in your HAML file, too!)
Sass is absolutely indispensable, especially in the long run. It's not just about writing the stylesheets when you have it all in your head, but about maintaining them down the road. The new Sass3 takes the syntax question out of the equation: you can take your pick if you prefer the curly-bracey SCSS syntax.
HAML/SASS may indeed be awesome to use, but they do introduce dependencies both technical and knowledge-oriented. This may not be an issue if your dev and prod environments are controlled and predictable enough, with newbies receiving enough training (or being vetted for subject knowledge on the way into the organization) to hit the ground running, but all of that is overhead to be acknowledged.
why is this..
%p
hello world
better than this..?
<p>hello world</p>
clue.. If you aren't doing ruby, it isn't. Unfortunately adding closing tags and braces isn't really the most challenging aspect of making webpages, so most professionals wouldn't really care. Use whichever you prefer.
From a developer's perspective, Haml and Sass absolutely rock. However: from a designer's perspective, Haml and Sass might not be readable. It really depends on who is on your team.
If it's a bunch of developers and/or designers who aren't afraid to learn a DSL, then absolutely go for it.
If you have a mixed team where designers toss their CSS and HTML work to developers who translate that to Haml/Sass, sure.
If you have a design team that passes work to the developers AND the work flows back to the designers, you may not want to use this because the designers might not be able to use their tools to edit the files.
If you have a small team where marketing and business people need to edit the web pages and they only know HTML and a light bit of CSS, then you probably shouldn't use Haml/Sass.
However you can't really make a blanket statement here. Consider that at least with Rails you can mix the template types in your views. So, some of your templates can be plain HTML stuck in .erb files, and other pages are .haml files. You can have partials be of one type inserted into templates of another. (I think mixing types is probably a bad practice, but if you just need to "get the job done" then it's an option.)
I am using SASS on a Django project right now. I like it and am going to continue using it. One problem I've found however is that error messages aren't always particularly intuitive, particularly if you leave off a }.
I have a created a userdriven gallery with Ruby on Rails.The site is using a few plugins to create friendly links, permissions, pageless pagniation etc. The application controllers and views has gotton quite complex and I find it difficult and very time consuming to work with. So I thought about rebuilding the app with hobo, as it includes all the user and permission logics and another template system. However I am affraid that I will be to limited, or maybe not win anything becasue I will loss a lot of time hacking hobo. I am planning to add frinedships and personal messing to my website. Could this be to compelx for hobo? Does hobo use jquery?
Best regards.
Asbjørn Morell.
Hobo is not that complex, however you would need to study documentation which takes some time. But, in the long-run any refactoring such as Hobo could help, if the code is currently getting unmaintainable.
JQuery can be used in any sytsem as it is independent of script frameworks etc. AFAIK,
No one can tell you if Hobo will help your specific program.
That said, I have been using Hobo for a while and I have found it to be very effective. It handles a good part of the standard rails logic every site needs (such as routes). The dryml system has been useful in my work as well, reducing the size and complexity of my views.
If your code is becoming unmaintainable and you feel a refractor is necessary, you could definitely do worse than Hobo.
i have been building a few hobo apps and they work rock solid, problem is dryml is quite peculiar and you must learn and do a lot of test and try, but in the end it allways comes along quite nicely. i recommend you start quickly with hobo and you will end up faster..!!
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.