| The distinction you start with between stack and tool-chain is fair, so let's cut out photoshop and illustrator. However, the three mentioned browsers are certainly part of the stack, and the browsers are the ones executing the cycles of anything running in the front end, which these days is a lot. Nearly all projects are literally targeting all of these disparate browsers. To cut a long story short: when you say "What you're implying is that you're too impatient to do engineering but you're willing to be a programmer (or hacker)" - this is correct. The only way for many people to get projects off the ground is not to engineer them, but just to throw them up. By the by, I actually in a couple of spare hours toyed with the idea of formalizing this into a project, where we would teach some valuable skill in 15 seconds. (I applied to a YC fellowship with it but wasn't selected.) Here's my prototype - (it autoplays 15 seconds of sound, you've been warned.) http://iknowkungfu.meteor.com I didn't write the tutorials up there now, and many of them are too long. But the idea is there: in a few seconds, you can often learn and incorporate something into your stack that you know next to nothing about. Do this a few times and you have a complete web app serving dynamic, database-backed content - and you've still been able to focus on what you know rather than engineering. There are 3 billion people out there who deserve to use some of the tools that are available. You, too, deserve to use some of the modern frameworks that are available. Without investing hours, days, weeks of your time into it. I know lots of technologies whose basic usage could be uploaded to someone's brain in 15 seconds of video. Git, to name one. No, you won't understand how it works or why - but you can commit and roll back (reset), which is all anyone cares about until they start caring more. The advantage to using the git that you can learn in 15 seconds, over copying files and continuously renaming them - is - simply put, astronomical. Many parts of the toolchain, and many layers of the stack, are quite similar. Who knows what cycles MongoDB is running? Who cares? |
I basically agree with everything you've said (in both posts) ... you can be successful while wasting cycles. And if you're working on a low-volume and/or internal only application, you'll probably never face the limits of a modern server.
If you need to operate "at web scale" [1], or run into an uncommon (or common) bug, you'll need to know more about the frameworks and systems you're code relies on (e.g. MongoDB configuration for systems over 2GB [2]). Blog posts like the one referenced are completely unfair to those that developed MongoDB - read the manual and understand how MongoDB works OR use it at your own risk.
So I'll switch arguments and help you make your point. We have an application written in Oracle's Application Express - while we have extensive expertise in Oracle's database software, we have this one system which was completed for expediency's sake. It's kind of horrific but (mostly) works at the scale required. It would be financially foolish to dig into more deeply into ApEx for this one dead-end application. Everyone is happy.
[1] https://www.youtube.com/watch?v=b2F-DItXtZs (audio NSFW)
[2] http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...