[dojo-contributors] what is the raison detre for dojo 2.0.
ttrenka at gmail.com
Thu Oct 11 17:05:35 EDT 2012
/me shakes head
On Thu, Oct 11, 2012 at 3:33 PM, Sasha Firsov <suns at firsov.net> wrote:
> The development patterns used for "simple" developer and "enterprise"
>> not just different but mutually exclusive. That is what I tried to say.
> Indeed, you are entirely wrong about this. There is nothing mutually
> exclusive about it.
> It is. And we have proven history in favor of "enterprise":
> - chaining was dismissed in multiple cases due to extra "return this;" in
> each call. Do not say that chaining could not be *more* than used than
It could. And in situations where it makes the most sense, it should.
> - variable function signatures. I.e. ability to pass arguments of
> different types, intelligent defaults, etc. Was cut off due to performance
Yes, particularly with early versions of dojo.connect. You see, its not
just the patterns that need to be paid attention to; its the performance of
those patterns as well (which btw, was also an early implementation of AOP,
which itself was dropped because of performance reasons.)
> - packages with dot notion in favor of AMD.
As I mentioned in the last email, I was the one that actually came up with
the idea of using JS objects as faux namespaces, and after analyzing the
improvements in both performance and approach with AMD I am fully on board
with it. Is this a problem for you?
> I am not sure how to make clear that friendly to developer and proper for
> "enterprize" are essentially different requirements.
> If you could recall I have been backing some kind of compromise by
> introducing aspects earlier days and API facade recently. But those just
> confirm how the "enterprise" requirements dominating in DTK decisions.
It depends on what you mean by "enterprise". If you are referring to the
idea that a codebase needs to be robust and try to prevent developers from
doing stupid things, I can understand where you are coming from (although I
don't and have never agreed with that approach). If you are referring to
the idea that the core libraries upon which things are built happen to be
just as easy for (in your terms) a "simple" developer as well as an
enterprise one...at the cost of one or the other...I don't agree at all.
> While I don't like your dichotomy between "simple" and "enterprise"
> developers (since in my experience most enterprise developers are actually
> one step above what you term as simple), I'll put it this way: *both* sets
> of developers are looking for one thing. A simple way to accomplish what
> they need to do in the quickest, simplest, easiest ways possible.
> You are wrong. There are many reasons further: reliable code, feature-rich
> complete code and UI, maintainability and so on.
> And if you are not just a UI developer you would care about coding
> discipline, high-level patterns, integration with other tiers.
> Among those "quickest, simplest, easiest ways" not just lost but removed
> as they going against good development practices.
This is an incredible pet peeve of mine, and I don't mind admitting it. I
have found that what you refer to as "patterns" cause many more problems
than they solve unless you happen to be developing against that almost
exact pattern. There is nothing wrong with good, careful integration.
There is also nothing wrong with building foundational approaches based on
the 7 years of experience we have in writing and maintaining the Dojo
> I am not saying that your reasons are not valid. They just belong to
> "simple" approach. And I do not see the ability to sneak it into DTK.
Your description of "the simple approach" seems to be both arrogant and
ignorant. There are many different ways to approach problem solutions;
each approach should be tailored to the situation and NOT determined by the
skills of the person(s) solving them. I think this is the fundamental
point that you are not getting. What I have to bring to the table for
discussion is 15+ years of development experience working in all kinds of
environments (including being one of the bigger influences on the original
structure of the Dojo Toolkit), and my arguments are uniquely formed based
on that breadth of experience. And I am trying to make it clear that you
simply don't dismiss people you term as "simple" developers. Quite a few
committers started that way(as "simple" developers) and used their
experiences with the Dojo Toolkit to learn and evolve.
Are you suggesting that they be ignored now?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors