Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Adding styles to html tags should be standard and everything should be normalized by a pipeline / ide. The fact that we need to manage gazzilion of css names instead of just write styles in tags and let computer to extract and merge those to generic names is biggest disappointment in frontend development.
-
@vane No, it shouldn't. Separating structure (HTML) from presentation (CSS) was the whole idea behind CSS. The way you suggest is how people worked in the bad old HTML 3 days in the 1990s.
Fun fact: CSS frameworks replicate that shitty old way of working by slapping presentational classes in the markup, thereby using CSS only by name while actually staying in the 1990s. -
@Fast-Nop I understand what css is. I'm saying it's not practical to change things in devtools and then copy paste it to editor, create css classes instead of just putting everything in style and then push some combination of keys to extract those to common names. Also if you want to deal with sizes you need to jump around @media instead of just use style="@media.foo.width:300px" and let the compiler to do the magic
-
@vane It's not only practical, it's actually faster. You just don't care about styles in the markup, it's that easy.
In the markup, you say what things are, logically, not how they look. You also don't need to slap tons of classes on every element because you have CSS selectors.
If you do it that way, your markup becomes simple, elegant, easy to understand, and easy to re-style for different layouts. Also, less work.
That's what actually using CSS brought to the table, and that's what really understanding CSS means - it's just that so many people can't get their head out of the 1990s and insist on the bad old way of working. Astonishingly, even people who weren't even born back then. -
@Fast-Nop in reality you end up with tailwind css and that is moving style to class
-
@vane CSS frameworks are born out of complete failure to understand how HTML and CSS even work. All of them. Littering the markup with presentational classes is basically refusing to actually use CSS at all.
Plus that they don't bring anything to the table, quite the opposite. You now have to deal with tons of cryptic classes and bloat the markup - which usually isn't cached, so you make the website slower as well.
The only even worse crap is to inline "critical" CSS in the markup, which also isn't cached across page loads. Maybe if one didn't abuse 200k of useless CSS bloat to do what 20k could do, and also not pumping out 200k of bloated markup for what should be 10k, the external CSS being in the critical rendering path wouldn't be an issue in the first place. -
@Fast-Nop I started out as a FE and I think most FE devs are pretty apt at most of the need-to-knows. It’s a few bad apples that can spoil the crop.
Also, you make some really good points, but managing the styles for a large application AND keeping the result bundle size small is one of the most difficult problems when writing CSS. Especially when you have bad apples that can cause almost permanent setbacks. Preprocessors attempt to fix the modularization aspect, but typically it always ends up as a fat bundle. That leads to the critical CSS optimization improving performance metrics unfortunately. It’s just the natural order of things for a lot of these massive sites. The main thing I try to preach now is the CUBE CSS methodology. It tries to leverage the cascade as much as possible to declare as many generic styles as possible. It’s def worth a lookup. -
@vane you are very wrong for all the reasons @Fast-Nop mentioned and more. You gotta keep the code DRY as possible and maintain an easy-to-understand style system. Did you also know that managing an understandable specificity in style rules is one of the toughest problems in writing CSS?!? Did you also know that adding inline style attributes to html create the highest specificity and their styles cannot be overridden by any external stylesheets?!? Unless you are using fucking “!important”?!? FUCK any developer that creates a third party app that uses these style attributes in their layout. You can use these style attributes to set CSS properties or something, but other than that don’t use them. You REALLY need to catch up and do your research man.
-
@shovethisrant I don't think that even a large website should need more than 50k of CSS (minified, but not gzipped yet), and that's already generous.
The reason is that different pages should be structured and look similarly, already for branding reasons, but also because consistency is easier for the users.
What bloats up the CSS is when different teams work on different sections and make them look somewhat similar, but everyone reinvents the wheel for his section and then styles it to fake consistency that isn't actually there under the hood.
That's not a CSS issue, but a project management one. Which is also why preprocessors struggle to cope with that - solving social issues with tech means usually fails.
If more than 50k are needed despite strutural consistency, that's either due to use of a CSS framework (just don't), or because the website is way too complex, i.e. doing too many things that don't belong on a website anyway. -
@shovethisrant what I mean is you should be able to remove those and put it to css file during html /react you name it preprocessing. I don't say you should have websites with those just you should have tools that would transform style="foo:bar" to class="foo"
and create import foo.css that contains .foo { foo:bar } somewhere instead of keeping those in style. I don't understand why we don't have such tools.
And that's only first step.
Second step, this tool should create map of those styles and pick most optimized solution to use DRY and IDE should suggest you those styles during writing style="foo:bar" I should get suggestion that shows .foo { foo:bar } so I don't have to remember fucking gazilion names all the time just type css stuff and leave rest to computer. -
And no I am not wrong, the whole world is wrong trying to get me to know more and more fucking css frameworks instead of me writing css and computer do the magic and import framework for me.
I don't want to fukcing chose between bootstrap, tailwind, fucking shit fuck awesome bullshit. I want to write style to the button once and use magic that would apply it to every button and I fukcing can't so all websites look like made by fucking disney cause we fucking didn't make css fucking automation that would do the stuff for me. -
@vane But that is the point of writing semantic HTML - you just don't have tons of classes to throw around. Ideally, you don't need any class at all. Obviously, that is not reachable in practice once you go beyond toy sites, but it's still worth to remember that as ideal.
If you slap around tons of classes, and that slows you down, that's because you are writing presentational markup instead of semantic markup. That is exactly the old, laborious 1990s way of working that CSS was made to get rid of.
Your wish is akin to make that inefficient way a little more efficient instead of doing it like intended. -
@vane Here an example. That's all the markup you need for an example navigation menu. No classes needed, in particular not on each list item or link.
Why? Because the ul already has an id. You target that, and then use CSS selectors for the inner elements. That's how clean the markup can look. No confusing classes, no tons of typing.
-
@Fast-Nop I understand and I don't want to remember where I keep #mainmenu > li
like I don't want to remember where I keep my toilet paper. I just want robot to refill it. -
@vane How do you do that with other source code in, say, C++, when files grow too large? You probably have several different source files with reasonable names. You can always merge the split CSS files before the actual deployment.
The point is, you don't need to remember tons of classes because you don't have that, which is also why you don't need an IDE doing that for you.
Just like you don't need a horse carriage with 32 horses and complicated horse management system if you get to modern tech and use a car. -
@Fast-Nop yes but I would compare it to driving a limo and driving a car. Sure you can drive car yourself but what if you're drunk and you want just move this button 1px to the left.
I don't want to know what #mainmenu > li means. I just want to write css and then click button / type command and it remembers stuff in some reference cache like it remembers javascript in cache and then when I add style="padding-left:1px" to li it should add it to this little cache key and generate this part of style for me.
That's how cache works, there is no css cache preprocessor for style="" attribute that preprocess it for you and remove style from source code for you.
To compare it to c++ it would be #define style="some macro" - change it for me.
It doesn't have to be style attribute I want that macro preprocessor. -
@Fast-Nop well yeah bootstrap is ass we have established this. Sometimes people require you to use bootstrap and you don’t have a choice as a dev bc other devs with more of a say are morons. Also, yeah I mean you can say that complex apps and features don’t belong on a website, but they are there anyways, so might as well make it nice!
The whole idea of modern FE dev for web apps is to constantly leverage new tech while trying to include as little code as possible. It’s a balancing act, and I’m sure as you know, the more optimizations happen, the more hard it is to make more optimizations! Sometimes, it requires adding systems that add bundle size but improve maintainability and structure and vice versa. For instance, I’m sure you could write your own VueJs, but would your smaller-size version be easy to work with by other developers? It’s also hard to perfect things in a team setting and when clients want to save as much money as possible. -
@vane Then what you'd need are reusable components, and that's usually the job of the templating engine. You don't slap some style on every element, making stuff looking inconsistent on every page, you pull in some macro-like thing e.g. for a CTA button.
At that point, you don't care how a CTA button looks, only that you want one at that point. The styling is independent from that, maybe even by someone else, i.e. the one who works on the template.
What that should put into the markup wouldn't be a mess of styles and classes, but a button of class cta-button. You say what it is, not how it looks.
Otherwise, if you slap styles in your IDE on everything, how will you ever maintain that if the design changes?
You want CTA buttons in blue next month, not in green. Easy with class cta-button. Difficult with presentational classes since that needs changes everywhere, not just in the CSS.
OR! the Bootstrap way in practice, you define button-green as blue !important in the CSS. -
@shovethisrant And that's the thing: CSS frameworks don't save time and money, don't make things more maintainable. All they do is enabling exactly the bad old 1990s way of working that CSS was meant to get rid of.
I think it's more or less the bandwagon effect in action.
It's different with JS frameworks - at least, they address an actual problem. Having everything stored right in the DOM is OK for small projects, but as stuff gets more complex, that doesn't scale. You'd end up with mega condition handlers for every control instead of routers. -
@Fast-Nop yeah I’d definitely agree. I think yeah the only way to optimize CSS is to remove any third party or framework stylesheet reliance whatsoever. Bandwagoning in FE is 100% a big problem lol
-
@Slow-Yep True for CSS frameworks, they shouldn't exist.
Different for JS frameworks if and only if used for building a complex web app because state management becomes a nightmare - remember the jQuery spaghetti before that? jQuery is superfluous now, but the spaghetti in Vanilla JS would be the same.
What you need on architectural level is a star topology, that's how you prevent a spider web non-architecture. However, a star needs a central point, and that's what JS frameworks achieve. A sane Vanilla JS architecture would effectively also turn into a self-rolled framework, but worse in terms of maturity and available developer resources on the job market.
However, the question is whether one even needs a web app. There is no reason why a shop or a blog should be a complex SPA. -
@vane im basically a code dinosaur and im shit with formatting... but even I know how much better it is to use css, as it was intended, versus style tags in markup.
With html structured well(basic shit like your h1-h6/p tags consistent and correctly identified divs and nav) it's WAY easier to maintain. Its the difference between editing piles of html files or just changing a page or 2 of css. It even makes it simple to test out multiple themes, colour schemes, etc. , without having piles of html to wade through.
I like shit like php in notepad.exe... people have called me a masochist for that... using style tags instead of actual css is way more masochistic imo
In my experience, any BE dev or old architect/lead programmer that says they “can do frontend” does shit like writing Ajax calls in script tags directly in the html. They are the ones who add style attributes directly in html. They are the ones who google how to center a div and they still use float positioning because all of them are old, arrogant BE devs who get caught in a single framework who convince themselves they are an expert. They can’t give any good UX advice. They don’t know how to use a screen reader. They don’t know what WCAG means. They don’t constantly keep up to date on what browsers are supporting and what’s being released in the unstable versions. They don’t know what a web component is. They don’t know what a closure is. They don’t know anything about optimizing web perf metrics. They couldn’t tell you what web crawlers look for. They couldn’t tell you anything about design principles and anti-patterns. They don’t know how to manage a web application that will be seen by millions AND keep it nice, shiny, and refactorable on the code side. What do they really fucking know? how to write an MVC app? How to connect APIs and integrate code that other people wrote? I do full stack all day and writing anything not-client-facing is super easy.
Take that stick out of your ass and get over yourself you asshole. You haven’t written anything close to amazing even though you constantly act like you’re a god-tier programmer and your shit doesn’t stink.
Hit the books like the rest of us you fuck.
The Frontend is anything but fucking easy.
rant