While Bootstrap certainly abstracts CSS away for you in a way that you can get by without knowing much about CSS (for simple things), Tailwind is just tokenized CSS. You can't use Tailwind without knowing CSS or learning CSS in the process.
The problem with tailwind is it does away with separation of concerns and messes up HTML, like the old styling tags in HTML. We moved on from those for good reasons.
It really isn’t the same as inline styles at all. It’s the best of both worlds, in my opinion. It’s hard to see myself ever going back to the old ways.
I have given a chance to Tailwind and it was neither nice or easy. I actually give up, wondering why my younger colleagues appreciate writing CSS using class names.
I write CSS since its debut. Clearly it wasn’t enough suffering: they reimplemented it as a class-name based language - with horrible IDE support. I am perplexed - I must be the boomer around here… :)
I think it makes sense when writing css for isolated components - usually ignoring the cascade. Makes it possible to not name things which is a plus in componentworld.
The thing is, it’s the cascade that makes css as powerful and elegant as it is.
And not naming the things comes at the cost of listing all css properties as classes on each element.
I write CSS and must say that in 2024 CSS is an amazingly powerful and elegant language.
If one is willing / given the time to learn it.
Using conventions like ITCSS, a few libraries like https://utopia.fyi and placing colors, font sizes and spacing into variables + the use of a few utility classes provide most of the conveniences of a utility-first framework with no downsides.
I can also see how devs focusing on components prefer utility-first frameworks for the speed of development. Despite the low maintainability and the horrible markup.
While this game is quite nice and fun to play, I find it kind of tempting to just experiment with the values until you solve the current problem instead of focussing on the "How does it really work" aspect of the problem, which would lead to a deeper understanding...
One way to solve this could be to allow more freedom in solving the problem as well as a small penalty on more than 2 or 3 tries.
I write frontend code and especially with CSS it's always trial-and-error, "bruteforcing" as you describe it. Sometimes you just gotta play with it until it works, while utilizing what you've learned from the previous times whacking at similar problems.
Giving players so much freedom that they can easily identify and execute a grindy, brute-force but boring strategy is an extremely common problem in game design. Fault is irrelevant, it is the game's problem if the player stops having fun because they got trapped in a psychological pit tying to circumvent the rules when playing by the rules is ultimately easier.
This is a tradeoff so requires some balance, but OP's suggestion is simple, unobtrusive, and probably effective.
Exactly. That's also the same reason why a game being too easy is the game's fault. One could object that players should be more disciplined and intentionally forego (e.g.) the stronger weapons in the game. But part of the fun of playing the game is to try to get the best possible weapon. Similarly, it is little fun to play e.g. tennis or chess against a weak opponent. Either it is too easy, or you don't give your best, neither of which is particularly fun.
The whole purpose of a game is to complete a goal. Good games gamify you to achieving that goal. If the goal is to learn CSS and the game hasn't guided you to achieve that goal then it's failing at its purpose. Blaming the player for not playing correctly is an unbelievably bad take. The mechanics of the game should punish the user for doing the 'wrong' thing and reward them for doing the 'right' thing.
I used to work at a place where weekly we'd have a show-and-tell with the team for about 30 minutes. One week I brought this and I let people who don't code give answers to see how far we'd get. It's interesting to see some who "got it" and others who struggled.
Overall people loved it! I think it was a great way to develop some basic programming skills in people who would otherwise never code in their entire life. For years after I did this my coworkers would bring it up as kind of a "You do _that_ all day?", which I thought was funny because this is like the easiest part of my job and they thought I was a magician for it but it was nice to see they respected the work more because they did it themselves a little once.
I thought Flexbox was a CSS gamechanger and then came Grid, which is so amazing and predictible.
Really, the only pain I have left with CSS is when I get into weird cases of "I want a component to use up any remaining space that its siblings don't use, but one of its children should use up everything it gets that its siblings don't use, and then overflow scroll if there's not enough space."
There's a whole bunch of cases where I find these weird interactions between flexbox and grid and some sort of priority for sizing layout that I don't quite understand. I suspect this is mostly on me, but it's something that, unlike flexbox and grid, still feels not straightforward.
I still consider those years to be the golden years of the web development. When the fruits of web standards movement started to appear. Alas, then came react and all the good stuff was thrown out of the window. I guess tag soup is palatable, when it is buried deep in node_modules.
Nowadays, I think the opposite. I feel a pang of jealousy and regret when I load a page from before CSS Zen Garden that uses tables for layouts. It still exists and works perfectly. I love how I can automatically date it in my mind, like period furniture or buildings. Unlike the thousands of pages that I made at the time, which are either gone or broken. I yearn for the html files that I lovingly handcrafted as unique pages. I destroyed them myself so that they could use a one-size-fits-all CSS solution. And they could in turn destroy each other with each new site redesign. If I ever get back on the indieweb, I'll be creating each page as a single file and allowing them to age gracefully.
I used to do web dev during the tables-as-layout days. I don’t miss them a little bit. For one, Netscape wouldn’t render anything if the table tag wasn’t closed, and still nothing regardless until it did hit the end tag. And that’s to say nothing of the dodgy layout quirks they had. No thanks.
They work now though. Do you remember all the CSS hacks? All those pages are broken today.
I'm not saying it's better, I'm just saying that I have a lot of regrets about jumping too hard on the bandwagon with a lack of critical thinking, and if I'm honest, evangelism.
The website links to Flexbox Froggy but via a link that requires you to register an account, but you can access it directly via https://flexboxfroggy.com/
I was hoping this would help me find a good solution to some small, simple web frontend thing I've been working on. Instead, after playing the first 10 levels, I just hate CSS more.
I dislike CSS Grid because it takes away almost all the semantic of the HTML. Flexbox at least means your HTML tree corresponds to some kind of structure on the page, CSS Grid means you see this
<div class="GridParent">
<-! random amount of divs without classnames -->
</div>
And you're suddenly required to cross reference CSS to make sense of what's on the page. It's just ugly, even if it is wildly effective.
Different topic, but this could be solved if somebody wrote an IDE that understood all the relationships between your HTML and CSS and let you manipulate it visually, rather than having to manually cross-reference symbols.
And I'm so thankful. Table layouts are horribly restrictive and opinionated with all sorts of arcane under-the-hood rendering rules making simple things like fixing the width of your columns not work at all. Grid is better except obviously if you're rendering an actual table
I really enjoyed Flexbox Froggy and felt like it helped me a lot better than Grid Garden. Maybe my brain just isn't a grid-oriented brain— CSS Grid never seems to stick.
CSS Grid was the first specification for page layout using rows and columns (grids) since the creation of the web. Everything else prior was a compromise.
Flexbox is for laying out rows or columns; while you can do some limited page layout, that's not what it's designed for. Just like tables and floats weren't designed for page layout either.
Another way to grok this: CSS Grid is for two dimensional layout and Flexbox is for one dimensional layout.
Flexbox and CSS Grid were designed to work together, each doing what it was designed to do.
Flexbox generally tends to be great for a single row/column layout, grid excels at multicolumn/row (especially considering subgrid)
One of the most useful features of grid that replaces flexbox, in my experience, is auto-fit and auto-fill, which are great for "card" style layouts. You can use flexbox for these, but the treatment of wrapping items in non-full rows was always a point of frustration for me. This is even better if you can utilize subgrid to align the card contents.
I don't recommend spending time on this. It doesn't teach you the right things. The problems you'll be solving in this "game" do not relate to the problems you actually need to solve when you actually need to do something with CSS Grid.
Honestly the game is kind of disappointingly surface level. It spends far too much time trying to exercise your knowledge of template columns and grid start/end but not enough to explain way more other features. No lessons about colspan, minmax, autoflow, gap, column names, subgrid and much more. I found flex to not fit a usecase I was working with so decided to use the website to learn about grid and I was pretty unamused to find out how little it actually teaches you
This is an old game from a time when CSS Grid was new, so they just focused on the basics. Nowadays you can probably assume that most CSS users are somewhat familiar with basic CSS Grid already, so a game which covers the advanced features would make more sense.
For someone such as myself, doing backend, this gave me a solid foundation for building modern UI apps while keeping them lean and simple.
No Bootstraps, no Tailwinds.