jsui was a mistake.
Javascript for the UI was a big mistake and nothing can be done about it, short of:
Cut your losses.
Somebody made a big mistake. They did not properly research the climate of available virtual machine technology of the 2003 timeframe. Even back then, we were well aware of Lua's' complete superiority.
JS spidermonkey and JS rhino virtual machines are irreclaimable. Their gluttonous memory consumption and slothlike performance will not be fixed.
Now Max/Msp's great potential -- a potential we looked forward for so long, is squandered. Max is not where it should be. This was so important. It was a critical mistake. Now we're screwed for a long time.
I feel that I'm being very pragmatic about this. I'm not taking a hard-edge aggrandizing stance here. JSUI is simply a failure. It's often easy for the creators, in this case, Cycling.. to 'be holding the handle' but not 'inside the pot.'
Yes, us guys who are inside the pot.. if you heard what actually goes on in our small talks, our unvoiced frustrations. It's just sad. "Well couldn't you do it with JSUI?" , "Ah man..." Yes, there are fleeting moments of innocent hope. They're quickly shattered.
Because JSUI is unusably slow. It destroys your CPU, it stabs your music. There is nothing you can do.
LUA is completely superior.
Superior in every possible way to Javascript. There is no justification you can come up with for a reason why we'd ever want Javascript, besides, "well, some web developers know it." And that reason isn't even real. Anybody who really wants to do something with Max's_amazing_new_LuaUi will have no problem getting into Lua very quickly. The "PiL" (Programming In Lua) book is orthogonal to Max/Msp's set of tutorials and help patchers. It's definitive and highly accessible for both programmers and non-programmers alike.
If we take a look at some respectable language benchmarks of LUA vs JS for a variety of algorithms,
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=lua&lang2=javascript
We'll see such things as, oh,
Lua being 8.6 times faster,
Javascript using 163 times more memory,
Lua being 5.7 times faster,
Javascript using 77 times more memory,
Or, in the case of LuaJit (http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=luajit&lang2=javascript), oh,
LuaJit being 30 times faster,
Javascript using 138 times more memory,
LuaJit being 15 times faster,
Ad nauseum.
Lua is an incredible little VM. It's fast and lightweight. It's easily embeddable with luabind or tolua++. It's sandboxed. It's so tiny that you can just spawn off VM's right and left if you like.
Cycling.
Listen up.
It's not too late.
CUT YOUR LOSSES.
JSUI has only been in Max for a few point releases. People aren't too attached. Max 5 is your chance to say:
Oh, well we made a little booboo.
We really want something that works and uses 2% cpu.
Come on.
- Invect
Haha, beautiful! Despite the contrast with the general positive and polite tone on this forum I must say I like this post.
Invect, without verifying your claims I'd like to say thanks for formulating your beliefs/frustrations in a comprehensive way to the MaxMSP community.
I must add that I see no problem at all in having lua -and- js available in Max.
Also check this: https://cycling74.com/forums/index.php?t=msg&goto=109151&rid=3579&S=acc90b750e6e7cee871bcc3602c197a9
my 2 cents
Mattijs
Btw I moved this topic to the javascript forum, mailing list users please reply to the javascript list.
what about using jit.gl.lua in a jit.pwindow?
On 10/4/07, joshua goldberg wrote:
> what about using jit.gl.lua in a jit.pwindow?
It works, but an integrated solution would be much nicer imo. 2 issues with this workaround that come to mind:
- you can't know when to update your window, so you're always updating even though your pwindow might not be visible at the time.
- there is no equivalent to jitter listener in jit.gl.lua. afaik. You have to manually connect the mouse events of the window to jit.gl.lua
I totally agree with Invect. I've tried to do serious UI design in both JSUI and JS+gl.sketch+pwindow. The latter being an order of magnitude faster obviously.
In my last attempt (multilayer sequencer and curve editor) I wasted a lot of time only to end up with an unscalable and slow 3000+ lines Javascript file that is now useless to me.
If I could go back I'd now probably do the whole thing in C++ but that kind of defeats the idea of using Max for me. I'd end up with something more like a standalone app rather than dynamic and reusable Max components.
Since the arrival of Lua support in Max I've been investigating several ways to design a UI library to be used with jit.gl.lua, but I fear I might not have the time or the experience to come up with a sustainable solution on my own.
If Lua ever will be fully integrated with Max, similar to Javascript is now (UI design + Pattr support), I'd be an extremely happy person.
My 2 cents,
Thijs
> In my last attempt (multilayer sequencer and curve editor) I wasted a lot of time only to end up with an unscalable and slow 3000+ lines Javascript file that is now useless to me.
I've been down a similar road. (Though not 3000 lines.. ;-)
I integrated a semi-complicated data structure visualization with
JSUI. It looked really nice, but as you said was quite slow. Also,
the visualization in question was intended to go inside a bpatcher,
and it turns out JSUI doesn't play very well with this, often drawing
outside the bpatcher boundaries.
I'm actually at the moment creating an LCD-based alternative, which is
working fine, though not as pretty. We're still using Javascript for
other tasks.
I never figured out if it's the javascript itself or just the JSUI
stuff that is slow. I get the impression is the latter, but would
need to find some way to test it.
Steve
Wow, I did not even know you could use Lua in Max.
That is good to know.
Anthony
On Oct 4, 2007, at 7:33 AM, Stephen Sinclair wrote:
> I'm actually at the moment creating an LCD-based alternative, which is
> working fine, though not as pretty. We're still using Javascript for
> other tasks.
>
> I never figured out if it's the javascript itself or just the JSUI
> stuff that is slow. I get the impression is the latter, but would
> need to find some way to test it.
Btw, if you disable FSAA (full scene anti-aliasing), JSUI drawing
code is 2-4x faster.
Lua's a great language and we're looking at easier ways for anyone to
make language bindings. So, no need to ditch JS. Btw, the Tamarin VM
which is slated for the next version of the SpiderMonkey JS
implementation is significantly faster. Personally, if speed/memory
is the utmost concern, I'd drop down to C.
-Joshua
The one thing I was hoping not to bring into this thread is another post from JKC about disabling antialiasing on JSUI.
JKC,
You've already said it on this forum 20 times.
We know.
Today while doing research, I read the standard "jkc-antialiasing-signature" at least 10 times.
Come on.
I am so sick of seeing you reply to every single person about disabling antialiasing for "2 to 4x" speed benefit.
It's as if it somehow allows you to slink away from the issue.
EVERY TIME.
> - there is no equivalent to jitter listener in jit.gl.lua. afaik. You have to manually connect the mouse events of the window to jit.gl.lua
Not true!
listener = jit.listener(this.drawto, callbackfunc);
wes
On Oct 4, 2007, at 11:13 AM, Zola wrote:
>
> I am so sick of seeing you reply to every single person about
> disabling antialiasing for "2 to 4x" speed benefit.
> It's as if it somehow allows you to slink away from the issue.
> EVERY TIME.
Sorry, but some people don't read the archives, and/or forget this
fact. The reason that JSUI is slow is that it uses a software based
OpenGL renderer, and uses 4x multi-sampling if fsaa is enabled (which
it is by default). Switching to lua with this same means of rendering
will not make much performance difference as the bottleneck is in the
drawing. In this case it's not a language perf issue. If you want to
make things faster, use js+jit.gl.sketch, or jit.gl.lua with
jit.pwindow, which is HW accelerated.
As for Lua vs. JS VM performance comparisons. Of course you're right.
There are a number of reasons why JS was chosen, and why we're
committed to it as a supported scripting language in Max. With
Tamarin, the VM performance discrepancy between Lua and JS will not
be such an issue.
I appreciate your frustration, but there is nothing preventing you or
other people from integrating Lua into Max. In fact two people, have
already have done this. There's no need to be impolite.
Thanks,
Joshua
Joshua,
Yes, making a lua extern takes just a few hours of work with luabind. I've done so. But the key issue here is something else.
Sketch is great. jit.gl.sketch + jit.gl.pwindow works well in the mostly-monolithic scenario. While I have no issues pushing towards eight sketches, it doesn't work out for atomic.
With Sketch, I would not create a whole set of building block UI components to use everywhere and love. I use Sketch for centerpiece UI's. Not for lego-bricks.
Atomicity is what JSUI is supposed to be able to do.
And that's where it fails too.
It's too slow for that.
So really, there is no use-case for JSUI:
We don't want it for atomic, (watch everything freeze up completely.)(hear your music die)
And we don't want it for what Sketch does.
I am driving at a stronger point here.
A powerful, fast, take-it-for-granted-that-it-just-works-fundamental-essential-building-block-of-the-whole-entire-MAX-idea,
A way of building UI components to go inside of Max,
Perfectly. As a core-feature of Max,
is so important.
It's the basics, man.
It baffles me how Cycling has placed such little importance on getting this right,
and allows JSUI to remain a failure.
The need is so obvious.
- Invect
Zola full of lightning?
On 10/4/07, Zola wrote:
>
> Joshua,
>
> Yes, making a lua extern takes just a few hours of work with luabind. I've done so. But the key issue here is something else.
>
> Sketch is great. jit.gl.sketch + jit.gl.pwindow works well in the mostly-monolithic scenario. While I have no issues pushing towards eight sketches, it doesn't work out for atomic.
>
> With Sketch, I would not create a whole set of building block UI components to use everywhere and love. I use Sketch for centerpiece UI's. Not for lego-bricks.
>
> Atomicity is what JSUI is supposed to be able to do.
> And that's where it fails too.
> It's too slow for that.
>
> So really, there is no use-case for JSUI:
> We don't want it for atomic, (watch everything freeze up completely.)(hear your music die)
> And we don't want it for what Sketch does.
>
> I am driving at a stronger point here.
> A powerful, fast, take-it-for-granted-that-it-just-works-fundamental-essential-building-block-of-the-whole-entire-MAX-idea,
> A way of building UI components to go inside of Max,
> Perfectly. As a core-feature of Max,
> is so important.
> It's the basics, man.
> It baffles me how Cycling has placed such little importance on getting this right,
> and allows JSUI to remain a failure.
> The need is so obvious.
>
> - Invect
>
On Oct 4, 2007, at 12:50 PM, Zola wrote:
> Sketch is great. jit.gl.sketch + jit.gl.pwindow works well in the
> mostly-monolithic scenario. While I have no issues pushing towards
> eight sketches, it doesn't work out for atomic.
You might find jitter-gui-sliderexample.pat useful for your purposes.
Similar strategies could be used in jit.gl.lua, and are also expose
with the Java Jitter binding.
-Joshua
Quote: wesley.hoke@gmail.com wrote on Thu, 04 October 2007 13:58
----------------------------------------------------
> Zola full of lightning?
>
Ack. I can never edit my posts.
jit.pwindow
On Oct 4, 2007, at 12:58 PM, Wesley Smith wrote:
> Zola full of lightning?
Completely :)
-Joshua
Quote: Zola wrote on Thu, 04 October 2007 02:33
----------------------------------------------------
> Javascript for the UI was a big mistake and nothing can be done about it, short of:
> Cut your losses.
> LUA is completely superior.
>
----------------------------------------------------
I love it, if for no other reason than the Lua sibling of jsui could be called lui-lui.
mz
Joshua,
> Lua's a great language and we're looking at easier ways for anyone to
> make language bindings. So, no need to ditch JS. Btw, the Tamarin VM
> which is slated for the next version of the SpiderMonkey JS
> implementation is significantly faster. Personally, if speed/memory
Tamarin will not be fast.
We already know that.
The deal is done.
If you are reserving some future hope that Tamarin will come in and save the day,
No chance.
If you would like proof of that fact,
Your proof will only come when you read-back on my forum posting in 3 years from now, and Tamarin has solved nothing.
Fundamentally it is impossible for Tamarin to ever be fast.
Please check here:
Notice how Tamarin is ~20% faster than SpiderMonkey.
20% is not significantly faster.
It's not an order of magnitude faster like Lua,
or using 150 times less memory, like Lua.
LuaJIT can be 10 to 40 times faster.
Tamarin is a big bloated piece of Junk with a huge codebase. Major KLOCage goes into concerns WEB SECURITY ISSUES.
It's complete bullshit for Max/Msp.
From wikipedia:
"
__What Tamarin is not__
Adobe contributed code for its virtual machine and the JIT compiler. The JavaScript compiler (the program generating bytecode from JavaScript source code) was not contributed as part of Tamarin. The contributed code will be integrated with SpiderMonkey to produce a complete JavaScript engine.
Tamarin is not the same as Adobe's Flash player, which remains closed source. The virtual machine is only a part of the Flash player, and will be a part of future versions of Mozilla/Firefox.
"
It's not a micro-VM like Lua is.
And that's what something like Max needs.
Javascript is worth giving up on.
Let's see Max/Msp become amazing.
Remove the things which stand in your way.
- Invect
On Oct 4, 2007, at 1:45 PM, Zola wrote:
> It's not a micro-VM like Lua is.
> And that's what something like Max needs.
No argument.
> Javascript is worth giving up on.
Won't happen.
It's not an either or question.
-Joshua
> The reason that JSUI is slow is that it uses a software based
> OpenGL renderer
Aha! *NOW* i understand why JSUI is slow. ;-)
It has nothing to do with the FSAA per-say.. this software-based
rendering is of course going to be slow. Surely it might be
eventually possible to drop-in a more efficient renderer that takes
advantage of the operating system facilities for OpenGL? (Maybe this
is planned, sorry I haven't read about the upcoming version yet..)
By the way I don't share Zola's opinion here. I think JavaScript is
actually quite a decent language. As for speed of execution, I pretty
much always expect interpreted languages to be slow and never expect
to use them in time-critical tasks. This is what C is for.
I never did understand why the JSUI stuff seemed slower than need be,
but I didn't realized it was completely software rendered... (thus..
defeating the purpose of using OpenGL?? Though I'm sure it made it
easier to implement.)
Steve
>> - there is no equivalent to jitter listener in jit.gl.lua. afaik. You have to manually connect the mouse events of the window to jit.gl.lua
> Not true!
> listener = jit.listener(this.drawto, callbackfunc);
Oops my bad! Don't know how I missed that one...
Thijs
There's an example in the jit.gl.lua download for listener stuff. It
currently takes a string argument. I've been meaning to change this
to take an actual lua function but haven't got around to it.
wes
On 10/4/07, Thijs Koerselman wrote:
>
> >> - there is no equivalent to jitter listener in jit.gl.lua. afaik. You have to manually connect the mouse events of the window to jit.gl.lua
>
> > Not true!
>
> > listener = jit.listener(this.drawto, callbackfunc);
>
> Oops my bad! Don't know how I missed that one...
>
> Thijs
>
On Oct 4, 2007, at 2:52 PM, Stephen Sinclair wrote:
>
> Aha! *NOW* i understand why JSUI is slow. ;-)
> It has nothing to do with the FSAA per-say.. this software-based
> rendering is of course going to be slow.
Btw, I don't think it should be much slower than the LCD you are
using if you set fsaa to zero (which is why I mentioned that old
tidbit again). As for drop in alternate renderers, you can relatively
easily change Sketch to jit.gl.sketch with jit.pwindow for HW
accelerated OpenGL with similar JS code.
-Joshua
Quote: jkc wrote on Fri, 05 October 2007 10:48
----------------------------------------------------
> Btw, I don't think it should be much slower than the LCD you
> are using if you set fsaa to zero
I also investigated using JSUI for my UI, largely to make use of the better antialiased text and easy scaling/resizing. My display requirements (and thus my internal drawing overhead) are actually very simple.
What killed the deal for me seems to be the overhead involved in passing messages from Max into JSUI. I'm dealing with a fairly dense stream of input messages in some situations, and JSUI required an order of magnitude more CPU time than LCD for the same task when I prototyped using both. Yes, FSAA was off.
If anything could be done about that overhead, I'd certainly look at JSUI again. Alternately, an OpenGL-based native version of LCD that accepts the equivalent OpenGL commands as Max messages would be most welcome, and possibly more future-proof(?). In Max, not Jitter. But maybe that's not possible?
Quote: jkc wrote on Thu, 04 October 2007 19:52
----------------------------------------------------
> Personally, if speed/memory
> is the utmost concern, I'd drop down to C.
----------------------------------------------------
For non-UI projects I’d almost always prefer C. But for UI-projects it is arguable that the API is a bit difficult and that something like jsui would be a lot more straight-forward to program (never mind debug).
Until such time as The One True Perfect Solution(TM) for an interactive UI development environment is available (for Zola that would clearly be Lua, but other people have probably got other ideals), how about this: use jsui to develop & debug, and when it’s working bite the bullet and port to C.
A port could probably have been made with less energy than has been invested into this thread.-!
When you say 'C' -- what do you mean? I've never seen anything allowing you to write UI components for Max in C, except during the old days of MacOS9. I'd love to be able to do that. HOW!? Every UI component is built-in to Max. Do you mean writing a C extern which... sends commands to LCD?
That's simply incorrect. You can write any kind of UI external object
in C. That said, if you have a big UI object project in mind, and
intend to upgrade to Max 5 (yes, I know you can't know this yet,
since you haven't seen it, but you know what I mean here), you should
wait for Max 5's release, since you'll most likely have to rewrite
the object for compatibility.
jb
Am 05.10.2007 um 13:21 schrieb Zola:
>
> When you say 'C' -- what do you mean? I've never seen anything
> allowing you to write UI components for Max in C, except during the
> old days of MacOS9. I'd love to be able to do that. HOW!? Every UI
> component is built-in to Max. Do you mean writing a C extern
> which... sends commands to LCD?
Quote: Zola wrote on Thu, 04 October 2007 20:13
----------------------------------------------------
> I am so sick of seeing you reply to every single person about disabling antialiasing for "2 to 4x" speed benefit.
> It's as if it somehow allows you to slink away from the issue.
> EVERY TIME.
----------------------------------------------------
What if he would have said 'You are correct, jsui is slow.' before saying 'Btw, if you disable FSAA, JSUI drawing code is 2-4x faster.'? I bet that would have made all the difference.
At first I was amazed by the amount of replies by experienced users and developers that looked like slinking away. Now I realize what they really say:
1) 'you are right, this could be better'
2) 'max simply isn't there yet'
3) point out the small improvements there could be made within the current possibilities.
Only step 1 and even 2 are mostly skipped.
It appears that Cycling '74, unlike most other companies, is honest enough to admit things could be better and that it didn't happen yet because of a simple lack of resources (mostly: time). In fact this is assumed to be common knowledge. So don't be too hard on them if they get a little tired of repeating themselves, right? ;)
Mattijs
I'd like to say sorry, if I was steaming, or flaming.
Probably too much coffee. Forgiveness is requested.
>
> It's not an either or question.
>
My comments with regards to Javascript annihilation may seem fanatic.
ie:
"Person has grudge against language Javascript, wants to see it removed. Why would we ever do that?! ..when we can keep the javascript and just provide a better and more generic solution, allowing users to pick what is best for them? Person descends towards language X war. Person hasn't thought this through, person sees only their own selfish preference."
Well, it's not that,
It's something else.
>
> and we're looking at easier ways for anyone to
> make language bindings.
>
Speaking in such a way as I have in this thread walks the fine line between making your point, and coming off as a crackpot.
Yet such is what we must contend with in an closed-source project.
On the flip-side, Max's codified codebase is what makes it really special. Puredata is a mess of different UI solutions, a UI fork, incompatible UI externs with dependencies that went into unmaintained land, and heroic-yet-unconcerted-efforts to fix the problem-- all producing splinters in your hand.
There is a certain greatness about the way that Max/Msp users exchange patches here on the forums. It's a defining characteristic of this community. The unification has kept Max strong. People can help eachother, and build upon the pieces which have been contributed by those who came before them. I don't even know how many parts of my max setup have the evolutionary origin of something I saw in a bugpost. I love it.
That all goes out the window when you throw us into a cold-world of 9 languages. Max's connection is warm. You must think about this. Don't go cold.
I am saying, keep that same patch exchange culture alive with UI design. Keep it alive with a strong fast language.
There is an element of support to all of this. Shipping something with the Max box, having a PDF that comes along, having patchers and .JS files that people can take apart. Just like how the max help-patchers rock.
You can't support 9 languages, have 9 language forums, have a Tabula Rasa, have everyone become veritable multilinguists. There must be one which is fundamentally aligned with Max's IDEA, as a core piece, which has a strong identity and culture, that everybody can read and understand. And then the rest, for who needs em'.
I really believe that people will not try to read Mr.T's_three_thousand_nine_hundred_lines_of_ruby_code when they've focused entirely on another lang for the rest of their work. Well, somebody will. But the gestalt of how things turn out as dependent on previous innovations or posted techniques is very important. Max has a lot of technique to it-- but Mr. T's lines of code weren't learned from lines of code which incorporated drawing techniques and some knowledge gleaned from a forum reply which was learned from lines of code posted in a tip which was taken from a useful abstraction which came from an idea that was in a help file and... And so the Mr.T's-thingy they could possibly pull apart isn't as good as it could be in the first place.
Supporting language binding for those who need it, is a great thing. I'm glad you're looking into that. I couldn't possibly argue against it. In truth, of course, I never actually felt that Javascript should be removed from Max. But simply unsupported, and moved into the "pile of languages" category. But for supported? Javascript isn't good enough to deserve that spot. Javascript isn't the one that's good enough for us all to get behind. If you haven't noticed already.
This whole problem is what has been keeping people from building sequencers in Max/Msp for ten years. The occurrences are few and far between, because there isn't a buildup of components.
It's all about the culture.
If I had my druthers, Lua would be the kick-ass UI design language of Max/Msp, Javascript and any other number of languages would be supported via extended language binding.
Yours,
- Invect
Quote: Jeremy Bernstein wrote on Fri, 05 October 2007 05:50
----------------------------------------------------
> That's simply incorrect. You can write any kind of UI external object
> in C.
Jeremy, I checked the Max SDK, and you're right. I see it's all there. Cool.
Quote: Zola wrote on Fri, 05 October 2007 09:38
----------------------------------------------------
> Quote: Jeremy Bernstein wrote on Fri, 05 October 2007 05:50
> ----------------------------------------------------
> > That's simply incorrect. You can write any kind of UI external object
> > in C.
>
> Jeremy, I checked the Max SDK, and you're right. I see it's all there. Cool.
----------------------------------------------------
I had managed to overlook this, coz I never heard it actually mentioned. I went forum searching here for win32 and got no results, went googling for win32 site:cycling74.com and got no results. I searched for every possible variation on UI, windowing toolkit, embedding, ui extern, window handle, lcd, gl, etc. for posts about people discussing how to do UI design in Max/Msp. I think I spent a week reading some 300 forum threads after making a list of every string which might refer to this stuff, and never in one of them heard somebody really actually say anything about doing it. I even found 2 or 3 posts of people asking if you can, or how to do it, all which went unreplied-to.
..and then, seeing the widgets like jit.cellblock -- NOT being externs. (wtf???)
Now that I see it's possible in the SDK, I even try searching for QTML and get nothing both here or on google searching here.
It's odd. What's with that?
I also don't remember any actual GUI externs which were released anytime since the turn of the century.
Well, I do remember some old mac-only Elsea objects.
Does anybody know of one?
iCE has some
the ambisonics package that jasch worked on has one
all jitter ui objects are externals
all msp ui objects are externals
several max ui objects are externals
UI externs are typically more work to code than non-UI externs, which
is probably why they are in the minority. Nothing to get all freaked
out about, though (wtf????)
Chapter 11 of the Writing Externals pdf (part of the SDK) is called
"Writing User Interface Objects". It's a good place to start (looks
like you already found it).
jb
Am 05.10.2007 um 18:08 schrieb Zola:
> Does anybody know of one?
Another way to reduce jsui's overhead is to have it draw less often. This code is excerpted from CNMAT's resonance-display.js:
function ndraw()
{
if (needtodraw==1)
{
draw(); needtodraw = 0
}
}
var tsk = new Task(ndraw);
tsk.interval=100;
tsk.repeat();
and there's a "needtodraw = 1" statement in the bang method. Look at the whole js for context.
There's no point in drawing faster that the screen refresh rate, no matter how much data is coming in. Our function sets the rate at 10 fps, which is totally fine.
mz
PS Still in favor of a lui *in addition to* jsui. The more the merrier, sez I.
> PS Still in favor of a lui *in addition to* jsui. The more the merrier, sez I.
>
Ha!
LUI and JSUI,
A two-headed brother.
www.icst.net/downloads
you'll find the ambimonitor's source in the Ambisonics Tools for
MaxMSP package.
/*j
my 2c....jsui is seductive becuase it offers a nice neat package for UI stuff...
but it is too slow with the software rendering, even with fsaa off. Fortunately, I haven't spend too much time finding this out-it was an early lesson.
I keep hoping that there will be a hardware-accellerated version of JSUI. Certainly jitter is one possiblility, but it's not quite as tidy as the JSUI. I'm reluctant to keep doing things in LCD, as it will probably never be hardware accellerated & antialiased, and I need to get in the OpenGL habits...
Personally I find javascript very useful --- easy to get things rolling with its connection to Max, especially for list work and some other tasks that come up. Yes, the speed is bad for jsui, but that's only one small part of the roles js can play in Max. There's more than enough ways to create fast, lower-CPU interface objects through jitter and the gl.sketch stuff, and they can look truly amazing (though actual moving textures slow things down, if you get that fancy). I especially like gridshape, as you can set to solid / wire / points and customize the appearance so readily (not to mention "auto-dimensionalizing", if that's a word). Of course you have to map out the interaction with the mouse or whatever you're using, but that's the case with jsui too. Using something like gridshape allows you to skip the js altogether, if you want to.
Interesting thread, glad to see it stayed productive. Performance issues like this will fairly soon be non-issues, at least for most applications. And language integration will of course evolve for more and more functionality and development options.
--CJ
RIP Lua ( ͡° ͜ʖ ͡°)
quickdraw rocks.