I can't find on Bun's site that they use WebKit engine. I see:
At its core is the Bun runtime, a fast JavaScript runtime designed as a drop-in replacement for Node.js. It's written in Zig and powered by JavaScriptCore under the hood, dramatically reducing startup times and memory usage.
My personal opinion is that Bun is trying to build too many things around it, like TypeScript. Which effectively leads to so many distractions instead of focusing on core, stability, and performance. It will be a huge ballon that will eat memory with probably 70% of features not used. There will be quantity over quality. At the moment of writing this comment, there are 1590 open issues and 1703 closed.
At this rate of bug growth, Bun will spend more and more time fighting bugs rather than stability and performance. Let's assume that it takes 4 hours to fix each bug (extremely optimistic), that's already 6360 hours spent just on fixing bugs. Let's keep counting, 8 hours a day, that's 795 days! 795 / 365 gives you over 2 years of work just to fix 1590 bugs!
And it will keep growing, as implementing too many features is just a consequence of that.
To the whole great post, I'd also add the overhyped Tailwind, which literally does nothing new and makes the whole development even worse. See example:
Tailwind complicated development 10 times by moving from logical to illogical order. What's wrong with reusable classes? What's wrong with named CSS classes? Instead of first looking at named classes to understand what follows, the engineer now needs to spend time decrypting the intention of the implementation behind all CSS classes. It should be the opposite: Read the name of the class. Interested? Dive into implementation details. Not interested? Keep searching. That approach allows you to quickly scan the app logic without diving into implementation.
You can always compose your own additional css class from tailwind css utility classes. What’s wrong with that approach which can be applied to such cases with classes that are too long/unreadable?
@andrzej_kowal
Composing your own CSS class was available long before Tailwind was born. My primary question is: what kind of problems does Tailwind resolve that weren't resolved before?
By making styling more visible and flexible, and limiting cognitive load. When working with a massive component-based SaaS codebase and an immature, unstable design system, I want to see styles in the DOM template of the component where they’re being applied without having to reference several different CSS files written by different authors at different times all applying globally what they thought could be taken for granted finding myself in CSS cascade hell trying to implement something new without breaking existing legacy UIs or take on the complexity of the entire system.
Pure CSS is beautiful and I can’t wait to ditch Tailwind… later, when the design system is mature and my UI is all nice, clean components, and what a joy it will be (and so easy too) to replace all of those tailwind classes with clean, structured CSS. But honestly, if I never get there, Tailwind will be just fine.
@stephenhebert Tailwind does not resolve the problem you described. Frameworks like Angular, Vue, and React do. You can encapsulate your styles within components. Even Web Components can be used today. Even using only Sass you still can structure code well.
By making hundred different small classes used within one element, it is extremely difficult to understand the semantic and expected behavior. The code should present the logic first. Implementation is important only when you want to dive into code changes, behaviour, or the like.
Check this article from creator of TailwindCSS. link.
I’ve written a few thousand words on why traditional “semantic class names” are the reason CSS is hard to maintain, but the truth is you’re never going to believe me until you actually try it. If you can suppress the urge to retch long enough to give it a chance, I really think you’ll wonder how you ever worked with CSS any other way.
Adam Wathan, Creator of Tailwind CSS
If you guys would like to know what TailwindCSS actually do and why, it might be a good idea to get on their official website and read by yourself.
I think you looked at this syntax "bg-white dark:bg-darkNight dark:border-matteGray border-b border-grayLighter w-full flex justify-between px-2 py-3 items-center xl:hidden fixed top-0 z-20" and become a hater just because it looks ugly.
But you forgot the benefit from it:
All of these configs are very clear, when you get the hang of it you can imagine or figure out how the element looks like exactly at the same time writing html code. No need to check the class name, looking for which css file contains that class then traverse all the css attributes for that class.
And more important thing, IMHO, the visual and preciseness of those tw classes, it's defined right on that element and belongs to that element only. When working with css class, I easily fall in the trap of nested classes, it works right on this page but on the other page, someone make some hacks to modify it a little bit. Everything will end up as a mess and very difficult to find out the reason.
@ginkcode "All of these configs are very clear, when you get the hang of it you can imagine or figure out how the element looks like exactly at the same time writing html code. "
That's the most unneeded "feature." You should not read the code to determine the meaning and expected action of a particular element. Those small classes are related to one (in general) case, and later, with the combination of all of them, they create a single element with its behavior. I don't see any advantages to having 20–30+ micro CSS classes and forcing the software engineer to read and analyse the code to find out what it is and how it behaves.
"And more important thing, IMHO, the visual and preciseness of those tw classes, it's defined right on that element and belongs to that element only."
No, they are shared classes. Anything you change in one class affects all places where it is used. Single classes, like margin or font weight, used alone might be applied to some specific cases, e.g., components used only in one place. Or you're adding modifications to some old code and you don't want to change the main element's CSS class, but rather just add one style.
"Everything will end up as a mess and very difficult to find out the reason."
Properly structured and organised Sass will make everything perfectly understandable, manageable, and easy to maintain. Using 20 or more microclasses makes the code very hard to understand and manage, unnecessarily increases the HTML size, and may, in some situations, also impact the performance.
You're talking about css shared classes. TW classes are different, I never think of any developer will ever try to override TW classes. They should be out of mind.
Anyway, if you prefer to work with Sass then that's your choice and no one is against that.
TW has proven its usefulness to the community and is well received by the developers. That's why it become so popular.
You're talking about css shared classes. TW classes are different, I never think of any developer will ever try to override TW classes. They should be out of mind.
Aren't TW classes shared? Is overriding an unnecessary and never wanted need?
Anyway, if you prefer to work with Sass then that's your choice and no one is against that.
Sass has nothing to do with TW. Sass organising your styles and working on them.
TW has proven its usefulness to the community and is well received by the developers. That's why it become so popular.
Popularity doesn't mean something is good. This has never been the case.
I'd be happy if you could provide a table with 2 columns: [Challange] [How TW resolved it] in the below post.
This is outside of the scope of this article. However, I would note that Tailwind's create (Adam Wathan) has specifically said that what you are advising is an anti-pattern and that @apply was only added to trick people into using Tailwind that did not like their HTML being littered with dozens of classes. His words, not mine. Source
If your company was using a css framework before, tailwind is solving that. pb-3 in bootstrap... what does the 3 mean? It means whatever your default size is. But what if you want something bigger? pb-4? But that's too big.
I thing it should not be that much treated as the only way. If you need couple of composes classes - world will not break. You definitely don’t need to make own class for each element in the tree - it’s for sure is not as it supposed to be done. But just few classes for very long class names - it’s fine I think.
I love Tailwind and SASS, but they have trade-offs. Tailwind offers scalability and maintainability, reducing the complexity of naming conventions.
If your project doesn't scale, then Tailwind may have more cons than pros, as it truly shines when maintaining large codebases with specific needs like SSR or performance.
I understand that it can be cumbersome and verbose to write styles like this, but using them at the right moment can be a lifesaver.
I think it's really important to know and experiment about everything that you can to know what these cons/pros are and understand what it's the right tool for the job.
@pablets Would you mind to explain what kinds of problems exactly does Tailwind solve?
The "scalability and maintainability, reducing the complexity of naming conventions" doesn't explain the issue and what kind of solution was invented by Tailwind to resolve it.
Is this bg-white dark:bg-darkNight dark:border-matteGray border-b border-grayLighter w-full flex justify-between px-2 py-3 items-center xl:hidden fixed top-0 z-20 called a "reducing the complexity of naming conventions"? If so, how so?
Can you give an example of scalability challenges and how Tailwind resolves them?
I can't find on Bun's site that they use WebKit engine. I see:
My personal opinion is that Bun is trying to build too many things around it, like TypeScript. Which effectively leads to so many distractions instead of focusing on core, stability, and performance. It will be a huge ballon that will eat memory with probably 70% of features not used. There will be quantity over quality. At the moment of writing this comment, there are 1590 open issues and 1703 closed.
At this rate of bug growth, Bun will spend more and more time fighting bugs rather than stability and performance. Let's assume that it takes 4 hours to fix each bug (extremely optimistic), that's already 6360 hours spent just on fixing bugs. Let's keep counting, 8 hours a day, that's 795 days! 795 / 365 gives you over 2 years of work just to fix 1590 bugs!
And it will keep growing, as implementing too many features is just a consequence of that.
To the whole great post, I'd also add the overhyped Tailwind, which literally does nothing new and makes the whole development even worse. See example:
flex transition-all dark:bg-darkNight bg-white duration-1000 relative 4xl:max-w-11xl 4xl:mx-auto 4xl:shadow-xl 4xl:rounded dark:shadow-4xlvs.
chat-messageTailwind complicated development 10 times by moving from logical to illogical order. What's wrong with reusable classes? What's wrong with named CSS classes? Instead of first looking at named classes to understand what follows, the engineer now needs to spend time decrypting the intention of the implementation behind all CSS classes. It should be the opposite: Read the name of the class. Interested? Dive into implementation details. Not interested? Keep searching. That approach allows you to quickly scan the app logic without diving into implementation.
You can always compose your own additional css class from tailwind css utility classes. What’s wrong with that approach which can be applied to such cases with classes that are too long/unreadable?
@andrzej_kowal
Composing your own CSS class was available long before Tailwind was born. My primary question is: what kind of problems does Tailwind resolve that weren't resolved before?
By making styling more visible and flexible, and limiting cognitive load. When working with a massive component-based SaaS codebase and an immature, unstable design system, I want to see styles in the DOM template of the component where they’re being applied without having to reference several different CSS files written by different authors at different times all applying globally what they thought could be taken for granted finding myself in CSS cascade hell trying to implement something new without breaking existing legacy UIs or take on the complexity of the entire system.
Pure CSS is beautiful and I can’t wait to ditch Tailwind… later, when the design system is mature and my UI is all nice, clean components, and what a joy it will be (and so easy too) to replace all of those tailwind classes with clean, structured CSS. But honestly, if I never get there, Tailwind will be just fine.
@stephenhebert Tailwind does not resolve the problem you described. Frameworks like Angular, Vue, and React do. You can encapsulate your styles within components. Even Web Components can be used today. Even using only Sass you still can structure code well.
By making hundred different small classes used within one element, it is extremely difficult to understand the semantic and expected behavior. The code should present the logic first. Implementation is important only when you want to dive into code changes, behaviour, or the like.
@stephenhebert , Tailwind does not decrease cognitive load. It does the exact opposite. I want to see less code, and more business.
Check this article from creator of TailwindCSS.
link.
If you guys would like to know what TailwindCSS actually do and why, it might be a good idea to get on their official website and read by yourself.
The idea behind Tailwind described by inventor isn't convenient to me. Let's move that discussion to some other relevant post.
I think you looked at this syntax
"bg-white dark:bg-darkNight dark:border-matteGray border-b border-grayLighter w-full flex justify-between px-2 py-3 items-center xl:hidden fixed top-0 z-20"and become a hater just because it looks ugly.But you forgot the benefit from it:
@ginkcode "All of these configs are very clear, when you get the hang of it you can imagine or figure out how the element looks like exactly at the same time writing html code. "
That's the most unneeded "feature." You should not read the code to determine the meaning and expected action of a particular element. Those small classes are related to one (in general) case, and later, with the combination of all of them, they create a single element with its behavior. I don't see any advantages to having 20–30+ micro CSS classes and forcing the software engineer to read and analyse the code to find out what it is and how it behaves.
"And more important thing, IMHO, the visual and preciseness of those tw classes, it's defined right on that element and belongs to that element only."
No, they are shared classes. Anything you change in one class affects all places where it is used. Single classes, like margin or font weight, used alone might be applied to some specific cases, e.g., components used only in one place. Or you're adding modifications to some old code and you don't want to change the main element's CSS class, but rather just add one style.
"Everything will end up as a mess and very difficult to find out the reason."
Properly structured and organised Sass will make everything perfectly understandable, manageable, and easy to maintain. Using 20 or more microclasses makes the code very hard to understand and manage, unnecessarily increases the HTML size, and may, in some situations, also impact the performance.
You're talking about css shared classes. TW classes are different, I never think of any developer will ever try to override TW classes. They should be out of mind.
Anyway, if you prefer to work with Sass then that's your choice and no one is against that.
TW has proven its usefulness to the community and is well received by the developers. That's why it become so popular.
@ginkcode
Aren't TW classes shared? Is overriding an unnecessary and never wanted need?
Sass has nothing to do with TW. Sass organising your styles and working on them.
Popularity doesn't mean something is good. This has never been the case.
I'd be happy if you could provide a table with 2 columns: [Challange] [How TW resolved it] in the below post.
I'd propose to move topic-related discussion to: dev.to/cezarytomczyk/tailwind-over...
This is outside of the scope of this article. However, I would note that Tailwind's create (Adam Wathan) has specifically said that what you are advising is an anti-pattern and that
@applywas only added to trick people into using Tailwind that did not like their HTML being littered with dozens of classes. His words, not mine. Source@thejaredwilcurt
That's for sure. However, I'd really love to hear what kind of problems Tailwind resolves that existed before.
If your company was using a css framework before, tailwind is solving that.
pb-3in bootstrap... what does the 3 mean? It means whatever your default size is. But what if you want something bigger?pb-4? But that's too big.Tailwind solves a lot of that.
I thing it should not be that much treated as the only way. If you need couple of composes classes - world will not break. You definitely don’t need to make own class for each element in the tree - it’s for sure is not as it supposed to be done. But just few classes for very long class names - it’s fine I think.
Because this Tailwind is more understandable?
h-screen xl:min-w-282pxl xl:w-260pxl hidden xl:block overflow-y-hidden dark:bg-darkNight dark:border-matteGray font-ubuntuI love Tailwind and SASS, but they have trade-offs. Tailwind offers scalability and maintainability, reducing the complexity of naming conventions.
If your project doesn't scale, then Tailwind may have more cons than pros, as it truly shines when maintaining large codebases with specific needs like SSR or performance.
I understand that it can be cumbersome and verbose to write styles like this, but using them at the right moment can be a lifesaver.
I think it's really important to know and experiment about everything that you can to know what these cons/pros are and understand what it's the right tool for the job.
@pablets Would you mind to explain what kinds of problems exactly does Tailwind solve?
The "scalability and maintainability, reducing the complexity of naming conventions" doesn't explain the issue and what kind of solution was invented by Tailwind to resolve it.
Is this
bg-white dark:bg-darkNight dark:border-matteGray border-b border-grayLighter w-full flex justify-between px-2 py-3 items-center xl:hidden fixed top-0 z-20called a "reducing the complexity of naming conventions"? If so, how so?Can you give an example of scalability challenges and how Tailwind resolves them?
I'd appreciate it.
To quote trac.webkit.org/wiki/JavaScriptCore
@mellen Thank you!