221–230 of 255 posts
The down-side with this is very high coupling between UI logic and style. If style becomes out of fashion, you have to modify files that contain logic. If framework (react/vue) becomes out of fashion, keeping styles will be difficult. The other down-side is thousands of web developers having to re-learn CSS and the tooling behind your app instead of just changing CSS files.
Want to show a title? Use ``, and style it with `h1 {color:palevioletred;font-size:18px;}`. Except hardcoding the font-size as pixels is another code smell, the `h1` is already bigger than the text body. Use `2em` if you really need things to stand out.
It's in the name, Cascading.
Earlier quoted context omitted.
> 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...
nix package manager
Earlier quoted context omitted.
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
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
Earlier quoted context omitted.
Yeah, it's really not hard to delete a CSS file. People really are that lazy , but that's on them, not the technology.
Nobody thinks it's hard to delete a file. It's hard to know when you can delete a rule . Are you positive that all the rules in your component's CSS file only affect that component? Then great, delete the whole file. What about the individual rules within that file? How do you know whether your app is still rendering any components with the `fancy` modifier anymore? Keep in mind any JS on the page could be be dynamic…
Absolutely
Earlier quoted context omitted.
Nobody thinks it's hard to delete a file. It's hard to know when you can delete a rule . Are you positive that all the rules in your component's CSS file only affect that component? Then great, delete the whole file. What about the individual rules within that file? How do you know whether your app is still rendering any components with the `fancy` modifier anymore? Keep in mind any JS on the page could be be dynamic…
> Are you positive that all the rules in your component's CSS file only affect that component? Absolutely
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. After you've done this perfectly, your app…
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 he…
Earlier quoted context omitted.
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 he…
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.
Earlier quoted context omitted.
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?
> 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.
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. After you've done this perfectly, your app…