Web frameworks

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

I'm interested in maybe not a full-fledged framework but at least a stylesheet that can do responsive layouts of highly legible text that works on wide variety of browsers, phones, etc... something that looks as polished as medium or substack but at a fraction of the overhead, maybe even something like ILX?

I guess more generally, which sites load fast and are pleasant to read medium to longform text with occasional pictures?