151–160 of 255 posts
CSS in JS is one place where Vue has a substantially better experience. Being able to toss scoped-css, written as normal in a css block is what I call nailing the developer experience. It is all the best parts of css in js with none of the downsides.
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.
Ok, but, the average startup web dev stays at a company for like two years? And then the thing eventually gets rewritten anyway in the latest flavor of the week, because nobody is using the same tools as two years ago. I guess the concern for longevity most devs have is amusing when most software, if its not like systems level stuff, or problems most devs dont want to solve, tends to get disposed pretty frequently. B…
both of these are pretty bad examples, as several modern developments have surfaced in both cases - here are 2 examples
- https://wikipedia.org/wiki/Curve25519 - https://github.com/google/brotli
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…
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…
CSS is not a programming language, and it shouldn't be viewed or compared as one. It has different functionalities.
I understand the "pit of success" idea, particularly when it comes to more junior devs. But I don't necessarily agree that you need stringent processes to get most of the gains you cite from using something like SCSS or even regular CSS these days. It's really easier than ever. 1- append only? No, each module/feature/widget gets its own CSS file, imported to the main app CSS file. Delete the widget? Delete the file.…
> Delete the widget? Delete the file. This rarely happens. I would argue that creating an automated system to enforce "rules" should be favored over forcing every developer to know the rules and abides by them. It is much easier to understand the relationship between css and js when the css is just a js variable. Having built many large applications using the CSS file method, css modules, each widget gets its own fil…
I'm unconvinced. For one thing, it's not CSS in Javascript... there's no cascade and no sheet, so it's just "styles in Javascript". (And, actually, this article is only about a specific implementation.) The benefits listed are: - "confidence" - but I think that's a matter of understanding and mastering the tool, whether it's CSS or this library. As the co-creator of "styled-components" the author is no doubt a master…
> "Painless Maintenance" - I would have to use it deeply before I could say too much about this. But I would guess that the danger of creating spaghetti code and a spaghetti of .css are pretty much the same and have the same root causes. But as you pointed out, there is no cascade and no sheet. The styles apparently just apply to the stuff they are near in the code. No twisted logic to unwind, hence no spaghetti. The…
Ah, well, things are not that simple.
In a project of any complexity at all, the style of any individual element is typically dependent on a number of things which collectively make up the context of its presentation. E.g, the site theme, the component, and the individual element (at least -- usually there's an app-subsection and components are usually grouped into modules, etc.).
Note that this is inherent to the problem space and is true whether you're specifying styles in code or styles in cascading style sheets or any other way.
CSS provides a basic mechanism for dealing with this -- the cascade (though as I mentioned, IMO it is lacking some necessary features). Styles in code needs an answer as well.
If you were to simply hard-code styles at the element-level (which you can do using either mechanism BTW though its probably easier with style-in-code), you'll have a hard time finding all the places in the code you need to update if you want to make a change. You'll be doing a lot of full code searches, reading code, and trying to put yourself into the mind of the person who wrote the code in the first place.
The "spaghetti" in the metaphor are the lines of dependencies. We have spaghetti code when those lines are disorganized, entangled with irrelevancies, obscured, and otherwise unnecessarily difficult to deal with.
In fact, if you hard-code a style on an element that is dependent on the site theme, app section, component module, and component, you'd be hiding those dependencies, which creates spaghetti code rather than avoids it.
Now, I expect most developers would naturally try to avoid doing something like that. I'm just trying to point out why style-in-code doesn't really help you avoid spaghetti code.
Author here, happy to respond to any questions. AMA!
Honestly, I think the CSS-in-JS approach is not for me and we haven't used it except for times where there was no other way to do something. Instead we have used CSS Modules ( https://github.com/css-modules/css-modules ), first by including it manually in webpack, now it's already built into create-react-app so I just have to install node-sass and call my Sass files ComponentName.module.scss and I can use them the sa…
Having some experience with CSS Modules myself, I thought they were interesting and definitely an improvement, but still left a lot to be desired.
For example: needing to use a helper like `classnames` to join/toggle many dynamic classes together was very ugly and cumbersome. There is also no way to "directly" tie variable state/props to CSS rules – you're still required to use this indirection where a state/prop relies on there being a predefined class/modifier in the CSS file.
e.g.
font-size: ${props => props.size}px;
color: ${props => props.special ? 'red' : 'blue'};
We built a relatively large social media management platform, and for one of our major features (a streams page that shows social media activities from different sources), we put a lot of our css in JS including all the logic for stream sizing/resizing and page responsiveness. I can honestly say that this approach is terrible. It is a maintenance nightmare. Even the smallest changes require a ton of time. We're now r…
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 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:
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…