True for sure, but there is a limit.
I actually feel like I’d prefer to have an electronic limiter in “normal” mode that would keep it at a certain level of power. Sport or track mode, go nuts.
Yep, once we reach a tipping point, we’ll see a snowball effect where low-margin gas stations are forced to close, others have to push their prices up, BEV’s become even more attractive and so on.
With the number of cheap (mostly chinese) BEV’s available now and coming in the pipeline we’re already seeing some very cost competitive propositions.
I think that point is very close, maybe mid-next year if all goes well.
Y'all understand that gas stations make almost all their money from snacks right? They make maybe up to 10 cents a gallon on gas. It's always been a low margin business, but since gas can sit in a gas station's below ground tank for months at a time, it's not really a concern for them if people start filling up gas less and start super-charging more. They will simply have less fuel resupplies. That's all.
It's funny, in another thread I pointed out the convenience stores, arguing that it will incentivize shutting the pumps down sooner rather than later. At a certain point pumps need replaced, and won't do it if they're not going to pay themselves off.
A lot of stations will go out of business if they only have say 50% of the sales volume though. Or even 70%.
Places lake motorway service stations where people will supercharge will do just fine, but your local gas station will have to compete will home chargers, parking lot chargers, etc. Not a lot of people will choose to shop at an expensive gas station shop if they don’t have to.
People aren't going to stop eating snacks and munchies just because they get an electric car. And I don't know if you've ever been to a Wawa or not but a lot of convenience stores are starting to serve decent quality food as well.
Selling gas is hugely profitable, labor cost for dispensing gas is zero. It's why legacy c-store operators like 7-11 and Wawa now include gas at almost all new locations they build.
It's not hugely profitable, its simply a draw for foot traffic to sell more snacks, alcohol, and food. 7-11 and Wawa have been serving gas since as long as I can remember.
Gas stations make about 10 cents per gallon gross profit on the gas pumped. That's before capital equipment depreciation, equipment maintenance, facilities staff, cleaning, etc.
It's profitable, but it produces a minority of the business's profit. The bulk of the profit is from higher margin snacks, drinks, alcohol, cigarettes, lottery, etc.
A switch from gas to electric is not going to affect most convenience stores.
> Gas stations make about 10 cents per gallon gross profit
According to 7-11, 39.75 cents per gallon in first half of 2022. Also, while same-store merch sales grew 4.9% y-o-y, gas gallons sold grew 44%. (page 25 of the link)
> 7-11 and Wawa have been serving gas since as long as I can remember.
You must be young, Wawa was not traditionally a gas station. It opened its first store in 1964 and had over 500 by 1992, but the first with gas was in 1996.
7-11's history and relationship with gas is more complex, but most legacy stores were freestanding store only (no gas).
For generations we’ve had this concern that technology leads to poor outcomes, Johnny just wastes his time watching TV/Gaming etc…
Still, parents, due to various factors had to let their kids be kids, and fend for themselves.
The kids didn’t seem to suffer massive mental health issues though, things pretty much worked out in the end.
Fast forward, parents may be more overworked, or may be addicted to the same devices we’re discussing here, so things may be slightly worse, but we’re seeing massive mental health challenges (not solely as a result of insta etc…).
Parents are ill equipped to cope with this from my experience, companies are weaponizing their apps to draw eyeballs with a level of competency never seen before, we have few defences, it needs to be on the co. / gov.
Sounds like another regression like when they removed music sync from smart watches when they killed google music and there was no current or eta for an alternative with YT music.
Entrenched usage patterns sometimes deserve to be broken, bringing in a new method of operation facilitated by new tech can be a game changer.
I’m not in a position to say if this is the case here though, but for one example, a Tesla’s ability to cancel indicators once it’s seen you’ve completed a lane change operation seems to be a step forward. So at least they’re thinking of new methods of operation.
Change is uncomfortable, everyone will be somewhere on the curve, depending on where you are, you might love it or hate it.
>Tesla’s ability to cancel indicators once it’s seen you’ve completed a lane change operation seems to be a step forward
That already exists. It's called "tap to pass." Tap down the left stalk but don't let it indent, and then it'll flash three to five times (depending on manufacturer) before resetting. Even then most modern steering wheels have speed sensitive systems that let you just bip the wheel right or left to turn off the turn signal at highway speeds without a full quarter rotation of the wheel.
I disagree, in a lot of cases a new service would require an update to 1 or 2 stacks only, and only those 2 stacks need deploying.
It is in some cases required to do some version of this as the vendor API support does not allow for proper feedback when an operation is complete so it needs to settle.
Or, building docker images which run each time and take a long time / resources unnecessarily (I believe Pulumi have a fix for some version of this).
If your stacks are deployed via CI/CD, it’s not really a big deal to deploy 10x stacks in sequence, or just.
This may be overkill for a lot of projects but it’s valuable insight from a respected organization / individual.
Why should anyone care about adding third party tech?
This argument boils down to: “But you don’t need Tailwind for that. You can do more work for a (almost certainly) worse result with a designsystem.css!” Sure you can! Why?
If you really want to, you can even use Tailwind's naming for you language file. The thing is, you add complexity to do a job that could be done in the same way without adding complexity and dependencies.
Shouldn't we try to justify added complexity through added value?
Because most frontend engineers cannot make something as visually appealing as Tailwind’s defaults and most designers cannot make frontend abstractions as ergonomic as Tailwind’s.
Now it seems like you’re suggesting just reimplementing Tailwind? Or yes you can have one of your FE engineers and one designer try to dream up your own Tailwind but again: why? Now you’re consuming two people for something that can be achieved by literally zero people and “yarn add tailwind.”
It is not at all my objective to “reduce complexity” that sits behind good abstractions. My goal is to ship product and to put as much complexity as possible behind good abstractions and ideally out of my team’s maintenance burden and Tailwind helps achieve all of those.
Sure, if Tailwind provided literally zero value I would say you shouldn’t add it to the codebase. But it provides a huge amount of time-value (the best kind!) in my experience, so “there’s a package from the internet” is hardly a consideration whatsoever.
If the Tailind defaults are used in a design language file, wouldn't it be simpler? If it's only a problem of "aesthetics", 20 minutes is enough to use Tailwind's defaults in pure CSS. No need for calling a designer here either.
Side benefits include that there is then no need to update any dependencies or library, no need to run a JIT server, no need for a new syntax, no need to wait for implementation of new CSS features, better performance possibilities, etc.
Just checking that I understand your suggestion: it’s that you copy/paste Tailwind into a file called “designsystem.css” and then say that you are not using Tailwind?
Or are you saying take their design system and use your own syntax for it (so it’s less complete than TW, less well-documented, and less transferable to/from the vast resources of the internet centered around TW)?
Sure now do the same for: whitespace (margins and padding), border radiuses, shadows, opacities, font sizes, font weights, and continue playing whack-a-mole as you run into new cases.
Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set of classes that took you zero hours of initial setup and will cost you zero hours of maintenance outside of your own use/application until the end of time. And it has a name so when a new engineer joins your team, you can say "we use Tailwind, go to tailwindcss.com" and they are fully read into your setup in about 15 seconds.
And the IDE will help you autocomplete it all. The same is true for all the other properties you enumerated. If it's a Tailwind design token, it can be a pure CSS design token. No "whack-a-mole" needed here.
Still, you're right about having documentation. And there has been a loooot of these kinds of doc (BEM, SMACSS, ITCSS, etc.) in the last 15 years. Nonetheless, a more modern-oriented one is indeed needed. And that's why I'm working on something like this.
As for the "15 seconds", I mean, really? If so, I beg to disagree. There is a lot to take in. And that is why numerous colleagues still have to open the Tailwind docs to know how to write a class that's not 1:1 CSS.
And lucky you if you haven't had any update and dependency issues in the medium to long term. But I know we had.
> Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set "of CSS features".
The sentence above is every bit as true as yours. Add a beautiful design language and you are in business.
> 20 minutes is enough to use Tailwind's defaults in pure CSS
not 20 minutes, more. Plus all the boilerplate around @media rules
> no need to wait for implementation of new CSS features
What CSS features are you waiting for with Tailwind?
> better performance possibilities
It's very hard to beat Tailwind's performance since it's a fixed set of css classes (and a very small set in production, since it only includes classes you actually use".
Any IDE can autocomplete 90% of any media query. And, on a sidenote, I was only talking about using Tailwind's default aesthetics in pure CSS, here. That's what the 20 minutes refers to. And I think it was a conservative estimate.
As for features, it took months before grid was included in Tailwind. New powerful and useful selectors aren't there. It took years for Tailwind to support "group hovers". And I can give even more examples if you're still not convinced. Or you can have a look at the changelog.
As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded? And that's not even considering the weight difference between the "tailwinded" HTML and the one needed to support pure CSS. These things matter if performance is a goal (as it should be).
If I'm missing something, go ahead and tell me, I'll be reading with great interest!
:root {
--gap-default: 2rem;
--gap-large: 4rem;
... 30-40 more vars ...
}
.component1 {
margin: var(--gap-default);
padding: 0 var(--gap-large);
... more styles like this ...
}
@media (min-width: 640px) {
.component1 {
padding: 0 var(--gap-default);
}
}
@media (min-width: 768px) {
.component1 {
... other overrides
}
}
/* potentially repeat for other breakpoints ...*/
/* repeat for all components */
/* repeat for some internals of some components */
> As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded?
Tradeoffs.
Most existing solutions can't even detect duplicated CSS. So if your existing component already has `width: var(--some-var)`, and you load a different component with the same style... You will still load that style hidden in a different (often auto-generated unique) class name.
Meanwhile with Tailwind has a fixed number of classes that apply to all components equally.
So, if you have a complex app with multiple component variations, of course you'll need to split your CSS and only load relevant CSS for displayed components. Because your CSS grows with the amount of variations, and each of those variations becomes its own unique class.
For Tailwind though that growth slows almost immediately because... it's just a fixed set of classes.
In your code example, all that is in :root should be used from project to project. As it is Tailwind. Only values should change. Again, same as Tailwind. So I don't really see a problem.
For .component1, you would do the same in Tailwind albeit with fewer characters but as I said, your IDE should pick up the slack here.
mb<tab> --gap<tab> and it is done.
As for your duplicate width problem, it can be solved easily with a linter that prevents styling across files. I'll give you an example if you're interested. At the same time, you would be repeating "width" across components in Tailwind too.
So the duplication still exists, if I understand correctly. Same with the growth of CSS... In Tailwind you grow the HTML instead. Fixed clases or not. I don't see how it is better but, again, maybe I'm missing something.
As for the media queries, same as above: your IDE should pick up the slack.
BUT!
The thing is that by writing modern CSS, you would not need most of these media queries! Do you know "clamp()[1]"? It's magical
And unfortunately not supported in Tailwind at the moment
the above will do what you want without media queries! clamp() solves a loooot of these use cases. Honestly I don't write much media queries anymore and yes, that's great.
And if I may, I think Tailwind here prevents you from thinking about better and simpler solutions like this one. If it ain't included in what you're using, it's normal to not think about it. But really, this is a game changer. And it's been available for certainly three years. That's a lot.
And in the end, I'd say using real CSS with Tailwind kind of defeats the purpose. You end up with different styling methods for different components. I don't think that's good. More like a "hack".
But really, your example above is right on point: by excluding new approaches, Tailwind disincentivize you from using them when they would solve many of your problems elegantly and simply.
edit: the Tailwind example provided is bad CSS. As were the ones given in the first fundamental post by Mr Wathan. These are strawmen. If you're interested, I'll give you an example of good CSS producing the same output.
And, as I'm sure you know, milliseconds are important in our craft. You can easily shave or add hundreds of milliseconds with HTML or CSS.
And to be honest, I find your general line of inquiry here to be quite agressive and dismissive. I think, respectfully, a little more good faith could further our understanding of each other.
The question about what you're building such that you care about perf characteristics of CSS is an effort to understand you, I am sorry I failed to come across that way.
Outside of consumer apps I am struggling to imagine a case where the HTML/CSS perf delta would be more important to capture than faster development time. I suppose part of why that doesn't seem like a good faith question is because you don't believe Tailwind dev time to be faster, so the tradeoff that I'm trying to evaluate is totally inane.
First, sorry for the response delay. I don't know why I didn't see your answer.
As for the case in point, in fact, I think CSS can be as fast if not faster. But that's totally for me to prove. Hehe.
That's why I'm working on a set of simple rules for efficient styling with CSS. A website with documentation, examples and tools is in the works. If you're interested, I can give you a heads up when it's online.
Feedback from Tailwind users is important and would absolutely be welcomed!
