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 }.
Related
which features you would like to have in Ruby on Rails, or maybe which features you find incomplete or bugy?
It's honestly a pretty full-featured framework. After using it professionally for two years, I have never come across anything Rails couldn't handle. In fact, quite the contrary, I'm constantly finding more and more amazing features I wasn't previously aware of.
Plus with the concepts of gems and plugins, the sky is the limit.
The more you use it, the more you'll love it.
Some things are easier done in pure SQL than ActiveRecord, and some are just impossible without SQL. This breaks the abstraction somewhat.
Since the creation of Engines, modularity & reusability made a huge leap which is great.
I'm wondering whether we'll need another abstraction layer for rich js interfaces. To be a more constructive, I'd personally appreciate to organize my js file the same way I organize my helpers.
#RocketR remark is totally right, as well as tybro0103 conclusion :)
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 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'm planning on taking the time to actually learn Ruby on Rails in-depth (I've previously done some very minor dabbling with it) so I can hopefully reinvent myself as a Rails developer.
The issue I run into though is that there are a fair bit of related technologies that are currently used in the Rails community, and I'm not sure if I should learn the whole shebang or focus on learning Rails with the defaults first, and then branch out into the additional stuff.
For example:
Templates. I took a look at Haml and it looks really cool (shouldn't be hard to learn either).
Testing. I've wanted to learn test driven development for a while now, but the "next big thing" in Rails-land seems to be behavior driven development with RSpec
Javascript. I'm not sure if I should stick with RJS or use something like jQuery which seems to be converting people.
I've never really used version control much. Rails seems to be using Git for most of it's projects.
Basically I want to learn Rails "right", but there seems to be a lot of different ways that I could go. Should I ignore the "variants" and focus on the Core stuff until I've written an application or three (e.g. core, unmodified Rails; RJS w/Prototype and Scriptaculous for Ajax, regular Test::Unit for testing, ERB for templating, Git for version control), or should I try to pick up some of the variants along the way?
If you want to do well in the rails world you should plan on learning (and relearning) things on a regular basis. It isn't as hard as it might sound, but it is important. I'd suggest you make a list of things to learn, and just work your way down it doing by getting an hour or so of hands-on-time with something new each day. If you feel like there's more to learn (or that the subject is in flux) throw it back on the tail of the list to revisit another day.
A starter list (yours plus a few you didn't mention), in no particular order:
erb
gems
acts_as...
test driven development
git
rspec & behavior driven testing
javascript
prototype.js
jquery
sql
rail's finders
rake
the rails console
plain old ruby
duck typing
ruby's metaprogramming facilities (how the magic is done)
css
rails generators
And so on and so forth. As you're going through one and come across something interesting, throw it on the list.
The point is, if you try to take a narrow view you will probably make life harder on yourself and learn slower than if you make a commitment to perpetually, steadily expanding your horizons.
I've been a full time rails developer for over a year now and what you use really depends on what kind of team you end up on. I've barely used RJS, have never used RSpec, but I use git, jquery and rails every single day.
My Advice: stick with rails for at least a few months. There is plenty to learn in the framework alone. I would consider ignoring RJS as I feel like it's going out of "fashion" as developers trend towards jQuery.
Regular Test::Unit is great, although I like to add thoughtbot's Shoulda to provide some testing macros that save a whole lot of time (consider ignoring all the Shoulda context stuff though).
Learning git feels pretty important IMHO, mainly because it's a great and is gaining quite a bit of popularity. It also enables you to feel comfortable using github, which can be a big advantage.
I'd recommend starting out with the basics of Rails. Haml, RSpec, jQuery, and Git are all great things, but if you try to learn it all at once, you may become overwhelmed.
I would start with the defaults first, as I agree with Matt's comment that trying to learn it all at once would be overwhelming.
Plus it may turn out that depending on your applications you may or may not need jQuery, you may be happy with the default testing, and there are tons of ways to do templates so starting with ERB to get the basic understanding of how the view/templating works is a good idea.
Once you get more experience and know exactly the requirements you will have for your application(s), you can then more easily pick up and swap out some of the variants.
Git is important. Make an account on github, install git, and get used to it - you need some kind of version control, might as well make it the new cool buzzwordy one.
The other stuff, not so much. Bang out a few applications and then add them in one at a time.
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.