I’m not sure if this has ever been discussed, but I couldn’t find it in the issues, so I’ll assume it hasn’t.
Over time HAML and Slim have been more and more used as html preprocessors instead of ERB. As we moved CSS and JS preprocessor to more elegant, indentation based ones, such as Sass and CoffeeScript, I wonder if it would not be a good move to do that for the HTML preprocessor as well.
There is much to gain:
Cleaner syntax
Less code and boilerplate
HTML minification by default (in the case of slim)
As to what we might loose is speed, which in the case of slim is not that much when compared to ERB.
Maybe I’m missing some huge reason why this change has not happened yet, but either way I believe it is worth discussing.
Hi Luís, personally I don't think HAML or Slim add much when compared to ERB as Sass (in special) and CoffeeScript add to CSS and JS respectively.
SASS enable developers to add variables to CSS while still being compatible with plain CSS so it's like a no-brainer as a good default in my opinion.
CoffeeScript is a mix of new interesting features, less boilerplate and personal taste. Some don't like it and won't use it, but I personally prefer CoffeeScript over JavaScript. But you can't deny CoffeeScript allows you to develop JavaScript classes more easily/ellegantly at least.
For HAML or SLIM, it doesn't provide any actual new feature over HTML/ERB. It will only provide sugar allowing developers to write HTML with less code but in the end it boils down to personal developer's taste. I don't have any strong opinion with regards to HAML or Slim, but differently from the JavaScript case I don't feel the pain of writing HTML. My code editor (Vim with plugins) already allows me to write HTML as quickly as writing Slim templates with a few keybindings and I don't have any problems reading HTML code. On the other side I don't think I would have any trouble reading/writing Slim/HAML code either. It's simply a matter that I don't see any significant advantages of Slim/HAML over HTML/ERB...
I agree that it mostly syntactic sugar, but a lot of people are going towards that. I personally think it increases readability, which is something I always try to improve, but as you’ve said it is a personal opinion.
The reason I raised this question is two sided, firstly just to understand if this had been discussed and what came out of that discussion, secondly to see how the community feels about this. Because even though it is about personal developer taste, if enough developer like it, then it becomes the community’s taste and we should try to adapt to that. Not saying this will be the case, but it is at least a possibility I’m willing to entertain.
I don't think this is how it works with regards to Rails, otherwise RSpec would be the default test library rather than test/unit
Remember that for a long time Prototype remained the default JS library bundled with Rails even if jQuery has always been the preferred one in the community, so this is not how things work with Rails. As far as I understand, if you want to change the omakase, you must convince the chef and no one else:
Rails core prefers ERB because you get what you see and in this case that
wins for our taste. The simplicity of ERB outweights for us the benefits
other people see in those template systems.
Rails ships with that default, and also allows you to switch to whatever
you prefer.
IMO the amount of boilerplate code that comes with ERB is not only unnecessary but adds visual noise to the understanding of the view code. That being said, it is really easy to switch, so the issue here would be more of what we want to encourage versus being able to do it.
I understand and respect your choice, and from your response I deduct it is not going to change in the near future.
Personally I prefer HAML over erg or slim, slim is to hipster and hate the “|” thing. After working with Rails project for about 5 years, I do understand why rails core don’t want to change ERB, basically is easy for new people, there is almost no learning curve and it’s easy for non developers to change stuff in the code.
