Sproutcore Guides - Advance Bindings

[Veebs]

Hi,

I've found binding transforms and custom transforms very useful in my
app. Thinking others may find it useful as well, I copied and edited
that section from the wiki and put it into the guides. I submitted
pull request: https://github.com/sproutcore/sproutguides/pull/54

I added my new section in to "Core Concepts" underneath the current
section on bindings.

Peter Wagenet suggested that the new section on special binding types
seems beyond the realm of "core" concepts. I agree with Peter.

How should we move forward on this?

1. Should we create a new guide called "Advanced Concepts" and put the
new section on binding transforms in there?

2. If so, should anything be moved from "Core Concepts" into the new
"Advanced Concepts" guide?

Thanks
Veebs

[Peter Wagenet]

The other alternative I see is to make a series of smaller guides that
expound on single topics in Core Concepts. We could have a bindings
guide, a RunLoop guide, etc.

Any thoughts?

-Peter

[Adam Hawkins]

I second smaller more focused guides.

[Topher Fangio]

I agree completely. I think it would drastically reduce the learning curve, and I think it is more in-line with what a guide should be: a quick point of reference that is more than JSDocs but less than a user manual.

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Veebs]

OK.

Any suggestions on where the smaller guides should sit?

How about a new "Runtime" section as illustrated below? Core concepts
will them be a short introduction rather an the currently lengthly
description.

Guides
- Start Here
- Install
- Getting Started with HTML-Based Apps
- Getting Started
- Core Concepts
- Runtime
- Objects
- Observers
- Bindings
- Run Loop
- Errors
- Models
- Views
- etc....

[Topher Fangio]

That looks excellent to me. Any thoughts from the Documentation or Core teams?

Sent from my iPhone

[Tom Dale]

This seems great. I'm not sure we should cover the run loop, though—IMO it should be a transparent concept to most users.

[Richard Klancer]

On Thu, Apr 21, 2011 at 2:32 AM, Tom Dale <t...@sproutcore.com> wrote:
>
> This seems great. I'm not sure we should cover the run loop, though—IMO it should be a transparent concept to most users.
>

Disagree. Runloops come up the minute you have an observer that does
something wrong because it accesses a bound value which is
inexplicably stale even though you clearly *just* set the other side
of the binding. (One might argue that a good developer will architect
code to have this problem only rarely. But the guides are *for*
newbies.)

Runloops also come up the minute you write a test or spec. And
certainly we don't want to discourage test-minded developers.

Cheers,

--Richard

[Tom Dale]

This sounds like a bug in SproutCore. How would an observer fire if you haven't changed it? I've never seen that happen. Can you provide a unit test so we can fix it?

[Richard Klancer]

Hi Tom,

Not to worry, I don't mean anything quite so exotic as an SC bug.
Sorry if I was unclear.

I was just referring to something I tripped over a few times when I
first started with SC.. Observers fire immediately. Bindings sync at
the end of a runloop. During a single runloop, you might set the far
side of a binding, then set a value which fires an observer. When
observer get()s the near side of the binding, it will obtain a stale
value because the binding sync has yet to happen.

Simple example in the console:

a = SC.Object.create({b: "old value"});
c = SC.Object.create({ bBinding: 'a.b' });
SC.run();
a.addObserver('d', null, function () { console.log("a.b is %s; c.b
is %s", a.get('b'), c.get('b')); });
c.addObserver('b', null, function () { console.log("c.b changed to
%s", c.get('b')); });
SC.run( function () { console.log('begin'); c.set('b', 'new value');
a.notifyPropertyChange('d'); console.log('end'); } );
console.log("a.b is %s", a.get('b'));

yields:

begin
c.b changed to new value
a.b is old value; c.b is new value
end
a.b is new value

It's well worth noting that this difference was a source of confusion
for me when I started, and is likely to be for others as well.

--Richard

[Erich Ocean]

On Wed, Apr 20, 2011 at 11:32 PM, Tom Dale <t...@sproutcore.com> wrote:
> This seems great. I'm not sure we should cover the run loop, though—IMO it should be a transparent concept to most users.

Sorry, that's just nonsense. Every SC developer is better off being
introduced to the run loop from day one. It is fundamental to what
makes SproutCore a *framework* and fundamental to it's correct and
efficient usage.

Best,

Erich Ocean
SproutCore Training and Mentoring
http://erichocean.com/training/index.html
http://erichocean.com/mentoring/index.html

[Tom Dale]

If understanding the run loop is fundamental to correct and efficient usage of SproutCore, that is a failing on our part. Books on Cocoa don't introduce run loops at the beginning, nor do books on web development. (As you know, browsers use a run loop too but none of us spend much time thinking about them.)

This attitude of forcing people to front-load complexity when learning the framework can be directly correlated with our current low adoption rate.

[Johannes Fahrenkrug]

Just as a piece of information: Cappuccino also uses a run loop and that fact is rarely mentioned, especially not in beginner tutorials. That being said I'm not against _mentioning_ early on that a run loop is being used, but the internal workings of a run loop are not essential for a beginner to get started with SproutCore. It's an architectural implementation detail of the framework. Granted, an important one but not essential to grasp to get started. Just my 2 cents.

[Erich Ocean]

On Fri, Apr 22, 2011 at 1:00 PM, Tom Dale <t...@sproutcore.com> wrote:
> This attitude of forcing people to front-load complexity when learning the
> framework can be directly correlated with our current low adoption rate.

It sounds like you are suggesting that I am somehow directly
responsible for SproutCore's current low adoption rate. Interesting.

I do not find the run loop complex, and knowing that SproutCore
buffers things until particular times *IS* fundamental to
understanding SC and developing with it. Hell, Yehuda gave an entire
talk about this a few weeks ago (posted the slides on Twitter).

Sorry you find them so complex. I personally haven't fielded a single
question about them after spending 5 minutes explaining what they are
and how they work. I do field problems and misunderstandings related
to the run loop if I don't, as others on this thread have helpfully
pointed out. You seem to want to keep me gainfully employed. :)

There simply is no such thing as a 100% transparent run loop unless
you intend to never buffer anything. If you intend to buffer, you have
to tell people you're doing it. The "run loop" is the class in
SproutCore that does so (and bears only a passing resemblance to
NSRunLoop in Cocoa, for those of you talking about Cappuccino and why
it's not discussed there).

So fine, if you don't want to say the phrase "run loop", at least
explain that SC buffers bindings, drawing, etc. until later. That's
all the run loop is anyway.

[Gregory Moeck]

So I agree with you Erich that the runloop is important to the framework. That fact that we buffer changes (particularly to the DOM) is a fundamental performance optimization. But the end of that sentence is important. It is largely a performance optimization. Which is why Yehuda talked about it in a talk on performance, but hasn't mentioned it in any of his introductory talks. 

We have largely followed the approach of "If you intend to do X, you have to tell people your doing it", and I think it is part of the reason that people feel so overwhelmed when they first come into the Sproutcore world. They have to take in and absorb 20 different things at once, and particularly with web programmers they generally just won't take the time. 

When someone sits down to learn Cocoa they're willing to take a book and read it over a weekend to absorb the concepts. But for better or worse the web developer isn't that way.  The web developer wants to immediately get firing build, something and see results. Because that's what he's used to. Decorating a page with jQuery is easy to get started with, and keep trying things until it works. Clearly this isn't ideal, but it is a reality.

I think our goal needs to be to tweak Sproutcore so that the on ramp for adoption isn't as steep as it currently is. This doesn't mean that we need to get rid of our complexity, but it means we need to make it easy to hide that complexity if you follow the "blessed path". 

For example, Rails is not lacking in complexity, or performance optimizations. There are many cases where if you don't know how Rails is doing something, it will come back to bite you. Yet people don't seem to have a hard time getting started with Rails. Why? Because complexity and performance optimizations are hidden away under  Rails'  "convention over configuration" pattern. It is only once people are familiar with the big concepts, and start wanting to do something interesting a bit off of the beaten path that they begin to learn more about how Rails does all the things that it does. 

I think all that Tom was saying was that the basic developer just getting started with Sproutcore should feel like the basic developer getting started with Rails. We don't need to drop them into how we buffer changes to increase performance the same way Rails doesn't drop them into how ActiveRecord connects to the columns in their database right off the bat. Give them time to get familiar with the concepts and abstractions of Sproutcore then they'll be in a position to not feel overwhelmed, and not leave the community saying things are too complex.

My two cents.

[Tom Dale]

Not at all. I'm atoning for my own sins.

Sent from my iPhone

[Erich Ocean]

On Fri, Apr 22, 2011 at 6:44 PM, Gregory Moeck <gmo...@gmail.com> wrote:
> I think all that Tom was saying was that the basic developer just getting
> started with Sproutcore should feel like the basic developer getting started
> with Rails.

So we agree. How do you explain this then:

http://api.rubyonrails.org/classes/ActionController/Base.html

Specifically, the first sentence:

> Action Controllers are the core of a web request in Rails. They are made up of one or more actions that are executed on request and then either render a template or redirect to another action. An action is defined as a public method on the controller, which will automatically be made accessible to the web-server through Rails Routes.

Here's the equivalent version for SproutCore:

> Run loops are the core of browser event handling in SproutCore. They consist of one or more responder methods that are executed in response to a browser event and then either data is updated, views are updated, or both. A responder method is a public method (for example, 'mouseDown') on a view which will automatically be called by SproutCore when the corresponding user event on that view occurs.

I simply do not believe that this is inappropriate information for a
SproutCore developer. I think Rails has the right level of detail, and
I think SproutCore should too. We don't need to be "simpler" than
Rails.

Furthermore, I'm all for making SproutCore easier to use, but
pretending that SproutCore apps are not event-driven systems, or that
SproutCore doesn't call responder methods in response to browser
events, is not helpful to anyone.

We're talking in this thread about including a discussion that
SproutCore does this in an *Advanced Guide*, and apparently, this is
considered to be such an amazing complication to application
development that we should omit the information entirely. Guys, I'm
baffled here that here is *any* opposition at all.

*sigh*,

[Gregory Moeck]

Erich,

I greatly respect you and personally benefited from your training when I was working out the kinks in how Sproutcore works. But if you think that most Rails developers how how a controller actually works, then you are mistaken. Sure, they know how to write a controller, but they don't necessarily know how it does what it does. They merely treat it like a DSL for connecting the data stored in their views with what they want to display in their views.

Besides it really isn't fair to compare controllers in Rails with the runloop in Sproutcore. Every developer must write a controller in order for their application to function, but how often do Sproutcore developers have to write a run loop to make their application function? A more fair comparison would be to ask how many Rails developers know about ActionDispatch? ActionDispatch is the way that Rails implements the response as the request comes into the system, yet few know about it. Why? Because it's an implementation detail that is there to optimize performance.

Now in reality my example really isn't totally fair, because the run loop concept is more critical to how Sproutcore works than ActionDispatch is to Rails. But my point is you don't necessarily need to know *how* it works in order to be able to successfully use it. Rails is great because it abstracts away that knowledge from you until your going to do something that your going to need it for. And then when your going to need it, it's there available for you to learn and use. 

I'm not advocating making Sproutcore simpler by hiding details of how to write applications. I'm advocating showing the the developer how to build the system that they need through the "blessed path", and not focusing as much on how that "blessed path" works. It's not even that the run loop itself is difficult itself to understand - it isn't. It's just one more thing that a new person has to understand and keep in mind when they're developing. When people say Sproutcore is complicated, they don't mean an individual piece is confusing, but that there are too many pieces and concepts to keep in their head at once when they're trying to learn. 

For sure the developer needs to know to write a responder method in their view to receive an event, and what to do once they receive it. They need to know to not modify the DOM in that view responder directly. They need to know to call into their statechart or controller to maintain the state of their application. They need to know that their controller/statechart should call into the model layer to modify the state of their data. They need to know how to implement a template or render/update method that describes the linkage between the state of their views and the DOM. And so on. But I personally don't think they need to know how the run loop works to buffer the data between each of the layers of the architecture. It should just do it for them.

The chart in your training where you have a circle that dispatches the DOM events to the view layer and is labeled as the "Run Loop" is great, and extremely helpful. It's an abstraction that explains that there is some "Run Loop" that takes the events of the DOM and gets them to my view. We shouldn't shy away from using the term, or the idea. I just don't think we need a section to explain the content of how it buffers or even that we're going to buffer. We intend to buffer, but we don't have to tell people that we're doing it, or how we're doing it off the bat because it is an optimization. The general concepts of writing an application would work with or without a run loop. That's why I agree with Tom when he says, "If understanding the run loop is fundamental to correct and efficient usage of SproutCore, that is a failing on our par". 

Greg

[Erich Ocean]

Greg, thanks for your detail replies. I think we have the same goals,
just different views about how to get there. Rails developers are not
my target audience; application developers are. But when a member of
the Rails core team is also leading the SproutCore core team, it's
pretty obvious which developers become important, and you don't have
to be a genius to see which ways the wind is blowing...

On Fri, Apr 22, 2011 at 8:29 PM, Gregory Moeck <gmo...@gmail.com> wrote:
> The chart in your training where you have a circle that dispatches the DOM
> events to the view layer and is labeled as the "Run Loop" is great, and
> extremely helpful. It's an abstraction that explains that there is some "Run
> Loop" that takes the events of the DOM and gets them to my view.

Something at the level of that diagram is all that I am lobbying for.
It's all I've ever taught anyone about the run loop in my classes, or
when mentoring.

From my perspective, Tom Dale is arguing that a SC developer should
not even know that there is such a thing as a run loop – that
SproutCore registers for browser events automatically and dispatches
them to views. More to the point, he seems to be arguing that
information like that should not be in the SproutCore Guides, even in
an "advanced" section, because he somehow has the idea that if we tell
people that information (and it helps them write "correct",
"efficient" code), that we've somehow "failed."

I think that's wrong: people *are* coming from jQuery, where you *do*
register for browser events. That's a fundamental difference between a
toolkit like jQuery and a app framework like SproutCore. I haven't had
even a single person tell me after my SproutCore class (which, as you
all know, talks about the run loop on the VERY FIRST SLIDE) that
everything I taught was great, but if I had just left out the run loop
part, they felt the complexity would have been much lower. Not one. If
you did, now is your chance to set me straight.

(For the record: I've taught hundreds of people new to SproutCore
and/or application development over the last 3.5 years, so I feel
pretty confident that the conceptual existence of the run loop, or the
idea that SC register for events and dispatches them to views, is not
something that is a barrier to adoption in SproutCore.)

On the other hand, I've also seen some astoundingly horrific
SproutCore code. You know what fixes it 80% of the time ? Walking a
developer through the slide with the run loop on it (it also includes
the "V" property). 10 minutes of discussion, problem solved, crisis
averted. (The other 20% is giving some frank advice on how to write a
view. Spoiler: use HTML and CSS.)

It's sad to think how many projects have failed (or nearly so) because
we as a community have some philosophical opposition to describing how
an event is handled in a SproutCore app. It truly mystifies me why the
run loop has suddenly become the source of all SproutCore's adoption
problems.

[sarc]

If event handling is something we need to hide from even developers
wanting advanced SproutCore information, why don't we try and abstract
the browser (DOM/CSS) altogether? There are many people (not me) who
want to do that, and there's even an entire app framework (Cappuccino)
dedicated to doing so. And JavaScript? Too difficult, let's use
CoffeeScript and abstract that out to to something we're more familiar
with, something that looks more like ruby. After all, prototype
inheritance is "new" and "web developers" can't be bothered to learn
about that stuff. They just want to put HTML on the screen. And CSS?
Again, too hard. Let's generate CSS from some ruby-like DSL instead.

Maybe SproutCore will take off like gangbusters when SC code reads
like backbone.js even though the library weighs ten times as much, but
those pesky "events" are gone for good. Yeah, that's the ticket.
Remove that abominable "run loop" and we're golden. Next: profit!

[/sarc]

Best,

[Yehuda Katz]

Responses inline.

Yehuda Katz
Chief Technologist | Strobe
(ph) 718.877.1325

On Fri, Apr 22, 2011 at 9:17 PM, Erich Ocean <ad...@erichocean.otherinbox.com> wrote:

Greg, thanks for your detail replies. I think we have the same goals,
just different views about how to get there. Rails developers are not
my target audience; application developers are. But when a member of
the Rails core team is also leading the SproutCore core team, it's
pretty obvious which developers become important, and you don't have
to be a genius to see which ways the wind is blowing...

I personally don't consider Rails development to be equivalent to SproutCore development. I certainly do not consider Rails developers to be the primary audience for SproutCore. I do, however, consider SproutCore an upgrade path for jQuery developers who are finding that they need help structuring their code using a tried-and-true pattern for application development.

I would be ridiculous to assume that those developers will not have to learn any new concepts. In general, we can think about the order we teach them those concepts as it related to the order that they find success with the framework.

 

On Fri, Apr 22, 2011 at 8:29 PM, Gregory Moeck <gmo...@gmail.com> wrote:
> The chart in your training where you have a circle that dispatches the DOM
> events to the view layer and is labeled as the "Run Loop" is great, and
> extremely helpful. It's an abstraction that explains that there is some "Run
> Loop" that takes the events of the DOM and gets them to my view.

Something at the level of that diagram is all that I am lobbying for.
It's all I've ever taught anyone about the run loop in my classes, or
when mentoring.

From my perspective, Tom Dale is arguing that a SC developer should
not even know that there is such a thing as a run loop – that
SproutCore registers for browser events automatically and dispatches
them to views. More to the point, he seems to be arguing that
information like that should not be in the SproutCore Guides, even in
an "advanced" section, because he somehow has the idea that if we tell
people that information (and it helps them write "correct",
"efficient" code), that we've somehow "failed."

I think you probably misunderstood Tom. I personally am strongly in favor of documenting the internal mechanisms of SproutCore in advanced parts of the guides, and think it's important that we tell people how SproutCore achieves efficiency benefits.

As I said above, I think we need to do that in an order that will have them feeling successful with SproutCore before we march in all the concepts.

 

I think that's wrong: people *are* coming from jQuery, where you *do*
register for browser events. That's a fundamental difference between a
toolkit like jQuery and a app framework like SproutCore. I haven't had
even a single person tell me after my SproutCore class (which, as you
all know, talks about the run loop on the VERY FIRST SLIDE) that
everything I taught was great, but if I had just left out the run loop
part, they felt the complexity would have been much lower. Not one. If
you did, now is your chance to set me straight.

To be fair, the people who came to your class already had a solid investment in SproutCore. They were willing to pay $100 for a multi-hour course in the framework. From that mindset, it absolutely makes sense to lay out more of the details up front. From the perspective of a developer who learned about SproutCore from Hacker News or a tweet from a friend, we need to get them up and running and feeling good in minutes, not hours.

 

(For the record: I've taught hundreds of people new to SproutCore
and/or application development over the last 3.5 years, so I feel
pretty confident that the conceptual existence of the run loop, or the
idea that SC register for events and dispatches them to views, is not
something that is a barrier to adoption in SproutCore.)

In general, an (even intermediate) guide that walked the reader through the process of dispatching events in SproutCore (which isn't all that different from how the browser does it), and talked about how bindings and rendering are deferred would be extremely welcome. I am quite sure that Tom was not arguing against that.

I would consider it more analogous to the Request or Response objects in Rails, which are used internally by Rails, but which are also available to the intermediate-to-advanced developer, and are somewhat crucial to understand exactly how flow through the application works.

 

On the other hand, I've also seen some astoundingly horrific
SproutCore code. You know what fixes it 80% of the time ? Walking a
developer through the slide with the run loop on it (it also includes
the "V" property). 10 minutes of discussion, problem solved, crisis
averted. (The other 20% is giving some frank advice on how to write a
view. Spoiler: use HTML and CSS.)

I completely agree that it makes sense to show developers how data flows through the framework. The fundamental difference between SproutCore and jQuery is that SproutCore is a data-oriented framework, while jQuery is a DOM-oriented library. Walking a developer through data flows is very helpful, once the developer has put something meaningful on the screen and is feeling invested in using SproutCore.

 

As you know, we agree that HTML and CSS are the right way to build views, even as I think we disagree about the value of somewhat reusable views.

It's sad to think how many projects have failed (or nearly so) because
we as a community have some philosophical opposition to describing how
an event is handled in a SproutCore app. It truly mystifies me why the
run loop has suddenly become the source of all SproutCore's adoption
problems.

I'm pretty sure that nobody is saying that the run loop in particular is the source of all of SproutCore's adoption problems. And I'm pretty sure that nobody has a philosophical opposition to describing how events work. We just want to get people up and running before we barrage them with information.

 

[sarc]

If event handling is something we need to hide from even developers
wanting advanced SproutCore information, why don't we try and abstract
the browser (DOM/CSS) altogether? There are many people (not me) who
want to do that, and there's even an entire app framework (Cappuccino)
dedicated to doing so. And JavaScript? Too difficult, let's use
CoffeeScript and abstract that out to to something we're more familiar
with, something that looks more like ruby. After all, prototype
inheritance is "new" and "web developers" can't be bothered to learn
about that stuff. They just want to put HTML on the screen. And CSS?
Again, too hard. Let's generate CSS from some ruby-like DSL instead.

I'm pretty sure everyone agrees with the point behind your sarcasm. Despite your gripes on Twitter, we are moving MORE in the direction of HTML, CSS and JavaScript since I have joined the project, not more in the direction of Ruby DSLs.

 

Maybe SproutCore will take off like gangbusters when SC code reads
like backbone.js even though the library weighs ten times as much, but
those pesky "events" are gone for good. Yeah, that's the ticket.
Remove that abominable "run loop" and we're golden. Next: profit!

Nobody is arguing that we should build something fundamentally like Backbone. Backbone is fundamentally event-based from the developer's perspective: you listen for inline events and then decide what to do (often, re-render). SproutCore is fundamentally about declaratively describing how data flows through the application, and rarely ever requires developers to immediately react to data-change events. Instead, it tries to intelligently batch and coalesce via *internal* mechanisms like property invalidations and propagation.

As a result, small SproutCore apps will always look different from Backbone, because they will be mostly about describing how data flows through objects, and almost never about reacting to immediate events.

The fact that we can make SproutCore apps smaller than the equivalent Backbone app is not a bad thing.

[Tom Dale]

This thread has obviously fallen way off topic, but given your tweet last night where you said that SproutCore "is moving rapidly into the weeds," I wanted to explain why I think that the health of the framework has never been stronger, and, for the first time in my almost two years of using SproutCore, I finally feel we are on the right trajectory to win in the marketplace of ideas.

Rails developers are not

my target audience; application developers are. But when a member of

the Rails core team is also leading the SproutCore core team, it's

pretty obvious which developers become important, and you don't have

to be a genius to see which ways the wind is blowing...

All developers are equally important. We want everyone to be able to use SproutCore—Rails developers, "application" developers, whoever.

From my perspective, Tom Dale is arguing that a SC developer should

not even know that there is such a thing as a run loop – that

SproutCore registers for browser events automatically and dispatches

them to views. More to the point, he seems to be arguing that

information like that should not be in the SproutCore Guides, even in

an "advanced" section, because he somehow has the idea that if we tell

people that information (and it helps them write "correct",

"efficient" code), that we've somehow "failed."

The Sturm und Drang is unnecessary. You keep arguing that I don't want it even in an "Advanced" section. No. If you look at the outline that Veebs posted, this is clearly an "Introduction to SproutCore" section. Your characterization of me as a paternalistic figure who wants to wrap the framework in foam cushions so that users don't poke their eyes out on the pointy bits is inaccurate. I'm just fighting back against the idea that we have to tell users everything up front. It can wait until the "Advanced" section.

I think that's wrong: people *are* coming from jQuery, where you *do*

register for browser events. That's a fundamental difference between a

toolkit like jQuery and a app framework like SproutCore. I haven't had

even a single person tell me after my SproutCore class (which, as you

all know, talks about the run loop on the VERY FIRST SLIDE) that

everything I taught was great, but if I had just left out the run loop

part, they felt the complexity would have been much lower. Not one. If

you did, now is your chance to set me straight.

This argument is absurd. Run loops aren't the straw that breaks the camel's back. Instead, the general air of complexity around SproutCore makes many developers pass us over  entirely; just look at any Hacker News thread about SC. The breaking point will be different for each individual. If I am a web developer, the amount of new concepts I have to learn is insane. Just off the top of my head, I have to learn about:

1. What a Page is
2. What a Pane is
3. What a MainPane is
4. When to use design() vs. extend() vs. create()
5. What a view is
6. How to get HTML on a page (by overriding a view)
7. How to handle events
8. What a responder chain is
9. Which controls are available
10. Which controls are production ready(!!)
11. How layout hashes work
12. Which CSS properties work with layout hashes (not all do)
13. What a "layer" is

There are more, of course, and I haven't even covered actually plugging an application into a backend yet.

On the other hand, I've also seen some astoundingly horrific

SproutCore code. You know what fixes it 80% of the time ? Walking a

developer through the slide with the run loop on it (it also includes

the "V" property). 10 minutes of discussion, problem solved, crisis

averted. (The other 20% is giving some frank advice on how to write a

view. Spoiler: use HTML and CSS.)

If it is that easy for developers to fall into traps, we need to fix our framework. If the party line is "never use more than a single view in your application," we seriously need to re-evaluate our view layer. Developers should not be shouldering the blame for our failures.

It's sad to think how many projects have failed (or nearly so) because

we as a community have some philosophical opposition to describing how

an event is handled in a SproutCore app. It truly mystifies me why the

run loop has suddenly become the source of all SproutCore's adoption

problems.

Stop blaming the failures of applications on the community. No one has refused to answer questions about event handling; we have one of the most helpful open source communities I've ever seen and I'm immensely proud of them. Stop presenting hypotheticals as facts.

I used to share the attitude that these were real apps, dammit; developers should just man up and deal with the complexity. But you're putting words in my mouth. I said the "attitude of forcing people to front-load complexity when learning the framework can be directly correlated with our current low adoption rate." It's death by a thousand paper cuts, of which the run loop is just one.

Here's the thing. You and I have been using SproutCore for too long. Our eyes and our brains no longer have the ability to see what makes sense and what doesn't. That's just the nature of things.

So what Yehuda and I have been doing for the past two months is actively talking to people who tried SproutCore and gave up. We've been pitching SproutCore to people and, if they decided not to use it, we'd ask them why. We've been compiling these reasons, looking at trends, and figuring out what we need to do to improve adoption outside companies with the extensive capital necessary to make SproutCore work today. I will continue to work tirelessly to make sure that SproutCore is the obvious choice for anyone building web applications, whether they use a widget library or want to build HTML-style apps.

We make the framework better by listening to users, not telling them that they're doing it wrong. We make the framework better by contributing code, unit tests, documentation, and ideas, not by blaming the community for not agreeing with us. We make the framework better by making it work for everybody, not just an elite few who have the time and raw intellect to understand its nuances.

So that's what I'm doing: I'm helping make the framework better. I will make mistakes along the way. That's why I need your, and everybody's, help.

We all need to pull in the same direction: Make SproutCore for all, not just a few.

Thanks for listening,

Tom

On Fri, Apr 22, 2011 at 9:17 PM, Erich Ocean <ad...@erichocean.otherinbox.com> wrote:

On Fri, Apr 22, 2011 at 8:29 PM, Gregory Moeck <gmo...@gmail.com> wrote:
> The chart in your training where you have a circle that dispatches the DOM
> events to the view layer and is labeled as the "Run Loop" is great, and
> extremely helpful. It's an abstraction that explains that there is some "Run
> Loop" that takes the events of the DOM and gets them to my view.

Something at the level of that diagram is all that I am lobbying for.
It's all I've ever taught anyone about the run loop in my classes, or
when mentoring.

(For the record: I've taught hundreds of people new to SproutCore
and/or application development over the last 3.5 years, so I feel
pretty confident that the conceptual existence of the run loop, or the
idea that SC register for events and dispatches them to views, is not
something that is a barrier to adoption in SproutCore.)

[Tom Dale]

The formatting on that last e-mail seems to have been screwed up in all clients except for Gmail, so here's the unstyled version:

* What a Page is

* What a Pane is

* What a MainPane is

* When to use design() vs. extend() vs. create()

* What a view is

* How to get HTML on a page (by overriding a view)

* How to handle events

* What a responder chain is

* Which controls are available

* Which controls are production ready(!!)

* How layout hashes work

* Which CSS properties work with layout hashes (not all do)

* What a "layer" is

[Alex Iskander]

I know push is a great new tech and all, but I do not like documentation "pushed" to me. I don't want an answer to a question I didn't ask.

When I was starting with SproutCore, the first thing I wanted to know was "How do I build an app?" It was not "How does SproutCore work?"

I suffered on two fronts: the run loop got pushed to me too early, and I became scared of it. Then, when I did need to learn about it, I a) didn't know I needed to learn, and b) was afraid to learn it. I would even skip over paragraphs mentioning it.

Absolutely, we ought to have a guide on the Run Loop. But it should not be something we "push" to developers on "day one." Guides affected by the run loop—for instance, ones covering events, bindings, observers, etc.—should have simple one-line notes mentioning how they are affected, and then link to the Run Loop guide.

The Run Loop guide should be under an "Advanced Topics" section. Of course developers should be able to learn about it. Making sure they learn about it when they need to—when bindings and observers don't work how they expect, when they handle events manually, etc.—is an absolute must.

But we should not push that information to them before they need it.

Alex

[Topher Fangio]

Hey guys,

I don't want to exacerbate this issue, but I wanted to share my thoughts since I am a newbie to SproutCore.

First off, I think everyone has made some excellent points. Secondly, I think it's great that we can have these type of discussions. These are the discussions that help communities grow, and I'm glad that I can be a part of it and have my thoughts actually considered by the core team members. I think that is one of the things that strongly differentiates SproutCore from any other framework I've seen. Sencha looks really cool, but their developer community felt sorely lacking when I was evaluating it. That's what made me stick with SproutCore even though I think Sencha is a more "mature" framework.

Anyway, on with my thoughts.

I learned quite a bit about SproutCore before making the investment in Erich's training courses. I'll admit, it took a lot longer than I had hoped, but here is what I ran into when evaluating SC:

1. There were no guides, and the wiki seemed really outdated, so I didn't trust it. This made it very hard to get up and running. I think we have fixed this with some of the guides, but I think there are still a few improvements to be made (and I'm trying to help with those, although I'm a bit slow at it).
   
   
2. I read a few notes about the run loop and it's purpose, but any more than that, I didn't care, and honestly, I don't think I needed to know. I think Erich is right that we should talk about it briefly, and I agree with Tom that if we (newbies only, not seasoned developers) HAVE to know a bunch about it, then it is a failing on the part of the framework. I think a simple sentence or two about it's purpose and basic runnings is all we need in the getting started guides. I've written about half of my first app and haven't needed to know any more specifics.
   
   
3. Some have said that we need a "blessed path" for getting up and running. I agree 100% with this. I think convention over configuration is the way to go for people just getting started. They can delve into the complexities later, but having that "this is how things should be done" would have been awesome for me.
   
   
4. I think that the interaction between the client and the server was the hardest part for me for me to grasp. I also think that this is the piece that needs a "blessed path" the most. It is a core concept and one that EVERY developer will face early on. Having "the way" painted out for us in a clear (and recently updated) format would have helped me tremendously. I think it is also a huge factor for anyone evaluating the framework.

Last point: I think anything not in the "Getting Started" section is an advanced guide and should be known as such. Getting Started is for developers who are evaluating the framework and want to see enough of the framework to make a decision on whether to continue or not. Everything else is either for those who are very interested, or who have decided to give SC a chance and want to learn about some of the inner workings.

Thanks for taking the time to listen :-)

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Veebs]

... and I thought I was just asking a simple question ;-)

Will the following revised TOC work?

Guides
- Start Here
- Install
- Getting Started with HTML-Based Apps
- Getting Started
- Core Concepts

- Runtime
- Objects
- Observers

One liner description of run loop with link to run loop guide

- Bindings
One liner description of run loop with link to run loop guide

- ** Run Loop Guide **
Brief description of buffering.
Diagram as mentioned by Greg
Link to detailed run loop description under How Sproutcore
Works

- Errors

- Models

- Views

- Theming

- Testing

- How Sproutcore Works
- ** Run Loop **
Detailed description of the in's and out's of run loops.
- Other topics ...
Please let me know so I can add placeholders

- Contributing


Veebs.

[Robin]

I think, time you spent arguing what practice is best or better, is enough to write some part of a tutorial regarding RunLoop.

Robin

UI Developer

rob...@gmail.com 

http://pagetalks.com/

http://www.elfvision.com/

[Michael Cohen]

Oh geez. I dared to get involved with this running thread.

This is just more of an FYI, but I wrote a pretty extensive blog post
about what the SproutCore run loop is and how it works:

http://frozencanuck.wordpress.com/2010/12/21/why-does-sproutcore-have-a-run-loop-and-when-does-it-execute/

So if you want me to migrate my stuff over to the SC guides and place
this under the "advanced topics" section, I can do so.

The run loop, while a more involved topic, isn't that overwhelming if
you break down the concept. Although advanced, I find that by
discussing the run loop really helps remove any doubts as to what is
really going on behind the scenes and why the approach was taken
compared to doing something else. Of course I personally wouldn't
start introducing the idea of a run loop until after I get people
comfortable with bindings first, but then that's just me.

Alright, I'm now going to duck out of the line of fire.

-Mike

[dooley]

As a guy who started SC from a typical web-dev position, I'd like to chime in with what hurt the most from the start:

1) The differences of MVC in SC than MVC from traditional thin-client stacks. It was hard to not have very much logic in the controller. (HUGE mind shift). The Views sort of tie into this as well, but the basica views are fairly simple to grasp, just difficult to implement without being forced to look at the base code because the online documentation wasn't easy to reference.

2) Bindings (never worked with KVO/KVC)

3) Set/get and the problems they can cause

4) .property() and .observes()

5) Advanced bindings

6) Kind of the runloop: invokeLast/later, but only in relation to complex objects from (3)

1 and 2 were, bar none, that most difficult to understand for myself. I've never been really taught about the runLoop other than it being mentioned and the general philosophy of how it works and then I learned more about it through artificially created performance problems.

I'd argue that you could build a fairly complex app without ever having to encounter run loop problems if you have a solid grasp of those top 5 things. The sixth is just gravy.

The easiest part of SC is probably the model layer: it's basically the same as models in typical frameworks.

My two cents.

I'm curious if other typical RoR/merb/LAMP people had the same problems I did.

[Charles Jolley]

Thanks dooley and thanks especially to everyone who has chimed in on this thread who is new or relatively new to SproutCore. Your experiences really matter as the whole point of this exercise is to smooth out the onramp for SproutCore!

-C

[dooley]

How could I forget: Statecharts. Those become extremely important; much more than runloop stuff.

[Erich Ocean]

On Mon, Apr 25, 2011 at 7:58 AM, dooley <wr3k...@gmail.com> wrote:
> How could I forget: Statecharts. Those become extremely important; much more
> than runloop stuff.

Ironically, every discussion of statecharts describes the "superloop",
the non-SC equivalent of the run loop (which is just SproutCore's
in-built event-dispatch loop).

IMO Every SproutCore developer from minute one should be told that SC
is a high-performance, event-driven system, that each event is
run-to-completion, and that views redraw after the event has been
handled and all data has propagated through the app. That's essential
what the first slide of my SproutCore Training video is all about.

Perhaps the best solution here is for me to do a "SproutCore for
Absolute Beginners" on my website that in one page, teaches what I
think should be taught. People can google that if they want to learn
SC the way I teach it.

[Chad Eubanks (gMail)]

Erich,

I'd lobe to see this as a guide as oppose to being posted on your personal site.

The reason I suggest this is because when I first started working with SproutCore I found it troublesome to search for things online. The guides help ones learning efforts to be focused on the material instead of goggling for information.

Kind Regards,
Chad Eubanks

Sent from my iPhone

[Peter Wagenet]

Chad,

I think Erich's point is that the way he wants to teach it differs from the way those on the
Core Team would like to teach it. While it would be ideal if we can come to an agreement,
the second best option is to both have our own way of explaining it. As long as we aren't
telling people contradictory things then the existence of multiple approaches isn't likely to
do any harm.

-Peter

[Joachim Haagen Skeie]

Now, having a short guide (possibly with links to more detailed guides
for each point) that will outline, in very short descriptions, what
these concepts are, and how they relate would be a very good resource
for finding out information about features and concepts that are
unique to SC. Certainly something I would have wanted to read when I
was starting to learn SproutCore!

Very Best Regards,
Joachim Haagen Skeie

On 23 apr, 19:28, Tom Dale <t...@sproutcore.com> wrote:
> If I am a web
> developer, the amount of new concepts I have to learn is insane. Just off
> the top of my head, I have to learn about:
>

>    1. What a Page is
>    2. What a Pane is
>    3. What a MainPane is
>    4. When to use design() vs. extend() vs. create()
>    5. What a view is
>    6. How to get HTML on a page (by overriding a view)
>    7. How to handle events
>    8. What a responder chain is
>    9. Which controls are available
>    10. *Which controls are production ready(!!)*
>    11. How layout hashes work
>    12. Which CSS properties work with layout hashes (not all do)
>    13. What a "layer" is