3 ms·

Except that with using a framework you have a big black box of unknowns. And they will remain unknowns to you unless and until you take the time to dive into t

Except that with using a framework you have a big black box of unknowns. And they will remain unknowns to you unless and until you take the time to dive into the internals of the framework (StackOverflow only gets you so far), at which point you might as well learn CSS. So what happens when the framework does something unexpected? Or, as is more often the case, you run into a situation where you need to do something to satisfy the requirements of your project that the framework simply didn't think of? Again, you can dive into the internals of the framework to figure it out. I'm arguing that in the long term you're better off learning CSS. Then you KNOW you can do what needs to be done. And with CSS you can still use a framework if you want but fall back to pure CSS if and when you need to.

wild_preference 8y ago
Now apply what you said to the mess of style.css that the churn of developers before you has appended to on an as-needed basis. Except nobody has the time nor role to organize and maintain your project's CSS like Spectre.css' developer could. And nobody wants to because CSS accumulates technical debt rapidly. Everyone opens up that file just long enough to do what they need and then they get out before the house of cards falls down. To avoid adding rules that break existing UI, they add a new class and a new rule just for that class to be safe. And let's say you're a CSS master. Which doesn't help all that much beyond being able to maneuver in the mess that was created. The above paragraph happens in projects where everyone knows CSS just like a project can evolve into spaghetti code between capable developers over the terrain of changing requirements. And being a CSS master equips you to understand a CSS framework too, so I don't understand why you keep alluding that CSS knowledge makes frameworks obsolete. I'd rather read organized framework code than whatever the bespoke clusterfuck people end up when left to their own devices under the constraint of time and deadlines. Frameworks help contain complexity. They aren't just a tool for beginners and non-professionals. You're making the wrong assumption that messes in programming are only made by not knowing the language. I remember thinking the same thing at my first job out of uni, but I was quickly straightened out at my first job when I realized that being good at a language meant almost squat against the real reasons: real world applications fighting between churning requirements, business concerns, and scarce developer resources like time.

wild_preference 8y ago

Now apply what you said to the mess of style.css that the churn of developers before you has appended to on an as-needed basis. Except nobody has the time nor role to organize and maintain your project's CSS like Spectre.css' developer could. And nobody wants to because CSS accumulates technical debt rapidly. Everyone opens up that file just long enough to do what they need and then they get out before the house of cards falls down. To avoid adding rules that break existing UI, they add a new class and a new rule just for that class to be safe. And let's say you're a CSS master. Which doesn't help all that much beyond being able to maneuver in the mess that was created. The above paragraph happens in projects where everyone knows CSS just like a project can evolve into spaghetti code between capable developers over the terrain of changing requirements. And being a CSS master equips you to understand a CSS framework too, so I don't understand why you keep alluding that CSS knowledge makes frameworks obsolete. I'd rather read organized framework code than whatever the bespoke clusterfuck people end up when left to their own devices under the constraint of time and deadlines. Frameworks help contain complexity. They aren't just a tool for beginners and non-professionals. You're making the wrong assumption that messes in programming are only made by not knowing the language. I remember thinking the same thing at my first job out of uni, but I was quickly straightened out at my first job when I realized that being good at a language meant almost squat against the real reasons: real world applications fighting between churning requirements, business concerns, and scarce developer resources like time.