by Aaron

Time for JavaScript.NEXT

OK, I’ll admit that HTML 5, when it becomes a true standard and the common browsers implement it and all of CSS 3 that we won’t need as many browser plug-ins for doing rich interactive applications anymore. We could ditch Microsoft’s Silverlight and Adobe’s Flash and not look back.

But, to do that, we need to move the web to a better programming language!

Reading this rant from MG Siegler on Tech Crunch made me want to come clean about my true feelings.

As Google Backs Away From A Plug-in, Microsoft Rushes Towards One

I don’t want to need Flash or Silverlight.

But, I’ll take either of them over programming a large scale web application using JavaScript – since both of them have a modern programming language (ActionScript 3 and C#). Seriously. JavaScript, born in 1995. It’s 14 freaking years old as of this December (as it was first released in December 1995). We’ve got budding programmers who were born AFTER it was created. JavaScript, unlike many of it’s commonly used, similarly aged counterparts, has not had any significant upgrades or improvements to reflect new market needs. Java and C++ both have (Java got generics for example), and C# was born in the last decade. I like Silverlight more than Flash only because of the programming language (and IDE) attached with its development.

Here’s my short list of complaints about JavaScript:

  • Dynamic typing – great, I can’t know until runtime what a type should be, and even then it could change. Makes for a great time.
  • Prototype – oh don’t get me started on the patterns that are necessary to create a robust object oriented framework in JavaScript – and “this”, and “oops, you’re missing a comma, good luck finding that!”
  • Closures – the source of too many memory leaks and confusion over the years, especially given the subtly of its behavior in JavaScript
  • No official “imports” or “usings” to make doing code-completion practical, and one JavaScript file can’t declare another JavaScript file as a dependency and have it automatically be loaded (just once of course), without creating a new framework.
  • Run-time code discovery – it’s great to be able to load things dynamically, but it’s completely a mess at design time trying to sort everything out and make sense of a large application.
  • Debugging – terrible IDE and debugging support across the browsers. Too many “alert” style debugging workflows in this day and age.
  • Interpreted – still making the browser do extra work and a bonus feature: you don’t know about coding errors until you try to execute the code!
  • Poor internationalization support – to do it right, you need to build functions or get a library to parse and format properly

(Don’t get me started about the inconsistency of DOM access from JavaScript across browsers – which I realize isn’t JavaScript – it’s a browser thing – but they’re intertwined from all practical purposes).

(And, I’m not complaining about a web application that consists of 2 JavaScript files, where one of them is JQuery. Think big. Applications. Complex workflows. Frameworks. Etc. It’s tough stuff. It’s doable, but unnecessarily difficult).

Major Web applications would have taken off long ago if the entire development experience/environment would have modeled after something like Visual Basic 3, 4, 5,  or 6. Web applications are still held back by an awful development experience.

Do you love JavaScript? Does it need to be upgraded to this century?

Updated to reflect a bit of ranting inconsistency.

by Aaron

Finally, someone admits that Silverlight and WPF will (likely) converge

However, will Silverlight and WPF merge?

From Pete Brown:

The Future of Client App Dev : WPF and Silverlight Convergence

As a Microsoft employee (Developer Community Program Manager for Windows Client), he said:

What the Future Holds – Convergence of WPF and Silverlight

 

I recently spoke with Ian Ellison-Taylor at Microsoft. Ian is a General Manager at Microsoft, reporting directly to Scott Guthrie. Among other things, his group handles both Silverlight and WPF (and RIA services and a lot of other stuff). I figured if I wanted the skinny on the future, he’d be the guy to talk to. So, he and I talked about the convergence of Silverlight and WPF, and later exchanged some email on the topic.

 

In the future, it is very likely that both Silverlight and WPF will be a single technology with a single codebase. After all, Silverlight was originally known as WPF/E (E as in Everywhere), and in an amazing 180 degree reversal of our usual approach, we took an ugly codename and created a great product name (Silverlight) from it.

D’uh. Like it wasn’t obvious, especially with the explosive growth and capabilities of Silverlight, why wouldn’t this be on the road map?

Of course, there’s no time frame mentioned, so don’t plan on your Silverlight application being able to use real 3D and actual DataTriggers any time soon.

by Aaron

Catalogs, oh my!

One day’s worth of catalogs:

pile of catalogs

I like shopping on the Internet, but there’s something to slowly paging through a paper catalog that is so much more satisfying than any Internet e-commerce site I’ve ever used. I’ll look through catalogs that hardly interest me if the catalog looks fun and interesting.

I’m not sure what it is about physical paper catalogs that appeals to me – if it’s the tactile touch, the presentation, the simplicity, …?

by Aaron

Impressive Silverlight game engine? Or something else entirely….?

A game in Silverlight – since I can’t read Chinese, I’m not sure what it’s all about, but it looks decent, and doesn’t seem to spike my CPU when playing.

I don’t understand the point of the demo/game that’s there and it seems to be impossibly difficult (as you can see from the screen shot).

Try it here:

http://silverfuture.cn/

image

Found via Silverlike.

As best as I can determine, here are the functions of the various features along the bottom:

image

Update: The comments have a better explanation of what the various items along the bottom do in the “game.”

by Aaron

Are web developers “stupid and arrogant”?

Michael suggests…

It’s easy to look at the world today and say that web applications have won. This is web developer arrogance. Stupidity is to think that web applications have won because web applications are superior to desktop applications. Smarter, but probably still arrogant developers would point to web applications as disruptive technologies. This involves admitting that web applications are inferior, but good enough, and present enough other "cheaper" advantages to compensate for their inferiority.

To understand why the "web apps have won" claim is dubious. There are definitely a lot of awesome web applications out there. Many of them were created back in the mid/late 90’s, The "features" of these applications were the key to applications, not the user interface. Now these days, most of these web applications offer APIs/web services/RESTful interfaces/whatever you want to call them. In many cases it is possible to build desktop applications that tap into the same features as these web applications. However, this was certainly not the case 10-15 years ago.

If a vendor could make installing and updating applications as seamless as web application models, I believe they’d have a goldmine on their hands.

Ease of deployment is what makes web applications rock. It’s not their functionality, or rounded buttons, or big text boxes, or gradients.

You don’t need to write a web application like the often praised 37 Signals’ applications (such as Basecamp) to have a well received application. It’s not because it’s a web application. It’s because they put in the features and functionality that customers need. If they’d written the same in a desktop application, and it was as simple to deploy and use, I’d argue they’d be just as successful.