The feedback is interesting, but I think it helps to understand more of the history to get that most of the negative feedback here is overreaction. Some thoughts:
* No, the foundation isn't trying to dominate or tell people what to do. It's trying to support open source projects through their lifecycle. Running a project can be a rather lonely and frustrating experience at times, but can also be very rewarding
* Open source foundations provide legal protection to individuals and corporations that contribute and use open source software, and help ensure that one company or person doesn't turn evil and try to pull the carpet out from under the community (which has happened many times in the history of OSS)
* Regarding standardization, the foundation has members on TC39, W3C TAG, etc. Helping with standards is time consuming (and something I personally don't want to spend any time on), but it does help to gather ideas and have a way to contribute in a smaller way to the process
* As a foundation, we don't require any project to merge or conform with another. We have 3 testing tools (Intern, Mocha, and QUnit) which all have different philosophical approaches. But there are certainly things we could collaborate on, inside or outside the foundation.
* The foundation is not a place for projects to go to die. For example, many think of Dojo 1.x as old (because it's been under active use and development since 2004), but if you look at the work being done on Dojo 2 ( http://github.com/dojo/meta ), you'll see that it's on its way to reinventing itself as a modern TypeScript based approach to building web apps.
* Over the years we've worked with many large companies, and it's important to remember that companies are made of individuals. These companies have behaved on the OSS front in a very helpful manner (and I'm a huge skeptic in general). IBM has contributed as much over the years to JS OSS as anyone out there. The amount of help they provided in a11y and i18n is second to none, and they've helped Dojo, jQuery, PhoneGap/Cordova and others in significant ways.
* The list of founding members is smaller than we would have liked, but many times, you need to put something out there before people will join (it's more difficult to convince someone to sponsor something not yet announced than something fully baked). And just because you haven't heard of a company doesn't mean they don't do interesting and important things. The goal was not to just get a bunch of large companies to push their logos, but to get a group of people that care about the open web involved.
Overall it seems like the community loves to hate on things out of FUD (nothing new), but really we're just a group of people that create OSS that solves problems we have as developers. Really we just want to help, and a foundation is just one way to encourage collaboration.
I've been feeling similar to the way you feel for about 9 years, but with Dojo rather than Cappuccino. I stopped worrying or caring about fighting trends I cannot control years ago because it doesn't matter. I focus on building a toolkit that people use to build apps that require solid architecture and APIs. If I spent all of my time listening to or worrying about every critic or every person that doesn't get the power of having something more robust, then I would never make progress and would fail our users. You're not alone in your perspective. And yes, we were indeed all impressed with 280 Slides when it first launched.
Being in a higher tax bracket doesn't lead you to pay more tax on your initial income, only a higher rate on money above a certain threshold. That said, the article is right in that an S-Corp or LLC sound right and are rarely a good idea because you sometimes lose out on certain tax deductions because your personal income is too high. Remember though, a tax bracket is a sliding scale... see the margin tax rates table at https://en.wikipedia.org/wiki/Income_tax_in_the_United_State...
The latter point is your opinion, but certainly many developers actually believe it does.
Dojo has plugins for localization and text loading that are needed for certain features. You would need similar capabilities in other AMD loaders for them to work. I believe it's simple enough to get most of Dojo working with RequireJS, or with Curl.
Dojo is used in more than 80% of the world's 2000 largest companies. Yes, it's not the default toolkit for WordPress or other large blogging and microsite platforms (which dominate the number of sites on the web), but Dojo is used far more than the numbers indicate. For every 10,000 basic sites, there's an impressive app out there that makes use of it. As I've argued before, if Apple had given up to Microsoft because everyone used Windows, or if Firefox had given up because everyone used IE, the world would be a boring place. With AMD, it's less about Dojo vs. other toolkits, and more about how to use toolkits together in an efficient modular manner to build the app you need.
Check out the new docs. I think it's no longer reasonable to say Dojo lacks good docs or reference code.
Marketing is challenging for engineers. We tend to not go crazy over every small feature, but focus on the big stuff. That said, we're improving our approach.
Popularity is fickle... things that are new and sexy get more buzz, things that are solid and reliable and powerful get used a lot, but don't receive as much hype.
That's fine. Dojo doesn't make this decision for you. Instead it gives you a full range of tools to choose for yourself how you want this to work.
Some UI widgets (Dijits) choose to use a client-side HTML fragment, but others do not have that requirement. Some of the work on projects like xstyle and put-selector seek to reduce this reliance further.
Dijits can be invoked either through extra markup in your base HTML page, or through a JS constructor. In the HTML templated widgets, there are attributes that bind DOM nodes to reference variables in your JS, so the widget knows where to insert content, or subwidgets, etc., and where to attach DOM events. The HTML isn't stored in JS, it's stored in an HTML file that gets combined through build tools (so you don't need to do this mix in process, it just works).
But again, that's an optional feature that's used primarily by the widget system and some of the widgets in Dojo.
That's one of the major things that 1.7 fixes and 1.8 will fix even further... smaller modules and finer-grained dependencies so you aren't pulling in nearly as much base code for each feature.
https://plate.udecode.io/ https://github.com/udecode/slate-plugins
Similarly, there's slate-yjs for integration with yjs, and so forth.