Re: First group project

Brian Kardell :: @briankardell :: hitchjs.com
On Jan 3, 2013 6:26 AM, "Marcos Caceres" <marcos@marcosc.com> wrote:
>
>
>
>
> On Thursday, January 3, 2013 at 9:53 AM, François REMY wrote:
>
> > I’m totally in. We already worked on that a bit, and I agree with you
this is a starting point to everything: even CSS prolyfills require some
CSSOM at some point. The WebIDL parser is already a good first part, now we
need to translate back to JS.
>
> Excellent.
> >
> > I’ll probably start by making a TypeScript interface description from
the parsed WebIDL, because this is easier and does not require working
implementation; just definitions and mappings. I really propose we use
TypeScript as a target because it compiles down to regular JavaScript and
yet provides useful type annotations that will enable us to check we’re not
doing ‘wrong’ things + it is a polyfill for ES6 classes, something that’s
really cool. Give it a look: http://www.typescriptlang.org/
>
> I'm open to this, so long as we don't use any proprietary features (if
any). Lets use Classes _only_ if we absolutely have to. Lets also be weary
that in some places typescript may conflict with WebIDL. For example,
WebIDL will let you send strings into places where numbers are expected,
and do casting for you as part of the conversion algorithm.
>
> To be clear: any typescript we use will just be a convenience wrapper and
should not be relied on to the do type conversion. Type conversions should
only be done through explicitly following what WebIDL says.
> >
> > Speaking about scope, I propose we support all browsers featuring full
ES5 support; but taking advantage of ES6 features when they are accessible
(that means we’ll probably have to provide multiple implementations of some
methods, because browsers have different ES6 capabilities (IE10 lacks the
ES6 __proto__ for example)).
>
>  I think that is ok. Our target is tomorrow's browsers - we are
explicitly not building any polyfills. If someone wants to take a
prollyfill and back port it to some legacy browser, that is a separate
project.
>
>
I am not an incredible fan of the idea of using typescript here, but I
suppose I could get over it since the output should be valid vanilla js...

More importantly though:  I think we should focus on evergreen browsers...
any attempt to do more I think is way harder, bad and inevitably involves
polyfills and shims - even worse it propigates the problem by not providing
incentives to get one.  There is simply no rationale for not having one at
this point - we should be encouraging the _next web_.