Good morning Craig, thank you very much for your reply. *Your statements sound very good and most interesting!*
Please pardon, if I expressed myself improperly and not clear enough, which seems to have brought you on a wrong track. So, I propose, let's make a total reset to our current conversation and start it all over again! In order to be more successful in this, I would need more details and I will try to acquire them in the next few days. Is there any link and/or doc where I can get more details on your work and plans than there are available on: https://pharojs.github.io ? The cause of your last posting is that my interest in your concepts has grown tremendously. You will soon see why. I will give you a more details about my environment and intentions: - *WebSockets* are available and play an essential part in my UI concepts. - *Pharo* - I don't mind using Pharo for, let's say, some "intermediate code fractions" as long as the existing server image can keep the sources and generate UI definitions for the client from its definition data. The technical code interchange between Pharo and the Smalltalk I use works quite well. It must just be avoided to port >10.000 application and test classes wtih >200K methods and all my own tools to Pharo. No way! - *User Interface* it seems that we are discussing here two levels, which should be seen separately although they closely interact, of course: 1) there is your part, which consists (in my simple words) of some browser add-on 2) there will be another part, which - at least over the next few years - consists of the by far most comprehensive UI library on the market, which is best capable of providing a desk-top look-and-feel and which much later I intend to substitute by a Smalltalk UI library (see below) 3) there partially are already and will soon be much more of my code, which in the near future acts as *middle layer* with these main purposes to: 3a) Generate all of the UI components using 2) only from definition data, whose original resides in my server image and which is serialized and provided to the client - mainly in a start-up batch procedure and to a smaller part also during run-time by responding to user actions and/or events I have been using an earlier version of this UI lib a few years ago based on handwritten JS code (what a nightmare for a Smalltalker to write JS code in these stone-age tools [I used Eclipse]) for a smaller project and from there I have some experience, which as far as this lib is concerned is mostly positive and for JS just the opposite primarily for the almost non-existing IDE and the crap of file-based sources in general Side-remark1: Why don't want these ignorant idiots who develop JavaScript and its primitive tools refuse to learn from Smalltalk?!?! In a JS forum, some of them wanted to explain me what "o-o" means although I made the clear statement that I have mostly Smalltalk experience. Side-remark2: I used Joose.it, a JavaScript extension that uses a somewhat Smalltalk-like syntax. It was developed by a former HPI student in Potsdam who came from the Smalltalk world. Brilliant! 3b) The middle layer will also act as a generic and data-driven message and data exchange interface with the server, whose purpose is to automate and mostly handle in a generic fashion all the required message passing between the "V" in the client and the "M" in the server as in MVC. 3c) The middle layer will also provide some lower-level "C"ontrollers, which again will mostly consist of data as a first and generic user action control system. 3d) Soon later the data-driven middle layer will be the precondition and technical basis of an UI editor, which is to enable low-skilled programmers, consultants and even somewhat trained and motivated end-users to modify or enhance parts (primarily containers, canvasses) of the prepared UI to their taste and needs. This is the logical extension to and it must work closely together with my long existing user-extendable data models, which constitute an important feature of my applications. 4) My long-term but most important plans (again: the UI iS THE decisive part in standard software) go far beyond this scenario. To cut it short, just the core points: 4a) The JS lib must be fully replaced by a mostly compatible Smalltalk lib (that aint no simple work). 4b) There must be a "private" browser, which offers Smalltalk direct access to the DOM without the current limitations (SOP single origin policy being just one of them) and which sends events straight to Smalltalk. 4c) This private browser should ideally become a technically integrated part of the whole Smalltalk scenario. I know that this is feasable. This will make my mass-market applications independent of the big-G evil giant who is about to extend their monopoly to the browser usages also due to FF's incapabilities to keep it's market share and with G's latest intention to regulate the advertising market by setting their rules in their unfortunately most popular browser. A few more general notes: - there is no room for this ugly, insane crap called *html* in most of my scenarios. It'll all go straight to the DOM. - the *browser* in my scenarios comes in two appearances: a) as a classical browser (to which I have lots of good ideas) b) as a desk-top like UI, which does not appear to be a browser but technically still is by 100% - I have lots of concepts and ideas concerning the user interface (those parts that the user really interacts with) and one of my hopes is that in the long-run this will solve Smalltalk's greatest deficiencies, which are in the lack of a really user-friendly and standard-like looking UI. See my posting here above of 13. Aug. 2017 - 22:42. - I do have a neither finished nor yet presentable white paper, size close to 100 pages, about my UI plans but I do not want to disclose this by now. It's far too early. - There is an important caveat in the close integration of the definition data with the UI parts, which mainly are an extension to what already exists in the definition data. It will neither be possible nor make any sense to extract some parts of it and use them separately. It's either all or nothing. Also, the learning curve is quite high, because the existing framework simplifies, standardizes and automates lot's of things, which must otherwise be programmed individually, but this causes a lot of learning requirements of the extemely well documented abstract and generic parts of my class tree - and it's not in Pharo. Best regards Frank -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p4961569.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
