4 ms·

I agree with the general sentiment of frontend tooling becoming more complex over time, but the thing about features like this one is that you don't ever have t

I agree with the general sentiment of frontend tooling becoming more complex over time, but the thing about features like this one is that you don't ever have to use them or even think about them if you don't need to. But they sure are nice to have if you do need them. Personally, I'm looking forward to implementing this at work, but I don't think I'll ever touch it for my personal projects.

smacktoward 6y ago
Webpack's general design philosophy is to dump a bag of tools on your head and tell you to use them to assemble a build system. So anytime the bag gets larger, I cringe.
- RussianCow 6y ago
  I don't disagree, but if you don't need the entire bag of tools, you can get by for quite some time (possibly indefinitely) using just `create-react-app` and friends. The issue with webpack is that the learning curve for going from CRA to manual tuning is incredibly steep, but what that buys you is full control over the entire build process. I do wish there was a middle ground where you could use 90% sane defaults and customize the other 10% without taking on a huge amount of tool-specific baggage. Parcel is great for simple projects, but is not (in my very limited experience over a year ago) anywhere near customizable enough for more advanced use cases.
wcarss 6y ago
It's a great point that you don't need to use these things if you don't want to in your projects, but the caveat is that you will often end up working on projects other people created, and they might have done things like use a feature just because it seems cool, or create the project from a template that includes the kitchen sink and eventually rusts through. In those cases, you have to understand the rusty sink at least well enough to fix it, and hopefully well enough to assess if it was the right tool for the job, and how to safely remove it if it really wasn't. A great example of this is actually create-react-app. Many people who have no idea what they're doing start off an app using this toolset and end up with a boatload of things they aren't even aware of, like a half-baked service worker that by default caches the app's code in localStorage to enable offline app functionality! My own experience with that specific issue was of people building a production system on top of an ejected create-react-app, who ended up with deployment issues where some users arrived to a blank page after some deploys. It just seemed to happen randomly. It turned out that after some deploys, for some users, the default CRA service worker's cache and the webpack js minify+chunk configuration, and the 404 redirect configuration for firebase, didn't play well together. You could end up with new code calling cached code which requested chunks that didn't exist anymore, and getting served html 404s with status 200, so the cache wouldn't bust properly. Understanding this, debugging it, and solving it safely (in part by safely deregistering the service worker for all users) took ~days! The really upsetting part is that no one involved in building this app (neither founders nor original create-react-app-running devs) ever wanted service workers, nor a progressive web app offline code cache, nor code chunking, nor optimistic 200-html pages in place of 404s. But those were all default options and packages and stackoverflow copypasta that got cargo culted in, and it produced a bit of a tower of crap.
- dceddia 6y ago
  That default service worker setup was frustrating. Even for local development, it would mess things up sometimes. Luckily they turned it off for new Create React App projects a while back - so at least it shouldn't haunt any new apps.
- cageface 6y ago
  The worst software hairball I've ever had to untangle was a react/redux/saga monstrosity that was excruciating difficult to debug or improve. I finally got permission to rip most of that out and the resulting plain react app was fairly pleasant to work on. So yeah, software development fads matter whether you personally follow them or not.
  - JamesBarney 6y ago
    I was recently brought onto a project to add a couple of simple screens to an app. Any other react project it would have taken a couple of days so I was surprised the previous estimate was for weeks of development effort. Opened up the hood to find saga, and quickly discovered why it would was weeks of effort.
8agpc 6y ago
Yep. Don’t use it for smaller projects. You can. But why. It’s designed for scale issues. Just cause you can doesn’t mean you should haha. I’m not using it on any personal projects because there’s no actual need for it. I’ve got it in production. Replaced tag management, personalization, configs, no page reloads between apps. I’d argue that MF simplified tooling and gives us back simple import capabilities. At least compared to everything else I’ve tried in the past 10 years

smacktoward 6y ago

Webpack's general design philosophy is to dump a bag of tools on your head and tell you to use them to assemble a build system. So anytime the bag gets larger, I cringe.

RussianCow 6y ago
I don't disagree, but if you don't need the entire bag of tools, you can get by for quite some time (possibly indefinitely) using just `create-react-app` and friends. The issue with webpack is that the learning curve for going from CRA to manual tuning is incredibly steep, but what that buys you is full control over the entire build process. I do wish there was a middle ground where you could use 90% sane defaults and customize the other 10% without taking on a huge amount of tool-specific baggage. Parcel is great for simple projects, but is not (in my very limited experience over a year ago) anywhere near customizable enough for more advanced use cases.

wcarss 6y ago

It's a great point that you don't need to use these things if you don't want to in your projects, but the caveat is that you will often end up working on projects other people created, and they might have done things like use a feature just because it seems cool, or create the project from a template that includes the kitchen sink and eventually rusts through. In those cases, you have to understand the rusty sink at least well enough to fix it, and hopefully well enough to assess if it was the right tool for the job, and how to safely remove it if it really wasn't. A great example of this is actually create-react-app. Many people who have no idea what they're doing start off an app using this toolset and end up with a boatload of things they aren't even aware of, like a half-baked service worker that by default caches the app's code in localStorage to enable offline app functionality! My own experience with that specific issue was of people building a production system on top of an ejected create-react-app, who ended up with deployment issues where some users arrived to a blank page after some deploys. It just seemed to happen randomly. It turned out that after some deploys, for some users, the default CRA service worker's cache and the webpack js minify+chunk configuration, and the 404 redirect configuration for firebase, didn't play well together. You could end up with new code calling cached code which requested chunks that didn't exist anymore, and getting served html 404s with status 200, so the cache wouldn't bust properly. Understanding this, debugging it, and solving it safely (in part by safely deregistering the service worker for all users) took ~days! The really upsetting part is that no one involved in building this app (neither founders nor original create-react-app-running devs) ever wanted service workers, nor a progressive web app offline code cache, nor code chunking, nor optimistic 200-html pages in place of 404s. But those were all default options and packages and stackoverflow copypasta that got cargo culted in, and it produced a bit of a tower of crap.

dceddia 6y ago
That default service worker setup was frustrating. Even for local development, it would mess things up sometimes. Luckily they turned it off for new Create React App projects a while back - so at least it shouldn't haunt any new apps.
cageface 6y ago
The worst software hairball I've ever had to untangle was a react/redux/saga monstrosity that was excruciating difficult to debug or improve. I finally got permission to rip most of that out and the resulting plain react app was fairly pleasant to work on. So yeah, software development fads matter whether you personally follow them or not.
- JamesBarney 6y ago
  I was recently brought onto a project to add a couple of simple screens to an app. Any other react project it would have taken a couple of days so I was surprised the previous estimate was for weeks of development effort. Opened up the hood to find saga, and quickly discovered why it would was weeks of effort.

8agpc 6y ago

Yep. Don’t use it for smaller projects. You can. But why. It’s designed for scale issues. Just cause you can doesn’t mean you should haha. I’m not using it on any personal projects because there’s no actual need for it. I’ve got it in production. Replaced tag management, personalization, configs, no page reloads between apps. I’d argue that MF simplified tooling and gives us back simple import capabilities. At least compared to everything else I’ve tried in the past 10 years