Tuesday, September 19, 2006

Blogger's Block #3: Dreaming in Browser Swamp

Part 3 of an N-part series of short (well, fast, anyway) posts intended to clear out my bloggestive tract.

I've been doing a lot of JavaScript and DHTML and AJAX programming lately. Increasing quantities of it. Boy howdy. The O'Reilly DHTML book has gotten big enough to crush a Volkswagon Bug, hasn't it? And my CSS book has gone from pristine to war-torn in under a month. I've managed to stay in the Dark Ages of web programming for the past 10 years: you know, HTML, a little CGI, font color="red". Way old school. And now I'm getting the crash-course. The more I learn, the more I wish I'd known it for longer. Although then I'd have had to live through the long transition from Dark Ages to the muchly-improved situation we have today. Far from good, to be sure, but it's improved dramatically since last I looked.

JavaScript is probably the most important language in the world today. Funny, huh? You'd think it would be Java or C++ or something. But I think it just might be JavaScript.

For one thing, despite JavaScript's inevitable quirks and flaws and warts and hairy boogers and severe body odor, it possesses that magical property that you can get stuff done really fast with it. 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. Slow and steady wins the race and all. JavaScript is definitely the tortoise to Java's hare.

See, JavaScript has a captive audience. It's one of those languages you just have to know, or you get to miss out on Web programming, and in case you hadn't noticed, thick clients are like Big Hair these days. Most non-technical people I know pretty much live in their browsers, and they only emerge periodically to stare in puzzlement at iTunes or a game or something, and wonder why isn't it in the browser, because everything else useful seems to be. It's where the whole world is. To non-technical people, of course. Which is, like, practically everyone.

We technical folks like to eye browsers with suspicion, and for a good reason. They're not platforms. They're sort of like platforms, but they're missing all this stuff you normally expect from platforms. The DHTML book (which covers pretty much the only semi-reliable intersection of the browser platforms) is, for all its massive size, still just one book, and any platform worth its salt will need a whole shelf.

It turns out if you dig deep into Mozilla (aka Netscape, aka Firefox, aka SeaMonkey, aka SwampMonster, I mean the thing really has way too many farging names already), you'll find that it actually is a relatively full-featured platform. It's not quite as general-purpose as an OS (or Java), but it's certainly big and hairy enough to be making threats in that general direction.

But my God, it's sooooooo ugly. It's got well over a decade of ugly packed in there. "Hello, World" in Mozilla is six or seven files in as many different languages. I kid you not. It's worse than Hello, World was back in the Petzold days of Win32 programming. You have your XUL file and your JavaScript file and your CSS file and your manifest.rdf and your i18n.something and I can't remember what all else. And then you have to build them together (using some other files) to make even more files: a JAR file and an XPI file at a minimum. That's one gnarly-ass introductory program.

Me, I kinda prefer Python's version:
print "Hello, world!"
Color me silly with font="red", but it just seems cleaner to me.

And then when you try to graduate from Hello, World to something that seems like it should be only epsilon more difficult, like, say, "Get me a list of the user's bookmarks", you officially launch off into this eerie XPCOM world where you have to write dozens and dozens of lines of JavaScript code that looks nothing at all like you'd imagine it should, if you closed your eyes and thought to yourself: "I wonder what the JS code for getting bookmarks would look like?"

Look, I'll even show ya:
/**
* Returns a sorted list of bookmark objects. Each object
* has properties name, url, and (optional) kw.
* @return bookmark list: an array of anonymous objects, each
* with "name", "url" and "kw" fields. Sorts the list by name
* if sort is true.
*/

function getBookmarkList(doSort) {
var rdf = Components.classes["@mozilla.org/rdf/rdf-service;1"].
getService(Components.interfaces.nsIRDFService);

var bmks = rdf.GetDataSource("rdf:bookmarks");
var NC_NS = "http://home.netscape.com/NC-rdf#";
var kwArc = rdf.GetResource(NC_NS + "ShortcutURL");
var urlArc = rdf.GetResource(NC_NS + "URL");
var nameArc = rdf.GetResource(NC_NS + "Name");
var rdfLiteral = Components.interfaces.nsIRDFLiteral;
var e = bmks.GetAllResources();
var items = [];

while(e.hasMoreElements()) {
var r = e.getNext().QueryInterface(
Components.interfaces.nsIRDFResource);
var urlR = bmks.GetTarget(r, urlArc, true);
var kwR = bmks.GetTarget(r, kwArc, true);
var nameR = bmks.GetTarget(r, nameArc, true);
if (!(nameR && urlR)) {
continue;
}
var item = {};
item.name = nameR.QueryInterface(rdfLiteral).Value;
item.url = urlR.QueryInterface(rdfLiteral).Value;
if (kwR) {
item.kw = kwR.QueryInterface(rdfLiteral).Value;
}
items.push(item);
}

if (doSort) {
items.sort(function(a, b) {
return (a.name.upcase() < b.name.upcase()) ? -1 : 1;
});
}
return items;
}

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

Admittedly this function does a little extra, what with the sorting, but that's only 5 lines of code, because JavaScript came with verbs included, thank you so much Brendan. And those 5 lines are actually fairly sane; I mean, you can read them and say "hey, that's sorting!" But as the rest of the code, what we seem to have is a serious failure to separate infrastructure from business logic. We're trying to take the patient's temperature here, and they're making us saw the poor guy open and grub around in his intestines looking for the right spot to stick the thermometer. So to speak.

In any case, that's not really JavaScript's fault; it's Firefox's fault. I have trouble keeping them separate in my head sometimes, because I, unlike the rest of the Free World, have the balls not to support Internet Explorer. For my personal stuff, anyway. (Or so I believe at the moment. Time will tell.)

That's what's really holding JavaScript back, you know. And it's holding back CSS, and DOM, and all the other standards. We have this little impasse problem. You know the song and dance: Microsoft didn't want Netscape to be a competing platform, so they built IE and gave it away for free, and for a brief while they even had a better product, so they captured enough market share.

And then... nothing. Oh, sure, they've made a few half-assed attempts to make IE standards-compliant, sort of, but only after making many full-assed attempts to distort those standards to give Microsoft competitive advantages. I've heard that directly from folks working on the relevant teams over there. Microsoft cheerfully shows up at the standards meetings to make damn sure they screw up the APIs for everyone else. You know. Microsoft-style. Sorta like how DirectX was bugly compared to OpenGL. Or Win32 compared to *nix. Or MFC compared to any sane object system (e.g. TurboPascal and TurboC). Or COM compared to CORBA. (I mean, you have to work hard to be worse than CORBA.) Microsoft has always been awful at making APIs, always always always, and I've decided over the years to credit this to malice rather than incompetence. Microsoft isn't incompetent, whatever else they might be. Burdened, yes; incompetent, no.

Why am I talking about them side-by-side with JavaScript? Because the standoff between Microsoft and the Forces of Neutrality (open standards and the like) is the main thing that's holding JavaScript back. Nobody wants to build an amazingly cool website that only works in FireFox/Opera/(insert your favorite reasonably standards-compliant browser here). Because they're focused on the short term, not the long term. It would only take one or two really killer apps for Mozilla to take back the market share from Microsoft. That, or a whole army of pretty good ones. People don't like downloading new stuff (in general), and they also don't like switching browsers. But they'll do it if they know they have to in order to use their favorite app.

Everyone knows all this; not a jot of it is news to anyone, but nobody wants to be the one to make a clean break from IE. It might bankrupt them. Great app, nobody sees it, company goes bust. So the killer apps will have to come from the fringe, the margin, the anarchy projects engineers do on the side — at least at companies where engineers have a little free time for innovation. Excepting only go-for-broke startups, most places can't (or won't) bet the farm on a Firefox-only application. So even though the spec is moving forward, or maybe sideways, DHTML in the real world has been in near-stasis for years.

In any event, the whole MSIE standoff isn't the only thing holding JavaScript back. There are definitely other contributors.

One big problem is that it's JavaScript. Nobody wants to use JavaScript.

I'm serious. It's not that it's a bad language (it's not); it's just not the language they want to use. You know. Them. You. Everyone who has a favorite programming language. Most people only want to use one, their favorite, whatever they're best with, and when they switch to a different one, they're slower. They feel stifled, held back, uncomfortable. That feeling goes away in under a month of immersion in a new language, but most engineers begrudge that time fiercely, probably because they don't realize it's only a month.

So many folks who take a stab at browser programming wind up saying "oh GOSH, why can't I use BLUB, man this really SUCKS!" and then instead of writing their killer web app, they go off and write some lame-ass toolkit that compiles their language into JavaScript, or tries to be a Firefox plugin, or tries to be a Frankensteinian compiled-together monstrosity like Apache and mod_perl was.

The funny thing is, they wouldn't be gaining a damn thing with a new language, except maybe libraries, but even that's somewhat doubtful. The standard library and runtime for any respectable general-purpose programming language are pretty big: definitely too big to expect everyone in the world to download. And that's the problem. You'd have to get everyone to do it. Might as well work on your own browser at that point. Oh, you can bet a bunch of people run off to do that, too, utterly overlooking the fact that nobody will use it even if it's great (like Opera), because it's not the browser they're accustomed to, and it has no killer app.

But if they wrote a killer app... oh, but that would have to be in JavaScript... well, maybe we can come up with a way to write it in XYZ instead! That's right — a bunch of would-be web app programmers are stuck in a vicious circle trying to break into a market that has one of the weirdest monopolies in history: IE (and to a tiny extent, Firefox and Safari: the Dr. Pepper and RC Cola of browsers, respectively) maintains its monopolistic lock not through overt control, but through apathy on the part of users worldwide.

And that apathy extends to the browser makers themselves. Microsoft and Apple have no reason to try to make their browsers competing platforms; quite the opposite in fact. So almost no innovation happens in IE and Safari, compared to the innovation (in Apple's case) or purchase and/or me-tooing of other innovations (in Microsoft's) going on outside the browser groups at those companies.

OK, but what about Firefox? Why don't they, you know, innovate? Well, they're trying, I think, but for what I'm guessing are probably tangled historical reasons — which manifest as the developers often being gridlocked politically — Mozilla lacks what Fred Brooks Jr. calls "conceptual integrity" in his classic "The Mythical Man-Month". [Which, incidentally, remains today the most vitally relevant book on software engineering, over 30 years after it was written.] The Mozilla folks would have to do a lot of serious re-thinking in order to reduce XUL's "Hello, World" down to a few lines of code in a single language. And I'm not convinced that kind of thinking is happening in the Firefox camp right now. It's not that they're not thinking at all; don't get me wrong. They're just not thinking about radical, revolutionary user-level simplifications to the basic framework.

Like, the kind of radical simplification Ruby on Rails introduced for server-side web programming. Yeah, yeah, I know, you hate Ruby because it's not the language you learned at your mother's teat, for God's sake. Despite Ruby's near-perfect Conceptual Integrity Index, you'd sooner quit your job and become a sanitation engineer than spend a day or three just learning the language and being done with it. But whatever your feelings on Ruby, Rails has caused a huge stir, because it took something that everyone assumed had to be ugly now and for all time, and it built layers and scaffolding on top that smoothed over a tremendous amount of that ugliness. Made it almost purty, even.

Rails — now that's the kind of simplification I'm talking about. Screw all the XML minilanguages (XUL, XBL, X*L). Screw the RDF. You need to be able to do everything in JavaScript. JSON is just good enough and parseable enough and language-interoperable enough to replace all of them. For that matter, screw CSS. I don't mean the CSS spec, not the relatively elegant constraint system they have in place; I just mean the CSS syntax, since it's one more language piled onto the heap. The whole selector minilanguage is nifty, but does it really need to be different from XPath? I mean, aren't they both doing path expressions to select things in the DOM? Jeez!

Am I spouting heresy or common sense here? It depends who you're asking. There are a lot of "web developers" in the world. Lots and lots. And they, my friends, are the last thing holding JavaScript back.

Because nobody wants to be a web developer. No self-respecting, rootin'-tootin', core-dump-debugging programmer wants to be one, anyway. That's sissy stuff. That's what most non-web programmers think, whether they use Java or C++ or C# or Perl or Python or Haskell or what-have-you. There's a deep-seated cultural perception problem in our industry about this, and I think it has a lot of root causes.

One cause, and let's be honest here, is that a lot of web developers were self-taught, weaned from text to HTML to onclick="foo.hide()" and onwards to CSS and DOM and more complex JavaScript, and thence on to CGI and PHP and VB and ActiveX and SVG and Flash and the rest of the gigantic mess of barely-interoperable languages we have to work with for web programming, not one of which covers the whole spectrum the way C++ or Java does. You have to mix and match them (always poorly) in order to achieve some effect that usually would have been trivial using a thick-client framework.

So we really have two reasons at play here: one is that web developers mostly taught themselves, which means they're generally not very good at what "real" programmers of course consider "real" programming, so diving into web programming hasn't been considered very glamorous, nor a very good career move. The other is that the field is so littered with new, ugly languages and technologies (again, not one of which is a turn-key solution) that most folks who do try it wind up fleeing.

I mean, I'm all in favor of MVC, but I think Common Sense and its kissing-cousin Conceptual Integrity will both tell you that M, V and C don't need to be three separate languages. And the manifest and build information needn't be a fourth and fifth, respectively. And i18n a sixth. And the XPCOM system services an effective seventh. And the server-side languages Nth through Zth. It just doesn't make any sense.

Which is in no small part why you keep hearing about Ruby on Rails, even though you really just wish it would go away so you don't have to learn it. Rails has the laws of physics (or at least economics) on its side. Rails is like one of those bizarre tunnel diodes, where the electrons on one side of the barrier tunnel to the other side without traveling the distance in between (at least in the classical-mechanics sense of "traveling"). They just sort of appear on the other side, instantaneously, because being on the other side is a lower quantum energy state, and tough shit if you don't like it.

People want Rails to go away because it has Ruby in the name: you can't use it like a library, nooooo, it has to be in some other language, and other languages are bad by axiomatic decree. Programmers are lazy: they've found that the greedy algorithm gets them there with the least energy expenditure most of the time, and switching languages requires much more energy than integrating a new library, no matter how godawfully complex and ultimately useless the library is. Which is why the Java community is thrashing around with like 50 competing frameworks for server side web programming. Oh, and the Python community too. And, um, all of the rest of them too.

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.

This phenomenon will happen in the browser space. I can assure you it will. It's an economic certainty. There's money at play here, lots and LOTS of money; every company in the world wants a cool website. Not just a cool website; they want cool apps. Companies are realizing — glacially, yes, belatedly, yes, but inexorably — that most people with computer access in the world today live inside their browser, and they'd prefer not to leave it.

"Everyone in the world" — that's an awful lot of money at stake.

So as soon as "Scheme on Skis" or "JavaScript on Jets" or whatever comes along, that Rails-like radical simplification of the huge ugly Browser Swamp, the game will change almost overnight.

I'm not sure exactly how it'll pan out. Rails is basically a big code generator, a big compiler, in a sense. The "language" is Rails itself — there's precious little actual Ruby in a Rails app, surprisingly enough, although there's tons underneath — and the target platform is the Browser Swamp. It's not a seamless abstraction; you still need to know CSS and HTML (at least), and you need to know a fair bit about HTTP and relational databases and web servers and all that crapola you need for "Hello, World" on the web.

But maybe that was the right choice. Maybe if DHH had defined an entire DSL for web programming in pure Ruby, with all the DHTML auto-generated, it wouldn't have been as popular. In the long run, I think the pure-Ruby approach (or pure-anything, as long as it's a single language that supports declarative programming, which rules Java out) is economically superior, because there's less to learn, and more purchase for optimizations, error-checking and the like. But in the short term, meaning today, the hybrid approach seems to be doing well.

The alternative to a Rails-like multi-language hybrid is to do the whole ball of wax in a single language. Lisp and Scheme folks have, of course, warmed to this idea, and they all write macros that generate HTML, which winds up being way cleaner than you might guess. But not many frameworks have taken the approach of generating all the JavaScript. The GWT is one, of course, but you'd have to be a pretty doggurn die-hard Java programmer to go that way. I'm sure it'll improve with time, but the biggest stumbling block, amusingly enough, is that it's not JavaScript. JavaScript is still King in the browser space, and ironically it's like programming to the "bare metal" compared to using a Java-to-JavaScript compiler. So JavaScript what the "real" web programmers prefer to use.

And we've come full circle.

Isn't this great? Me, I'm loving it. Yeah, it's a crap sandwich and we all have to take a bite. But it's also a greenfield opportunity, a land rush, a high-energy state just dying to become a low-energy state. Who's going to solve it? What will the solution look like?

One option I haven't really discussed is the incumbent: maybe the standards committees will eventually evolve cross-browser support into a platform that doesn't drive most programmers into I'll-write-my-own-dammit frenzies. 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? Heck, I doubt it: they're barely possible today. But they make it pretty obvious which way thick clients are headed, don't they?

Hang on — you're not still a thick-client programmer, are you? Oh dear. You'd better get yourself a DHTML book and an AJAX book, and right-quick. Oh, you're above that client stuff, you're a server-side programmer then, are you? Bully for you! I don't blame you. I hid there for many years myself; server-side is a haven of sanity, isn't it? But I think you'll find that adding web programming to your skills lineup will go a long way; you'll be able to wire up those nifty backends you're writing in ways that real-live people will appreciate. Like, say, your family. And real employers too. They like the web. There's money there. So DHTML/AJAX a great Mixin skill; it complements just about anything else you know how to do.

Anyway, I've pretty much belched out the barest outlines of my browser-ish thoughts for today: just enough for a blog entry, so I'll wrap up.

Ooooh, and it's a Blogger's Block entry! This Blogger's Block series has been great for the ol' creative juices. Just write about whatever you want, no worries, and it all flows nicely.

The only thing that could possibly go wrong is me reading the comments.

What?

I had a realization last night as I was juuuust falling asleep. The realization I had was that I have all my realizations just as I'm falling asleep. Or just as I'm waking up. There's something magical about that time, and I think I know what it is.

I think you (or at least "I", but I think maybe "we") are highly creative when we're nearly asleep because all the pressure's off. You can't go to sleep if you're under a lot of pressure — not easily, at any rate. Nobody can follow us into our dreams, so we go there alone, and when you're alone with yourself, you can be yourself. We've put shields in place to prevent us from saying or doing stupid things in public, and those shields come down when we're asleep.

That's why you always have those amazing dreams that you want to write down in the morning, the ones that would make a great movie screenplay or spy-thriller novel. Your mind is in a creative frenzy, and you mostly suppress it during the day.

Well, you can't say stuff in a public blog without getting some criticism, which is why most employees at most companies (that's you, an all likelihood) are reticent to try it. There's not much to be gained, and a lot of potential downside. People have been fired over their blogs, for instance, although those are relatively rare cases, and the blogger in question is almost invariably a jackass. For most bloggers it's more subtle. If you're speaking in a public forum and sufficient people appear to be listening, then it's hard not to be perceived as a spokesperson (of sorts) for the company. Scoble's the canonical example, but you can easily find others who fit the profile.

If your company has an ad-hoc, out-of-band, quasi-pseudo-spokesperson on the loose, the person is a risk. Sort of. I mean, it's lose-lose. If the person is cheerleading, well, nobody likes a fanboy. (It's a truly ugly word, isn't it? "Fanboy" is the new F-word.) If it's badmouthing, well, that's not too cool either. But hey, one person's fawning is another person's badmouthing, right? There are two sides to any interesting opinion (otherwise it's not going to be very interesting), so anything a blogger says in public is going to be criticized by some percentage of the readers. So no matter what, the company the blogger works for is taking some indirect heat, and it's risky to hope that the positive side of the blog, if any, will make up for it.

Well then. That's why bloggers like me always have to give you the following disclaimer: I don't speak for Google. Not even a little bit. For the reasons I've outlined above, the best I can really hope for is that they choose to look the other way when I blog. It's the best any blogger can hope for. It's what I'm hoping for.

I'm a frigging Google fanboy, though; that's going to be really hard to hide, so I'll just be honest with you. F-word, I hate that F-word. But it fits in this case. I'll try my best to be objective. Google's a terrible place to be when you're on a diet, for instance.

In any case, my sleepy realization has effectively solved my Blogger's Block problem. I couldn't write because I was too worried about what other people (i.e., you) would think. Yeah, I care about you too much. You! I think that gradually piled on resistance, and it was getting harder and harder for me to write past it. You can see it pretty clearly in the "Clothes for the Soul" post, which I don't care all that much about — it was just a thought-exercise, after all, and was supposed to be fun. But then I got all defensive at the end, which made commenters all defensive, and I made a mess, all because I was trying so hard to avoid criticism.

So the solution is simple: I won't read the comments.

ZZZZZzzzzzzzooooooooompf — and just like that, in a flash, I'm alone with my thoughts. Amazing. Really. I can feel a chill; it's like I didn't know I was in a haunted house until all the ghosts left, all at once.

La la la, La la la, I can say whatever I want, and I needn't know 'til I'm dead what anyone else thought of it. Nobody mentions my blog at work, by and large, since it's awkward to do so. (I assume this is the case for all bloggers — we don't have any cultural conventions for it, so it's like the third time you pass someone in the hall and you both carefully avoid eye contact.) So if I don't read the comments, then I really am alone with my thoughts.

That's how I was able to write some of my more interesting things back at Amazon; initially nobody read my blog, so I was writing for an audience of at most about 5 people, and then only if I pestered them to read it, which I almost never did.

So no reading comments. My blogs may not be any better for it, but I'm sure I'll be much happier. Oh, you can bet I'll be tempted. Maybe I won't be able to resist. Must... *pant* ... resiiiiist... augh! But I think I'll be able to hold out. Why? Because for this entire entry I've felt like I'm just about to fall asleep. Well, that's because I was; it's been a long day, and I didn't start until 1am, and it's 4:30am now. So yeah. Sleeeep.

But it's a nice feeling. Much nicer than the Russian Roulette of reading the comments on my blogs. "Uh-huh, uh-huh, yep, *BANG* aaaaah!" <blood pressure shoots up to 190/150>. High blood pressure is a recipe for some pretty questionable blogging, I think, and it's not too good for your health, either.

So! Tell me what you th... er, tell others what you think! I'll be hiding under my desk, hoping the monsters go away.

And learn DHTML! You won't like it, but you'll be glad all the same.

'night.




p.s. some light reading:

30 Comments:

Blogger Charles said...

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?!?

6:14 AM, September 19, 2006  
Blogger codeturkey said...

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.

6:49 AM, September 19, 2006  
Blogger Chris said...

> a viscious circle

Wow. Angry and slippery

8:24 AM, September 19, 2006  
Blogger Brendan said...

Good. He's not reading the comments anymore. Now we can talk about him behind his back.

Ah, crap. I'm a Stevey fanboy, so I got no snark to bring here. I'm just glad he found a laxative. Seeing three new Stevey posts in my RSS thingy was a treat.

8:24 AM, September 19, 2006  
Blogger fad said...

->

8:27 AM, September 19, 2006  
Blogger Alejandro said...

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 !!

8:53 AM, September 19, 2006  
Blogger Ville said...


"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....

9:54 AM, September 19, 2006  
Blogger Ole Begemann said...

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?

9:59 AM, September 19, 2006  
Blogger bfults said...

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.

10:15 AM, September 19, 2006  
Blogger Thor said...

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.

10:26 AM, September 19, 2006  
Blogger Tristan said...

"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.

10:27 AM, September 19, 2006  
Blogger dasil003 said...

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.

12:34 PM, September 19, 2006  
Blogger James said...

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.

1:48 PM, September 19, 2006  
Blogger db48x said...

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 :)

3:16 PM, September 19, 2006  
Blogger timshawn said...

Have a quick question about languauges. Steve here says to learn Ajax and JS. Right now I'm confused as hell because I want to learn too many languages at once. I bought a bunch of books for Ruby (pickAxe, cookbook) and Rails, (recipes, agile)
I'm reading SICP for Scheme, (I came from a Java/C/C++ school, UW-madison) and I also have Dive in Python on loan from my company library. I also downloaded a bunch of those intro ot Lisp books.
I think all of these languages are interesting, I have cursory knowledge in all of them... (Ruby probably being most familiar with, since I'm using at work for data munging).. what do you think is the "preferred order" of learning and getting more in-depth with them if I don't really need one or the other for work? I"m doing this in my spare time...
I guess if you were to design a curriculum of learning programming languages, how would the order go?
(target student knows static languages very well, and Perl)
Help!
Thanks!

4:42 PM, September 19, 2006  
Blogger Binny V A said...

> 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.

8:50 PM, September 19, 2006  
Blogger bluefacedpixie said...

db48x: I think the point was - it's not

print "Hello World!"

(how did you get blogger comments to take code anyhow?)

8:51 PM, September 19, 2006  
Blogger db48x said...

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!">

12:21 AM, September 20, 2006  
Blogger Damien said...

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.

1:44 AM, September 20, 2006  
Blogger jazzfeigling said...

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)

1:53 AM, September 20, 2006  
Blogger Barry said...

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. :-)

1:23 AM, September 22, 2006  
Blogger Wai-Kwong Sam said...

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!

1:56 PM, September 22, 2006  
Blogger Damien said...

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 :)

11:57 AM, September 27, 2006  
Blogger Barry said...

What's IE6?

1:18 AM, September 29, 2006  
Blogger Gordon said...

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 :)

11:51 PM, October 07, 2006  
Blogger judge.mentok.the.mindtaker said...

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.

2:20 PM, November 28, 2006  
Blogger Jeff said...

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

11:20 AM, December 01, 2006  
Blogger ToLazyToThink said...

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.

1:47 AM, December 05, 2006  
Blogger Tim said...

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?

2:41 AM, January 20, 2007  
Blogger GistOut said...

"Rails is like one of those bizarre tunnel diodes,..."
Nice analogy!
Cited in Programming Analogies & Metaphors.

5:57 PM, November 22, 2007  

<< Home