[Sugar-devel] Regarding GSoC tasks in Sugarizer

[Lionel Laské]

Hi Utkarsh,

Sugarizer is currently agnostic regarding JavaScript frameworks.
Some activities are written in Vue.js (eBook Reader, Calligra), some
activities are written in ReactJS (Scratch, Exerciser), some activities are
written in Enyo (Abecedarium, TankOp, FoodChain, TamTam), most other
activities are written in VanillaJS with some specific JS framework
(CreateJS, Cytoscape, ...).
The only pre-requisite is to integrate require.js and sugar-web, see
https://github.com/llaske/sugarizer/blob/master/docs/architecture.md
Sugarizer Core is written in Enyo.js. BTW it's more a way to structure the
code than a real dependency on UI, because the UI aspect is provided by
sugar-web. Since Enyo is (already) deprecated, migrating to Vue.js is in
the roadmap. But once again, the dependency should stay light. Plus, I'm in
favor to use an inline framework instead of a framework that need a backend
and a dev environment to be used. It's why I'm more interested by Vue.js
than by ReactJS/Angular.

Regarding GSoC ideas, Vue.js is recommended but not mandatory.
Specifically I think that Vue.js is more pertinent for Knowledge activity
pack than for Game activity pack where most the UI will probably depend of
canvas (at least for Tamgram).
So you're free to make a proposal without Vue.js. BTW if you integrate
Vue.js in your proposal, I suggest you to have a look on Calligra activity
that already propose and encapsulation of sugar web components (toolbar,
localization, ...) into Vue.js. The first task for GSoC students could be
to propose an Activity Template in Vue.js.

Hope it helps.

Regards.

             Lionel.




Le mar. 17 mars 2020 à 10:37, Utkarsh Raj Singh <u.rajsingh2503 at gmail.com>
a écrit :

> Hello,
>
> The ideas page for GSoC 2020 has several ideas for Sugarizer, and all of
> them recommend the use of Vue.js, as necessary. While this is a progressive
> decision, I would want to discuss a few points:
>
> Frontend libraries provide many standard implementations out of the box.
> This will help us take many critical decisions automatically - Vue.js will
> already do it for you. This will save a lot of time and help us maintain
> industry relevant implementations. And if given the choice, I will
> definitely vouch for Vue.js as I personally like it.
>
> That being said, we also know that most of the activities are in
> VanillaJS. And while this takes more time to develop, we have more fine
> grained control over the DOM updation, performance and several other
> factors. Also, if we utilise one particular framework, and that framework
> is to depreciate in the future, we will possibly have to port to some
> prevailing framework.
>
> For almost every aspect of an application can be developed both in
> VanillaJS and Vue.js, I am a little confused as to what to prefer. Should
> we make Vue.js based activities, or should we stay with VanillaJS? In other
> words, to what extent should we mix the two? I would appreciate if the
> community can guide me here.
>
> Thanks,
> Utkarsh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20200317/7f1c0d04/attachment.htm>