5 ms·

Maybe this is good and useful for some people: but to me it feels like a continuation of the dark slide that frontend tooling is going on. Way overcomplicated,

Maybe this is good and useful for some people: but to me it feels like a continuation of the dark slide that frontend tooling is going on. Way overcomplicated, likely brittle and buggy, significant barriers to just sitting down and building stuff.

denster 6y ago
I can't help but agree! Where's the Visual Basic 6 of our era? :) Sure, apps weren't pretty, but you could bang one out in a few days and start getting use from it. That's why I've devoted my career to tooling, hoping to improve the situation [1] [1] {cough, cough} https://mintdata.com https://mintdata.com is where we put our blood, sweat 'n tears as a result :)
irrational 6y ago
You are my spirit animal. Where did these people come from that decided that front end development needed to be such a house of cards that it takes a masters degree to get a build system successfully set up and working and know how to fix it when it breaks every few days.
- Kaze404 6y ago
  I personally don't think it's that hard to run `parcel` on the command-line. Front-end tooling is as complicated as any other tooling: as much as you need it to be.
  - Nullabillity 6y ago
    Parcel is easy to use (as long as you stay on the golden path), but I have a hard time calling it simple. Automagically installing dependencies that it fails to `require()` seems way out of scope for a bundler. Or managing Rust toolchains. Or a bunch of hard-coded rules that hard-exclude compiling stuff in `node_modules`. Unless they're in symlinks (presumably for Yarn workspaces?). And so on.
  - markdown 6y ago
    There's a new one called parcel? WTF? I started with Grunt. Then came Gulp, webpack, and a couple of others. They all do pretty much the same thing, and yet apparently someone has come up with a new one called parcel. Do they do this shit to make nice CV's so they can land FAANG jobs? Everything was easier back when we used to use FTP to upload CSS and JS files to sit alongside index.html or index.php. EDIT: I just googled and the first result is parceljs.org, but that one is blank with a BLM logo on it. Is there another site?
    - deltron3030 6y ago
      Parcel is old news, Snowpack and Vite is where it's at right now (not joking). Or you ditch node.js completely and go with Deno!
      - irrational 6y ago
        Crap. I totally thought you were joking. The insanity must stop.
    - Kaze404 6y ago
      All of those you used previously still work and are arguably more used than Parcel. I only mentioned it because it's entire premise is that those bundlers are too complicated, and Parcel literally just works out of the box, no configuration, for most things. It's neat, and you might enjoy it :)
RussianCow 6y ago
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.
8agpc 6y ago
As a co creator of it. It’s very resilient. Running over 6000 handwritten modules with no issues at the moment. Other companies are applying it to 50,000 handwritten modules. I’d say that it’s most helpful for those at scale. If you don’t actively need it. Definitely don’t use it haha

denster 6y ago

I can't help but agree! Where's the Visual Basic 6 of our era? :) Sure, apps weren't pretty, but you could bang one out in a few days and start getting use from it. That's why I've devoted my career to tooling, hoping to improve the situation [1] [1] {cough, cough} https://mintdata.com https://mintdata.com is where we put our blood, sweat 'n tears as a result :)

irrational 6y ago

You are my spirit animal. Where did these people come from that decided that front end development needed to be such a house of cards that it takes a masters degree to get a build system successfully set up and working and know how to fix it when it breaks every few days.

Kaze404 6y ago
I personally don't think it's that hard to run `parcel` on the command-line. Front-end tooling is as complicated as any other tooling: as much as you need it to be.
- Nullabillity 6y ago
  Parcel is easy to use (as long as you stay on the golden path), but I have a hard time calling it simple. Automagically installing dependencies that it fails to `require()` seems way out of scope for a bundler. Or managing Rust toolchains. Or a bunch of hard-coded rules that hard-exclude compiling stuff in `node_modules`. Unless they're in symlinks (presumably for Yarn workspaces?). And so on.
- markdown 6y ago
  There's a new one called parcel? WTF? I started with Grunt. Then came Gulp, webpack, and a couple of others. They all do pretty much the same thing, and yet apparently someone has come up with a new one called parcel. Do they do this shit to make nice CV's so they can land FAANG jobs? Everything was easier back when we used to use FTP to upload CSS and JS files to sit alongside index.html or index.php. EDIT: I just googled and the first result is parceljs.org, but that one is blank with a BLM logo on it. Is there another site?
  - deltron3030 6y ago
    Parcel is old news, Snowpack and Vite is where it's at right now (not joking). Or you ditch node.js completely and go with Deno!
    - irrational 6y ago
      Crap. I totally thought you were joking. The insanity must stop.
  - Kaze404 6y ago
    All of those you used previously still work and are arguably more used than Parcel. I only mentioned it because it's entire premise is that those bundlers are too complicated, and Parcel literally just works out of the box, no configuration, for most things. It's neat, and you might enjoy it :)

RussianCow 6y ago

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.

8agpc 6y ago

As a co creator of it. It’s very resilient. Running over 6000 handwritten modules with no issues at the moment. Other companies are applying it to 50,000 handwritten modules. I’d say that it’s most helpful for those at scale. If you don’t actively need it. Definitely don’t use it haha