4 ms·

I won't use Sass, Haml, LessCSS or things like that until I see Sass, Haml and LessCSS in Firebug or View Source (or whatever your choice of web development too

by Pistos2 17y ago

I won't use Sass, Haml, LessCSS or things like that until I see Sass, Haml and LessCSS in Firebug or View Source (or whatever your choice of web development tools). The claimed benefits are nice in theory, but I think it is a debugging roadblock to have to mentally translate and associate your source code with what the web server serves. If I code in CSS and HTML, that problem is practically nonexistent (excepting things like templating). The CSS and HTML the web server serves are the CSS and HTML in the source code.

oscardelben 17y ago
Maybe I've misunderstood your post, but what's preventing you from seeing the generated code in your browser?
- Pistos2 17y ago
  Indeed, generated code is seen in the browser. The issue is that the generated code is not the source code when you use Haml, Sass, etc.
rufo 17y ago
Haml is literally a one-to-one relationship with HTML tags, so there's almost zero mental overhead. If anything, the tight relationship between indentation of HAML and outputted HTML makes it far easier to debug things, and I haven't had to debug a pesky missing closing tag bug in eons. Sass is slightly more difficult, but by default in development mode it outputs comments describing which Sass rules generated the CSS you're looking at, so it's not too difficult to go back - and it's a far simpler language than whatever you're coding your app in. Honestly, I don't see it as being any different than (as you point out) translating the outputted HTML/CSS back into ERB/PHP/etc, or as difficult as trying to trace output backwards through your codepath.
rubyrescue 17y ago
to further the point, when you EDIT styles in the browser, you are always working on the generated file. Editing styles in the browser is WAY more common than editing HTML in the browser, and because the tools with which you edit the CSS in the browser generate CSS, it becomes much more tedious, ironically, to do a lot of CSS work, then convert to Sass.
- rufo 17y ago
  Perhaps it's just the way I work, but generally if I'm adjusting CSS in the browser, I'm previewing how some potential changes will work. I already know what the affected class is (since I'm editing it inline), and I've already targeted the CSS I'm about to modify, so once I'm done previewing it's a simple matter to go back to the Sass and change things around.
jlong 17y ago
All I can say is try it for a while. A month or two at least. I don't think the issues that you are anticipating are as great as you think they are.

by Pistos2 17y ago

oscardelben 17y ago

Maybe I've misunderstood your post, but what's preventing you from seeing the generated code in your browser?

Pistos2 17y ago
Indeed, generated code is seen in the browser. The issue is that the generated code is not the source code when you use Haml, Sass, etc.

rufo 17y ago

Haml is literally a one-to-one relationship with HTML tags, so there's almost zero mental overhead. If anything, the tight relationship between indentation of HAML and outputted HTML makes it far easier to debug things, and I haven't had to debug a pesky missing closing tag bug in eons. Sass is slightly more difficult, but by default in development mode it outputs comments describing which Sass rules generated the CSS you're looking at, so it's not too difficult to go back - and it's a far simpler language than whatever you're coding your app in. Honestly, I don't see it as being any different than (as you point out) translating the outputted HTML/CSS back into ERB/PHP/etc, or as difficult as trying to trace output backwards through your codepath.

rubyrescue 17y ago

to further the point, when you EDIT styles in the browser, you are always working on the generated file. Editing styles in the browser is WAY more common than editing HTML in the browser, and because the tools with which you edit the CSS in the browser generate CSS, it becomes much more tedious, ironically, to do a lot of CSS work, then convert to Sass.

rufo 17y ago
Perhaps it's just the way I work, but generally if I'm adjusting CSS in the browser, I'm previewing how some potential changes will work. I already know what the affected class is (since I'm editing it inline), and I've already targeted the CSS I'm about to modify, so once I'm done previewing it's a simple matter to go back to the Sass and change things around.

jlong 17y ago

All I can say is try it for a while. A month or two at least. I don't think the issues that you are anticipating are as great as you think they are.