Hacker News Reader

This is sad. All because people are not able to think of one simple prefix and stick with it when naming CSS classes. How hard can it be? Just use some part or abbreviation of the company name and be done with it. Or better yet: Let third party do that. I always hated that, when someone used Bootstrap on a website and Bootstrap f'ed up all future styling, by assuming it was the only one player in the game. So stupid.

I personally never ever ran into any problem, when I myself named CSS classes and that is because I automatically think about the future and whether a name could conflict with something else, instead of being lazy and typing 3 characters and thinking I did my job. I am simply careful and use prefixes and give unique names, so that it has such a low chance of someone else using that CSS class name, that it simply never happened in practice. So from my personal experience all that mumbo-jumbo about CSS name collisions comes from people not being careful and is a "house made" problem, not a problem of CSS. I never had any need to use JS to do what is CSS's job.

Using JS for doing something CSS should do is furthermore dangerous, since clever people deactivate their JS or block it partially. For me personally, your (not you personally, but you in general, anyone who reads this) JS better comes from your own domain, or it will be blocked by default. If you can live with people seeing your website utterly destroyed by its inability to apply style, then OK, do the styling in JS.

People want an interface such that a folder represents all they want to know at that moment about a component. But then someone else may want an interface such that a folder can represent all the styles across the app.

Otherwise I do think that the naming collision problem is really easily fixed.

You can get the beat of both worlds by having one folder for one component and then a ‘common’ folder.

SASS seems to solve most of the problems i would have with writing basic CSS.

I'm happy that just prefixing things is working for you. I don't typically have problems on smaller projects.

But I've also been writing CSS since 1997. I've deployed CSS to sites like walmart.com, nfl.com, mlb.com, starbucks.com, twitch.tv, etc. Some of these sites have a lot of third-party widgets on them. I can confidently say that the (multiple) issues with CSS are not a "just do <simple thing X>" type of problem.

> I can confidently say that the (multiple) issues with CSS are not a "just do <simple thing X>" type of problem.

I'd go so far to say that almost no (real) problem is that type of problem. Maybe problems that are mostly inconsequential, sure.

This is the goal of Web Components / Shadow DOM.

Angular implements a polyfill for this. Every angular component has 3 files html, ts, (s)css, and the styles in the components css file are automatically scoped to just the component they apply to. It takes away all the stress of global css selectors, and if you want to share styles you can just have a library of shared styles and import them via scss. It's honestly heavenly and I haven't thought about conflicting selectors in years.

I'm aware and agree, and it also – even if less so than other solutions like Styled Components – counts as CSS-in-JS. So welcome to enjoying CSS-in-JS :)

Or use Polymer/LitElement, where it's just all in one file... I swear people are just reinventing react methods to eventually get to where Web Components have been for the past 4 years.

React is greater than 4 years old, and people mostly use it for the nice authoring experience, not to dick around with CSS isolation problems.

You don't have to "dick around" with CSS isolation problems with web-components, it just works. React is where you are dicking around.

I agree CSS has problems. What I don't see is how styles-in-JS addresses them.

Very typically, for a given app and page the styles of individual elements and components are not independent. They also depend the app theme, app section, layout area, component group, etc. The element fits the component. The component fits into the section, the section fits into the page. The specific relationships in a particular case are different of course. Styles are visual and the idea that a component on a page has nothing visually to do with the rest of the page is wrong.

The typical scoping rules of programming languages doesn't fit that well here.

To the extent some styling solution encourages you to treat styles that are dependent as independent, that's not a good or useful thing.

A lot of CSS-in-JS libraries provide a theming solution, e.g. [1], so it's not an 'either/or'.

(You can also relatively easily implement your own, because JS :))

[1] https://www.styled-components.com/docs/advanced#theming

Sure.

My point is, when it comes to visual styling, you inherently have a shared visual context.

The post I was replying to was concerned with the "global" nature of CSS.

I'm pointing out that this is inherent to the problem space. You have to deal with it whether you use CSS, code or any other mechanism to style.

Nobody in the CSS-in-JS world is disputing that a global theme is useful, just that having no choice but to have all your selectors be global is not so great.

I don't entirely understand why some people find CSS so difficult to work with. I agree that it has its own challenges, but solutions generally aren't very complex. Global selectors ("variables") collisions? Use namespacing. Specificity is convoluted? Simplify by using only non-nested classes.

Does the annoyance primarily center around the fact that styles cascade to child elements? Hard to tell from the article.

Good software is reusable. I can import functions from 1,000,000 different npm modules all into my project and they don't fuck with each other, right?

Let's say you wanted to pull in a button from Bootstrap for one part of your page, a button from Material UI elsewhere, a button from Semantic UI elsewhere, etc.

These things are made to be reusable right?

What are the chances you can do that without issues? Do you think any of their style rules/selectors would clobber each other? What about the base/assumed CSS that they all most likely require? What about components more complicated than a button? Without actually trying it, how much confidence do you have in your guess, vs. your assumptions about importing other things (like functions from npm modules)?

Good software is reusable without worry.

> Good software is reusable. I can import functions from 1,000,000 different npm modules all into my project and they don't fuck with each other, right?

I just spent the whole day trying to fix compatibility issues between different versions of npm libraries transitively imported in a project. Reusability in JS is a joke.

What dependency system anywhere on earth is free of the problem of "two things require different versions of the same library"? I don't see the relation to JS at all.

I've had this problem with JavaScript-before-npm-existed, Python, apt, Homebrew, Portage...

stack for haskell

nix package manager

Note that npm also supports having multiple versions of the same package installed just fine.

The problem:

I use X to create an object with library A v1.0.

I use Y to create an object with library A v2.0.

These objects are not necessarily compatible, so X and Y have problems communicating.

I would be very surprised if you told me nix or stack inherently make objects from multiple versions of the same library magically compatible with each other.

Feel free to close issues like this one if I'm wrong: https://github.com/NixOS/nixpkgs/issues/30551

Hmm I think this should go something like this:

How would objects created from X and Y can reach each other and communicate when X is not dependent from Y or otherwise? You need global mutable state or your own code witch depends from both X and Y is somehow connecting them.

So one top thing FP movement argues against is global mutable state so of course you don't have that ...Unless you are wrapping some non-FP thing like QT...

And if it's your own code it shouldn't be different that Y creates B:s instead of A v2 since your code is aware from two different versions anyway.

Do you see any weak points?

Agree.

As a primarily JS/React developer, I think there is irony if JS is held as a good design pattern in comparison to CSS with respect to reusability. Inasmuch as what are being called CSS "workarounds" are in fact workarounds, so too has been the case with JavaScript itself. I am old enough to remember jQuery and Prototype colliding over the dollarsign namespace.

Don't get me wrong. I am not a JS (or CSS) hater. I think these "workarounds" are more than adequate in making these technologies easy to work with. Which I suppose is sort of my point. I see a lot of overengineered codebases with Byzantine solutions to relatively simple problems.

Also, to parent poster:

> Let's say you wanted to pull in a button from Bootstrap for one part of your page, a button from Material UI elsewhere, a button from Semantic UI elsewhere, etc.

1) First of all, don't do this. Perhaps you were just saying this to make a point, but obviously don't include 3 monolothic libs with overlapping functionality in order to implement 3 things with the same functionality.

2) It sounds like your problem with this is more with the libraries themselves. When I write a component, I always namespace it myself. Obviously, if libraries are properly namespaced, then you could easily include buttons from three separate button libraries.

CSS is not a programming language, and it shouldn't be viewed or compared as one.

It has different functionalities.

It's a language either way, whether you consider it "programming" is not really important. So, good luck with that.

I live in the real world where it's used almost exclusively by programmers.

CSS is a tool used by web developers to style their websites.

Whether technically it's a programming language or not is tangential.

People implement Doom in CSS. It's clearly more than just some style notes for the browser.

I think you may be confusing that with something else. You can't create a complex game with just CSS. I'd love to be wrong but provide a link.

https://codepen.io/chrissimmons/pen/bqBabr

It's off brand, but the technology is roughly the same.

Another game: https://thenextweb.com/dd/2018/05/08/some-madman-built-a-mar...

The first one looks like a big part of the functionality is from the JavaScript file. It's crashing my iPhone so I'm having trouble digging into it too much. The second link, however, does seem to be done in pure css. Impressive! Thank you for the links. I stand corrected.

That limitation is why people like the article writer often replace it with a programming language.

It's not a limitation. It's different.

Its different and it a poor lang. The only people advocating for css only are privacy freaks. They're often the least return producing customers, hence ignored.

As far as I understand there are very good sides of CSS, as a declarative constraint language. More than being a poor language it looks like it is hard to use it for modern web development.

> The only people advocating for css only are privacy freaks.

This just is not true. It may be your opinion, but it is objectively false, particularly in the context of this discussion.

It is absolutely a limitation, because there are things you can express in other languages that you cannot in CSS.

But a limitation isn’t necessarily bad, and is often good. Finding the language of least power (ie it is just powerful enough to express the sorts of things you want, and no more) is very useful for safety and productivity, but in CSS’s case it seems like it’s no longer powerful enough to express all the things its users desire.

It is both. Whether you consider that a good or a bad thing is an entirely separate issue.

Isn't CSS (with HTML) Turing complete?

As far as I know, Turing completeness isn't essential for being considered a programming language.

SQL is one, HTML too.

They both tell a computer what to do.

HTML is not a programming language, it's a markup language. And SQL is Turing complete.

Coq is a good example of a non-Turing complete programming language.

I don't know. I've seen people do some crazy things with pure CSS that look quite a bit like programming.

On the flip side, after using CSS in large projects for years with many, many third party libraries, I've never once felt this urge... Rarely had any problems. At least none that the effort of styling everything in JS would merit!

Not a solution for CSS I guess but if I was using a programming language that had only global variables I'd write a compiler to generate variable names.

It is a solution for CSS, and it's called CSS Modules.

and it counts as "css in js"

To me the real problem is javascript. It makes stuff like this so easy that no real solution has come along. Worse is better, I guess.

Emacs lisp is pretty much like that. Nowadays it does support semantic scoping but lexical scoping is still very useful.

I don’t really understand this comment. Emacs lisp always had dynamic scoping, which is a bit more than just global scope because you aren’t quite stomping on top of other variable bindings. You get resetting your bindings to what they were before you started for free and you don’t need to worry about nonlocal exits. Emacs lisp also has macros and gensym to avoid some of the pain of name clashes.

Emacs lisp also has lexical scoping. It optionally had it for a long time using cl.el with lexical-let and friends. It now has it as a file-local variable read by the compiler/interpreter.

I also don’t understand what you’ve written at all. You say “Nowadays it does support semantic scoping” but semantic scoping isn’t really a thing (as you next write lexical scoping, I assume you mean dynamic scoping), but the words “nowadays,” “but,” and “still” imply that you are talking about the new kind of scoping (ie lexical) and comparing with the old (dynamic, which you cal lexical???).

It's part of what makes Emacs so easy to customize on-the-fly.

CSS isn't a programming language, that is the fundamental difference and explains a LOT of the debate surrounding it.

Does not classifying it as a programming language help this situation at all?

LocalPCGuy may just be responding to the grandparent comment which claims that it is:

> Imagine a programming language that only had global variables. You have to carefully name your variables using complicated conventions in order to avoid any conflicts or unexpected behavior. Even your functions don't have local variables; there is no lexical scoping. Any function can overwrite or mutate what any other function is doing inside. There is no real encapsulation.

That simply isn't true; CSS specifies a bunch of declarative rules, which statically evaluate. Though the evaluator may be stateful, reasoning about how the properties for each document node are determined doesn't require state. It requires reasoning about the targets of the rules, and when they overlap, about their relative scopes and priorities.

I am the grandparent, and never mentioned anything about state. Not sure why state matters. Declarative CSS rules have effects. The scope of those effects can be both unlimited and unintended, and you can't "opt out" of being affected by rules – if some rule is targeting you, you're out of luck, unless you anticipate it and apply everything with the greatest specificity possible.

Pardon me; I was thrown off by wording like "overwrite or mutate".

And HTML is a markup language for hypertext, a document rather than an application.

But it turns out that we're using it and CSS and JavaScript to build full blown applications. So, because we're trying to solve problems with applications rather than documents, we have to map the problems of application programming onto it.

So, to build an application, we run into problems CSS wasn't designed to solve (being a not-programming language.) Whether it is or isn't a programming language is irrelevant - to solve our problems (writing applications), we have to treat it as if it is.

This is one of the reasons why I don’t like web development. Here’s how MS solved this in XAML, a markup language used in Windows world for GUI:

  <StackPanel>
    <StackPanel.Resources>
      <Style TargetType="TextBlock">
        <Setter Property="Foreground" Value="Red" />
      </Style>
    </StackPanel.Resources>

    <TextBlock Text="Red" />

    <StackPanel>
      <StackPanel.Resources>
        <Style TargetType="TextBlock">
          <Setter Property="Foreground" Value="Green" />
        </Style>
      </StackPanel.Resources>

      <TextBlock Text="Green because the default style was reset by the nested container" />

    </StackPanel>

    <TextBlock Text="Red again because the nested container scope has ended" />

  </StackPanel>

I find this extremely hard to read. I mean I can see the advantage, but there must be a better way?

I agree on readability, CSS is much more compact, and therefore easier to read. I think MS designed XAML to be mostly handled by tools not humans. Didn’t work because the tool (expression blend) is not quite good enough so humans have to deal with the source too. Experience helps for simple cases like this one but not for more complex cases like control templates or animations.

I’ve wrote the above example because it shows a possible solution to the stated problem, i.e. how to introduce namespaces for styles without also introducing a full-blown programming language with scopes and variables. The exact syntax can be replaced making it more compact and easier to read.

Compared to this mostly-immutable scoped dictionaries, way more things can potentially go wrong with code, regardless on the programming language.

You can get basically the same thing from rebass in JS:

  <Box
    p={5}
    fontSize={4}
    width={[ 1, 1, 1/2 ]}
    color='white'
    bg='magenta'
  >
    Box
  </Box>

It uses a CSS-in-JS library under the hood to translate that into a CSS class for each unique combination of styling props.