You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Patrick Mueller <pm...@gmail.com> on 2012/10/22 14:14:03 UTC
sweet.js and TypeScript
There was some chit-chat on Twitter this weekend about using the sweet.js
[1] macro processor in Cordova. Somehow. Not quite sure how. Also, a - I
believe trolling - mention of using TypeScript [2]. Somehow.
I'd be interested in hearing more about either.
w/r/t TypeScript - note that Isaac Schlueter has mentioned using TypeScript
with node.js [3]:
"It’d be a great idea to write up a TypeScript header file
for the API surface in Node. Then, we could automatically
test for API deviations, validate and flesh out our
documentation, etc. Static typing does confer some very
relevant value."
I spent a frustrating couple of hours writing code with TypeScript - didn't
come away impressed; but as an interface definition language - maybe. Not
sure what the reflective capabilities are there in terms of the output tho.
[1] http://sweetjs.org/
[2] http://www.typescriptlang.org/
[3] http://blog.izs.me/post/32697104162/thoughts-on-typescript
--
Patrick Mueller
http://muellerware.org
Re: sweet.js and TypeScript
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Oct 22, 2012 at 10:04 AM, Gord Tanner <go...@tinyhippos.com> wrote:
> My main idea with sweet.js would be to replace a couple of the build time
transforms we already do in cordova.js:
>
> module.exports = {
> };
>
> to
>
> define("filename", function (require, define, module) {
> module.exports = {
> };
> };
>
So convert a node.js styled module, into an AMD-styled one, using macros,
instead of the bit-o'code that we already have. Not sure there's enough
bang for the buck there.
> as well as the version number updating.
>
Ya, maybe. So we have some macro that looks like a function invocation,
which maybe at dev time reads a file, but we "compile" at build time into a
string literal. My previous experience with such things is that you need
to make the name of the macro (in this case) very obvious that it's
something replaced at compile/build-time, otherwise it's difficult to tell
what's going on if you just look at the code.
The easiest way to play with this is to have the pre-compiled source code
also be valid JS code, so it will basically work when you run the
pre-compiled version.
It is just a thought but would be nice to use macros to handle those
> transforms and maybe start adding some ES Harmony style macro's to
> cordova.js (Just for our code, not leaking into user code yet).
>
> for example:
>
> var foo = {func: (a) => { return a + 1; }};
>
This violates the "allow the pre-compiled version to still run as JS", so
I'd say "yeah, maybe in the future, once we're happy with infesting our
code with macros".
--
Patrick Mueller
http://muellerware.org
Re: sweet.js and TypeScript
Posted by Gord Tanner <go...@tinyhippos.com>.
Yes, the TypeScript comment was trolling ;)
My main idea with sweet.js would be to replace a couple of the build time
transforms we already do in cordova.js:
module.exports = {
};
to
define("filename", function (require, define, module) {
module.exports = {
};
};
as well as the version number updating.
It is just a thought but would be nice to use macros to handle those
transforms and maybe start adding some ES Harmony style macro's to
cordova.js (Just for our code, not leaking into user code yet).
for example:
var foo = {func: (a) => { return a + 1; }};
On Mon, Oct 22, 2012 at 8:14 AM, Patrick Mueller <pm...@gmail.com> wrote:
> There was some chit-chat on Twitter this weekend about using the sweet.js
> [1] macro processor in Cordova. Somehow. Not quite sure how. Also, a - I
> believe trolling - mention of using TypeScript [2]. Somehow.
>
> I'd be interested in hearing more about either.
>
> w/r/t TypeScript - note that Isaac Schlueter has mentioned using TypeScript
> with node.js [3]:
>
> "It’d be a great idea to write up a TypeScript header file
> for the API surface in Node. Then, we could automatically
> test for API deviations, validate and flesh out our
> documentation, etc. Static typing does confer some very
> relevant value."
>
> I spent a frustrating couple of hours writing code with TypeScript - didn't
> come away impressed; but as an interface definition language - maybe. Not
> sure what the reflective capabilities are there in terms of the output tho.
>
> [1] http://sweetjs.org/
> [2] http://www.typescriptlang.org/
> [3] http://blog.izs.me/post/32697104162/thoughts-on-typescript
>
> --
> Patrick Mueller
> http://muellerware.org
>
--
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos
Re: sweet.js and TypeScript
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Oct 22, 2012 at 6:10 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Not sure I follow your intended purpose for the "header files". Are they
> for documentation purposes?
>
Here's the typescript "header file" for node.js:
http://typescript.codeplex.com/SourceControl/changeset/view/fe3bc0bfce1f#samples%2fnode%2fnode.d.ts
So, what could you use this for? Presumably, things like:
- doc
- instrumented version of Cordova that type-checks parameters
- linters
- code completion in editors, debuggers
- showing structure in editors, debuggers
> docs for CC interfaces:
>
> https://developers.google.com/closure/compiler/docs/js-for-compiler#tag-interface
I meant "interfaces" generically - should have said "APIs".
One of the things you need, if you're going to take the time and hand-code
up a type-encrusted machine-readable description of your "API", is to get
that type information back out again, for your doc, code completers, etc.
Eg, you'd want to "compile" your description into a JSON structure that
some other program can read. I don't see the Closure compiler nor
TypeScript providing this kind of information. But maybe I'm wrong.
It appears Closure uses JSDoc annotations for a lot of this information -
and we're already using these types of annotations; perhaps that's a better
route to go down, for anyone thinking about playing with this stuff. I'm
not sure you can get the "data" description of your API out of JSDoc
either, though.
--
Patrick Mueller
http://muellerware.org
Re: sweet.js and TypeScript
Posted by Andrew Grieve <ag...@chromium.org>.
Patrick,
Not sure I follow your intended purpose for the "header files". Are they
for documentation purposes?
docs for CC interfaces:
https://developers.google.com/closure/compiler/docs/js-for-compiler#tag-interface
On Mon, Oct 22, 2012 at 3:43 PM, Brian LeRoux <b...@brian.io> wrote:
> > My primary interest here would be to do something similar to what Isaac
> was
> > suggesting: have a separate "header file" (prolly header-file-per-plugin)
> > that describes the API of the plugin using a typed description language.
> > Then make use of that typed information in various ways.
>
> FWIW, the Typescript dist contains said header file for NodeJS and
> jQuery. I do believe they had to be hand authored. (ugh)
>
Re: sweet.js and TypeScript
Posted by Brian LeRoux <b...@brian.io>.
> My primary interest here would be to do something similar to what Isaac was
> suggesting: have a separate "header file" (prolly header-file-per-plugin)
> that describes the API of the plugin using a typed description language.
> Then make use of that typed information in various ways.
FWIW, the Typescript dist contains said header file for NodeJS and
jQuery. I do believe they had to be hand authored. (ugh)
Re: sweet.js and TypeScript
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Oct 22, 2012 at 10:05 AM, Andrew Grieve <ag...@chromium.org>wrote:
> I'm well accustomed to writing typed JS from my past experience with
> Closure Compiler. I haven't looked enough at TypeScript yet to know which
> tool might give better type checking, but if people are interested in type
> checking, it'd be worth considering Closure Compiler as well.
My primary interest here would be to do something similar to what Isaac was
suggesting: have a separate "header file" (prolly header-file-per-plugin)
that describes the API of the plugin using a typed description language.
Then make use of that typed information in various ways.
I've tried this a number of times over the years, even doing whacky things
like describing JS interfaces in Java - Java interfaces are easy to
introspect over - and "Web IDL" - which is frankly a bit horrifying (but
can be greatly simplified). So, I'm pretty open-minded about HOW we
describe our interfaces. We just need a way to get the interface
description out of the headers, programmatically.
Does Closure Compiler support that in any way? It appears to me that it
consumes JSDoc comments, and then uses them internally for validation, etc.
--
Patrick Mueller
http://muellerware.org
Re: sweet.js and TypeScript
Posted by Brian LeRoux <b...@brian.io>.
Don't want to see this veer into a huge theory discussion. FTR I
really like Typescript approach but I do not want barriers (real or
imagined) to contribution so from my perspective its out.
Now that said, I really love the concepts in Traceur and SweetJS and
fully support prototyping to remove boilerplate and let the machines
do our work for us. (But would prefer we avoid creating a new language
called Cordova! ;)
On Mon, Oct 22, 2012 at 7:31 AM, Gord Tanner <go...@tinyhippos.com> wrote:
> Just a friendly nudge away from typescript ;) Sweet.js has nothing to do
> with typescript.
>
> The idea is more for using macro's to add new and upcoming syntax support
> to our javascript layer.
>
> On Mon, Oct 22, 2012 at 10:28 AM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> From my indirect knowledge of TypeScript, I think one of its major points
>> is that it's a strict superset of JS. That means that normal JS is valid
>> TypeScript, so it can be used with other libraries and tools that are plain
>> JS.
>>
>>
>> On Mon, Oct 22, 2012 at 10:05 AM, Andrew Grieve <agrieve@chromium.org
>> >wrote:
>>
>> > Sounds like a fun discussion :)
>> >
>> > There are two things about sweet.js that make me iffy about it:
>> > 1. Looks like it might make our code look not like JS, and contributors
>> > would need to learn a new language to figure out what's going on
>> > 2. It might make it easier to write bloated code
>> >
>> > I think if we really wanted something like sweet.js, something like
>> > Traceur<http://code.google.com/p/traceur-compiler/wiki/LanguageFeatures
>> > >might
>> > be a better place to start.
>> >
>> > I'm well accustomed to writing typed JS from my past experience with
>> > Closure Compiler. I haven't looked enough at TypeScript yet to know which
>> > tool might give better type checking, but if people are interested in
>> type
>> > checking, it'd be worth considering Closure Compiler as well.
>> >
>> >
>> >
>> > On Mon, Oct 22, 2012 at 8:14 AM, Patrick Mueller <pm...@gmail.com>
>> > wrote:
>> >
>> > > There was some chit-chat on Twitter this weekend about using the
>> sweet.js
>> > > [1] macro processor in Cordova. Somehow. Not quite sure how. Also, a
>> > - I
>> > > believe trolling - mention of using TypeScript [2]. Somehow.
>> > >
>> > > I'd be interested in hearing more about either.
>> > >
>> > > w/r/t TypeScript - note that Isaac Schlueter has mentioned using
>> > TypeScript
>> > > with node.js [3]:
>> > >
>> > > "It’d be a great idea to write up a TypeScript header file
>> > > for the API surface in Node. Then, we could automatically
>> > > test for API deviations, validate and flesh out our
>> > > documentation, etc. Static typing does confer some very
>> > > relevant value."
>> > >
>> > > I spent a frustrating couple of hours writing code with TypeScript -
>> > didn't
>> > > come away impressed; but as an interface definition language - maybe.
>> Not
>> > > sure what the reflective capabilities are there in terms of the output
>> > tho.
>> > >
>> > > [1] http://sweetjs.org/
>> > > [2] http://www.typescriptlang.org/
>> > > [3] http://blog.izs.me/post/32697104162/thoughts-on-typescript
>> > >
>> > > --
>> > > Patrick Mueller
>> > > http://muellerware.org
>> > >
>> >
>>
>
>
>
> --
> Gord Tanner
> Senior Developer / Code Poet
> tinyHippos Inc.
> @tinyhippos
Re: sweet.js and TypeScript
Posted by Andrew Grieve <ag...@chromium.org>.
If it's for making ES6 features work with older JS engines, then I'm for
it. The first example on sweetjs.org is for making JS look like python
though.
Are you saying you want to use syntax like
http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples
and then sweetjs can be used in the compiling step?
On Mon, Oct 22, 2012 at 10:31 AM, Gord Tanner <go...@tinyhippos.com> wrote:
> Just a friendly nudge away from typescript ;) Sweet.js has nothing to do
> with typescript.
>
> The idea is more for using macro's to add new and upcoming syntax support
> to our javascript layer.
>
> On Mon, Oct 22, 2012 at 10:28 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > From my indirect knowledge of TypeScript, I think one of its major points
> > is that it's a strict superset of JS. That means that normal JS is valid
> > TypeScript, so it can be used with other libraries and tools that are
> plain
> > JS.
> >
> >
> > On Mon, Oct 22, 2012 at 10:05 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > Sounds like a fun discussion :)
> > >
> > > There are two things about sweet.js that make me iffy about it:
> > > 1. Looks like it might make our code look not like JS, and contributors
> > > would need to learn a new language to figure out what's going on
> > > 2. It might make it easier to write bloated code
> > >
> > > I think if we really wanted something like sweet.js, something like
> > > Traceur<
> http://code.google.com/p/traceur-compiler/wiki/LanguageFeatures
> > > >might
> > > be a better place to start.
> > >
> > > I'm well accustomed to writing typed JS from my past experience with
> > > Closure Compiler. I haven't looked enough at TypeScript yet to know
> which
> > > tool might give better type checking, but if people are interested in
> > type
> > > checking, it'd be worth considering Closure Compiler as well.
> > >
> > >
> > >
> > > On Mon, Oct 22, 2012 at 8:14 AM, Patrick Mueller <pm...@gmail.com>
> > > wrote:
> > >
> > > > There was some chit-chat on Twitter this weekend about using the
> > sweet.js
> > > > [1] macro processor in Cordova. Somehow. Not quite sure how.
> Also, a
> > > - I
> > > > believe trolling - mention of using TypeScript [2]. Somehow.
> > > >
> > > > I'd be interested in hearing more about either.
> > > >
> > > > w/r/t TypeScript - note that Isaac Schlueter has mentioned using
> > > TypeScript
> > > > with node.js [3]:
> > > >
> > > > "It’d be a great idea to write up a TypeScript header file
> > > > for the API surface in Node. Then, we could automatically
> > > > test for API deviations, validate and flesh out our
> > > > documentation, etc. Static typing does confer some very
> > > > relevant value."
> > > >
> > > > I spent a frustrating couple of hours writing code with TypeScript -
> > > didn't
> > > > come away impressed; but as an interface definition language - maybe.
> > Not
> > > > sure what the reflective capabilities are there in terms of the
> output
> > > tho.
> > > >
> > > > [1] http://sweetjs.org/
> > > > [2] http://www.typescriptlang.org/
> > > > [3] http://blog.izs.me/post/32697104162/thoughts-on-typescript
> > > >
> > > > --
> > > > Patrick Mueller
> > > > http://muellerware.org
> > > >
> > >
> >
>
>
>
> --
> Gord Tanner
> Senior Developer / Code Poet
> tinyHippos Inc.
> @tinyhippos
>
Re: sweet.js and TypeScript
Posted by Gord Tanner <go...@tinyhippos.com>.
Just a friendly nudge away from typescript ;) Sweet.js has nothing to do
with typescript.
The idea is more for using macro's to add new and upcoming syntax support
to our javascript layer.
On Mon, Oct 22, 2012 at 10:28 AM, Braden Shepherdson <br...@chromium.org>wrote:
> From my indirect knowledge of TypeScript, I think one of its major points
> is that it's a strict superset of JS. That means that normal JS is valid
> TypeScript, so it can be used with other libraries and tools that are plain
> JS.
>
>
> On Mon, Oct 22, 2012 at 10:05 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > Sounds like a fun discussion :)
> >
> > There are two things about sweet.js that make me iffy about it:
> > 1. Looks like it might make our code look not like JS, and contributors
> > would need to learn a new language to figure out what's going on
> > 2. It might make it easier to write bloated code
> >
> > I think if we really wanted something like sweet.js, something like
> > Traceur<http://code.google.com/p/traceur-compiler/wiki/LanguageFeatures
> > >might
> > be a better place to start.
> >
> > I'm well accustomed to writing typed JS from my past experience with
> > Closure Compiler. I haven't looked enough at TypeScript yet to know which
> > tool might give better type checking, but if people are interested in
> type
> > checking, it'd be worth considering Closure Compiler as well.
> >
> >
> >
> > On Mon, Oct 22, 2012 at 8:14 AM, Patrick Mueller <pm...@gmail.com>
> > wrote:
> >
> > > There was some chit-chat on Twitter this weekend about using the
> sweet.js
> > > [1] macro processor in Cordova. Somehow. Not quite sure how. Also, a
> > - I
> > > believe trolling - mention of using TypeScript [2]. Somehow.
> > >
> > > I'd be interested in hearing more about either.
> > >
> > > w/r/t TypeScript - note that Isaac Schlueter has mentioned using
> > TypeScript
> > > with node.js [3]:
> > >
> > > "It’d be a great idea to write up a TypeScript header file
> > > for the API surface in Node. Then, we could automatically
> > > test for API deviations, validate and flesh out our
> > > documentation, etc. Static typing does confer some very
> > > relevant value."
> > >
> > > I spent a frustrating couple of hours writing code with TypeScript -
> > didn't
> > > come away impressed; but as an interface definition language - maybe.
> Not
> > > sure what the reflective capabilities are there in terms of the output
> > tho.
> > >
> > > [1] http://sweetjs.org/
> > > [2] http://www.typescriptlang.org/
> > > [3] http://blog.izs.me/post/32697104162/thoughts-on-typescript
> > >
> > > --
> > > Patrick Mueller
> > > http://muellerware.org
> > >
> >
>
--
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos
Re: sweet.js and TypeScript
Posted by Braden Shepherdson <br...@chromium.org>.
>From my indirect knowledge of TypeScript, I think one of its major points
is that it's a strict superset of JS. That means that normal JS is valid
TypeScript, so it can be used with other libraries and tools that are plain
JS.
On Mon, Oct 22, 2012 at 10:05 AM, Andrew Grieve <ag...@chromium.org>wrote:
> Sounds like a fun discussion :)
>
> There are two things about sweet.js that make me iffy about it:
> 1. Looks like it might make our code look not like JS, and contributors
> would need to learn a new language to figure out what's going on
> 2. It might make it easier to write bloated code
>
> I think if we really wanted something like sweet.js, something like
> Traceur<http://code.google.com/p/traceur-compiler/wiki/LanguageFeatures
> >might
> be a better place to start.
>
> I'm well accustomed to writing typed JS from my past experience with
> Closure Compiler. I haven't looked enough at TypeScript yet to know which
> tool might give better type checking, but if people are interested in type
> checking, it'd be worth considering Closure Compiler as well.
>
>
>
> On Mon, Oct 22, 2012 at 8:14 AM, Patrick Mueller <pm...@gmail.com>
> wrote:
>
> > There was some chit-chat on Twitter this weekend about using the sweet.js
> > [1] macro processor in Cordova. Somehow. Not quite sure how. Also, a
> - I
> > believe trolling - mention of using TypeScript [2]. Somehow.
> >
> > I'd be interested in hearing more about either.
> >
> > w/r/t TypeScript - note that Isaac Schlueter has mentioned using
> TypeScript
> > with node.js [3]:
> >
> > "It’d be a great idea to write up a TypeScript header file
> > for the API surface in Node. Then, we could automatically
> > test for API deviations, validate and flesh out our
> > documentation, etc. Static typing does confer some very
> > relevant value."
> >
> > I spent a frustrating couple of hours writing code with TypeScript -
> didn't
> > come away impressed; but as an interface definition language - maybe. Not
> > sure what the reflective capabilities are there in terms of the output
> tho.
> >
> > [1] http://sweetjs.org/
> > [2] http://www.typescriptlang.org/
> > [3] http://blog.izs.me/post/32697104162/thoughts-on-typescript
> >
> > --
> > Patrick Mueller
> > http://muellerware.org
> >
>
Re: sweet.js and TypeScript
Posted by Andrew Grieve <ag...@chromium.org>.
Sounds like a fun discussion :)
There are two things about sweet.js that make me iffy about it:
1. Looks like it might make our code look not like JS, and contributors
would need to learn a new language to figure out what's going on
2. It might make it easier to write bloated code
I think if we really wanted something like sweet.js, something like
Traceur<http://code.google.com/p/traceur-compiler/wiki/LanguageFeatures>might
be a better place to start.
I'm well accustomed to writing typed JS from my past experience with
Closure Compiler. I haven't looked enough at TypeScript yet to know which
tool might give better type checking, but if people are interested in type
checking, it'd be worth considering Closure Compiler as well.
On Mon, Oct 22, 2012 at 8:14 AM, Patrick Mueller <pm...@gmail.com> wrote:
> There was some chit-chat on Twitter this weekend about using the sweet.js
> [1] macro processor in Cordova. Somehow. Not quite sure how. Also, a - I
> believe trolling - mention of using TypeScript [2]. Somehow.
>
> I'd be interested in hearing more about either.
>
> w/r/t TypeScript - note that Isaac Schlueter has mentioned using TypeScript
> with node.js [3]:
>
> "It’d be a great idea to write up a TypeScript header file
> for the API surface in Node. Then, we could automatically
> test for API deviations, validate and flesh out our
> documentation, etc. Static typing does confer some very
> relevant value."
>
> I spent a frustrating couple of hours writing code with TypeScript - didn't
> come away impressed; but as an interface definition language - maybe. Not
> sure what the reflective capabilities are there in terms of the output tho.
>
> [1] http://sweetjs.org/
> [2] http://www.typescriptlang.org/
> [3] http://blog.izs.me/post/32697104162/thoughts-on-typescript
>
> --
> Patrick Mueller
> http://muellerware.org
>