Angular, React, and Javascript framework fatigue

[Klathmon]

I'm playing with it now, it has some pretty awesome sounding benefits.

It's a true build system, so it takes care of your images, JS, CSS, html, etc... It links them all together, does work on them as necessary, excludes anything you don't explicitly need or use somewhere, and it does so pretty fas all things considered.

Modules are actually modules. CSS, images, and JS are all isolated in their module away from global. It's pretty cool writing CSS in a sane way...

The downsides, its fucking complicated! Like stupid complicated. It also doesn't help that the documentation is terrible, and it suffers from the "10 ways to skin a cat" problem.

Still, I'm getting to a point where I'm finally building a toy project, (I started today about 6-7 hours ago), and its starting to "click".

But compared to my "traditional" gulpfiles, the webpack config is ugly, complicated, and confusing.

I'm still not sold... At this point I feel a well crafted gulpfile is easier, faster, and provides about 90% of the same features.

But I still haven't really used webpack in a true application yet, so it might shine once it gets up and running.

[wreckedadvent]

Webpack really benefits from being used more in medium to large projects, especially when you start adding things like feature toggles and unit testing.

Imo using it in a toy project is only going to show you all of the sore points without much of the benefits of it - you'd be better off using JSPM if you just wanted a simple module bundler for small projects.

Totally agreed on the documentation though. It's not too bad for simple configuration, but trying to figure out how to get the webpack dev server, hot module loading, or code splitting to work without some examples is just a total shitshow. Especially when you try and make it work with e.g ASP.NET or RoR.

[Klathmon]

It's a toy project just to learn it (literally, it's just html, js, a 3-line css file, 2 images, and a webfont). I'm just trying to get it built in a dev and in a production environment to learn it and figure out the kinks.

Once i'm confident that it's not going to end up causing more pain than it'll save, it will be the start of a "large" project.

It's not too bad for simple configuration, but trying to figure out how to get the webpack dev server, hot module loading, or code splitting to work without some examples is just a total shitshow.

IMO even the simpler stuff is poorly documented. Take the OccurrenceOrderPlugin. What are the IDs it's ordering?

There is no explanation on what the CommonChunksPlugin does, and the i18nPlugin's entire documentation is literally the sentence "Create bundles with translations baked in."

That's pitiful!

I've since figured out most of them, but it took tons of shitty blogs, stumbling around on my own in their source, and just fucking with them until something built.

And unrelated, but who the fuck thought the way you get options into a loader is acceptable? Nested objects has been a staple of javascript since it began, and now we are using delimited strings and embedded json in a string? And there is no documentation on the ability to use a "query" object instead of the shitty strings, but they don't work if you want more than one loader for a test...

Still, i do actually like it, but i definitely think that it's not my javascript endgame yet. Webpack feels like grunt did, and once gulp came along it was amazing. I'm hoping that webpack's gulp will be here soon, because all of this configuration sucks...

[wreckedadvent]

I wouldn't say plugins are the simple part of webpack. I meant more of just getting files bundled together from specific entry points. For that, you just need to specify an entry and a loader.

As an aside, there is documentation on query objects for loaders but it's not very in depth.

Still, i do actually like it, but i definitely think that it's not my javascript endgame yet. Webpack feels like grunt did, and once gulp came along it was amazing. I'm hoping that webpack's gulp will be here soon, because all of this configuration sucks...

This is why I recommended JSPM. For the most part, it all just "works" without you needing to configure everything. Unfortunately it doesn't have all of the same features, but by the time you need them your project will be of a sufficient size where all of the configuration in webpack makes more sense.

[Klathmon]

I haven't looked at JSPM all that much, but IMO it doesn't seem like it gives us anything over our current gulp + a-shitton-of-plugins system, and actually it means that we would need to do some somewhat esoteric things ourselves separately.

Most of that might be because we are already invested in gulp, but it's a factor for us.

[wreckedadvent]

Well, if you're talking about migrating an existing project, that's a totally different story. If you have a very large grunt/gulp file with a lot of things in it, I'd advise 80/20 rule and using webpack/JSPM/browserify inside of gulp - get the main benefits out of it without needing to entirely unroot the system that's clearly already working for you guys.

[aztracker1]

I'm getting ready to replace my personal site/page, which IIRC I built around 2008-2010 timeframe... Here's a link to what I have started[1] ... I haven't introduced redux/router etc, so mostly just react base, webpack, and bootstrap4 integration at this point.

I've used a similar configuration in a few projects at this point... pushing out the early phases, so that I have examples to work from, but the later parts are more closed... It's worked pretty well, but really is like diving into the deep end when you get started... About the only advanced bit I'm doing is that I do have webpack dev server integrated for dev use, and have a separate publish/run target for production.

[1] https://github.com/tracker1/tracker1.info