Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MacRumors

macrumors bot
Original poster
Apr 12, 2001
68,103
38,855


Last week's news of Apple's adoption of the SproutCore Javascript framework was met with a shrug of the shoulders by some web developers. Indeed, SproutCore itself is just the packaging together of existing web technologies into a developer-friendly package. No brand new capabilites were introduced to what existing web applications are currently able to do. That being said, a technical interview (podcast) with SproutCore's creator provides some interesting insight behind its development. Specifically, special efforts have been made to provide an efficient development environment as well as efforts to decouple the application from the server itself. In essense, the final web application runs in your browser alone and can be entirely independent of the web servers.

By itself, this is just an interesting footnote for end users, however, a few other tidbits make for some interesting future possibilties.

With the introduction of Safari 3.1, Apple introduced a few Safari-specific features. This included CSS Animation. We've heard that Apple demonstrated even more advanced browser-based 3D animation capabilities at WWDC. At WWDC, these features were demoed in the context of the iPhone, allowing developers to create CoverFlow-like functionality and animation within mobile Safari itself.

Another relevant feature is the recent adoption of client-side storage which allows web-applications to store data locally. This means that web-applications could be independent of an internet connection.

Developers and users alike may cringe at the thought of these poorly-adopted web features, since only Safari and web-kit based browsers are capable of supporting many of these features at this time.

However, Apple's inclusion of "Save as Web Application" feature in Safari 4 could alter this reality. By bundling Webkit into a standalone executable, developers could theoretically release downloadable Webkit-based applications for use on Windows XP, Tiger and Leopard. To the end user, these would appear as standard applications, but the underlying technologies would be Webkit and Javascript.


Article Link
 
I'm not sure I understand the usefulness of this concept. Why not just make a full-blown app that simply syncs itself via internet connection as necessary?

As a casual web designer, I appreciate the value of more flexible and more efficient in-browser capabilities. But I don't see real value of a "webapp" that has to be downloaded in its own little package to be used properly when you could simply make a "real" one.

Is it something to do with being lightweight and having a new level of cross-platform compatibility?
 
I'm not sure I understand the usefulness of this concept. Why not just make a full-blown app that simply syncs itself via internet connection as necessary?

That was my first thought too. Unless I'm missing something, the only advantage of these webkit based apps is that the same version can run on both Mac and PC.
 
Wow. This could be very interesting, especially if they build in this functionality into X-Code as you could build web info apps that rely solely on browser technology, unlike the .net framework and java. With that, you wouldn't have to code specifically for a platform, you could distribute it to any platform that supports these technologies. Of course, the feasibility of this is probably remote. Well, one can hope right? :D
 
This sounds more like a night-mare than a nice dream. The history of HTML is a history of undefined presentation. I don't see the point in creating an application in a language like javascript that is meant to behave the same on all platforms AND is meant to be good on performance.
Java on the other hand is well defined. And it has a UI that works on all platforms and it is performant and it is available to many platforms too.
 
i have tried prism and fluid to run certain sites (eg meebo) on my desktop. then i realise i have more desktop clutter, and i just end up going back to using site in tabs in firefox.

i only see this as useful (as it stated in teh first post) when i do not use a webkit browser, and i need access to a features in a sproutcore site. i am all for improvement but i would probably avoid more desktop clutter.
 
to write a javascript local app w/o internet interaction...and throw in some CSS term just for authority.....

.........

.........

The point being? cross-platform?
 
This sounds more like a night-mare than a nice dream. The history of HTML is a history of undefined presentation. I don't see the point in creating an application in a language like javascript that is meant to behave the same on all platforms AND is meant to be good on performance.
Java on the other hand is well defined. And it has a UI that works on all platforms and it is performant and it is available to many platforms too.

You're joking, right? Java has a UI that works on all platforms?

Apple has noticed that most developers moving to their platform don't develop for Windows; they develop for the web. With that in mind, Apple is making sure that the web is not a second-class citizen of the development world. It's going to become very possible to develop native-like apps using technologies already mostly familiar to many web developers. This is a much faster route for them than learning Objective-C, Cocoa, etc. I'm certainly in that boat myself.

I hope it isn't constituted as an NDA breach if I say that the hardware-accelerated CSS technologies and other new features demoed for WebKit at WWDC were impressive as hell.
 
This is Apple's response to Silverlight and AIR/Flash.

This is probably one of the main reasons Flash isn't on the iPhone.
i dont see javascript and css has nearly as much function as flash. I dont speak for silverlight sinve i know nothing about it.
You're joking, right? Java has a UI that works on all platforms?

Apple has noticed that most developers moving to their platform don't develop for Windows; they develop for the web. With that in mind, Apple is making sure that the web is not a second-class citizen of the development world. It's going to become very possible to develop native-like apps using technologies already mostly familiar to many web developers. This is a much faster route for them than learning Objective-C, Cocoa, etc. I'm certainly in that boat myself.
....

what does UI do? do safari-web-applications have an UI at all?

Apple is making sure it combine its resource together and sell for more $$$, whatever intention you described, that 3% global marketshare isn't gonna work.

Again, js and css are limited, limited, and limited.
 
i've been impressed as hell with the advances of the webkit team. they make mozilla look like the IE team (e.g. lots of excuses, slipping schedules, slow uptake on new technology).

all someone needs to do now is create a killer web-kit only app. not necessarily to re-start the "best viewed in" wars of the early 90's, but to accelerate the adoption of web-kit to mozilla like market-share.

we've seen what the threat of one browser with 15-20% market share has done at the IE team* imagine what two browsers with a combined market share of 30-50% would do... and i might also kick mozilla up the rear to stop making excuses for their slowed rate of innovation.

*admittedly not ideal, but IE7 is damn site nicer/easier to develop for than IE6.
 
i've been impressed as hell with the advances of the webkit team. they make mozilla look like the IE team (e.g. lots of excuses, slipping schedules, slow uptake on new technology).

amazing, you call this web-app (which is a direct copy of prism from mozilla lab) innovation?

mac users need to learn more facts first.:p
 
Unlikely to be effective until JavaScript 2

Not to knock JavaScript/HTML/CSS development, but until the next revision of JavaScript becomes official, using it as your primary development language is likely too slow for many applications.

Adobe/Mozilla are working on the Tamarin project, an open source JavaScript engine that will support JavaScript 2 (an implementation of ECMAScript 4) and allow for JIT compilation which will bring a significant speed boost to the execution of JS. Originally developed internally at Adobe/Macromedia, it brought around a 10x speed increase for ActionScript (another implementation of ECMAScript).

But, by the time that JS2 becomes official, WebKit supports JIT compilation, and developers start working in this new environment, who knows what else we'll have to work with.

WebKit is already a platform of sorts when you consider that both Fluid and Adobe AIR use it to generate desktop apps using web-dev technologies. So it makes sense that future app development will continue to move in that direction.

But, in the short run, my money is on Adobe to continue to make huge gains in the space. Aligning ActionScript with JavaScript 2 and Mozilla AND opening up the SWF format makes me think that Adobe is thinking in terms of the next decade, and not the next 6 months.

Exciting times ahead!

References:
Tamarin - http://en.wikipedia.org/wiki/Tamarin_(JIT)
John Resig on Tamarin - http://ejohn.org/blog/why-tamarin-instead-of/
 
Not a wonderful desktop app framework

I think desktop app developers are shrugging their shoulders, too.

I mean it's always nice to have another option. But client-side storage + CSS Animation + the sproutcore framework isn't going to cut it for a lot of desktop apps. Sproutcore is sluggish and simplistic compared to native options. The few controls available only roughly mimic native ones. No one is going to mistake a sproutcore app for a native one. Do desktop app developers really need another option for creating sluggish, simplistic, least-common-denominator-style cross-platform apps?

Put it this way: this approach has substantially the same drawbacks of typical web apps but few of the benefits of native desktop apps.
 
Um. Again, as a continuation of my last post and again as a casual web developer, I think that if this is about putting proprietary capabilities into the hands of web developers and then putting their proprietary "webapps" on the end-users desktop, then I must be entirely missing the train.

Web developers aren't "second-class citizens," they're citizens of a different nation, so to speak. I really think that if you want to have advanced in-browser capabilities that that's wonderful and great; but to enable this at the expense of requiring increasingly proprietary scripting is a problem to begin with, and trying to put that in a faux-desktop-app is even more troubling.

Why not just let these features stay in-browser and let the desktop apps stay to desktop app developers? Not to mention that the people viewing the actual content in my nifty-awesome-super-new-technology-downloadable-"webapp" don't want to have to download a "whole program" (which is what it is, as far as they're concerned) to have to access to that content.

Again, I'm all for better in-browser performance regarding client-side scripting and client-side storage and such. But I really believe that the better solution is promoting Safari as the browser that can do this best - not making some cluttering little downloadable webapp that makes things more confusing and proprietary for the end-user.

Am I opposed to Apple developing this? Of course not. I just think it's a waste of time. I'm willing to accept that I might be wrong, but I just don't see the usefulness at this point. Unless that point is merely cross-platform compatibility... in which case the better pursuit would seem to be further developing, streamlining, and pushing Safari for Windows instead of a gaggle of webkit downloadable apps just to properly view content.
 
You should let know Google know about the limitations as they are pretty busy implementing an entire office application in just that...

well, my friend, do you really believe google docs can do nearly as much as M$ office, or apple iworks, or openoffice?

get real.
 
Not to knock JavaScript/HTML/CSS development, but until the next revision of JavaScript becomes official, using it as your primary development language is likely too slow for many applications.

Adobe/Mozilla are working on the Tamarin project, an open source JavaScript engine that will support JavaScript 2 (an implementation of ECMAScript 4) and allow for JIT compilation which will bring a significant speed boost to the execution of JS. Originally developed internally at Adobe/Macromedia, it brought around a 10x speed increase for ActionScript (another implementation of ECMAScript).

But, by the time that JS2 becomes official, WebKit supports JIT compilation, and developers start working in this new environment, who knows what else we'll have to work with.

WebKit is already a platform of sorts when you consider that both Fluid and Adobe AIR use it to generate desktop apps using web-dev technologies. So it makes sense that future app development will continue to move in that direction.

But, in the short run, my money is on Adobe to continue to make huge gains in the space. Aligning ActionScript with JavaScript 2 and Mozilla AND opening up the SWF format makes me think that Adobe is thinking in terms of the next decade, and not the next 6 months.

Exciting times ahead!

References:
Tamarin - http://en.wikipedia.org/wiki/Tamarin_(JIT)
John Resig on Tamarin - http://ejohn.org/blog/why-tamarin-instead-of/

There's nothing that stops a JIT compiler being used for ES3 (ECMAScript). ES4 does nothing to make a JIT compiler any more possible (partly because it claims to be compatible with ES3 in ES3 compatibility mode). At the moment, SquirrelFish (the ES interpreter in WebKit trunk) is quicker than Tamarin: JIT compilation isn't everything. The difference between modern JIT compilers and modern interpreters isn't much.
 
i dont see javascript and css has nearly as much function as flash. I dont speak for silverlight sinve i know nothing about it.

....

what does UI do? do safari-web-applications have an UI at all?

Apple is making sure it combine its resource together and sell for more $$$, whatever intention you described, that 3% global marketshare isn't gonna work.

Again, js and css are limited, limited, and limited.

I guess you haven't seen the MobileMe apps built with SproutCore - these are desktop quality apps. Basically Apple Mail, Address Book and iCal, all running in javascript inside web browsers.
 
I guess you haven't seen the MobileMe apps built with SproutCore - these are desktop quality apps. Basically Apple Mail, Address Book and iCal, all running in javascript inside web browsers.
Jesus, did you see google calendar? google doc? yahoo mail? AOL mail?

You call that desktop quality apps?

I think I have different standard. yes, much higher standard to define a "desktop quality apps".

PS. when I said "limited", which, I think, means there are much it can NOT do.
 
well, my friend, do you really believe google docs can do nearly as much as M$ office, or apple iworks, or openoffice?

get real.

If you're strictly looking at feature comparison, then no one would use anything but MS office. It by far has the most features. In real use how of those features are actually used though? I think we're coming quickly to a point in time where people will ask "how much more do I need in a word processor or home use spreadsheet?" Do the Google apps do everything that MS does? No, but they don't need to. The Google apps meet a lot of the common demands and since they are server based the user gets an automatic back up to boot.

Google has only scratched the surface with what's possible with standard ECMA script and a browser. Every computer, cell phone, internet device, etc... has a web browser. The browser is the ubiquitous platform and I personally don't see that changing anytime soon. I'm expecting to see more and more web applications replace desktop applications in the future.
 
well, my friend, do you really believe google docs can do nearly as much as M$ office, or apple iworks, or openoffice?

get real.

Not only can, but will. It may take them some time, though recall they're doing this for free, but the capabilities of these web apps can certainly approach and exceed the capabilities of the programs you mentioned (with the possible exception of the iLife integration of iWork).

Oh, and try not being so rude next time.

jW
 
I think there's some bad assumptions here

I don't see this new feature of Safari 4 as a move by Apple to have browser-based desktop apps that don't use a network connection. I see this simply as Apple's acknowledgment that Fluid is a good idea.

Fluid does not obviate the need for an internet connection nor does it create WebKit apps that 'don't need an internet connection.' It simply creates a site specific browser - which still needs an internet connection to browse that specific site.

As far as I can see, Safari 4 is adding a feature that does exactly what Fluid does - except at this point, Fluid has way more features.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.