Long time front end developer here. In the last couple of years I can't recall seeing even a single project without a build pipeline (not that they don't exist, I just haven't encountered them at my day job, first or third party).
For anything remotely important, you're almost certainly going to already want a build pipeline to do things like concatenating/minifying code, running tests, and deploying. Adding a transpilation step to extend support to older browsers comes with almost no cost to time or maintainability, assuming you're using well-supported things like Babel and its official plugins.
I've talked with frontend devs who only worked on projects with build steps about this and they often seem perplexed and surprised by just how simple it can be if you don't make it complex.
It's nice and simple for small projects but let's not act like putting a script tag in HTML is some divine wisdom that newbies don't understand.
They may be simple concepts, but there's definitely still an added cost with transpilation and minification steps.
If you work with Babel long enough you'll encounter scenarios where the transpiling didn't quite work as expected and breaks in-browser.
When you're debugging minified code in-browser using source maps, it's not all that uncommon to get different line numbers and stack traces than you get when loading up the original unminified source. I can recall a number of occasions where I had to deploy unminified source for in-browser debugging because the source maps were obfuscating the real error.
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
The payload to fill promises, regenerator and async are huge, and without them, my payload is significantly smaller. for preset-env...
{
loose: true,
modules: false,
useBuiltIns: 'usage',
corejs: 3,
targets: {
browsers: ['edge 15', 'safari 10.1', 'chrome 58', 'firefox 52', 'ios 10.3'],
},
exclude: ['transform-async-to-generator', 'transform-regenerator'],
},
try {
eval('(function() { async _ => _; })();');
if (typeof fetch === 'undefined') throw new Error('no fetch');
} catch (e) {
window.location.replace('/auth/legacy.html');
}
We don't have one at my work (Fortune 100 company), but it has nothing to do with whether it is appealing or not. It has to do with the projects we are working on started years before there was any such thing as a build pipeline in the web world and it's not pragmatic to add one in at this point. Maybe some decade we will get the budget to start over from scratch (haha!) and get modern things like a build pipeline.
While less of a consideration for established teams, it dramatically raises the barrier to entry for those who are learning as well as those who currently have much simpler requirements. Those are the future members of that established team. Adding hurdles to the process of learning will, in the long run, result in a smaller, more homogeneous pool of experienced developers to draw upon. It's a self-perpetuating cycle - making folks learn by using complex build scripts will result in experienced developers who then create further complexity because they've self-selected to be those who happen to think in that mode.
That's not intended to suggest that progress is bad. Rather that it's a bit short-sighted of us, as an industry, not to consider the ramifications of enforcing a workflow that happens to be trivial from the limited perspective of long time front end developers.
{ Edit to try to make the last paragraph sound less accusatory. Sorry! That wasn't my intention. }
The syntactic sugar that we're adding to make our own jobs easier is arguably making things disproportionately more difficult for anyone who doesn't already have the same baseline level of knowledge. That includes those who are trying to learn to do our jobs after we've all moved on. That would notably have also included all of us, earlier in our careers.
I'm just suggesting that it's worth considering whether that seems sustainable in the long run.
[1] ... for relatively simple tasks. Complex tooling happens to be a very good tool for complex tasks, like the sort of professional work that you seem to be referring to. No matter how good our hammer may be, however, not every task always wants to be a nail. create-react-app and parcel are examples of excellent hammers.
I ended up adding Parcel for easy Typescript support.