[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