Status of Caffeine

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Status of Caffeine

Siemen Baader
What is the status of Caffeine now - is it production-ready with Pharo, and how large is a minimal (not development) image with everything required to run a production system - i.e. what would be the load time of a Caffeine web app?

Thanks,
Siemen

Sent from my iPhone
Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Ben Coman
On 19 July 2018 at 14:59, Siemen Baader <[hidden email]> wrote:
> What is the status of Caffeine now - is it production-ready with Pharo, and how large is a minimal (not development) image with everything required to run a production system - i.e. what would be the load time of a Caffeine web app?
>
> Thanks,
> Siemen
>
> Sent from my iPhone

hey cool.  I had thought Caffine was only for Squeak, but then was
surprised to find...
https://thiscontext.com/2017/06/29/pharo-comes-to-caffeine-and-squeakjs/

cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Erik Stel
In reply to this post by Siemen Baader
You can find the source at the GitHub-link below. Craig seems active on this
project seeing the number of recent commits. Focus is on creating a live
VR-environment. Cool stuff I think . It will run Pharo, but if that means
'production ready'... Small image sizes for production systems/applications
is probably a separate topic. Caffeine is a Smalltalk VM written in JS (with
some extra's), so image size depends on how small you can make your image. I
read in some of the more recent issues that on some mobile devices (based on
iOS) the page reloads after switching apps and/or locking the device. This
will loose any data currently in the Caffeine app. Craig is working on a
solution based on WebWorkers. This probably means: not production ready for
mobiles yet .  

Link:  https://github.com/ccrraaiigg/ccrraaiigg.github.io
<https://github.com/ccrraaiigg/ccrraaiigg.github.io>  

HTH



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Siemen Baader
Thanks!

My idea was to use it in a similar manner to e.g. Angular, with a full app being loaded into the browser which communicates with a backend API. But this requires the load time to be acceptable.. another direction would be to embed it in a phone gap app and use it to build DOM-based mobile apps. There a larger footprint would be ok.

-- Siemen

Sent from my iPhone

> On 19 Jul 2018, at 11.26, Erik Stel <[hidden email]> wrote:
>
> You can find the source at the GitHub-link below. Craig seems active on this
> project seeing the number of recent commits. Focus is on creating a live
> VR-environment. Cool stuff I think . It will run Pharo, but if that means
> 'production ready'... Small image sizes for production systems/applications
> is probably a separate topic. Caffeine is a Smalltalk VM written in JS (with
> some extra's), so image size depends on how small you can make your image. I
> read in some of the more recent issues that on some mobile devices (based on
> iOS) the page reloads after switching apps and/or locking the device. This
> will loose any data currently in the Caffeine app. Craig is working on a
> solution based on WebWorkers. This probably means: not production ready for
> mobiles yet .  
>
> Link:  https://github.com/ccrraaiigg/ccrraaiigg.github.io
> <https://github.com/ccrraaiigg/ccrraaiigg.github.io>  
>
> HTH
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Craig Latta
In reply to this post by Siemen Baader



Hi Siemen--

> What is the status of Caffeine now - is it production-ready with
> Pharo, and how large is a minimal (not development) image with
> everything required to run a production system - i.e. what would be
> the load time of a Caffeine web app?

     I'm using Caffeine in production with Squeak; there are a few bugs
to deal with in Pharo. Would you like to work together on it?

     A minimal system is a few hundred kilobytes, depending on the
application. The VR app I'm doing now is fairly large and loads in 10
seconds. A small app should take about two seconds. The mini image demo
at [1] is a good approximation.

     Please feel free to join in on Caffeine issues, at [2].


     thanks,

-C

[1] https://squeak.js.org/demo/simple.html#fullscreen
[2] https://github.com/ccrraaiigg/ccrraaiigg.github.io/issues

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Craig Latta
In reply to this post by Erik Stel

Hi Erik--

> I read in some of the more recent issues that on some mobile devices
> (based on iOS) the page reloads after switching apps and/or locking
> the device. This will loose any data currently in the Caffeine app.
> Craig is working on a solution based on WebWorkers. This probably
> means: not production ready for mobiles yet.

     It turns out splitting the app over multiple processes is only
necessary on iOS 12, which has more severe memory limits. iOS 12 doesn't
support OffscreenCanvases in web workers yet, or 2d contexts for OCs, so
for now I'm just back in iOS 11, where everything works in one big
process (Squeak + A-Frame).


     thanks,

-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Siemen Baader
In reply to this post by Craig Latta
Hi Craig,

Great, thanks! The minimal example seems to load fast enough. Do you think there is a potential to slim it down even further for a production system that uses the DOM as its UI, ie remove morphic and others and use the image in headless mode?

Thanks for the offer to work together on the Pharo port. It is too early for me to commit to that, but I definitely like the idea. Right now I'm just checking out. I'd like to use Pharo's (or Squak's) interactive development workflow to develop single page web apps and mobile apps in a reliable manner.

Is there a way to run the IDE in a separate window from the actual application, so that the UI would behave as in production during development? I'm especially thinking of responsive web applications here.

(If not then perhaps putting them into divs next to each other might be a decent workaround)

Cheers,
Siemen

Sent from my iPhone

> On 19 Jul 2018, at 14.25, Craig Latta <[hidden email]> wrote:
>
>
>
>
> Hi Siemen--
>
>> What is the status of Caffeine now - is it production-ready with
>> Pharo, and how large is a minimal (not development) image with
>> everything required to run a production system - i.e. what would be
>> the load time of a Caffeine web app?
>
>     I'm using Caffeine in production with Squeak; there are a few bugs
> to deal with in Pharo. Would you like to work together on it?
>
>     A minimal system is a few hundred kilobytes, depending on the
> application. The VR app I'm doing now is fairly large and loads in 10
> seconds. A small app should take about two seconds. The mini image demo
> at [1] is a good approximation.
>
>     Please feel free to join in on Caffeine issues, at [2].
>
>
>     thanks,
>
> -C
>
> [1] https://squeak.js.org/demo/simple.html#fullscreen
> [2] https://github.com/ccrraaiigg/ccrraaiigg.github.io/issues
>
> --
> Craig Latta
> Black Page Digital
> Amsterdam :: San Francisco
> [hidden email]
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Craig Latta

> The minimal example seems to load fast enough. Do you think there is a
> potential to slim it down even further for a production system that
> uses the DOM as its UI, ie remove morphic and others and use the image
> in headless mode?

     Certainly. I've done some experiments with "animated wireframes"
for the development tools. See [1]. I can compose UIs in HTML, then read
them into SqueakJS and give them behavior by giving them DOM event
handlers written in Smalltalk.

> Thanks for the offer to work together on the Pharo port. It is too
> early for me to commit to that, but I definitely like the idea. Right
> now I'm just checking out. I'd like to use Pharo's (or Squak's)
> interactive development workflow to develop single page web apps and
> mobile apps in a reliable manner.

     Yes, I've found it to be a very productive environment. It's great
to be able to debug things in situ, in the DOM environment.

> Is there a way to run the IDE in a separate window from the actual
> application, so that the UI would behave as in production during
> development? I'm especially thinking of responsive web applications
> here.

     Yes; I've also built an interface to the Google remote debugging
protocol, so (in Chrome) I can run SqueakJS in one browser window, and
control whatever's going on in any other browser window.

> (If not then perhaps putting them into divs next to each other might
> be a decent workaround)

     Yeah, this is what I did in the first Caffeine demo[2]. When I want
the Smalltalk IDE to disappear I just set the opacity of its div to zero
and its pointer-events to none. This approach works across all browsers.


     thanks,

-C

[1] https://tinyurl.com/y9ngn363 (github.com)
[2] https://caffeine.js.org

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Siemen Baader
Very good!

What about the UI lag and the occasional spinner that blocks the UI, is this related to the debugging protocol (I see that the IDEs are loaded in iframes) that will go away when run from local, or is this something that can be optimized away?

Thanks for the details so far!
Siemen



On Thu, Jul 19, 2018 at 8:12 PM, Craig Latta <[hidden email]> wrote:

> The minimal example seems to load fast enough. Do you think there is a
> potential to slim it down even further for a production system that
> uses the DOM as its UI, ie remove morphic and others and use the image
> in headless mode?

     Certainly. I've done some experiments with "animated wireframes"
for the development tools. See [1]. I can compose UIs in HTML, then read
them into SqueakJS and give them behavior by giving them DOM event
handlers written in Smalltalk.

> Thanks for the offer to work together on the Pharo port. It is too
> early for me to commit to that, but I definitely like the idea. Right
> now I'm just checking out. I'd like to use Pharo's (or Squak's)
> interactive development workflow to develop single page web apps and
> mobile apps in a reliable manner.

     Yes, I've found it to be a very productive environment. It's great
to be able to debug things in situ, in the DOM environment.

> Is there a way to run the IDE in a separate window from the actual
> application, so that the UI would behave as in production during
> development? I'm especially thinking of responsive web applications
> here.

     Yes; I've also built an interface to the Google remote debugging
protocol, so (in Chrome) I can run SqueakJS in one browser window, and
control whatever's going on in any other browser window.

> (If not then perhaps putting them into divs next to each other might
> be a decent workaround)

     Yeah, this is what I did in the first Caffeine demo[2]. When I want
the Smalltalk IDE to disappear I just set the opacity of its div to zero
and its pointer-events to none. This approach works across all browsers.


     thanks,

-C

[1] https://tinyurl.com/y9ngn363 (github.com)
[2] https://caffeine.js.org

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Craig Latta

> What about the UI lag and the occasional spinner that blocks the UI,
> is this related to the debugging protocol (I see that the IDEs are
> loaded in iframes) that will go away when run from local, or is this
> something that can be optimized away?

     That's just the speed of Morphic. The VM is set up to display the
spinner whenever anything takes more than a certain amount of time (one
alternative is to just turn it off :). While Morphic in SqueakJS has
gotten a lot faster since the first release, just because JavaScript
engines have gotten faster, I was still motivated to explore
alternatives. That's why I experimented with animated HTML wireframes,
morphic.js from Snap, and using a separate HMTL5 canvas for each morph.

     All three of these approaches are much faster than traditional
Morphic. However, the traditional Morphic UI has the appeal that it's
pixel-portable between the Web and native apps.


     thanks again,

-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Siemen Baader
Ok, Thanks!

:)
Siemen

Sent from my iPhone

> On 20 Jul 2018, at 10.08, Craig Latta <[hidden email]> wrote:
>
>
>> What about the UI lag and the occasional spinner that blocks the UI,
>> is this related to the debugging protocol (I see that the IDEs are
>> loaded in iframes) that will go away when run from local, or is this
>> something that can be optimized away?
>
>     That's just the speed of Morphic. The VM is set up to display the
> spinner whenever anything takes more than a certain amount of time (one
> alternative is to just turn it off :). While Morphic in SqueakJS has
> gotten a lot faster since the first release, just because JavaScript
> engines have gotten faster, I was still motivated to explore
> alternatives. That's why I experimented with animated HTML wireframes,
> morphic.js from Snap, and using a separate HMTL5 canvas for each morph.
>
>     All three of these approaches are much faster than traditional
> Morphic. However, the traditional Morphic UI has the appeal that it's
> pixel-portable between the Web and native apps.
>
>
>     thanks again,
>
> -C
>
> --
> Craig Latta
> Black Page Digital
> Amsterdam :: San Francisco
> [hidden email]
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)
>

Reply | Threaded
Open this post in threaded view
|

Re: Status of Caffeine

Siemen Baader
Hi again,

I played a bit with the online demo. Do you have implemented a basic file browser with
DOM (not canvas) UI? But it is not compatible at the Morphic level, right? So it is not a DOM element based backend that existing Morphic applications could use..?

Also, what happens when you have an exception in code in a DOM callback like xhr completed or a click event? Does it pop up a real Squeak debugger and allows coding in the debugger like real smalltalk?

Cheers,
Siemen

Sent from my iPhone

> On 20 Jul 2018, at 11.27, Siemen Baader <[hidden email]> wrote:
>
> Ok, Thanks!
>
> :)
> Siemen
>
> Sent from my iPhone
>
>> On 20 Jul 2018, at 10.08, Craig Latta <[hidden email]> wrote:
>>
>>
>>> What about the UI lag and the occasional spinner that blocks the UI,
>>> is this related to the debugging protocol (I see that the IDEs are
>>> loaded in iframes) that will go away when run from local, or is this
>>> something that can be optimized away?
>>
>>    That's just the speed of Morphic. The VM is set up to display the
>> spinner whenever anything takes more than a certain amount of time (one
>> alternative is to just turn it off :). While Morphic in SqueakJS has
>> gotten a lot faster since the first release, just because JavaScript
>> engines have gotten faster, I was still motivated to explore
>> alternatives. That's why I experimented with animated HTML wireframes,
>> morphic.js from Snap, and using a separate HMTL5 canvas for each morph.
>>
>>    All three of these approaches are much faster than traditional
>> Morphic. However, the traditional Morphic UI has the appeal that it's
>> pixel-portable between the Web and native apps.
>>
>>
>>    thanks again,
>>
>> -C
>>
>> --
>> Craig Latta
>> Black Page Digital
>> Amsterdam :: San Francisco
>> [hidden email]
>> +31   6 2757 7177 (SMS ok)
>> + 1 415  287 3547 (no SMS)
>>