TL;DR: There isn’t one. There’s no short way to say any of this, yet one of the reasons you keep fighting is because you misunderstand what the fight is about. Read the damn article. Please and thank you.
I hate intros. Let’s just dive in and I’ll fill you in where pertinent.
The Great Divide
Chris Coiyer’s essay "The Great Divide" broke the frontend dev community, inviting no small amount of snarkiness and drama on Twitter and elsewhere. In case you haven’t read the piece (and you should), it revolves around an observed division between frontend developers who use primarily JavaScript-related technologies to do their job, and frontend developers for whom JavaScript is only one of the many technologies they employ to do their more UX-centric job. The thing that everyone seems to be missing is that this is not a prescriptive view of how frontend-land should work, but rather, a descriptive view derived from real-life interviews Chris and his buddy Dave Rupert have conducted on their podcast ShopTalk Show (dot com).
In other words, the split is real. Chris and Dave are merely putting it into words.
Chris concludes in “The Great Divide” that this rift in focus is happening because frontend-land has basically ballooned away from the old context where frontend development was comprised of merely styling server-rendered components. He notes that many frontend developers are using JavaScript in a way more closely reminiscent of usual MVC-style backend programming, while others are focusing on using a more rounded set of tools, and primarily CSS, to make the frontend experience better and more accessible, and thus, if we’re to helpfully describe the jobs frontend developers are being hired to do, we should be distinguishing between JS Engineers and UX Engineers.
Class Warfare
The discussion, though, immediately devolved into whether JS Engineers (I’ve gone ahead and accepted Chris’s proposed nomenclature) do more work than UX Engineers, and whether UX Engineers deserve to be paid the same as JS Engineers.
I should note: if you've seen the discussion online and the outline I'm presenting doesn't jibe with your version of the events, that's fine. The web is a big place, and it's entirely possible you and I have witnessed two sides of the same coin. I'm trying to contextualize what I've seen with this narrative I'm building; I hope that's OK with you.
Anyway, as a surprise to nobody in the industry, we have a recurring theme of derision and general snootiness toward other people’s tech, an attitude which developer Aurynn Shaw incisively terms “contempt culture”. In this case, we began to see this contempt target UX Engineers... and I’m certain a number of you reading this are now thinking “you mean designers, though, right? How is design also engineering?”
Because here's the thing: even when no offense is meant, a lot of people don’t think UX Engineers are a thing, or that they’re glorified web designers at best. I observed this same attitude in the discussions surrounding the ShopTalk interviews of people who were primarily doing design-centric work. I’m not going to nag you one way or the other about whether this is correct; I’m merely pointing out that this is an attitude that people hold.
I'm likewise going to point out that people who take part in this culture of contempt often don't mean harm with their dismissiveness (citation needed, sure, but it’s my writeup). People are not necessarily trying to be jerks when they dismiss Ruby for being slow, nor when they dismiss JavaScript for “having been written in ten days”, nor when they dismiss Java as tech for stuffy old farts, nor when they dismiss Elixir as a toy language, nor when they dismiss PHP for being PHP, nor when they dismiss web development as “not real programming”, nor when they dismiss UX Engineers as “not engineers”. Sometimes the snootiness is just abrasive opinion based on passive biased observation.
Not many are keen on defending this behavior, though, because to people specializing in the technologies being disdained, these opinions often constitute a direct attack. You can pin a huge asterisk on this point, but basically: turns out when a person feels other people are shitting on the thing that pays the bills, that person might (rightly or understandably, your choice) get defensive. And that’s precisely what we saw on Twitter.
Jen Simmons (W3C's Working Group, Mozilla, Layout Land) describes the animosity toward UX Engineers as “class warfare”, and shot a number of choice spicy tweets toward a particular lean of JS Engineers:
Jen Simmons@jensimmonsIt’s beginning to feel like the HTML-CSS-JS vs JS-JS-JS war is a class war. If your project has a budget of millions, “of course” you should use a complex build process and a JavaScript framework that handles everything (according to the folks who believe this). The pressure…19:48 PM - 27 Jan 2019291
910
Jen Simmons@jensimmonsThe pressure to re-architect the web itself to conform to these ideas, and abandon the original design principles (HTML as a base, super robust, works with *all* devices; CSS for styling on top of that, with a cascade; JS for bonus fanciness) is fierce. Feels like a class war.19:48 PM - 27 Jan 2019
Jen Simmons@jensimmonsRich vs poor.
Massive teams vs everyone else.
Building a web that works for everyone vs a web that only works for those with expensive new devices and no disabilities.
Architecting a web that favors massive corporations and pushes out less-powerful voices and ideas.19:48 PM - 27 Jan 2019
Jen Simmons@jensimmonsIt does feel like a war. A war for the future of the web. When I read “the standards bodies don’t care about web developers” I see someone wielding a weapon in this war — pushing to get rid of the design principles that made the web for everyone. To give the powerful more power.19:48 PM - 27 Jan 2019
I’m not doing you the (dis)favor of including any of the shittier tweets thereafter flung in Jen's direction: it’s the web—use your imagination. On the more sensible side of things, though, this argument gets more nuanced. Dan Abramov (React, Redux, create-react-app) writes:
Dan Abramov@dan_abramovThe real class war: class vs className21:06 PM - 27 Jan 2019
Dan Abramov@dan_abramov(Despite the humorous nature of this tweet, I want to mention I empathize with concerns about JS developers not always putting sufficient care into a11y and perf of their solutions. This is an educational and cultural problem, and it’s on *us* as the community to fix.)21:08 PM - 27 Jan 2019
Dan Abramov@dan_abramov((Building walls between communities and calling it a war instead of cross-polination and learning from each other is only going to make it worse))21:09 PM - 27 Jan 2019
I'm obviously putting Dan in the JS Engineer camp because, you know, React. Then there are people who don't fully identify with either of our new frontend designations. For example, Kyle Simpson (You Don't Know JS, Frontend Masters) writes:
getify@getifyThe "great frontend divide" exists, but not because of which skills people pick or what's listed in job descriptions.00:56 AM - 22 Jan 2019
getify@getifyIt exists because the way we treat technology as more important than people means many (most?) will develop a superiority complex over their own choices/path, and look down on other "inferiors".00:56 AM - 22 Jan 2019
getify@getifyThe root problem is lack of empathy. That's what drives the wedge deeper.
Those with a design-primary view of the web often lack empathy for those with a dev-primary view. And vice versa is at least as common.00:56 AM - 22 Jan 2019
Among other opinions, though, you can see folks beginning to tire of the incessant barrage of negativity. Das Surma (Google, HTTP203) sums it up thusly (and I really wish I could say “Surma surmises” but it’s wrong diction):
Surma@dassurma*sigh* okay:
Frontend dev: hard.
Backend dev: hard.
Language design: hard.
Writing docs: hard.
HTML/CSS: hard.
UI design: hard.
Communicating: hard.
Leading people: hard.
Management: hard.
It's all hard. Each one of these is an endless rabbit hole. And it's not a competition.18:23 PM - 21 Jan 2019
Basic as HTML
By the time Surma makes this statement, though, we’ve lost all semblance of a common thread of discussion. It’s no longer about how frondend development is evolving, but about whether CSS and HTML are difficult as technologies, by way of defending people whose job might often go no further programming-wise (though in my case obviously not dismissing the wealth of education and experience required for UX Engineering).
This is where DHH, whose JavaScript framework Stimulus (and indeed his entire work on Rails) pivots on the idea that the web is becoming unnecessarily complex and we’re all better off focusing on making app development as straightforward as possible, gives us his unsurprisingly direct opinion that designing for the web ought to mean making HTML and CSS. Here's his tweet on the subject:
DHH@dhhIt's fascinating to watch this debate over front-end developers from afar, because it feels like a foreign world. At Basecamp, designers do their own HTML and CSS. Most can mock things with JS + Rails too. Programmers do final JavaScript/Ruby. 🤷♂️ css-tricks.com/the-great-divi…00:37 AM - 24 Jan 2019
I’ll admit that I think the discussion did seem to have jumped the shark a bit around the time DHH said this (though in the name of defending UX Engineers, so I’m not faulting anyone).... I mean, isn’t the whole point of web technologies to be accessible? Shouldn’t we take pride on the fact that HTML and CSS are as easy as they are powerful?
Wait, what were we talking about?
Somewhere around this point, there seemed to be a shift in the atmosphere: a secondary argument began to emerge... and it is where I think everything became real convoluted, and it's where people are having trouble reconciling what the hell is even going on with this whole UX vs. JS thing. Because while one side was fighting about whether UX is as cool as JS or whatever, an adjacent and more interesting talk began to make its way forward...
From my personal vantage, it started with DHH, who goes on to make a second appearance in this story with an observation about the state of web technologies, this time in a post about how View Source is on the decline and how we shouldn’t let it die. Here's his tweet on that subject:
DHH@dhhLike a compiler threw up all over your browser. What a sad disregard for the web. twitter.com/sindresorhus/s…15:13 PM - 26 Jan 2019Sindre Sorhus @sindresorhusI learned web development in the early days (long before GitHub) with the "View source" button. The trend of generated class-names makes me sad... https://t.co/JCZleAdCRq
(Here Tom Dale throws a spicy one at DHH; I'm including these for no better reason than it's funny:)
Tom Dale@tomdaleJust compare that compiler-produced gunk to Basecamp's artisanal, handcrafted JavaScript. Amazing to sit back and admire the raw skill and craft that produced an artifact of such expressive clarity. This is the web we must return to.18:36 PM - 26 Jan 2019
DHH@dhhFair point from Tom. Uglified JavaScript is also a transgression against the beauty of the web. Enabling humans to read your HTML, CSS, and JavaScript is a gift to anyone trying to learn. We will redouble our efforts on making that true across all products 🙏❤️ twitter.com/tomdale/status…22:11 PM - 26 Jan 2019Tom Dale @tomdaleJust compare that compiler-produced gunk to Basecamp's artisanal, handcrafted JavaScript. Amazing to sit back and admire the raw skill and craft that produced an artifact of such expressive clarity. This is the web we must return to. https://t.co/xgNvuR2Gbw
Anyway, the idea that View Source is worth saving is pretty interesting, because I knew I couldn’t be the only one who thinks the original discussion is coalescing into a second and more nuanced conversation, namely: what is going on with the semantic web?
Wait, what? Who is even bringing up the semantic web?
Well, look, allow me a brief leap in context. In case you're not familiar and didn't bother reading the article I linked to just now, the semantic web was Sir Tim-Berners Lee's idea for the future of the web, where web pages would be intelligible to humans as well as computers. To be realistic about it, though, the semantic web ultimately amounted to not much more than a bunch of schema tags that we were supposed to throw into our HTML to make it easier for Google to do their job, but while it's fun to be cynical about it, let's not forget the real reason the notion of the semantic web exists: the dream of a decentralized web where everyone owns their data and information silos aren't a thing. More pertinently, though, the semantic web illustrates that, ever since the beginning of the web, there's been the idea that the web is meant to be accessible and open.
Agree or disagree—not the point. I'm only claiming this is what is at the heart of this second round of the fight pitting JS against UX: whether or not JS is becoming bloat that is keeping the web from being accessible and open.
As you can probably tell, this also runs in contempt culture territory, because it implies that frontend Javascript technologies are bad for the web. And while I think this argument has more intellectual merit than whether UX engineers are less cool than JS engineers or whatever, as you might infer, things once again got pretty heated. For the sake of brevity, here's a cursory list of the types of arguments being made:
- Some people argue that using so much JS on the frontend is creating a scene where the fabric of the web that's supposed to tie us together is no longer human-accessible (implication being that's a problem).
- Some people argue that it doesn't matter because the web is only a delivery method for digital products.
- Some people argue that JS frameworks make the web impractical or inaccessible for people with accessibility needs.
- Some people argue that, while accessibility concerns are a valid criticism, it doesn't mean that frameworks and best practices aren't still evolving and this is a solvable problem.
- Some people argue that frameworks are making people overly reliant on technologies not inherent to the web, and new developers are losing grasp of the possibilities of raw technologies.
- Some people argue that frameworks help tame the complexity of the web and allow people to become productive faster.
- Some people argue that frameworks are needlessly bulky and make the web experience worse for people with crappier internet.
- Some people argue that's also a solvable problem....
I wanted to back each of those sentiments with individual tweets expressing them concretely, but that's a lot of work, so I'm using my editorial discretion and not doing any of that. However, you can go on Twitter or Dev.to or Medium and do your own research—people are expressing these opinions.
None of this is new
This whole fight about the state and future of the web has long been a simmering disturbance in the Force, usually felt by developers as no more than a dull background throb, but every once in a while coming back with a jolt. This is evidently one such time. As developers though, we recognize this recurring argument as the worn motif of old, morphed but yet familiar, and existing as long as our industry has existed: what role should computers play on the theme of our collective human experience?
...yeah, OK—I'll tone down the philosophical flight of fancy.
But you know what I'm saying, at least. This is the industry that coined the hacker ethic, and free software, and open source, and Creative Commons, and "information wants to be free," and the aforementioned semantic web, and shit, we could even take it as far back as Doug Engelbart's notion of augmenting human intelligence with computers. All I'm saying is that developers have been known to entertain thoughts about the nature of the relationship between humans and computers.
So one good thing that's emerged from this fight is a renewed vigor in visiting this topic from the point of view of the web: what do we want out of it? What do we want the web to look like? What's worth preserving, and what's expendable? What new features do we want to see? Who's role is it to bring this all about? And what role will frontend engineers of every persuasion play?
Indeed, some of the people I've already mentioned in tweets have some pretty sharp observations on the future of the web. For example, in his excellent talk about the future of JavaScript, Kyle Simpson talks about whether we should let JavaScript become a mere compilation target (relevant bits at 27:50):
And in one of her great videos about modern CSS, Jen Simmons recommends to stop reaching for frameworks such as Bootstrap and to begin to use raw CSS and all its awesome features (relevant bits at 8:29):
And it couldn’t hurt to also watch this other excellent talk about why the semantic web as originally envisioned failed, and what we can do about it (summary slide thrown at around 1:09:24).
But maybe I digress....
Get to the point, author guy
Yeah, ok. My point is that there are a number of us (whoops, I guess I am choosing sides after all) who think the web should be a batteries-included, accessible platform for everyone, and that we should try hard to maintain its open and semantic nature. Some of us (me) even go so far as to buy into Sir Tim Berners-Lee’s idea that the web should be wholly decetralized and become solid scheming turtles all the way down or whatever. In this newly morphed discussion, let's call this extreme side A.
Then there’s others who think that it doesn’t matter if the web is just a compilation target: that the web only matters insofar as people are using it for real business purposes, and if this is so, then our only concern should be to deliver a good experience to our product’s users, and this hippy-dippy notion of the web as a place where we can hold hands and view readable source be damned. Let’s call this extreme side B.
No doubt, most people will have opinions that fall somewhere along that continuum, rather than at either extreme. To conclude, though:
Chris Coiyer’s “the Great Divide” is meant to be descriptive, not prescriptive, of the state of frontend development.
The conversation of whether UX Engineers should be paid as much as JS Engineers is mired in misunderstanding of what the hell UX Engineers even do and whether the appellation is just a fancy new name for “designers”, a word which in this context seems to carry the weight of substantial misplaced disgust. I would stay away from this.
The conversation among sensible developers centers more around whether it’s OK or not that we’re using so much JS framework magic on the frontend that it’s in fact evolving the industry—less like gradually leveling up a Pokémon, and more akin to forcing a Thunderstone-induced transformation on Pikachu. I think there are good points to be had either way, but everyone involved would probably benefit from being careful not to tread in contempt-culture territory. Not that you need me refereeing your shit, but you know, it's my blog.
Also, no surprises, but Twitter commenters who are not sensible can indeed be so much fodder for a hefty trash compactor.
But fuck’em, because there’s a neat adult conversation to be had about the future of the web in spite of these people, so let’s, you know, get crackin' on that front: let's discuss the role of JS frameworks; let's discuss whether Web Assembly is really going to replace JavaScript, and whether we want it to; let's even discuss all the great new features available on the web... There's a lot to talk about, valid interpretations of our future as web denizens and as developers, and we should definitely sit down and talk it out.
You go first, though.
Top comments (62)
I do have to say that topics like these (while they were excellent and revealing reads) fill me with a ton of anxiety. I'm about to graduate this semester with my BA in Comp Sci and just recently within the last few months got into exploring and learning about web development. It's been the most fun I've had programming in a long time during my university experience and I feel more inspired and passionate than I've ever been before. It felt amazing to finally have some direction and know what kind of career I believe I wanted.
But there's just SO MUCH to web development. Picking up vanilla JavaScript wasn't too bad because I already was taught good, basic programming fundamentals, but there's just SO MANY tools, SO MANY different libraries and frameworks, and SO MANY things about web dev that I didn't even know I didn't know (if that makes sense). Since getting a good handle on I've JS been learning Node, React, and good HTML/CSS fundamentals but I wish I had discovered how much I like web development sooner because I feel like the clocks ticking 'til the time I graduate and I'm filled with a lot of dread that when it comes time to getting interviews I'm going to be revealed as a fraud who doesn't really know anything, because to be honest that's kind of how I feel at the moment.
** Edit: Thanks to everyone who responded for all the encouragement. You've all calmed my anxiety about my future and I'm very grateful.
A lot of what you're seeing is incidental complexity. The fundamentals remain. Learn:
These are the highest value uses of your time. React and other frameworks can be useful, but they are ephemeral and they can't help if you don't know the fundamentals. They're distractions from the real stuff that is going to last.
[1]: Before someone starts chiming in about React or other things obsoleting this, they don't. React's flow is just inversion of control in MVC.
You'll be alright, just keep learning. Being curious is the best tool when it comes to being in the field of web development, and good employers should recognize that. Even after a couple years of doing web dev full time, once a day I learn something new and think to myself, "damn. How did I not know that?" But that's a good feeling if you're curious - keeps things interesting.
Also, one thing I found useful: be peripherally aware of the trends in the various fields of web dev, but pick up a couple tools to use as your primary tools. Otherwise you might find yourself always learning and never building instead of doing both.
Thank you for the kind words of encouragement, Grant. Focusing on a core set of tools and skills has definitely been my mindset thus far. I'm super grateful for all the amazing tutorials and learning materials that are available online for these tools.
This is nothing new. Before the web it was cross process communication, Data protocols and OS API stacks that one would need to explore and had little exposure to prior to graduation. Don't sweat it. You are hired as a junior engineer for a reason.
Yes I'm dating myself, but when I graduated, web devs (all encompassing) were barely a thing and "weren't really engineers". Forgive me, but these battles (not war) are trivial :). Try arguing that people who write code of any kind for the web are actually engineers. Thank those that fought the real war 20 years ago.
P.S. The last part needed a proper shake of the fist and a "Git off my lawn". :)
Are you going to -f those kids of your lawn?
Meh, nothing to be scared about. You are looking at entry-level with a thin portfolio. Employers are familiar with that. Build up that portfolio, gain confidence, and be adaptable.
Thanks for the good summary Uli! I think you left out, in your "class warfare" and "contempt culture" argument this important POV (read the thread):
but good summary nonetheless!
I would never define myself as a frontend developer as of today but I definitely lean towards "side A" than "side B".
As a person that's actively interested in WebAssembly you made think about this from a different side: WebAssembly is definitely closer to "side B" because it would be "opaque" and literally treat the browser just as a compilation target. Food for thought :)
The gender gap might exist in roles being given and salary too, there is no need to discuss about it.
The problem I have with the discussion is that there are always employers, agencies, chiefs, and customers that are greedy and search arguments to reduce the bill (in general that's quite common). Some express it smart with arguments like "there is just not more budget", "you made yourself some work by these faults", "I never requested these features", others express it simple and when the argument about gender is thrown it sounds unfair because you can't do anything about it even with a thousand of certificates and 100 years of experience.
The point is: if somebody is greedy, the argument doesn't really matter much if you can't counter the denial to pay more in general. It might concern women as well as men and if you hear gender as reason then it's an argument but the problem might be different.
Apart from that: if a whole project is wrong calculated by yourself and even the agency too (I had that case in this year and will still suffer from it in next year) then smaller additional payments can reduce the pain a bit but never add the value you'd need for the whole work (like double or triple in comparison to the first offer).
I'm white, I'm male and don't know how to survive next month and sometimes even only the next day. Perhaps I'm also stupid and somehow disabled if you search some explanation for my situation. But I'm probably not the only one with that experience and know that unfairness can show up with many faces and many arguments. And sometimes arguments about gender might be reason to pay less, sometimes these are just arguments.
Yeah, THAT was one of the most educational threads to come out of the whole tweet storm.
Exactly, an angle in the whole discussion I couldn't have foreseen and, I have to admit, I was sadly oblivious about.
If I had to choose a side, I’d be closer to what Chris labels a UX Engineer.
That said, none of this particularly concerns me.
I’ve been doing web dev for 25 years and coding for longer, and one trend has proven true over the years.
Tools & practices that have proven useful to the majority of client-side developers over a sustained period of time eventually get built into the core languages and are supported natively by the browsers. A couple quick examples: Bootstrap Grid -> CSS Grid (which is better than the original), JQuery Element Selectors -> Javascript getElementsByClassName, etc. Also, does anyone remember emulating border-radius by slicing a box into 9 sections for proper scaling?
The javascript engineering community is contributing by building tools that enable us to create great experiences. Will big companies be able to leverage them first? Sure, because resources. Will the useful tools and practices eventually become part of the core functionality for web languages and servers? History says yes. We just gotta let evolution do its work.
Aha, thanks for reminding me the border radius with 9 divs. I teach a Web Design and Development course in a CS department and this was one of my favourite examples ~10 years ago to demonstrate how you can get creative with CSS and unleash its awesomeness. I was pretty disappointed -and possibly the only person in the whole world feeling that way- when
border-radiuswas introduced. Luckily they also invented this CSS animation thing and new CSS3 selectors so I was able to fill the gap in my lectures after saying farewell to manual border radius.I've been working on web applications since Netscape 2 was supported in the mid 90s. I was a fan of JavaScript before the good parts book. I was even a fan of aspx for a while.
Today, there are times I'll push a simple page and plug in something like jQuery and Bootstrap to get something out.
That said, I prefer modern tooling with React and CSS in JS. I also feel it's useful to publish source maps. Hiding source is not security.
In the end I've been in all sides of these arguments. I've been labelled all of the titles discussed and it comes down to the person and roles in the company. I also worked with "UX Engineer" titled people who didn't write code at all.
The arguments all have some merit and are all mostly useless. I write code with an emphasis on discoverable and maintainability in a feature-component hierarchy. That doesn't mean conforming to a given framework or patterns specifically. It means being able to find the piece you are working on and the places where it's connected into a larger application.
I think jsx, redux/graphql and jss are better fits than most other options. If it's mostly content delivery, then a good server platform is often better.
I also tend to reach for JS/node first on the server. No, it is not the best at anything server side. But it is good enough for almost everything with a lot of flexibility and less disconnect to the front end than pretty much everything else.
You had me until you mentioned node :). Call me crazy, but it feels like the only reason node is a thing is because JS devs didn't want to learn a new language :). Sorry, must just be in a 'stir the pot' mood tonight.
Node is definitely not the only thing I use. That said, in Windows Linux and Mac, when UI development is happening, node is there.. that means I can write scripts for tasks and orchestration that will work on all three platforms with minimal issue and without more complicated tooling.
It's more a matter of convenience. There's also bash generally, which I also used a lot, but the implications in Windows are different.
Compiled languages are fine for server only applications and backend servers, but there's less wait for a quick change on a script.
I also have been meaning more heavily on docker lately as well.. again to minimize my own impact across platforms. Docker desktop on Windows and Mac are close enough with a couple gotchas, but generally minimizes the disconnect on differing systems
That's a reason that node became a thing, but taking advantage of the JS event loop was also a (good) reason.
I'll throw in my two cents, from someone who remembers when JavaScript was first available.
UX engineer vs JS engineer: "engineer" has become a term of exaltation or oppression in software because its core meaning is missing. The core of engineering is legal. If a layman stands up in court and says, "The building that I checked that fell over and killed a bunch of people did not do so because of the design that I checked," the burden of proof is entirely on them to prove that proposition. If an engineer stands up in court and says that, the burden of proof is on the opposition to disprove it. Everyone wanting to claim that title needs to think about how it's going to go when the lawsuits start flying and they show up in court.
As for salaries, two things determine salary: scarcity of people with the skills and value produced. If you can make use of the skills of an X to make another $500,000, then you certainly aren't going to pay more than that. On the other hand, if X's are prevalent and there's not enough work to go around, their price is going to go down. From that point of view it is entirely possible for someone with a good grasp of UX and CSS to be bother scarcer and able to provide more value than someone who has a good grasp of React and webpack. The converse is also true.
The other side I see is parochialism. "This is what I build on the web" becomes "This is the web" in people's minds. The web is an enormous commons, so large that it's easy to not see what is outside of your neighborhood.
I think Simpson (getify) is right about lack of empathy being a factor, but I'd say the real root cause is that humans feel a strong need to be perceived as right (and, more primally, powerful). Coupled with the other common human trait of insecurity, we unfortunately go to great lengths to justify our positions and our choices... even when we have an inkling that we could be at least partially wrong.
You can pick pretty much any subject and end up with these debates-that-become-wars. I've seen some disagreements turn into vicious flaming on... wait for it... Guinea pig forums. :-D
I just wish people accepted that there's room for many approaches, and different apps built by different teams have different needs.
It was worth the wait. By it I mean the Guine pig forums. :) Human beings are wonderful creatures for being able to attach meaning to a mostly unmeaningful universe.
People always gonna argue about something.
I'm not web developer/engineer/designer etc... However, your post did pique my interest. Regarding the job title nomenclature and what that entails, I believe if everyone simply accepted that they are all "skilled tradespeople" and have the same goals in mind, then maybe you can move past that. It seems really silly to get caught up in a title like that.
Regarding stacks, that is not isolated to the web (As I'm sure everyone who reads this post are aware of.).
I completely agree. The specific title of “engineer” has been one of the most contested things about my post, and really I only defend it because of the implied “eww, design” attitude that some developers get.
You know what it remind me of? Did you watch that episode of the Office where Dwight was fighting about the difference in prestige between “Assistant Manager” and “Assistant to the Manager”?
lol I hadn't seen that episode. I'll make a note to check that out.
Usability and design in a lot of ways (in my opinion) adhere to the same principals as engineering. Each choice must go through the same rigor as any complex backend system.
Reminds of the "full-stack" thing from years past (That still a thing?).
As a user with accessibility needs I've been getting more and more frustrated at the state of the web because of all of the sites that use Angular or whatever for everything and just completely throw out all of the stuff that made the web useful in the first place. I wrote a rant about that from my perspective over yonder: beesbuzz.biz/blog/7456-Modern-web-...
Good to be informed that the old accessibility-basics are still important. I thought javascript perhaps wouldn't be a big deal anymore and it's good to know that it should be even today avoided for basic functionality of websites!
Holy moly! That’s awful! Thanks for your input; I’m going to redouble my efforts.
Can I just say that I love this article? :D
I'm not going to argue for any sides, I'm just arguing for a healthy discussion and this is a very informative addition to it 👍
Thanks for summarizing what went on and your insights. Your links were pretty helpful too. I especially appreciate your bringing up the Semantic Web angel. I agree that is way more important in the long term for every one of us in the webdev spectrum than these kind of tribal fights.
Just 2-3 years ago there were only a handful people who were advocating for more ethical machine learning practices and pointing out the problems. Nowadays how to fight inherent bias in ML algorithms, how to make their inferences more interpretable are active research areas and industry also took notice. I brought this example to find encouragement for discussing things you mentioned even if they are not the hottest topics currently. Eventually more sensible people will join the discussion and we'll find new ways. We always did in the dev world when it really matters and enough people became convinced that it matters. So I am optimistic.
For whom who wants the "right" way to do CSS thing:
Why ?
webpackthing neither.CSS is the bad guy here. It made the dev tooling more complicated than it should be.
The correct way in future is : Just put everything in JS !
Ha, no; sorry. Who wants to open and step through a debugger to figure out why the BG color on a button is incorrect. Nobody, ever. They are separated for a reason. JS frameworks made the tooling a nightmare fwiw. Tooling didn't really exist before npm and JS frameworks.
Interestingly, desktop toolkits started out this way and consistently went the opposite direction, creating theming languages and other equivalents of CSS to remove the visual layout from the code.
So based on the history of the field, CSS-in-JS will be a fad for a couple of years, and then fade into history for the same reasons that visual styling was factored out on the desktop.
Some related observations/thoughts I don't know where else to put:
The Misunderstanding
React/Angular/...-Dev: "CSS in JS!"
"Classic"-static-page-Dev: "No! How would we.. It makes no sense!"
React/Angular/...-Dev: "Yes, it's so much better! Just shove it in your components"
"Classic"-static-page-Dev: "In my what? But Cascade!"
(spoiler-alert: both are right)
The Twitter/HN-Bubble
I would take popular tech-twitter with a truckload of salt.
Lots of them are marketing-folks (advocates, evangelists) so they are biased towards whatever their company does.
Lots of them are really smart, but in the end are only human, and can be victims to fallacies like all of us.
Most front-end-devs I talk to outside conferences never even heard about any of the folks mentioned in the article.
Not to mention the differences between Silicon-Valley and the rest of the world.
The web-dev-spectrum
My hypothesis: Everybody has their line where it becomes uncomfortable for them, on both sides, if you assume a web-dev-spectrum like (sorry for the simplification):
Concept/IA <-> Graphic Design <-> HTML/CSS <-> Style-JS (Anims, jQuery) <-> Techie-JS (TS, Ng, React) <-> THE API <-> Server-Side Dev. / Ops / OS/Systems-Dev
Even though I'm interested in all of those fields, my "home" is from HTML to Techie-JS.
I assume it's a bit different for everybody, especially as this spectrum gets finer grained, the bigger the company/team/project gets. But I also would say, that i.e. Systems-Devs with typography-skills are the exception to the rule.
CSS is hard
Most "CSS is hard"-rants which got my attention come from the tech-side of the spectrum. Are most issues with CSS really deficits in design-skill? Would they have the same issues with Sketch or Photoshop?
What makes them think CSS is easy? Do some years of full-time CSS and it won't be that hard anymore.
I agree with everything you mention!
And in general, I like your use of headings to separate points, lol. Sorry, I enjoy formatting :D
I understand that in Canada and European countries you need a engineering certification to have the title. In that regard, I understand it. If a software engineer is writing software that monitors your heart rate, you want assurances that it will work and if something should go wrong, you can hold the organization or person accountable who created it. That's how it works here (US) for other engineering disciplines.
However, in the US this isn't the case. The term "software engineer" is thrown around a lot and it's in a way commingled with "developer" or "programmer". In some cases we say the word as to not offend the individual. Again reiterating that other engineering disciplines are required to be certified. Just not the software variety.
In light of all that, by me expressing that design follows the same kind of "rigor" as engineering does not mean that i'm taking a side in that regard (Seriously, I don't care. Call yourself whatever you want.). I was merely speaking to the kind of philosophies good UX/UI professionals do (In my experiences.). They are held accountable for the products that they produce at least on a organizational and product level.
Hope that explains my initial posts.
Aren't discussions like these about who is "better" or deserves to be paid more or whatever just total nonsense? Building better teams, that's what really matters.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.