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...
YES! It's so annoying how few people understand this. People are never "in a tax bracket" -- only money is!
Your first $40k may be taxed at 10% and your next $20k may be taxed at 15% or whatever, but you are not "in a tax bracket".
The idea of being "in" a tax bracket gave rise to the dumb idea that making more money can net you less after taxes, which is virtually never the case.
Sorry, but it may be dumb, but it's true. Making more money can lead to less take-home pay. One really good example is if you hit the AMT (alternative minimum tax.) "Your money" is not in the AMT-- you are. And it often means that a raise can end up costing you money. There are also similar situations where getting a job can mean losing out on welfare, leading to you actually having less money to take home.
Yes, the AMT is the one case where you could end up with less take-home. Its an exception to the normal functioning of the tax code, though, and it works by prohibiting most permissible deductions. Thus, while the statement about the AMT decreasing take-home with increased is factually correct, this does not happen through the bracket system. GP was clearly addressing the misconception that people move into tax brackets and must pay higher tax rates in all their income as a result.
Your welfare example has nothing to do with taxes. Welfare benefits are set by gross income level with some COL and other local adjustments. Your tax status is irrelevant.
There are a ton of places in the tax code where making more money results in you keeping less of it. For example if you sell more than X dollars worth of goods on eBay, you have to start paying tax, which will cost you dear. So the jump from X to X+1 ends up costing you. I think X = $500, but maybe they changed it.
The IRS even reduces your taxes if you lose money in the stock market, if your business property depreciates, and so forth. I like to refer to those cases as "the government paying you to be a loser." Just another case where doing better means you do worse.
Let's not even try to pretend this is a fair or well-designed system. Even Warren Buffet, surely one of the greatest beneficiaries of the system, has spoken out against it.
This is absolutely false, making more money can make you subject to the AMT (and potentially a higher marginal tax rate), but you will never be in a situation where if you make an extra $1000 you'll owe an extra $1001 in taxes.
This is correct, and worth pointing out, because the OP has this line:
>So now you owe an extra 10% on your $40K salary which is $4K. And you also owe 35% on that $50k which is around $18K.
Which is false. The extra 50k is taxed more than your first 40k. Your overall effective tax rate increases, but it's incremental. Your first 40k is taxed the same with or without the extra 50k, but the extra 50k is taxed at a higher rate because it's in a higher marginal rate.
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.
The tutorial section looks much improved over previous visits - good job.
Two points:
1. The tutorial shows using the CDN, then there's big warnings saying "don't do this in production". Give another demonstration of the "highly recommended" approach vs leaving people to piece that together themselves.
2. "we tend to not go crazy over every small feature". What's a small feature to you may just be something that 80 people have been waiting patiently for. While you can often judge what a 'big' feature is by your standards, dismissing many other things as 'small' probably misses a lot of people.
Point 1. is indeed a "uncomfortable" part of dojo. Getting started is difficult. For a lot of demo and hello world like apps CDN version is fine, assuming they are only using the modules packaged into dojo.js on CDN. If you start using other modules, then you will soon see a escalating number of HTTP requests, and for this reason using CDN version for production is bad idea.
Its just not that easy to get started with and get a sane production build from dojo yet. Hope all of this will change by the time 2.0 is out.
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.
I recently did a project using Dojo (1.7) and my coworker told me that it 'lost the war' against jQuery. Having worked with it, the documentation was absolutely horrid (which they no claim to have somewhat resolved). As for popularity, it is a Catch-22 - it's not used very often and so no one is willing to learn it and people don't learn it, so it's not used very often. From the same website showing jQuery is on 50% of websites now, you can see that Dojo is absolutely abysmal in popularity and usage:
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.
Unfortunately, you cannot load Dojo with other AMD loaders. It has shims and features within its dojo.js that prevent's other loaders from being able to use it; dojo can load other AMD modules but not vice-versa.
Also, the comparison of FF/IE and Windows/Mac, the argument is flawed - the underdogs came out to fix problems with the status quo. Dojo does not provide significant benefit over jQuery or similar tools to warrant switching frameworks.
"Dojo does not provide significant benefit over jQuery or similar tools to warrant switching frameworks."
This is not correct at all. Compared to jquery, dojo is significantly better option for large projects. Dojo has a very rich unified set of widgets, jQuery has plugins, but they do not play well with each other. Each jQuery plugin is unique, with no standard way to extend them. I can extend any dojo class and in a very uniform fashion.
It is possible to do write good code in jQuery, but a vast majority of them are not, jQuery is like PHP, a haphazard mix of functions that do something. Dojo is like Django etc, with everything thought out from start to end, everything gels together.
Or at least that is my initial impression, would love to know why you believe the class system, the AMD modules, the rich widget library, storage framework, MVC framework, i18n, etc offered by dojo is no benefit to you?
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.
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.