World: r3wp

Having a javascript interpreter embedded inside Rebol would allow 
more users ( familiar with javascript ) to write their own add ons 
without having to learn Rebol.

Agreed.

It would also bringe the gap of REBOL and....the "web". :)

Should I make a task for this? :)

Is this on 20% time? :)

This is what Gab and I have been talking about, although even more 
abstracted from REBOL <-> JS, more like REBOL->Dialect->anything 
(HTML, XHTML, JS, HTML+JS, etc.)

I have been giving this a lot of thought over the years, but have 
started coming up with real strategies for doing this for real in 
the last few weeks. I would like to discuss this kind of thing with 
you some time later.

By the way, I would like to ask you that 20% time question for real.

( shouldn't this be in private chat? )

BrianH, You should speak with Henrick too. I believe what you are 
planning is part of long range goals for his html dialect.

I would like to discuss those details, yes. :-)

Brian - bring this topic/plan in Complilers group in R3-alpha world. 
Carl is reading this group, as I pointed him to that interesting 
chat privately ...

Reading this discussion since Terry's first post 8 hours ago (the 
"be serious" one), shows to me how hard it gets to think outside 
the box and that's another challenge when it comes to marketing the 
REBOL browser. When we think of browser, we automatically refer to 
a whole range of technologies and languages. It's something so ingrained, 
we never notice it. Partially you can say it's the same for a PC, 
as it's very likely to run Windows and that if you want to read an 
electronic document mailed to you from an average person, it's very 
likely to be written in MS Word. That's not how we want it to be. 
That's how people think. They think in axioms and familiarity, because 
they don't know any better.


I think the marketing should play strongly on familiarity, such as 
with the aforementioned GMail clone, where it's easy to tell the 
difference in speed between the two technologies. Keep duplicating 
existing stuff. I disagree that the average person can't tell the 
difference. I've observed average people praising that GMail now 
runs faster in FF3 than it did in FF2.


The REBOL browser is disruptive technology. It will be able to do 
things that normal webbrowsers won't be able to do for the next 5 
years at least, if ever. But only if it's done right, by playing 
on familiarity. If it's done right, dumping the traditional web can 
happen faster than we think and I would do it in a heartbeat.

I imagine that if Reichart was ever to do QTask for the REBOL browser, 
he could probably build it alone at 1/3 or 1/4 the time that it takes 
to build it for a traditional browser and the final product would 
run faster.

I think we should wrap some services. Do you remember few scripts, 
wrapping SlashDot? What about wrapping Google mail? And then showing 
the source code of VID? I think it could cause some jaws drops, how 
small the source can be. Then we could encap it, and provide it as 
a Flash app. It could be downloaded in millions. And Google might 
get interested. They imo need something against Flash/Silverlight, 
and there is not third technology to the game but REBOL imo ...

But - we also need multimedia later, so hopefully codecs get finished 
one day ...

These are all great ideas. Is it possible to get started of them 
before we know what Rebol 3 is going to be?

of them -> on them

We have to see the browser and its capabilities first, before we 
can make a next move.

Perhaps it would be easier to appeal to the porn industry to gain 
acceptance. :-)

IMO we can't even be surely Carl will come with browser? Maybe it 
will be "just" VID 3.4, which will allow creation of such browser.

Pekr, why not ask him directly?

But I am glad that my idea of REBOL "player" is fulfilled with the 
browser idea. I never liked ViewTop (desktop paradigm). I wanted 
it to strip down to "go" screen = a browser :-)

to be honest, I am interested in VID 3.4 first, to see how styles 
are built, how it is extensible and in the first place - how flexible 
it is. If it will not allow everything Gabriele had in VID 3, I will 
be strongly disappointed. I expressed it several times publicly and 
also privately to Carl, that I don't accept any unnecessary simplification, 
resulting into R2 VID like limitations. Carl assured me he is taking 
the right aproach, so we will see ...

As for the browser itself, I am not sure Carl is the right person 
to do it (judging how rebol.com looks graphically :-). I think we 
need to cooperate on the idea.

I don't think the design of the browser GUI is as difficult as its 
underlying concepts, like security and basic page display mechanisms. 
He'll want to get those right first.

imo any kind of rebol browser is just VID 3.4 app. That could come 
later imo. We first need to get VID itself right ...

I think he knows that :-)

can't wait for first code examples and screenshots (although those 
will not tell much about architecture itself)

Yeah, let Carl write the stylesheet engine, but have someone else 
do the stylesheets.

Nobody is going to learn Rebol so they can generate Javascript code.. 
and Javascript -> Rebol seems odd. 

I would rather see Rebol -> C or especially Objective C.. then you 
could export to iPhone. 


I played around with Jiggy for my jail broke iPhone.. which lets 
you use javascript to write iPhone apps.. works well. 
http://www.jiggyapp.com/

Terry, Rebol -> JS is kind of similar in purpose and in concept to 
what the Ruby on Rails guys did with Ruby -> JS (aka. RJS).  With 
Rebol's lexical muscles, it is surely a great candidate for abstracting 
what happens in the browser.

I think a few, including Reichart (Qtask), Henrik (HTML Dialect) 
and myself (not started yet, QM) are going this route.

Terry - why would not anyone use VID like fluent description of GUI 
instead of crap js code? Then tell me, why JAVA guys came with declarative 
JAVAFX aproach, if they had JAVA itself already ....

I already used Rebol -> ECMAScript (at least to generate data (mainly 
nasted arrays)) to skip a need to write something like XML parser 
on the client side, how most people do now:)

Terry, I am not going to learn REBOL to generate JavaScript code. 
I already know REBOL. I already have to generate JavaScript code, 
for my job at the very least. As for a REBOL-hosted JavaScript runtime, 
that is likely to be just a useful side effect.

Petr "JavaScript, despite the name, is essentially unrelated to the 
Java programming language, although both have the common C syntax, 
and JavaScript copies many Java names and naming conventions. "

And what I learn can be adapted to other targets, including C, in 
theory. Though C is a poor choice for generating iPhone apps - it 
would be better to generate LLVM code directly, as it has a better 
semantic model than C.

Or even Objective C.

http://phonegap.com/

Interesting. Your point?

While the Rebol community chats, the world solves.

You are talking to the wrong part of the community. I have a full-time 
job solving problems with REBOL.

Here's my problem.. A simple way to create apps for the iPhone.. 
Rebol seems like the perfect candidate. Any ETAs?

Not happening as long as Apple won't allow 3rd party language runtimes 
on the phone.

I don't know anyone in the REBOL community with the porting skills 
who actually owns an iPhone.

I have the skills, but not the phone, and I like the phone I have. 
Do you want to buy me an iPod Touch? And some time?

And a Mac?

Henrik is right... their license forbids other languages and programs 
with a plugin architecture, like say,  other browsers.....

You would have to make a subset of REBOL a library that is statically 
linked to other applications, and that subset could not include any 
of the DO dialect functions. You could generate those applications 
using Mac-hosted standard REBOL code though.

I think that's my point.