Ulrich Hobelmann <[EMAIL PROTECTED]> writes:
> Mike Meyer wrote:
>>> This can be designed much better by using iframes, maybe even Ajax.
>> Definitely with Ajax. That's one of the things it does really well.
> But then you're probably limited to the big 4 of browsers: MSIE,
> Mozilla, KHTML/Safari, Opera. Ok, that should cover most desktop
> users, but you might run into problems on embedded.
True - using Ajax definitely defeats what I consider to be the best
feature of the web.
>>>> Why can't we use the Web for what it was meant for: viewing hypertext
>>>> pages? Why must we turn it into a wrapper around every application
>>>> imaginable?
>>> Because it works?
>> Because you can - if you know how to use HTML properly - distribute
>> your application to platforms you've never even heard of - like the
>> Nokia Communicator.
> If the NC has software that can properly interpret all that HTML, CSS,
> JavaScript plus image formats, yes. But who guarantees that?
You don't need that guarantee. All you need is a reasonable HTML
renderer. The folks at W3C are smart, and did a good job of designing
the technologies so they degrade gracefully. Anyone with any
competence can design web pages that will both take advantage of
advanced technologies if they are present and still work properly if
they aren't. Yeah, the low-end interface harks back to 3270s, but IBM
had a *great* deal of success with that technology.
> I'd rather develop a native client for the machine that people
> actually WANT to use, instead of forcing them to use that
> little-fiddly web browser on a teeny tiny display.
You missed the point: How are you going to provide native clients for
platforms you've never heard of?
> And again: connections might be slow, a compact protocol is better
> than loading the whole UI every time. And while Ajax might work,
> despite the UI being maybe too big for the little browser window, and
> even if it works, it's still probably more work than a simple, native
> UI. First of all it needs to load all the JS on first load, secondly
> sometimes for a flexible UI you'd have to replace huge parts of the
> page with something else. Native UIs are more up to the task.
I'm not arguing that native UI's aren't better. I'm arguing that web
applications provide more portability - which is important for some
applications and some developers.
>> I started writing web apps when I was doing internal tools development
>> for a software development company that had 90+ different platform
>> types installed inhouse. It was a *godsend*. By deploying one
> If that's 90+ GUI platforms, then I agree.
Why do you care if they are GUI or not? If you need to provide the
application for them, you need to provide the application for
them. Them not being GUI just means you can't try and use a standard
GUI library. It also means you have to know what you're doing when you
write HTML so that it works properly in a CLUI. But your native app
would have to have a CLUI anyway.
> I just wonder who wrote fully standards compliant web browsers for
> those 90 platforms.
Nobody. I doubt there's a fully standards compliant web browser
available for *any* platform, much less any non-trivial collection of
them. You write portable web applications to the standards, and design
them to degrade gracefully. Then you go back and work around any new
bugs you've uncovered in the most popular browsers - which
historically are among the *worst* at following standards.
> If you have one Windows GUI (maybe C#), one Mac GUI (Cocoa), one Gtk
> GUI for X, you're done.
You think you're done. A lot of developers think you can stop with the
first one or two. You're all right for some applications. For others,
you're not. Personally, I like applications that run on all the
platforms I use - and your set doesn't cover all three of those
systems.
>> well-written app, I could make everyone happy, without having to do
>> versions for the Mac, Windows, DOS (this was a while ago), getting it
>> to compile on umpteen different Unix version, as well as making it
>> work on proprietary workstation OS's.
> Well, stick to POSIX and X APIs and your stuff should run fine on
> pretty much all Unices.
You know, the same kind of advice applies to writing portable web
apps. Except when you do it with HTML, "portability" means damn near
any programmable device with a network interface, not some relatively
small fraction of all deployed platforms.
> I never understood those people who write all kinds of weird ifdefs
> to on all Unices. Maybe that was before my time, during the
> Unix wars, before POSIX.
There were standards before POSIX. They didn't cover everything people
wanted to do, or didn't do them as fast as the OS vendor wanted. So
Unix vendors added their own proprietary extensions, which software
vendors had to use to get the best performance out of their
applications, which they had to do if they wanted people to buy/use
them.
That's still going on - people are adding new functionality that isn't
covered by POSIX to Unix systems all the time, or they are adding
alternatives that are better/faster than the POSIX version, and there
are lots of things that applications want to do that simply aren't
covered by POSIX. And not all implementations are created equal. Some
platforms malloc's provide - to be polite - less than optimal
performance under conditions real applications encounter, so those
applications conditionally use different malloc implementations. The
same thing applies to threads, except such code typically includes a
third option of not using threads at all. And so on.
And we haven't even started talking about the build process...
Basically, deciding to write to POSIX is a decision to trade away
performance on/to some platforms for portability to more
platforms. It's the same decision as deciding to write a web app,
except the tradeoffs are different. Each of the three solutions has a
different set of costs and benefits, and the correct choice will
depend on your application.
> And if it's not Unix, what's a prop. workstation OS?
They've mostly died out since then. At the time, there were things
like Domain and VMS.
>> Of course, considering the state of most of the HTML on the web, I
>> have *no* idea why most of them are doing this.
> Yep. Maybe it would be best to reengineer the whole thing as ONE UI
> spec+action language, incompatible with the current mess, compact, so
> it can be implemented with minimum fuss. And most of all, I wouldn't
> use a MARKUP language, as a real application is not text-based (at
> least not as characteristic #1).
You mean most of the applications I run aren't real applications?
Right now, my desktop has exactly two GUI applications open on it - a
mixer and gkrellm. Everything else is characeter based. Hell, even my
window manager is character based.
I think you're right - a web standard designed for writing real
applications probably wouldn't start life as a markup for text. The
only thing I can think of that even tries is Flash, but it's
proprietary so I don't know much about it.
Care to tell me how you would design such a format if the goal were to
*not* lose any portability - which means it has to be possible to
design interfaces that work properly on character devices, things like
Palms three-color greyscale displays, and devices without pointers or
without keyboards, or even in an audio-only environment.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
