Unfortunately browsers don't provide much (or really any) information about many non-english input methods. On the plus side, copy/paste does work with any unicode character (if it's any consolation).
This is definitely a problem, and a shortfall of one of our earlier design decisions. We're working on revamping our text system to resolve this, and other issues.
JavaScript doesn't support video at all. That's why 280 Slides uses Flash for videos.
Flash definitely has its place in the web world, I just happen to disagree on exactly what that place is:)
HTML and CSS were designed as document layout tools. They're pretty good at that task, but they aren't particularly good at building applications, or application UIs.
As far as users with JavaScript disabled, an app like 280 Slides simply isn't possible without JavaScript. It's an application, not a website. Declarative languages wouldn't be enough. So, since you need JavaScript to work at all, its reasonable to make design decisions that require it to be on.
This isn't true. The only difference in total communication size between being based on Flash and being based on Cappuccino/Objective-J is that you're downloading the entire runtime when you visit the site, instead of as a plugin ahead of time. This gives the developer control over what version/what features he or she can use, instead of placing the burden on the user's version of flash.
When the runtime is cached, there is no difference in server communication. Since the app is loaded, and then doesn't communicate at all with the sever except to do things like save and open documents, it does exactly the same amount of communication a Flash application would have to. Plus, eventually the runtime can be cached across all sites that opt-in (like Google is doing with other AJAX libraries), further reducing server traffic.
I don't think this is really true. Flash hasn't managed to work on all platforms (like the iPhone), and its certainly not particularly fast on the mac.
Flash and Flex require a (proprietary) plugin, don't work on all platforms (like the iPhone), and are incredibly slow and resource heavy on Macs. Not to mention, being constantly asked to upgrade to the latest version to use some new site is kind of a pain.
In my experience, JavaScript is a much faster approach than Flash. Then again, I'll admit to my own bias.
PowerPoint 2008 on the mac is particularly slow. Actually, I think 280 Slides is significantly faster. It's often faster than Keynote as well, depending on the task.
True. But, we're optimizing for real world use, not Slashdot:).
One thing we're looking into doing is starting to load things in the background once the app is already in use. We can put some of these loads on timers, so as to not affect normal use, but make the initial loads of the UI elements snappier.
There may be some initial delays when you open up new UI elements (since we delay loading to improve initial performance). Our images are taking longer than usual to load.
If you use the app for more than a few minutes (i.e. after you've initially loaded most of the UI), does the issue persist? It shouldn't. The best explanation I could offer is that Firefox 2 on Linux does have some performance issues of its own. FF3 would probably help a lot. That being said, I use it on my macbook pro with FF2 all the time without issue.
Well, the nice thing about Objective-J is that it's a strict superset of JavaScript. At any time you can simply write pure JavaScript and it will run just fine. You don't even technically need to use Objective-J to use Cappuccino (our framework), but it makes it MUCH easier.
As far as using Ruby or anything else, everything we do in the application is pure client side. The only interaction with the server is via XMLHTTPRequests. We'll be able to distribute Cappuccino/Objective-J as a simple download.
I agree that Javascript isn't the best solution to write an entire application. That's one of the reasons we build Objective-J. JavaScript 2 is not around, and likely won't be around at all until next year. Even then, it will only be in Firefox. IE isn't going to see JavaScript 2 for a long time.
More importantly, though, Cappuccino (the framework) is what's really needed to build great applications. Like you said, it IS a non-HTML GUI toolkit. We're abstracting away all the limitations of the browser.
Our load times definitely took a hit when we got posted to slashdot (maybe taking about three times as long as usual), but performance of the app shouldn't be slow at all (since the entire app is executing locally). Mind sharing some information about your browser/machine?
Slashdot Mirror
Where exactly does it "Breaks in places in Firefox?" Let us know and we'll get right on it.
Unfortunately browsers don't provide much (or really any) information about many non-english input methods. On the plus side, copy/paste does work with any unicode character (if it's any consolation). This is definitely a problem, and a shortfall of one of our earlier design decisions. We're working on revamping our text system to resolve this, and other issues.
JavaScript doesn't support video at all. That's why 280 Slides uses Flash for videos. Flash definitely has its place in the web world, I just happen to disagree on exactly what that place is :)
Just to clarify, Sproutcore is something completely different. Cappuccino and Objective-J have no relationship with Sproutcore or Apple.
HTML and CSS were designed as document layout tools. They're pretty good at that task, but they aren't particularly good at building applications, or application UIs.
As far as users with JavaScript disabled, an app like 280 Slides simply isn't possible without JavaScript. It's an application, not a website. Declarative languages wouldn't be enough. So, since you need JavaScript to work at all, its reasonable to make design decisions that require it to be on.
This isn't true. The only difference in total communication size between being based on Flash and being based on Cappuccino/Objective-J is that you're downloading the entire runtime when you visit the site, instead of as a plugin ahead of time. This gives the developer control over what version/what features he or she can use, instead of placing the burden on the user's version of flash.
When the runtime is cached, there is no difference in server communication. Since the app is loaded, and then doesn't communicate at all with the sever except to do things like save and open documents, it does exactly the same amount of communication a Flash application would have to. Plus, eventually the runtime can be cached across all sites that opt-in (like Google is doing with other AJAX libraries), further reducing server traffic.
I don't think this is really true. Flash hasn't managed to work on all platforms (like the iPhone), and its certainly not particularly fast on the mac.
Flash and Flex require a (proprietary) plugin, don't work on all platforms (like the iPhone), and are incredibly slow and resource heavy on Macs. Not to mention, being constantly asked to upgrade to the latest version to use some new site is kind of a pain. In my experience, JavaScript is a much faster approach than Flash. Then again, I'll admit to my own bias.
PowerPoint 2008 on the mac is particularly slow. Actually, I think 280 Slides is significantly faster. It's often faster than Keynote as well, depending on the task.
We work okay with Opera. Especially the latest 9.5 release. There are a few minor issues though, especially with regard to text scaling.
True. But, we're optimizing for real world use, not Slashdot :).
One thing we're looking into doing is starting to load things in the background once the app is already in use. We can put some of these loads on timers, so as to not affect normal use, but make the initial loads of the UI elements snappier.
There may be some initial delays when you open up new UI elements (since we delay loading to improve initial performance). Our images are taking longer than usual to load. If you use the app for more than a few minutes (i.e. after you've initially loaded most of the UI), does the issue persist? It shouldn't. The best explanation I could offer is that Firefox 2 on Linux does have some performance issues of its own. FF3 would probably help a lot. That being said, I use it on my macbook pro with FF2 all the time without issue.
Well, the nice thing about Objective-J is that it's a strict superset of JavaScript. At any time you can simply write pure JavaScript and it will run just fine. You don't even technically need to use Objective-J to use Cappuccino (our framework), but it makes it MUCH easier. As far as using Ruby or anything else, everything we do in the application is pure client side. The only interaction with the server is via XMLHTTPRequests. We'll be able to distribute Cappuccino/Objective-J as a simple download.
I agree that Javascript isn't the best solution to write an entire application. That's one of the reasons we build Objective-J. JavaScript 2 is not around, and likely won't be around at all until next year. Even then, it will only be in Firefox. IE isn't going to see JavaScript 2 for a long time. More importantly, though, Cappuccino (the framework) is what's really needed to build great applications. Like you said, it IS a non-HTML GUI toolkit. We're abstracting away all the limitations of the browser.
Our load times definitely took a hit when we got posted to slashdot (maybe taking about three times as long as usual), but performance of the app shouldn't be slow at all (since the entire app is executing locally). Mind sharing some information about your browser/machine?