4 ms·

I don't understand what is so appealing about not having a build pipeline for JavaScript, other than the ability to very quickly test and learn things directly

by baddox 7y ago

I don't understand what is so appealing about not having a build pipeline for JavaScript, other than the ability to very quickly test and learn things directly in the browser, which of course anyone can still do. 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.

thothamon 7y ago
I have no concerns about having a build pipeline per se. My concern is that it's still way too complex and difficult. I think it could be made to be much simpler for 90 percent of cases, while still maintaining optional complexity for the remaining 10 percent of cases that need it.
EB66 7y ago
> Adding a transpilation step to extend support to older browsers comes with almost no cost to time or maintainability 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-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
irrational 7y ago
>I don't understand what is so appealing about not having a build pipeline for JavaScript 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.
SahAssar 7y ago
The appealing thing about not having a build pipeline is not having it. Not having another thing to maintain and update/upgrade/debug. I've gone through grunt, gulp, webpack and parcel. Somewhere along the way I realized that with es6 imports and css variables I don't really need it. 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.
- korm 7y ago
  Can you imagine a modern SoundCloud, Spotify, Facebook, Airbnb or Slack without a build pipeline? There's nothing appealing about that. 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.
  - SahAssar 7y ago
    Yes I can. All of those except for facebook (because facebook is a sprawling platform) seem reasonable to be able to build without a build system. And with using es6 modules it's not "putting a script tag in HTML", you have a proper module loading system without needing any builds or libs. I'm not saying it's some sort of lost knowledge like Damascus steel, I'm just saying that many people these days are so caught up into the current dogma of JS that they never consider a simpler but still modern path.
tracker1 7y ago
I'm using Webpack + Babel... but literally only for features after async/await. All major, current browsers support it. That's the baseline support for the apps I'm working on now. 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'], }, from here, I only need the features not part of stage 4 that I want to add. I have the following in a test script... try { eval('(function() { async _ => _; })();'); if (typeof fetch === 'undefined') throw new Error('no fetch'); } catch (e) { window.location.replace('/auth/legacy.html'); } With async functions, and fetch api available, you get a LOT in the box.

by baddox 7y ago

thothamon 7y ago

I have no concerns about having a build pipeline per se. My concern is that it's still way too complex and difficult. I think it could be made to be much simpler for 90 percent of cases, while still maintaining optional complexity for the remaining 10 percent of cases that need it.

EB66 7y ago

> Adding a transpilation step to extend support to older browsers comes with almost no cost to time or maintainability 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-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

irrational 7y ago

>I don't understand what is so appealing about not having a build pipeline for JavaScript 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.

SahAssar 7y ago

The appealing thing about not having a build pipeline is not having it. Not having another thing to maintain and update/upgrade/debug. I've gone through grunt, gulp, webpack and parcel. Somewhere along the way I realized that with es6 imports and css variables I don't really need it. 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.

korm 7y ago
Can you imagine a modern SoundCloud, Spotify, Facebook, Airbnb or Slack without a build pipeline? There's nothing appealing about that. 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.
- SahAssar 7y ago
  Yes I can. All of those except for facebook (because facebook is a sprawling platform) seem reasonable to be able to build without a build system. And with using es6 modules it's not "putting a script tag in HTML", you have a proper module loading system without needing any builds or libs. I'm not saying it's some sort of lost knowledge like Damascus steel, I'm just saying that many people these days are so caught up into the current dogma of JS that they never consider a simpler but still modern path.

tracker1 7y ago

I'm using Webpack + Babel... but literally only for features after async/await. All major, current browsers support it. That's the baseline support for the apps I'm working on now. 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'], }, from here, I only need the features not part of stage 4 that I want to add. I have the following in a test script... try { eval('(function() { async _ => _; })();'); if (typeof fetch === 'undefined') throw new Error('no fetch'); } catch (e) { window.location.replace('/auth/legacy.html'); } With async functions, and fetch api available, you get a LOT in the box.