12 ms·

Vue.js and Brunch: Webpack Alternative

147 points by sandGorgon 9y ago

dingle_thunk 9y ago
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).
mikewhy 9y ago
I loved Brunch back a few years ago. But I wasn't happy with how plugins worked, or their "all files get included in your bundle even if you never required them". So I built my own build system on top of Gulp, and added a set of tasks using browserify for web apps (https://github.com/BraveNewWorldDev/parched-example-app https://github.com/BraveNewWorldDev/parched-example-app). It's heavily "convention over configuration", like "npm install parched-babel" is all you need to get Babel integrated. I'm still using it in production on websites, Cordova apps, and Electron apps, but I'd still recommend webpack nowadays since that's where the community is.
- bfred_it 9y ago
  Oh boy I just finished moving my old gulp+browserify(+sass+postcss) config to webpack. It was a bunch of custom nonsense. In return I got a faster build, 20% lighter output and a lot more information (webpack shows size, etc)
timdorr 9y ago
Brunch has a good "vs Webpack" section in their docs: http://brunch.io/docs/why-brunch#brunch-vs-webpack http://brunch.io/docs/why-brunch#brunch-vs-webpack Some of the big table stakes features that Brunch is missing are code splitting and handling of binary assets (allowing things like image inlining). It also doesn't have true hot module reloading, which is a pretty useful dev feature.
- efdee 9y ago
  Code splitting seems like a major feature to miss out on. I assume/hope it will come to Brunch sooner rather than later.
- christilut 9y ago
  I can't live without hot module reloading anymore.. With my Vue projects (no idea if React does it like this too) I can update my code and it only reloads either CSS, JS or HTML and it completely maintains state. Textfields maintain their content while I edit their CSS, just great. Wasn't long ago that auto reload on file change was a fancy feature...
hhandoko 9y ago
I looked into Vue + Webpack vs Vue + Brunch on my last project. I ended up with Brunch because the requirements are fairly basic and Brunch are easier to grok. Had the requirements be a little bit more complex, I could have easily gone for Webpack. IMO, there are a few key things lacking with the Vue + Brunch combo: - The `vue-brunch` plugin seems to be no longer in active development? (https://github.com/theocodes/vue-brunch https://github.com/theocodes/vue-brunch) - The `sass-loader` plugin allows me to use Sass dialect in SFC-style Vue (Single File Component). I'm using plain CSS with Vue + Brunch SFC as I cannot find a Brunch plugin offering similar functionality. - There are some Brunch idiosyncracies. For one, the processing pipeline is executed as per `package.json` (dev)Dependencies ordering. I spent quite a bit of time before figuring this out.
aarondf 9y ago
I really love using Laravel Mix [1], which is a wrapper around webpack. I know nothing about webpack, because mix makes it easy to just get going on my actual project instead of futzing about with configuration. Edit: FYI, Laravel not required. 1. https://github.com/JeffreyWay/laravel-mix/tree/master/docs#readme https://github.com/JeffreyWay/laravel-mix/tree/master/docs#r...
- dabernathy89 9y ago
  Agreed - Laravel Mix makes it absurdly easy to get started with Webpack, while still getting a lot of power out of it. And you can use it in anything: a mostly server-side app (like a typical Laravel project, where Mix originated), a complex SPA, or even a WordPress theme (which I found myself doing over the weekend).
marcofatica 9y ago
not sure if i did something wrong, but i cloned the app and ran the build and there's over 7500 lines of boilerplate included before the 'main.js' import in public/app.js. what is going on?
hardwaresofton 9y ago
If you're looking for alternatives to Webpack, please also check out JSPM (a good short description might be "preprocessing system + package manager + systemjs"): https://jspm.io/ https://jspm.io/ It takes a little more to get it to work with vue (the plugin that makes .vue files work is older and unsupported nowadays), but I use it just fine, with my template, styling and component files separated (I wrote a little thing: https://gitlab.com/mrman/systemjs-plugin-vue-template-compiler#readme https://gitlab.com/mrman/systemjs-plugin-vue-template-compil...) If you dislike how complex webpack is, you'll like JSPM -- here's the video that got me hooked (it's pretty old but still valid): https://www.youtube.com/watch?v=iukBMY4apvI https://www.youtube.com/watch?v=iukBMY4apvI
- aweiland 9y ago
  Rollup looks pretty good too. It's on my list to play with. https://rollupjs.org/ https://rollupjs.org/
  - kevmo314 9y ago
    Rollup and webpack serve two somewhat different purposes: https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c https://medium.com/webpack/webpack-and-rollup-the-same-but-d...
  - akvadrako 9y ago
    Rollup looks like the future - one big plus is the output looks nearly hand crafted compared to the unreadable mess webpack shits out.
- jameshush 9y ago
  We used JSPM in production for a year and a half. We had to switch back to Webpack because JSPM's bundles (even with HTTP2 enabled) were slowing down our time to first render drastically. About an extra 2 seconds on 3g mobile compared to the same site with webpack. We're an edge case though, for most sites JSPM will work fine, and if it's currently working for you don't switch over. Switching over was a pain so I don't recommend switching unless you absolutely have to. I would not recommend using it for new projects though.
petepete 9y ago
I've been writing a Brunch/Vue.js app for the last few months and, for a relative newcomer to JavaScript frameworks, Brunch was far easier to get up and running with than Webpack. I spent a couple of days failing to get things working the way I wanted with Webpack and after discovering Brunch I was productive within half an hour. My `brunch-config.js` is about 30 lines long and everything works as I'd expect.
tkubacki 9y ago
When did Vue hype officially start ? It's funny to see how deeply HN crowd is driven by vouge.
- apocalyptic0n3 9y ago
  Depends on what community you are part of. Vue received a lot of hype within the PHP community (especially the Laravel community) shortly after it launched. I want to say early 2015 is when it started there.
- unvs 9y ago
  I thought it had more to do with all the noise lately around the React PATENTS, but I could be wrong
  - thegayngler 9y ago
    Yeah I think that is a concern for many people around building an app with React and friends. I've heard people complaining on this issue multiple times at work.
- jaequery 9y ago
  mainly its the react fatigue, thats finally tipping them over the edge to try something better. vue seems to have come in at the right time for that. and given the momentum, its possible that vue may supercede react at some point if this keeps up.
  - bartread 9y ago
    I'm getting pretty jaded with the JS ecosystem as a whole. I don't want to have to learn new (effectively throwaway) technologies every few months because, fundamentally, I'm interested in building valuable products, not in learning technologies as an end in itself. Or, in other words, I have better and more interesting things to do. Also, this endless churning is not how you develop expertise. The way things are at the moment you've just about learned to work with the quirks of one framework and then you have to pick up another one. It's completely ridiculous, especially when in a lot of cases the benefits of one technology over another similar technology are pretty marginal. I mean, come on: can you honestly say that Brunch is a quantum leap on from WebPack (or vice versa), or that WebPack is a quantum leap over Gulp (or, again, vice versa)? I don't think so. By contrast, you become an expert by sticking with things and developing deep understanding. I've therefore reached the point where I'm only interested in the browser APIs and JS libs that are proven, battle-tested, and have stable APIs. I don't want to waste time rewriting code that was working and is now broken just because the previous API version offended the aesthetic sensibilities of some capricious maintainer. (Sorry, I do tend to get quite grouchy about this stuff.)
thex10 9y ago
Similar to Brunch but more opinionated is Jus. http://jus.js.org/ http://jus.js.org/ I really enjoyed using it, but alas I wanted a different Markdown loader (theirs is based off Github markdown, which doesn't support footnotes), so I switched to Metalsmith. But Jus and Brunch and the like are great options.
pselbert 9y ago
Years ago when Phoenix was adding JS support I lobbied Chris McCord to go with Webpack. He took a lengthy look at the setup/configuration process for all of the popular build tools and ended up choosing Brunch. For most tasks it is a great choice, and an excellent default for a "batteries included" web framework.
jstewartmobile 9y ago
How long can we keep adding to the tower of javascript shitware before it falls over? Honestly I thought it would have fallen over a long time ago. Just looking at long chains of mystery-meat that npm imports, and the time it takes Babel to compile the simplest of projects make me just want to say the hell with it all and do everything as GET/POST.
- root_axis 9y ago
  So why don't you do everything as GET/POST?
  - jstewartmobile 9y ago
    Because I was dumb enough to try React when enough people said "Oh, this changes everything!" Whatever React gave, npm and Babel took right back.
    - root_axis 9y ago
      I'm not sure how trying things makes a person dumb. Either way, that doesn't answer the question of what is stopping you from using the tools you prefer rather than the ones you despise.
      - jstewartmobile 9y ago
        I still have to maintain the product, unless I want to go full CADT and re-do it in something else.
- VectorLock 9y ago
  I wonder the same thing myself. Occasionally I look into these frameworks to see if they really add anything to the development of complex web applications vs. the amount of work they take to integrate them and it always heavily seems like a waste of time.
  - 9y ago
TekMol 9y ago
Do you guys use any public websites that are based Vue, React or alike? Everytime I search for sites that use frameworks like Vue or React, I came up with mostly empty hands. Except for example pages or pages by coders for coders. Or pages that "use" one of the frameworks but seem to make no use at all of the functionality. When I ask around people usually tell me "Well, at my company we make a dashboard for another company and it's based on ..." Any popular public sites (Aka no login needed to access it. So Facebook doesn't count.) for non-coders out there that use these frameworks?
- Method-X 9y ago
  Here's a project I'm working on that uses react: https://edabit.com https://edabit.com
  - TekMol 9y ago
    Thanks! Tried it a bit and thought: "Hmm.. it's probably react that causes all these spinning "loaders" everytime I click somewhere. Wouldn't it be better without?". How do you see that? EDIT: Ups, why the downvotes? With spinning "loaders" I mean the "loading" animation the website shows. The spinning circle. Anything bad about this question?
    - JasonSage 9y ago
      > Anything bad about this question? You didn't ask a question, you jumped to a (wildly inaccurate) conclusion.
      - TekMol 9y ago
        In which sense inaccurate? If the server would just send a rendered page, why would a loading animation be needed?
        JasonSage 9y ago
        > it's probably react that causes all these spinning "loaders" everytime I click somewhere Statistically speaking it's _probably_ jQuery or pure JavaScript. These loading spinners have been around to make site loading more attractive for a long time, predating React, Vue, Ember, even Backbone. I have tons of clients on Wordpress that love this kind of thing even if all it does is make their site load without a flash of unstyled content (FOUC). > If the server would just send a rendered page React is primarily a client-side framework, but it's possible to render it on the server using Node. However, a lot of sites still use React to enhance an existing frontend, and therefore do not port their entire server to Node to render with React. > why would a loading animation be needed? Alright so lets assume you've server-rendered with React, do you still need a loading animation? Maybe. All these sites you click on that have loading spinners are all server-rendered pages too, but that doesn't stop people from throwing jQuery plugins at it to make their sites look fancy and prevent a FOUC. It's more a question of how many images the site wants to display above the fold. If there's a bunch of images, your site will not load fast and you can choose between letting users see a gappy page gradually get filled in or sit and look at a spinner for 1.5s. EDIT: not to mention all the advertising trackers these sites have enabled. This makes your image-loading all the more laggy.
Shorel 9y ago
Do we still need Webpack when all connections can use HTTP/2 and TLS thanks to LetsEncrypt ?
- zwily 9y ago
  What does that have to do with Webpack?
  - JasonSage 9y ago
    Instead of serving bundles you can load individual scripts over an HTTP/2 connection and quickly serve only the scripts which are needed.
    - zwily 9y ago
      Ah, but webpack does so, so much more than just bundling.
- BrandoElFollito 9y ago
  You need webpack to actually use a Vue component (template + script + CSS).
  - dabernathy89 9y ago
    You can use Browserify or Rollup too. https://github.com/vuejs/vueify https://github.com/vuejs/vueify https://github.com/vuejs/rollup-plugin-vue https://github.com/vuejs/rollup-plugin-vue
    - BrandoElFollito 9y ago
      Yes, I meant that the OP comment missed a large chunk of webpack use cases, such as compilation of components.
  - Shorel 9y ago
    Damn, I see that as unnecessary tight coupling, but a lot of our current technologies have survived that way.
deleted 9y ago
[deleted]
zackify 9y ago
How can you use this for any real production apps over webpack when it doesn't even support code splitting. This is nice for bootstrapping projects, or using just a little JS on certain pages. Otherwise I don't see how you could use it in an all JS app
- rosylamp 9y ago
  in the first paragraph the author addresses this directly. The author suggests this may be suitable for smaller projects > Webpack is a crucial tool for building sophisticated, highly optimized web applications, and is encouraged by many influential web developers. However, for newer developers, or those working on less ambitious projects, Webpack mostly occurs as a barrier
deleted 9y ago
[deleted]
patleeman 9y ago
For those new to Vue, Vue-CLI + templates have all the webpack configuration set up already for you. This makes setting up a Vue project very quick and simple. https://github.com/vuejs/vue-cli https://github.com/vuejs/vue-cli https://github.com/vuejs-templates https://github.com/vuejs-templates
MOdMac 9y ago
This does look nice but we can solve the configuration difficulty of Webpack without switching tools. Webpack should be the standard we all get behind until there is a tool that offers significant improvements, not just being easier to use. We are using an internal NPM package for common Webpack settings similar to the JetBrains library [1]. With that setup, our Webpack configs are much easier to use. There are other libraries like webpack-config [2] that give you a fluent api and allow common configs to be extended. [1] https://github.com/JetBrains/ring-ui https://github.com/JetBrains/ring-ui [2] https://www.npmjs.com/package/webpack-config https://www.npmjs.com/package/webpack-config
bricss 9y ago
Webpack is a new Grunt, if we talking about configuration.
agnivade 9y ago
I thought the vue-cli(https://github.com/vuejs/vue-cli https://github.com/vuejs/vue-cli) tool did a pretty good job of creating sane webpack configurations by asking just a few basic questions.

147 points by sandGorgon 9y ago

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).

mikewhy 9y ago

I loved Brunch back a few years ago. But I wasn't happy with how plugins worked, or their "all files get included in your bundle even if you never required them". So I built my own build system on top of Gulp, and added a set of tasks using browserify for web apps (https://github.com/BraveNewWorldDev/parched-example-app https://github.com/BraveNewWorldDev/parched-example-app). It's heavily "convention over configuration", like "npm install parched-babel" is all you need to get Babel integrated. I'm still using it in production on websites, Cordova apps, and Electron apps, but I'd still recommend webpack nowadays since that's where the community is.

bfred_it 9y ago
Oh boy I just finished moving my old gulp+browserify(+sass+postcss) config to webpack. It was a bunch of custom nonsense. In return I got a faster build, 20% lighter output and a lot more information (webpack shows size, etc)

timdorr 9y ago

Brunch has a good "vs Webpack" section in their docs: http://brunch.io/docs/why-brunch#brunch-vs-webpack http://brunch.io/docs/why-brunch#brunch-vs-webpack Some of the big table stakes features that Brunch is missing are code splitting and handling of binary assets (allowing things like image inlining). It also doesn't have true hot module reloading, which is a pretty useful dev feature.

efdee 9y ago
Code splitting seems like a major feature to miss out on. I assume/hope it will come to Brunch sooner rather than later.
christilut 9y ago
I can't live without hot module reloading anymore.. With my Vue projects (no idea if React does it like this too) I can update my code and it only reloads either CSS, JS or HTML and it completely maintains state. Textfields maintain their content while I edit their CSS, just great. Wasn't long ago that auto reload on file change was a fancy feature...

hhandoko 9y ago

I looked into Vue + Webpack vs Vue + Brunch on my last project. I ended up with Brunch because the requirements are fairly basic and Brunch are easier to grok. Had the requirements be a little bit more complex, I could have easily gone for Webpack. IMO, there are a few key things lacking with the Vue + Brunch combo: - The `vue-brunch` plugin seems to be no longer in active development? (https://github.com/theocodes/vue-brunch https://github.com/theocodes/vue-brunch) - The `sass-loader` plugin allows me to use Sass dialect in SFC-style Vue (Single File Component). I'm using plain CSS with Vue + Brunch SFC as I cannot find a Brunch plugin offering similar functionality. - There are some Brunch idiosyncracies. For one, the processing pipeline is executed as per `package.json` (dev)Dependencies ordering. I spent quite a bit of time before figuring this out.

aarondf 9y ago

I really love using Laravel Mix [1], which is a wrapper around webpack. I know nothing about webpack, because mix makes it easy to just get going on my actual project instead of futzing about with configuration. Edit: FYI, Laravel not required. 1. https://github.com/JeffreyWay/laravel-mix/tree/master/docs#readme https://github.com/JeffreyWay/laravel-mix/tree/master/docs#r...

dabernathy89 9y ago
Agreed - Laravel Mix makes it absurdly easy to get started with Webpack, while still getting a lot of power out of it. And you can use it in anything: a mostly server-side app (like a typical Laravel project, where Mix originated), a complex SPA, or even a WordPress theme (which I found myself doing over the weekend).

marcofatica 9y ago

not sure if i did something wrong, but i cloned the app and ran the build and there's over 7500 lines of boilerplate included before the 'main.js' import in public/app.js. what is going on?

hardwaresofton 9y ago

If you're looking for alternatives to Webpack, please also check out JSPM (a good short description might be "preprocessing system + package manager + systemjs"): https://jspm.io/ https://jspm.io/ It takes a little more to get it to work with vue (the plugin that makes .vue files work is older and unsupported nowadays), but I use it just fine, with my template, styling and component files separated (I wrote a little thing: https://gitlab.com/mrman/systemjs-plugin-vue-template-compiler#readme https://gitlab.com/mrman/systemjs-plugin-vue-template-compil...) If you dislike how complex webpack is, you'll like JSPM -- here's the video that got me hooked (it's pretty old but still valid): https://www.youtube.com/watch?v=iukBMY4apvI https://www.youtube.com/watch?v=iukBMY4apvI

aweiland 9y ago
Rollup looks pretty good too. It's on my list to play with. https://rollupjs.org/ https://rollupjs.org/
- kevmo314 9y ago
  Rollup and webpack serve two somewhat different purposes: https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c https://medium.com/webpack/webpack-and-rollup-the-same-but-d...
- akvadrako 9y ago
  Rollup looks like the future - one big plus is the output looks nearly hand crafted compared to the unreadable mess webpack shits out.
jameshush 9y ago
We used JSPM in production for a year and a half. We had to switch back to Webpack because JSPM's bundles (even with HTTP2 enabled) were slowing down our time to first render drastically. About an extra 2 seconds on 3g mobile compared to the same site with webpack. We're an edge case though, for most sites JSPM will work fine, and if it's currently working for you don't switch over. Switching over was a pain so I don't recommend switching unless you absolutely have to. I would not recommend using it for new projects though.

petepete 9y ago

I've been writing a Brunch/Vue.js app for the last few months and, for a relative newcomer to JavaScript frameworks, Brunch was far easier to get up and running with than Webpack. I spent a couple of days failing to get things working the way I wanted with Webpack and after discovering Brunch I was productive within half an hour. My `brunch-config.js` is about 30 lines long and everything works as I'd expect.

tkubacki 9y ago

When did Vue hype officially start ? It's funny to see how deeply HN crowd is driven by vouge.

apocalyptic0n3 9y ago
Depends on what community you are part of. Vue received a lot of hype within the PHP community (especially the Laravel community) shortly after it launched. I want to say early 2015 is when it started there.
unvs 9y ago
I thought it had more to do with all the noise lately around the React PATENTS, but I could be wrong
- thegayngler 9y ago
  Yeah I think that is a concern for many people around building an app with React and friends. I've heard people complaining on this issue multiple times at work.
jaequery 9y ago
mainly its the react fatigue, thats finally tipping them over the edge to try something better. vue seems to have come in at the right time for that. and given the momentum, its possible that vue may supercede react at some point if this keeps up.
- bartread 9y ago
  I'm getting pretty jaded with the JS ecosystem as a whole. I don't want to have to learn new (effectively throwaway) technologies every few months because, fundamentally, I'm interested in building valuable products, not in learning technologies as an end in itself. Or, in other words, I have better and more interesting things to do. Also, this endless churning is not how you develop expertise. The way things are at the moment you've just about learned to work with the quirks of one framework and then you have to pick up another one. It's completely ridiculous, especially when in a lot of cases the benefits of one technology over another similar technology are pretty marginal. I mean, come on: can you honestly say that Brunch is a quantum leap on from WebPack (or vice versa), or that WebPack is a quantum leap over Gulp (or, again, vice versa)? I don't think so. By contrast, you become an expert by sticking with things and developing deep understanding. I've therefore reached the point where I'm only interested in the browser APIs and JS libs that are proven, battle-tested, and have stable APIs. I don't want to waste time rewriting code that was working and is now broken just because the previous API version offended the aesthetic sensibilities of some capricious maintainer. (Sorry, I do tend to get quite grouchy about this stuff.)

thex10 9y ago

Similar to Brunch but more opinionated is Jus. http://jus.js.org/ http://jus.js.org/ I really enjoyed using it, but alas I wanted a different Markdown loader (theirs is based off Github markdown, which doesn't support footnotes), so I switched to Metalsmith. But Jus and Brunch and the like are great options.

pselbert 9y ago

Years ago when Phoenix was adding JS support I lobbied Chris McCord to go with Webpack. He took a lengthy look at the setup/configuration process for all of the popular build tools and ended up choosing Brunch. For most tasks it is a great choice, and an excellent default for a "batteries included" web framework.

jstewartmobile 9y ago

How long can we keep adding to the tower of javascript shitware before it falls over? Honestly I thought it would have fallen over a long time ago. Just looking at long chains of mystery-meat that npm imports, and the time it takes Babel to compile the simplest of projects make me just want to say the hell with it all and do everything as GET/POST.

root_axis 9y ago
So why don't you do everything as GET/POST?
- jstewartmobile 9y ago
  Because I was dumb enough to try React when enough people said "Oh, this changes everything!" Whatever React gave, npm and Babel took right back.
  - root_axis 9y ago
    I'm not sure how trying things makes a person dumb. Either way, that doesn't answer the question of what is stopping you from using the tools you prefer rather than the ones you despise.
    - jstewartmobile 9y ago
      I still have to maintain the product, unless I want to go full CADT and re-do it in something else.
VectorLock 9y ago
I wonder the same thing myself. Occasionally I look into these frameworks to see if they really add anything to the development of complex web applications vs. the amount of work they take to integrate them and it always heavily seems like a waste of time.
- 9y ago

TekMol 9y ago

Do you guys use any public websites that are based Vue, React or alike? Everytime I search for sites that use frameworks like Vue or React, I came up with mostly empty hands. Except for example pages or pages by coders for coders. Or pages that "use" one of the frameworks but seem to make no use at all of the functionality. When I ask around people usually tell me "Well, at my company we make a dashboard for another company and it's based on ..." Any popular public sites (Aka no login needed to access it. So Facebook doesn't count.) for non-coders out there that use these frameworks?

Method-X 9y ago
Here's a project I'm working on that uses react: https://edabit.com https://edabit.com
- TekMol 9y ago
  Thanks! Tried it a bit and thought: "Hmm.. it's probably react that causes all these spinning "loaders" everytime I click somewhere. Wouldn't it be better without?". How do you see that? EDIT: Ups, why the downvotes? With spinning "loaders" I mean the "loading" animation the website shows. The spinning circle. Anything bad about this question?
  - JasonSage 9y ago
    > Anything bad about this question? You didn't ask a question, you jumped to a (wildly inaccurate) conclusion.
    - TekMol 9y ago
      In which sense inaccurate? If the server would just send a rendered page, why would a loading animation be needed?
      - JasonSage 9y ago
        > it's probably react that causes all these spinning "loaders" everytime I click somewhere Statistically speaking it's _probably_ jQuery or pure JavaScript. These loading spinners have been around to make site loading more attractive for a long time, predating React, Vue, Ember, even Backbone. I have tons of clients on Wordpress that love this kind of thing even if all it does is make their site load without a flash of unstyled content (FOUC). > If the server would just send a rendered page React is primarily a client-side framework, but it's possible to render it on the server using Node. However, a lot of sites still use React to enhance an existing frontend, and therefore do not port their entire server to Node to render with React. > why would a loading animation be needed? Alright so lets assume you've server-rendered with React, do you still need a loading animation? Maybe. All these sites you click on that have loading spinners are all server-rendered pages too, but that doesn't stop people from throwing jQuery plugins at it to make their sites look fancy and prevent a FOUC. It's more a question of how many images the site wants to display above the fold. If there's a bunch of images, your site will not load fast and you can choose between letting users see a gappy page gradually get filled in or sit and look at a spinner for 1.5s. EDIT: not to mention all the advertising trackers these sites have enabled. This makes your image-loading all the more laggy.

Shorel 9y ago

Do we still need Webpack when all connections can use HTTP/2 and TLS thanks to LetsEncrypt ?

zwily 9y ago
What does that have to do with Webpack?
- JasonSage 9y ago
  Instead of serving bundles you can load individual scripts over an HTTP/2 connection and quickly serve only the scripts which are needed.
  - zwily 9y ago
    Ah, but webpack does so, so much more than just bundling.
BrandoElFollito 9y ago
You need webpack to actually use a Vue component (template + script + CSS).
- dabernathy89 9y ago
  You can use Browserify or Rollup too. https://github.com/vuejs/vueify https://github.com/vuejs/vueify https://github.com/vuejs/rollup-plugin-vue https://github.com/vuejs/rollup-plugin-vue
  - BrandoElFollito 9y ago
    Yes, I meant that the OP comment missed a large chunk of webpack use cases, such as compilation of components.
- Shorel 9y ago
  Damn, I see that as unnecessary tight coupling, but a lot of our current technologies have survived that way.

deleted 9y ago

[deleted]

zackify 9y ago

How can you use this for any real production apps over webpack when it doesn't even support code splitting. This is nice for bootstrapping projects, or using just a little JS on certain pages. Otherwise I don't see how you could use it in an all JS app

rosylamp 9y ago
in the first paragraph the author addresses this directly. The author suggests this may be suitable for smaller projects > Webpack is a crucial tool for building sophisticated, highly optimized web applications, and is encouraged by many influential web developers. However, for newer developers, or those working on less ambitious projects, Webpack mostly occurs as a barrier

deleted 9y ago

[deleted]

patleeman 9y ago

For those new to Vue, Vue-CLI + templates have all the webpack configuration set up already for you. This makes setting up a Vue project very quick and simple. https://github.com/vuejs/vue-cli https://github.com/vuejs/vue-cli https://github.com/vuejs-templates https://github.com/vuejs-templates

MOdMac 9y ago

This does look nice but we can solve the configuration difficulty of Webpack without switching tools. Webpack should be the standard we all get behind until there is a tool that offers significant improvements, not just being easier to use. We are using an internal NPM package for common Webpack settings similar to the JetBrains library [1]. With that setup, our Webpack configs are much easier to use. There are other libraries like webpack-config [2] that give you a fluent api and allow common configs to be extended. [1] https://github.com/JetBrains/ring-ui https://github.com/JetBrains/ring-ui [2] https://www.npmjs.com/package/webpack-config https://www.npmjs.com/package/webpack-config

bricss 9y ago

Webpack is a new Grunt, if we talking about configuration.

agnivade 9y ago

I thought the vue-cli(https://github.com/vuejs/vue-cli https://github.com/vuejs/vue-cli) tool did a pretty good job of creating sane webpack configurations by asking just a few basic questions.