Great question. We rarely rely on shared utility classes these days. Historically we'd end up going the @apply route, but lately we just add a new style to the root-level css file and call it a day. We may prefix it with "@layer" so that it gets tree-shaken, but that's about it.
I've found that in component-driven UI, the need for these kinds of utility classes becomes less and less necessary. The utility CSS may be defined in the component, and the component is ultimately what gets reused.
Could you elaborate more on the reason for your interest? I've used Tailwind to implement several well-defined design languages, and always had great success. In fact, compared to other design systems, Material for example, I found it to be far simpler to manage over time.
I’m a strong advocate for Tailwind, and I believe that this approach is truly effective. In my experience, this subset of Tailwind has been sufficient for every project I've worked on that used it. Moreover, I've observed that it often converts skeptics into supporters.
Mostly echoing everyone else’s appreciation for the film in the thread. I was sucked in when I saw it the first time, and it’s one of the few movies I regret not seeing in theaters when it was available. If Alamo ever decides to do a special showing of it, I’d be there in a heartbeat.
It’s upsetting how as the years go on, I’m seeing more and more similarities to the world that the film depicts. But in a strange way, that makes the film all the more important to me.
To address your point about the lack of fragments: It's not as clean as React's implementation, but you can set a component to "ViewEncapsulation.None" to help address this.
Within a components template though, I frequently use <ng-container> to execute async pipes, or to perform simple conditional logic without adding unnecessary divs.
I was in a similar situation, and ultimately decided to reimplement the state management using NGXS. Fortunately the app was relatively small at that point, but I found that it held the developers hands a bit more, which lead to significantly more readable code.
Things can still get tangled up once you start using "ofActionDispatched" lifecycle handlers, but overall I found them to be far more manageable over time than NGXS.
NurdRage - incredibly interesting high level chemistry (to me at least). Has a really great series where he finds a new way to make Sodium Metal.
https://www.youtube.com/user/NurdRage
The "Spec House" series is incredibly valuable if you're even remotely interested in building your own home. I'm incredibly excited to see how that series continues!
I consider Essential Craftsman to be one of the best YouTube channels out there. If you're interested in tools, construction or history in heavy industry, definitely give it a look.
Not entirely. I do approach new projects with a bit more scrutiny than before, which I consider to be a good thing.
I do a lot of small projects here and there. I'm currently working on one that I've been chipping away at for the last six months or so, but it's coming along at a much more relaxing pace.
While I do think that it's important to finish what you start, I also believe that knowing when to stop is just as valuable.
I admittedly haven't looked at it since I gave up on my personal project, so I'm not entirely sure of it's state. However, a quick glance at the changelog seems to indicate that it supports .NetCore in some fashion.
I spent about three years working on a webapp for simplifying the RFQ process, specifically for defense projects. Ultimately I decided to finally call it quits on the app when I realized that even if I built this thing, I'd never have the skills/time/patience to sell it. Wish I had realized that sooner!
After work I would typically spend a few hours a night hacking away at whatever feature I thought was a "must have". Suddenly the list of features that were absolutely needed to ship a 1.0 release grew quite long, and was too much to manage on my own.
I called it quits a few years ago at this point, but I wouldn't say I regret my decision to have put so much effort into a project. It gave me an opportunity to contribute to some high-profile libraries like Lucene.NET and Backbone, and I most certainly grew as a developer.
I wouldn't beat yourself up too hard, though. I'm sure you learned a whole lot about browser limitations, animation, and how to manage your time and expectations in the future. If you agree, then I'd say it wasn't a total loss at all.