9 ms·

Every time I start a new project, I try using latest webpack first. Result is always me getting frustrated and replacing it with simple `browserify` call with c

Every time I start a new project, I try using latest webpack first. Result is always me getting frustrated and replacing it with simple `browserify` call with couple of `--transform` flags. Recently I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config. `yarn start` kept linting something deep inside `node_modules`, and failing for some nefarious reason even after linting step was removed completely from everywhere I could reach. `build` command work fine, though, so go figure. Not sure if "magic comments" will solve my problem, but it surely is nice to have simple alternative, thanks substack and everyone behind browserify! https://github.com/substack/node-browserify https://github.com/substack/node-browserify

manigandham 9y ago
webpack is just more complicated, which means it takes longer to start - it also has some bad naming and quirks which happens when design-by-committee decisions take place. the webpack book by survivejs takes a few hours to read completely, or an hour to read the important parts, and you'll be very comfortable with it. https://leanpub.com/survivejs-webpack https://leanpub.com/survivejs-webpack or https://survivejs.com/webpack/preface/ https://survivejs.com/webpack/preface/
- daviddumon 9y ago
  I second this recommandation. This book was really a good help setting up webpack for the first time.
- teknologist 9y ago
  It's so horrendously complex. I can already sense the "you-dont-need-webpack" wiki page being made by some pissed off developer out there!
  - mkohlmyr 9y ago
    It really is. Back when I was trying to get excited about learning yet another way to bundle things (YAWTBT(TM)) I attended two tech talks that concerned webpack. I really wanted to 'get it'. I left the second one having decided to never touch it again if avoidable. The first was by a developer who had recently moved a sizable codebase to webpack. He had pages after pages of graphs of how he had tuned webpacks code splitting capabilities. The end result of all this work was actually a larger sum of file sizes - and a slower loading speed. But I guess those days / weeks of tuning shave off a few kB when they deploy minor changes. The second talk was by one of the primary maintainers of webpack. It was completely incoherent. It was a jumble of things that "can be done with webpack" - not one good reason why. E.g. "You can extract CSS from your javascript files with this plugin" - what genius came up with the idea of inlining styles in a javascript bundle to begin with?
    - deleted 9y ago
      [deleted]
    - fenomas 9y ago
      > what genius came up with the idea of inlining styles in a javascript bundle to begin with? I do this in a project and it's terrific. The JS files in question are front-end components (for Vue.js in my case), and the point of having the styles inline is so that components can be a single file, styles can be prefixed to be local to that component, and so on. It's light-years easier to work with than trying to do something similar without a module bundler.
      - nobleach 9y ago
        Because there are instances where one doesn't want to block rendering with large CSS file downloads? For above the fold content, inlining makes perfect sense.
    - teknologist 9y ago
      > what genius came up with the idea of inlining styles in a javascript bundle to begin with? All these, I guess... https://github.com/MicheleBertoli/css-in-js#features https://github.com/MicheleBertoli/css-in-js#features
- bicubic 9y ago
  > the webpack book Holy shit, I thought you were kidding. We're at a point where the bundler, one of a dozen elements required for a 'barebones' modern js application, needs a book. I'm finding it hard to find motivation to do any kind of web based side projects these days because they inevitably begin with 'which combination of latest and greatest libraries do I need to spend an entire day wiring up before I can do hello world this time?'. Someone make this madness end. Modern javascript tooling makes 90s C++ look pretty pleasant.
  - baystep 9y ago
    Have you ever tried Gulp? Honestly I had the same feeling with webpack, I like it for my "professional" day job project that's grown to huge size and webpack can chop through it quickly; but for side projects, probably not. Then I found gulp. Uses a more functional streaming style, but for the end goal of [Turn ES6 into ES5]->[Stick it in this folder] it's dead simple and quick.
  - positivecomment 9y ago
    JavaScript is trying to get rid of the script! https://www.manning.com/books/java-development-with-ant https://www.manning.com/books/java-development-with-ant
  - Sacho 9y ago
    I think your hyperbole is unwarranted; if you're building a "hello world" application, you don't need to use a bundler, or any of the "latest and greatest libraries". Pick tools which you are comfortable with and which solve problems you actually have. Otherwise, you'll be left complaining about some vague "community" that is "forcing" you to adopt the "modern standard", even though there's nothing "standard" about the apps this "community" develops as a whole.
    - susw 9y ago
      Hello World is only your first test case to get all the tooling up and running. The real work starts after Hello World and is expected to become more complex. Within minutes you will grow tired of manually running transpilers, minifiers, tests, adding each new js module to index.html etc. You will want to automate all of this. At least this is my experience every time I start a new project.
teknologist 9y ago
Would you mind posting an example of such a browserify call for someone who isn't too familiar?
- elmigranto 9y ago
  Here's my Makefile, which includes all the configuration: react, babel, etc. (I do not have any dotfiles in root except for linter). `watch` recompiles on changes and has sourcemaps. You can require any node modules and calls to `fs.readFileSync` will be replaced with `Buffer` objects. NODE_MODULES=../../node_modules NODE_BINARIES=${NODE_MODULES}/.bin BABEL_PRESETS=--presets [ es2017 react ] BABEL_PLUGINS=--plugins [ transform-object-rest-spread ] FLAGS= \ --transform [ babelify ${BABEL_PLUGINS} ${BABEL_PRESETS} ] \ --transform brfs \ --outfile ../../public/bundle.js \ entrypoint.js build: ${NODE_BINARIES}/browserify ${FLAGS} watch: ${NODE_BINARIES}/watchify --debug --verbose ${FLAGS} What it doesn't have is any kind of automatic page reload or code swap and you can't `require` non-js files. There is also no minification for production build. I believe you can have those after couple of minutes on npm, but I haven't tried. Dependencies: yarn add --dev browserify watchify babelify babel-plugin-transform-object-rest-spread babel-preset-es2017 babel-preset-react brfs
  - Yaggo 9y ago
    For minification you can use e.g. uglifyify transform. Envify also comes in handy. I'm big fan of browserify & npm scripts, I love the simplicity.
just-boris 9y ago
> I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config I am pretty much confident that everything worked well before you have made any modifications in the webpack config. So, the negative effects, that you are describing after, is a result of your efforts, but not anybody else. And why did you want to eject in the first time? Most popular use-cases are already covered into create-react-app by default.

manigandham 9y ago

webpack is just more complicated, which means it takes longer to start - it also has some bad naming and quirks which happens when design-by-committee decisions take place. the webpack book by survivejs takes a few hours to read completely, or an hour to read the important parts, and you'll be very comfortable with it. https://leanpub.com/survivejs-webpack https://leanpub.com/survivejs-webpack or https://survivejs.com/webpack/preface/ https://survivejs.com/webpack/preface/

daviddumon 9y ago
I second this recommandation. This book was really a good help setting up webpack for the first time.
teknologist 9y ago
It's so horrendously complex. I can already sense the "you-dont-need-webpack" wiki page being made by some pissed off developer out there!
- mkohlmyr 9y ago
  It really is. Back when I was trying to get excited about learning yet another way to bundle things (YAWTBT(TM)) I attended two tech talks that concerned webpack. I really wanted to 'get it'. I left the second one having decided to never touch it again if avoidable. The first was by a developer who had recently moved a sizable codebase to webpack. He had pages after pages of graphs of how he had tuned webpacks code splitting capabilities. The end result of all this work was actually a larger sum of file sizes - and a slower loading speed. But I guess those days / weeks of tuning shave off a few kB when they deploy minor changes. The second talk was by one of the primary maintainers of webpack. It was completely incoherent. It was a jumble of things that "can be done with webpack" - not one good reason why. E.g. "You can extract CSS from your javascript files with this plugin" - what genius came up with the idea of inlining styles in a javascript bundle to begin with?
  - deleted 9y ago
    [deleted]
  - fenomas 9y ago
    > what genius came up with the idea of inlining styles in a javascript bundle to begin with? I do this in a project and it's terrific. The JS files in question are front-end components (for Vue.js in my case), and the point of having the styles inline is so that components can be a single file, styles can be prefixed to be local to that component, and so on. It's light-years easier to work with than trying to do something similar without a module bundler.
    - nobleach 9y ago
      Because there are instances where one doesn't want to block rendering with large CSS file downloads? For above the fold content, inlining makes perfect sense.
  - teknologist 9y ago
    > what genius came up with the idea of inlining styles in a javascript bundle to begin with? All these, I guess... https://github.com/MicheleBertoli/css-in-js#features https://github.com/MicheleBertoli/css-in-js#features
bicubic 9y ago
> the webpack book Holy shit, I thought you were kidding. We're at a point where the bundler, one of a dozen elements required for a 'barebones' modern js application, needs a book. I'm finding it hard to find motivation to do any kind of web based side projects these days because they inevitably begin with 'which combination of latest and greatest libraries do I need to spend an entire day wiring up before I can do hello world this time?'. Someone make this madness end. Modern javascript tooling makes 90s C++ look pretty pleasant.
- baystep 9y ago
  Have you ever tried Gulp? Honestly I had the same feeling with webpack, I like it for my "professional" day job project that's grown to huge size and webpack can chop through it quickly; but for side projects, probably not. Then I found gulp. Uses a more functional streaming style, but for the end goal of [Turn ES6 into ES5]->[Stick it in this folder] it's dead simple and quick.
- positivecomment 9y ago
  JavaScript is trying to get rid of the script! https://www.manning.com/books/java-development-with-ant https://www.manning.com/books/java-development-with-ant
- Sacho 9y ago
  I think your hyperbole is unwarranted; if you're building a "hello world" application, you don't need to use a bundler, or any of the "latest and greatest libraries". Pick tools which you are comfortable with and which solve problems you actually have. Otherwise, you'll be left complaining about some vague "community" that is "forcing" you to adopt the "modern standard", even though there's nothing "standard" about the apps this "community" develops as a whole.
  - susw 9y ago
    Hello World is only your first test case to get all the tooling up and running. The real work starts after Hello World and is expected to become more complex. Within minutes you will grow tired of manually running transpilers, minifiers, tests, adding each new js module to index.html etc. You will want to automate all of this. At least this is my experience every time I start a new project.

teknologist 9y ago

Would you mind posting an example of such a browserify call for someone who isn't too familiar?

elmigranto 9y ago
Here's my Makefile, which includes all the configuration: react, babel, etc. (I do not have any dotfiles in root except for linter). `watch` recompiles on changes and has sourcemaps. You can require any node modules and calls to `fs.readFileSync` will be replaced with `Buffer` objects. NODE_MODULES=../../node_modules NODE_BINARIES=${NODE_MODULES}/.bin BABEL_PRESETS=--presets [ es2017 react ] BABEL_PLUGINS=--plugins [ transform-object-rest-spread ] FLAGS= \ --transform [ babelify ${BABEL_PLUGINS} ${BABEL_PRESETS} ] \ --transform brfs \ --outfile ../../public/bundle.js \ entrypoint.js build: ${NODE_BINARIES}/browserify ${FLAGS} watch: ${NODE_BINARIES}/watchify --debug --verbose ${FLAGS} What it doesn't have is any kind of automatic page reload or code swap and you can't `require` non-js files. There is also no minification for production build. I believe you can have those after couple of minutes on npm, but I haven't tried. Dependencies: yarn add --dev browserify watchify babelify babel-plugin-transform-object-rest-spread babel-preset-es2017 babel-preset-react brfs
- Yaggo 9y ago
  For minification you can use e.g. uglifyify transform. Envify also comes in handy. I'm big fan of browserify & npm scripts, I love the simplicity.

just-boris 9y ago

> I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config I am pretty much confident that everything worked well before you have made any modifications in the webpack config. So, the negative effects, that you are describing after, is a result of your efforts, but not anybody else. And why did you want to eject in the first time? Most popular use-cases are already covered into create-react-app by default.