How did we end up with CSS-in-JS and why some developers don't like CSS

George Katsanos — Wed, 12 Jun 2019 09:37:59 +0000

I recently read Why Most Developers Fear CSS and I decided to take the time and present some thoughts that I've accumulated during the past 4-5 years or so.

Most of the "Whys" people use to base their frustration with CSS are:

Browser incompatibilities

Claim
Browsers, mainly IE, were not aligned in the implementation of the CSS spec.

Reality
It still occasionally happens, but if you haven't done CSS in the years before 2014/2015 then you've seen nothing when it comes to hacks and tricks and bugs we had to solve to make things look descent. Have you done rounded corners using png's, 4 extra HTML elements and absolute positioning? No? Then you have no right to complain. Try to vertically align in the pre-flexbox era. The situation has dramatically improved, and with IE Edge adopting Webkit this question is closed for good.

Scope/Cascading/Inheritance

Claim
I changed this rule here and it broke something over there.

Solution

Functional CSS ( https://tailwindcss.com/ or https://tachyons.io/ )
Component based architecture with one (only one) parent selector that creates a scope for you

The real reasons some coders have issues with CSS are in my opinion a bit more complicated.

Ex-backend devs (PHP,Java,.NET) switched to Frontend because of the JS hype which started around 6 years ago. (slowly with Backbone, followed by Angular and shortly after with React)

These engineers were on average more proficient with handling logic/programming/algorithms, more-so than someone who was mainly doing HTML/CSS/jQuery throughout his career. They picked React as it is still the most popular JS framework out there.

But, they never got the time, will and hands on experience to learn CSS.

They regarded CSS as 'inferior', a necessary evil, 'it's not real programming' (maybe true, still doesn't mean it's easy to do) they just dive in, change a couple of lines here, a couple of lines there and pray it works. Spray and pray for CSS.

I've seen excellent programmers write the ugliest CSS I've seen in my life. Unneeded repetition, deeply nested selectors, magic numbers, little to no architecture etc.

A general low barrier of entry

CSS being a descriptive language, a set of rules and what not, feels easy. Anyone can do it. People jump in expecting to understand everything without any learning.

"This thing can't go exactly where I want it to go"? -> "position: absolute;"
"This rule isn't powerful enough"? -> "!important"

and so on and so forth.

Frameworks

CSS Frameworks even though they're super helpful tools, can't replace real hands on experience with Vanilla CSS. You may whip some Bootstrap modules together with a bit of a luck, but you won't go far. The moment you hit the first bump in implementation, you'll be like "oh this is so complicated, it's the language's fault".
UI Frameworks for React have similar results. You can make a webapp with Material UI for React easy peasy. But when you need to go custom?

Conclusion

The hate and confusion towards CSS and the possibility to do all web without really doing CSS led to patterns like CSS-in-JS and tools like Webflow. Most of the technical arguments against CSS-in-JS have already been debuckled by Chris Ferdinandi here.

Generalist vs Specialist Developers: Theory and practice

George Katsanos — Mon, 15 Oct 2018 21:06:52 +0000

Like every other Senior developer out there, I am quite often approached by companies looking for Web Developers to join their teams. When the message and project look interesting, I sometimes engage in a first general discussion either by phone or if the company is located physically close, in person.

There were always vague or badly written job descriptions in our field; Back where I come from, Greece, traditional software companies were notorious for looking developer profiles who could do everything from Databases to backend, frontend, system administration, and in very "exotic" language combinations (PHP, Java, .NET - in one profile). Companies were trying to save money by hiring one person, a generalist, to do everything. That naturally led to chaos and produced throwaway code no one was able to maintain or support (especially when the one man army developer would decide to move to a new project)

During the past months, and partially because of the prevalence of JavaScript in both ends of the development spectrum, I've noticed a growing popularity for "Full Stack" profiles. I had discussions with companies looking for a "Frontend Developer" who is:

an expert (!) in iOS (Objective-C, Swift) and Android (Java) development and has years of experience in Native (!) application development
familiar with Python Ruby or Go
naturally an expert in frontend Frameworks

Where I come from, that's definitely not a "Frontend Developer".

I've observed developers around my network with very solid mathematical problem-solving skills, who come from a pure backend background and have jumped in the JavaScript train. They can code Node.JS based applications and APIs with ease but even if they claim they're "full stack", they really neglect a lot of the skills and tools needed to master the Frontend part of the job.

To me, a (Senior) Frontend Developer sits somewhere between Product, UI, UX and backend, and by collecting feedback orchestrates the final product result. He is someone who's familiar with things like device and browser quirks, accessibility, SEO, and who ultimately has an eye for design, or possible UX issues all this while keeping it with the very fast paced frontend ecosystem and its' tools and libraries - which is a full time job on its own.

Do you think Frontend Development is moving to a phase that implementation of web interfaces for the browser is going to be only secondary to things like Node.JS, mastery of docker and microservices, and mobile development?

What is your opinion on profiles that claim they can do everything, and would you work for a company that expects you to do everything?

DEV Community: George Katsanos