> > 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
This in my opinion is the way forward rather than artificially setting up boundaries between roles defined by the languages they use.
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?"
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.
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.
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.
>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.
> 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.
Many GUI applications are actually based on a client-server pattern that mirrors the "front-end" v. "back-end" distinction. Often the "server" is a separate CLI app, or even a daemon/service with no interaction with the rest of the system other than via the platform IPC (COM, DBus, whatever).
Consider the traditional large-scale "pattern" of desktop apps, viz. Model-View-Controller. The Model is back-end, the View-Controller pair (which is often tightly coupled anyway) is front-end.
"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 idea of fullstack isn't that you have no preference at all between backend or frontend, but that you can do both. Much like a backend developer could specialize in certain areas, so can a full-stack one.
"he key evidence to me that full stack is mostly BS is that it only crops up in web roles. Outside of web dev, people are still silo'd -- security people and systems developers aren't pulled off-task to go work on the company website. We're completely fine accepting their responsibilities in terms of the product. If you're a front or back-end web dev though, there's this constant pressure of "why haven't you learned to full stack yet?"
The term is defined by web technologies. In other areas we have different names - devops is a similar merging of separate roles (At least in some interpretations of the loaded term).
I've been in orgs where the job of the DBA was left for developers. In many IOT companies the hardware guys also do low level software. Game development in smaller shops tend to mix tons of roles into a single person.
Just because we don't have a name for it doesn't mean it doesn't exist.
>The idea of fullstack isn't that you have no preference at all between backend or frontend, but that you can do both.
Either front/back specialist can google things these days and "do" both sides. If the only goalpost is simply "doing" front or back end, then that just backs my argument that fullstack is kinda BS.
The impression I've always been given is that fullstack was good at both, not simply "able to write something that works" in both.
This qualification is important because...
>Just because we don't have a name for it doesn't mean it doesn't exist.
... the name for it has always been "doing extra work without getting appropriate compensation".
I think it might mean things to different companies, but in most places I've worked, there's definitely a feeling that either front-end or back-end developers should try to limit how much they modify "the other sides" code.
It isn't just a question of capability, if your organization is set up with front-end and back-end developers Conway's law is going to result in a fairly separate front end and back end world that is worked on almost exclusively by the "right" kind of developer - similarly to how most developers will stop designing anything as soon as someone with "Design" in their title joins the company.
Conway's law says that your design will reflect your communications structure. Front and back end teams will produce front and back end systems. B2B and B2C teams will produce B2B and B2C systems.
People have different skills and interests, so even a 100% "full stack" team tends to develop unofficial silos unless management prevents it.
What does "good at both" even mean? Where I come from it's "good enough given our time and resource constraints" and generally that's a business decision and not a technical one.
To add a counterpoint to your evidence, I think an important part of why full-stack tends to be a thing and that front-end / back-end silo less than other disciplines like infrastructure and security is that front end and back end developers more often have a symbiotic relationship. In a fully siloed world, where front-end developers never touched the backend and vice versa, both groups would be completely unable to deliver value or do much of anything useful on their own. That's definitely not true of the examples you provided.
> The key evidence to me that full stack is mostly BS is that it only crops up in web roles.
Scientific computing / Data Science / Machine learning is an area that benefits from people knowing the full stack. Siloed environments, where the scientists don’t talk to the engineers and the engineers don’t talk to ops are especially poisonous to this type of work.
Research and science requires a lot of trial and error and the compartmentalised waterfall style of development doesn’t work well.
Best results come from teams of generalists working as specialists.
What if my "thing they are best at and enjoy the most" is just creating new functionality, no matter what language I use? There's no place for me on a team of pure specialists.
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.
This is why I love single file Vue components[1] with scoped CSS/SASS. The styling for the component in question is right there with the markup and JS, and you know it's not effecting any other HTML with it's declared classes/styling. Breeds a lot of confidence when making changes without having to follow more rigid and fragile paradigms.
Obviously you will still have global styles and themeing but figured this is at least worth a mention.
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
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.
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.
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.
> 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.
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.
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.
> Anything less than ‘real programming’ is now considered trivial, silly, artsy, female.
I am a very strong supporter of feminism, but this kind of reasoning needs to stop.
The idea of "as a man you're biased from your position of power, therefore your opinion is invalid/worthless" means that the opinion of any men can be shut off automatically just by finding a gender twist on any debate. It's incredibly condescending, and frustrating, since any rebuttal you might try will be dismissed as your inability to see the other side, no matter how tenuous the connection to gender is. I would even go as far as to say that it's a mirror of the old "these are men things, as a woman you wouldn't understand" that was sadly common in the past.
While I'm very happy to see women empowered and their perspective being taken into account more and more, I'm also worried about the rise of any system that leads to the opinion of a group not being listened to. That is never good, period.
And to be clear, I'm not equating the current trend of dismissing male ideas to the suffering of women under patriarchic societies. Just pointing out a worrying development.
There is a bias against the value of design in FOSS, the dismissive attitude described does exist, but I don't think that bias is gender based. The argument draws from outdated principles about gender division where "female" = "artistic/emotional/right-brain" and "male" = "scientific/rational/left-brain", concluding that HTML and CSS being "layout" makes them "design" and therefore more "feminine."
But HTML and CSS aren't art, nor is layout a "creative" activity. HTML and CSS are configuration. They're no more feminine than JSON or a Lua table. I don't think there's ever been a time where, even if the gender bias described existed, it was ever applied in the way described.
Graphic designers tend to be pretty well respected, even though they are also very underrepresented and needed in the FOSS community. People that mainly work with HTML and CSS are less valued because they're seen as mere "transcribers" of the design made elsewhere, or at least that's my perception.
>I am a very strong supporter of feminism, but this kind of reasoning needs to stop.
Yes, and insofar as feminists continue to use this reasoning, we should reduce our support. It may seem like a sad case of a few bad actors poisoning the well, but the lack of outcry by other feminists implies, to me, that the movement has gone rotten, no matter how I wish it weren't so. If you keep poking your allies in the eye, you can't expect them to remain allies for long!
Well, feminism is about freeing people from gender based discrimination, so it also includes freeing men from those societal expectations (like being the only ones to be conscripted / go to war).
But at least in the specific issue addressed in my message (someone's opinions and talent being ignored due to their gender) I think it's hard to argue that women have historically gotten the short end of the stick.
Feminism is about women's rights. Whenever men rights groups(or egalitarian groups for the matter) fight for men's rights - like increased domestic abuse shelters, parental rights, custody rights etc. - they find feminists lobbying in the opposition.
I agree that women have historically gotten the shorter end of the stick in this area. But that's hardly classified under suffering - especially in an era where the barrier of entry for women in everything they feel marginalised in has been lowered artificially to accommodate them.
Feminism means many different things to many different people.
The reductionist statement made is usually "Feminism is just about equality" — a claim quickly invalidated when you consider the Swedish Feminist Initiative political party had as official policy in 2014 that men and women will earn the same money for the same work, but men must now pay more income tax than women to address historical imbalances.
Well, my answer would be that such a measure would not be feminist - it can't even be classified as positive discrimination since gender, unlike race, is not hereditary.
I guess you could chalk that to a "no true Scotsman" fallacy, but I'm fairly certain that the majority of people who self identify as feminist would not support such a measure - I have no numbers to support that claim, as I wasn't even aware of that party's existence.
Not surprising from Brad. Every once in a while one of his articles show up on hacker news. He's good at creating debate, mostly because what he writes is always a bunch of BS wrapped in this kind of comments that make people want to comment.
I yet have to find an article from him about engineering that makes any sense. He's able to write a few lines of jQuery this seems to make him feel like he knows so much about things he has no experience on.
Why do you feel compelled to defend Frost's "programming chops"?
Frost can publish his ideas about JavaScript being intimidating because the naming convention is camelCase and not kebab-case, and it's fair game for any other programmer to point out that Frost doesn't know what he's talking about.
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.
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.
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.
> 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.
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.
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.
I would understand it if any actual examples of men dismissing HTML and CSS as artsy or female were given, but they aren't, instead this association of them with femininity is being straw-personed into being as an excuse for ranting against an imagined bias.
Pioneering women were crucial in the development of CS as claimed, but HTML and CSS were both created by men so the author's accusation of denigrating the contribution of women is simply not a factor in this issue. Characterizing HTML and CSS as feminine in this way is promoting exactly the sort of gender stereotyping these rants are claiming to oppose.
I'm afraid this is what gender wars activism has come to - fabricating and promoting fake gender stereotypes and associations so they can keep fighting the good fight for it's own sake.
I currently work with women (and men) who feel their roles as front end devs are considered less than our back end devs within our company. We also have the worst front end "big ol' ball of Javascript" spaghetti mess I've ever seen from people trivializing not just HTML & CSS but also JS. I didn't see it as a gendered issue until it was brought to my attention by female co-workers who had experienced the same thing at multiple companies.
> ...women (and men) who feel their roles as front end devs are considered less...
> I didn't see it as a gendered issue until it was brought to my attention by female co-workers...
Female co-workers bringing an issue to your attention doesn't make it a gendered issue and you literally refer to it as a non-gendered issue, though parenthesising men.
As a full-stack JS dev, having come from a .NET background, through a pure frontend job, to a full-stack position, I regularly have to shoulder banter from Scala colleagues' (both male and female) snark at Javascript - primarily because it's existed for a long time and been a barely justifiable mess for most of that time.
If however only or predominately females encounter attitude and males dont, then it is likely gendered issue. And vice versa.
People tend to assume that I do frontend and try tu push me toward ui design side of things, despite me being completely crappy at that. It was real problem only once, normally I can easily negotiate different position. But, it requires me to often explain that I really cant design - I dont have to explain I dont do any other technology to avoid position, ever. People dont assume me to know sql, databases, server, java, but they do tend to assume me to be good at design.
> If however only or predominately females encounter attitude and males dont, then it is likely gendered issue. And vice versa.
Every frontend dev I've ever worked with has received this same treatment, so I would find it difficult to believe it's even predominantly females; but maybe I've met a lot of exceptions.
Oh, I absolutely know that frontend is undervalued. I am even one of those who undervalued it too.
But, I am not even frontend developer and get the assumption that I am one. When I was nearby frontend, people made further assumptions about which part of it I do - they expected me to do aesthetic work altrough I am really bad at it and were sometimes oddly awkward when I wanted to talk about architecture or algorithms. I don't think male frontend developers are not undervalued, but the assumption about which part of it they do is on average a bit different.
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.
For whatever it is worth, I personally perceived HTML and CSS as less then programming and primary artsy/aesthetic. It was not real to me and I did not seen HTML/CSS as equal achievement. I don't recall where and how exactly I picked that attitude, it was years ago. I picked it by osmosis as "of course" attitude along with other attitudes I was reconsidering lately.
I honestly think it is less, speaking as someone who does it day in and day out. That HTML/CSS is so complicated to require specialized positions to handle the intricacies of these broken technologies, instead of having well though-out systems and visual design tools, speaks volumes about the rotten state of the web and and web development as a discipline. In this day and age we should not need a small army of so called developers to maintain a single marketing website.
Considering the other comments here, this isn't going to be a popular opinion, but we should probably being talking about the data rather than how ridiculous/insecure it seems.
What's at issue here is that coding is a combination of EQ and IQ, and when we create environments that favor "rightness" over common empathy and effective communication, we turn our backs on the people who favor thinking that way (no matter their gender) and we make worse products as a result.
We're not writing code for machines, we're writing code for people.
It seemed like a normal discussion until this random buzz topic popped up; albeit, sure we need to solve the ills of this, treat all types of people normally. ~ Wtf does Gender Bias have to do with React not being good because if you like/write css and dont know js you're fucked?
You can build a scary amount of social capital (which usually translates to financial capital) in this industry by just pushing the narrative accepted by a certain clique.
- Everything bad in the world is because of straight white men, and capitalism.
- Coding is not part of a coding job. Culture is more important.
- Making people feel happy is more important than building something that works.
- Truth is subjective, i.e. post-modernism.
Parrot the above talking points with an air of self-importance and you'll be well on your way to a highly-paid do-nothing job.
The 4th one about truth is perhaps an exception, unfortunately some people might agree to that. Although, it's a bit abstract for most useful discussions.
1. If you haven't seen the demonization of white, "cisgendered" men in the tech scene and culture in general, I don't know what to tell you. Maybe you're not in the US (and specifically, West-Coast) tech scene.
Edit: I had to add quotes, as I really dislike that word.
2. A more subtle point, but I've seen enough articles written by members of the tech scene to be convinced this may be a genuine issue. Articles claiming that demanding merit-based software development is bigoted/racist/sexist, others saying that if there isn't equality of outcome for all software devs, then the issue is the stated goals of software development.
3. Similar to 2
4. Again, very US-centric. There is a definite movement towards a person's "lived experience" and feelings (of being "safe" or whatever) is more important than objective facts.
The points above are true to the extent that I decided the West-Coast US tech scene was not for me, and returned to my home country.
I know what you refer to, as I worked in SF recently for several years. I don't think it is true that white men are unilaterally demonized by any significant group in American culture today. There is obviously some of that occurring, and occasionally the behavior is a bit troubling, but I don't there is any major problem to worry about. The behavior you are concerned will go away naturally as the recent social movements mature and are able to see some of the progress they are making. In general, most people don't support the extreme behavior, so there is only limited space for it to survive.
I do think patient and healthy pushback can be appropriate in the right circumstances. It is a tricky issue though. There are some very legitimate (and some less so) reasons motivating such behavior, even if, occasionally, some of the specific actions themselves are troubling. Anyone claiming rigid, simplistic absolute statements here seems wrong to me.
Perhaps I'm biased towards (and privileged enough to do so) being patient with what I see as some temporary flare ups that are side effects of attempting to process and rectify some of the results of absolutely terrible historical occurrences over the past several hundred years. I don't know. We will see how the next 10 or 20 years go.
I have to go so I won't address the other issues. These topics are tricky and hard to discuss with a short comment.
I will say that the way you are discussing them is preferable to the person I accused of straw-manning. You seem more capable of considering nuance, which I appreciate.
The author didn't write it, nor did he attempt to support it. I think the author made the mistake of quoting too heavily such that it's easy to mistake another author's words for his.
I didn't think I'd need to quote his actual words, but that's where we are:
> Whether it’s explicit gender bias or not, it’s important to recognize that people are afraid to speak up about how they feel for fear of getting dog-piled on by a bunch of “real” developers. That needs to change.
While I might not agree with everything he says, the gender bias lawsuit against Google revolved around women being siloed in front-end development (as well as starting at lower ranks/pay, etc.). So it doesn't seem all that far-fetched and there may be a kernel of truth there, depending on where you are and what your environment is like.
"Logic programming is considered superior to HTML/CSS even though it isn't. Just like one gender thinks that they are superior to others even though they aren't."
I've seen the claim made elsewhere that the server-side web architecture is sexist, so I wouldn't be surprised if it was meant to be taken literally (although I was astonished the first time I saw it).
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?).
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.
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.
> 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).
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.
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.
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.
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.
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.
I found the political angle he took to be daft as well.
I became a full stack developer for the same reasons as you, I like assuming the responsibility of every aspect of a product's development- plus, working in different aspects keeps things fresh. Building beautiful ui with react is really fun, so is building the services that app talks to. Personally, being really good at both of those things has been super profitable for me.
I associate the "full stack" trend with the rise of startups, not the rise of SPAs.
The article is mainly about how writing HTML and CSS in JavaScript means that designers are expected to be full stack developers. The author says he is confident developers can handle it. Where do you get the idea he thinks there should even be a DBA?
If "full-stack is about accountability", does that mean specialization is about avoiding accountability?
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.
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.
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.
> 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".
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.
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..
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.
Those are fair points. However, also missing in these discussions is the fact that oftentimes throwing more people at a software problem is known to not necessarily increase output, and can sometimes have the reverse effect. Depending on the situation, having specialists on the front-end and back-end may not improve things unless there is a specific goal/problem in mind that a specialist in one area can solve.
> 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.
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.
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.
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...
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.
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.
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.
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.
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...
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.
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.
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.
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!
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.
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.
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.
> Historically, different languages suggested different roles.
Otherwise known as silos. In my experience, front-end developers and back-end developers not working together but each "role" merely throwing their results over the wall and expecting the other side to do whatever it is they're doing is a huge problem. We supposedly have DevOps but we don't even have sufficient collaboration within the Dev part of that equation.
None of these roles delivers a usable product or solution to a problem on its own.
CSS-in-JS or defining styles at a component level is not a problem per se either. It can become a problem if there's a mismatch between the document structure envisioned by a designer and the component architecture devised by a developer. Component architectures aren't foreign to designers though, the perhaps most prominent example ironically being Brad's own Atomic Design paradigm.
Just yesterday I saw this talk about "Angular for Designers" by Stephen Fluin, which advocates making JavaScript applications, of the Angular variety in this case, more accessible to designers: https://www.youtube.com/watch?v=LP-fNM8OITI
This in my opinion is the way forward rather than artificially setting up boundaries between roles defined by the languages they use.