Re: Questions about netwindows, probably a faq

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Austin,

On Wednesday 07 April 2004 2:08 pm, Austin Schutz wrote:
> On Wed, Apr 07, 2004 at 07:29:44AM -0700, Alex Russell wrote:
[ snip ]
> > This means that we aren't going
> > to go ahead and give you objects that do every little thing (the
> > DOM already does most of that for us), but we WILL give you
> > objects and widgets that the browser doesn't intrinisically
> > provide, as well as a straightforward way to build your own
> > custom widgets if/when you need to.
>
> 	Right, and that's cool. But a novice DOM user like me is is
> completely daunted by using DOM: I don't know which parts of it
> work in which browsers, which parts work correctly, and which parts
> are implemented but require hacks to make them work uniformly
> across all DOM "compliant" browsers. I have a copy of the O'Reilly
> "Dynamic HTML" book. It's an insane monster of a book, weighing in
> at 1400 pages.

Yeah, and it doesn't cover some of the ickiest portions, I'm afraid. 
To some extent, I think you've pretty clearly outlined one of the 
current failings of NW. Right now, we give people that don't know 
jack about either DHTML or app development an easy way to use our 
widgets via inline ctors. Beyond that, your only options with NW are 
to jump in head first. There isn't much of a middle ground: either 
you grok what we do and how we work, or you remain somewhat ignorant 
and hope that you can do what you need with direct inline ctor 
declarations.

I'm open to ideas on how to close this gap.

> 	Said book documents in great detail which browser supports which
> functions and how. But I don't _want_ to have to read this monster,
> or even consult it. What I want is _one_ place I can go to
> implement my application. So if that means the toolkit
> "reimplements" some of the things that actually _are_ cross
> platform, that's fine by me, especially because in the next release
> of browser X they're going to screw it up.

More likely, they're going to fix a behavior that used to be broken 
but you were relying on. That's much more common in my experience, 
but not less troublesome.

> 	I hear the point about latency and bloat, but for the parts the
> browsers do correctly and uniformly the calls would just be shims -
> not much overhead and very little space increase.

Given how anal retentive I am about file size, I tend to think that 
anything like this would have to be completely optional, but I don't 
think I'm against it.

> If even that
> seems like a waste of time and space, how about sticking it in an
> external lib that can be optionally included? Maybe I could work on
> the reimplemented wheel myself. Really though "reimplementation"
> isn't really the right word, because I'm not actually doing any
> reimplementation, just unification.

Some of the building blocks you might want are already in __util__. We 
already can detect if the browser has a sane box model, set total 
width including borders, etc.

I think I'm still uneasy with this, but I'd have to see more about 
what you're proposing (like what the syntax will look like) before I 
make a judgement. I guess what I'm looking for here are particular 
instances of how you would like to use the toolkit and how we fall 
down in those scenarios. Abstracting away problems gets easier when 
you can identify the pain that people are actually feeling.

> 	With that done, I know I can go right to the netwindows docs to
> implement my entire application, given a few "Hello world" sort of
> examples. No muss, no fuss.

The hope is that right now you can just start using many of the 
widgets via inline ctors without having to rip-out and replace large 
portions of your app. The last thing I want to do is create a toolkit 
that either encourages or requires wholesale adoption of our stuff to 
get an app to work right.

[ snip ]

> 	Ok, I wasn't familiar with those, but I've spent a couple hours
> checking them out. dynAPI seems more concerned with layering than
> widgets. Isomorphic seems fairly bloated. domAPI seems to be a
> little closer, but neither it nor Isomorphic are open source.

I've been fortunate over the years to be able to maintain some ammount 
of focus on ease of adoption and by having people helping us like MDA 
who have forced the issues of size, speed, and compression. In order 
to keep providing sane interfaces at acceptable sizes, we have to 
make some tradeoffs. One of the one's that I've come to embrace is to 
write to spec, fix as necessaray. This allowed us to get out ahead of 
the browser curve and over time become one of the most portable 
toolkits around. Another has been to let the browser do the work. 
Between these two, I think there's an explanition for the gulf 
between the ease of use for inline ctors and the ammount you need to 
know to work with our stuff programatically. We don't ease that 
transition any by having our toolkit implement intermediate 
constructs. You're either dealing with an NW object (which thinly 
wraps DOM structures), or you're in the DOM.

> > What benefit do I get by ensuring that my toolkit can't take
> > advantage of improvements in browser rendering, etc...? I guess
> > at the end of the day, there's a difference in philosophy if
> > toolkit design. Whereas some of the other toolkits I mentioned
> > attempt to get everything to be pixel-perfect all the time, NW
> > takes a more web-ish approach to DHTML widgets. That might be
> > what you're looking for, it might not be. You have choices,
> > though.
>
> 	I agree.. definitely want to take advantage of the smarts the
> browser has already. That's the whole point - I want a unified and
> consistent interface to the smarts, which is what the dom standards
> are supposed to give you, but don't due to implementation
> differences.

In this case, I recommend doing something similar to our approach: 
trust the DOM (i.e., develop on Mozilla) and when it comes time to 
port to broken DOM's, only THEN investigate workarounds. We're here 
to help, and we give you higher-level object constructs for wrapping 
up this kind of logic (the NW widget and component classes). But 
since these corner cases get rarer and rarer, it seems like perhaps 
mispent effort to go abstracting them away at great expense to both 
developer and user useability.

> 	On top of that, I want a base set of application widgets as one
> would find in application toolkits, most of which are already
> there, and many more implemented by netwindows. Then I can get to
> work on doing real work and not care about implementation details.

I guess one of the things that strikes me here is that we've got 
different targets: I want a sane way to make developing web apps 
better, whereas you are looking for an interface that will appeal to 
people who aren't sold on developing an app in a browser in the first 
place. Is that a good way of saying it?

[ snip ]

> 	I suspect it's been pigeonholed for the reasons noted above:
> eveyone is stuck trying to figure out how to use it and make it
> work cross platform.

My thinking these days is that there's a lot of culpability to be laid 
at the feet of the major browser manufacturers for not getting their 
collective acts togeather in or around 2000. Netscape stopped 
competing somewhere around NN4.2 and at that point Microsoft decided 
they could rest on their laurels, so we got this dryspell where if 
you were doing "serious" DHTML you had to implement everything twice 
and shoot for lowest-common-denominator capability. This gave rise to 
a lot of these toolkits that spend LOTS of time trying to unify some 
interface that they can use. This lead to a lot of bloat, which in 
turn slowed addoption...etc. Vicious cycle. You get the idea.

We had the adavantage at the time of not being one of the "cool" APIs 
and not having a lot of users to tack us down to a set of 
technologies, so I was able to re-write things in 00-01 to be 
DOM-only. We made a bet and it's paying off now by giving us a very 
favorable size/capability ratio in relation to other toolkits that 
are available. At this point, I hesitate somewhat to start 
re-considering some of the fundamental decisions that put us in the 
advantageous position in which NW finds itself.

> Additionally they don't have any sort of
> "metaphor" with which they can understand how to use it. People
> understand GUI apps, and they understand web pages, but without
> help they won't get web applications.

Our metaphor is DOM-DHTML and what you can abstract away from it to 
give your app a better interface more quickly with less custom code. 
Unfortunantly that means that our metaphor sits at the nexus between 
some technologies that have been giving developers fits for _years_, 
namely HTML, CSS, JavaScript, and DOM. I think we can all agree that 
this is a liability, but given the constraints of our operating 
environment, we're trying to make lemonade. There are lots of great 
reasons to deploy your app to the browser, we don't try to make that 
case any stronger. What we DO try to acheive is giving you a saner 
toolkit once you're comitted to in-browser deployment.

[snip]

> > Other toolkits require these because they don't have an
> > environment that already gives these to them. DHTML, OTOH, exists
> > in an environment that already has a box and bounding model, a
> > reflowable set of containers, and a table implementation that can
> > be used to emulate most of these constructs.
>
> 	Right, so implementing things like 'pack' and 'place' isn't needed
> at all. That makes sense to me now.

Understanding what we provide and what the browser can provide for you 
is an area where we don't do a very good job right now, I'm afraid. 
Perhaps you can help me identify what kinds of documents or tutorials 
would make this easier?

> 	As far as the table implementation emulating the constructs, that
> makes sense too, but how to go from GUI frame widgets to table
> cells requires a bit of a learning curve. Maybe we could provide a
> few examples (again, something I would take on).

If you're willing to help out with this, I would love to work with you 
to get stuff like this written. So far, we've spent a LOT of effort 
on just getting the API documented and even things like the FAQ have 
been something of an afterthought. At some point in the past we 
attempted tutorial-style documents, but they never really got much 
traction (not least of all because I got distracted with fixing bugs 
and making improvements every time I tried to write one).

[ snip ]

> 	Ok.. my understanding is obviously more of gui toolkit and little
> of dhtml. In the gui toolkit realm, you would take a frame, stuff
> two subframes into it, then populate the frame with some sort of
> text widget. It _looks like_ you could do this with tables too.. so
> why is the split pane widget handy?

Because you can't "grab" the section between the "panes" and resize 
them with regular HTML tables. The split pane also allows you to 
specify for each of the panes a URL to fetch contents for the pane 
from. The split pane also works around some fairly nasty DOM problems 
to acheive this.

> > Well, that depends. You already have programatic control over
> > HTML, I see no need to give that additional syntactic sugar that
> > just increases the size of the toolkit. We assume our heavy users
> > are DOM clued, because otherwise you wouldn't be successful in
> > building an app in the browser anyway.
>
> 	Ok, that makes sense. I would hope to make it so simpler
> applications wouldn't require so much dom clue, though.

Right. That's what inline constructors are all about: making it 
trivial for someone to build complex interactions in a purely 
declarative style. Whether or not we get close to this is a matter 
for debate = )

> Conceptually people will have to understand what they're working
> with, but hopefully some of the lower level implementation details
> could be hidden for most apps - sort of like working with C++ (or
> other high level language) instead of assembly.

Sure, but even in C++, you have to grok how the system actually 
_works_ when you have to debug code. If you can't step through a 
debugger and understand what the assembler is doing, you'll never 
make a top-notch C++ developer. The same is true of most technology 
stacks, and DHTML is no different in this regard. Abstraction is a 
common-case convenience, but it doesn't protect us when the 
abstractions break.

[ snip ]

> 	Ok, but unless I'm not understanding, there really isn't a "the
> DOM", per se. There's the w3c dom, plus various implementations
> which differ in minor but crucial ways - much like C varies on
> different compilers. Writing portable 'C' code is a total
> nightmare, despite the fact the compilers are all theoretically
> based on the same specs.

Yes, but the situation is MUCH improved of late. If you have a look at 
the DOM-maipulation code in our widgets, you'll note that there are 
relatively few conditional branches for various browsers. DHTML has 
improved from "write as many times as there are browsers" to "write 
once, test everywhere, tweak for IE".

> > Now, one of the reasons we haven't done the obvious thing that
> > you suggest here (which is to implement wrappers around what the
> > browser can already do) is becaues of the caveat that you
> > outline. Performance for the user in the browser is related not
> > only to runtime speed but also to initialization time.
>
> 	Yeah, I definitely get this. Has anyone figured out how much
> overhead this would take?

No, but I would need to get a better idea of what exactly we are 
wrapping and what the interfaces would look like.

> 	Also, if the "wrapping" isn't worth the overhead where the
> browsers are actually consistent of implementation, it would still
> be worth wrapping the places they differ, but - and here's the key
> part - it could be documented together. Moreover, you never need
> the horrible
>
> isCSS = (document.body && document.body.style) ? true : false;
> isW3C = (isCSS && document.getElementById) ? true : false;
>
> if( isCSS ) { ... }
> else { ... }
>
> style syntax. The toolkit takes care of it for you.

I can see some of the value there. OTOH, we are starting to provide 
utility methods to do a lot of these things where you need them. Box 
model hackery is the biggest problem we find, and __util__ recently 
got a lot of methods to help deal with it.

> > Toolkits that have
> > taken a more heavyweight approach (like Isomorphic) have seen
> > their toolkit size after crunching move upwards of half a meg.
>
> 	Yeah, that seems pretty brutal. It looks like they are trying to
> replicate the look, feel, and speed (argh) of Windows. This is
> definitely not what I'm proposing

Good, I'm not sure I'd help out if you were ;-)

Regards

- -- 
Alex Russell
[email protected]   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAdZVboV0dQ6uSmkYRApuOAJ9Sp5FJGyIIAgZ7BmlWZdWNbGFh1ACfccwl
UHzMCCaicMaw6Ja9QUP1SGA=
=Tfem
-----END PGP SIGNATURE-----


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org