Curious what you dislike about Gulp? I keep hearing people poo-poo it and say that it's "totally uncool now", but I can't understand anyone's frustrations with it, especially compared to other build tools.
If you're familiar with the jdk ecosystem, I can make an analogy: webpack is to SBT as gulp is to gradle as brunch is to maven. Their styles essentially boil down to different philosophies (code-is-config, build-is-code, and declarative-config respectively).
Gulp takes the philosophy that build is code. You hand code all of your pipelines. That's works perfectly fine for simple applications where all you're doing is writing code in a single language (like say just javascript for a node backend), but I've found that it is an unadulterated nightmare trying to get things to work across types of files, as is required by front end development. Your HTML, Javascript, and CSS interact with each other in several different ways, and things no longer fit into a neat pipelines abstraction...it resembles a graph more than anything. Throw in transpilers or compilers, parallel processing pipelines (like for sourcemaps), and it quickly becomes buggy chaos.
I maintain that the best abstraction for a build system is that found in Make. Make is actually brilliant in some respects...it is a language for declaratively building a data flow between processing pipelines, but allowing you to use a Bash-ish imperative style to build those pipelines. The problems of Make are many: not everything uses files as inputs or outputs, not everything has a 1:1 input-output ratio, dynamically selecting inputs or naming outputs is horrendously buggy, etc.. But the concept and philosophy behind it are brilliant. If there is any build system of the future, it will be borrowing heavily from Make.
I don't think I understand how HTML, CSS, and Javascript interaction makes Gulp development complicated. My CSS files are totally separate from my HTML/javascript, and are just included directly in my index.html. I use JSX with React to do inline HTML markup inside my .js files, which Babel handles just fine through its transform-react-jsx plugin, included easily in a one-line command in my Gulpfile which is just a very simple "babel" function call configurable via a regular .babelrc file.
Basically, I have yet to hit any limitations with the "build-is-code" philosophy, despite years of people telling me it's an awful and horrible thing to do. I can't forsee my <75 line Gulpfile growing too much, as the plugin ecosystem is robust and I already have all the features I could possibly want.
For reference, here is my simple Gulp setup. Each line is easily readable and explainable to anyone who knows basic Javascript (and a single Node.js primitive called "pipe").
As I asked another commentor: If you can point me to a clear tutorial on Make that lets me do all the things this Gulpfile does with extreme ease, I'll abandon Gulp and use Make exclusively for all front-end projects.
Probably you're finding it simple because your Gulp build script does nothing more than defer to Rollup - a module bundler like Webpack - to handle JavaScript bundling. You're literally just using Gulp to watch the file system and kick off either cssimport or Rollup on changes, which you barely even need Gulp to do.
Plus there's no incremental building - all CSS or JS is rebuilt on every save, your server doesn't build the project when it starts and it can't do things like hot module replacement or CSS injection - the latter of which BrowerSync can do.
I'm guessing you're using this on your smaller personal projects, where doing a complete rebuild on every save is fast enough not to be an issue, and reloading the page on every change won't be a pain when experimenting with new features or debugging complicated UI issues.
