JSS VS oocss

Most websites those days are SPA applications that render on the front-side. There is also this trend of CSS in JavaScript also knowns as JSS that is debatable (makes everything overcomplicated), but in some specific cases, can be justified and very useful.

> why tf aren't we using JS for styling already

People are and have been for quite a while

https://cssinjs.org/

JSS

It is possible. At its most simple, you could just modify the style property on every element. That's not generally considered best practice, but there are a number of "CSS-in-JS" libraries which streamline the process. The typically generate dynamic CSS classes and apply them to your elements. A big one is JSS.

import React, { useState, useEffect } from "react"; import Amplify, { API, graphqlOperation } from "aws-amplify"; import { createBlog } from "./graphql/mutations"; import { listBlogs } from "./graphql/queries"; import awsExports from "./aws-exports"; import { ListBlogsQuery } from "./API"; Amplify.configure(awsExports); const initialState = { name: "", body: "" }; const App = () => { const [formState, setFormState] = useState(initialState); const [blogs, setBlogs] = useState(); useEffect(() => { fetchBlogs() }, []); const handleInputChange = (event: React.ChangeEvent) => { setFormState({ ...formState, [event.target.name]: event.target.value }); }; const fetchBlogs = async () => { try { const blogData = (await API.graphql(graphqlOperation(listBlogs))) as { data: ListBlogsQuery } setBlogs(blogData.data); } catch (err) { console.log("Error fetching blogs" + err); } }; const addBlog = async () => { try { if (!formState.name || !formState.body) return; const blog = { ...formState }; if (blogs) { await API.graphql(graphqlOperation(createBlog, { input: blog })); await fetchBlogs(); setFormState(initialState); } } catch (err) { console.log("error creating blog: ", err); } }; return (

Amplify Todos

Create Blog {blogs && blogs?.listBlogs?.items?.map((blog, index) => { return (

{blog?.name}

{blog?.body}

); })}

); }; const styles = { container: { width: 400, margin: "0 auto", display: "flex", //real weird issue: https://github.com/cssinjs/jss/issues/1344 flexDirection: "column" as "column", justifyContent: "center", padding: 20, }, todo: { marginBottom: 15 }, input: { border: "none", backgroundColor: "#ddd", marginBottom: 10, padding: 8, fontSize: 18, }, todoName: { fontSize: 20, fontWeight: "bold" }, todoDescription: { marginBottom: 0 }, button: { backgroundColor: "black", color: "white", outline: "none", fontSize: 18, padding: "12px 0px", }, }; export default App;

Material UI v5 brought some amazing updates, but switching from JSS to Emotion had an arguably nasty side-effect: it was no longer as straightforward to group your component styles in classes. Fortunately, a fantastic library emerged that allowed developers to not only reduce the extreme pain from migrating all their classes from v4's makeStyles to emotion, but to also to continue to writing classes in practically the same syntax, with wonderful TS type-safety. This library was tss-react, and it was one of my favorite open source discoveries of 2021.

I started writing a long response, but I want to add that a simple CRA + JSS + TS (named exports only) stack solves or abstracts away most of these issues.

JSS

Perhaps the most important CSS methodology to emerge during the web’s transition towards application-like websites was Object Oriented CSS (OOCSS), devised by Nicole Sullivan in 2009. Nicole’s now legendary article, ‘The Media Object Saves Hundreds of Lines of Code’, represented a fundamental rethinking on the composition of CSS rulesets and their relationship to HTML content. Instead of writing CSS styles around specific HTML content or basing styles on the location of content within the DOM, OOCSS prioritized writing reusable styling rules based on design patterns (in the case of the media object: ‘a fixed size media element (e.g. image or video) along with other variable size content (e.g. text)’). As perhaps the first instance of a CSS methodology systematically informed by a visual pattern language, OOCSS was also a critical step towards a more modular, reusable approach to writing CSS.

Component based CSS frameworks originating with OOCSS inherently limits selector scope to only elements inside the 'CSS object'.

OOCSS

OOCSS - Object Oriented CSS

OOCSS - (Object-oriented CSS) 2. Use a preprocessor. They fill the lacking features of CSS and helps you write more readable, and smaller reusable pieces of CSS. Some popular preprocessors are: 1. Sass 2. Less 3. Stylus 3. Reduce redundancy. You are using font-weight: bold for the header, but you are also setting it for the div inside. CSS stands for Cascading Style Sheets because styles in CSS are cascading, meaning child elements will inherit styles from parents. 4. Avoid using strong and complex selectors. You are using an id, but a class would do just fine. Having strong selectors means you will have a harder time overriding them later on if needed. 5. Avoid using !important as much as possible. Only use it for utility and helper classes if you must, which need to override anything, such as hiding or displaying an element. 6. Don't use inline CSS, unless your inlining critical CSS. Instead, import styles using a link tag in your head element. (Critical CSS refers to above-the-fold content. Inlining it can help users see a properly rendered page more quicker) 7. Use semantic HTML. You are assigning a header class to a div, which could have been an h1/2/3/n element. This not only helps in terms of accessibility but can also help to improve your SEO score. 8. Use rem for typography. You are using em which cascades, meaning if you set the root element to have 12px, a main element with 2em will have the font size of 24px. If you put a div inside of it with 2em, it will have a font size of 48px, meaning that the size is duplicated. This makes it hard to track down values for deeply nested elements. Instead, use rem which stands for root em, and does not cascade. 9. Make sure your formatting is consistent. You use opening brackets both after a selector and on a new line. Tools like stylelint can help you enforce certain rules to keep your code more consistent, which helps to improve readability and maintainability. 10. Outsource your colors / sizes / spacings into variables. Everything that is bound to change can be in a configuration file to make things more flexible. You can either use CSS variables for this, or a preprocessor. 11. Nothing is written in stone, feel free to come up with your own set of rules that helps you create a more dev-friendly environment. But most importantly, keep things consistent.

✨ BEM 💥 Object Oriented CSS 🌟 Atomic CSS