Domain: 280slides.com
Stories and comments across the archive that link to 280slides.com.
Comments · 11
-
Re:Normal people hate web apps.
Try 280slides.com
-
Re:"pages render faster"
Alright, consider Javascript. Consider Google docs, spreadsheets, gmail.
Heck, consider http://280slides.com/
That last one is re-implementing appkit (cocoa) in javascript, complete with Objective-J (an Objective-C inspired extension to Javascript), with all of this compiled down to plain, ordinary javascript that then has to run ... slowly, sadly, without good browser support.
Faster rendering? Don't think "Just put the text up on screen". Think "Load the images; remap the colors by ICC 2 standard color conversions; automatically adjust size and anti-alias the images. Run arbitrary programs, because with Javascript we are now an asynchronous execution engine, not just a text formatter. Deal with tables that don't force precomputed sizes, but are nested arbitrarily deep that we have to resize based on user font size preferences."
Did I miss any other big CPU issues of the modern web?
Frankly, I'd put the "Target speed and power" at 1.42 GHz, G4, or about 1.8 GHz, single core. Yes, newer systems are bigger, badder, faster, but there's an awful lot around that speed out there. -
Re:Options
I'm almost positive you could do that entire site with HTML5 and javascript, and if you wanted an easy development environment, you'd use something like Cappucino, which is just a a language and framework that compile to javascript and HTML4. Take a look at their demo powerpoint app.
-
HTML 5?
I'm still surprised companies aren't jumping on the HTML 5 bandwagon. Eschew flash and plug-ins for native web browser applications and video. http://280slides.com/ is a great example of what can be done. The ObjectiveJ they're developing is truly amazing - and it's all browser native. Even IE 8 works. I hate to say it, but Apple are right for once - get rid of flash and other plug-in based user interfaces and get back to basics. Share your JavaScript frameworks, use local storage and more - embrace HTML 5.
-
Re:Could someone please..
Show me an example of a website with so much javascript that it is too slow to use?
280 Slides. It won't bring Mozilla to a crawl, but it is noticeably faster on Chrome. IE is almost unusable.
I'm actually excited about sites like this - web apps could really go somewhere if they were all this feature-rich.
-
Re:And for their next trick:
If it's as cool as their online presentation application, I'll actually be a tiny bit excited. The newest browsers actually run 280slides.com pretty well. Safari is acceptable and Chrome actually screams.
For the love of God, please don't run it in IE.
-
Re:It wont even install for me
I finally found a "Wow" application with it - 280 Slides. It's actually the first browser where it feels like you could really use it instead of Powerpoint (from a performance standpoint).
-
Re:Javascript can never run as fast as C
It's true that for applications where a Javascript function takes a long time to execute, that translation overhead can be neglected, yielding comparable speed with C, however such functions are rare enough in ordinary web applications that the point is moot.
They're becoming increasingly less rare as people write more complex applications for the web. There are Javascript libraries that do complex layouts not possible in CSS/HTML which dynamically resize when you drag and drop items around. Someone a Keynote workalike, which chugs badly on slower machines -- while you could probably blame a lot of it on DOM, the Javascript and the Objective-C-like abstraction layer and windowing library probably doesn't help.
So it might be that it "only" takes 400 ms to update the layout after you drag a slider to resize a divider, but it'd be great if it only took 100 ms, especially on old hardware. If you only compile code that actually gets executed, the translation overhead might be less than you think. In particular, the method mentioned in the article uses a less expensive type of JIT than traditional JIT compilers.
-
Re:JavaScript is Extensible!
I mean http://www.280slides.com/ - Sorry all.
-
Re:Damn ...
1MB+ of code and images + Slashdot = not happy. But once the app is loaded, it runs quite fast since it only talks to the server when it absolutely needs to. Load the app directly here: http://280slides.com/Editor
-
280 North seems to have the same idea in mind.
It seems like the guys at 280 Slides have been working on something similar. They have an Apple background and called their language Objective-J, from what I can tell it's an extension on JavaScript in a similar manner to way Objective-C is to C. Their Cocoa like framework on Objective-J is called Cappuccino.
Now I don't know if SproutCore is anything like what they are doing (wasn't at WWDC so I don't know the details), but the end goals of both projects seem like the same thing. A language and framework where whatever you make should just work across browsers. It's very early days for both, so we will have to see. From the article it seems like SproutCore is going to be fairly open. The 280 North guys seem like they want something similar for Objective-J and Cappuccion but they are still working on cleaning up the frameworks.
Either way, the competition should be good and hopefully bring sanity to the client side scripting world.