[Sugar-devel] GSoC 2015: Interactive JavaScript Shell

Sebastian Silva sebastian at fuentelibre.org
Sat Mar 14 14:39:30 EDT 2015


I find this discussion very interesting.

It is hard for me not to think of a full IDE like creature when thinking
of the jsfiddle tool.

Perhaps I'm failing to see exactly the point or the inteded "Use Case".

On my side, as a self-taught-as-a-child programmer, I appreciate
abstraction layers very much because they allow me to think of the
actual thing I want to implement.

What I do not appreciate is boilerplate code.

To really understand Hello World activity, you must understand some
basic concepts of Object Orientation, the notion of what is GTK,
event-driven programming, etc.

Even Hello Web carries a lot of boilerplate with it.

In my humble opinion it's not so bad when the boilerplate code is not
seen (i.e. part of the toolchain, or at least, in a template).

Perhaps we've exhausted the discussion and it will come to a matter of
the design chosen by the implementors for its first iteration.

Perhaps it's a good time to remember our core design ideas: Simplicity,
Collaboration, Reflection, and try to apply them to this design.

Sounds like a fun project.

Regards,
Sebastian


El 11/03/15 a las 00:34, Richa Sehgal escibió:
> Hi,
>
> Regarding inclusion of libraries such as Jquery, maybe we can let
> students create templates which we can save in their web folders. The
> objective is the following: As Tony mentioned, providing them with
> templates might not make them learn the basics, but essential parts of
> programming. For example, in my initial days of coding, I used Eclipse
> which started a new file in a nice template. During my first exam, I
> realized that I have forgotten the signature of the function main (the
> arguments type and number of arguments). Since then, for any new
> language that I pick up, I start from scratch. So what we can do is
> that students can create templates for shortcuts, but at least they
> would have some hands-on experience. This can then serve like what
> Sebastian mentions.
>
> As for the performance, after we develop the tool, we can do a
> performance benchmark and publish the numbers for different libraries,
> and CSS functionalities. These numbers can also be used by other
> developers as the basis for their algorithms, and we can see how to
> improve on them and also study how they change as XO and Sugar evolves.
>
> Thanks
> Richa
>
> On Tue, Mar 10, 2015 at 5:05 PM, Tony Anderson <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>> wrote:
>
>     Hi, Sebastian
>
>     I am using Zim Desktop Wiki to reformat the book into digestible
>     lessons (actually done). This makes it all html. My plan is to put
>     this on the school server so that a
>     student can download a chapter to view locally while working on
>     it. I added a button to the Browse toolbar that displays a Journal
>     object chooser and then displays the selected Journal object  - a
>     zip file which contains the web site in a compressed folder.
>
>     I also provide a prerequisite course introducting the Terminal
>     Activity and the nano editor. The model is that students would
>     have a directory in /home/olpc/Documents named web. This directory
>     would be used to hold thier web pages. At some point when they
>     learn about links, they can set up a main page with links to the
>     others. All
>     of this is accessible from the Browse activity by
>     file:///home/olpc/Documents/web/index.html.
>
>     The student should learn to add jquery by reference in the head of
>     their web page. The actual js files can be downloaded from the
>     school server (or installed with Sugar by usb stick). One problem
>     with ide approaches is that it hides some of what we are trying to
>     have the students learn. For example, I seriously considered using
>     pippy to teach Python, but concluded that it would hide how to
>     save Python programs, how to make them executable, and how to
>     share them. In a course on making Sugar Activities, pippy can
>     actually export the python code in a Sugar Activity wrapper, but
>     what does the student learn about the construction of a Sugar
>     Activity from that? I would rather they begin with the HelloWorld
>     Activity.
>
>     I have used a localhost for years with no problem. Since switching
>     from Firefox to Webkit, I haven't been using it but primarily
>     because I haven't tried to implement the features that required
>     it. I am not sure it will be relevant at the intial web level. In
>     any case, jquery did not cause any performance problems on an XO1.
>
>     As regards Webkit, my concern is that in the Browse Activity it
>     does not seem to support flexible boxes, the modern way to do web
>     layout, and in many ways the key to reponsive web design.
>
>     Tony
>
>
>     On 03/10/2015 10:11 PM, Sebastian Silva wrote:
>
>         El 10/03/15 a las 04:58, Tony Anderson escibió:
>
>             I am working on a course based on Pocket HTML
>             (http://www.goer.org/HTML/) which is available via CC. At the
>             javascript level, I think Eloquent Javascript would be a
>             good base and
>             is also CC.
>
>         Hi Tony,
>
>         This is wonderful. I have had my eye on that tutorial ever since I
>         started to think about Web activities a long time ago.
>
>         My first attempt at a Web Activity was called WebSDK and was
>         an IDE for
>         doing web apps [1].
>         Those were old-style web apps, the ones that had a Python
>         mini-server
>         running in the background.
>         I still consider this a good approach to access Python
>         infrastructure
>         from Javascript, but I'm not sure how (or if) the new Web API
>         infrastructure has replaced this mechanism.
>
>         I think, in any case, for a GSOC student working on dev tools
>         for JS on
>         Sugar, should consider the entire IDE scenario, not just the
>         "fiddle"
>         part. I.e. it should be possible to deploy a mini app (or
>         content!) from
>         this activity.
>
>         About embedding JQuery and other libraries, I would favor a
>         "Wizard"
>         approach. I.E. a form that will allow you to have a basic
>         project from a
>         template (w/ or without optional toys such as Jquery). I like the
>         hand-holding approach especially since low performance
>         machines can't do
>         multi-tasking very well (so looking up docs is not easy).
>         Therefore a
>         version of the JS tutorial that Tony referenced would be great
>         to have
>         embedded,  IMHO, or included somehow. (Tony do you have an
>         offline copy?)
>
>         In order to avoid slow pages on older machines, including XO,
>         it should
>         be super lightweight, i.e. utilizing as little CSS3,
>         transformations,
>         transparency, SVG rendering, and animation as possible. At least a
>         couple of templates should be able to run on the XO1 without
>         issues.
>         Hopefully some profiling feedback would be shown inline during
>         development (such as at least load time for the "fiddle").
>
>         Also, there are wrappers for web activities for versions of
>         Sugar that
>         don't include the Web Activities framework. Maybe include those as
>         options in the templates. Finally, a good editor goes a long
>         way for a
>         good development environment (I used Ace editor component and
>         it ran
>         well on XO1, back in the day).
>
>         The way I think of this is that you should be able to develop
>         something
>         relatively basic without resorting to the Internet either for
>         sensible
>         libraries or their respective documentation. If done really well,
>         perhaps we could even offer an alternative to Pippy and Develop?
>
>         Finally, I don't think the Webkit or even old Firefox
>         rendering engine
>         are a severe limitation. It's not worse than targetting Internet
>         Explorer 6 and most web developers had to do that only a
>         couple of years
>         ago. I suggest you download Firefox 3.6 (from like 10 years
>         ago) as that
>         is the rendering engine found on Sugar 0.94 and limit yourself
>         by what
>         it can do. I havben't looked for a reference browser for the
>         Webkit1
>         engines, except Browse itself. It would be good to find out
>         what our
>         current engine equivalent is and document it (along with more
>         contributions) to http://developer.sugarlabs.org/
>
>         Regards and good luck.
>
>         [1] http://somosazucar.org/files/2011/07/WebSDK1.png
>                http://somosazucar.org/files/2011/07/WebSDK2.png
>         .
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150314/d26232b9/attachment.html>


More information about the Sugar-devel mailing list