Feature: Mobile compilation target for jac

[chess10kp]

Description

I was one of the people at Jachacks today that hacked together a mobile compilation target for Jac. We used a PWA library to put something together for the hackathon, but it comes with obvious performance concerns when trying to render computation heavy views.

Does it still make sense to go ahead with this implementation? Other ideas we tried was to compile to tauri/React native but that's a far more involved process.

We ended up adding in a new codespace for mobile, but given that the differences between the cl and the mobile codespace are very similar, would it make more sense to keep a single codespace and just pass in a flag?

I'd love to work on the PR, but looking for some guidance before I start putting something significant together.

[RandiJay96]

@chess10kp Hi,
Thanks for reaching out. One of our team members will get in touch with you soon with necessary guidance.

[marsninja]

Hi @chess10kp Yes this would be a very useful feature for the ecosystem. Yes I'd imagine this feature being a target flag similar to the desktop target flag that is currently on main and recently enhanced by @musab-mah-7 . I'm going to make a quick pr to beef up the documentation related to his prs on the desktop pathway. Also, what are your thoughts around using Expo for the mobile pathway?

[chess10kp]

Initially we were going to work with React Native (RN) + Expo because I work with it at my day job. It also gives
you access to a huge list of packages, including many web packages ported to mobile. However, RN is subtly different from React, (no dom access, different component names like View, ScrollView, instead of div) and would've ended up being a more involved process, meaning you can't just write web code and have it work on mobile.

Then I thought of using a webview inside a Expo app, but then I realized using capacitor makes more sense at that point. Webviews inside a Expo app can't use native sensors, but with Capacitor you can. On top of that, we reused the existing jac-client implementation to hack something together in a weekend.

The con with using Capacitor is that you get worse perf that RN apps, but this performance isn't always noticable if your views are simple dashboards. Another difference I can think of is that you can't have one file that compiles to both targets, since you cant't use divs in a RN app. The user would have to write two codebases for mobile (using View, ScrollView, Animated) and another for the web frontend.

I could put more time into looking into making Expo work, since that will give you faster apps (in theory).

TLDR: Expo = more effort to build and maintain and can't compile to multiple targets from a single codebase, but also gives you faster apps + more plugins, Capacitor is a lot less effort but slower PWAs and lets you reuse the same codebase for multiple targets.

I'm be down to work on either honestly, they're both going to be fun to implement

[marsninja]

This makes sense @chess10kp, I did a little digging into capacitor and it strikes me that it would be a much more simpler "out-of-the-box" target for Jaseci, though we should likely support both. There are a few internal developers looking into rn+expo potential architectures, but I think we it would be good to integrate capacitor as a webview focused target in the nearer term. Ultimately I'm thinking we should support both and provide developers a choice, though long term I wouldn't be surprised if the fragmentation in the mobile realm has a strong "Electron" moment as whats happening in desktop.

[chess10kp]

Sure, that sounds good. I'll get working on that capacitor PR.