This past weekend I attended JSConf 2010 in Washington, DC, and, I have to say, I was mighty impressed with what I saw. Although I couldn’t see everything, there were still a lot of fantastic presentations of what JavaScript can now do — not just on the client-side, but also on the server side!
And here’s the thing: I’m convinced that 2010 is thee year that JavaScript as a language can start to be taken seriously as a tool for real software development — It’s not your lil’ scripting language to do neat web page tricks.
Frameworks like node.js and hook.io are pushing the way forward in making real server-side software. Another framework called seed.js is finally providing a way of centrally retrieving and pushing modules of JavaScript code for others to use and share. It starts a real collaborative development community that you would find in places like Ruby and Python. Very exciting.
Then, of course, on the client-side, you are finding fully featured frameworks, like SproutCore and Raphael, that are pushing the boundaries of what you can do when building a web application.
The presentation by Evin Grano and Mike Ball demonstrated how SproutCore has matured, what you can do with it on the iPad (touch!), and then they topped it all off by revealing a SproutCore interface builder tool called Greenhouse that was a real crowd pleaser. The presentation showed the audience that you can indeed build feature rich and fast desktop-like applications within a web browser that can rival an application written based on traditional languages and frameworks.
Dmitry Baranovskiy presentation on his Raphael framework was also another crowd favorite. In just 45 minutes, this dude laid down the hammer that you can indeed create expressive vector graphics and smoothly animate them in a web browser with a cross-compatible and intuitive API. I think everyone in the audience was floored. I know I was. To top it all off, Dmitry created his awesome framework as a side project while commuting to and from work. I mean, seriously? I need to get better. *sigh*.
Other highlights included presentations by Douglas Crockford (you know who he is) who attacked HTML 5 for its lack of security to prevent cross-site scripting attacks, Steve Souders of YSlow fame who discussed JavaScript’s performance impact on web sites, Billy Hoffman giving a fun yet scary talk on web security, and, most of all, a presentation by Brendan Eich, the father of JavaScript.
Brendan talked both about the history of JavaScript and the new language features that are coming or being considered. Of all the language features Brendan discussed, the one that jumped out at me the most was module support, which is the one thing I’ve always felt JavaScript desperately needed. Let’s all cross our fingers that module support is added and is quickly adopted by all the browser vendors.
Of course it wasn’t all about the presentations. The conference was also about getting a chance to meet other people who work with JavaScript and sharing ideas. I met quite a number of people who are doing some impressive stuff with JavaScript at their job and even as side projects. And the growing body of people working on open source JavaScript frameworks is just another encouraging sign of everyone working together and giving back. Bravo!
I know I didn’t mention all the other presentations that happened at JSConf but that’s only because I didn’t get a chance to see them — I really wish I had! That being said, I’m looking forward to what the rest of 2010/2011 will bring and who will be presenting the next eye popping use of JavaScript at JSConf 2011.
As a final parting thought, I have come to a second prediction, perhaps a much bolder predication, and it’s this: Adobe’s Flash, Microsoft’s Silverlight, and, to a much lesser extent, Oracle’s JavaFX, they will all become less and less significant in the future of the web due to the combination of open technologies like SproutCore, Raphael, and HTML 5. Proprietary technologies no more!
Some might argue that my claim is preposterous given the number of people that use technologies like Flash to provide rich, interactive media. However, I would disagree because to the end user, they soon won’t be able to tell the difference between what is made in Flash and what is done with the suit of tools like SproutCore, Raphael, and HTML 5. And let me be clear: I’m not saying it’s specifically SproutCore and Raphael combined with HTML 5 that will fill the gaps, it could be any JavaScript frameworks that provide a solid model-view-controller (MVC) foundation along with a rich and powerful framework to do vector illustration and animation.
Does all this mean no more Flash? No, of course not. But Flash and its like will gradually make up less of the web market share. The only other missing link that would help accelerate this decline of Flash are tools that regular designers can use to build their content, just like you can do currently with Adobe’s Flash IDE. I have a feeling, however, that the JavaScript community could take on such a challenge of making such a tool. I mean, if SproutCore can have a interface builder tool, then what’s stopping us from taking things to the next level?
-FC
Good one!! What are your thought on #Cappuccino?
@Lakshmikantan:
Regarding Cappuccino, I admit that I haven’t used it much. I’ve played with it, but nothing along the lines of making a serious application like I have been doing with the SproutCore framework. So perhaps my input on this subject is a bit muted. That being said, from my limited use, there are two major things that pop out at me.
First is the LGPL license Cappuccino uses. For people making open source projects on Cappuccino and for personal use, the license is fine. However, from a corporate standpoint, LGPL is seen by the lawyers as not ideal. If you’re going to use open source in industry then an MIT license is the way to go and the lawyers will give their blessing. If your corporate lawyers are okay with LGPL then more power to ya.
The other big thing about Cappuccino is its use of Objective-J based on Objective-C. The framework does translate the Objective-J to JavaScript so it obviously works in the browser. Here’s the thing: In order to use Cappuccino you have to learn how to use Objective-J. I understand why the language is used simply because there are a lot of people who develop apps for the Mac and are used to the syntax of Objective-C.
I’ll be frank: JavaScript is the programming language of the web, so why bother abstracting yourself from the language and have to force the user to learn another language on top of how to use the framework? Well designed JavaScript frameworks provide the real power to get things done quickly and easily. JavaScript is already a very powerful language. Yes, it does have its short comings and even Brendan Eich fully admitted as such, but despite the flaws, JavaScript really gives you all the power to start building serious code. If I want to write an app for the Mac/iPad/iPhone, then, fine, that’s when I’ll learn to code in Objective-C. But as Mike Ball and Evin Grano perfectly demonstrated, an application written in SproutCore using JavaScript is just as good as one written in Objective-C.
Okay, I can already sense that my second opinion about Cappuccino is going to piss some people off who happen to use and love Objective-J and Cappuccino. You know what? Who cares. I’m perfectly happy for people that want to use them. But know that there are real options like SproutCore that you can also check out. For people that know JavaScript and just want to learn a framework, then SproutCore might look like a good alternative.
As a related subject, this using another language to generate JavaScript is not new. Google has their GWT framework. So as a Java developer you can stay safe within your Java language world and not have to care about learning JavaScript. But I ask you this: If you’re a smart developer you don’t want to be shielded, you want to learn and get better. Technology evolves and so should you.
Again, this is why I made this post. To make it clear that JavaScript has reached this critical point where you can no longer see it as a toy to hack with. It’s now become a serious tool for development and will only get better so long as companies like Google, Apple, Mozilla and the such keep investing in the language of the web and build faster and faster JavaScript virtual machines.
So, again, I really don’t have anything personal again Cappuccino. I mean it; I don’t. You use it and love it? That’s perfect. But competition is good and it give you options. SproutCore is just one of those options.
Alright. I’m going go grab a helmet and a shield before bombs and spears are thrown at me.
Having written extensively on the subject in the past, I’d just suggest you take a look at this post:
http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-and-objective-j/
In essence, the point is that JavaScript may be what we’re stuck with in the browser, but we don’t have to limit ourselves to what a essentially one guy 15 years ago came up with. Having a language that sits on top of JavaScript lets us innovate without waiting for browser vendors and standards bodies to reach a consensus, a process which takes years or maybe even decades.
Nobody believes Objective-J is the “one true language” for writing apps, but it does provide essential features lacking in JavaScript and it does so in a way that’s already familiar to hundreds of thousands of developers.
@Boucher
Ah yes. It’s definitely interesting to get your insight from the Objective-J/Cappuccino world. I certainly welcome it. It only benefits those trying to understand the difference between with what you have and the SproutCore framework. Talking with people at JSConf and watching the tweets online, questions have been posed :-).
We both agree that JavaScript has its flaws. You agree; I agree; Brendan Eich agrees. Done. We also agree that there is definitely a future for rich desktop-like applications within the browser. Will there still be traditional web pages? Ya, of course. We know that.
Where it appears that we first part in thought is how to address JavaScript’s limitations as a language.
You take an interesting approach by developing Objective-J, based on Objective-C, in order to introduce new language-level features that handles things like classes and missing method invocation a-la Ruby. This is, of course, independent of Cappuccino. Interesting separation of concerns. As I’m sure you already know, SproutCore also provides class and inheritance support as well as method missing invocation. But unlike Objective-J, those concepts are part of SproutCore’s underlying runtime framework (or library… pick your term of the day).
Regarding what is a “better” approach along the lines of making up for what JavaScript lacks, it’s six of one, half a dozen of the other. Realistically, they both try to enhance the use of building heavy-weight desktop-like applications. Again, if you come from a Objective-C background and feel it is more natural to start jumping in and work with Objective-J, all the better to you. But, for those who do know JavaScript, and there are a lot of them too, SproutCore also helps pick up where JavaScript falls off.
Now, as for abstracting away HTML and underlying DOM manipulation and event handling/propagation, both Cappuccino and SproutCore do that in one form or another. So that’s good for everyone in order start building desktop-like applications and not concern themselves tinkering with low-level bits and bytes. In addition, both frameworks provide a type of model-view-controller (MVC) structure, which is what any good desktop development framework should have. Yay for us.
Putting aside features like bindings, records, and datastores, and who has what set of view widgets, the main difference in the frameworks is just HOW much abstraction they provide from the brower’s underlying feature set: CSS, Canvas, SVG, etc, etc, etc. The “rendering engine” as you nicely put it. In this department, Cappuccino currently goes further. Today’s hot web standard technology is tomorrow’s Microsoft DHTML dust bin. Who knows what will happen.
First, SproutCore fully embraces CSS. It’s there. All good web designers use CSS and it’s a well established standard. Personally, I don’t think its going anywhere. Could SproutCore help make it easier to pick the best CSS attribute? Ya, of course. Lord knows that there are CSS differences between browsers. As for SVG, VML and HTML5 Canvas, SproutCore does not currently have a module to abstract those vector-like capabilities away from you. It’s certainly something SproutCore should have and probably will acquire. I actually *wished* that SproutCore had something like the Raphael JS framework that does a great job of abstracting away those vector-based technologies. It’ll come.
Really, in any case, it all comes down to how much you trust web standards and will the browsers all play nice now and in the future. It’s the correct level of abstraction that we are after in order to make development feel more holistic and easy to do. However, Microsoft and its Internet Explorer typically makes sure that its interests subvert any standards others would like to adopt. It’s sad. First its VBScript/JScript versus JavaScript, next it’s DOM manipulation, and then its SVG/Canvas versus VML. Groan.
Like I’ve been saying, I don’t have anything against what you guys have built for the community at large. Both Objective-J/Cappuccino and SproutCore are attempting to provide a open source solution to build desktop-like applications for the web. I think there’s room for both and people ultimately get a choice, which I’m for. Anyone can get involved and contribute back. It just makes for a better experience. And we all win trying to fight the mighty proprietary technologies. Death to Flash!
As a final comment, I assume you were at this years JSConf. If so, it’s unfortunate we didn’t get a chance to meet and discuss. I enjoy this debate. It’s really interesting and fun. Perhaps at some point we’ll get a chance to cross paths.
I’d like to throw in my two cents here as well (having spotted this discussion in the tweeterverse). One fundamental premise that we do not believe in is that JavaScript is the one true future of the web and death to flash and blah blah blah.
The web is not great because of JavaScript or Flash or HTML5 video or whatever, the web is great due to the interconnectivity it provides, and the fact that its limited to one “idiom” if you will is actually one of its downsides (yes there are upsides AND downsides!). In my ideal future, the web is full of many languages and technologies. I want a web where a programmer can make his rich application in client side Python, Ruby, Objective-J, Erlang, CoffeeScript, Scala, *whatever*. Yes, even Flash. Flash is not a terrible thing, and its a worthwhile technology to have around in my opinion – it gave us video years before we even started talking about a standard video option on the web. I don’t personally like programming in Flash or ActionScript, but I don’t extrapolate from my personal dislike the need to obliterate it from the web. I can understand if someone likes Java and I don’t, there’s nothing religious or incompatible about it. What I perceive is that people think that with this latest round of HTML/JS/CSS features, we’ve finally “finished” the web, that it will now be perfect, thus why the need for options? This is obviously a silly premise. HTML5 won’t be implemented across the board for *years*, and by that time we will have a ton of new features that users will crave, and who will fill in those gaps? What languages on top of JS and technologies like Flash provide is a healthy lab of experimentation, which is as essential to the web as any standard. They allow us to build ideas like YouTube or 280Slides years before its accessible with the technologies you get out of the box. The goal is to get everyone on the web — NOT to get everyone using JS. If we could snap our fingers and have Ruby and Python working on the client, I and many others would be satisfied — others would argue that its not “web enough” :/
Unrelated: bumping up the font size would be a huge favor to my bad eyes :)
@Tolmasky:
Your two cents are more than welcome :-).
First, I should address my “death to flash!” statement that I’ve tossed about in this post and even in a few of my tweets.
Take the statement more with a little ‘d’ then a big ‘D’. As I mentioned in my post, Flash isn’t going away now or anytime soon. There are a lot of people who have a vested interest in the technology and like to use it. I’m all down with that.
My little ‘d’ is more about providing additional options on the web both for desktop-like application development and rich, interactive media. Flash holds a dominant market share for rich, interactive media on the web. Microsoft has tossed their hat in the ring too with Silverlight. Awesome. The first started because their was a lack of something on the web and they filled it, the other came about due to competition, and during that time, open web standards pitched in to make a more level playing field and for some level of compatibility among browsers.
My little ‘d’ is also more about a shift away from proprietary technologies that lock you in. Sure, proprietary technologies have benefits and can certainly take a stand by leading the way that others may follow. Open source technology has proven to do this as well.
Aside from little ‘d’ and big ‘D’, in a round-about way, I agree with what you are saying regarding the ideal future of the web that provides lots of great tools that we can use to build really cool stuff. We can definitely shake on that.
Here’s the thing: We all know that the Internet will keep evolving in how it’s used, and from that there will always be a need to create tools that will fill for a wanted feature, abstract away variations between browsers, or what have you, and make people lives easier to build stuff — such is the circle of life *cue the ‘Lion King’ theme song*. Whether or not JavaScript is the dominate language of today’s Internet versus the newer, sexier Internet of the future, I don’t know. That being said, the JavaScript language itself has grown up from being seen as a toy language that web developers plunk around with to something more that can be used in real development, which is what my original post was all about.
A lot of companies and open source communities are investing heavily in JavaScript in one form or another, or at least they right now. So it makes sense for today’s developers to now start understanding how JavaScript works instead of being shielded from it. It’s a powerful language (with admitted flaws).
Should today’s plucky developer just invest only in JavaScript? Heck no. Variety is the spice of life, so learn other languages to get the job done. I know I certainly do. And learning other languages is fun taboot! Now I know I’m an official geek after saying that ;-). And by the way, I’m a big Ruby fan. I use it just as much as I use JavaScript.
Anyway, we’ve taken things to a sort of meta-level — fun! Where are you guys located? On the east coast? West coast? It’d be great to meet up at some point to discuss more about JavaScript and the future of the Interwebz. Awesome discussion :-).
Oh, ya. Regarding the font size, I hear ya. I think my eyes are kind of going on me too. I need to look at upgrading my blog’s layout.
I’m shopping around for a serious client-side framework… the things which are trying to satisfy me so far are pyjamas, sproutcore, and qooxdoo. Clearly, pyjamas is just not thriving the way it needs to, so I’m basically counting it out.
But between sproutcore and qooxdoo: I’m somewhat mystified by how qooxdoo seems in some ways more mature than sproutcore, and has a very slick presentation, yet is much quieter on twitter and blogs. One factor which I understand is that the qooxdoo community is more German, but that still begs the question somewhat – do Germans not use twitter?
So, I’m wondering if you can respond – what’s your view of qooxdoo? Why do you prefer sproutcore?
@homunq
If my knowledge of the Cappuccino framework is limited to simply playing around with it, then my knowledge of the qooxdoo framework is, well, pretty much none existent. That being said, I have occasionally seen the term “qooxdoo” tossed about on the twitterverse with respect to building desktop-like applications in the browser. I would assume Germans like to tweet on Twitter (tongue twister there), but perhaps they just stay quieter about these sorts of things. Who can tell. ;-)
I did go over to the qooxdoo web site to see what they’re all about (http://qooxdoo.org/), and from a quick overview it would appear they have many ideas in common with both SproutCore and Cappuccino to create rich desktop-like applications.
- All three frameworks follow a model-view-controller (MVC) pattern in one form another, which is good.
- They all have a rich set of GUI/view widgets, albeit, SproutCore does not have a table view as part of their official 1.0 release.
- All have a concept of bindings that allows the framework to propagate data changes from one object to another.
- All have some kind of event handling/propagation mechanism so that your widgets can react to incoming user events.
- All have a windowing/dialog type of feature set. Cappucino and SproutCore both follow the pane concept a-la Cocoa framework.
- All the frameworks have some kind of data modeling and datastore concept in order to represent and manage model objects and abstract away server-side communication; again, this is good.
- All come with tools to help unit test the objects and widgets that you make.
- All have some kind of visual tool to help build your application instead of always having to manually code the widgets you want to use, how to lay them out, and how to connect them together. SproutCore now has Greenhouse that was introduced during this year’s JSConf.
You can debate about how they try to accomplish these things at their individual framework level, but if you step back far enough, blur your eyes, and do the hokey-pokey dance, there’s a lot of similarities going on.
So what about the differences between the three frameworks? Well…
- qooxdoo sides more with SproutCore with respect to how to make up up for JavaScript’s lack of language features; those features are part of the framework, not another language like Objective-J.
- qooxdoo uses a set of Python tools to build an application, just like SproutCore has a set of Ruby tools to build SproutCore applications. Cappuccino has no build tools since there is an Objective-J compiler (written in JavaScript) that gets download to the browser and converts the code to JavaScript that the browser can then execute.
- qooxdoo uses a LGPL license like Cappuccino does compared to SproutCore that uses an MIT license. Talk to your corporate lawyers and see how they feel about the two.
- qooxdoo and Cappuccino use more abstraction to keep you away from underlying HTML, DOM and CSS when building and styling your custom GUI/view widgets. In SproutCore, when you build a custom widget at the lowest level, the HTML and DOM are more apparent but it does use a render context object to provide abstraction. Styling in SproutCore is mostly based on CSS through a view’s various class tags.
Aside from tool support to create, test and style your application, the big differences to me come down to the following: 1) How to make up for JavaScript’s lack of language features; 2) How you create custom GUI/view widgets; 3) How easy is it to compose and connect various objects; and 4) the license they use.
I really don’t want to use these comparisons to drive a wedge in how people feel about the frameworks or which one you should use. I’m not here to start some kind of geeky religious war. I believe it’s far more important to provide information and let you decide on your own. Like Objective-J/Cappuccino? Cool. Feel qooxdoo is where it’s at? Awesome. Believe that SproutCore is all our Savior? Perfect.
At the end of the day, like I’ve been saying in my post and previous replies, is that they all help you build a rich desktop-like application on the web and they’re all open source, so you ultimately get to contribute back. We all win against proprietary technology — Whee!
I agree with your main point. Each of these “second-generation” frameworks is a good option, and there’s no need for holy-warring. However, one does need to choose, and that choice will have a significant impact down the line. And since I don’t care about python v ruby build tools or MIT v LGPL, that leaves only one difference between Sproutcore (sc) and Qooxdoo (qx). So, to help myself work through this choice, I’d like to add to your list of differences. This is all from the perspective of someone who has NOT done real work in either sc or qx (and hasn’t even looked seriously at Cappuccino), so please take the following with a big grain of -DISCLAIMER-I could be wrong- and correct me if I am:
-qx is easier to embed in an existing web page alongside other HTML/whatever. Sproutcore pretty much needs to take over your whole page.
-From where I’m sitting, I can’t tell which one would be easier to embed foreign sub-components into (ie, flash embeds such as YouTube, or foreign Javascript). This is not a huge consideration for me, but somewhat salient.
-qx is missing a strong vector canvas at the moment.
-as noted above, sc has a louder (larger?) community. This could mean faster progress.
…
Overall, for me, it’s hard to choose. I see small advantages on either side. The ideal, for me, would be if some amazing hacker created an automated javascript->pyjs wrapper for one of these, so I could use it with pyjs – and write my business logic once for client and server, because my server is python (GAE). But I’m not holding my breath.
So in the end, I’m flipping a (quantum) coin – and hotbits says, pick Sproutcore. In some alternate universe, I’m using qx- but here I go with sc.
@homunq
I have a feeling that there is probably some 12-year-old genius kid from China who is currently in his parents’ basement cooking up the next generation framework that will abstract away and trump SproutCore, qooxdoo, and Objective-J/Cappuccino. When that day comes, we will all bow to him ;-).
But aside from child geniuses, we do currently have good options available to us. Since you’re more focused on SC and QX, let me try to address your points.
Regarding the ease at which to embed a QX app compared to an SC app within a more traditional web page, I’ll take your word for it that QX does make it easy to do. SproutCore is, yes, geared towards taking over the entire screen. However, you can technically incorporate an SC app into a traditional web page, but it’s not obvious, so I wouldn’t, at the moment, call this a feature of SC. In addition, SC hooks into the window and document DOM objects to monitor all incoming browser events, so it really wants control of the web page. You also have the option of including an SC application into a traditional web page by way of an iframe.
Now, as for embedding foreign components, I can tell you from my own personal experience that this is achievable. The team that I work with have managed to include foreign JS frameworks without a problem. And if you’d like to see an example of embedded video in SC, check out the following link: http://papercube.peterbergstrom.com/.
Speaking purely from SproutCore experience, incorporating HTML into your custom views to do interesting things is fairly trivial in SC — not that you *have* to explicitly write HTML or even touch the DOM, but it’s there for your coding pleasure when the need arises.
On your third point, SC is also missing a integrated vector drawing component. This is something that Cappuccino does have. Again, using custom HTML, you can make use of the HTML 5 canvas or include SVG/VML, but, to me, this is something that actually does need to abstracted away by the framework, just like Raphael JS does. I’ve started to address this problem with some others because we need to, and if we develop a proper solution, it’ll probably be open sourced for others to take advantage of.
Finally, to your point that SC has a larger, possibly louder, community, I’m not really sure, but I do know we’re active. There is an active SproutCore IRC channel and news group that you can always access to get help. In addition, people like me and others have blogs to help people write SproutCore code and understand how it actually works.
Although SproutCore is now at an official 1.0 release, it is still maturing as a framework. There are gaps for sure, but they are being addressed. I and the team that I work with have being pushing the boundaries of what SproutCore can achieve for a while now. Where SproutCore is missing some feature or has a bug, we address it and push it openly back to the community. As an example, Mike Ball and Evin Grano started their SproutCore UI framework (SCUI) to include view widgets and other interesting things that SC doesn’t have. (Josh Holt and Jonathan Lewis have also been big contributors to SCUI as well). Ball, Grano and I have all worked together on a new statechart component based on David Harel’s paper (http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf) and it’s now part of SC’s top of tree (TOT). Ball and Grano developed Greenhouse and it’s now officially part of the SproutCore framework. I’ve been building a test automation framework that I call ‘Lebowski’ (yes, after the movie ‘The Big Lebowski’) that is used to perform full feature and integration testing for SproutCore-based applications. I haven’t open sourced it yet, but will soon. In any case, as you can see, there’s a lot of things going on just from the team I work with.
Once again, I’m just telling you and others what I know. Hopefully all the information I’ve provided gives you more information about the framework you’d like to work with in order to build your next generation web app.
SproutCore does not need to take over your web page. You can associate a DOM element other than the tag to base a SproutCore 1.0 app inside of. Nothing about SproutCore assumes that it has “control” or whatever of the entire web page.
that should have said “body” tag above, but the comment system ate it.
@homunq I won’t meddle in discussion SC vs. QX vs. other frameworks but would like to highlight one (really important) point. This is documentation. This is really important for people who’s just starting and for people who uses framework.
I played with SC a little bit and I can say that I like it (especially the way how it manages data and databinding). But it has a big problem – a lack of documentation. I subscribed to all blogs about SC, I checked all wiki articles – it’s not enough. It’s not enough for an easy start. I believe developers will work on it… but you need this right now to start.
On other hand I have been working with QX for a while. They have excellent docs and manuals, their code well documented and there is an API viewer which helps a lot. And the last, but not least, they have very active and friendly community.
So, that’s also a point to consider and a thing which SC team could improve.
@Barysiuk
You make a valid point about documentation. Actually, when I went over and took a look at the qooxdoo web site, I was impressed with their documentation and sample code. So a big kudos to them. I submit that SproutCore’s documentation could certainly be improved.
http://smuglispweeny.blogspot.com/2008/12/road-to-qooxdoo.html has some good info on qooxdoo.
Following both Sproutcore and Qooxdoo for over a year now it seems that one interesting difference between the two is the age/experience of their developers and followers – Qooxdoo’s being much older. That results in SC being more experimental in nature, its developers being interested in learning as they are in producing a framework while learning. From a few personal exchanges I had with them or observed others having in the SC “core team” they have little to no interest in what other people have previously done in this area (unless it comes from Apple of course) and had one developer commenting that one major achievement of SC is its Cocoa affiliation.
As for the proprietary technology – I’m all for it. Lets all drop this Safari that keeps freezing on my MBP for the last year or so and use Chrome.