Linked by Adam S on Sun 15th Jun 2008 21:59 UTC
General Development RoughlyDrafted Magazine has posted an in-depth article that examines Sproutcore, an Apple-backed Javascript framework that approximates Cocoa on the web. The article examines why using HTML, Javascript, and CSS just may win the battle with Flash, Silverlight, and Java for rich internet application deployment. Sproutcore enables web developers to create full-featured cross-browser web apps an in a Model, View, Controller convention, much like Rails. The Sproutcore site has some great tutorials that show off the framework.
Order by: Score:
The killer app
by chrono13 on Mon 16th Jun 2008 00:39 UTC
chrono13
Member since:
2006-10-25

The killer app is ubiquitous video playback.
Can this solution meet the following?
1. Play video in browser
2. Stream said video
3. At reasonable compression
4. Be ubiquitous (not require installing Yet Another Codec)*.

And somewhat less important, as it does not pertain specifically to video playback, is number 5) be interactive (games).

*I understand that Flash requires an install, but it is often pre-installed via OEM.

Silverlight and Flash are able to do all of this. Any serious competitor will have to be able to do this, and offer as-good-as development/video tools to be even remotely competitive in the Flash-dominated web.

Silverlight will make huge inroads on Flash simply because Microsoft.com (and thus by default IE) is bugging everyone to install it. See again point 4.

Edited 2008-06-16 00:42 UTC

Reply Score: 5

RE: The killer app
by Kroc on Mon 16th Jun 2008 11:22 UTC in reply to "The killer app"
Kroc Member since:
2005-11-10

And I would add to that list: DRM.
If video can't be streamed without suitable protection, the paranoid providers will simply stick to Flash and Silverlight (Here's looking at you BBC, ITV)

Reply Score: 4

RE: The killer app
by aliquis on Mon 16th Jun 2008 13:09 UTC in reply to "The killer app"
aliquis Member since:
2005-07-23

There already exist a standard for video on the browser, and Safari already supports it. So nothing more needed.


Anyway, I'm all for anything which can get us away from the crap flash is. I haven't tried Silverlight but it's probably much more heavy on system resources than a webpage with javascript anyway.

Reply Score: 2

RE: The killer app
by chrish on Mon 16th Jun 2008 14:26 UTC in reply to "The killer app"
chrish Member since:
2005-07-14

I'm a little concerned about how Silverlight's major version keeps going up without any significant adoption by anyone other than microsoft.com. Major versions = incompatible changes, and nobody's even using it yet...

Reply Score: 1

RE: The killer app
by Wes Felter on Mon 16th Jun 2008 18:48 UTC in reply to "The killer app"
Wes Felter Member since:
2005-11-15

I think you're taking Web video mania a little too far; there are plenty of Web 2.0 apps that don't use video (ahem, MobileMe).

Reply Score: 2

Different market
by unoengborg on Mon 16th Jun 2008 00:43 UTC
unoengborg
Member since:
2005-07-06

This framework looks interesting, but I'm not sure it will appeal to Flash current developers, as they tend to be more of the designer type than the programmer type of people.

My guess is that most Flash developer will prefer some drag & drop/point & click kind of tools over command line stuff like this. So I wouldn't hold my breath while this takes over the market of Flash. At least not until there are GUI based development tools for it.

The idea that Javascript and .*ML could take over the role of Flash sounds interesting especially now when both Firefox and Webkit improved a lot on Javascript performance.

Reply Score: 8

RE: Different market
by hobgoblin on Mon 16th Jun 2008 04:48 UTC in reply to "Different market"
hobgoblin Member since:
2005-07-06

designers indeed. only time i bump into full page flash is when its some design house showing off or similar...

Reply Score: 3

RE: Different market
by rain on Mon 16th Jun 2008 09:35 UTC in reply to "Different market"
rain Member since:
2005-07-09

This framework looks interesting, but I'm not sure it will appeal to Flash current developers, as they tend to be more of the designer type than the programmer type of people.


That's a myth really, there are both kinds using flash. With flash there are basically two approaches, either design and add function or create function and add design.

Lots of people are actually developing flash apps without ever touching the "design"-tools of flash. I personally find that to be the most convinient approach for more advanced applications.

Reply Score: 1

Progress?
by samad on Mon 16th Jun 2008 00:56 UTC
samad
Member since:
2006-03-31

Perhaps frameworks like this will make obsolete coding HTML or JavaScript, even with GUI tools, in the same way that programming in assembly is obsolete when one can use Java or Python. (By obsolete I mean there are other tools out there that are far more useful and productive to use.)

Reply Score: 3

RE: Progress?
by richmassena on Mon 16th Jun 2008 04:47 UTC in reply to "Progress?"
richmassena Member since:
2006-11-26

If we could abstract away all of the javascript/html/css and deal with a higher level of code, I'm ready to jump on board.

I don't have much experience outside of web development, but it has to be one of the worst platforms (if you can call it that). Four major browser vendors (plus versions) to develop for and test (coding to standards, but we know how IE behaves). Not to mention 5 different languages to master (e.g. PHP, SQL, Javascript, CSS, and HTML).

Was programming Unix targetting DEC, AIX, SCO, SunOS, etc. like this?

Reply Score: 2

RE[2]: Progress?
by -pekr- on Mon 16th Jun 2008 11:55 UTC in reply to "RE: Progress?"
-pekr- Member since:
2006-03-28

Exactly. So weeee, REBOLs, are working on our own future - REBOL3, for some two years already. While not popular, REBOL was RIA even before RIA term was born :-)

Reply Score: 1

RE[2]: Progress?
by FunkyELF on Mon 16th Jun 2008 14:18 UTC in reply to "RE: Progress?"
FunkyELF Member since:
2006-07-26

If we could abstract away all of the javascript/html/css and deal with a higher level of code, I'm ready to jump on board.


Have you looked at Google's Ajax framework? You write it in Java and it gets compiled into Javascript. They take care of all of those IE vs. Firefox little intricacies. I haven't used it myself but I went to a presentation on it at JavaOne a year ago and it seemed to do a pretty good job at abstracting all that other stuff away.

Reply Score: 2

RE[2]: Progress?
by rain on Mon 16th Jun 2008 16:48 UTC in reply to "RE: Progress?"
rain Member since:
2005-07-09

I don't have much experience outside of web development, but it has to be one of the worst platforms (if you can call it that). Four major browser vendors (plus versions) to develop for and test (coding to standards, but we know how IE behaves). Not to mention 5 different languages to master (e.g. PHP, SQL, Javascript, CSS, and HTML).


By using a good php framework and a good javascript framework you will have to deal a lot less with such things. You don't need to know SQL to interact with a database, unless you want to do advanced stuff. And there's abstraction layers for the other things as well (even javascript).

If you use a good javascript framework (like ExtJS for example) you won't have to work so hard to make things work in all the browsers, the framework developers will do that for you.

Not that it solves all issues with web development, but at least there are tools to make it a whole lot more comfortable.

Reply Score: 1

RE: Progress?
by Clinton on Mon 16th Jun 2008 04:59 UTC in reply to "Progress?"
Clinton Member since:
2005-07-05

For most tasks programming in Java is obsolete when you can program in Python.

Java is too wordy and takes too much time. Python is a much better language to write in, I think. Java has its place, to be sure, but it isn't everywhere and probably not even most places it is currently being used.

Reply Score: 1

RE[2]: Progress?
by makc on Mon 16th Jun 2008 05:53 UTC in reply to "RE: Progress?"
makc Member since:
2006-01-11

Static checking.

Reply Score: 2

RE[3]: Progress?
by FunkyELF on Mon 16th Jun 2008 14:21 UTC in reply to "RE[2]: Progress?"
FunkyELF Member since:
2006-07-26

Static checking is okay, but it becomes a pain in the ass to have to declare types of everything.

In Java if you have a method that needs to return two Vectors of Strings, you can put them in another Vector... public Vector<Vector<String>> getSomeStuff();

But if you need to return two things of two different types you wind up using Vector<Object> and your static checking is no good. And you'll run into class cast exceptions at runtime just the same as you would in Python.

Reply Score: 2

RE[4]: Progress?
by danieldk on Mon 16th Jun 2008 18:36 UTC in reply to "RE[3]: Progress?"
danieldk Member since:
2005-11-18

But if you need to return two things of two different types you wind up using Vector and your static checking is no good. And you'll run into class cast exceptions at runtime just the same as you would in Python.


In the very rare case that using two getters is not more appropriate, why not use a simple wrapper class as the return type, along the lines of C/C++ structs? You retain static type checking, and it is actually clear to the caller what a method returns by looking at its signature.

Reply Score: 3

RE[5]: Progress?
by FunkyELF on Mon 16th Jun 2008 19:42 UTC in reply to "RE[4]: Progress?"
FunkyELF Member since:
2006-07-26

There are many times when using two getters isn't appropriate. Imagine needing to get two different hashmaps from a server that have the same data but with different keys. If creating those tables requires costly database calls you should create both objects at the same time since they have the same data. You could do it in two separate getters, but you'd either be 1: doing the same work twice, or 2: caching an object that you won't know when to free.

Your other solution of creating a wrapper class does not scale well. You could easily wind up with more wrapper classes than real classes.

I have been programming in Python recently and when I go back to maintain something I wrote in Java a while back I just wish I would have started in Python.

Reply Score: 2

RE[2]: Progress?
by danieldk on Mon 16th Jun 2008 07:52 UTC in reply to "RE: Progress?"
danieldk Member since:
2005-11-18

For most tasks programming in Java is obsolete when you can program in Python.


I can think up many reasons why this is nonsense:

- Java with modern JDKs is *a lot* faster in most areas than Python. For the applications I have written it comes close to C++ (it's mostly a bit slower, but it can be a good trade-off).
- Java enforces static type checking. I know that there is a continuous battle about static vs dynamic type checking. But for larger applications I am on the static type-checking side of the fence. I like to check as much at compile-time as possible.
- Java has a very extensive class library, and many high-quality frameworks are available.
- Java is better at multi-threading, it does not have a global interpreter lock. In an age when multi-core machines are the future, easy parallel processing is an important advantage.
- I think the productivity gain of dynamic languages is overrated. Partly, because static type checking catches problems beforehand. Additionally, modern IDEs like Eclipse help with producing Java code rapidly (e.g. there is very good completion, functionality for code refactoring, etc.).

I have to add that I write a lot of Python code as well. It has its place, and is a good language. But it is not a magic substitute for Java, especially on larger or computationally-intensive projects (of course, you can write modules in C/C++).

Fortunately Jython, JRuby, Groovy, Scala, et al. have the potential to keep us all happy ;) .

Reply Score: 4

RE[3]: Progress?
by samad on Mon 16th Jun 2008 23:34 UTC in reply to "RE[2]: Progress?"
samad Member since:
2006-03-31

I agree almost entirely with your assessment, except in one aspect:

The problem with Jython is it cannot use native Python modules. This is important when using modules like rpy that controls R through Python. (R is an awful language compared to Python, and programming in Python but having the range of statistical packages in R is a powerful combination.)

Java is fast becoming a common language in scientific computing. Python simply does not have comparable execution time to Java, and one is forced to write critical aspects of a program as a Python C module to get decent performance.

Reply Score: 2

RE[3]: Progress?
by rsvihla21 on Tue 17th Jun 2008 03:16 UTC in reply to "RE[2]: Progress?"
rsvihla21 Member since:
2008-06-17

- I think the productivity gain of dynamic languages is overrated. Partly, because static type checking catches problems beforehand. Additionally, modern IDEs like Eclipse help with producing Java code rapidly (e.g. there is very good completion, functionality for code refactoring, etc.).

I honestly think greater emphasis on Unit testing makes your counter point not apply. Now if you're not a TDD/BDD'er then that's fine and dandy and you're point is accurate but the XP crowd has been moving from Java to dynamic languages as a result of the fact their code is already heavily tested as it's written and not as dependant on the compiler saving them (see Bob Martin, Bruce Tate, Martin Fowler as just three notable examples of lifelong Static camp thought leaders to move to the Dynamic camp).

Edited 2008-06-17 03:17 UTC

Reply Score: 1

RE[3]: Progress?
by Clinton on Tue 17th Jun 2008 05:19 UTC in reply to "RE[2]: Progress?"
Clinton Member since:
2005-07-05

I agree with some of your points, but I think your idea of "most programming" and mine are different. For every big program I write, where speed may be an issue, I probably write 50 little ones.

There is no need to waste a bunch of time writing a string parsing app in Java (whose mechanism for handling files and IO totally sucks in its verbosity) when you can write it far more quickly in Python, and the performance difference is going to be nigh unto imperceptible in these cases.

"- Java has a very extensive class library, and many high-quality frameworks are available."

Python has the same.

"- Java is better at multi-threading, it does not have a global interpreter lock. In an age when multi-core machines are the future, easy parallel processing is an important advantage."

I don't think you understand what the global interpreter lock does. Python has threads and they are wrappers around true OS level system threads, so threaded Python apps run on multi-core machines just fine. The GIL just prevents Python code from running in those threads concurrently.

"- I think the productivity gain of dynamic languages is overrated. Partly, because static type checking catches problems beforehand. Additionally, modern IDEs like Eclipse help with producing Java code rapidly (e.g. there is very good completion, functionality for code refactoring, etc.)"

I think static type checking is overrated. I also think the reason Eclipse has to give you help in producing Java code rapidly is because Java code is so overly wordy. It truly does suck in this regard.

"I have to add that I write a lot of Python code as well. It has its place, and is a good language. But it is not a magic substitute for Java, especially on larger or computationally-intensive projects (of course, you can write modules in C/C++)."

That's the point though. How many times when we write code is it on large computationally-intensive projects? For me, it is about 1 to 50, so Python wins almost all the time for me.

"Fortunately Jython, JRuby, Groovy, Scala, et al. have the potential to keep us all happy ;) ."

I personally think the reason most of these things exist (especially Groovy) is because of all of Java's flaws.

I agree that Java has its place over Python in some instances, but in my experience, I find the other way around is more common. Programming languages are like tools and it is always best to use the right tool for the Job.

Edited 2008-06-17 05:22 UTC

Reply Score: 3

RE[3]: Progress?
by Clinton on Tue 17th Jun 2008 06:37 UTC in reply to "RE[2]: Progress?"
Clinton Member since:
2005-07-05

@danieldk

I forgot one point I wanted to make regarding your threading comment...

Most of the common uses of threading in real-world applications do not improve overall performance of an application anyway, no matter how many cores your machine has. The benefits of multicore desktop machines come from multitasking and not from single applications that use threads.

Reply Score: 2

RE[4]: Progress?
by anarxia on Tue 17th Jun 2008 10:27 UTC in reply to "RE[3]: Progress?"
anarxia Member since:
2006-06-02

desktop != server. On the server side multiple threads/processes improve performance (requests per second) even for single-core machines if you have more than one user.

Reply Score: 1

RE[5]: Progress?
by Clinton on Wed 18th Jun 2008 00:19 UTC in reply to "RE[4]: Progress?"
Clinton Member since:
2005-07-05

That depends on the program. In my experience, most real-world programs don't use threads effectively for performance (actually, most real-world programs don't use threads at all).

But, since both Python and Java support threads, I don't know why we're arguing over it.

Reply Score: 2

Flash?
by memson on Mon 16th Jun 2008 01:21 UTC
memson
Member since:
2006-01-01

Flex maybe, but Flash... no. This is a direct analogue with what Flex does really.

Reply Score: 3

Doesn't work too well in Opera 9.5
by Kabal on Mon 16th Jun 2008 04:26 UTC
Kabal
Member since:
2005-07-09

Their photo app demo was a mess.

Reply Score: 6

Just looked at the code
by werfu on Mon 16th Jun 2008 05:42 UTC
werfu
Member since:
2005-09-15

This look like rails.... same extension, similar syntax. Looks like another MVC framework, just boosted on Javascript side. IMHO this could not be bad if code is all written in JS, even on server side, especially if code can be shared between the client-side and the server-side. All it needs is a fully featured, sane OOP implementation.

Just waiting for JS2.0 to happen. Javascript will get promoted to a fully, sane development language. Everytime I use JS, I still get the same old 1995 feeling of hacking my way out. Like if using JS would be bad. At that time it was. Nowadays I guess it should be more ok to do so, but still.

I'm simply dreaming of JS2.0 to be available massively on browser. Sharing code between server and client will become useful. Like, sharing classes definitions between the two sides and sending serialized objects instead of simple values. Getting a full OOP web programming scheme will do miracle. (Did somebody told web 3.0?)

Reply Score: 1

RE: Just looked at the code
by PlatformAgnostic on Mon 16th Jun 2008 07:05 UTC in reply to "Just looked at the code"
PlatformAgnostic Member since:
2006-01-02

One advantage of being forced to do both sides of your application in different environments is that it makes it extremely clear in the code what is client and what is server. If people can send you serialized objects and you deserialize them everywhere and anywhere in your code, it opens up the floodgates for vulnerable handling of the data. It happens today anyway, but at least there's some sort of airgap when the server and the client are forcibly separated codebases.

Reply Score: 3

Not for serious development
by tomcat on Mon 16th Jun 2008 07:39 UTC
tomcat
Member since:
2006-01-06

Seriously... there's a reason why Flash (and to a lesser extent Silverlight) has come to dominate rich Web content: It's provides a highly-integrated dev environment, it provides excellent performance/features, and it plays video. Until a combination of JavaScript/HTML/CSS has those attributes, it's not going to replace anything. No, the battle for rich Web clients will be fought between Flash and Silverlight. Silverlight has done surprisingly well -- probably because it has HD video playback. Should be an interesting battle to watch unfold.

Reply Score: 2

RE: Not for serious development
by adricnet on Tue 17th Jun 2008 06:27 UTC in reply to "Not for serious development"
adricnet Member since:
2005-07-01

HTML 5 was supposed to have video in it, but the video ... market (?) is so ... complicated ... that that part of the standard was blocked hard (by Nokia as I recall).

Hard to get that sentence together with going on a tearing rant or three. Sorry for the elipses.

Reply Score: 2

extJS
by andrewg on Tue 17th Jun 2008 00:42 UTC
andrewg
Member since:
2005-07-06

Please have a look at extJS (www.extjs.com). Its more professional and polished. If you want to build a web app then you won't find anything matching extJS even if it their documentation does not entice you with words like "Rails" and "Cocoa".

Reply Score: 2

RE: extJS
by rain on Tue 17th Jun 2008 11:02 UTC in reply to "extJS"
rain Member since:
2005-07-09

Yeah, ExtJS is actually quite amazing. I've been working with it pretty much every day for the past five months and I'm constantly surprised at how mature and well built it is for being such a young framework (it started out with a good foundation though). It doesn't feel like a hack like many of the competitors.

Edited 2008-06-17 11:03 UTC

Reply Score: 1

Sproutcore Tutorial?
by adricnet on Tue 17th Jun 2008 06:34 UTC
adricnet
Member since:
2005-07-01

The Sproutcore site has some great tutorials that show off the framework.

I really must disagree. The tutorials and sample code and apps are a bit .. anemic (?). The framework does seem to have some new tricks, and you will see some of them working through the tutorial, but it's .. early.
I had some frustrating moments working through the tutorial where typos or misunderstanding led to a completely unhelpful controller error message.

Perhaps a 1.0 release will have more compelling examples and documentation? Sproutcore shows promise, but there are a lot of frameworks already... going to need more wow. Oh and make it work with drag and drop in XCode (but surely this has been mostly completed).

Reply Score: 1

Listener
by sanctus on Wed 18th Jun 2008 02:44 UTC
sanctus
Member since:
2005-08-31

I don't have much experiences with ajax toolkit. Just play arount with dojo and scriptaculous.

But I found the idea of listener(observer) very interesting. I don't know if it's because I didn't look deep enough inside other framework, but the logic seems to be quite more natural. Just add a listener, and your object is fully dynamic, in the opposite of explicitly writing script that target other dom element.

At first, it looks like it require less code and less hassle.

Reply Score: 2