How many times do we have to be told they're not reinventing the wheel while reinventing the wheel! This is not better than just writing CSS.
'Proxy' DSLs are not a solution to anything other than "how to do I make sure the next person taking on this codebase will want to delete all my shit and start again clean and coherent"
If you're at the point where you're getting people to write the style attribute in your own DSL so you can claim some marginal utility gains then you're missing the point of what makes CSS difficult for coders to deal with: how do you describe visual complexity in code. How does x-style="e:2;" solve a problem that the 'contract' between designer and developer has?
Assembler CSS doesn't look very good and I wouldn't use it ... but I have come to absolutely love utility CSS through Tailwind. Tailwind's documentation does a good job explaining why:
https://tailwindcss.com/docs/utility-first
It's really not very similar to writing inline styles, nor is it about saving keystrokes. It's about very quickly and confidently translating a design in your mocks (or your head) into working CSS which draws from a finite design system that you control.
It't not something I'd use on mywebsite.com/about.html but it pairs really nicely with modern JS frameworks which allow you to create custom elements with scoped styles.
They reinvent inline styles, then they reinvent classes! It's kind of impressive.
I read through the docs, trying to find a value proposition to this over CSS. So far, the benefits claimed amount to "knowing how to use development tools is scary", "you can abbreviate properties into incomprehensibility", "here are some new values and defaults to keep straight".
In terms of what you can't do with plain old inline CSS? Apparently, just some parlor tricks like styling sub-elements (with a cumbersome syntax) and some concise transitions.
My first impression is it's kind of like a transpiler or Babel for CSS. I agree with your sentiment and I wouldn't use it, but let others have their fun I guess.
<body>
<!-- Your code here -->
<div x-style="max-w:80; mx:auto; radius:md; e:2; e.hover:4; transition:all 0.25s; cursor:pointer">
<img x-style="block; max-w:100%; w:100%; h:auto; radius-top:md" src="...">
<div x-style="p:4">
<div x-style="text:lg; color:black; font-weight:700">Fresh veggies</div>
<div x-style="text:sm; color:silver; font-weight:400">600g</div>
<p x-style="pt:4">
Any veggie can belong on your menu, so choose what you love and use the rest
for future meals and snacks you can enjoy in flavorful ways.
</p>
</div>
</div>
</body>
Reading the docs, the talk of "other CSS frameworks" seems to be primarily aimed at Tailwind; but fails to discuss the trade-offs.
The key design difference seems to be to use a runtime script and data/x attributes to allow customisation and perform style pruning, rather than using config files and build scripts. There are clear downsides to this (as well as upsides, such as faster ramp-up time), but they're not really being presented honestly.
From my perspective, it's hard to imagine someone adopting this as core tech for _websites_, because requiring a blocking script before any styles can load is an absolute deal-breaker for me. But perhaps people will find some utility from it for prototypes, and in environments (perhaps electron apps) which are less sensitive to blocking scripts.
> We've decided to develop Assembler CSS as a reaction to the current state of the ecosystem, not just as a solution to our company's needs.
I cannot comment on the company’s internal needs but, to be honest, I would consider the need to reinvent the wheel with custom attributes for styling to be one of the problems with today’s JavaScript ecosystem. And having a styling framework that only works with JavaScript turned on seems like a bad idea, even for single page applications.
I thought it was a parody but now I'm not so sure. If that sounds harsh it's because I'm struggling to understand the value proposition or what problem it solves exactly.
Am I right in that it requires runtime js to parse it's special style tags in order for any css to work?
This gets more and more baffling. Everyday another totally useless framework gets released – and they never tell you what usecase this shit has. Seriously, what problem is solved by this?
What is wrong by just writing VanillaCSS? This is becoming ridiculous.
Having used a couple of these frameworks (emotion and tailwind mostly), I can attest that there are significant issues with vanilla css at scale. I wouldn't dream of going back. That being said, I agree, the volume and wheel reinvention is getting ridiculous.
You want me to include a Javascript file to style my website and you use the non standard `x-style` attribute. I think i will pass and write vanilla CSS or something that compiles down to it.
I'm not sure why utility frameworks are so popular. It seems like Sass solves most of the problems of vanilla CSS. Writing Sass is not only quicker and more powerful than regular CSS, but you can also create your own utility classes very easily with loops.
Moving CSS into HTML does not makes much sense either, as it's far stylistically cleaner to separate CSS and HTML into their respective files.
Plus, if you have two elements with the same or similar styling, re-writing all those utility classes over and over seems extremely cumbersome. Why not just write the class name and use it everywhere it needs to be used? .button or .button-primary is far simpler than writing out inline CSS over and over again.
> Plus, if you have two elements with the same or similar styling, re-writing all those utility classes over and over seems extremely cumbersome
Tailwind doesn't really work that well on static websites, or apps that have markup that you have to repeat all over. It is supposed to be used with components.
If you have a button, it should be its own component, rather than something that you have to copy-paste around.
Of course, you can use @apply to merge Tailwind classes into CSS Components, but it kinda negates the benefits of functional CSS.
-
> Moving CSS into HTML does not makes much sense either, as it's far stylistically cleaner to separate CSS and HTML into their respective files.
The "separation of concerns" idea is still here, but the idea is that HTML+JS is the "presentation", while the "content" comes in the form of JSON (or any kind of object, if you're using it in the backend).
Without this conceptual shift, it really doesn't make sense to use Tailwind.
I think that is spaghetti code. I can do that with my own library and much cleaner functional approach, and much reduced code https://github.com/meerita/utilcss
This is ridiculous. I personally want a higher level of abstraction and not worry about different border radius styles. I want components with minimal syntax like bootstrap or w3css.
The example on that site of the gradient button with "Preview" text is broken. The text isn't centered because the container is set to display: flex but no flex-grow set to expand the content box to fill the parent. It has text-center set, but because the box is collapsing that's not working as expected. Really, it needs Tailwind's justify-items-center applied to it.
I'd worry about using a framework whose primary example is wrong.
Maybe I'm just too traditional here, but I simply don't see the real advantages of any of the CSS-in-JS solutions. I like CSS modules, but anything fancier seems to add more problems than it helps to me.
This one seems even more extreme than many others and looks pretty much like writing inline CSS for everything.
[+] [-] weego|4 years ago|reply
'Proxy' DSLs are not a solution to anything other than "how to do I make sure the next person taking on this codebase will want to delete all my shit and start again clean and coherent"
If you're at the point where you're getting people to write the style attribute in your own DSL so you can claim some marginal utility gains then you're missing the point of what makes CSS difficult for coders to deal with: how do you describe visual complexity in code. How does x-style="e:2;" solve a problem that the 'contract' between designer and developer has?
[+] [-] habosa|4 years ago|reply
It's really not very similar to writing inline styles, nor is it about saving keystrokes. It's about very quickly and confidently translating a design in your mocks (or your head) into working CSS which draws from a finite design system that you control.
It't not something I'd use on mywebsite.com/about.html but it pairs really nicely with modern JS frameworks which allow you to create custom elements with scoped styles.
[+] [-] Semiapies|4 years ago|reply
I read through the docs, trying to find a value proposition to this over CSS. So far, the benefits claimed amount to "knowing how to use development tools is scary", "you can abbreviate properties into incomprehensibility", "here are some new values and defaults to keep straight".
In terms of what you can't do with plain old inline CSS? Apparently, just some parlor tricks like styling sub-elements (with a cumbersome syntax) and some concise transitions.
[+] [-] mkotowski|4 years ago|reply
``` […] id: !ID language: !LANG *target: !ID
! Create a default margin of 3 em ! HTML.leftindent: 3.0 HTML.justify: full […] ```
[0]: https://www.wiumlie.no/2006/phd/archive/odur.let.rug.nl/~ber...
[+] [-] harrygeez|4 years ago|reply
[+] [-] dmitriid|4 years ago|reply
But Assembler CSS looks like an overly elaborate joke
[+] [-] peterkelly|4 years ago|reply
[+] [-] EMM_386|4 years ago|reply
I sincerely hope you are right.
[+] [-] garblegarble|4 years ago|reply
[+] [-] andrewingram|4 years ago|reply
The key design difference seems to be to use a runtime script and data/x attributes to allow customisation and perform style pruning, rather than using config files and build scripts. There are clear downsides to this (as well as upsides, such as faster ramp-up time), but they're not really being presented honestly.
From my perspective, it's hard to imagine someone adopting this as core tech for _websites_, because requiring a blocking script before any styles can load is an absolute deal-breaker for me. But perhaps people will find some utility from it for prototypes, and in environments (perhaps electron apps) which are less sensitive to blocking scripts.
[+] [-] f311a|4 years ago|reply
[+] [-] mkotowski|4 years ago|reply
> We've decided to develop Assembler CSS as a reaction to the current state of the ecosystem, not just as a solution to our company's needs.
I cannot comment on the company’s internal needs but, to be honest, I would consider the need to reinvent the wheel with custom attributes for styling to be one of the problems with today’s JavaScript ecosystem. And having a styling framework that only works with JavaScript turned on seems like a bad idea, even for single page applications.
[+] [-] have_faith|4 years ago|reply
Am I right in that it requires runtime js to parse it's special style tags in order for any css to work?
[+] [-] runxel|4 years ago|reply
What is wrong by just writing VanillaCSS? This is becoming ridiculous.
[+] [-] tenaciousDaniel|4 years ago|reply
[+] [-] vexatus|4 years ago|reply
[+] [-] tmpfs|4 years ago|reply
[+] [-] orangegreen|4 years ago|reply
Moving CSS into HTML does not makes much sense either, as it's far stylistically cleaner to separate CSS and HTML into their respective files.
Plus, if you have two elements with the same or similar styling, re-writing all those utility classes over and over seems extremely cumbersome. Why not just write the class name and use it everywhere it needs to be used? .button or .button-primary is far simpler than writing out inline CSS over and over again.
[+] [-] ratww|4 years ago|reply
Tailwind doesn't really work that well on static websites, or apps that have markup that you have to repeat all over. It is supposed to be used with components.
If you have a button, it should be its own component, rather than something that you have to copy-paste around.
Of course, you can use @apply to merge Tailwind classes into CSS Components, but it kinda negates the benefits of functional CSS.
-
> Moving CSS into HTML does not makes much sense either, as it's far stylistically cleaner to separate CSS and HTML into their respective files.
The "separation of concerns" idea is still here, but the idea is that HTML+JS is the "presentation", while the "content" comes in the form of JSON (or any kind of object, if you're using it in the backend).
Without this conceptual shift, it really doesn't make sense to use Tailwind.
[+] [-] i_am_proteus|4 years ago|reply
10/10.
[+] [-] btbuildem|4 years ago|reply
[+] [-] sodimel|4 years ago|reply
Bonus: MDN about inline css:
> Tip: An inline style loses many of the advantages of a style sheet (by mixing content with presentation). Use this method sparingly.
[+] [-] nsonha|4 years ago|reply
[+] [-] meerita|4 years ago|reply
> <h1 x-style="mt:0; mb:8px; font-size:2.5rem; md|font-size:3.5rem; line-height:1.25; color:white;" style="--asm-margin-top:calc(0 * var(--unit-size)); --asm-margin-bottom:8px; --asm-font-size:2.5rem; --asm-md--font-size:3.5rem; --asm-line-height:1.25; --asm-color:white;" class="asm#c871 asm#c23e asm#822f asm#825d asm#b9fa asm#6330">Just-in-time CSS, unlimited possibilities</h1>
I think that is spaghetti code. I can do that with my own library and much cleaner functional approach, and much reduced code https://github.com/meerita/utilcss
[+] [-] hit8run|4 years ago|reply
[+] [-] yewenjie|4 years ago|reply
https://windicss.org/
[+] [-] onion2k|4 years ago|reply
I'd worry about using a framework whose primary example is wrong.
[+] [-] toastercat|4 years ago|reply
[+] [-] fabian2k|4 years ago|reply
This one seems even more extreme than many others and looks pretty much like writing inline CSS for everything.
[+] [-] danesparza|4 years ago|reply
[+] [-] leodriesch|4 years ago|reply
[+] [-] lampe3|4 years ago|reply
< insert the office gif here > No! God! Please! No!
-------
Even worse this runs on the client and is transformed from js back to css.
How is this even helpful? Why not use inline style directly then? What do I miss?
[+] [-] cosmotic|4 years ago|reply