Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time

Lars Rune Nøstdal wrote:
vanekl wrote:
Lars Rune Nøstdal wrote:
vanekl wrote:
Lars Rune Nøstdal wrote:
[major announcement]


--
Lars Rune Nøstdal
http://nostdal.org/

Your timing is impeccable. I'm starting a new project and am
shopping around for the best framework that fits the project
needs. The biggest perceived need is trying to flip the client/
server model on its head and constructing as much of the widgets
client-side (or is this now the server?), and your framework at
first blush appears to fit this model. I hate page flash in IE,
and direct DOM manipulation fixes that. Should save me bandwidth,
too.


I forgot to comment on this. I'm not sure what you mean, but the
widgets are constructed (or coded?) on the server end.

You may have noticed that the client is slowly taking on more and
more of the server's tasks, such that the traditional server in some instances
may dump the majority of the processing off to the client and the server acts
more in a support role. The producer/consumer model is blurring, and in
some frameworks has actually flipped 180 degrees.
I haven't taken a close enough look around to know on which side
of the wire most of the "control" logic was happening in your
framework so I wasn't sure whether you had made the full switch, too.
That's not important to me as much as whether SW can handle selective
DOM manipulation seamlessly, which it can.

Yes, in a way I guess I kinda want to bring the client to the server
so I can manipulate it there using a language I like. Then mirror
the effects at the client end in real time as I go.

It should really "feel" like the DOM or the browser is "right here
in the REPL" and also available at any time in any code.

Agreed. It really doesn't matter to me where the control logic mainly resides,
as long as this "feel" you mention is maintained. If I remember correctly,
IE6 starts having fits when more than 4,000 js objects are created, so
there's probably a limit on how much you can hand off to the client. And
as long as the feel can be maintained, there's not a lot of compelling reasons
why one would want to force the client to do everything, anyway.

I also want to maintain state so that when the user refreshes the page,
even though he probably doesn't have to do this, or when a widget is
hidden then shown again later - things are "redrawn as they where".
Wrapping things in "widgets" solve this; they are maybe like HTML with
closures -- or something like that.

This is not exactly what I meant, but your code is helpful
and does provide a solution.
I was referring to the brain dead way IE6 refreshes the
entire screen by first whiting it out, and then redrawing
every control, even if no visible change has occurred.
This might happen on a POST, for example, when the data
is posted back to the server but the page remains the same.
I'm sure you noticed this doesn't happen with Mozilla.
Best way to get around this, as far as I can tell, is to
do the DOM manipulation manually (as you show above),
instead of doing the conventional Web 1.0 method of redrawing
the entire page. Yes, asp.net, I'm looking at you, bitch.

Hehe, let's kill it!

I guess i should have explained the reason why this "page flash"
business bothers me. I've noticed my style of web surfing acts
sort of like how an electron moves in a copper wire. Normally
things are fast and fluid, but when I have to make a decision
as to whether I should click on a conventional html button or link
and have the entire page redraw, even if none of the controls
change appearance I stop and think twice about continuing.
(This is equivalent to how an electron occasionally gets
stuck in its metal lattice in my metaphor.) I'm trying
to avoid that hesitation, that mental impedance one gets when one knows
that his environment is going to go away and something new is
about to take its place. It's a mental barrier that I think a
lot of people have, and if you are trying to get customers to
peruse your site, making the site morph to the customer's
commands is more friendly and has lower barriers than, in effect,
deciding to turn the entire screen white, go away for a few
seconds, and then redraw everything, sometimes looking exactly
like the screen was before. It makes coding more difficult,
but I think it makes sense monetarily if used for a store site,
for example. Less hesitation by customers should translate into
increased sales. That's the theory, at least.

I agree. I've noticed this also, and I can imagine it is a
stronger and more negative experience for a person not used to
computers or technology.

Agreed.

..this leads to another challenge wrt. expected behavior..

Yup.

Some have asked me about maintenance of history (back/forward
buttons) combined with referenceability(#1), and I'm working on
some patches that will solve this in a, I think, clean way that
I haven't seen anyone take advantage of yet. :)

This is interesting. There's a huge push to make sites more RESTFUL.
I like the idea, but it's a trade-off. If I had to choose btn
client-side DOM manipulation OR FORWARD/BACK button functionality,
I would choose the former without reservation. I think the crowd
that insists that FORWARD/BACK buttons /must/ work correspond to
the same crowd that insist that universal COPY/PASTE must work on
smart phones, ergo the iPhone is a non-starter.
Designing is about choosing which trade-offs give you the best
overall value. Trying to satisfy every last request from every
last stakeholder is folly, IMO. Better to concentrate on core
competencies if resources are limited, which they usually are.


#1: The ability for a user to link to a certain location at a
site.

.

Loading