Re:Dear Developer, the Web Isn't About You
by lhorie on Thursday December 20, 2018 @01:10PM
(#18727376)
In my experience, ironically, a lot of web tooling tends to actually bog you down, especially at scale. For example, I've seen people get blocked from shipping code due to a million lint errors after running some codemods, people wasting a month configuring webpack (and still not get it quite right), people wasting weeks cleaning up flow errors after a patch release. Bikesheds about webpack loaders and babel plugins and lint rules and typescript-vs-flow. Nasty workarounds for babel parsing bugs for non-standard syntax. Erroneously-strict mode bugs in bundling. Minification bugs. `node_modules` peer dep hoisting bugs. Bugs in `yarn`. GYP issues. Stuff that only breaks in CI. VS Code plugin configuration issues. Etc etc etc.
Large companies literally have entire teams dedicated to maintaining tooling. And don't even get me started on monorepos.
At a previous company, a co-worker that had been setting up tooling infrastructure for a project was astonished at my iteration speed when he saw that mine was written with just a micro-framework and ES5. Conversely, when I had to jump in to help get his project back on schedule, we could never figure why the hot reloading setup had a 2 second delay on my machine (among other things).
Having worked on two projects of very comparable scope (two documentation sites for different projects), one written with the "latest and greatest" Gatsby and friends, and the other with just a dirty script, I honestly can't see any reason to do the former: it takes longer to do anything, the final payload is bigger, and now the codebase is using a version one major out of date, meaning a migration looming in the horizon. On the upside... GraphQL; yay I guess?
With this point in mind, your carpenter analogy seems a bit off IMHO. Of course, consumers don't care if the carpenter uses an electric screwdriver, but they do care if a knob gets loose and falls off because it was held by a single rushedly-drilled screw. Also, the employer should presumably be worried if said carpenter keeps spending a significant portion of his time sanding his hammer handles and replacing his workbench legs, or needs another carpenter to do so on an ongoing basis.
Large companies literally have entire teams dedicated to maintaining tooling. And don't even get me started on monorepos.
At a previous company, a co-worker that had been setting up tooling infrastructure for a project was astonished at my iteration speed when he saw that mine was written with just a micro-framework and ES5. Conversely, when I had to jump in to help get his project back on schedule, we could never figure why the hot reloading setup had a 2 second delay on my machine (among other things).
Having worked on two projects of very comparable scope (two documentation sites for different projects), one written with the "latest and greatest" Gatsby and friends, and the other with just a dirty script, I honestly can't see any reason to do the former: it takes longer to do anything, the final payload is bigger, and now the codebase is using a version one major out of date, meaning a migration looming in the horizon. On the upside... GraphQL; yay I guess?
With this point in mind, your carpenter analogy seems a bit off IMHO. Of course, consumers don't care if the carpenter uses an electric screwdriver, but they do care if a knob gets loose and falls off because it was held by a single rushedly-drilled screw. Also, the employer should presumably be worried if said carpenter keeps spending a significant portion of his time sanding his hammer handles and replacing his workbench legs, or needs another carpenter to do so on an ongoing basis.