I'm not disagreeing, but one thing that makes this different is you can easily fix most Bootstrap bugs by overriding it with some custom CSS, or just not use that class. It's different than some deeply integrated code that you have to patch and maintain.
"you can easily fix most Bootstrap bugs by overriding it with some custom CSS" vs. "you can easily fix most [imperative/OO/functional programming language's library] bugs by overriding it with some custom [code]"
and
"just not use that CSS class" vs. "just not use that [method/function/class]"
An contrived example: let's say an unfixed Bootstrap 3 bug is that there is a formatting error when rendering "div.jumbotron > h1 > span.label > small". You could replace the last small with you own css class and be done.
Contrast that to a bug in Angular, for example, that enabled a XSS bug. You'd want to upgrade Angular, instead of manually patching or adding a workaround to all your forms.
This reminds me, a few years back I was reading the code of a few different obscure libraries. One of them had a primary process that would spawn different worker processes and kill them off if certain conditions were met. No joke, the primary process was named "Hitler".
As someone who has created templated subclasses with both private and public virtual inheritance, I don't think that's a bad thing. C++ is wildly powerful, but it's a mess, and most people should stick to easily understood idioms/patterns, for the sake of maintenance if nothing else.
I have a love-hate relationship with nginx. I love that it's fast and rock solid. But recently I keep on getting tripped up when the directive I'm trying to configure is only available in the paid plan, the pricing of which puts it out of (my) reach.
Also, there really should be separate docs for the open source vs paid plan.
That said, I do plan on kicking the tires on the HTTP/2 support.
> the directive I'm trying to configure is only available in the paid plan
Sadly, this is how the developers of nginx can earn and continue to make good software. Some of the new features in this release has been directly supported by the commercial edition, and some has been open sourced after being made for the commercial edition because clients demanded them.
Also, the nginx team is open to a feature being sponsored by a third-party, non-client in order to add it to the open source edition. Some of the significant features in nginx have been built this way (http/2, spdy, websocket support etc.)
If nothing, even patching or writing modules for nginx is not that hard (assuming you know how to develop, and in C). It is one of the more well-designed codebases. (Some others are: Redis, Postgres, Git).
> there really should be separate docs for the open source vs paid plan
I thought nginx.org contained only open-source info, save for an occasional ad about the paid offering. Is there any documentation on nginx.org that doesn't apply to the open source edition?
I may not have been clear, but I understand and fully support their right to charge for software and services. I just haven't worked on any projects for which their prices fit in to the calculation.
But a benefit might be cross-platform compatibility seeing as some OSes don't come with, say, grep out of the box. While you could use the native tools, there could be some benefit to writing your own to do exactly what you want consistently.
I don't really disagree with you, but just pointing out there is some benefit to writing one's own CLI.
I am still holding my breath for Windows 10 to start including more and more Unix tools. We finally have ssh to be included with Windows 10 and having tools awk, sed, grep on Windows seems like a logical move for Microsoft EVENTUALLY.
For now I use vagrant all the time when I am on Windows.
Sure if you want a full set of native tools I won't suggest otherwise. But a full cygwin install is way more invasive than node, and if you just want some specific tools, vorpal might be for you. Or maybe cygwin is. Whatever works for you.
