TL;DR: There are a lot of people who love both JS and UX/CSS/etc. If we stop labeling people just as “JS developers” or “UX developers”, we can ach...
For further actions, you may consider blocking this person and/or reporting abuse
In my book, I promote an even more open definition of developers. Basically anybody who works on a software product. We have to stop being divisive, and look to solving user problems.
Good article. And a good point about social perspective. Although I do not really see this 'war'. But that's likely because I do not find myself in those social surroundings.
I like and use Vue. I use a lot of components but I won't use JS if it can be done with CSS. Simply for performance benefits. But that doesn't mean the HTML won't be rendered with JavaScript on build time or on server side rendering stage, even being hydrated on clientside. I think JS and CSS can work perfectly together.
Yeap, likely Vue has fewer conflicts about “CSS vs. JS”.
I think it is because they didn’t start CSS-in-JS movement with very aggressive ideas at the beginning (“you do not need CSS anymore”, etc).
BTW, I really like CSS implementation in Vue. It combines CSS syntax with the best part of CSS-in-JS (one file for the whole component with built-in selectors isolation).
I think you are right about that. I like reading react articles though, a lot of concepts within the Vue ecosystem are and will be based on those of React. But I also think Vue does a better job of combining both CSS and JS. That also goes for UX, it got a place at both sides. At least that's how we look at it from within our company.
Furthermore, I think that because React is initially so JavaScript focussed, that it's much harder to think outside the box of JavaScript. Note that my knowledge of React is not that extensive.
That might also be the case for the 'CSS guys' you are talking about. They may not be able to think outside that box that easy.
This makes it hard to combine both. But that's my opinion and interpretation of this 'war'.
:)
Were are at war. And even if we stop it - The Great Divide would exist.
It's more about mindset - black and white, cats and gods, meat and fish, iPhone and Android.
My wife is HTML-CSS-(js) person, as long as she started as "PDF-to-HTML" developer. She likes "the picture". Every time I am writing some CSS - she is crying - so much better it could be. But I am not understanding her.
I honestly not giving a shit about BEM-compliance. Hello! We are using CSSModules!
She could not understand what the fuck is redux, why I need it.
It's super cool to work together.
Redux is a horrible solution for the problem it tries to solve. But at least, when it was invented, there was an actual problem to solve. In the cssinjs case, the problem doesn't even exist. It's just another way of making web development a bit more convoluted, retarded and broken. Whats going to be next, ascii in js?
Well, one could argue that everything global in css is a problem.
I hate css in js, but i like two solutions to this problem:
I'm exhausted with all the semantics around programmers and the different types. A developer learns to use the tools they need to get the job done and I think we've tried too hard to force specializations.
It's like a damn class system in an MMO. Everyone is so concerned about what is "best" and what is "right".
I never grasped this mentality. We have so many tools for a reason. Just like games. Sometimes I want Chrono Trigger for a great story and experience and sometimes I just want Kitten Cannon.
I feel like there's another component to the problem that honestly bothers me the most: the developers are way too dogmatic. For some reason we look at the world like our own point of view is the only one.
When we argue about CSS, we either perceive CSS-in-JS as the only right or ultimately wrong way (depending on the view). We can't accept that in a certain team, requirements or context one or another solution is more applicable than another.
For example, if the team has established a design system with well developed React components library, it will be a crime to build a landing from scratch ignoring the library. On the other hand, when the team has no or little prior experience with React and needs to quickly ship a marketing page, it will be insane overkill to use Gatsby only because everyone on Twitter says so.
I myself is guilty of getting it too far. I remember when I finally understood the concept of tests I came to the conclusion that there are the devs that write tests for everything and the ones that didn't wake up yet. When I'd meet a dev that doesn't write tests regardless of the context I considered them amateur. Now I work on my own business and write tests only when they are absolutely necessary.
I'd like to see developers became more open-minded and accept that everything in the world is relative and what's good for team working in the enterprise might be deadly for small team work on a pre-market-fit startup.
Interesting take on the topic! Personally I lean towards the JS-JS-JS side of things as I enjoy the sheer amount of tooling and enhancements that have been brought over to JavaScript, but I was on the vanilla side years ago just like everyone else. Although I wouldn't consider myself a CSS guru, I'm good enough to get a responsive layout going, and I find with styled-components in React this is much easier to manage (w/ effective code splitting) and modularize instead of a vanilla stack.
I will say that while I agree with many of the points you made, I saw a similar post labeling the other side of the frontend spectrum (the HTML-CSS-JS side) as claiming accessibility and design as their core focus rather than performance, which I think I agree with more. I would also bundle semantic markup into this as well as I know I do not consider this a first-class citizen when writing components for the first time.
Overall I think it's negligent to say either is more effective/efficient than the other since both sides present valuable aspects to building modern web applications. I'll list out a few of my thoughts on what is easier to implement (and maintain) on both sides:
HTML-CSS-JS:
JS-JS-JS:
Array.map()to generate content rather than hardcoding the markup, I'm happy)I like both. I wrote a blog post about it:
The "Backendification" of Frontend Development
Sorry it's so long, but people seem to like it :)
I try to get the best from both worlds. I'm doing a design system for my company using React and styled components via styled-jsx. I give styled components for React devs and a CSS file for web designers. IMO, devs trends to be very partials choosing one of two options instead choosing both.
BTW, you can try Astroturf zero-runtime CSS-in-JS. Compare to SC it has better performance and it generates a static CSS file, which you can give to web designers. Could be even simpler build system. And it has the same API.
Awesome. Thanks for the tip!
This thread seems to be on point, though on another aspect of this divide:
Thanks for the boost! To be honest, I kind of wrote that thread as a subtweet of this article (and of the overall "debate" recently more generally). I think that when we look at the "purely technical" questions we discover that everyone is trying to solve different problems, but there's ultimately no such thing as a purely technical question when humans are involved.
And then of course there's the question of whose problems are prioritized.....
Mind you, I think the OP has admirable positive intent! But I think that papering over the really nasty gender dynamics underneath all of these debates is unlikely to lead to a lasting "peace."
Thank you Betsy, I didn't know it was sparked by this. I feel like we're going meta now then.
Yesterday I was reading this thread
and today yours.
I wonder whether in 3 to 5 years your argument will be still valid, hopefully not but I might be a tad optimistic.
yeah, this is one of those things that you either learn or you shun at the risk of becoming one of those "rockstar ninja developers" nobody really wants to work with :D
Do you mean "prioritized by the industry/companies to be solved" ? Or do you mean something else?
You say "build tools are not well accepted in a modern CSS community" and that we should use linters, but people have been using Sass and Less for donkey's years, which are build tools that won't transpile if there are CSS errors.
So I'm not sure that's a problem.
Hi Andrey, do you mean by "UX developers"? Why not to use term "UI developer" regardless technology, whether it is JS, CSS, SVG, pure HTML controls, WebGL, Canvas or QT? After all business or end user doesn't care about tech.
I do not support this label at all. The idea, that it is a fake label and real developers mostly bigger that this separation.
The solution should fit the problem. Right now, I'm building a web app that is very user interaction driven, and using React and css-in-js for that because the CSS needs to be very dynamic. Then I'm also building a blog to support this web app, and the primary concerns are initial rendering time and meta tags for social media. So I'm building a server-side rendered app that's traditional HTML, CSS, JS. The solution should fit the problem.
I am 100% into the idea of a 'front end' conference! Any developer working with the front end should know some UX and marketing-tech basics, IMO, in addition to the tech we build the sites with; even if it's a static site! Expanding a 'front end' conference to include marketing and UX/Design talks makes a lot of sense to me. (Even if that might be a step further than you were thinking.)
Some people are great at both things, but we still see lots of "mainly CSS devs" that simply can't / don't want to get into the JS heavy stuff, as well as "mostly JS devs" that are new to front end (either new to programming or coming from desktop / back end) that can't grasp the most basic CSS concepts.
But I don't they they are to blame. Sure, some have that "CSS is below me" attitude, but for the most part, the actually want to learn it, it's just that it gets really hard to find a decent source.
Most bootcamps, courses and resources out there barely burns through CSS from a "quick results" approach, sometimes even deferring to bootstrap, instead of teaching the core concepts.
CSS-in-JS is great, but it also allows this kinds of devs to mostly get away with it... until something fails and they bash CSS for their own flaws.
But the industry is in such a great demand for JS (mostly React) devs that they get really good jobs with great salaries anyway. Some companies proud themselves on "our designers make their own CSS", which is exactly just as wrong.
And that's the real issue right there. HTML, CSS, a11y and all that stuff requires a completely different skillset than "real programming", as well as different from "actual design". So most devs don't feel like CSS should be their responsibility, and neither do most designers.
JS is mostly about logical intelligence, HTML+CSS mostly about linguistics intelligence, and actual design (as in working with graphic tools) requires visual-spatial intelligence.
Some people are great at all of them, some at two of them, and some really shine in a particular one. But unless we start recognising the differences and respecting the role of whoever makes the HTML + CSS, we're gonna be stuck in this war.
That and actually providing decent sources for CSS learning, that get deep into the theory instead of pretending people to memorize a gazillion (and ever growing) set of properties
There is no such thing as UX developers. There are only UX designers, and they are nothing compared to a typical developer. Their thinking process is way different than a dev's. And I'm saying this from experience.
I don't know. None of it rings true to me but maybe I'm missing out on some larger experience. My take:
A Different Kind of War
Anton Frattaroli
Very interesting article. I can say I'm the kind that loves both CSS and JavaScript, gonna try linters!
People who specialize in different things have especially a lot to talk about. I highly recommend for backend devs to go to frontend conferences, and vice versa.
What is it with some developers that they value their opinions about how things are supposed to work more than the languages and libraries they are supposed to work with?
I don't disagree, that's why I go into a lot of other skills the define programmers in my book. People who code Web apps and people that code drivers, share more in common than they have apart.