[dojo-contributors] what is the raison detre for dojo 2.0.
dylan at dojotoolkit.org
Thu Oct 11 14:19:23 EDT 2012
-----BEGIN PGP SIGNED MESSAGE-----
That perception exists because for much of our history, it was the case.
And it's certainly easier to just include a script file, use a single $,
As Colin said, when you start moving beyond those simple cases and need
to organize your code, that's when people start looking at Dojo or other
To revisit our history of failed marketing in the past:
* We were slow and difficult to use (0.2-0.4)
* We had a bad web site and incomplete and hard to follow docs (0.9-1.2)
* We did a major rewrite that encouraged people to decide on their next
* We had performance problems and API inconsistencies and hard to theme
* We lacked easy to understand docs, and had the weight of namespaces
* We had an incomplete transition to AMD that made documentation and
consistency of comprehension a challenge (1.6-1.8)
Even with 1.8 being as amazing as it is, the APIs are still
inconsistently used within our toolkit. Look at on vs. connect, xhr vs.
request, charting widgets which don't work with data-* attributes for
nested inline definitions, etc.
Today, the challenge we struggle to market with is that things are much
easier and much better documented, but it's still too easy to run into
problems without finding easy solutions, and many of our APIs still make
For 2.0, I'll say it again:
* We need 2-3 sophisticated, beautiful reference apps that make solid
use of our APIs (look at how much dojox/mvc improved by the ToDoMVC
work). They should include step by step tutorials, and the APIs
shouldn't be considered done until those apps feel like they are hack free
* We need to approach perfection on our docs. We're much improved, but
if everyone spent an hour a day on average, we'd be close to perfection
with what we have today by the end of the year.
* We need to leverage the best possible base, so we are supporting the
newest and greatest stuff, while not forgetting about the majority of
the market. To me, this means IE9+ and latest of other browsers for 2.x
(1.x can live on for people that need IE 6-8 for a few more years). Not
that we should intentionally break things, just that we shouldn't go our
of our way to support or test on earlier stuff
* We need to add value by making it easy to test, document, build,
optimize, and create with Dojo. Lots of great ideas out there, but until
it's as easy to assemble your dojo app as it is if Dojo was included as
one big package, we've just moved the burden to end users
* We need an active evangelism team to champion all the fine engineering
work we're going to do.
Bottom line, we need a lot more active help than we've ever had to pull
it off, and then, we need to get focused on the things that matter and
get there, rather than spending all of our time rehashing and debating
things forever, so we can ship something amazing next year.
on 10/11/12 11:04 AM (GMT-07:00) Rawld Gill said the following:
> Agree completely. My main reason for bringing up JQuery yesterday was
> because there are lots of people who think JQuery is easier than Dojo
> for certain tasks and have therefore selected JQuery over Dojo. I want
> to understand why that perception exists. And that question applies to
> any competing library that purportedly does something better than Dojo
> and has convinced a significant set of customers as such.
> If the reason is ?we can?t do what library X does because it implies a
> penalty to do something we really care about?, then that is at least
> rational. But I have yet to see an example of such a penalty.
> *From:*dojo-contributors-bounces at mail.dojotoolkit.org
> [mailto:dojo-contributors-bounces at mail.dojotoolkit.org] *On Behalf Of
> *Kitson Kelly
> *Sent:* Thursday, October 11, 2012 8:24 AM
> *To:* dojo dev.
> *Subject:* Re: [dojo-contributors] what is the raison detre for dojo 2.0.
> On 11 October 2012 15:39, Rawld Gill <rgill at altoviso.com
> <mailto:rgill at altoviso.com>> wrote:
> I'm sorry to be a pia, but can you/anybody please give a couple of
> examples of things we should *not* concern ourselves with. Or,
> equivalently, areas where we should *not* compete.
> My opinion, which I think others maybe getting at is that we shouldn't
> be driven by where we are at relative to other toolkits. We should be
> driven by what we technically need to create the applications we
> consider our "target market". I know you aren't specifically arguing
> competing feature by feature against others, but I think in a way that
> maybe what people are hearing.
> It is always good to "sense check" against the others, look at what they
> are doing right and wrong. But if the main driving force for having an
> easy to access DOM manipulation API is because JQuery has one would be
> wrong. We should have an easy to access DOM manipulation API because it
> is also needed to hack together a website, but again, that shouldn't be
> our motivating raison d'être.
> Having features, functionality, APIs to complete against others is not
> of interest to me personally.
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the dojo-contributors