I don't know for sure if these runtime effects can be ignored when we just parsing the code, but I can ask typescript to join the discussion once we have somewhat a basic agreement that the concept of a syntax superset is worth a deeper investigation.
On Sat, Oct 22, 2016 at 3:46 PM, Bradley Meck <[email protected]> wrote: > I would like to note that TypeScript actually has runtime effects/syntax > beyond just type annotation like how modules work: > https://www.typescriptlang.org/docs/handbook/modules.html . I don't think it > is realistic to treat things that affect runtime/import/export/etc. to be > treated as comments and expect things to just work. > > On Fri, Oct 21, 2016 at 10:11 PM, Gert Cuykens <[email protected]> > wrote: >> >> Apparently you can, I used jsbin to show the compiler errors which >> would be the same if I gave you a html file. Notice that web >> components (polymer to be more exact) tend to use inline scripting so >> you can program more declarative and that the html template you are >> using is close to the js code for that specific part, not in a >> different file. >> >> A complete other benefit would be the npm world can contain pure >> typescript and you only need a nodejs compiler once nodejs support >> es2015 modules. Now you need to make type definitions for your npm >> package. I also believe the adoption rate of typescript would increase >> allot. I know that I can't convince a js specialist into typescript >> because they make far less mistakes then I do, but for beginners its >> highly recommended they start with something like typescript before >> you take off the typing training wheels and let them do pure js. >> >> I think the Ecma262 community would benefit if they can tell the >> world, look we will focus on the low level part and if you want >> typings fine, here is the superset syntax specification to do so but >> don't bother us again for typings go complain to Ecma26X :) It's going >> to relieve friction between typescript and narrows the Ecma262 down to >> the essentials without sacrificing blocking evolution in typings which >> is essentially just syntax sugar anyway and never needed as a >> essential part of Ecmascript. Or to phrase it differently, out source >> the typings by making a agreement how to do so. >> >> On Sat, Oct 22, 2016 at 3:59 AM, Ron Buckton <[email protected]> >> wrote: >> >> From: es-discuss [mailto:[email protected]] On Behalf Of >> >> Gert >> >> Cuykens >> >> Sent: Friday, October 21, 2016 4:56 PM >> >> To: Tab Atkins Jr. <[email protected]> >> >> Cc: Bruno Jouhier <[email protected]>; es-discuss <es- >> >> [email protected]> >> >> Subject: Re: expanding comments proposal >> >> >> >> There are two reasons for that, one is am not a typescript expert but >> >> if you >> >> want the complete typescript syntax set I can look it up and try to >> >> summarize >> >> the complete syntax and find some typescript expert who can help me on >> >> this. Two I dont want to exclude other languages that I dont know off >> >> and >> >> make them feel like they don't count. But I admit my end goal for me >> >> personally is indeed aimed to typescript because I use it the most. >> > >> > If this is aimed at the fact that you would like to be able to paste >> > TypeScript code into JSBin, please be aware that JSBin does have support >> > for >> > TypeScript: http://jsbin.com/xeticulini/edit?html,js >> > >> > Ron >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
