I'm quite surprised by the number of comments on Sass/CSS pre-processors being of little to no value while we have created a huge complicated Frankenstein mess with webpack/React and the rest.
I don’t work in a tech-focused business, because I work in the public sector. That means our funding is fairly limited, even though 90% of our workforce spends 5-8 hours a day on some for of smart device or pc. Because we’re limited, however, we need to be careful about how we spend our resources, and that means we simply can’t keep up with the modern frontend environment.
If all you do is angular, then the transition from AngularJS to angular 2 might have been smooth, but it sure wasn’t for us, and neither would the big react-versions be.
We also can’t really take advantage of the package/library environment because we’re not as fault tolerant as others. We can’t have security issues, but we also can’t code-review 70 packages/libraries every week because there was an update.
As a result we’re back to using the old MVC frameworks that don’t change every day and have solid standard libraries. We did buy a frontend “platform” so we can have things like editable grids without constant page-reloads, but in general, JS is something we add to a specific component only if it’s absolutely necessary.
I am looking forward to when Flutter finally has the ability to build websites. Because then we’ll have both mobile platforms, web and desktop frontends covered in one tool. Which is frankly exactly what we need to be productive in 2019, that or we’d need to hire 2-3 people, and the latter is just not happening.
Not like C/C++ programs, where we have a super simple setup of Make, config, and autoconf. Like checkout this easy-peasy Make file: https://github.com/apache/httpd/blob/trunk/Makefile.in . Even a child could understand it.
Or look at Java. Who has ever seen a complicated ant or pom file? No one ever. This Lucene ant file practically wrote itself: https://github.com/apache/lucene-solr/blob/master/lucene/bui...
/s
I guess my snarky point is that build systems are complicated. It's like the Bjarne Stroustrup about programming languages. There are two kinds of build systems: the ones people complain about the ones no body uses. Robust build systems have to handle the nearly endless combinations of different requirements each app brings to the table...complexity is table stakes.
Modern web apps are built to be able to run on a myriad of different platforms, as they have to maintain compatibility between tons of version of several different browsers running on a slew of different device types running different operating systems. Did we think that was going to be easy?
People like to shit on webpack, but I don't get it. It's a well thought out tool that works extremely well.
And what are the alternatives? Yes, yes, yes, I know, your blog/website/thing you have is just plain ol' html and and you stick some javascript in a script tag or whatever. No need for any of these fancy build scripts, blah, blah. So what? That's like telling the people at lucene that all this arcane index stuff is overkill because you just search your hard drive using ripgrep.
You can't make a real app like Slack, Spotify, VS Code, or Google Docs without a serious build process. People are making photoshop, for the browser. They're not going to do it with ES3 they write directly into a script tag.
The problem isn't that webpack is bad but too many projects use it where there's not need for it. Also for newcomers to the js world it looks terrifyingly complicated. Sure those bootcamp rookies eventually discover how terrible C++ buils are but who cares since this is more like comparing a spoon with a shovel.
Well, I feel that bit of nuance gets lost most of the time. It’s usually just simplified to “all these JS tools are a mess.”
It’s like if people all started complaining that rust is bad because they saw someone write a rust program when that person should have just written a bash script.
Is it considered bad practice now? How did it rise so quickly, how did it fall so quickly, what's going on in the web dev world?
Some novel things like a primaryColor variable to easily adust your theme is easily replicated with a traditional find/replace.
The fewer frameworks / compiles-to X languages you have to learn the better.
IMO, a little redundancy is better than a little complexity or a little dependency.
The original reason I switched was for nested structures so I could stop repeating myself. E.g.
div {
&:hover {}
.class ul {}This made it much more pleasant to write in sass.
The other thing is mixins. If vanilla css doesn’t support this then it’s still a no-go.
Lastly I’m confused why sass of all things is an issue. It’s basically css, and very lightweight. You just add one step in your preferred build tool to transpile sass -> css. “vanilla is magically better” is not an argument.
CSS now has variables (if you really need them -- chances are you don't).
The redundancy of writing a selector multiple times is sightly annoying, but I don't think it rises to the level of value I need to include a new dependency in my app or build pipeline.
[0]: https://css-tricks.com/custom-user-mixins/
These are preferable because you can compose them as needed for elements, instead of having to make extra classes.
> CSS now has variables (if you really need them -- chances are you don't).
I fail to see how you could -not- need variables. Not many, mind you, but using none at all boggles the mind. For starters, DRY code is fairly fundamental. When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided".
It also helps with consistency for site theming/branding. You can define $primaryColor, $primaryHighlight, $secondaryColor, $textColor, $backgroundColor, etc, and reference these down the line instead of copy/pasting and getting bugs if the specs change.
Isn't that the point of selecting classes in the first place? That said, I understand the utility in using it for things like individual colors, as you described.
Any self respecting programmer will find this "solution" abhorrent and inelegant.
There's a trend to throw a library at the problem, but that comes at a cost.