11 ms·

First, I'd like to say I'm a big fan of Vue.js. I've used it for a few production apps. > Enjoy the dev experience of Vue + webpack I just find this confusing

• petecooper 9y ago
  >SPAs Single page applications?
  • WD-42 9y ago
    Yes, from the front page: > VuePress generates pre-rendered static HTML for each page, and runs as an SPA once a page is loaded.
    • petecooper 9y ago
      Today I learned. Thanks very much!
• always_good 9y ago
  It's not bad once it's set up. For example, hot reloading your application state.
• josephg 9y ago
  > The only reason I tolerate webpack is because of how convoluted the front end web build chain has become. I've moved back to browserify (/ watchify) for hobby web projects and I've been very happy with it. Its a huge relief to jettison all the complexity that webpack brings. Browserify configuration often fits on the command line even for complicated projects. You have great tools for analysing bundle size with disc[1], and you can do hot reloading on SPAs with budo[2]. The ecosystem has babelify for JSX, tsify for typescript, uglifyify + unassertify for minification, and sheetify for CSS. Browserify also seems way faster. I haven't tried webpack 4, but with webpack 3 I've had plenty of builds that take nearly a minute. Its out of control. Webpack seems like the web generation's automake & autoconf. How long before we have tools which generate webpack configuration programatically, and which need configuration themselves. [1] https://www.npmjs.com/package/disc https://www.npmjs.com/package/disc [2] https://www.npmjs.com/package/budo https://www.npmjs.com/package/budo
  • navs 9y ago
    I recently made the switch to using ParcelJS [1]. Came from a browserify + rework + npm run scripts setup and wanted something with 0 configuration for my projects. Parcel's been that for me. Disclaimer: I'm not a serious webapp developer/software engineer. I mostly build websites so mileage may vary. [1] https://parceljs.org/ https://parceljs.org/
    • onion2k 9y ago
      Webpack 4.0 also has zero config and it works exceptionally well.
  • fiatjaf 9y ago
    Even better than watchify is the combo entr + browserify-incremental.
  • mattdesl 9y ago
    Glad you are enjoying budo! It's a little tool that I built before Webpack became so popular, yet I'm still finding myself using it daily for the last couple years. I'm actually working on some new tools that combines my favourite parts of budo, webpack, babebl, and parcel... But ultimately with very similar usage and "unix philosophy" approach as the rest of browserify. :)
  • jekrb 9y ago
    I also feel like browserify resonates better with me. I use the browserify plugin "tinyify" to make the final output smaller: https://github.com/browserify/tinyify https://github.com/browserify/tinyify If I'm working on a choo app I use banaki which uses browserify and my preferred bundle optimization plugins/transforms under the hood: https://github.com/choojs/bankai https://github.com/choojs/bankai
  • dabernathy89 9y ago
    > How long before we have tools which generate webpack configuration programatically, and which need configuration themselves. Haha, too late! I actually really enjoy using Laravel Mix, which despite the name is not tied to Laravel. It's a Webpack wrapper that simplifies it significantly for many common use cases. https://github.com/JeffreyWay/laravel-mix https://github.com/JeffreyWay/laravel-mix
• pknopf 9y ago
  > but seriously, just use Hugo or Jekyll! Both of those lack support for custom "sources", instead of just markdown files. A lot of people like Contentful (https://www.contentful.com/ https://www.contentful.com/), which static site generators like Gatsby support. This doesn't really address your remark about webpack though. However, I have been using Gatsby and I haven't had any issues with it. It is completely internal and hidden from the end user.
  • fiatjaf 9y ago
    > Both of those lack support for custom "sources", instead of just markdown files. That's why I wrote sitio[1]. sitio has a pretty simple imperative API where you can say stuff like "generate page on /about/ using the React component on 'components/page.js' and the following data: {}", so your entire configuration is just a simple nodejs script and you can use data from anywhere. Then it generates static pages that, if JavaScript is avalaible, will become React components and the entire site will be a Spa with proper history. If there's no JS, it's an HTML static site. Also, it uses Browserify under the hood, because Webpack is horrible. [1]: https://github.com/fiatjaf/sitio https://github.com/fiatjaf/sitio
    • pknopf 9y ago
      Interesting project! Does it generate pure html, without react support?
      • fiatjaf 9y ago
        Yes, it does. Actually if you don't include the main bundle.js you'll be left with just HTML and everything will be great.
  • hugozap 9y ago
    > Both of those lack support for custom "sources", instead of just markdown files. For me that's the beauty of it, just simple structured text files. If custom sources are needed for a static website then writing a transform script to generate the markdown files and yaml header is simpler than having to deal with integration apis.
• thsowers 9y ago
  The latest version of the vue-cli (might still be in alpha or beta) generates an app where webpack works out of the box very nicely
• abritinthebay 9y ago
  Webpack is basically zero configuration now - with v4 - so I’ve no idea what you’re doing to make it impact your life so. It literally is one command running in the background
  • pier25 9y ago
    It's zero config as long as you follow its conventions.
    • abritinthebay 9y ago
      ...using JavaScript? I mean as long as you use import or require it just works. Everything else is optional. You can use all that other stuff but there’s zero requirement to do so. What conventions do you mean?
      • pier25 9y ago
        For example that the entry point has to be ./src/index.js
        • abritinthebay 9y ago
          It doesn't have to be. Mine is ./src/client.js for example If you want zero config then there are assumptions it makes, but that's true of all zero config setups - they assume defaults. Changing it is one property in a config file. Not exactly tricky or complex.
• manigandham 9y ago
  Webpack is not hard, the config is a simple javascript app that has to return an object following a specific schema. It's a list of entries (the starting file of an app) and the loaders to use for each type of file, based on a regex test of the filename. It is maybe 0.05% of the difficulty of any actual app. Why is it so confusing when you can clearly create real apps without a problem?
  • seanwilson 9y ago
    > Webpack is not hard, the config is a simple javascript app that has to return an object following a specific schema There's so many variations in what stacks people are using and what build steps are required for different projects that setup issues and bugs to workaround are virtually inevitable. I want to move up to the next major version of Webpack for one project for example but after spending a total of several days getting my builds working correctly already, I'm almost certain it'll eat up at least a few days to get everything working again (e.g. production and development builds, source maps, live reloads, hot reloading, template compilation, TypeScript compilation, SASS compilation, project paths, optimizations). Saying it's just simple JavaScript is completely overlooking all the plugins and configuration you have to stitch together and when things go wrong it can be challenging to know what to Google for.
    • manigandham 9y ago
      I understand, but that's more of an issue of there being so many external plugins. The entirety of webpack itself is just a small core runner with plugins and they're slowly moving more functionality into the main package. Fundamentally I think the issue just comes down to terrible documentation and the spread of outdated blogs and examples as a result. The team seems to know that and they're working on it but it should be the highest priority for them. Honestly though, starting from scratch, you can build a complex config (with all those things you mentioned) in about 30 minutes. If you really need help then post it here or on stackoverflow and you'll get an answer pretty quick.
      • seanwilson 9y ago
• mkl 9y ago
  > I honestly think you must be a sadist to use something like this. A nitpick, but this says something a bit like the opposite of what you intended. You mean "masochist".
  • mygo 9y ago
    maybe a sadomasochist
    • mkl 9y ago
      What indication is there of the "sado" part? Using webpack doesn't inflict pain on others, does it? (I've never actually used it myself, but the OP only seemed to imply hurting themselves with it.)
      • stephenr 9y ago
        Hearing about it is pretty excruciating.
      • jwdunne 9y ago
        What about your team?
      • mygo 9y ago
        Does not have to inflict pain on others. Sadomasochism is the giving or receiving pleasure from inflicting or receiving pain. With that being said some people like seeing their team suffer. No sense of accomplishment if there was no struggle.
    • Fulck 9y ago
      fair enough
• pier25 9y ago
  Eh, Webpack is not so bad. The problem is using tools like Vue CLI which have overly convoluted configurations. If you make your own it will fit your needs and you can reuse it on every project. Parcel is a lot simpler but it still isn't ready for prime time (with Vue at least). As for static sites I agree. Simpler solutions like Jekyll, Gitbook, etc, make a lot more sense.
  • dabernathy89 9y ago
    Wasn't Vue CLI's config pretty much all webpack? (BTW they are moving into a zero-config approach with v3)
    • pier25 9y ago
      Vue CLI 2 is also a zero config approach (if you are ok with whatever template you are using). The big thing in v3 is that it's based on plugins.
      • dabernathy89 9y ago
        So, not so much zero config as prefab config :)
• bitexploder 9y ago
  Seriously, I have been writing code for almost 30 years now. I pick up new languages and packages and love hacking on new things still. Modern front end developmemt feels so bad in some areas. I spent full /days/ trying to tame webpack and friends and just gave up. "Modern" web front end developer is a weird and annoying place. I would rather battle pthreads and kernel bugs with gdb than try to figure out web front end. There are some bright spots. Vue is nice enough. Bootstrap has always made sense. jQuery is easy enough. But man, I remember IE4 vs NS navigator compatibility being more pleasant to manage in some ways to learning some of these JS frameworks. And I am not just expressing a grumpy get off my lawn sentiment. This stuff is legitimately obtuse. But in a strange way compared to say systems programming. Systems program is deep and sort of orderly. Modern JS is broad, chaotic, frustrating.
  • WD-42 9y ago
    I think what's started to happen is there is an entire generation of new coders that grew up on Javascript and the web and so all of this just seems totally normal. I look at some of this static site and server side rendered Javascript stuff and wonder if the people developing them have ever used flask, or Sinatra. I mean hell these frameworks make RoR look lean and simple.
    • fvdessen 9y ago
      Yes we have, and while the various new JS frameworks may be a bit more complicated they are also vastly more productive environments. For example webpack's development server let you develop your app with real time updates with hot reload. The productivity benefits from just that are worth more than a few days of setting up webpack. And that's just one thing webpack provides
      • yoavm 9y ago
        How is the productivity benefits from not having to press F5 after I'm updating the code is worth a few days of setting up Webpack? If I sum the time it took me to refresh pages since I started using the internet it doesn't get to a few days.
• jwdunne 9y ago
  Ugh. A colleague was struggling with a webpack set up. He was waiting like 30 minutes to rebuild a CSS change. Meanwhile, I'm using Sass on 2 projects, with around 100ms build times inc. live reload. Clearly there's reason for the disparity. So we looked and it turns out the webpack fast-sass-loader was around 3000% slower than just sass-loader. It now takes 3 seconds to build CSS changes. That to me is still too high for CSS but it's an improvement. There seems to be a heavy overhead with webpack in terms of both configuration and actual performance. We may have configured it wrong or maybe fast-sass-loader just isn't as advertised. Between that and package.json containing a makefile on top of dependencies, it's all a bit nuts.
• raresp 9y ago
  Or Wordpress :)
• EvanYou 9y ago
  Not sure why this is the primary concern but... did you even try it? Webpack is really an internal implementation detail for VuePress and not visible at all in most use cases.
• TheDutchCoder 9y ago
  I understand your frustration. I had the same problem as you: I found webpack waaaay too abstract. Tons of configuration was needed to even begin and there was little to no documentation that I could follow as a mere mortal developer. So what I did was to rewrite the majority of their beginner guides by submitting PR's for 2 reasons. 1: help out people like you and me. 2: learn about webpack in the process. I can really recommend following along with the Guides, because they use really, really basic examples and become more and more "complex" (it really isn't) as you follow along. You can find the guides here: https://webpack.js.org/guides/ https://webpack.js.org/guides/ and I really hope it will help you. It isn't as difficult as it has always seemed and if you have any struggles: don't hesitate to give the webpack team (including myself) feedback so we can improve the docs and guides. Hope it helps!