Live data from Hacker News

Less.js will obsolete CSS

fadeyev.net

91–100 of 131 posts

Re: Less.js will obsolete CSS

#91
post #36

Earlier quoted context omitted.

That's like saying that instead of learning how to write functions, one should just get better at copying and pasting (because VIM is good at that).

CSS has very flexible selectors, so in a sense it already has some abstraction features. Those differ from what we know from other languages, but they are still very useful and should be exploited. I was never forced to define important colors more than twice in my CSS style sheets, usually defining them just once. Maybe my document structures are too simple to get into trouble - but maybe that's the whole trick. (i.…

Complexity is not all bloat. For a given set of data with a given list of goals, there's an optimal level of complexity. More than this and it's bloat — but less than this and you're not accomplishing what you set out to do.

Re: Less.js will obsolete CSS

#92
post #62

Please, no . This is terrifying. Let us browse without JavaScript and in peace. Please.

You can still browse without Javascript. This won't hide any content — you just won't have Javascript gussying up the presentation for you. Which is already the case on a lot of sites that don't use it as a CSS replacement. That is basically your choice if you choose to roll without Javascript.

Re: Less.js will obsolete CSS

#93
post #77
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…

The less compilation, the better.

Re: Less.js will obsolete CSS

#94
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…

I agree with your last point, but things like extensive jQuery and TypeKit usage are demonstrating there's an appetite to do a lot of semi-essential rendering and event processing in JavaScript nowadays. I can't wait to see some benchmarks, but I can't imagine Less.js would affect page load times as severely as Typekit seems to sometimes.

Re: Less.js will obsolete CSS

#95
post #36

Earlier quoted context omitted.

That's like saying that instead of learning how to write functions, one should just get better at copying and pasting (because VIM is good at that).

CSS has very flexible selectors, so in a sense it already has some abstraction features. Those differ from what we know from other languages, but they are still very useful and should be exploited. I was never forced to define important colors more than twice in my CSS style sheets, usually defining them just once. Maybe my document structures are too simple to get into trouble - but maybe that's the whole trick. (i.…

I wasn't arguing that CSS does not stand on its own two feet, or that LESS is necessary. Rather, I was just objecting to the view that one should just improve one's text editing skills instead of learning to use some kind of abstraction.

Re: Less.js will obsolete CSS

#96
post #91
post #36

Earlier quoted context omitted.

CSS has very flexible selectors, so in a sense it already has some abstraction features. Those differ from what we know from other languages, but they are still very useful and should be exploited. I was never forced to define important colors more than twice in my CSS style sheets, usually defining them just once. Maybe my document structures are too simple to get into trouble - but maybe that's the whole trick. (i.…

Complexity is not all bloat. For a given set of data with a given list of goals, there's an optimal level of complexity. More than this and it's bloat — but less than this and you're not accomplishing what you set out to do.

There's still a maximum level of complexity for presentations (here: HTML presentation of a set of data). That level is independent of the content. Anything above that is just irritating for the viewing persons.

This is especially true for web sites which should at least look as simple as possible. So in principle, there should be always a way to produce HTML whose DOM structure isn't too complicated, no matter what the content is.

Re: Less.js will obsolete CSS

#97
post #4

Literally the only problem with CSS itself is that it doesn't have defines. Every other problem is just browser implementations.

I agree for the most part, but as the "only" problem, it's a seriously gigantic one. CSS is cool but this limitation is so frustrating, especially once your style sheets start getting really big.

Re: Less.js will obsolete CSS

#98
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…

I can imagine a scenario where the bandwidth is so slow, and the client CPU is so fast, that theoretically sending a small file that is expanded into CSS would result in a faster page load. The use of JS Web Workers might further this.

In addition, with more mobile internet providers capping monthly usage, every byte counts.

I'm assuming that these CSS compilers generate larger output CSS files than their input.

Re: Less.js will obsolete CSS

#99
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…

This is a red herring. Any compiler that is implemented in JavaScript can be run both in the browser at run-time (very convenient for developers), or once at deploy-time using one of the many server-side JavaScript platforms (better performance for deployments).

In fact this is exactly what we do with Objective-J, and if Less.js doesn't already then I expect they will soon.

Re: Less.js will obsolete CSS

#100
post #90
post #77

Earlier quoted context omitted.

"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 reque…

"As for serving it up as JSON: no one wants to write stylesheets in JSON."

You don't have to. You can use a compiler to generate JSON to feed to the system, retaining the flexibility of having the compiler running but skipping the parsing step. Why not compile straight to CSS? Well, why not? For simple sites that may be just fine. For more complicated sites it might be desirable to screw with the CSS before compiling.

My real meta-point here is that compiling isn't that scary. The idea of load you may get from g++ or GHC is not generally applicable. And as JS gets closer and closer to C-speeds it'll matter even less. (Not saying it will reach them, but you don't have to.) And there are already quite a few compilers in the mix; every web language has one (JS, CSS, HTML, SVG) and adding another is not like an enormous scary step. I suppose this is another consequence of the continuing deplorable move away from having compilers be a required class for a degree; truly it is one of the most powerful techniques of computer science that is relatively difficult to fully encounter outside of a formal education. (Like everything else in programming, it isn't impossible, but as it is very easy to walk away with a degree without ever having encountered one, so much moreso it is easy to not encounter one in informal education too.)

Post reply on HN