Hacker News Reader

Comment by derefr | Hacker News Reader

I wouldn't compare it to a scripting language specifically; it's maybe powerful like JS, but I wouldn't say it's "very JavaScript-like" in any other way. I'd compare modern CSS more to a logic language like Prolog or SQL; or maybe to whatever you'd call Excel (dataflow programming?)

In places where CSS takes expressions, they're always declarative, functional expressions; and they're always guaranteed to auto-update when their dependent values update, instantaneously as part of the update to the dependent values. Like an Excel grid-cell.

To me, however constrained "programming" in CSS still is, this makes for far better "programming ergonomics" than JS could ever give me — which, as you say, has me always reaching for a CSS solution before one in JS.

View on HN

CSS is also, notably faster for many equivalent operations, because JS has its whole single-threaded, interpreted bottleneck.

CSS is also interpreted. CSS is faster because it's not a general purpose language and so its expressions have many optimization opportunities for reusing partial computations and parallelization.

CSS is also interpreted.

CSS is actually compiled. WebKit uses a Just In Time (JIT) compiler [1]; I suspect all modern web engines do something similar.

[1]: https://webkit.org/blog/3271/webkit-css-selector-jit-compile...

By that argument JavaScript is also compiled, so this point is wrong no matter how you interpret it: if "interpreted" means source code is transmitted and then executed in whatever fashion, then both JS and CSS are interpreted, if "interpreted" means a specific execution model on the client machine, then they are both JIT compiled and neither are interpreted.

By that argument JavaScript is also compiled, so this point is wrong no matter how you interpret it…

The primary difference between a traditionally compiled language (like C) and CSS and JavaScript is C is compiled before execution and CSS and JavaScript are compiled during execution.

There’s a reason why JIT stands for Just In Time compilation [1].

[1]: https://en.wikipedia.org/wiki/Just-in-time_compilation

Yes I know the difference, the point is that the original poster said CSS is faster because JS is interpreted. There is no way to intrepret that statement in a way that makes sense.

Sure there is - some people use interpreted to mean step-by-step, as in imperative. "CSS is faster because JS is imperative" is a charitable and correct reading.

But that is not correct, js is not interpreted/executed step-by-step in many cases (it is a bit more complicated, there are multiple interpreters and JIT compiler in the picture, it usually is started up by interpreting but then switched to JIT compiled native machine code).

The correct difference to make is the execution model, one being basically a Turing machine while the other is more similar to logic programming languages.

>By that argument JavaScript is also compiled, so this point is wrong no matter how you interpret it:

If JavaScript is not compiled how does hoisting work?

yes, declarative is exactly how i'd describe css "programming". you supply constraints and the css engine applies them as best it can. the constraint declaration language of css is becoming more sophisticated, which is much needed and welcome, but it's not anywhere close to scripting (as in, providing a precise flow of instructions).

Reply on news.ycombinator.com