Hacker News Reader

Comment by DerekBickerton | Hacker News Reader

CSS has become like a scripting language now. You can do things like nested CSS[0], keyframe animations[1], calc operations[2], etc

It has become very JavaScript-like and this is why I always try to see if I can do something in CSS first before I resort to JS.

[0] https://www.w3.org/TR/css-nesting-1/

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/@keyframes

[2] https://developer.mozilla.org/en-US/docs/Web/CSS/calc

View on HN

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.

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).

I mean some of those things just make sense. Why shouldn't CSS allow you to mix units and do some basic maths like with calc? Having had to resort to JS for that stuff is the real issue there.

CSS in my eyes should be able to handle 99% of visual style related needs with ease, JS should be there for the rest.

>CSS has become like a scripting language now. You can do things like nested CSS[0], keyframe animations…

The WebKit team first proposed keyframe animation in 2009 [1], so that’s been here for a while.

[1]: https://webkit.org/blog/324/css-animation-2/

I already want an add-on that allows me to disable certain CSS features just like I block JS by default. It's becoming a problem for sure.

I already want an add-on that allows me to disable certain CSS features just like I block JS by default. It's becoming a problem for sure.

You’ve pretty much always been able to do this via user style sheets [1], which override author (the author of the website you’re viewing) stylesheets.

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade#use...

What I'm missing is a sane set of defaults applied to every page automatically with a nice UI so I can enable specific features on a per-domain basis with a couple clicks. If I get the time I'll write the firefox add-on myself, but in the meantime I'm hoping someone else will save me the trouble

In about:config you can enable or disable features individually.

Recently they added ":modal" that will make paywalls harder to bypass. Most sites haven't implement yet, but I've already disabled this "feature" on config.

thanks for this! I've already got a huge list of changes I make in about:config on every install but it looks like it's time for an update

Every once and a while I have a look at the changelog of the FF dev. It is good way to find the flags to disable features and to have an idea how the web is changing overall.

The downside of cherry picking features is that your browser fingerprint becames pretty much unique.

I don't think of nesting or calc as scripting like.

Animation control is where things start to get weird.

CSS also performs better than JS in many cases. It's also easier to write and manage.

and there's the vulkan like layer coming up, it's gonna become a rendering pipeline (for better or worse)

Reply on news.ycombinator.com