I always thought the bigger mess was html and css rather than JavaScript.
I was watching videos from the chrome developer conference and there were two young peppy faces beaming that "gap" was now a supported CSS attribute for flex containers. That means in 2 years, if we are lucky, we can space out elements without hacking margins on child elements. Sometimes I almost can't believe what we put up with.
The mess with CSS comes from the difficulty of code resuability once an application becomes complicated. Things start colliding and patterns diverge easily.
Thanks, yes, I didn't realize you were talking about a particular framework. I'm not familiar with that one.
> The mess with CSS comes from the difficulty of code once an application becomes complicated. Things start colliding and patterns diverge easily.
CSS is imperfect, and there are different ways to think about it. But if you find yourself running into design problems often, you may want to rethink how you think about CSS.
For example, my approach to CSS used to be thoroughly semantic. Lately I've been enjoying more of a "utility first" approach, which I learned about from an article that you might also find interesting: https://adamwathan.me/css-utility-classes-and-separation-of-...
Any language or system that requires highly disciplined and unintuitive patterns to make work is a flawed system.
There is a a sort of catharsis once understanding of a pattern is achieved but you should not be fooled by this. "Rethinking" a concept increases your perception and understanding but CSS was never designed to be thought about from another perspective. What you are mastering when you master CSS is how to use the idiosyncrasies of a flawed system.
This is not unique to the front end. SQL is much the same way. Often in SQL there are Optimizations with no rhyme or reason. You just write one permutation of a query and pray that it compiles into something performant.
A well designed system is one where good design is emergent from the language itself. A good example of this on the front end is ELM.
Things can seem unintuitive is when one's mental model of something is different than what's actually happening. In that case one can choose to believe that one's mental model is perfect, or one can consider the possibility that one's mental model is incomplete and/or incorrect.
But that's learning, no? Everyone's mental map of almost everything is incomplete and/or incorrect. Consider that CSS is generally (the occasional implementation bug notwithstanding) doing what you tell it to do, and that if it's not doing what you'd expect, that there's probably an opportunity learn why your mental model doesn't match the reality of the abstraction.
> This is not unique to the front end. SQL is much the same way. Often in SQL there are Optimizations with no rhyme or reason.
There's always rhyme or reason (or bugs, sometimes). I have the pleasure of working with some of the foremost SQL experts in the world. When SQL that I've written doesn't work how I'd expect or as performantly as I'd expect, I inevitably discover that the problem is that my mental model is wrong and/or incomplete and eventually walk away with enhanced understanding.
Many times the model that the language promotes is not what the developer needs so the developer creates patterns to deal with inefficiencies. This is a flaw.
Sql abstracts the underlying model of procedural algorithms into a one line declarative expression. The language is designed to hide the model deliberately.
However due to the requirement of optimizing queries one must optimize the procedural algorithms while working with an API that deliberately hides it. Thus in order to know which permutation of a sql expression maps to what permutation of procedural algorithm you must memorize arbitrary mappings or hacks. This is a huge design flaw. Your premiere sql experts are experts in using hacks to get around the flaws of SQL.