Nothing here yet.
Nothing here yet.
No blogs yet.
Every time you need to change your markup to accommodate a style change, it's either a failing of CSS (the language) or your markup. No, class="flex" is exactly the same thing, just wordier. The whole point is to use elements/classes/ids that reflect meaning , not presentation, use CSS to style that, and only change the CSS when you need to change the presentation. It's not always possible, but it's a good ideal to strive for.
I think the primary reason for it is JS developers that feel out of their comfort zone with CSS, so they're trying to bring it to JS. I think it excludes people who don't know JS, it increases the barrier to entry for working on a project, and over time it ends up being more of a problem than a solution because you often need the very concepts you are trying to avoid that way (e.g. cascading and inheritance). Hopefully CSS variables & scoping will help with this. CSS variables are perfect for making CSS depend on JS without moving all of your style into JS. You just set the variable in JS and do everything else in CSS. It could even be separate people writing the two. Scoping will help with encapsulation. Encapsulation and dynamic variability are the two primary arguments I hear for CSS in JS, so hopefully we're on our way to getting rid of this terrible practice.
Atom. It's hackable like Sublime, but it doesn't go to the extreme of using config files for everything. Also, it's much more maintained, and it's open source. I keep Sublime around as well, and use it to open really large files, since Atom is still slow with that.
I do agree that a lot of it seems to be JS developers who are used to working imperatively (a series of commands) and cannot understand CSS due to its declarative nature. It's too different from what they know, and they're out of their comfort zone, so they're trying to bring it in it by moving everything to JS. For non-programmers, declarative languages are actually easier to deal with, because they don't have to care about ordering and state (e.g. compare :hover to mouseenter/mouseleave). This is why I think it's very important to be able to do things from CSS, without forcing everyone to learn JS: there are actually many people who are great at HTML & CSS and find JS hard or impssible. There are no official statistics on their exact number, but it appears that they are at least 50% of HTML/CSS authors. There is a recent movement to add JS APIs for things without a CSS counterpart because it's easier for browsers and "everyone knows JS anyway". I think we should fight this trend. However I'm fully aware that CSS is a bit of a mess. I love it, kind of to how you love your best friends: they have some terrible habits, but they also have redeeming qualities, otherwise they wouldn't be your friends. CSS was originally designed for simple documents, not applications, and we're trying to make it something it was not designed for. However, we cannot change anything because we would break existing websites, so we are just adding and adding to it and it has become quite a messy, inconsistent pile of stuff. Even things we do realize were mistakes (e.g. margin: auto for centering, or border-radius instead of corner-radius) we can't fix because it would break websites. Lastly, people have different performance expectations from CSS, which influences what is possible with the language. In JS the onus is on you not to create an infinite loop. In CSS, the language must actively prevent it. Therefore, there are many features that would simplify a ton of CSS tasks (e.g. element queries or referring to other properties), but because of the remote possibility of cycles, we cannot add them to the language. Also, even without cycles, if a feature cannot be implemented in a way that makes it blazing fast, it just doesn't get added to the language. Parent selectors are an example of this (yes, they are in Selectors 4, but will only be available in querySelectorAll). All these issues result in CSS being incredibly confusing to work with, and only the first one is actually the author's fault. At work people often come to me with CSS problems that seem simple, so they blame their inability to solve them to their poor CSS knowledge. More often than not, it turns out that the simple thing they were trying to do is actually not possible without JS or markup changes. I always find it embarrassing when I have to tell them that.
Actually, most of my day-to-day work is not that different from a typical JavaScript developer: I go to the office, I write JS all day, I go home. Sometimes I think a bit as well or have meetings where we all think about the design of what we're building. Pretty standard, right? In HCI research, you typically build a system, then test it with a user study, then publish a paper about it. The exact percentages for each differ per researcher. In my case, it's about 75% development, 10% user studies, 10% brainstorming, 5% paper writing. This is a bit more development than most HCI researchers, as I want to release my work to the public just like another open source library, and I want people to be able to use it in their projects. Many (if not most) HCI researchers produce prototypes, built primarily for research. This is not wrong, just a different way to work: As a researcher, your primary job is to produce ideas. Time spent fixing bugs, is not time spent on ideas. On the other hand, time spent fixing bugs could mean more people using your ideas. It's a balance, and every researcher picks a different point on that spectrum. Hope this answers your question! :)