value of Iliad

[Siemen Baader]

Hi all,

On Tue, May 5, 2020 at 2:07 PM Steven Costiou <steven....@gmail.com> wrote:

Do you guys still think Iliad has an interest technologically speaking, and that we should spend energy on it?

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 guess my question would be more: is there an angle to evolve Iliad in a new and original way you can think about?

 

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?

Anyway, I'm interested to explore debugging features for Iliad, as it is one of my main areas of expertise. Question is always time.

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

 

[Shaping]

[…]

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

 

[Siemen Baader]

Cool - thanks for your interest!

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 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

 

 

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 iliad+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/98f5ebed-a7b8-4448-afca-daeeed9d3e51%40googlegroups.com.

[Shaping]

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

 

[Siemen Baader]

On Sat, May 9, 2020 at 5:19 AM Shaping <sha...@uurda.org> wrote:

Can we change/augment Iliad to use Smalltalk in the browser, as the recent PharoJS video shows? 

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.

 

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.

 

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

1: http://forum.world.st/New-type-of-web-application-using-HTML-CSS-and-Smalltalk-td5116051.html)

[Steven Costiou]

Hi,

Le ven. 8 mai 2020 à 11:25, Siemen Baader <siemen...@gmail.com> a écrit :

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.

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?

 

I can share that, it would be great to work together on it as a part of Iliad. Is anyone interested?

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.).

 

Anyway, I'm interested to explore debugging features for Iliad, as it is one of my main areas of expertise. Question is always time.

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!

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.

 

[Shaping]

On Saturday, May 9, 2020 at 5:37:20 AM UTC-5, Siemen Baader wrote:

On Sat, May 9, 2020 at 5:19 AM Shaping <sha...@uurda.org> wrote:

Can we change/augment Iliad to use Smalltalk in the browser, as the recent PharoJS video shows? 

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.

 

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.

 

Indeed. Try Caffeine, I think it is the most advanced & stable system for this. Then you will be doing applets, not SPAs.

What are the inherent limitations of an applet?  What deficiencies cannot be changed?  I prefer an SPA or AJAX-based architecture. 

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.

Are you saying that the JS is emitting events back to the SmalltalkJS VM/image at a rate it cannot keep up with?

Also, many Pharo classes are transpiled to equivalent classes in JS

Is this what is happening in the video linked below?

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.

Right I was thinking of running STON from Smalltalk only.

 

You can use JS libs but obviously you cannot use them on the Pharo side and use the Pharo debugger.

Can we use Smalltalk to include the needed scripts in the HTML and receive registered callbacks from the running JS?

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),

As long as JS is needed we will need to transpile.  We will need to do this also with a Wasm target. 

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.

I'm okay with that to in the short term. 

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

1: http://forum.world.st/New-type-of-web-application-using-HTML-CSS-and-Smalltalk-td5116051.html)

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