Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Less.js will obsolete CSS

fadeyev.net

Post reply on HN
Print view View original

81–90 of 131 posts

Re: Less.js will obsolete CSS

#81

Post by GavinB »

danieldon wrote: post #59
trebor wrote: post #43

Earlier quoted context omitted.

Obsolete is a verb, but it is a poor choice. A better choice would be obsolesce, as in: "LESS.js will obsolesce CSS". This is because LESS.js won't obsolete CSS, but it may well start the industry on the path. Obsolete has a feeling of immediacy to it, and obsolesce has a feeling of lethargy or a gradual process which is why it's the better choice. It's an opinion, take it with a grain of salt. (BTW, I dislike MW bec…

Obsolete is a verb, but it is a poor choice. A better choice would be obsolesce, as in: "LESS.js will obsolesce CSS" "Obsolete" is the correct word because it's a transitive verb (eg, [subject] obsoletes [object]), while obsolesce is an intransitive verb (eg, [subject] obsolesces).

I would have gone with "Less.js Will Render CSS Obsolete."

Re: Less.js will obsolete CSS

#82

Post by isleyaardvark »

kellishaver wrote: post #73
IgorPartola wrote: post #54

Earlier quoted context omitted.

CSS is far from easy to use correctly. CSS is very poorly designed. Aside from all the browser hacks it's core constructs often times contradict each other (think float vs position). We do need something better but I'm not sure if LESS is it. I would much rather see something built into browsers directly.

I hear this all the time and I really just don't see it. I'm not trying to be argumentative, I just don't understand. Yes, it is poorly designed, no question about that and there are certainly things that could be done better, and one shouldn't have to use all of the "hacks" to begin with. But I do find it incredibly easy to work with, and I'm often doing very complex layouts that have to work in everything from IE6…

The value it provides is it simplifies CSS, helping maintainability and preventing repetition. It's not a replacement for CSS, it's just a way to make dealing with CSS easier. The syntax is easier and since it's a superset of CSS, you can keep on using plain old CSS syntax if you want. It adds more options and more flexibility.

Variables alone make LESS/SASS worthwhile, but even putting those aside, let me give you an example of added value: importing other files. With LESS/SASS you can import different files, and they get compiled into one CSS file. With CSS if you use @import, you've got an additional HTTP request, which negatively impacts performance. LESS/SASS gives you additional flexibility in organizing your CSS. In LESS/SASS you can just go to the individual file that deals with typography, as opposed to the tricks designers have used to find things in a large CSS file (e.g. putting a table of contents at the top of the CSS in comments, with a unique string for each section, which you then use Ctrl-F to look for to find the section of rules you're interested in.)

I'd recommend trying it out on a small project if you haven't already, to see for yourself.

Re: Less.js will obsolete CSS

#83

Post by mhd »

edanm wrote: post #24
weego wrote: post #5

Earlier quoted context omitted.

There is genuinely a tiny benefit because you don't need to declare colors etc more than once, everything else about it is trying to wedge ideas from other areas of programming into a language that contains so many abstract concepts as to not benefit from it at all. I've worked as a UI developer for 12 years now and I wouldn't go near something like this because there is no value. At least the server side version you…

Let me give an example use case, something I've wanted. Lots of developers will tell you that it's fine to use systems like the 960 Grid System for rapid prototyping, but you shouldn't use them for final, "production" sites. Their argument is that "littering" your code with classes like "grid_4", etc. is not semantic (and they're right). So here's what I would love to do: use a system like 960 in development, but ins…

Isn't that basically what compass does?

http://compass-style.org/

Re: Less.js will obsolete CSS

#84

Post by Daniel_Newby »

what wrote: post #64
rabidgnat wrote: post #53

Earlier quoted context omitted.

There are plenty of problems with CSS. You can't specify the width of an inline element, for one. That alone prevents a lot of reasonable layouts, like tables. Also problematic is a standards body that ignores this use case! In this case, they protect the writer from over-filling some boxes with more boxes. But that would at least be visible - in this case, the workarounds end up far worse.

If you want a table layout, why not just use a table? Or you can use display: inline-block if you want to give a width to an inline element.

Tables FTW. It's the HTML element for controlling horizontal and vertical relationships at the same time.

Re: Less.js will obsolete CSS

#85

Post by unfletch »

jomohke wrote: post #14

We used Less for a project, but ended up moving to Sass: http://sass-lang.com/ The Sass compiler was (is?) more mature, and the language feels more consistent (see the '&' operator in Sass vs the :hover special case in Less). The editor/tool support was quite a bit better too. Sass doesn't have a javascript in-browser implementation (afaik), but for rapid development it can watch a folder/file for changes and automat…

FYI, Less.js isn't just a javascript port. It adds new features, and the "&" selector is among them.

That said, I agree that SASS is more mature. I've used each on at least two projects now, and, with the release of SASS 3.0's and SCSS, I'm committing to SASS. This client-side parsing is a cool trick, but it's easy to do my CSS generation at the same time as my javascript minification. I just don't need it.

Re: Less.js will obsolete CSS

#88

Post by rabidgnat »

what wrote: post #64
rabidgnat wrote: post #53

Earlier quoted context omitted.

There are plenty of problems with CSS. You can't specify the width of an inline element, for one. That alone prevents a lot of reasonable layouts, like tables. Also problematic is a standards body that ignores this use case! In this case, they protect the writer from over-filling some boxes with more boxes. But that would at least be visible - in this case, the workarounds end up far worse.

If you want a table layout, why not just use a table? Or you can use display: inline-block if you want to give a width to an inline element.

I run into plenty of situations where I have multiple lines, and I'd like the respective elements to align. It's not limited to tabular data, but it's the easiest example

Re: Less.js will obsolete CSS

#89

Post by jsharpe »

KevinMS wrote: post #6

I cranked out something similar to this years ago called in Lua and C called moonfall, actually more powerful because it was extendable, even got on smashing magazines "best of the month" or something like that, and I'm pretty sure it didn't obsolete CSS. Actually I don't think anybody used it, not even me. Maybe because Lua didn't have the buzz that javascript has now. http://moonfall.org/

Ideas like this could, eventually, actually obsolete CSS as we know it. All it would take is for subsequent revisions of the CSS standard to include support for some of these features, and for browsers to support more complicated CSS.

With Less, SASS and similar tools becoming more popular recently, I wouldn't be surprised to see Chrome or Firefox experimentally include their own implementations.

Re: Less.js will obsolete CSS

#90

Post by nex3 »

jerf wrote: post #77
nex3 wrote: post #16

Running a compiler in the browser in production will never be a good idea. If you care about the speed that your website displays -- and you should -- the slowdown caused by parsing, processing, and concatenating large amounts of CSS will dwarf over-the-wire time. People who seriously care about the usability of their sites have been spending a lot of effort recently figuring out how to get load times as fast as poss…

"Running a compiler in the browser in production will never be a good idea." Well, it's way too late for that. You need to send that statement back to mid-1990s. Or does your processor natively execute Javascript text? That dogmatic declaration is nonsense. Compilers are just code. Certain programming language compilers are very slow due to the immense complexity of their task but there's nothing intrinsically slow a…

You're right, that was too broad a statement. However, it is undeniable that in-browser compilation of CSS will always be slower than precompilation, as long as the compilation outputs CSS. For some people, this speed hit will never be negligible. But for those who don't need to squeeze every bit of performance out of their sites, it's sufficient that it only be an order of magnitude or two faster than the HTTP request.

However, that's not the case right now. Maybe in the future Javascript's string parsing will become dramatically faster, but in my benchmarks elsewhere on this thread, it's clear that for large files less.js is pretty slow relative to HTTP.

As for serving it up as JSON: no one wants to write stylesheets in JSON. The reason Less became popular as an alternative to Sass was that it had a CSS-like syntax.

Post reply on HN