Big ol’ ball o’ JavaScript
bradfrost.com
bradfrost.com
> Historically, different languages suggested different roles.
Otherwise known as silos. In my experience, front-end developers and back-end developers not working together but each "role" merely throwing their results over the wall and expecting the other side to do whatever it is they're doing is a huge problem. We supposedly have DevOps but we don't even have sufficient collaboration within the Dev part of that equation.
None of these roles delivers a usable product or solution to a problem on its own.
CSS-in-JS or defining styles at a component level is not a problem per se either. It can become a problem if there's a mismatch between the document structure envisioned by a designer and the component architecture devised by a developer. Component architectures aren't foreign to designers though, the perhaps most prominent example ironically being Brad's own Atomic Design paradigm.
Just yesterday I saw this talk about "Angular for Designers" by Stephen Fluin, which advocates making JavaScript applications, of the Angular variety in this case, more accessible to designers: https://www.youtube.com/watch?v=LP-fNM8OITI
This in my opinion is the way forward rather than artificially setting up boundaries between roles defined by the languages they use.
The reason this debate will never end is because it's never anchored to how the business sells and delivers products. Full stack is better for shorter product life cycles. Specialists are better for longer-running products and monoliths. Code quality really doesn't matter if the product disappears.
The key evidence to me that full stack is mostly BS is that it only crops up in web roles. Outside of web dev, people are still silo'd -- security people and systems developers aren't pulled off-task to go work on the company website. We're completely fine accepting their responsibilities in terms of the product. If you're a front or back-end web dev though, there's this constant pressure of "why haven't you learned to full stack yet?"
It's only by the early 2000s and the advent of architecturally complex, heavily back-end-leaning frameworks such as J2EE or JSP that front-end and back-end diverged. These frameworks had their benefit compared with the fast-and-loose way web apps often were developed before but they also introduced new problems.
Apart from inherent architectural issues these frameworks introduced a new crop of developers to web development that was at least somewhat averse towards how front-end development is done on the web. To this day, I still know developers who loathe JavaScript, CSS and HTML because "they're not the proper way of doing things".
Furthermore, with traditional desktop applications you also usually have a full stack attitude, although again it isn't called "full stack" in that case. Desktop application developers are typically expected to be able to write both UI code as well as business logic and database access code. Probably that's because with desktop applications there's usually only a single language you're dealing with.
Many GUI applications are actually based on a client-server pattern that mirrors the "front-end" v. "back-end" distinction. Often the "server" is a separate CLI app, or even a daemon/service with no interaction with the rest of the system other than via the platform IPC (COM, DBus, whatever).
Consider the traditional large-scale "pattern" of desktop apps, viz. Model-View-Controller. The Model is back-end, the View-Controller pair (which is often tightly coupled anyway) is front-end.
These were business trends, not mechanical limitations.
>Properly understood, "responsive design" is a triviality; all good design is responsive design.
I have no idea what you mean by this. Responsive design means for a page to respond to different viewport constraints by re-arranging elements and making rules for different breakpoints that you choose to support. None of that is trivial unless this is another "it's not a hard CS problem so it's trivial" argument.
It is an instance of the bin-packing problem, which is NP-complete.
The idea of fullstack isn't that you have no preference at all between backend or frontend, but that you can do both. Much like a backend developer could specialize in certain areas, so can a full-stack one.
"he key evidence to me that full stack is mostly BS is that it only crops up in web roles. Outside of web dev, people are still silo'd -- security people and systems developers aren't pulled off-task to go work on the company website. We're completely fine accepting their responsibilities in terms of the product. If you're a front or back-end web dev though, there's this constant pressure of "why haven't you learned to full stack yet?"
The term is defined by web technologies. In other areas we have different names - devops is a similar merging of separate roles (At least in some interpretations of the loaded term).
I've been in orgs where the job of the DBA was left for developers. In many IOT companies the hardware guys also do low level software. Game development in smaller shops tend to mix tons of roles into a single person.
Just because we don't have a name for it doesn't mean it doesn't exist.
Either front/back specialist can google things these days and "do" both sides. If the only goalpost is simply "doing" front or back end, then that just backs my argument that fullstack is kinda BS.
The impression I've always been given is that fullstack was good at both, not simply "able to write something that works" in both.
This qualification is important because...
>Just because we don't have a name for it doesn't mean it doesn't exist.
... the name for it has always been "doing extra work without getting appropriate compensation".
It isn't just a question of capability, if your organization is set up with front-end and back-end developers Conway's law is going to result in a fairly separate front end and back end world that is worked on almost exclusively by the "right" kind of developer - similarly to how most developers will stop designing anything as soon as someone with "Design" in their title joins the company.
People have different skills and interests, so even a 100% "full stack" team tends to develop unofficial silos unless management prevents it.
Scientific computing / Data Science / Machine learning is an area that benefits from people knowing the full stack. Siloed environments, where the scientists don’t talk to the engineers and the engineers don’t talk to ops are especially poisonous to this type of work.
Research and science requires a lot of trial and error and the compartmentalised waterfall style of development doesn’t work well.
What if my "thing they are best at and enjoy the most" is just creating new functionality, no matter what language I use? There's no place for me on a team of pure specialists.
Mind you, ask your mailman what
"div.a > .b:nth-child(3n+2) { margin: -5px -1px -5px -10px; }"
is supposed to do and you might get a different response.
backgroundColor: "blue"
The problem I've had with CSS is answering the question, "If I change this code, what will happen?" It is so easy for the answer to be "random other things break" that keeping CSS organised is really hard. At least with CSS-in-TS a "Find all references" will tell you where the style is used.
CSS Modules[1] tries to help by introducing "local" CSS, then there are other approaches like BEM[2] that bake a namespace system into the class names, then there's OOCSS[3] that tries to break it down into separate .foo and .bar "objects" a bit like your example, then others going in the opposite direction like Atomic CSS[4] that try to make all the CSS rules so narrow that it is OK that they are global, then have multiple class names used on each HTML element to make the usage local.
Really, it is quite hard, lots of smart people trying to make it work.
Personally I've found the approach of CSS-in-TypeScript the easiest to work with, since I'm very familiar with TypeScript and it allow re-using the same tools to solve different problems (and my usecase wouldn't be a good fit for static HTML in the first place, so depending on JS for rendering is OK), but I can see how people not familiar with TypeScript might prefer a different approach to handling the complexity.
[1] https://medium.com/front-end-developers/css-modules-solving-... [2] http://getbem.com/introduction/ [3] https://www.keycdn.com/blog/oocss [4] https://acss.io/
This is why I love single file Vue components[1] with scoped CSS/SASS. The styling for the component in question is right there with the markup and JS, and you know it's not effecting any other HTML with it's declared classes/styling. Breeds a lot of confidence when making changes without having to follow more rigid and fragile paradigms.
Obviously you will still have global styles and themeing but figured this is at least worth a mention.
.products > .widget:nth-child(3n+2) { margin: -5px -1px -5px -10px; }
I think the argument could be made that, ironically, the "everything is Javascript" is a direct result of having front end specialists that only have experience with one Turing complete language, being JS.
When Node came out, one of the biggest selling points was that front end designers would be familiar with the toolchain and backend language, and could become more full stack.
SPA frameworks came out when UX people decided page refreshes were ugly and slow, so they took HTML and turned it into a template language for JS instead of semantic markup.
Finally, in general, the trend of pushing web interfaces far past what HTML/CSS were designed to do by the front end community (who, rightly, see potential in their platform) is why more "power" is required, and why a Turing complete language is needed for an ecosystem originally intended to use forms as the only means of I/O.
Well, and HTML+CSS: https://github.com/elitheeli/stupid-machines/
But yeah, your point stands.
But this completely jumps the shark when equating negligence of the front end to gender bias. Basically the author is pissed and vindictive, but gets to keep thinking of themselves as the good person, because the objects of wrath aren't just CS majors who know how to tree sort and don't care if the button looks flat or 3D, but are morally evil people who are the source of oppression in the world.
I have to take CSS seriously or I'm a woman-hating racist? Look man, I just like computers and building things.
> We need to address the undervaluing of HTML and CSS for what it is: gender bias.
I find it baffling how some people can make such ridiculous statements to fit their narrative and insecurities.
> We need to address the undervaluing of HTML and CSS for what it is: gender bias. Even though we wouldn’t have computer science without pioneering women, interloping men have claimed it for themselves. Anything less than ‘real programming’ is now considered trivial, silly, artsy, female. That attitude needs to eat a poisoned ass.
And it's from this link: http://www.heydonworks.com/article/reluctant-gatekeeping-the...
I admit I don't understand the point. I haven't experienced this perception of HTML/CSS as something "trivial, silly, artsy, female". It's possible though that this does exist? In some places? I mean people do have a tendency to think of what they're good at as superior to the things they're bad at...and loads of programmers are really bad at HTML/CSS.
Attributing "gender bias" here is stupid and harmful. I'm repeatedly astounded that these people are taken seriously.
It's charlatanry.
I don't necessarily agree with argument in its entirety, but it isn't about the mere participation of men. It is about the exclusion of women. Very different things.
I see what you mean by "interlope", that is a good point. That is a rather poor word choice from the quoted article (by Hayden). I find it hard to believe that Brad, being a man himself, would argue that men can't participate in the field.
I've long since given up hope of trying to parse the madness. I sincerely don't understand what motivates people to say these ridiculous things, and as a consequence I sincerely can't tell when somebody means what they say to be figurative and when they are expressing a genuinely-held (but mad) belief completely literally. Given the alarming frequency with which these sorts of claims in fact become accepted truths among feminists that get repeated over and over, I err on the side of assuming the latter.
Hayden used the word, and did so in a context where there was no obvious way to interpret it as hyperbole or metaphor. In the absence of any other possible interpretation, I'm going to assume that he means exactly what he said.
Pioneering women were crucial in the development of CS as claimed, but HTML and CSS were both created by men so the author's accusation of denigrating the contribution of women is simply not a factor in this issue. Characterizing HTML and CSS as feminine in this way is promoting exactly the sort of gender stereotyping these rants are claiming to oppose.
I'm afraid this is what gender wars activism has come to - fabricating and promoting fake gender stereotypes and associations so they can keep fighting the good fight for it's own sake.
> ...women (and men) who feel their roles as front end devs are considered less...
> I didn't see it as a gendered issue until it was brought to my attention by female co-workers...
Female co-workers bringing an issue to your attention doesn't make it a gendered issue and you literally refer to it as a non-gendered issue, though parenthesising men.
As a full-stack JS dev, having come from a .NET background, through a pure frontend job, to a full-stack position, I regularly have to shoulder banter from Scala colleagues' (both male and female) snark at Javascript - primarily because it's existed for a long time and been a barely justifiable mess for most of that time.
People tend to assume that I do frontend and try tu push me toward ui design side of things, despite me being completely crappy at that. It was real problem only once, normally I can easily negotiate different position. But, it requires me to often explain that I really cant design - I dont have to explain I dont do any other technology to avoid position, ever. People dont assume me to know sql, databases, server, java, but they do tend to assume me to be good at design.
Every frontend dev I've ever worked with has received this same treatment, so I would find it difficult to believe it's even predominantly females; but maybe I've met a lot of exceptions.
But, I am not even frontend developer and get the assumption that I am one. When I was nearby frontend, people made further assumptions about which part of it I do - they expected me to do aesthetic work altrough I am really bad at it and were sometimes oddly awkward when I wanted to talk about architecture or algorithms. I don't think male frontend developers are not undervalued, but the assumption about which part of it they do is on average a bit different.
Or it's a False Cause.
I am a very strong supporter of feminism, but this kind of reasoning needs to stop.
The idea of "as a man you're biased from your position of power, therefore your opinion is invalid/worthless" means that the opinion of any men can be shut off automatically just by finding a gender twist on any debate. It's incredibly condescending, and frustrating, since any rebuttal you might try will be dismissed as your inability to see the other side, no matter how tenuous the connection to gender is. I would even go as far as to say that it's a mirror of the old "these are men things, as a woman you wouldn't understand" that was sadly common in the past.
While I'm very happy to see women empowered and their perspective being taken into account more and more, I'm also worried about the rise of any system that leads to the opinion of a group not being listened to. That is never good, period.
And to be clear, I'm not equating the current trend of dismissing male ideas to the suffering of women under patriarchic societies. Just pointing out a worrying development.
But HTML and CSS aren't art, nor is layout a "creative" activity. HTML and CSS are configuration. They're no more feminine than JSON or a Lua table. I don't think there's ever been a time where, even if the gender bias described existed, it was ever applied in the way described.
Graphic designers tend to be pretty well respected, even though they are also very underrepresented and needed in the FOSS community. People that mainly work with HTML and CSS are less valued because they're seen as mere "transcribers" of the design made elsewhere, or at least that's my perception.
Yes, and insofar as feminists continue to use this reasoning, we should reduce our support. It may seem like a sad case of a few bad actors poisoning the well, but the lack of outcry by other feminists implies, to me, that the movement has gone rotten, no matter how I wish it weren't so. If you keep poking your allies in the eye, you can't expect them to remain allies for long!
I yet have to find an article from him about engineering that makes any sense. He's able to write a few lines of jQuery this seems to make him feel like he knows so much about things he has no experience on.
But hey, at least you got to knock his programming chops amirite?
Frost can publish his ideas about JavaScript being intimidating because the naming convention is camelCase and not kebab-case, and it's fair game for any other programmer to point out that Frost doesn't know what he's talking about.
"Logic programming is considered superior to HTML/CSS even though it isn't. Just like one gender thinks that they are superior to others even though they aren't."
> I have about 3 blog post drafts covering similar ground and apparently we see very much eye-to-eye on this
> Whether it’s explicit gender bias or not, it’s important to recognize that people are afraid to speak up about how they feel for fear of getting dog-piled on by a bunch of “real” developers. That needs to change.
Based on the tone of everything else written by Frost and Pickering here, I’m not taking each sentence most charitably.
2. Claim that the new prevalence of women in front-end coding is sexist
3. ??
4. Profit!
- Everything bad in the world is because of straight white men, and capitalism.
- Coding is not part of a coding job. Culture is more important.
- Making people feel happy is more important than building something that works.
- Truth is subjective, i.e. post-modernism.
Parrot the above talking points with an air of self-importance and you'll be well on your way to a highly-paid do-nothing job.
I understand the temptation, I have my own critiques as well. But divisive rhetoric is not the correct response.
The 4th one about truth is perhaps an exception, unfortunately some people might agree to that. Although, it's a bit abstract for most useful discussions.
Edit: I had to add quotes, as I really dislike that word.
2. A more subtle point, but I've seen enough articles written by members of the tech scene to be convinced this may be a genuine issue. Articles claiming that demanding merit-based software development is bigoted/racist/sexist, others saying that if there isn't equality of outcome for all software devs, then the issue is the stated goals of software development.
3. Similar to 2
4. Again, very US-centric. There is a definite movement towards a person's "lived experience" and feelings (of being "safe" or whatever) is more important than objective facts.
The points above are true to the extent that I decided the West-Coast US tech scene was not for me, and returned to my home country.
I know what you refer to, as I worked in SF recently for several years. I don't think it is true that white men are unilaterally demonized by any significant group in American culture today. There is obviously some of that occurring, and occasionally the behavior is a bit troubling, but I don't there is any major problem to worry about. The behavior you are concerned will go away naturally as the recent social movements mature and are able to see some of the progress they are making. In general, most people don't support the extreme behavior, so there is only limited space for it to survive.
I do think patient and healthy pushback can be appropriate in the right circumstances. It is a tricky issue though. There are some very legitimate (and some less so) reasons motivating such behavior, even if, occasionally, some of the specific actions themselves are troubling. Anyone claiming rigid, simplistic absolute statements here seems wrong to me.
Perhaps I'm biased towards (and privileged enough to do so) being patient with what I see as some temporary flare ups that are side effects of attempting to process and rectify some of the results of absolutely terrible historical occurrences over the past several hundred years. I don't know. We will see how the next 10 or 20 years go.
I have to go so I won't address the other issues. These topics are tricky and hard to discuss with a short comment.
I will say that the way you are discussing them is preferable to the person I accused of straw-manning. You seem more capable of considering nuance, which I appreciate.
I am not proud of how male dominated frontend is, and no one should be: https://2018.stateofjs.com/demographics/gender-breakdown
As you get closer and closer to coding, you can see how this ratio gets smaller and smaller: https://www.invisionapp.com/inside-design/designer-compensat...
What's at issue here is that coding is a combination of EQ and IQ, and when we create environments that favor "rightness" over common empathy and effective communication, we turn our backs on the people who favor thinking that way (no matter their gender) and we make worse products as a result.
We're not writing code for machines, we're writing code for people.
https://www.forbes.com/sites/clareoconnor/2017/09/14/google-...
The execution engine is elsewhere and the 'code' is really configuration for the HTML/CSS engines. Same thing for SQL which is another language he mentions.
There are many advantages to this. First, of all it's much less error prone to write, and second you don't have to run any code to predict it's output.[1]
If you pull the markup languages into a procedural framework, you lose many advantages.
[1] Testing becomes a matter of seeing the results in a browser, which is not to say it's trivial. The downside of declarative languages, is that it can be hard to debug when the engine does something unexpected (remember ie6?).
Well that's a conscious decision the developer makes.
You don't need to use any of this.
If, as a beginner, you just want to write an HTML doc with some styles - that still works.
However, if as a beginner you jump into a Webpack / React / CSS-in-JS setup... well you're going to have a hard time.
Complaining that "that's the way things are going" seems to pass the buck. If you don't want to go that way, then don't!
You will if you want a job. Noone's hiring devs who only know html and css and don't want to learn anything else.
Also it's useful to have utility players who can fill in gaps in any position.
You end up in the "width vs depth" debate if you go along these lines. It is debatable whether it is better to know 60% of all worlds or >95% of one world. (Assumption: It is extremely rare finding people who know >95% of all worlds).
However, I agree with your point that full-stack is the way to go if you are limited on resources (small orgs).
* CSS-in JS isn't gatekeeping; there are huge benefits to breaking the global CSS model, which these articles seem to ignore, which is surprising to say the least
* the market reality is that most companies are better off with 'full-stack' people - the need adaptable people, who can get things done, albeit not always with the perfect approach
To ignore these and instead point to gender bias seems bizarre.
But I think that it's possible to have really good full stack developers and there is a lot of value in having one on the team. Every project needs at least one person who understands every major part of the code; the more detailed their understanding is, the better it is for the project.
First the idea that the term fullstack is somehow a capitalist conspiracy to maximize profits over the poor developer is beyond misguided. Fullstack development came to be because of the rising popularity of SPAs and the shifting of what was once strictly backend development into client side (templates, routing, etc...).
Not all code is the same, but the separation to backend and frontend is artificial - MVC in js or in C# is the same no matter what language you write it in.
I'm a proud full-stacker and would hate to work in an organization the article paints as paradise - a place where I'll have to wait for someone to write my web-services or for the DBA to add a column to a database. In fact it is that enterprise way of thinking that made me, and I think many people, prefer fullstack work.
To me full-stack is about accountability, it's about not having someone else become a bottleneck to a feature you are in charge of, it's about the ability to see a feature from start to finish and make it the way you, as the one who actually works on it, think it should be.
I've gone from a company where I worked in service and api layers as well as in the UI. To a large enterprise with well-defined silos...where my role is solely as a Sr UI developer this role change has been the most regrettable of my career.
Architectural decisions should take into account all cross cutting aspects of a system. I just think it's such a lack of imagination and passion for someone to be satisfied with just doing CSS or frontend-js work too.
The best dev's I have ever worked with with are curious about all sorts of things. Have good vision as to where design decisions should be made (ie what part of the stack) and have a good sense of programming patterns and practice across the different layers.
If all someone knows how to do us UI inevitably they will view the UI as their hammer to solve every problem. This is the case even when business logic or computation should happen at a higher level so as to serve multiple client platforms.
Also I find it supremely sexist to say that frontend is a girly thing. The VP of my last company was a female with a post graduate degree studying operating systems. That to me is the real gate-keeping.
The article is mainly about how writing HTML and CSS in JavaScript means that designers are expected to be full stack developers. The author says he is confident developers can handle it. Where do you get the idea he thinks there should even be a DBA?
If "full-stack is about accountability", does that mean specialization is about avoiding accountability?
I became a full stack developer for the same reasons as you, I like assuming the responsibility of every aspect of a product's development- plus, working in different aspects keeps things fresh. Building beautiful ui with react is really fun, so is building the services that app talks to. Personally, being really good at both of those things has been super profitable for me.
If you focus only on your own thing it quickly leads to alienation from the rest of the team.
Ah, yeah. `background-color: blue` is indeed worlds more easily comprehended than `backgroundColor = 'blue'`.
ಠ_ಠ
Don't do CSS-in-JS because a linter reminding you to camelCase is intimidating? Really? I've mentored several juniors over the years and none of them have been that touchy.
I'm not a proponent of CSS-in-JS, but this article makes some "interesting" mental contortions (and even a jab at capitalism, for some reason? [Oh, right, I forgot that endorsing Communism is trendy in the US these days]) which I'm interpreting more as the author's defence against learning a little more than just HTML, CSS, and "presentational JavaScript".
At a stretch, I can definitely see how someone with strong roots in CSS development could see camelCased CSS as being convoluted. I think it's looking at things from a very narrow perspective, however.
Out of all the arguments in this article, I think this is definitely one of the weakest.
As more projects start leaning towards "fullstack" apps, typically Node.js/React, I'm observing the main issue this article raises: these specifically frontend-focused people are getting separated/excluded from the development process, unless they become familiar with all-JS solutions (the "big ol' ball o' JavaScript").
The learning curve is significant (ES6~, Babel/TypeScript, React, dev/build steps), so they must choose to either:
- Become more proficient in JS to be able to contribute
- ..or focus on design/prototype using HTML and CSS as a separate phase, to be incorporated into the final product by the fullstack people
For one such project/team, I'm experimenting with a compromise: a fullstack React app that renders and composes pages/screens from folders of HTML and CSS templates that frontend people can edit freely. This is aiming toward the "best of both worlds", but it's still a bit awkward. Vue.js might be more suitable, but - at least personally - it's a compromise in the other direction..
The roles are driven by business needs. The more budget is available, the more you can afford to stratify roles into front-end, back-end, and architect. But it's up to the business to decide what roles they need, not us. The output of engineering departments is something normal people have to be able to reason about. We don't build bridges just for other engineers. We do it with taxpayer money to serve taxpayers.
That's the thing the article seems to be glossing over categorically. I kept looking for the distinction between skill sets/productivity thing and what I'll just call jobtitle capitalism. You can't cash in on being master of none, but being a Jack-of-all-trades doesn't make you look competent either.
My counterpoint is that if you had to rely on craftsmen for everything, the number of buildings we can have is always going to be limited to what they can produce. We need handymen software developers because Pandora's Box has been opened and the business need for software is utterly insatiable.
It won't be long before we're longing for good ole' days of code schools. People will be entering the software field with nothing more than CodeCademy on their resume soon.
EDIT: What's wrong with codecademy? See, figuring things out in a way that efficiently translates human ideas to machine processes isn't straight forward and usually involves multiple attempts. Which means, I, as a craftsman, need to be pointed to shortcomings of what I do multiple times to arrive at the ideal solution. Whether I studied what I'm doing in college actually has less to do with this process, though, and more with my own humility towards my own craft.
> I can see full-stack development emerging as a result of capitalistic exploitation
In my experience, I have worked with a lot of lead developers who seem to wilfully propagate this notion to their managers that we need less resources, that we can squeeze more out of what we have. I understand that part of this comes from the human desire to save your ass, especially in that kind of work culture. However, I always felt that we needed to push the opposite message, even if it wasn't necessarily true. Why have two developers working at 100% crunch-mode when you can have 3 or four working at a more relaxed pace. Simplistic, but that's my view.
In this scenario, who's money are you spending?
I do gotta say though that I don't have a better idea as to why things happened this way. I'm just guessing companies wanted to cut costs on frontend servers by only serving up static bundles and people hated page refreshes.
> I can see full-stack development emerging as a result of capitalistic exploitation
The "generalist" has always been there, what capitalistic exploitation has to do with it, I don't know.
> We need to address the undervaluing of HTML and CSS for what it is: gender bias.
Pickering & Frost: Did it seem like a good idea maybe hopping on the bandwagon of the populist rhetoric in the media? Next thing we hear about might be that Python is not trans-gender friendly enough...
I'm glad I'm not the only one who sees this.
Sorry for being a tad slow here, but how so? :) That their opinions about technology are regarded too highly?
Also, please don't break the site guideline about calling names.
Before, we used HTML, CSS, JavaScript as both input and output. We built layers of abstraction such as Sass for CSS. We generated HTML using backends in various flavours (PHP, Ruby, Python).
Ideas like BEM, OOCSS, SMACSS and Atomic CSS was crucial for driving the movement towards reusability. CSS architecture was treaded by the community as a serious consideration. It helped front-end teams scale in a way that's safe, easy to extend, easy to conceptualise.
Building scalable web applications, thinking in components can be a fantastic thing for web teams. Having styles coupled to components, as opposed to having them cascade down based on classes, IDs and element type does break a lot of the ways we've been writing CSS over the last ~5+ years.
The question is, how do we install systematic design principles without the structure we've been using to write our scalable CSS?
Stuff like variables, mixins and reusable visual style rules are all achievable with CSS-in-JS.
The big paradigm shift that's needed to grok the concept, is to understand that by having the input of HTML, JS, CSS written in a single language/place, we can be more deliberate how we express the relationship between styling, markup and logic.
We are starting to see people build projects to attempt to add some structure to how we do CSS in the new world of front-end, and Brad has a lot to add to this discussion given his incredible contributions to CSS over the years.
Given how expressive CSS-in-JS has made me able to express the relationship between styles, I'm not sure I'd want to go back to a world where the considerations are separated. JavaScript as a layer of abstraction can do more good than harm.
TL;DR
Layers of abstraction (i.e. Sass and now CSS-in-JS) increase ability to express front-end/design architecture. Separation of concerns by intention rather than language.
I noticed this myself when we adopted React and I told my cofounder (a designer by education) that he could "just tweak the embedded HTML in there as he saw fit" (i.e. the JSX). I think I said something like "just scroll past all the code you don't understand until you reach something that looks like HTML". In practice I don't think he ever touched it - not because he's an idiot or easily intimidated, but simply because editing the HTML wasn't the most productive way forward for him anymore. Instead, he'd edit it live in devtools, make a screenshot and copy out the edited HTML+CSS sources and tossed it over to me. I don't think he was wrong about doing it that way.
I don't think you're wrong either, by the way - I don't think we made the wrong decision when we started writing our HTML (and later, also, our CSS) in JS. But, depending on your team composition, there's real world consequences to doing so that you're going to want to take into account.
It is a good point, and it's something I think I'm going to have a think about. I think it's really important that designers aren't put off building front-ends because it's just gotten too complex.
Since when? You don't need to know JS to write CSS. You just don't. You make an architectural decision, based on what you want to create, to use css-in-js. But that's a decision that you make. You can 'do' CSS without anything but... CSS!