value of Iliad
Locked
 
|
Hi all, On Tue, May 5, 2020 at 2:07 PM Steven Costiou <[hidden email]> wrote:
To me Iliad is unique and valuable because it combines the (time) responsive UI interaction of modern single page web applications with the Smalltalk live development experience. You can't get that combination of UX and Dev Ex with any other framework that I know of. Remember that SPAs have a similar UX to Iliad because they too have to interact with a server for anything interesting. I can elaborate on that, perhaps for a FAQ or feature comparison on the Iliad website.
I have built a layer on top of Iliad with the aim for one developer (me) to develop and iterate many apps rapidly in close dialogue with users and clients. This layer lets med build the UI in pure static HTML with a visual web editor, evaluate it with users before it is integrated with any backend, and integrate it gradually with domain models in Iliad by adding rendering directives to HTML attributes. The frontend stays in plain HTML so I can gradually extend the app with more static content, evaluate it and gradually integrate without having to convert between HTML and tag brushes. I am also abstracting common functionality like navigation, functional testing and also shopping carts to be subclassed in new apps. I find it quite useful and really quick to develop with. I can share that, it would be great to work together on it as a part of Iliad. Is anyone interested?
I think that is very relevant. For myself I have added (monekey-patched) caching variables to the Iliad stack so that `self application` is bound whenever I get an exception in controller code. A lot more can be done to streamline the flow of defining expected behavior in the frontend, then implementing code on the debugger. I think your expertise will be very useful for Iliad here, I don't know if anything could also flow back and help your academic research, but why not? I'm interested in an high-level, design approach to software development and how it can be mapped to running code. Debugging is one very interesting path for this. Feel free to share your ideas! cheers Siemen You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/CAM47Zxo78hPNsm3qpO1_QT%2BFEPjH%2B2uV8AxG%3DfLQDamEOoqh%3Dw%40mail.gmail.com. |
|
|
I have built a layer on top of Iliad with the aim for one developer (me) to develop and iterate many apps rapidly in close dialogue with users and clients. This layer lets med build the UI in pure static HTML with a visual web editor, evaluate it with users before it is integrated with any backend, and integrate it gradually with domain models in Iliad by adding rendering directives to HTML attributes. The frontend stays in plain HTML so I can gradually extend the app with more static content, evaluate it and gradually integrate without having to convert between HTML and tag brushes. I am also abstracting common functionality like navigation, functional testing and also shopping carts to be subclassed in new apps. I find it quite useful and really quick to develop with.
I can share that, it would be great to work together on it as a part of Iliad. Is anyone interested?
I am.
Can you comment on Iliad's suitability for real-time apps?
Shaping You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/98f5ebed-a7b8-4448-afca-daeeed9d3e51%40googlegroups.com. |
|
|
Cool - thanks for your interest!
I think you should think about it like any Ajax app building framework, just more comfortable to use. I think you can get the same degree of real time as with elixir Phoenix which I think you linked to, perhaps a bit less performant than erlang for many users, but not what you need for games and simulations with a simulation and rendering loop. Maybe you’d need to replace the current comet implementation to use web sockets instead of long polling. If you need something than behaves more like an applet then maybe Craig Latta’s caffeine.js is best for you. I’ve used PharoJS for SPAs. It is very fast, loads with little overhead but is very experimental and unstable. I can walk you around the pitfalls but it is not the same dev experience as Iliad or any other smalltalk. Amber is also fast and stable but also lacks the full pharo dev experience. HTH Siemen
--
You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/15FBE924-7D60-475E-87A2-9BFDA86C3CE9%40gmail.com. |
|
|
Can you comment on Iliad's suitability for real-time apps? I think you should think about it like any Ajax app building framework, just more comfortable to use. I think you can get the same degree of real time as with elixir Phoenix
Phoenix is very fast.
which I think you linked to, perhaps a bit less performant than erlang for many users, but not what you need for games and simulations with a simulation and rendering loop. Maybe you’d need to replace the current comet implementation to use web sockets instead of long polling.
Right, polling will not work. WebSocket is the way to go. I’ve used the Zinc framework for WS and HTTP. It works well. Will Iliad be based on Zinc? I saw a mention of the Zn* stuff in a recent posting about the upgrade effort to Pharo 8.
If you need something than behaves more like an applet then maybe Craig Latta’s caffeine.js is best for you.
I’m trying to avoid JS and skip directly to Wasm/WASI. Really. I want my universal compile target to be Wasm, and I want minimal involvement in JS. I’m using two JS libs now with Aida because I have too. I would like to use them also in Iliad, and then port out of JS, as I write my own stuff in Smalltalk and compile to .wat and then .wasm.
I’ve used PharoJS for SPAs.
Can we change/augment Iliad to use Smalltalk in the
browser, as the recent PharoJS video shows?
It is very fast, loads with little overhead but is very experimental and unstable. I can walk you around the pitfalls but it is not the same dev experience as Iliad
Can you break that down? What are the problems? The demo in the video I posted recently seemed very interesting if one’s aim is to code and debug the entire web app in Smalltalk.
or any other smalltalk. Amber is also fast and stable but also lacks the full pharo dev experience.
I could never accomplish much
with Amber, but really wanted it to work.
Even more so now, I’m trying to distance myself from all things JS. I’ll use the JS glue for Wasm-based apps, because I have no choice currently, but
that’s as far as I want to go with it. I
prefer to focus on Wasm, WebGL2, and WebGPU when ready. WebGPU works for native apps too: http://kvark.github.io/web/gpu/native/2020/05/03/point-of-webgpu-native.html.
Shaping
You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/cbcceb57-0137-4834-b612-40c36020c01a%40googlegroups.com. |
|
|
On Sat, May 9, 2020 at 5:19 AM Shaping <[hidden email]> wrote:
No, Iliad is for AJAX applications, while PharoJS and Amber are for single page applications (SPAs) and Caffeine and video of a minimal Pharo image running via SquakJS in a browser that you posted earlier [1] are running comparable to a Java or Flash applet - they download a Smalltalk image an run that. Three different architectures with different properties.
Indeed. Try Caffeine, I think it is the most advanced & stable system for this. Then you will be doing applets, not SPAs. PharoJS (for SPAs) is unstable in that it the bridge that it uses to connect Pharo and the JS runtime breaks when too many JS events are fired, so you have to use the JS console to interact with your code in the browser instead. This rules out (reliable) TDD and coding in the Pharo debugger. Also, many Pharo classes are transpiled to equivalent classes in JS which behave differently or miss methods, so you get different behavior in JS. Eg Dictionary can only handle strings as keys. This means you cannot use Pharo libraries in JS, eg STON. You can use JS libs but obviously you cannot use them on the Pharo side and use the Pharo debugger. I have found ways to work with this using mocks in Pharo for DOM and other browser objects and transpile code to JS (this part is reliable), and by using the Firefox Scratchpad (now removed from Firefox, but you can still use the console in multiline mode) to interact with the transpiled js code directly. I am OK with seeing and occasionally debugging the JS code as long as I can maintain my code base in Pharo. But in the end there are many bugs and many incomplete parts which are not really fixed for years before new features are introduced. Iliad and Amber are stable, and Caffeine seems stable. HTH Siemen You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/CAM47ZxqxTZw-E8VpQMt1OBP6%2B-DbPDxFAF%3DAw-7ky2Q7e072FQ%40mail.gmail.com. |
|
|
In reply to this post by Siemen Baader
Hi, Le ven. 8 mai 2020 à 11:25, Siemen Baader <[hidden email]> a écrit :
This is cool :) I really liked Iliad and its simplicity, and it is cool to know that it still has value :) What about the ajax stuff that Iliad uses? Is it not outdated?
Yes I'm interested. We're not a lot to work with/on Iliad, so once it's migrated to github we can add our own packages in it. @Benoit, for now the only problem is the migration? I personnally would not bother with keeping all the history. Everything is on sthub and squeaksource, and what we'll do with Iliad will probably be different. Could we not migrate what we can (if we have history or part of it, it's nice) and just credit the right people somewhere in the (future?) iliad webpage (using github pages?)? Once we have the github project, we can add issues and a project to manage Iliad and we can all help on the porting to Pharo 8/9 and on moving outdated dependencies to modern tools (e.g., zinc, etc.).
Well, first I also think it is a great sandbox to experiment debugging tools. Once we got the github migration done we should create packages with debugging tools, I'd be interested to see what you did and how it solved your needs. And in Pharo 8 and 9, we have lots of new advanced debugging features that I'm eager to experiment on real apps, such as object-centric debuggers, scriptable debuggers, back-in-time debuggers, etc. I also worked during my phd on "unanticipated debugging", that is, you get a bug only in production (or you get a bug but you cannot stop your app), so you need to connect a debugger on-the-fly and debug your app. But in that case, you need some properties like minimum (or controlled) interference, easy rollback, etc. So I got prototypes of such tools, and next year I want to push that further. I always wanted to experiment that kind of bleeding-edge technology on Iliad, but never actually got the opportunity. Steven. You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/CADaHKuFaFfZairumRNLxZbGeQo393X8cd4%3DWXgdGQR6cLWMjKQ%40mail.gmail.com. |
|
|
In reply to this post by Siemen Baader
On Saturday, May 9, 2020 at 5:37:20 AM UTC-5, Siemen Baader wrote:
What are the inherent limitations of an applet? What deficiencies cannot be changed? I prefer an SPA or AJAX-based architecture.
Are you saying that the JS is emitting events back to the SmalltalkJS VM/image at a rate it cannot keep up with?
Is this what is happening in the video linked below?
Right I was thinking of running STON from Smalltalk only.
Can we use Smalltalk to include the needed scripts in the HTML and receive registered callbacks from the running JS?
As long as JS is needed we will need to transpile. We will need to do this also with a Wasm target.
I'm okay with that to in the short term.
I don't understand why the PharoJS architecuture is being pursued by anyone if Smalltalk-level debugging is not possible. Erik Stel, the author, in the link above mentions debugging in Smalltalk. How would this be done? Shaping You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/407aed53-d5c7-4360-8677-3a8fcf50cb42%40googlegroups.com. |
| Free forum by Nabble | Edit this page |