I would've guessed the entire thing rendered in canvas, but no, it uses HTML and just uses a canvas for stuff like the paint program.
If you did everything in canvas you’d just have to reimplement something like flexbox to center, align, stretch, and animate all your icons text, boxes, buttons, etc.
Why not just stay in HTML and use a layout engine that’s already implemented, and highly optimized for literally every platform.?
IE, Chrome, Firefox, and Opera had their own separate rendering engines. IE was also notorious for running with "quirks mode" out of the box which basically meant that IE was render pages in a non-standard way by default
It was possible to develop things correctly, of course. But resources, both in terms of availability of documentation as well as time, were not as easy to find as they are today
tired of people who've never seemed to use CSS beyond some pet project or stuck in early 2000s (all frameworks are dumb!) mindset make the wrong arguments over and over again.
Perhaps they use frameworks and write CSS at scale. You don't know and failed to enquire, instead becoming defensive and robbing the circumstance of the chance for productive conversation. Shame.
Value judgement for value judgement, I'd say the snark both ways is pretty fair. More than welcome to explain their pov.
Naming things is often hard, but at least with UI you’re usually building something concrete so there should be some name—if not a wrapper that holds more loose parts you can’t easily control (like a #Content element around some reStructuredText output).
The cascading part is a double-edged sword tho. It can be used to great effect for good, but it can be unweildy with a disparate or undisciplined team. But it’s often better to work with it rather than fight uphill against the only style engine we have in browsers (if feasible)—the output will generally be smaller & easier to follow with less to know or maintain.
mb-5 = margin-bottom: 5x (something)
It’s ‘standardized’ within its niche. Niches can have shorthands, but breaking into mainstream seems a bit lofty considering the ambiguity from the outside (I’ve never used regularly) as well as how much & how far you can get with CSS without a library (not saying there’s not obvious places for libraries).
You could be more clear by writing margin-bottom-5, but then you reinvented CSS. And using shorthands for singular properties feels like reinvented CSS—especially since the name implies you can’t even refactor mb-5 { margin-bottom: 6α }. If you can’t use it to refactor, what’s its point?
You could say the same about any api not being immediately obvious.
> And using shorthands for singular properties feels like reinvented CSS
It’s quite a nice way to describe css in my experience. The shorthand classes actually teaches you css too. As they’re basically a 1-1 mapping, but you can write them much faster than manually writing the styles
It also scales well, as you don’t get crazy css class hierarchy’s that are hard to modify.
> you can’t even refactor mb-5 { margin-bottom: 6α }. If you can’t use it to refactor, what’s its point?
Not impossible, I mean you can easily edit the tailwind.config to be different for mb-5. Or search all relevant instances of mb-5 and replace them with mb-6 for example.
I think it’s best for component-driven development, where you want to encapsulate styles with components and not have them dependent on the context that their in. It does make the HTML more verbose, but development much easier and faster
There' s reason why there was a rise in something like tailwind, because they ended up creating what IMO we end up doing anyway. For me, it's 100x easier to maintain to open a component up that is months old and grok every everything about it without having to reference some other CSS file or structure. If I want to tweak some aspect I can do so easily right there, I don't have to jump back and forth, and it's better than inline because I benefit from things like hover styles and responsive classes which I can't do inline. You can always extract truly reusable pieces into their own class.
Is it more verbose? Yes. Can it be abused? Yes. But I wouldn't go back to the "old" way and it isn't for lack of knowing how.
just to be clear, perhaps we're talking about the same thing (mix of style) just from a different angle and more emphasis on one or the other. i still use a "global" stylesheet as a base but the majority of our work within components is utility classes, so i'm also not suggesting that everything be utility only.
If you weren't full of it, you'd defend your position rather than wasting your time denigrating strangers. Even worse, smart people are going to reply to you in order to make your argument for you. So then people to try to have a real discussion within this poisonous context. All over the internet, over and over again.
to be fair, his initial point didn't make any sense to me and was also of the same flavor of assuming something about people (equating utility classes with people not knowing CSS) and prompted my knee-jerk response. i clarified my point to him in a later reply. seems we did have a fine discussion?
but thanks for assuming that i'm full of it lol. ironic in a way that you'd criticize me while throwing the exact same ad hominem when you literally also know nothing about me.
- Bootcamps & self learning resources don't emphasize CSS. JavaScript gets you hired. A huge amount of web developers in the last 5-7 years came out of bootcamps and career switchers self learning, and the resources available overwhelmingly focus on frameworks and JavaScript, to the point that I've been in interviews where someone can give really good answers if the answer is framework specific but they don't basics like `call` or `bind`.
- See previous comment. JavaScript gets you hired. Rarely, if ever, have I seen candidates get rejected because they lacked proper CSS knowledge nor have I seen it be appreciated on the same level as having "deep" JavaScript knowledge
- CSS isn't programmatic[0] like JavaScript. The rules are different, and more fuzzy. Its one of its strengths, but its also a bit of a weakness, as you can't simply algorithmically design something and test its outcomes. You have to understand spatial concepts like placement and understand how to design / create with tools that have multiple different ways of achieving the same outcome alot (but not always). CSS does have more "exceptions to the rule" than JavaScript does.
- In many ways, it doesn't help that CSS has had no API culling. IE, we know that flexbox / grid are much preferable but many developers don't grok things like when you should use negative margin, border vs outline, or proper usage of media queries. Then you have things like color formats, e.g. HEX vs RGBA vs HSLA. Which one is "better" isn't obvious to many. There's alot of CSS features like this.
- In many ways, CSS has a bigger surface area, a much more expansive API, and way less backing documentation from the community. MDN is pretty good, but its not exhaustive (nor could it ever be, really) to every situation.
- The reliance on CSS frameworks / generators. I think a big part of the popularity of things like Tailwind is you can just "try until it works the way you want" by throwing combinations of different classes together that a developer may semi-understand should work together until something happens, basically, which side steps having to have deep knowledge of CSS in many ways, or take bootstrap. Bootstrap made it easy to build websites following a formula. There are many other examples of this.
- Developers really don't understand how to properly leverage the cascade. The industry general notion is "avoid it at all costs" because the same thought that goes into organizing your logic (JavaScript) isn't given to CSS. There's really bad hygiene practices in our industry with regards to CSS and its derivatives (SASS, LESS)
[0]: I realize CSS is turing complete if you abuse custom properties a certain way or with the recent addition of container queries you could model this as well. I'm talking about it more in the way that CSS isn't like JavaScript, in that you have no familiar programming constructs (like if statements, for loops etc). Yes, I understand in the most literal sense, CSS is technically a programming language, but in practice, I don't think it is (at least, not yet)
This was how I ended up writing flexbox like layout code for SVG with a VML bridge. Was a good project as a junior developer.
But when I try to explain what these things are to a person learning JavaScript, I am vaguely aware that I sound like a lunatic.
Perhaps 'koolaid syndrome'.
I am not stupid - C, Java, nginix, streams, tcp slow start, NBP, etc. But CSS has always been hard for me. 'float'? 'block-inline'? <div/> vs <p/>? Eh? Rem's and em's, %, and px's Oh My!
One of the things that helped was to understand that CSS is a _layout_ engine. It takes a list of elements and plunks them into a container. In prehistoric times (BG - before grid) you needed to float things.
So yes, CSS is very capable. And there are some things that would be much harder to write with Canvas or Threejs. But if I didn't already have CSS koolaid syndrome, I wonder if ....
I have to re-learn CSS every two years, since I might not do front-end development for a year.
But I'm pretty happy to do so, because the best way sometimes changes. I never get very good.
But maybe one day down the road I have been considering a total rewrite in WebAssembly in which the entire thing is a canvas. I feel this would be much more portable to other platforms and would have a better chance of escaping the browser one day.