Blogger's Block #3: Dreaming in Browser Swamp

I see what you did there with the Amazon referral links

...Also Blogger's CAPTCHA is b0rked with cookies disabled, shouldn't you be fixing it?!
Wait, what are you doing from under your desk? Shouldn't you be under your desk, hiding from our comments while being your core-dump-debugging programmer self?!?

Hi Steve,

If you're getting into rails and haven't checked out rjs templates yet, DO IT! There is a 60 page pdf available from oreilly--$10--that gives a great intro to them. RJS templates are a way to define javascript functionality in ruby, then have it converted to javascript.

Uhm. Nice... i think.

Yeah. Sort of.

Hopefully you are not reading this so i can be completely honest here.

Windows Rocks. Microsoft Rocks.

Tarja won't rock anymore since she is not at Nightwish anymore.

Good Luck !!

"Everyone in the world" — that's an awful lot of money at stake.
So as soon as "Scheme on Skis"....

Money in GUI toolkits, thats really what you are talking about, right? I suppose QT from Trolltech makes some money, but even MS doesn't make money selling the actual GUI toolkits. Sounds too tough and I think thats why there aren't many serious exclusive web toolkit companies.

So hence my obvious question, where is the google browser? (opensource/free obviously)
It would make gmail and gcalendar etc have all kinds of special nifty feature so everybody would be forced to download it.
Obviously, it would have Ruby instead of Javascript built-in.

Anyway, great post, thanks, back to core-dumping for me, wake me up when Google Browser is ready....

Wow, I never realized Javascript could be used to get a list of the user's bookmarks. Shouldn't we consider this a huuuuuge security hole?

Norvig on Quick Learning

While your observations are mostly accurate, your conclusions make me cringe. What I hear is "go pick up this 'AJAX' thingy skill this weekend and add it to your laundry list on your resume." That's depressing and unhelpful.

While it's true that many (or most) web developers learned JavaScript as part of an evolutionary process, starting with 1995 HTML and progressing painfully from there, that doesn't mean that there isn't a body of good code and coders to be found in the language. It just means that 95% of the coders who claim "JavaScript skill" wouldn't know good JS if it verbed on their face.

Teaching responsible JavaScript practices and sane web development architecture is thus exceedingly difficult. It's difficult because everyone trivializes it as "that thingy you should add to your resume after reading about it for a weekend."

More education should be in order and red flags should be raised around the slew of JavaScript creations with good intentions but deleterious results.

Stevey, you're spot on with the point about high energy vs low energy states. We need to lower the energy required to build stable, crossplatform and interactive applications for the web, otherwise we'll continue to only see small quantum leaps of improvement such as GMail or Google Maps - which, despite their UI niftyness, any of us decently-advanced JS developers, given the map data, could have slapped together over a boring weekend.

You're also spot on about the general reluctance towards learning new languages and environments - I loved the genericability (is that even a word?) of RubyOnRails but I hated the fact that it was based on Ruby. We need Javascript on Jets, and we need it bad - I don't even care if it'll get yet another detergent name.

"Well, if you happen to be doing web programming, Ruby on Rails defies classical language mechanics by actually being a lower energy state. That's right; it's more lazy to learn Rails than it is to try to get your web framework to be that productive, so people are just tunneling over to it like so many electrons."

Sort of. This is true for the simple cases, but much less so when you want to do something out the ordinary, or when something is not beavin quite as it should.

Then it's like pulling teeth to get help to good examples. Even Dave Thomas' Rails book, good as it is, only covers the trivial situations.

It's a nice utopian dream, but I don't see how it will ever happen. Not without massive platform refactoring. The explosion of the web in the 90s pretty much guaranteed cancerous growth; the web was never intended for serious interface design. Hell, it wasn't even intended for serious graphic design. All these piecemeal technologies have gone a long way to improving the situation, but getting there was like pulling teeth.

As much economic incentive as their is, the cost and barrier to entry of a better platform is insurmountable. It would have to come from a Microsoft or a Google, and even then it would be limited by their own interests.

The best we can hope for is incremental improvements and cleaner layers. Javascript toolkits like Prototype and Dojo, and server-side frameworks like Ruby on Rails are fantastic. However, there are still basic issues like complete CSS support that are holding us back in a lot of ways. Heck, even CSS has a lot of flaws due to the fact that it was spec'ed out without a complete understanding of what people might want to accomplish (vertical centering? two floated divs in lockstep height? width 100% including padding and margins? etc). All I can say is things are a lot easier then they were 7-8 years ago, and that's an achievement considering the increase in complexity.

Ole, arbitrary JavaScript on a web page can't fetch a list of your bookmarks. But internally, the user interface of Mozilla-based apps is written in XUL, CSS, JavaScript, XBL and a few other components; that code is not sandboxed the way JavaScript in a web page is sandboxed, and with good reason. Extensions for Mozilla-based apps are usually written the same way, and also have much deeper access than JavaScript running on the web.

Here's hoping you read this Stevey. You've written a good article, but I think you've misunderstood something.

You describe needing to create several files in order to create an extension. This is true, but remember that most of that stuff is analogous to an installer, not the program itself. It's like saying you have to learn how InstallShield works in order to write a Hello World app in C. A XUL hello world application is as simple as this:

data:application/vnd.mozilla.xul+xml,<?xml version="1.0"?><window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"><label value="Hello World"/></window>

(Granted you'll have to write that mime type down somewhere, and the namespace is a bit unwieldy as well, but I blame all that on XML.)

Everything else adds features, and they're probably features that you want. Separating the js out into it's own file lets you write a lot of js without cluttering up your UI definition. Putting the xul into a file instead of a data url lets you edit it sanely. install.rdf and jar.mn let you install it as an extension. Having a dtd and/or a properties file lets you translate your extension into other languages with ease (think gettext).

The jar.mn file is an interesting case, because it's gradually evolved from a straight list of files, one per line, into a bit of a monster. It could easily be replaced with some js or something that gets compiled into a jar.mn at build time. The problem with that is that almost nobody has a js interpreter handy at build time, since it's wrapped up inside the browser. It could be done with Perl, or a shell script though, since those are pretty much always available.

On the other hand, install.rdf is a new improvement to the install process. It used to be the case that the installer for an extension was written in javascript (the install.js file), but this proved to be a problem because it meant that Firefox could never reliably uninstall an extension. As a result they moved to the rdf file because that limits what the extension author can do to just those things that Firefox can undo automatically.

On a different note, you can now use Python in place of JavaScript, if you've installed the relevant Firefox extension. I don't know that Python will ever be available in the default install though, because it seems that Mozilla.org cannot redistribute the Python runtime.

Well, this comment ended up being quite a bit longer than I had intended. I hope someone read it all :)

> Well, if you can find any halfway decent tools and libraries for it, that is. Which you can't, not without effort. But the situation is improving.
I would say the the situation is good right now - a lot of libraries(good ones) are available. Prototye, Dojo, YUI, jQuery, Mochikit etc are good examples. As for the 'tools' category, that is a problem. I would place my bet of Firefox with Firebug extension and Apatna.

> It would only take one or two really killer apps for Mozilla to take back the market share from Microsoft.
Firefox has a lot of 'killer apps'. But they are extensions - not websites.

Good write up - Thanks.

bluefacedpixie: Sure, I understand that. However, you can strip it down even further if you want. Just do

data:text/plain,Hello World!

if that's all you want. Just as with Python, it all depends on how much control over the UI you want. Is a console application good enough? If so, then the print function is an adequate start. If you need a GUI application, you'll have to do something more complicated. In Firefox, that means using XUL and Javascript, but it doesn't mean that you need any of the half-dozen other kinds of files you will commonly see in a Firefox extension. Those are only needed to package the result as an extension.

Anyway, to put that XUL code in a blogger comment I had to escape the angle brackets:

&lt;label value="Hello World!"&gt;

becomes:

<label value="Hello World!">

I mean, it's a LOT better than it was in 1997. Look at Google Spreadsheets or Writely or GMail or Google Maps (anyone notice a pattern here?) — would any of these really have been possible in 1997?

Yes, all of these would have been possible in 1997, but they would only have run on IE.

If your interested in the relationship between sleep and creativity, I thought I'd pass on one my favorite books:

The Act of Creation

All sorts of unexpected insights in there. (Not that you're reading this anyway)

Hi Steve,

I come here to read what you have to say, and rarely ever give my opinion. I can live without a lot of the responses in general, but you do occasionally get good ones.

What is the intention of not reading the comments? To shield you from the negative ones, right? It's kinda cool to hear favourable responses now and then. But, it's the neutral ones that are most valuable - the ones that give you a new direction to think in, or add to your horizons with a new technology, book, URL, anime, etc.

So... how do you filter the oxygen bandits from your blog comments? A Plan for Blog Comments, perhaps? And you could have a whitelist - I'm sure there's a few Stevey Fanboys (apologies for using an F-word) out there to head a whitelist. I for one am a fan... er, like your posts, however I don't usually have anything worth saying. ("usually?" they gasp).

Surely with your new-found web hacking skills, you could whack together some code that sifted through your blog's comments and filtered out the crappy ones. You don't need to view them through the same interface we do. Write another script that injects your responses to chosen comments.

Then, we know you're not reading the bad stuff - you never comment on it, and we can all ignore it or flame each other pink over it - but what do you care? They'll get filtered too.

The point is, your blood-pressure doesn't spike, and you live longer to share more with us - both original works and responses to the more erudite comments.

People might object to the suggestion of adding the filter to the actual web interface to the comments; especially those contributing the filtered ones. Perhaps individuals get to see a union of their own comments and the filtered set. That nobody comments on their tripe will be because nobody else can see it. They can tell themselves that it left everyone speechless, if it makes them feel any better.

Ok, it isn't going to be perfect. All filters miss something some of the time, and it'll need training... but we're not talking high risk traffic here - you miss someone's suggestion to start learning BLYB 'cos it's the kool3st thing since... You'll hear about it soon enough if it's worth hearing.

Or, perhaps you could just hire a secretary instead. Or as well.

Just a ramble. And thank goodness you haven't got this mechanism in place yet, or only I would see my contribution. :-)

All the XML, rdf stuff in javascript, XUL are all FireFox-specific.

In terms of simplification I guess you can take it to two-levels:

1. For the javascript needed for the ajax stuff like you see in google map, etc. It's bad but not that bad. There is some pretty useful stuff like prototype, behavior, etc that make you more productive.

2. For a even richer experience that really integrates to the browser (essentially creating browser extensions), then the nightmare for XUL, rdf, manifest... will be true!

after all that time spent boning up on DHTML etc, I guess you'll be pleased to hear that your blog doesn't render in IE6 correctly :)

What's IE6?

to: db48x

I like your second comment better - point noted! that is as concise, the only difference being it's slightly less intuitive for all us old-folks who harken back to the days of BASIC PRINT statements.

(and thanks for the markup :)

Shouldn't there be a "getBookmarks()" in there somewhere? I mean, what is all that crap?

Late to the show but good ol' Brendan linked you all up.


After decrying the long list of special purpose, proprietary calls you need to make to 'get bookmarks' why would you think a special purpose, propritary call to getBookmarks is any better? You're proposing that ECMA script become like Ruby and PHP, which are definately helping to muddy the waters. Try doing anything other than what the language designers already intended in either of those, and you end up.. no way! .. stringing together a long chain of calls that don't really do what you want in order to cull side effects into an operation you desire.

One of the reasons JavaScript is limping at the head of the pack is because they left it just primitive enough for you to do very very difficult (read HARD, not obscure) things with about as much code as very easy things.

The more Mozilla can unify XUL with that methodology, the closer they'll be to a full platform that can also rapidly develop apps.

I think it's fair to say now that Ajax-y toolkits are starting to mature: YUI, GWT, even Atlas. All big guns on the table... Then there are Dojo, Mochikit, and others. All of these give you freedom (to a degree) from browser idiosyncracies.

Then there is OpenLaszlo - a different approach and more like RoR but for the client-side: Use XML for declarative objects and Javascript for functional programming and compile it into the target you want (Flash at the moment, DHTML very soon, maybe one day SVG, .NET, who knows).

Keep your eye on those...



There there is

judge.mentok.the.mindtaker said...

After decrying the long list of special purpose, proprietary calls you need to make to 'get bookmarks' why would you think a special purpose, propritary call to getBookmarks is any better?


Surely you're not defending that filth? Even if you have a problem with a special purpose function, there is no escuse for that complexity. Make the easy task simple and the hard task possible. Getting a list of bookmarks shouldn't require hours of googling obscure and obtuse interfaces.

Steve! I don't understand what you mean about how all the scripting languages screwed up lexical scoping. But I do want to understand. How should they have done it?