13 ms·

Big ol’ ball o’ JavaScript

95 points by fagnerbrack 8y ago

lewisflude 8y ago
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 8y ago
  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.
  - lewisflude 8y ago
    That's a good point. Developer/designer productivity being lost in favour of some other wins isn't always the best tradeoff for every team, and the fact that it's becoming normalised does put some developers/designers in an awkward position. 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.
  - trh88 8y ago
    > 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 8y ago
      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.
    - skrebbel 8y ago
      That's exactly what I wrote, right?
  - beefalo 8y ago
    How common is it to have designers that are actually writing css and html? Of the dozen designers I have worked with, every one of them was using a tool like Invision or Sketch and as far as I know, have no html/css knowledge.
captainbland 8y ago
"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.
- lewisflude 8y ago
  It does seem like a bit of a cherry picked example. However, for the most part, I think it's great how intuitive CSS naming conventions are. I think it's relatively easy to learn enough CSS to be dangerous.
- DougBTX 8y ago
  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 8y ago
    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 8y ago
      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-the-challenges-of-css-at-scale-85789980b04f https://medium.com/front-end-developers/css-modules-solving-... [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/
jondubois 8y ago
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.
yakshaving_jgt 8y ago
> 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 8y ago
  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.
bsbechtel 8y ago
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 8y ago
  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 8y ago
    > 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 8y ago
      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.
Aeolun 8y ago
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 8y ago
  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_ 8y ago
    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 8y ago
      A team can have redundancy without every developer having to know the full stack.
BjoernKW 8y ago
> > 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 8y ago
  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?"
trh88 8y ago
> 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 8y ago
  > 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 8y ago
    Brad Frost clearly doesn't want to learn anything else and apparently people keep hiring him.
    - test1235 8y ago
      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 8y ago
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 8y ago
  > 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).
- pseudalopex 8y ago
  The "full stack only" trend isn't limited to small organizations.
321yawaworht 8y ago
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.
- blahblahblogger 8y ago
  I lol-ed a bit here.
- scandox 8y ago
  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-problem-with-full-stack 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.
  - yakshaving_jgt 8y ago
    I think you're being overly-generous towards a nonsensical claim. Attributing "gender bias" here is stupid and harmful. I'm repeatedly astounded that these people are taken seriously. It's charlatanry.
  - kace91 8y ago
    There is a perception of front end/user experience being easier than logic programming, in the same way that STEM degrees are considered harder/superior to other degrees. The implication of trivial -> female is quite unwarranted and unjustified IMO.
  - 8y ago
deleted 8y ago
[deleted]
boubiyeah 8y ago
This entire blog post is well written garbage. There is no content.
- deleted 8y ago
  [deleted]
- dang 8y ago
  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
Illniyar 8y ago
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 8y ago
  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.
- pseudalopex 8y ago
Touche 8y ago
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.
fuball63 8y ago
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 8y ago
  > 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 8y ago
    I should have learned by now to always double check before assuming something isn't Turing complete!
gerbilly 8y ago
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?).
SuperheroicJo 8y ago
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...
- jayko 8y ago
  The author is just trying to shoehorn his political ideology into a completely irrelevant topic to score social points with his friends and pat himself on the back. There is no need trying to find anything of substance here. He is hearing hoofs, and imagining zebras instead of horses.
- yakshaving_jgt 8y ago
  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 8y ago
    > 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 8y ago
      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 8y ago
mouzogu 8y ago
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 8y ago
  > 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?
darepublic 8y ago
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.
aristophenes 8y ago
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 8y ago
  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.
icedchai 8y ago
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 8y ago
  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 8y ago
    Sadly, Makefiles make a lot more sense to me than CSS.
room271 8y ago
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.
lioeters 8y ago
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..
t0astbread 8y ago
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 8y ago
  Please correct me on this though - I know I'm probably wrong

95 points by fagnerbrack 8y ago

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 8y ago
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.
- lewisflude 8y ago
  That's a good point. Developer/designer productivity being lost in favour of some other wins isn't always the best tradeoff for every team, and the fact that it's becoming normalised does put some developers/designers in an awkward position. 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.
- trh88 8y ago
  > 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 8y ago
    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.
  - skrebbel 8y ago
    That's exactly what I wrote, right?
- beefalo 8y ago
  How common is it to have designers that are actually writing css and html? Of the dozen designers I have worked with, every one of them was using a tool like Invision or Sketch and as far as I know, have no html/css knowledge.

captainbland 8y ago

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

lewisflude 8y ago
It does seem like a bit of a cherry picked example. However, for the most part, I think it's great how intuitive CSS naming conventions are. I think it's relatively easy to learn enough CSS to be dangerous.
DougBTX 8y ago
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 8y ago
  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 8y ago
    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-the-challenges-of-css-at-scale-85789980b04f https://medium.com/front-end-developers/css-modules-solving-... [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/

jondubois 8y ago

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.

yakshaving_jgt 8y ago

> 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 8y ago
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.

bsbechtel 8y ago

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 8y ago
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 8y ago
  > 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 8y ago
    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.

Aeolun 8y ago

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 8y ago
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_ 8y ago
  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 8y ago
    A team can have redundancy without every developer having to know the full stack.

BjoernKW 8y ago

> > 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 8y ago
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?"

trh88 8y ago

> 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 8y ago
> 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 8y ago
  Brad Frost clearly doesn't want to learn anything else and apparently people keep hiring him.
  - test1235 8y ago
    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 8y ago

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 8y ago
> 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).
pseudalopex 8y ago
The "full stack only" trend isn't limited to small organizations.

321yawaworht 8y ago

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.

blahblahblogger 8y ago
I lol-ed a bit here.
scandox 8y ago
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-problem-with-full-stack 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.
- yakshaving_jgt 8y ago
  I think you're being overly-generous towards a nonsensical claim. Attributing "gender bias" here is stupid and harmful. I'm repeatedly astounded that these people are taken seriously. It's charlatanry.
- kace91 8y ago
  There is a perception of front end/user experience being easier than logic programming, in the same way that STEM degrees are considered harder/superior to other degrees. The implication of trivial -> female is quite unwarranted and unjustified IMO.
- 8y ago

deleted 8y ago

[deleted]

boubiyeah 8y ago

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

deleted 8y ago
[deleted]
dang 8y ago
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

Illniyar 8y ago

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 8y ago
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.
pseudalopex 8y ago

Touche 8y ago

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.

fuball63 8y ago

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 8y ago
> 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 8y ago
  I should have learned by now to always double check before assuming something isn't Turing complete!

gerbilly 8y ago

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

SuperheroicJo 8y ago

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

jayko 8y ago
The author is just trying to shoehorn his political ideology into a completely irrelevant topic to score social points with his friends and pat himself on the back. There is no need trying to find anything of substance here. He is hearing hoofs, and imagining zebras instead of horses.
yakshaving_jgt 8y ago
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 8y ago
  > 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 8y ago
    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 8y ago

mouzogu 8y ago

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 8y ago
> 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?

darepublic 8y ago

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.

aristophenes 8y ago

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 8y ago
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.

icedchai 8y ago

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 8y ago
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 8y ago
  Sadly, Makefiles make a lot more sense to me than CSS.

room271 8y ago

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.

lioeters 8y ago

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

t0astbread 8y ago

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 8y ago
Please correct me on this though - I know I'm probably wrong