Why can't I write code inside my browser?

No, I do not think you have understood my argument.

There is only one word for someone, who approaches a topic they know little about, and suggests that its rubbish and he knows better.

That word is 'arrogant'.

And you are correct, I have no sympathy for arrogant people.

> The author is lazy, and is channeling his energy into complaining rather than learning.

I don't know about that. The author is certainly confusing programming with setting up a development environment. I can understand why they would be frustrated with the latter, since it takes away with what they are trying to do.

When I started out, the latter was fairly simplistic: computers booted into BASIC. If you needed something more sophisticated, you could buy an IDE where everything would run right off the boot disk or after an automated installation. You can still find those tools, designed to serve everyone from home users to professional developers. That being said, it seems to be much less common.

In some cases, like web development, that makes sense. The target is a standard rather than an operating system or hardware architecture. In other cases it is self-inflicted. When you choose to work with third party libraries, there is a much higher probability that some work will need to be done to integrate it. Then there is the WTF category.

Take one of the easier cases: Java. Even though the development model is much closer to traditional languages like C++, the most common use case will involve installing an IDE and the language separately (possibly with some tweaking of the environment). That's not too bad, but it's likely more than people want to see when they want to get their tools up and running. Contrast that to C++ on a commercial operating system: you install Visual Studio or Xcode and are ready to focus upon programming for the chosen platform.

Of course, C++ isn't always like that and it comes close to representing the other extreme. Setting up development tools for microcontrollers can be quite the task, particularly if you choose the "wrong" one. That's a good part of the reason why novices like Arduino and Platform IO, it makes going from nothing to a functional IDE fairly straightforward.

Now I'm not going to say that the author is right, but I will admit that they have a point. Presenting Unix-isms in a macOS installer is going to rub some people the wrong way. That should have been addressed in a better manner. On the other hand, they were also attempting to accomplish something that is non-trivial to start with.

That's a fair argument to make, however i'm not sure that i'm able to entirely agree to this.

> While good developers think about each one and try to find a minimal set of them.

(tl;dr at the bottom, things up to "In short, " are merely my experience, which is entirely subjective)

For example, suppose that i'm working on a Java project and i want to do some non-trivial operations with the filesystem. In this instance, my options for implementing the functionality would be as follows:

    1. Attempt to do it myself by using the standard library
    2. Attempt to find a really specific library that allows me to do what i need
    3. Attempt to use one of the larger libraries out there, that provide a variety of related functionality, which may or may not be useful

Each of them definitely should be evaluated, but for the most part, i've found the following to be true about these approaches:

1. Attempt to do it myself by using the standard library

    + Will be easily customizable, because no source/recompilation will be necessary for an external library (though mostly a problem of the toolchain and approaches to including libraries).
    + Will result in a small distribution size, since there won't be redundant code included.
    - The code mostly won't have good test coverage, since i cannot spare the time because of business/bosses needig functionality ASAP. Neither will i be able to address the technical debt that might arise from this solution, or throw out a sub-optimal solution and rewrite it until i get it right. Ideally this wouldn't be a problem, but i'm afraid that this is usually the case.
    - The documentation will be sub-par, since code itself doesn't provide many mechanisms for showing examples on how to use it (as opposed to a Wiki/sandbox), even in the case of "self-documenting code", non-trivial concepts will still require code comments, which will also need to be kept up to date by someone who'll need to edit the code. Onboarding will be more difficult, because initially noone will be familiar with the solution.
    - Time spent creating bespoke solutions will prevent me from implementing other solutions and addressing other concerns with the limited time i have. In addition, bugs could arise, since i'd miss certain aspects that people who are more proficient in working with IO would notice and address.

2. Attempt to find a really specific library that allows me to do what i need

    + Will result in a small distribution size, since there won't be too much redundant code included.
    - More often than not, minimal dependencies can result in many of the above problems (especially problematic with documentation, since i wouldn't even have had written the code in the first place).
    - In addition, minimalistic solutions often have relatively few contributors, which can result in them becoming abandoned some time down the road. Maybe not too important for small libraries that can be rewritten, but eventually you'll end up with unmaintained dependencies which will need addressing.

3. Attempt to use one of the larger libraries out there, that provide a variety of related functionality, which may or may not be useful

    + Will usually be actively maintained (for example, https://github.com/apache/commons-io has 70 contributors and 360k users).
    + Will usually also have reasonable test coverage (the library above has 89%, according to GitHub)
    + Will usually have a rather good documentation that's updated by others (sometimes in the form of a separate website, like https://commons.apache.org/proper/commons-io/)
    + Can easily be Googled with plenty of common problems (some of which are almost inevitable) addressed. This will also help others, who need to work with said code.
    + Maintenance and technical debt won't need to be addressed in house. Oftentimes it'll be as easy as bumping up the version number and running the tests surrounding the integration (if any exist).
    - Will probably include lots of bloat, which may or may not have a significant impact on the bundle size of your project.
    - Will most likely increase the attack surface of your project in some way.
    - Will also be difficult to audit and really get to know in entirety (if not impossible).

In short, i don't think that how "minimal" dependencies are should be the deciding factor when choosing them, but rather the results of deliberation of the points that you've described above. In my experience, i've found that more often than not, counting on existing and popular frameworks/libraries/approaches is the best way to go. Though this is from the perspective of someone creating mostly business oriented solutions for external clients, thus i'm biased because of time/resource limitations and such.

There was actually a rather humorous presentation a while back and while the best video i can find of it is still in pretty bad quality: https://youtu.be/AUYPnxv0yss (couldn't find the exact timestamp) one of the things that stuck to me was the suggestion that you should use whatever language/tool/framework that your friends/colleagues use, if possible. Essentially - use boring technology, that will be easy to reason about and that will help you more often than not.

> But isn't using the code that people smarter/more proficient than you have developed a rather good way to go about things?

Many problems don't go away and don't become easier just beacuse you shove them under the carpet into a library. A lot of developers use libraries as an excuse to NOT THINK about the issues and ignore their existence not to save work. There's a fundamental difference between "I understand the problem and I know that library X will give me a good solution with low amount of work" and "This problem is hard, I'll shovel in another library and keep my fingers crossed that it does a good job at it."

It's saving work vs. saving thinking. First one is ok. Second one is not.

That's like people expecting to be able to repair their TV with their remote control.