Shoes Socks Polish
3 views
Skip to first unread message
Krishna Krishnamaneni
May 19, 2009, 3:16:52 AM5/19/09
to ruby...@googlegroups.com
Pretty interesting project popped up on Github
http://github.com/petejkim/socks, it emulates shoes framework that
_why has written. The interesting thing about it is it has blocks like
ruby. I was digging through the code since me and Rob were actually
trying to do something similar with
http://github.com/polymar/polish/tree/master which also is a shoes
inspired framework.
Here's what i found: He uses script tag with his own type
(application/javascript-socks ) and he is parsing the code in that
script tag after the page loads, he basically added {} block syntax to
javascript. Pretty nifty.
Can anyone think of a better way to do blocks than this:
http://github.com/petejkim/socks/blob/1be679899a5d8f882a15572aed83a64d9dbdc89a/socks.init.js
or to rephrase the question can anyone think of making {} syntax more
generic than how its used in Socks. We need to implement some kind of
block syntax other than ugly function () {} in Polish since we are
going to present it at Ajax World which is coming up pretty soon.
http://github.com/petejkim/socks, it emulates shoes framework that
_why has written. The interesting thing about it is it has blocks like
ruby. I was digging through the code since me and Rob were actually
trying to do something similar with
http://github.com/polymar/polish/tree/master which also is a shoes
inspired framework.
Here's what i found: He uses script tag with his own type
(application/javascript-socks ) and he is parsing the code in that
script tag after the page loads, he basically added {} block syntax to
javascript. Pretty nifty.
Can anyone think of a better way to do blocks than this:
http://github.com/petejkim/socks/blob/1be679899a5d8f882a15572aed83a64d9dbdc89a/socks.init.js
or to rephrase the question can anyone think of making {} syntax more
generic than how its used in Socks. We need to implement some kind of
block syntax other than ugly function () {} in Polish since we are
going to present it at Ajax World which is coming up pretty soon.
--
Regards,
krishna krishnamaneni.
Dan Yoder
May 19, 2009, 3:57:40 AM5/19/09
to ruby...@googlegroups.com
My advice is to stick with function.
It is less ugly than it seems ... Ruby has spoiled you. The success of JQuery I think proves my point ... it is not a significant obstalce in Javascript land, since developers are used to a slightly clunkier C-derived syntax anyway.
The only way to do something like this is to do what this guy did, and parse the code. At that point, you get into a number of issues, particularly semantics (how do you pass an argument?), debugging, and performance. It isn't worth it just to get rid of a keyword.
Remember, that Nice (the RSD-based library I want to add on top of Polish for my own talk later in September) will solve this problem anyway. So I would say, let Polish be what it is, a Javascript library, and let Nice be there when you want to make it look ... nice.
This also keeps each layer in our emerging little client-side framework nice and focused. Cappucino worries about widgetry, Polish worries about making it dead-simple to programmatically construct UIs, and Nice worries about making it dead-simple to do it declaratively.
One last thought on this ... Keep in mind that Nice will not need to generate Javascript. It is essentially an interpreter that executes using Polish. Up until the Nice stylesheet itself is loaded, we are relying entirely on the native browser's (increasingly) powerful Javascript compilation. By that time, 90% of the real work is finished, and all we're doing is simply mapping parsing events to Polish functions.
This, by the way, is also an advantage of using markup to create structure, since the DOM tree will already have been constructed by the time the Nice stylesheet begins running, reducing the amount of work being done on the fly. However, I'm not sure how easy that is to reconcile with Cappucino.
Dan
It is less ugly than it seems ... Ruby has spoiled you. The success of JQuery I think proves my point ... it is not a significant obstalce in Javascript land, since developers are used to a slightly clunkier C-derived syntax anyway.
The only way to do something like this is to do what this guy did, and parse the code. At that point, you get into a number of issues, particularly semantics (how do you pass an argument?), debugging, and performance. It isn't worth it just to get rid of a keyword.
Remember, that Nice (the RSD-based library I want to add on top of Polish for my own talk later in September) will solve this problem anyway. So I would say, let Polish be what it is, a Javascript library, and let Nice be there when you want to make it look ... nice.
This also keeps each layer in our emerging little client-side framework nice and focused. Cappucino worries about widgetry, Polish worries about making it dead-simple to programmatically construct UIs, and Nice worries about making it dead-simple to do it declaratively.
One last thought on this ... Keep in mind that Nice will not need to generate Javascript. It is essentially an interpreter that executes using Polish. Up until the Nice stylesheet itself is loaded, we are relying entirely on the native browser's (increasingly) powerful Javascript compilation. By that time, 90% of the real work is finished, and all we're doing is simply mapping parsing events to Polish functions.
This, by the way, is also an advantage of using markup to create structure, since the DOM tree will already have been constructed by the time the Nice stylesheet begins running, reducing the amount of work being done on the fly. However, I'm not sure how easy that is to reconcile with Cappucino.
Dan
John Haltiwanger
May 19, 2009, 5:43:00 PM5/19/09
to rubywaves
Ahh, the rebirth of BSS/Cruiser ?
"Nice", I like that :)
And you are totally right that at the level of 'BSS' (for lack of a
better acronym) the {} slight of hand will be moot -- interfaces will
(read: should) be even easier than in Shoes (though arguably not by
much).
So when is it going to be part of the default Waves stack? ;)
> <kitt...@gmail.com>wrote:
"Nice", I like that :)
And you are totally right that at the level of 'BSS' (for lack of a
better acronym) the {} slight of hand will be moot -- interfaces will
(read: should) be even easier than in Shoes (though arguably not by
much).
So when is it going to be part of the default Waves stack? ;)
>
>
>
> > Pretty interesting project popped up on Github
> >http://github.com/petejkim/socks, it emulates shoes framework that
> > _why has written. The interesting thing about it is it has blocks like
> > ruby. I was digging through the code since me and Rob were actually
> > trying to do something similar with
> >http://github.com/polymar/polish/tree/masterwhich also is a shoes
>
>
> > Pretty interesting project popped up on Github
> >http://github.com/petejkim/socks, it emulates shoes framework that
> > _why has written. The interesting thing about it is it has blocks like
> > ruby. I was digging through the code since me and Rob were actually
> > trying to do something similar with
> > inspired framework.
> > Here's what i found: He uses script tag with his own type
> > (application/javascript-socks ) and he is parsing the code in that
> > script tag after the page loads, he basically added {} block syntax to
> > javascript. Pretty nifty.
> > Can anyone think of a better way to do blocks than this:
>
> >http://github.com/petejkim/socks/blob/1be679899a5d8f882a15572aed83a64...
> > Here's what i found: He uses script tag with his own type
> > (application/javascript-socks ) and he is parsing the code in that
> > script tag after the page loads, he basically added {} block syntax to
> > javascript. Pretty nifty.
> > Can anyone think of a better way to do blocks than this:
>
Reply all
Reply to author
Forward
0 new messages