> Enjoy the dev experience of Vue + webpack
I just find this confusing. The only reason I tolerate webpack is because of how convoluted the front end web build chain has become.
I honestly think you must be a sadist to use something like this. It sounds like it might get around the SEO problems SPAs suffer from somehow, but seriously, just use Hugo or Jekyll!
[0] https://www.semrush.com/blog/how-fast-is-fast-enough-page-lo...
You can't be wasting cognitive load on that.
Hot reload is nice, but there's nothing revolutionary about it that justifies more than an hour of getting things to work.
I've found productivity boosts in shortening the feedback loop. A tighter feedback loop makes it easier to get into flow.
But days of effort to get a simple thing working defeats the purpose. My worst days are when I look over the day and I've spent it fixing a build process - there's no flow in that. I could just bite the bullet and still get into flow albeit less smoothly but still. That's how I worked for years.
I just wanted to point out it isn't as simple as eliminating a refresh. There is a gain behind that.
It doesn't take a few days, it's more like a few hours, and it's completely worth it. It makes development much less frustrating, it reduces cognitive load (no switching back and fourth between windows) and it's faster (includes not having to get the app back into the state it was in before with hot reloading).
When compiling and reloading is something you're doing hundreds of times a week, a seemingly small improvement makes a huge difference to how enjoyable it is to work on a codebase which makes you more productive. I'd say the same thing about reducing a test suite run from 10 seconds to 1 second; it might only be saving you a few seconds each time but it makes you more productive because tightening the feedback loop reduces frustration which increases productivity.
There's nothing worse than attempting a fix, waiting 60 seconds in anticipation it worked, seeing the same error message as last time and then having to try again for instance.
I've never set up Webpack myself, but I'm getting all the benefits.
Hot reloading saves so much time, and means you'll check for smaller increments, because it's painless.
I very much would like to use a simple, sturdy, predictable environment and trying to work with webpack has brought me only frustration.
Things that should get chained together and just work, don’t. To fix them I needed to understand obscure bugs in infinite npm dependencies. I’m not that good at JavaScript and honestly don’t want to be.
I would gladly pay $50-100 per set up if this service existed.
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 [2] https://www.npmjs.com/package/budo
Disclaimer: I'm not a serious webapp developer/software engineer. I mostly build websites so mileage may vary.
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. :)
I use the browserify plugin "tinyify" to make the final output smaller: 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
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.
mix.js('resources/assets/js/app.js', 'public/js') .sass('resources/assets/sass/app.scss', 'public/css');
Here are the docs: https://laravel.com/docs/5.6/mix
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/ 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!
Both of those lack support for custom "sources", instead of just markdown files.
A lot of people like Contentful (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.
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.
Does it generate pure html, without react support?
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.
Also, Hugo lacks support for plugins. If you want to do something with it, it better be baked-in out-of-the-box.
Middleman / Jekyll both support slim, webpack if needed, live reload, json or yaml data files, partials, page matter (in-page data in yaml format) etc.
The only issue is setting up webpack (for vie and Babel in the middleman specific confit).
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.
A nitpick, but this says something a bit like the opposite of what you intended. You mean "masochist".
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.
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.
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?
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.
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.
If you're sticking to a pre-built template or simple defaults maybe but once you start to customise things it's easy to get stuck in your own unique problems. Resolving path issues can easily eat up 30 minutes alone so I'd say you're severely underestimating.
> If you really need help then post it here or on stackoverflow and you'll get an answer pretty quick.
Once you've got your own unique combination of plugins going, it gets difficult to know where the problem is and you're less likely to get help if you've got something bigger than a minimal example. I know how to ask for help but there's just something about build system which makes it more challenging and more frustrating to get help compared e.g. typical programming problems.
What other paths are you running into problems with? Also debugging this is just like any other app, start with 1 line at a time and see what changes. You can technically run it all inside of a debugger but that's a lot of setup so the old-school 1 change at a time + console.log() statements work well. Remember its just a single-file js app that produces an object.
Webpack as of now reserved to just vendor. Porting the whole app over will take a significant amount of work. I don't have that at the moment, not with 2 or 3 deadlines on my plate!
That object needs 4 main properties: the entry (the file where your app begins), the output (where to put the compiled stuff), the loaders (what to use to load various file types identified by a regex to test the file name), and plugins (for anything else that operates on the compiled output).
Also, even the most popular webpack plugins have trouble tracking the latest version of webpack and you often still have blocker bugs months after a release, so you often have to try many, many combinations before your workflow does what you want.
Single page applications?
> VuePress generates pre-rendered static HTML for each page, and runs as an SPA once a page is loaded.
It literally is one command running in the background
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?
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.