John Resig announced some very good news about the future of JavaScript yesterday.  The technical team at ECMA - TC39 - responsible for writing the spec for the next version of JavaScript (called variously ES4 or ES3.1) had effectively split in two, hindering any real progress towards producing a real spec.  The result was that the group finally decided to jettison some of the ideas both camps had adopted and coalesce around a more evolutionary approach to JavaScript.

Despite whatever conflict might have caused this, the outcome is undoubtedly good for JavaScript developers everywhere.  The ES3.1 spec add minor sugar while completely neglecting some of the glaring issues with the language.  The ES4 spec, meanwhile, mutilated the language to the point of making it unrecognizable.  ES4 would have both led to the removal of some of JavaScript’s most useful features while simultaneously telling the world to ignore JavaScript for another 5 years while the standard body in charge of it decided what they wanted it to become.

So thanks TC39, you’ve made a wise choice.  Let’s hope your new middle path can fix the language without leaving its most powerful features behind.

Update: Douglas Crockford weighs in as well. 

Tags: Opinion by charles
2 Comments »

Yet another use for Flash is headed for the dust bin…Firefox 3.1 will provide native support for <audio> and <video> tags, just like WebKit.  It will still be years before these browsers have broad enough distribution to completely eliminate the need for plugins to handle audio and video, but the writing is on the wall…

Tags: Opinion by charles
No Comments »

John Resign announced today that he and a few others will be taking over the Firebug project for Mozilla.  This is hugely important as the folks working on Firefox appeared to actively break Firebug with every beta release. 

It’s pretty clear that as software running in the browser becomes more complicated, the developer tools supported by each browser will become one of the most important features of that browser (at least to developers).  The browser vendors that don’t get that are going to really harm their position in the marketplace.

Way to go John.  We’re cheering you on!

Tags: Opinion by charles
No Comments »

If you are building a client-side application in the web browser, what should happen when you turn the programming language off?  This is the issue raised by Steve Webster today.

A lot of people argue that the web is about accessibility and therefore a well designed, standards-compliant web page should practice progressive enhancement.  That is, if JavaScript is shut off, people should still be able to access the page.

I totally agree with this statement.  It is particularly true if you are a company like Yahoo, writing an ad-supported content-driven website where reaching the broadest audience possible is of the utmost importance.  Where is the business value is setting a high bar of entry for readers?

This is not the case however for thick-client web applications like SproutCore apps.  In this case, your users come to your site to use a fast, right, desktop-class application.  JavaScript is the key enabling technology behind the very features your users want to use.  Asking them to turn it on in their web browser only makes sense.

That said, there are a lot of progressive techniques that do still make sense.  Smoothly degrading your CSS for example is an obvious choice.  Also expensive things like animations that make the experience less pleasurable on slower browsers would be obvious places to cut back.  If you do use Flash (maybe for audio or video playback) that’s another good place to avoid requirements; asking users to enable an option built in to their web browser is way different from asking them to download and install a plugin.

If you want to support users with no JavaScript as well, build a reduced functionality site using traditional page-driven models that you can redirect your users to via a <noscript> and <meta> tag in your SproutCore app.

If you’re building a content site like the NY Times or Yahoo’s front page, make sure your page works even with JavaScript turned off.  It’s the best way to bring in the broadest audience.  If you are building a web app however, requiring JavaScript to be turned on so you can deliver a fast, fluid experience on the web will attract more customers because it will set you apart from the competition.

Tags: Opinion by charles
3 Comments »

From Standard Pixel:

Indeed we are becoming more and more aware that there are two different categories of web project, Web Apps and Web Sites. Web Apps are a lot like a desktop client. Users expect to have a single interface and be able to get to everything they need in few clicks. Web Sites, on the other hand are more like a news paper and people expect to enter through a front page of some kind and explore in to get more detailed information on a subject. For me, I have settled on creating one Web App project with a Ruby on Rails back-end mixed with a client written in SproutCore. Another project however, is a simple information site which will use PHP, along with a little interface help from YUI. - SproutCore is a chainsaw and YUI is a paring knife.

Could not agree more.  We decided a long time ago that there is a big difference between building a thick-client JavaScript app vs a web site with some JavaScript enhancements.  Thick-clients require a whole new level of complexity that web sites don’t have.  Use the right tool for the job.

Tags: Opinion by charles
2 Comments »

Everyone always asks: “What is the difference between SproutCore and GWT?”.  If you don’t know, GWT is the Ajax library developed by Google.  You write Java code, which is translated into JavaScript for you to run in the browser.  

I could go into lots of details about the specific strengths or weaknesses of this or that feature, but the big difference between GWT and SproutCore can be summed up with this quote from their from page:

Google Web Toolkit (GWT) makes it easier to write high-performance AJAX applications. You write your front end in the Java programming language and GWT compiles your source into highly optimized JavaScript. Writing web apps today is a tedious and error-prone process. You spend 90% of your time working around browser quirks, and JavaScript’s lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile. It doesn’t have to be that way.

In other words: we don’t like JavaScript.  It’s not Java and it’s hard.  Use GWT instead and avoid learning that language altogether!

SproutCore’s approach, as you probably know by now, is quite the opposite.  Embrace JavaScript.  It’s a good language once you get to know it.  The tedious and error-prone part of it is not the fault of JavaScript, its the natural state of the web browsers and their relatively primitive APIs.  But that’s what a framework is for.

Here’s the problem with using something like GWT or any other framework or tool that lets you write in <insert favorite language here> and then converts it to JavaScript:  they can’t always get it right.  

Every framework, even SproutCore, makes some assumptions about the kinds of problems you will need to solve or how your code will need to perform.  When you run up against these limits (and you always will) in a platform that tries to isolate you from JavaScript what do you do?  Well you have to write the JavaScript yourself.  Only now the problem is twice as hard because you have to figure out how to interface with that super-optimized, totally unreadable code generated by your tool as well.

With SproutCore, if you want to do something not anticipated by the framework, well, write a little more JavaScript.  It will be easy to interface with the rest of your app because that is what SproutCore does. Better yet, use one of the many libraries already out there to help you.  It feels totally natural and normal to do this because you get to stay in the same platform where you belong.

The point is, any framework that tries to help you avoid learning JavaScript, be it GWT, ruby helpers, or anything else, is fine when you have some relatively simple things to do.  But if you want to build apps that really shine in the browser, you need to go native.  Use the technologies that the browser is made of and you’ll be far happier in the long run.

And that’s the difference between SproutCore and GWT.

Update: I have great respect for the GWT team and what they have built.  It’s an amazing feat of technology and very useful for any Java engineer who needs to add a little Ajax love without learning JavaScript.  But for the kinds of apps SproutCore is designed for, we differ on the approach.  The purpose of this post is to explain that difference.

Tags: Opinion by charles
23 Comments »

This guy gets it:

This is why projects like Sproutcore have me excited. Never mind the whole “Cocoa on the web angle” that a lot of people are talking up when describing it. It’s exciting because it is promoting a “back-end neutral” philosophy and emphasizing that people who ignore Javascript are turning their backs on a lot of good functionality. - New Trends in Front Ends

Tags: Opinion by charles
1 Comment »

Fred Brunel points out this quote from Joel Splosky late last year:

So if history repeats itself, we can expect some standardization of Ajax user interfaces to happen in the same way we got Microsoft Windows. Somebody is going to write a compelling SDK that you can use to make powerful Ajax applications with common user interface elements that work together. And whichever SDK wins the most developer mindshare will have the same kind of competitive stronghold as Microsoft had with their Windows API.

I remember reading Joel’s original post last year and agreeing very strongly with it.  I even drafted a nice long post but never had the time to polish it up.  I have no idea what SproutCore’s future will be, but I’m pretty convinced that a full cross-platform desktop-class JavaScript Framework is inevitable for the web, and Joel explains why better than I could.

Tags: Opinion by charles
No Comments »

It’s tempting to claim desktop frameworks since they come with 20 years of experience built in.  But 20 years of experience also means 20 years of baggage. When Apple created the UIKit (AppKit for the iPhone), even they didn’t clone Cocoa exactly:

One of the biggest differences is the extensive use of properties throughout the UIKit class declarations. Properties were introduced to Mac OS X in version 10.5 and thus came along after the creation of many classes in the AppKit framework. Rather than simply mimic the same getter and setter methods in AppKit, UIKit employs properties as a way to simplify the class interfaces. For information about properties, see Properties in The Objective-C 2.0 Programming Language.

From iPhone Getting Started Docs

Tags: Opinion by charles
No Comments »