Fog Creek Software
Discussion Board




Web - Single Rendering/Executing Vendor

I don't think we can get these great web applications with more than one vendor rendering and executing the GUI.

I have worked in Web Development for the last 2 and a half years. I've read Zeldman's book on Web Standards, I've built my personal site in XHTML Trasitional and CSS. I've programmed in Coldfusion and I'm learning Java. The next technology I'd like to learn after Java/JSP is Macromedia's Flash.

I've seen, used, and written quite a few web applications. And here is what I've learned:

When you have a specification instead of a product, obviously it is with the intention of having multiple groups implement it. The problem with multiple implementations of a specification that is based around what people see is that if one vendor is off by a couple of pixels, or the behavior of the client is slightly different, you have just destroyed the user experience.

In my experience as both a user and a developer is that JavaScript is twitchy and doesn't reliably work the same in all browsers. Not to mention, what happens when the user starts seeing GUI elements on the screen and tries to start working, but the .js file hasn't finished downloading! With JavaScript, you're literally leaving it up to all the different browser makers to perform the behavior of your application. And that scares me.

If all the vendors implemented the spec exactly the same way, then maybe we'd be able to use a future form of HTML/CSS/JavaScript for developing web applications with rich GUIs. The reality of the situation is, Microsoft rules the web browser and the corporate desktop. Every vendor that comes into my place of work and pitches their software say the same thing, “We only support IE. You can try it in other browsers, but it's not supported.” Translation, “The product will probably work like crap in anything other than IE.” So if Microsoft doesn't implement the new “standards”, they'll be about as popular as XUL.

Not to mention, when you develop a "rich" GUI for a web app, do you really want to spend time tracking down all the different bugs across all the different platforms? Anyone who's done a lot of CSS work will tell you how much time you can waste making everything look the same in all the browsers. It can be accomplished, but think of how much more work you could have gotten done if the client you are aiming for was just one renderer.

When you are talking about a standard web site, one that delivers primarily text content (articles, blogs, product information, etc..) You can get away with not everything being being pixel perfect across all browsers. Heck as long as everything is readable and doesn't look bad in all the browsers, you're golden. I just don't believe the same is true for web applications. I want all the people using my app to see the same thing! And I want it to behave exactly the same in all environments!

I believe you need to go one level above web browsers, and into the domain of a single vendor's product that runs on all major platforms.

-Flash
-Java Applets

(Does anyone know of any other technology that can give you a rich interface that installs in all major platforms?)

Don't confuse the crap you've seen done with these technologies and the quality of these technologies.

With Flash and Java Applets, you can write your code once, and test it inside of 1 environment. You won't spend all your time opening all the different browsers (Opera 6&7, Netscape 6.0, 6.1, 7+, IE 5.0, 5.5, 6+, Mozilla , Safari 1.0, 1.2) watching how they look and act, fixing bugs, seeing how they "degrade" to the older versions, etc.... You'll write to your platform version and that's that.

Both of those platforms (Flash / Java Applets) already have most of the "rich" functionality that a web application should have.

Developing a desktop app in native code for one OS is easier than for multiple OSs. It costs less, and you don't have to stretch your support across multiple platforms. With web development of “rich GUI apps” you can be an ass and only support 1 browser or you can increase your QA and support costs by supporting multiple browsers.

OR

You can develop for one environment, get a ton of “rich”-ness, and have your application work on all the major platforms!

The web browser is a delivery medium for text. We need to stop trying to bend HTML and the joke that is JavaScript to do what we want and start developing applications in technologies that are built for it.

(I should go apply for the Macromedia cheerleader squad.)

Does this answer the Amazon.com question? No. Amazon shouldn't re-write their site with a rich GUI. It's a catalog that remembers what I was last look at and then tries to remind me to buy it, not a web application.

Does this answer the web application question? Yes. Think about how amazing Gmail would be in Flash. All that stupid Frames/JavaScript crap they are doing right would be 10x smoother and less buggy in Flash.

Start taking advantage of the tools we have available now. If you don't, one day Hotmail will launch with some nifty XAML front end and everyone wil be scrambling to figure out how to catch up with Microsoft.

michael sica (michaelsica.com)
Saturday, June 19, 2004

"if one vendor is off by a couple of pixels, or the behavior of the client is slightly different, you have just destroyed the user experience"

We're looking into implementing at least parts of our system with a rich client environment, maybe Flash.

But that said, there are not many applications where a "user experience" is important; for the vast majority of web sites I prefer simple, clean, and fast as possible.

And really, how many users are so sensitive that a couple of pixels will destroy their experience? I think you are taking your artwork a bit too seriously.

Tom H
Saturday, June 19, 2004

Some comments:

"I don't think we can get these great web applications with more than one vendor rendering and executing the GUI."

...

"When you have a specification instead of a product, obviously it is with the intention of having multiple groups implement it. The problem with multiple implementations of a specification that is based around what people see is that if one vendor is off by a couple of pixels, or the behavior of the client is slightly different, you have just destroyed the user experience."

Like the Windows API? And besides, if one vendor is "off" that means they didn't implement the specification correctly. You are going to run into that wherever you go. Take for example some previous posts on JoS which mentioned the finnagling major companies did with the Windows API. They didn't implement the specification, and so their product didn't work. Microsoft knew they would be the ones that would be blamed and so worked around it, but that's beside the point.

"In my experience as both a user and a developer is that JavaScript is twitchy and doesn't reliably work the same in all browsers."

Granted, I have stayed away from heavy CSS scripting the past 7 years I've been doing web development, but very rarely have I had major issues with Javascript. Except Opera which didn't quite implement JS correctly when it first came out. But, most of the work I did had to degrade gracefully and not rely on users having JS enabled, so it was a different approach.

"Every vendor that comes into my place of work and pitches their software say the same thing, “We only support IE. You can try it in other browsers, but it's not supported.” Translation, “The product will probably work like crap in anything other than IE.”"

Actually, the translation should be, "We were too lazy to try to stick to standards and wanted to rely on Windows-specific features, so we didn't bother trying to make it cross-browser compatible." Or, "My boss doesn't get why we would want this to be cross-browser, so our deadlines only allowed us to build for IE. Sorry."

If it doesn't work in anything other than IE, and isn't for Intranet use, more often then not someone is being lazy. A notable exception is accessing printing features from the browsers - before IE 5.5's time there wasn't a pretty way to access print features, except through very browser specifc calls.

"So if Microsoft doesn't implement the new “standards”, they'll be about as popular as XUL."

I'm sure developers would love to bicker with you about the popularity of XUL. But, the biggest issue I see is getting people to upgrade. Even if Microsoft implemented new standards, who is going to upgrade to it? Granted, they could push it out through Windows Update, but the number of PCs being sold doesn't outnumber PC Owners anymore, so it would be a hard sell. You still are going to have to do browser checking like you do today.

"I want all the people using my app to see the same thing! And I want it to behave exactly the same in all environments!"

Then write a friggin desktop app. Let it use TCP/IP as a transport mechanism to get the information you need.  But I'm sure you want to only have to write the application once, right?

"With Flash and Java Applets, you can write your code once, and test it inside of 1 environment."

Yep. And sorry to say, that is a false statement. Ever worked with Microsoft's Java implementation? PoS.  Or wanted Flash to interact with the browser in a meaningful way (hint: it uses Javascript too)?

"We need to stop trying to bend HTML and the joke that is JavaScript to do what we want and start developing applications in technologies that are built for it."

"If you don't, one day Hotmail will launch with some nifty XAML front end and everyone wil be scrambling to figure out how to catch up with Microsoft."

The technologies I have seen built for it are not the ones that are embedded in a browser. Maybe Java, but it isn't the most fun thing to work on in multiple-OS environments.  It's been things like Qt and wxWidgets using various languages as its backend.

Flash maybe has promise, as it was one of the client-side technologies I used to do XML DOM parsing and rendering and it did a good job. But even then, the conversation boils down to one thing. If you want cross-platform Rich-client GUI apps, don't plan on using your browser. But, that means that it will be much more difficult to rely on every one having whatever they need to run your app. Which doesn't seem that much different then where we are today.

CF
Saturday, June 19, 2004

Hi guys, you made some good points, but I'd like to say a few things!

Tom H:
"And really, how many users are so sensitive that a couple of pixels will destroy their experience? I think you are taking your artwork a bit too seriously."

-I use a web application at work called Unicenter. It's built by CA and is only supported in IE. It works in Mozilla, but the spacing of everything is off (so it looks crappy), and the JavaScript doesn't work exactly the same between browsers. IE is a lot smoother, when I use Mozilla I end up retrying to do things because whatever events they are using just don't translate over to Mozilla in the same manner. Is this the fault of the development team who didn't "stick to standards"? Well, I don't know. Maybe IE did things in a way they wanted to use, or maybe they just don't know what they are doing.

-But it doesn't matter because its built for the most dominant browser. And for the vast majority of the development teams out, that is the only thing they seem to care about.

-If the front end of the application was written in Flash, we wouldn't even be having this conversation. Because it would look and act the same in all the browsers I run it in.

CF:
"Like the Windows API? And besides, if one vendor is "off" that means they didn't implement the specification correctly."

-Exactly. The vendors won't ever all be on the same page. And as long as MS has the lock they do on IE, it won't ever change. Too many companies are building IE only apps, and the business units that need them don't care. (they don't know the difference.)

-If an app is built in Flash, then it wouldn't matter which browser was being used, because its running in the 1 environment.

"Yep. And sorry to say, that is a false statement. Ever worked with Microsoft's Java implementation? PoS."

-No, and that's a good point.

"Or wanted Flash to interact with the browser in a meaningful way (hint: it uses Javascript too)?""

-But Flash doesn't have to use JavaScript with the browser. It uses its own internal ECMA Script engine called Action Script. You don't need to interact with the browser at all. (Except for maybe to print or something.)

"Flash maybe has promise, as it was one of the client-side technologies I used to do XML DOM parsing and rendering and it did a good job. But even then, the conversation boils down to one thing. If you want cross-platform Rich-client GUI apps, don't plan on using your browser. But, that means that it will be much more difficult to rely on every one having whatever they need to run your app. Which doesn't seem that much different then where we are today."

-I agree. But I can see everyone on the planet having Flash installed before I can see everyone on the planet having IE, mozilla, Windows, Linux, etc... installed.

......And of course you would be locked into Macromedia as your sole Flash vendor.... Blah Blah... ;)

michael sica (michaelsica.com)
Saturday, June 19, 2004

By the way, I encourage everyone to go read what Flash is now capable of.

http://www.macromedia.com/devnet/ria/

And no, you need to use "Flex" to get a RIA. From what I can tell you can do everything from a GUI perspective that with Flash than you can with Flex. Flex actually compiles into a flash file. (.swf)

michael sica (michaelsica.com)
Saturday, June 19, 2004

Hi Michael,

"But Flash doesn't have to use JavaScript with the browser. It uses its own internal ECMA Script engine called Action Script. You don't need to interact with the browser at all. (Except for maybe to print or something.)"

I was thinking more along the lines of being able to interact with elements outside of the movie. For that, the only way I knew it could interact (without Flash Remoting) was through Javascript or posting requests. I've worked a lot with Actionscript at it is very powerful.

By the way, excellent link about Flex - I will have to spend some time playing with that.

CF
Saturday, June 19, 2004

The solution is very simple in my humble opinion. Just assign the stylesheets dynamicly and have one for IE/win, one for IE/Mac and one for Mozilla and the rest for Win and Mac. Thats four variations and it adds about two hours of work if you plan ahead. Its basicly the only sane way of getting good font rendering on both platforms anyway.

Also, IE5.5/mac is usually the browser to cause the most trouble with JS and CSS so we cant really trust MS to set standards.

Eric Debois
Saturday, June 19, 2004

Typo!

"And no, you need to use "Flex" to get a RIA. "

Should have been,

"And no, you DON'T need to use "Flex" to get a RIA."

michael sica (michaelsica.com)
Sunday, June 20, 2004

*  Recent Topics

*  Fog Creek Home