expanding comments proposal

Gert Cuykens gert.cuykens at gmail.com
Sat Oct 22 14:03:00 UTC 2016


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 <bradley.meck at gmail.com> 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 <gert.cuykens at gmail.com>
> 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 <Ron.Buckton at microsoft.com>
>> wrote:
>> >> From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of
>> >> Gert
>> >> Cuykens
>> >> Sent: Friday, October 21, 2016 4:56 PM
>> >> To: Tab Atkins Jr. <jackalmage at gmail.com>
>> >> Cc: Bruno Jouhier <bjouhier at gmail.com>; es-discuss <es-
>> >> discuss at mozilla.org>
>> >> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>


More information about the es-discuss mailing list