Hello Craig, your answer to my posting to you does not show up here and I only accidentally detected it in the flood of unwanted messages that came is. See my frustration posting above. I accidentally saw just your reply come in. This is why I am answering here to the most important points. I hope you receive this answer. I wrote:
...especially if their sources MUST be closely connected with existing Smalltalk code, which does not run in the client like all the data-driven model definitions etc that I already have
You answered:
There is no such requirement.
Of course, there is, actually it's an absolute necessity in my case. Almost all UI components relate to some definition data, which exist in my main Smalltalk environment. From this data the DDL is generated, the models created, this data handles at run-time the instance variables, avoid getters and setters, and a huge lot more. It's ALL ONLY in ONE central place, of course. No dedundancies! This also handles versions and different configs. The UI is just a slightly enhanced extension to the data-definded models in the MVC concept. And all my models are defined ONLY by data. It would be insane to douplicate this data into the UI parts! I wrote:
the responsivness of such a solution in the browser must always be far slower than any "normal" browser UI
You answered:
That's not true. For example, at the moment my UI is Mozilla's A-Frame 3D virtual reality framework, at 90 frames per second.
Well, what I have seen from the demos, the responsiveness to the cursor alone is so very far away from being acceptable that I only belive, what you are writing, when I have seen a real-word JavaScript UI based on your system. Sorry, over the years, from bad experiences and one's own mistakes, I have become very sceptical and even more careful. I wrote:
and it's impossible to port my >10.000 framwork and application classes to Squeak.
You answered:
Caffeine can use Pharo, Squeak, or Cuis.
Well, my Smalltalk code is in neither of these and it would cost many months of work and the loss of very essential tools to port this to any of your supported systems. That is out of any discussion. Such an investment would never pay back and AFAIK a lot of features are missing in Pharo to substitute my current environment (I couldn' be drunk enough to ever consider Squeak alone because of its outregeous UI). However, *I see one advantage in your approach*, assuming that no Smalltalk source code must be sent to the client (I have no info about that) and this is in the fact that Smalltalk byte code is, of course, a much better protection of IPR than any obfuscated JavaScript could ever offer. But the price for this advantage would be far to high, as far as I can currently tell. So, thank you for responding. I tink we can close the case at least for the foreseable future (and I can't wait, I need some working solution during winter 2017/18). Good luck with your development! Best regards Frank -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.