Rather than dismissively calling it “brain poison”, can you describe any specific problems with Mojo’s use of JavaScript? As toastal’s reply shows, if the user disables JavaScript by default, it causes styles to break – that certainly can be a problem for some use cases. Were there other problems you were you thinking of?
Also, since I don’t see how Mojo alone “[shoves] literally everything into a single javascript file”, what do you see as the ingredients that form that trend? Apart from JavaScript-powered CSS frameworks like Mojo, all I can think of is JSX.
If you are trying to prescribe something new for front-end web but your demo is riddled with questionable pracitices, there’s irony folks can’t help but point out. …Like pitching a new restaurant with a the musk of rotten food as you open the door, why trust this establishment?
Mojo follows the Atomic CSS approach, which means that it focuses on providing a set of low-level CSS utilities that can be used to build custom user interfaces.
My understanding is that their CSS framework is a middleware between low-level CSS (native? actual?) and high-abstraction frameworks (tailwind? bootstrap?).
I’m not sold on the value-added of something like what they are proposing over just writing CSS directly.
Mojo is one of many atomic (a.k.a. utility-first) CSS frameworks. It didn’t invent the concept. According to Let’s Define Exactly What Atomic CSS is, the term “Atomic CSS” was coined in 2013. Mojo was released a month ago.
How is atomic/utility-first CSS different from inline styles?
Next, you might wonder why would anyone would use utility-first CSS over semantic CSS. The Case for Atomic / Utility-First CSS links to some arguments. (I don’t claim that utility-first CSS is always better – I think it has upsides and downsides. And of course, any specific implementation of utility-first CSS such as Mojo also has pros and cons.)
There is no way to write that hover style as an inline style. As my comment’s second link said, “Inline styles can’t target states like hover or focus”.
Mojo class names such as px-5 can be much shorter than equivalent CSS rules such as padding-left: 5; padding-right: 5;.
Being able to set padding-left and padding-right to the same number makes consistency easier to achieve.
I haven’t found explicit reasons on Mojo’s website for the use of abbreviations in simpler classes such as pl-* (padding-left), but the arguments I’ve heard from Tailwind users are that you can not only type the rule faster, you can see more such rules on the screen at a time, requiring less horizontal or vertical scrolling when navigating. Some Tailwind users claim that after you learn the abbreviations they aren’t slower than regular CSS.
SPAs have really brain poisoned everyone into thinking “it’s fine to shove literally everything into a single javascript file”
This static landing page is completely blank with JavaScript in allowlist mode too since it’s built on a SPA I would assume.
it actually has server-rendered content. But also a
display:noneon the<body>tag…Oh no… why?. Looks like the styles don’t even work without JS so this is why?
Rather than dismissively calling it “brain poison”, can you describe any specific problems with Mojo’s use of JavaScript? As toastal’s reply shows, if the user disables JavaScript by default, it causes styles to break – that certainly can be a problem for some use cases. Were there other problems you were you thinking of?
Also, since I don’t see how Mojo alone “[shoves] literally everything into a single javascript file”, what do you see as the ingredients that form that trend? Apart from JavaScript-powered CSS frameworks like Mojo, all I can think of is JSX.
100% agreed with this one. Web teams are easily blocked when everything is controlled by the JS developer.
My favorite part of this landing page is the bit where they explain why “without shipping CSS” is advantageous
This seems like a great idea if you specifically want to tank your SEO ranking.
why are comments on this website so snarky
If you are trying to prescribe something new for front-end web but your demo is riddled with questionable pracitices, there’s irony folks can’t help but point out. …Like pitching a new restaurant with a the musk of rotten food as you open the door, why trust this establishment?
indeed, pretty disappointing. starts to look like HN :/
That’s because we live in snarky times.
Is this a satire? Wasn’t OP bashing on Tailwind recently? I’m confused, sorry.
The story submitter tipiirai did bash on Tailwind recently, but according to the link in the bottom right corner of https://mojocss.com/, tipiirai is not one of the two authors of Mojo CSS.
The frontpage renders extremely slowly in firefox on my laptop. Mousover effects take around a second to render.
So…they’ve reinvented inline css?
Absolutely not:
padding:12px_6pxis “atomic”. Not to confuse with inline CSS:
padding: 12px 6pxThere is too much whitespace in inline CSS, just unreadable.
What does atomic mean in this context, and how is the inline css not atomic?
This is what they have on their help file:
Maybe they are inspired by this?
My understanding is that their CSS framework is a middleware between low-level CSS (native? actual?) and high-abstraction frameworks (tailwind? bootstrap?).
I’m not sold on the value-added of something like what they are proposing over just writing CSS directly.
They also reinvented CSS classes, but they call them patterns. https://mojocss.com/docs/guide/component-abstraction#using-patterns
Mojo is one of many atomic (a.k.a. utility-first) CSS frameworks. It didn’t invent the concept. According to Let’s Define Exactly What Atomic CSS is, the term “Atomic CSS” was coined in 2013. Mojo was released a month ago.
How is atomic/utility-first CSS different from inline styles?
Next, you might wonder why would anyone would use utility-first CSS over semantic CSS. The Case for Atomic / Utility-First CSS links to some arguments. (I don’t claim that utility-first CSS is always better – I think it has upsides and downsides. And of course, any specific implementation of utility-first CSS such as Mojo also has pros and cons.)
Ok but in this case the name of the class is the css to be generated.
Not really. This Mojo CSS example (source) demonstrates two things Mojo does that inline styles can’t:
hoverstyle as an inline style. As my comment’s second link said, “Inline styles can’t target states like hover or focus”.px-5can be much shorter than equivalent CSS rules such aspadding-left: 5; padding-right: 5;.padding-leftandpadding-rightto the same number makes consistency easier to achieve.pl-*(padding-left), but the arguments I’ve heard from Tailwind users are that you can not only type the rule faster, you can see more such rules on the screen at a time, requiring less horizontal or vertical scrolling when navigating. Some Tailwind users claim that after you learn the abbreviations they aren’t slower than regular CSS.