[dojo-contributors] what is the raison detre for dojo 2.0.
suns at firsov.net
Thu Oct 11 20:00:29 EDT 2012
On 2012/10/11 2:05 PM, Tom Trenka wrote:
> /me shakes head
will add to dictionary.
> On Thu, Oct 11, 2012 at 3:33 PM, Sasha Firsov <suns at firsov.net
> <mailto: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 now...
> It could. And in situations where it makes the most sense, it should.
Your problem is what is criteria for most sense?
For "simple" guy it should be on usability side, on "enterprise" - on JS
There is no compromise. Pick your side. Mine is on "simple" and JS
performance to be resolved by compiler. Which is a dream of course.
> - variable function signatures. I.e. ability to pass arguments of
> different types, intelligent defaults, etc. Was cut off due to
> performance reasons.
> 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
Here you are on "enterprise" side again. May be it is time to stop to
goof around and make your mind what is more important?
Just a reminder, you are backing "simple" developer :)
> - 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?
For me - absolutely not. I am all for full-scope AMD. including css!,
xml!, json! and other AMD -driven development patterns.
But it is enormous burden for "simple" guy. And also quite inconvenient
approach as opposite to "include all" approach. If you are on the
"simple" side, than be logical and support auto-load modules, have "all"
bundle and so on...
> 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".
"enterprise" is about quality. Of design, code, JS performance, docs,
tests, practices. Not about novice vs. expert as you trying to endorse.
Not about scale of project.
> 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.
Good. Because early you sound like that.
>> 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 Toolkit.
> 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.
I do not see not arrogant nor ignorance in post. In fact I was backing
"simple" in all possible ways - from trying to convince to offering
The "simple" library need to exist. Same for "enterprise". While on
first we have some competition JQ, underscore, etc. On enterprise there
is a vacuum which DTK fills to certain level so far.
> 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?
Yes. They do need rapid development tool. Which allow to do fast
prototypes for cost of quality, code speed,etc.
Once they or project will come to the level of maturity they will be
converted to "enterprise" on their own.
There is no shame to be beginner or an expert. And should be a clear
path for such transition.
If miracle happen, 2 libraries should appear: simple and enterprise. If
they will reuse many aspects starting from docs and build/repository
structure, transition will be less painful.
Also "simple" does not mean useless. Expert will choose it for
appropriate situation like prototyping.
But most of "simple" principles do not fit "enterprise" and vise versa.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors