
Big ol’ ball o’ JavaScript - fagnerbrack
http://bradfrost.com/blog/post/big-ol-ball-o-javascript/
======
BjoernKW
> > In this symbiotic relationship, each party has a secure job with a well-
> defined role

> 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](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.

~~~
Novashi
A team of full stack devs tend towards whatever they fancy when handing out
JIRAs, and the separation is still usually front or back-end. It becomes an
unofficial silo anyway. The full stack advantage is for sudden departures: the
project doesn't completely stop because people can fill in with mediocre code.
A disadvantage is that you don't have specialists and risk more technical debt
that can't be enforced by linters/testing.

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?"

~~~
BjoernKW
The early days of web development up to roughly the end of the 1990s
technically were full stack. It's just nobody called it that at the time.

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.

~~~
Novashi
Desktop and web development also got to ignore responsive design for a long
time, and that revolution added serious complexity to HTML/CSS/JS and browser
engines. You could slap a minimum desktop resolution on your product and call
it a day.

~~~
zozbot123
HTML/CSS were engineered to be device-independent and to separate styling from
the underlying semantics, from day one. Properly understood, "responsive
design" is a triviality; all good design is responsive design.

~~~
Novashi
>HTML/CSS were engineered to be device-independent and to separate styling
from the underlying semantics, from day one.

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.

~~~
tatersolid
Re-arranging elements optimally into different sized containers is clearly
_not trivial_.

It is an instance of the bin-packing problem, which is _NP-complete_.

------
captainbland
"I could ask my mailman to guess what background-color: blue does and he’d
probably guess right"

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.

~~~
DougBTX
And then looking at it the other way, the equivalent JS is:

    
    
        backgroundColor: "blue"
    

which as an isolated bit of code is no more or less understandable than the
CSS.

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.

~~~
z3t4
You can organize using a class hierarchy, which make it possible to have
separate rules for .foo button and .bar button. To over-rule something you
make it more specific like .foo form button, .bar form button

~~~
DougBTX
I think the core of the problem is that CSS is applied to the whole page, so
it makes thinking about local changes hard.

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-...](https://medium.com/front-end-developers/css-modules-solving-the-
challenges-of-css-at-scale-85789980b04f) [2]
[http://getbem.com/introduction/](http://getbem.com/introduction/) [3]
[https://www.keycdn.com/blog/oocss](https://www.keycdn.com/blog/oocss) [4]
[https://acss.io/](https://acss.io/)

------
fuball63
The author is advocating for a departure from "everything is a flavor of
javascript" to "it's ok to have front end designers only specialize in
HTML/CSS".

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.

~~~
lkbm
> 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.

Well, and HTML+CSS: [https://github.com/elitheeli/stupid-
machines/](https://github.com/elitheeli/stupid-machines/)

But yeah, your point stands.

~~~
fuball63
I should have learned by now to always double check before assuming something
isn't Turing complete!

------
aristophenes
Full stack devs not taking the front end seriously is definitely a thing. It's
like the icing on the coding cake, and they tend to get frustrated when they
find out it is a very hard thing to do, mostly because CSS is very
unintuitive. You can get 80% of the way there with an afternoon of training,
and then the remaining 20% takes like 5 years of experience and IE will still
f you up from time to time.

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.

~~~
dsego
They assume things are easy, because they would be if CSS was a properly
engineered solution. But it isn't. Having to wait for flexbox to be able to
easily vertically center stuff proves the point.

------
321yawaworht
Quoted from the article:

> 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.

~~~
scandox
He's quoting someone else though he is agreeing with them. The full quote is:

> 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...](http://www.heydonworks.com/article/reluctant-gatekeeping-
the-problem-with-full-stack)

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.

~~~
XCabbage
More obnoxious than the "gender bias" claim is the idea that because computer
science as a field owes its entire existence to female pioneers (leaving aside
whether there's any sane sense in which that's true), men who now participate
in it today are "interlopers". This is the first instance I've seen of the
logic of "cultural appropriation" being applied to genders instead of races;
women invented this, so it's immoral for men to participate! Uh, no it isn't,
and fuck you.

~~~
dwaltrip
> women invented this, so it's immoral for men to participate

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.

~~~
XCabbage
No, that's not what it means to "interlope" (the original author's word
choice). It means to intrude in a space where you are not supposed to be.

~~~
dwaltrip
I was looking at the phrase "claim for themselves", which I took to mean
excluding women.

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.

~~~
XCabbage
Sure, it's obvious madness, and it's hard to believe that anyone who says it
(or quotes it approvingly) could really believe it. But that's basically what
I expect out of any feminist commentary on any topic. The entire space is
littered with claims like this - ones so patently false or morally outrageous
that one thinks that surely, _surely_ , the author doesn't really believe what
they're saying. Stuff like that there exist no innate biological differences
in ability between the genders, or that pro-lifers are motivated by a desire
to exert control of women's bodies, or that being falsely accused of rape is
less likely than being struck by lightning, or that Otto Warmbier deserves no
public sympathy for being tortured to disablement and death by North Korea
because he was a beneficiary of white privilege.

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.

------
gerbilly
The thing that makes HTML and CSS different from Javascript is that they are
_declarative languages_.

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?).

------
trh88
> Any code that can be written will eventually be written in JavaScript.

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!

~~~
test1235
> 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.

~~~
yakshaving_jgt
Brad Frost clearly doesn't want to learn anything else and apparently people
keep hiring him.

~~~
test1235
There are the odd few, including Harry Roberts, but they're the exceptions. By
and large, you're not getting into the industry knowing only html and css when
(given the amount of easy-to-access online resource) it's so easy to find devs
who will learn those plus more.

------
lordnacho
Isn't the idea with full stack devs that you might have an organisation that
isn't large enough to have fully specialised staff? Or that some part of the
code needs some special skill eg SQL but not enough for a full time
specialist?

Also it's useful to have utility players who can fill in gaps in any position.

~~~
wawhal
> 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).

------
darepublic
Agree with some of the insights in this article. Basically in frontend /full
stack jobs generally the only interview questions are related to javascript --
kind of assuming that it's the hardest/most important part of the job. But CSS
and layout stuff is its own skillset imo. Thankfully I feel more comfortable
in the js coding aspect of things so this never burns me when seeking
employment.

------
room271
I remember reading the original article and discussing with colleagues at
work. The premise just seems wrong to me:

* 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.

------
jondubois
I agree that front end and back end should be treated as separate parts of the
system (I'm not a fan of isomorphic JavaScript or server-rendered front ends).

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.

------
Illniyar
He's not a frontend developer, he's a designer, who happens to do a bit of
javascript. That's fine, but it obviously colored what he thinks about full-
stack developers, and frankly it's a load of bull.

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.

~~~
cphoover
Bingo...

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.

------
Aeolun
Honestly, I think it’s really important for people to have at least some grasp
of the whole product structure even if they don’t directly work on it all the
time.

If you focus only on your own thing it quickly leads to alienation from the
rest of the team.

~~~
wawhal
Why is alienation a problem? As far as every part of the system is being
worked upon by somebody who specializes in that part, the system should do
well.

~~~
Cthulhu_
The problem is risk; if there is only one person that knows something about X,
the project is at risk if that person goes away. If OTOH you have a team of
full-stack developers with shared ownership and understanding of the codebase,
that risk is mitigated. The challenge is that people (in my experience)
generally WANT to specialize in one area of expertise, they want sole
ownership of one part of the code.

~~~
pseudalopex
A team can have redundancy without every developer having to know the full
stack.

------
yakshaving_jgt
> CSS is a relatively friendly, approachable, readable language (I could ask
> my mailman to guess what background-color: blue does and he’d probably guess
> right), but by sucking styling into these complex JavaScript ecosystems we
> lose that approachability.

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".

~~~
lewisflude
I think the jab is more because it's "different to how it's previously been
done" vs being "mentally complex".

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.

------
lioeters
I work with a number of frontend developers and designers who know HTML,
CSS/Sass, and a beginner to lower-intermediate level of JavaScript (often
jQuery).

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..

------
bsbechtel
If you call a full stack developer an architect, then people have a radically
different opinion regarding their role and importance to the team.

~~~
vinceguidry
Full-stack development and architect are roles, not skill sets. That's what I
see as going missing in these discussions. Anybody can do either job. Whether
they do them well depends more on their general level of software knowledge,
and not so much on individual skills known.

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.

~~~
mar77i
> Full-stack development and architect are roles, not skill sets.

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.

~~~
vinceguidry
I saw the article as a harkening back to how crafts and trades work. You have
handymen and the craftsmen, who go about their jobs in very different ways for
very different reasons. The author's basic point is that you can't use
handymen to build anything remotely sophisticated.

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.

~~~
mar77i
In an ideal world, few craftsmen would beat more handymen's asses regularly so
they take the things that matter seriously. So how do we get VC to align with
this?

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.

------
icedchai
As a mostly back end dev, I am always in awe of CSS/HTML wizards. I grew up in
the "tables and font tags" era of the mid 90's, and CSS has never quite made
sense to me...

~~~
dsego
CSS doesn't make sense to any sane person, kinda like makefiles. But everyone
doing it is a little bit insane after being at the deep end for so long, that
doing things any differently seems impossible.

~~~
icedchai
Sadly, Makefiles make a _lot_ more sense to me than CSS.

------
mouzogu
A lot of strong, interesting opinions. I didn't agree with everything. I found
this to be a very interesting perspective:

> 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.

~~~
yakshaving_jgt
> 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?

------
Touche
Great article. I think what we're really seeing here is the end of web
development as a craft. It's turning into assembly line and "inefficiencies"
like having people specialize in different things is no longer (financially)
viable, so it's been done away with. It's unfortunate, I miss the craft.

------
t0astbread
If this whole full stack thing came from a massive capitalist exploitation
scheme, then why was JavaScript gonna be the chosen language for everything?
There were far more languages "spoken" by more people who were already
involved in web development - the typical backend languages - and JavaScript
wasn't a particularly popular language either.

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.

~~~
t0astbread
Please correct me on this though - I know I'm probably wrong

------
SuperheroicJo
Both Pickering & Frost seem so out of touch with reality that it's difficult
to read. For one:

> 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...

~~~
yakshaving_jgt
Thank you for this. For a long time I've had a case of Emperor's New Clothes
when it comes to these two people and others in their clique.

I'm glad I'm not the only one who sees this.

~~~
SuperheroicJo
> Emperor's New Clothes when it comes to these two people

Sorry for being a tad slow here, but how so? :) That their opinions about
technology are regarded too highly?

~~~
yakshaving_jgt
Yes, or even regarded at all. Frost and Pickering have both written garbage
here, and it's totally amazing that we all find it so noteworthy.

~~~
SuperheroicJo
100% agree with that, and I'm getting downvoted to boot!

------
boubiyeah
This entire blog post is well written garbage. There is no content.

~~~
dang
Maybe so, but can you please not post unsubstantive comments here?

Also, please don't break the site guideline about calling names.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
lewisflude
Paradigms that CSS-in-JS introduces can be intimidating. Especially from a
taditional perspective of the way we look at HTML, CSS and JavaScript.

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.

~~~
skrebbel
You did not address the author's point, however - that to do CSS, you now also
need to know JS. That's a significant learning curve for people whose
specialism is design, not coding.

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.

~~~
trh88
> to do CSS, you now also need to know JS

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!

~~~
icebraining
Yes, working on a personal project, I can make those decisions. In a team, I
often can't; I have to work on convincing others. Posts like these are part of
that process.

