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.
Well some of us think webpack/react and the rest are even worse and that a page-reload never killed anyone.
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.
As a front-end developer it sounds just like the perfect job for me. I'm so tired of fighting the infrastructure and tooling instead of doing real work that I wish I could go back in time to work in simple MVC project. I don't really care if it's Rails, Django, PHP, .NET or Java. On my previous 4 jobs I wrote SPAs for products that weren't supposed to be a SPA. I wonder if there are still interesting products being built with these 'old' tech. Where I live certainly there isn't.
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.
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.
> People like to shit on webpack, but I don't get it. It's a well thought out tool that works extremely well.
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.
> The problem isn't that webpack is bad but too many projects use it where there's not need for it.
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.
I am quite surprised at how the wheels have turned. I remember a year ago I was interviewing people and each single candidate listed SASS as a skill, and almost everyone during the interview claimed its their preferred method of working. (my team so far has been using plain css and are happy with it, so that surprised me a lot back then).
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?
Sass and other CSS generators were useful a few years ago for rapid code generation. However, CSS has caught up as have editors and it's hard to see what real advantage Sass has today.
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.
Using a find and replace instead of a variable holder is extremely bad practice. I should not have to copy/paste my site’s brand colors every time.
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.
I used to write only in Sass for these same reasons, but switched back to CSS.
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.
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.
> 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".
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.
Sass is very much still useful today. Mixins, used sparsely, can be very powerful and avoid large doses of redundancy. Also variables with good names make the job a lot easier than communicating around hexvalues.
Variables alone are not a reason to use Sass anymore. There are CSS Custom Properties [1] now, which are even more powerful in that you can dynamically override them in specific sub-sections of the DOM. The only downside is that Internet Explorer 11 doesn't support them (if that's important for your target audience).
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.