Web frameworks

I hate them all.

Well, actually, no I don't, but I think the whole web programming thing is a bit of an abberhation. The idea of sending the entire screen from a client to a server and then picking bits out of the content to drive your processing and then delivering the entire screen back to the client is a model that started disappearing in the 1980s. The web brought it all back again, and it's a problem, because it was never designed for building applications; it was designed for delivering documents.

A model where the GUI lives and executes on the client and makes strongly-typed (probably XML) requests to the server for processing, but not GUI generation is a better model in my opinion (although of course the GUI code can be delivered over the web). All of a sudden, there's a bunch of stuff in this area - Adobe's Flash (been doing it for years, but help back by people's poor experience of daft animations); Microsoft's recently announced Silverlight and also Sun's recently announced JavaFX. If implemented well, these things for me hold the promise of bringing web application programming back into the land of the living and make it as easy as thick client programming, with the added bonus that everything is faster and slicker, but doesn't need to be programmed in some ropey scripting language that varies across platforms. Of course, standardisation is an issue, but then, it always is.

You do get lots of advantages from having the code server-side though -- you can update it v. easily, with 0 user intervention being the first to come to mind. The alternative is a generic app on the client that takes its instructions initially from the server -- and isn't that basically what a browser is becoming anyway?

There are certain apps for which a thick client is ideal -- mail clients, newsreaders, iTunes store -- but these are exceptions to the rule for web stuff. Things like Silverlight and AIR seem much more like a barely-concealed bid to regain control of the browser than a new way forward.

But it's this "for web stuff" that's the issue; the web's only different because of the current constraints in programming it. If the progrmaming model were richer, then things like Office style programs would happily run everywhere, instead of being ropey, poor alternatives to the real thing, like Google's word processor, which as far as I can tell, is nothing more than a glorified rich text box. This isn't because Google are rubbish at making word processors; it's because the programming model makes it difficult to do much better (at least in a reasonable timeframe). a colleague of mine recently remarked that he thought Flickr was amazing and it made me think how, despite knowing what he was on about, if Flickr was a desktop application, it would have looked like a shit one over ten years ago.

What the motives of the various companies are, I have little interest in, because it's always the same, it's all about making money; that's because they are companies in a capitalist society. That there's a use for a richer client model, combined with the client-server model for centrally processed logic and data, I can see.

The alternative is a generic app on the client that takes its instructions initially from the server

Yeah that is what I mean, but I'm not sure I see a browser becoming this. I guess my problem is that the way web programming is now, is pretty much by default, rather than by design, and I'd rather it was kind of rebuilt to include the programming lessons that were learnt in the 1980s (you can have a very rich client by harnessing the client's processing power; you can write more maintainable programs by using OO rather than procedural code etc.)

Oo xposted.

Aye, but I fear the browser now has so much traction that launching a competing client system is going to be a Difficult Thing.

I agree...

But I hope someone gives it a shot. When I was a kid, we were going to be going to Mars and the best anyone's managed since then was orbit. I still hope people go to Mars. It's depressing that reality moves much more slowly than you hope.

Oh, and I guess I don't know that it has to be "competing"; in that, it could be embedded in it, as most of these things are, though I think the best model would respect the simplistic and easily understood back/forward etc. hyperlink-style model that the WWW currently works with.

Also, I think the article you post is fairly poor, as it doesn't suggest any alternative. Another way of viewing what this person's written is to say that all the companies are thinking the same way ("couldn't we deliver richer apps over the internet?") as opposed to what he suggests, which is "they're all doing it for their own gain". I mean, no shit you fucking hippy! Big companies do stuff for their own gain!!! Is anyone surprised?!?!

Alternatively, no-one ever makes the web better than the semi-static way it is right now. Maybe some Robin Hood programmer will invent something amazing that will take off that advances the game, but for now, my money's somewhere between Sun, MS, IBM, Adobe and Oracle (and a bunch of other companies).

SYMFONY

Also, I think the article you post is fairly poor, as it doesn't suggest any alternative.
Yeh, I think his unspoken alternative is HTML5 and other standards stuff that might finally get the browser moving forward again instead of its current lurching stop-go

It seems quite tricky to get much (readable) info on HTML 5... The examples I see seem to use client side interpreted Javascript to program what appears to be a much richer set of client APIs. The APIs themselves look OK; well, what little I've looked at them, but still programming in dynamically typed (there's another discussion!), interpreted Javascript embedded inside pages, or at best "#include"-ed into pages? Just feels like the dark ages (again).

When I had a look at PHP when I started to look at rewriting ILX, because someone had suggested we should write it in PHP, I bought a book on the subject, and one of the (many) things I felt I just couldn't bear was going back to this kind of:

#ifndef X

#include file.c

#define X

#endif

to cope with the fact that you wanted a tree of includes. "import"-style mechanisms are far simpler, and this sort of thing just feels like a step backward.

If the actual means of programming these APIs were updated, then I think the whole thing would look a lot rosier, but maybe there's something I just don't know.

I guess the other problem is that it'll take another five years for browsers to implement HTML 5, even if everyone's really into the idea.

I do also feel that the language on the W3C site is still along the lines of "web applications". What do you think is different about "web applications"? Are they not just "applications"?

I guess the other problem is that it'll take another five years for browsers to implement HTML 5, even if everyone's really into the idea.
Aye, though the Mozilla and Apple teams are both on the HTML5 group (WHATWG), which seems to be going somewhere. A totally seperate thick client would probably take as long, I fear.

I do also feel that the language on the W3C site is still along the lines of "web applications".
"Why use one word when seventeen (in their own markup format) will do" is the W3C motto, I think. Though it is handy to differentiate between web applications and the client-side applications that run them.

I agree about the thick client having the same problem as HTML5 (though they're both thick clients).

I agree - but I don't think they do distinguish (at least properly); currently, there are "web applications" and "non-web applications". The former run in a browser and the latter don't. The former are developed using one set of technologies and the latter a different set. I think this is a bad way of defining things. For me, there are (ideally):

- Applications that have whatever kind of GUI you want that access stuff over a network, possibly from a web server, but probably from something better (supporting things like publishing of events to clients, like HTML 5 seems to suggest a web server would need to)

- Applications that have whatever kind of GUI you want that don't access stuff over a network

Both would be built the same way. Accessing services over a network is just a case of making use of an appropriate library.

Pretty much, that just means you have "applications".

It is a point though, that some of the HTML 5 stuff would seem to suggest some significant changes needing made to servers as well as clients.

won't thick clients just tend towards becoming Word (say) but where all documents are saved on an external server?

and what about the Canvas additions to html? (which treat the browser window as a drawable object, for svg or whatever). which is tending towards X11 or something (but an X11 that is operating system neutral, albeit probably browser specific)

(oh, and btw, php has an include_once(). which may or may not work on windows.)

Yeah, I think that's about the size of it... Though the server would also deliver the executable (word) code, to control updates.

The canvas stuff isn't quite a set of widgets, though... Unless you want to write your own, drawing them with svg.

Didn't know about the include_once() thing. Sorry, I still think it's all a bit shit, PHP.

In addition, the HTML5/Javascript thing has an issue in that you might not want to give your source code away, which you pretty much have to is it's just text included in a web page.

http://tnx.nl/php.jpg