No one would argue that complexity for the sake of it is a good idea.
Yet somehow we've convinced ourselves that frontend development now requires package managers, compilers, CSS test cases, CSS frameworks, etc.
Sure there are web-based apps with a rich functionality that require some of these things, but the vast majority of pages that I see out there are just as simple as they were five years ago.
In the case of some front-end tools, they are an absolute must.
When your CSS compiler takes care of all the stupid -webkit-/-moz-/... prefixes, allow you to define variables, mixins, use loops, you gain a great amount of power and your code is a lot cleaner.
When your build system integrates with livereload and make your changes appear instantly as you save, you gain speed and comfort.
That's major benefits for little to no inconvenience.
I don't know about the necessity of CSS frameworks, styleguides or package managers, but some tools are just too good.
It's not about the end result, it's about using better tools to get to it.
After gaining a fair amount of experience with various technologies over the years (by which I mean, getting burned (especially by things that seem wonderful and then cease to exist for a variety of reasons)), that has become the single most important question I ask about a new technology. If it's been around for ten years, it'll probably still be around in ten years. If it hasn't then it may not, especially in a form recognizable as related to today's.
C and Java are, well, not horrible, but bad. However, C has been C for my entire career. And I'm fairly sure that if I write something in simple, plain Java, in five or ten years when it needs some significant work then that work won't start with a complete rewrite.
I don't understand this: with open-source, it doesn't matter that your CSS compiler has been abandoned: as long as you are satisfied with the current feature set, the code isn't going to disappear.
Stylus is only about 3.5 years old. But if all development were to stop now, I'll still be able to use it 5 years down the road. It probably helps that npm dependencies are pinned to a specific version.
C has been around for dozens of years, but you can consider its feature-set pretty much frozen. That's about the same thing as being satisfied with (CSS compiler X)'s feature set and sticking with it.
DSLs like the ones for CSS compilers are feature-complete fast enough. You don't need to wait 10 years for it.
I was merely using the CSS compiler as an example. For something like that, just put a copy in your source repository and forget about it---it'll be fine for a couple of generations of browsers, until the "best current practices" have gone beyond deprecation.
I'm sitting here looking at a JRuby on Rails application using JRuby 1.1.4 and a suitably ancient version of Rails (2.2, maybe?). It's been in production for roughly five years and has received essentially no love during that period; it Just Worked[TM]. The poor sod who was responsible for it and our one other Rails application, our one and only Rails developer, finally managed to move on to other things.
At this point, security issues and (most likely) the inability to slather on new features have percolated up the chain of command and it has been agreed that Something Must Be Done. Since the upgrade path seems to recapitulate the phylogeny of Rails, our options seem to be to rewrite the applications in a modern Rails and kick the can down the street, hoping it'll work better this time, or rewrite it using our common tools around here (and because I've got something to do with it, in the simplest manner possible). (And against the usual "never rewrite anything, ever" meme---which isn't an option---it's going reasonably well.)
As for C, yes, it's feature set has been more-or-less frozen, which is good. It's environment is not. I was reasonably happy with the first version of gcc I used; call it 1.37 or so. Do you think you could use gcc 1.37 today?
You don't need a build system during development. I work on a 500.000 line web app, and it has no dev time build step. You check out the source into your web root, and run the app. Edit + f5 is fast enough, no need for smart build systems. Build steps are ofcourse inevitable for the jump into production.
If you're satisfied with pure CSS and Javascript, the only thing you really need is a build tool for concatenation, minification and gzip. And livereload. And probably normalize.css.
-> I use a Makefile, because it's the most simple to modify and adapt. When I have several targets of the same type (ex: build.min.js and debug.min.js), I use a yaml file with a custom python script for concatenation. See gulp.js and a thousand others for alternatives, YMMV (my Makefile nowadays: https://gist.github.com/idlewan/11012492). Magical bit for running make every time a file changes:
watch:
@inotifywait -m --exclude ".*\.swp|.*~" -e moved_to,close_write -r . | \
while read; do make -s; done
To get more from just CSS, you need a CSS precompiler.
-> I use Stylus with the nib library (https://github.com/visionmedia/nib). Alternatives: LESS, SASS, and some others. You might want to add some grid and 'responsive shortcut' mixins on top.
For webapp needs, you need a template library (some people prefer using a fat framework that does everything for them, e.g. Angular).
-> I use Jade (https://github.com/visionmedia/jade), because it runs on the server for Python, Node.js and soon Nimrod, and on the client with precompiled templates. Alternatives: Mustache and a thousand others, YMMV.
Yet somehow we've convinced ourselves that frontend development now requires package managers, compilers, CSS test cases, CSS frameworks, etc.
Sure there are web-based apps with a rich functionality that require some of these things, but the vast majority of pages that I see out there are just as simple as they were five years ago.