[transcript] "So, what you should look for, if you are interested in this stuff is if the way it works is that you have to supply an HTML template and it injects that HTML template directly to page, that essentially means that there is not much that they can do to optimize that."
It seems like he's saying that using markup directly and creating a fast, stable javascript api at the same time isn't possible.
He ran around his idea, and I think the phrasing made the whole thing confusing. I guess he's saying that at this point sproutcore can't be thrown at a "template" view (as in, pre-built, possibly even a legacy view from another architecture) and make it perform better immediately. There's no way he could say that markup and a slim, fast and stable JS api can't be done.
TL;DR: it takes a bit of work to make sproutcore perform. Don't throw your current html at it in hopes it does better than everyone else (yet).
Hi - I am the creator SproutCore. Thought it might help to provide some context around this.
It's not that you can't make a fast UI with a template-oriented system. The problem HTML makes it very easy for you to do a lot of things - some are very fast, others are very slow. There is no clear line which is which since it has more to do with how you use the DOM than anything else. To make matters worse, the fast paths are different on different browsers.
What this means is that if you want to build really fast UI in the browser using a DOM-centric, template-based system, you are basically taking on all the responsibility to do everything in a fast way yourself. (Which means you also need to know all the little tricks to doing this - many of which are not obvious.) The framework won't be able to really help you.
This is why a JS-based API that takes ownership over the DOM instead of exposing most of it directly to you can be much faster. We can take this crazy world and turn it right side up again with a cogent API that makes it easy to do fast things and harder to do slow things.
Thanks very much for taking the time to reply. I was unclear on the fact that it was the DOM configuration itself that was causing the performance issues.
I watched the whole video. Interesting material and I have played with Sproutcore a few times in the last couple of months.
My problem with Sproutcore is that I am a casual Javascript programmer and I find something like Dojo easier for me to use. This might change when more developer usability work gets done on Sproutcore. (Spent time this morning hacking with Clojure + Javascript + Dojo, BTW.)
5 comments
[ 5.3 ms ] story [ 30.6 ms ] thread[transcript] "So, what you should look for, if you are interested in this stuff is if the way it works is that you have to supply an HTML template and it injects that HTML template directly to page, that essentially means that there is not much that they can do to optimize that."
It seems like he's saying that using markup directly and creating a fast, stable javascript api at the same time isn't possible.
TL;DR: it takes a bit of work to make sproutcore perform. Don't throw your current html at it in hopes it does better than everyone else (yet).
It's not that you can't make a fast UI with a template-oriented system. The problem HTML makes it very easy for you to do a lot of things - some are very fast, others are very slow. There is no clear line which is which since it has more to do with how you use the DOM than anything else. To make matters worse, the fast paths are different on different browsers.
What this means is that if you want to build really fast UI in the browser using a DOM-centric, template-based system, you are basically taking on all the responsibility to do everything in a fast way yourself. (Which means you also need to know all the little tricks to doing this - many of which are not obvious.) The framework won't be able to really help you.
This is why a JS-based API that takes ownership over the DOM instead of exposing most of it directly to you can be much faster. We can take this crazy world and turn it right side up again with a cogent API that makes it easy to do fast things and harder to do slow things.
hth.
My problem with Sproutcore is that I am a casual Javascript programmer and I find something like Dojo easier for me to use. This might change when more developer usability work gets done on Sproutcore. (Spent time this morning hacking with Clojure + Javascript + Dojo, BTW.)