please describe thresholds where tools are appropriate AND where they are completely unneccessary

[brianleroux]

build tools are great! we love our tools. I use them every day. but the tool isn't the goal and the statements of this website could lead less experienced developers to conclude that tools are the starting point for a project. this is not a good practice or useful advice to new developers.

we should incrementally adopt tools as project requirements grow to include them.

for example, you do not need to bundle all your modules if you have very few and avoid the waterfall by using an entry file (similar to Deno's deps.ts convention). another example: dead code elimination is cited as a great performance gain. this is true, but not adding dead code to execution paths is probably the ideal state rather than constructing large dep trees only to rely on a tool to optimize the output.

anyhow, this kind of sentiment might be taken as 'do not use tools' but this isn't the intent. my intent is to communicate tools are useful but only in context of when they are appropriate which, in this modern everygreen web, is increasingly rare if ever necessary. we shouldn't be propping up yesterdays practices for todays web and especially if the tools encourage non standard syntax and dialects.

[jakearchibald]

Might take me a couple of days to reply to this with web.dev/live still going on, but I will 😀

[jakearchibald]

Cards on the table, I initially thought this was an anti-tooling rant that I was going to softly dismiss (based on the twitter discussion that I only really saw out the corner of my eye), but I think it highlights some stuff missing from the site, so thanks for raising it.

build tools are great! we love our tools. I use them every day. but the tool isn't the goal and the statements of this website could lead less experienced developers to conclude that tools are the starting point for a project. this is not a good practice or useful advice to new developers.

we should incrementally adopt tools as project requirements grow to include them.

Yeah, that's fair.

for example, you do not need to bundle all your modules if you have very few and avoid the waterfall by using an entry file (similar to Deno's deps.ts convention).

Sure, but if you keep lots of files, caching becomes even more important, and manually adding version numbers to files is a massive pain in the arse, and errors are likely to creep in.

another example: dead code elimination is cited as a great performance gain. this is true, but not adding dead code to execution paths is probably the ideal state rather than constructing large dep trees only to rely on a tool to optimize the output.

I agree in terms of code you write yourself, but dead code elimination is important for third party code, which may be doing more than you need. We see sites including all of lodash even though they're only using a couple of functions.

@surma @developit some thoughts on changes based on this:

• Add a "what are bundlers" page. Currently our 'About' and 'FAQ' pages are based more around the site itself, whereas "what are bundlers" would be purely about bundlers.
• "what are bundlers" includes "Do you need a bundler?", which is a "no, but you might be missing out on…".
• "what are bundlers" then goes onto briefly talk about the benefits, linking off to the various tests.
• "what are bundlers" includes a section about the dangers of over-using build tools, detailing what can go wrong if you needlessly use all the features. We could also talk about the advantages of 'special' imports looking special. This might also take care of Justin's concerns, if we talk about the downside of publishing non-standard code.
• Add something to pages like the binary test to stress that adding a lot of binary data to JS is bad. Maybe explain that this test is a proxy for testing particular bundler capabilities.
• In our dead code test, point out that this is mostly useful for third party libraries.

@brianleroux does that make sense and would it close this issue?

[surma]

Thanks @brianleroux for writing this up in a longer form. I think Twitter might has made us sound harsher than we intended :D

I’m on-board with building out the About page (and potentially adding a more prominent link to the About page from the landing page). All the bullets sound reasonable to me.

[developit]

One point to add to this: there are a few newer tools that straddle bundling + unbundled development, like Vite and Snowpack. These could be compared to bundlers, however most of the tests on tooling.report focus on production output - in production, these tools generally bundle things using one of the bundlers already compared (Vite uses Rollup, Snowpack uses Webpack, etc).

It's possible this is a whole separate type (or level?) of tooling, and worthy of a separate suite of comparisons. It would be hard to assess the current crop of "unbundled" developer tools without including tests for development-only features like module reloading and update latency. My hesitation in suggesting a new devservers.tooling.report site is that developers do end up needing to choose between using a "dev server with production build" VS developing and building with the same bundler.

One option we could consider would be to add a disambiguation page, which would list popular "meta-tools" (tools built atop lower-level ones) and link to the relevant tests for the underlying bundler. It could also explain how each meta-tool is different, or any "modes" that affect its output (development VS production, etc).

[brianleroux]

@jakearchibald sounds super good to me! I'm happy to help with any of this copy. You make a VERY valid point about fingerprinting files which, in my opinion, isn't even a nice-to-have but rather a requirement for production deployment. Third party proxies can cache regardless of header directives and cause much pain. This may shock casual readers but we fingerprint automatically for begin.com and don't make this an authortime/developer concern. We code raw paths (eg /src/index.js which is intercepted by a cloud function that does a 302 redirect to the fingerprinted file (which it either created or reads from a warm cache). Is that bundling? Yes. Am I wasting my time doing it manually? No. In theory that is the job we created computers for. As for 'tree shaking' garbage third party libs: imo that is passing the buck and enabling bad actors that should penalized and most definately not fixed by userland. I don't use lodash whole hog for this reason and if devs can learn how to webpack their babels they can learn how to do this too.

@surma Twitter definitely amplifies bad vibes and I am super sorry for propagating that. Should've just come here first.

@developit Sure, meta things are neat too I guess. I suppose what I'm hoping for is teaching the reasons for these tools. As mentioned above we automate this stuff completely. Should we all not be aiming for that end goal? Focusing on pure business logic and an accessible, durable, performant and resilient user experience? Dare I say ..responsive. Progressive even. Heresy I know!

Sometimes I wonder if we should just give HTTP cute name and mascot so people think it is a framework (instead of a scary platform primitive) and start learning how to use it beyond GET requests. ;P