The important thing is that client-side rendering stays on the client and doesn't need to go back to the server. If you have any noticeable latency (read: everything on mobile, desktop clients not close to a server), needing to go back to the server to render will ruin the perceived performance of your app. Well-written applications running on the client can take a change and optimistically render that before the change has even been persisted back to the database. This is inherently faster. If you're able to invest in the infrastructure to allow you to do this on the server, and your use cases allow you to make that decision, then the trade-off is a little less black and white.
One thing I've noticed is that Google likes to use RC4_128 as their encryption method for SSL. Most people just pick AES_256_CBC like 37s has. RC4_128 is so much faster in tests we've run. Of course, there's a possible security trade off, sort of. RC4, I believe from reading, is still plenty strong when it's properly implemented.
I've definitely observed this performance difference, and it is quite significant. However, the new AES-NI instructions in more recent Intel chips may lessen the performance difference over time, as more users buy machines with these chips. (Of course, that won't help mobile devices yet, and it's possible that one could equivalently speed up RC4 with those instructions as well.)
But I know the latest OpenSSL does have an AES implementation that uses AES-NI when those instructions are supported.
The important thing is that client-side rendering stays on the client and doesn't need to go back to the server.
It still needs to go back to the server to fetch new data. And it's not like rendering on the client side is instant and free. There are plenty of JS-heavy websites that visibly lag during UI operations because of all the stuff that goes on during "rendering" (in quotes, because it usually includes large chunks of business logic).
If you want to use a decent library, you can rest assured that your client-side templates will render far faster than the Ruby version of the same HTML.
Even considering I do not have an 8 core machine with 32 GB of ram sitting on my lap (or in my pocket)?
I realize that ruby is significantly slower than v8/JägerMonkey/Tracemonkey/etc, but is it so easy to discount the significant disparity between the average compute power of a server vs mobile/laptop?
I think a stronger counter argument would be flexibility, smaller http responses (and thus less latency), and possibly an argument that it is simpler or more straightfoward, in favor of client-side javascript templating/rendering, but rendering speed? Not so sure.
I have a subscription to the Atlantic because of reading the articles and their blogs online. I don't think it would be incorrect to attribute their turnaround in going digital first. I've been reading their properties for years and there was definitely a change (perhaps in just attitude).
We're definitely working on the documentation situation. We learned hard lessons with the 1.x series, which remained undocumented for far too long. If you want to send me an email and let me know what you thought was lacking in the docs (can be as specific or general as you'd like), I'd really appreciate it: colin at sproutcore dot com
What's lacking for me is something that explains what currently is and is not possible in the 2.0 branch. For instance, it's not immediately clear what's going on with the UI components, datastores, and routing. Are these planned, implemented, or never going to be ported from 1.6?
I'd also love better documentation on how to integrate 3rd party UI libraries like Closure, YUI, Jquery UI.
The problem is there is no guarantee they will play nicely together, not clash, or provide similar and compatible APIs. JavaScript developers are running into a very similar set of problems and having everyone cobble together their own solutions is pretty clearly not an answer, which obvious to those who have tried. You may already know what is being abstracted by some of the more expansive frameworks (Cappuccino, SproutCore, Backbone, etc) but there are a lot of people who do not know or do not want to deal with the differences in browsers, etc.
I'm assuming that you don't consider jQuery or its ilk restrictive as far as abstracting the DOM. I don't know of many application developers who would prefer to deal with the low-level DOM API (which differs across browsers, etc) instead of a library like jQuery. There are many people who approach application structure from a similar viewpoint. Instead of rolling their own and running into problems scaling and maintaining their applications, they can use a framework that provides an abstraction that is proven to work. Everyone tries to roll their own pet framework project because that's where the glory is. That's not necessarily the best thing for the future of the web.
> Everyone tries to roll their own pet framework project because that's where the glory is.
Here's jtaby about twenty minutes earlier:
> Everyone today wants to get the personal glory out of their own little pet project instead of getting the glory out of contributing important patches to existing projects.
The diminutive "little pet" prefix at one point applied to: linux kernel, kde, gnome, jquery, prototype.js, node.js, ruby, &etc. Your dismissal of small, young projects is akin to saying "Don't start a startup, just join a big business!"
You're calling out to people in the Bazaar and asking them to join your Cathedral. Good luck!
I agree that rolling new frameworks/libraries out for the glory only is a terrible thing but they generally don't do much harm since the truly atrocious projects fade into oblivion. We can only hope at least one thing was learned from them.
I do not consider jQuery restrictive and in fact it's liberating because it provides a core set of tools that are much more useful than the core tools provided by native JS. jQuery was born out of a need. As long as something is more useful than what it wraps I tend to not mind it. But wrapping things arbitrarily like HTML is just useless.
I do see a stark difference between marrying independent frameworks that are proven and writing a brand new one that encompasses all the ideas of each.
We're working on new demos, and a new website. Demos feature much more heavily in the new design, and you definitely don't (and won't) need to install the build tools to run them!
I would encourage you to make that a priority. Every time I see something about SproutCore, I'm interested but end up not doing anything with it. I keep hearing about the demos being out of date.
Things like this: "we have a great new default theme called Ace 2.0"
Sounds great, how about a screenshot or two, if not a demo?
And this: "looks at home on ... mobile operating systems"
More info please? I'm interested but I see no examples, screenshots or other info about doing mobile dev. Device, browser and OS support?
Fair points all around; I agree wholeheartedly. Here's what the problem has been thus far: do we focus on making the framework better, or do we focus on selling it? Personally, I'm much more comfortable with making sure we deliver the goods before we try to sell it. That's what SproutCore 1.5 is about. This is the first smoke signal of where we want to head with the framework, and people can take that for what it is. The core of the framework is amazing and fun to work with, but a lot of our demos are old and ugly. In many cases, our documentation has been or is still lacking and we're working on that too.
This obviously makes it a tougher sell. However, when people actually start building apps, their responses are overwhelmingly positive and they're very happy with their decision. I would much rather this problem than vise versa. We're going to work on the outward facing stuff, I promise.
Good to hear. The way I (and most people) decide which frontend libraries to use are by seeing them in action. Then I can decide after evaluating it technically if it's something I want to use or not.
Couldn't agree more Colin, let us (the community of people building apps with it) continue to do the evangelizing, your team has been doing a great job and we appreciate it a lot.
agree with the above...went through some eval on SC a few months back. We didn't go with SC, not for the lack of the demo link (swear the demo link wasn't there then :)), but I recall being a bit off put about it as well
...seems there has been a lot of development since though, some updated demos would really be nice.
I wholeheartedly agree that SproutCore's documentation is poor. There have been plenty of reasons (and excuses) provided, but regardless, that still doesn't cut it. We're beginning to rectify the situation with Guides (http://guides.sproutcore.com) which was announced on Friday. There is already one written (http://guides.sproutcore.com/fixtures.html) and there are more in the pipeline, being written by both core team members and developers from the community. Given we're a startup, sometimes things need to take a backseat but Strobe is definitely committed to making developing web apps as easy as possible and documentation is high on the priority list.
Yehuda has already made some fantastic changes to the Abbot build tools that should be landing with the 1.4 release any day. It's in rc2 right now, just run gem install sproutcore --pre, the tools are super fast now.
Greenhouse isn't ready to be compared to Atlas just yet, the development has only been ongoing for a matter of weeks. That being said, Atlas costs money, and Greenhouse is completely open source:
If you're more comfortable with Obj-C/J, then Cappuccino is the way you should go. Personally I use SproutCore because I'm far more comfortable in JS/HTML/CSS.
