"Frameworks"

7 views
Skip to first unread message

Dave Porter

unread,
May 30, 2013, 12:11:53 PM5/30/13
to sproutc...@googlegroups.com
I'm sick to death of calling SproutCore a framework, and then stumbling to explain that it also includes frameworks. For a while I thought we should rename frameworks to "libraries" or something in SC2.0, but that would take more effort than ... not doing that. The other option is to call SproutCore itself something else. I've considered "platform", but platforms usually have some permanent piece like a web server or something.

Any ideas? I appreciate your thoughts on this crucial issue of utmost urgency!

Cheers,
Dave

Jeff Pittman

unread,
May 30, 2013, 12:16:58 PM5/30/13
to sproutc...@googlegroups.com
System?

I like Platform, which is similar.

Jeff

--
You received this message because you are subscribed to the Google Groups "SproutCore Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sproutcore-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Mitch Oliver

unread,
May 30, 2013, 12:18:20 PM5/30/13
to sproutc...@googlegroups.com
Calling SproutCore something-not-framework seems like a fool's errand. Why is SproutCore a something-not-framework and Ember/Angular/etc. a framework?

If we were to rename anything it would have to be the components within SproutCore. I'm not terribly troubled by the frameworks-within-the-framework, however.


--

Jeff Pittman

unread,
May 30, 2013, 12:21:23 PM5/30/13
to sproutc...@googlegroups.com
I like System better than Platform I think.

We speak of cross-platform dev, indicating that platforms are Android, Desktop, etc., but system is a more generic term.

Jeff

Dave Porter

unread,
May 30, 2013, 12:24:25 PM5/30/13
to sproutc...@googlegroups.com
Mitch, if we need to justify our nomenclature to anyone, then the reason I would give is that the other guys are things you drop into a regular web document via a <script> tag, while SproutCore is decidedly more than that.

Topher Fangio

unread,
May 30, 2013, 12:32:09 PM5/30/13
to sproutc...@googlegroups.com
I think the term Framework does indeed correctly apply to what SproutCore is. It is a set of building blocks and API and utilities for building enterprise-level web applications.

I also don't particularly mind the framework-within-a-framework terminology, but I have always thought of them as "modules" or "plugins", and that is what I typically tell others when we discuss it. If we're thinking about changing the terminology, we should definitely discuss the architecture of the build tools and if there is any overlapping terminology so that we can keep it consistent.


--
Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

Dave Porter

unread,
May 30, 2013, 12:39:25 PM5/30/13
to sproutc...@googlegroups.com
Topher, good point, and Cocoa (SproutCore's inspiration) is also goes by "framework". What are Cocoa's component parts generally called?

Topher Fangio

unread,
May 30, 2013, 12:40:30 PM5/30/13
to sproutc...@googlegroups.com
Unfortunately, I think they are called frameworks :-P


--
Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141


Mitch Oliver

unread,
May 30, 2013, 12:43:40 PM5/30/13
to sproutc...@googlegroups.com
Perhaps a more apt example then is Cappuccino, which is also a "framework."

Dave Porter

unread,
May 30, 2013, 12:53:11 PM5/30/13
to sproutc...@googlegroups.com
Ahha... Apple pervasively refers to Cocoa as "a set of frameworks". Mystery solved! I'd be thrilled to see more nods to Cocoa in our branding, but I wonder if calling SproutCore "a set of frameworks" would be a boost or a confusion.

Topher Fangio

unread,
May 30, 2013, 1:02:10 PM5/30/13
to sproutc...@googlegroups.com
If we put a bit more emphasis in 2.0 on framework separation, then I think that totally makes sense. For instance, if we have sproutcore-runtime, sproutcore-desktop, and hopefully sproutcore-mobile; then I think calling it a set of frameworks much better aligns with what we're pushing.

On the other hand, currently, sproutcore also refers to the build tools, so, unlike Cocoa which has XCode and InterfaceBuilder as separate products, ours currently encompasses all of them; and personally, I think that's the way to go. I really HATE the approach Sencha has taken where you can download the framework...or you can download their command line tools...or you can download their IDE, but in general, you still want all of them anyway...

I think being able to say the following is really powerful and we should stick with "flexible simplicity" instead of "infinitely configurable but complicated":
  1. Install Node
  2. Install SproutCore
  3. Run "sproutcore new MyAwesomeProject"
  4. Run "sproutcore server"
  5. Make something awesome!
So, I think SproutCore is a set of frameworks and tools for building outstanding, enterprise-quality web applications. Or at least...I think this is what we should always shoot for; but that's just my two cents :-)


--
Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141


Dave Porter

unread,
May 30, 2013, 1:07:01 PM5/30/13
to sproutc...@googlegroups.com
So to wrap up this thread: I agree that if we manage to get an intelligent split between the frameworks, then easing over to the "collection of frameworks" branding (with the rest about ease of awesomeness) will be a good idea. Let's debate further when 2.0 is closer.

And that segues perfectly into the question of reorganizing the frameworks for 2.0, which deserves its own thread, so I shall start one!
Reply all
Reply to author
Forward
0 new messages