5 ms·

Great ideas. It seems like this sort of 'sane defaults' functionality could easily be added to future versions of webpack, and that might really help with adop

Great ideas. It seems like this sort of 'sane defaults' functionality could easily be added to future versions of webpack, and that might really help with adoption... rather than this community endlessly switching tool chains.

alexlrobertson 9y ago
I'm surprised we haven't seen config packages for webpack take off along the lines of the configs in the ESLint community. There's nothing stopping anyone from publishing an extensible base config.
- shados 9y ago
  I was under the impression that was the idea behind the new webpack cli (though I haven't tried it). The main issue is generally that there isn't much of a consensus on toolchain. Are you using vanilla ES6 or TypeScript? If the former, are you sticking to the standard or using class properties and object spread? Are you also adding non-stage3 crap like bind operator and decorators? For CSS, are you using styled components or Sass? Maybe you're using PostCSS? If so, with which plugins? Are you doing codesplitting? If so, how? Are you using a DLL plugin for your vendor stuff? Oh, and how would you like to handle far future caching? For a trivial app there probably can be a default, but unlike something like ESLint, any app that plans on living more than a little bit needs to answer all these questions and the answer is not obvious. Generally you could stick with some defaults that represent a majority opinion, but right now its so close to 50/50, it's hard. Still could be done though.
- antjanus 9y ago
  There IS an abstraction on top of Webpack called "terse webpack": https://github.com/ericclemmons/terse-webpack https://github.com/ericclemmons/terse-webpack It seems to have presets for sane defaults on the roadmap.
  - ericclemmons 9y ago
    I'm redoing that whole stack, as it was a prototype to get buy-in to "fix" the Webpack API for most cases. For an eslint-style plugin system I'd recommend webpack-blocks.
ziggzagg 9y ago
I know this will get downvoted, but here I go anyway: Please stop reinventing the wheels. Just stick to one library/framework whatever crap they are. Why? Because your new shiny wheel will be as crap as the old one very soon. I am myself refusing learning new tools in javascript. I think I have spent enough time learning enough of them. I have a selected set of them, and I turn down projects which fall out of that set. Less money, but better mental health.
- jaequery 9y ago
  one thing i learned to accept with the web is just how fast a trend can change in this industry. after i invested time in knockout, then came angular. then once i invest in angular, then came react. then after investing time in react, then came vuejs. it seems to either be a systematic cycle of people wanting to always try new things or that the tools are infact getting better and better. and once a group of pack starts going off in one direction, its just a matter of time before everyone is on it. for better or worse, it seems hard to stop this type of movement. im not sure why this is tbh, because mastering your tools is a big part of becoming a 10x developer, where you are actually productively creating and not just looking up docs half the time. perhaps this type of fad may be mainly driven by beginning or jr devs who are still undecided on what they want to learn and just go with what seems to be the next cool thing to learn. but then again without this type of change, we might as well all be still coding in perl. it really sucks to throw away what you invested in for a year or more but its just something you have to accept as a dev and move on these days as a javascript developer.
  - shados 9y ago
    the FE world used to be anemic in term of options. Then came Ajax, stronger web standards and eventually ES6, HTML5, etc. So that was a period of transition where finally all of the stuff the rest of world had was within our reach. But since we were starting (almost) from scratch, we had a chance to make it better. However, to do that, we had to experiment (and fail a lot). Thats where you saw all these tools as people iterated on it. It slowed down a lot now, and a lot of concepts bubbled up on top and we're down to only a couple of mainstream options (there's a lot of more obscure ones, but that's true in JVM/backend land too, and that's been around for a while).

alexlrobertson 9y ago

I'm surprised we haven't seen config packages for webpack take off along the lines of the configs in the ESLint community. There's nothing stopping anyone from publishing an extensible base config.

shados 9y ago
I was under the impression that was the idea behind the new webpack cli (though I haven't tried it). The main issue is generally that there isn't much of a consensus on toolchain. Are you using vanilla ES6 or TypeScript? If the former, are you sticking to the standard or using class properties and object spread? Are you also adding non-stage3 crap like bind operator and decorators? For CSS, are you using styled components or Sass? Maybe you're using PostCSS? If so, with which plugins? Are you doing codesplitting? If so, how? Are you using a DLL plugin for your vendor stuff? Oh, and how would you like to handle far future caching? For a trivial app there probably can be a default, but unlike something like ESLint, any app that plans on living more than a little bit needs to answer all these questions and the answer is not obvious. Generally you could stick with some defaults that represent a majority opinion, but right now its so close to 50/50, it's hard. Still could be done though.
antjanus 9y ago
There IS an abstraction on top of Webpack called "terse webpack": https://github.com/ericclemmons/terse-webpack https://github.com/ericclemmons/terse-webpack It seems to have presets for sane defaults on the roadmap.
- ericclemmons 9y ago
  I'm redoing that whole stack, as it was a prototype to get buy-in to "fix" the Webpack API for most cases. For an eslint-style plugin system I'd recommend webpack-blocks.

ziggzagg 9y ago

I know this will get downvoted, but here I go anyway: Please stop reinventing the wheels. Just stick to one library/framework whatever crap they are. Why? Because your new shiny wheel will be as crap as the old one very soon. I am myself refusing learning new tools in javascript. I think I have spent enough time learning enough of them. I have a selected set of them, and I turn down projects which fall out of that set. Less money, but better mental health.

jaequery 9y ago
one thing i learned to accept with the web is just how fast a trend can change in this industry. after i invested time in knockout, then came angular. then once i invest in angular, then came react. then after investing time in react, then came vuejs. it seems to either be a systematic cycle of people wanting to always try new things or that the tools are infact getting better and better. and once a group of pack starts going off in one direction, its just a matter of time before everyone is on it. for better or worse, it seems hard to stop this type of movement. im not sure why this is tbh, because mastering your tools is a big part of becoming a 10x developer, where you are actually productively creating and not just looking up docs half the time. perhaps this type of fad may be mainly driven by beginning or jr devs who are still undecided on what they want to learn and just go with what seems to be the next cool thing to learn. but then again without this type of change, we might as well all be still coding in perl. it really sucks to throw away what you invested in for a year or more but its just something you have to accept as a dev and move on these days as a javascript developer.
- shados 9y ago
  the FE world used to be anemic in term of options. Then came Ajax, stronger web standards and eventually ES6, HTML5, etc. So that was a period of transition where finally all of the stuff the rest of world had was within our reach. But since we were starting (almost) from scratch, we had a chance to make it better. However, to do that, we had to experiment (and fail a lot). Thats where you saw all these tools as people iterated on it. It slowed down a lot now, and a lot of concepts bubbled up on top and we're down to only a couple of mainstream options (there's a lot of more obscure ones, but that's true in JVM/backend land too, and that's been around for a while).