Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] History of handcrafted JavaScript in UI

re: tracking shims
That's a timely question! We're just doing a major overhaul of all existing bugs in Orion but there will be a bugzilla report for each shim that is ready to be removed. There is no one bug that groups all the various shim removals together however that's not a bad idea at all - I'll look to do that.

re: use a library for  a new feature -- sure if the license is right and as long as it wasn't huge -- it's a bit of a balancing act to be honest. An example like this that comes to mind is Polymer. We really want to adopt native browser web components and are willing to shim but we need to weight costs vs benefits carefully here. Also... if we really feel the feature is valuable we would actually help push its adoption forward in TC39 or the  WebApps WG since we want both a standard backing the feature and a native implementation someday.

-Simon
Inactive hide details for Ken Finnigan ---05/07/2015 11:33:31 AM---Hi Simon, Thanks for the detailed response.Ken Finnigan ---05/07/2015 11:33:31 AM---Hi Simon, Thanks for the detailed response.

From: Ken Finnigan <ken@xxxxxxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 05/07/2015 11:33 AM
Subject: Re: [orion-dev] History of handcrafted _javascript_ in UI
Sent by: orion-dev-bounces@xxxxxxxxxxx





Hi Simon,

Thanks for the detailed response.

Is there a document, BZ, or something else that tracks the state of the "shim" or "polyfill" components that are being used prior to their inclusion in a browser? Something linking the code to the relevant standard, and maybe a rough roadmap?

Just to clarify, if a new library was created that added a new feature to JS, but it wasn't part of an existing or evolving standard, would Orion consider utilizing it, would Orion be inclined to push for its adoption in a standard, or wait for it to be included in a draft standard?

Thanks
Ken


On Tue, May 5, 2015 at 3:22 PM, Simon Kaegi <Simon_Kaegi@xxxxxxxxxx> wrote:
    Hi Ken,

    There is indeed an architectural principle at work here that drives our choices for base-level components. Orion wants to build directly on the browser API as opposed to using a library that provides its own base platform. When a particular browser or even work on a browser standard is not ready for prime-time we use a "shim" or "polyfill" to emulate the behavior we anticipate. For several of the shims we have like Deferred, HTMLTemplates, TextEncoder, and URL we're actively working with others standards implementers to get agreement. For Deferred as you guessed we've been  following the process with our implementation  all the way from it's beginnings as CommonJS Promises/A "then-ables" through to the work in ECMA 6 Promises.


    We're happy to use libraries where we can however with our shims unless there is a de-facto standard we're more likely to use our own implementations to give ourselves a bit more control during the bumpy period when the native implementation of what we were shimming lands in the browsers. An example of that is when Chrome first added the URL Object it lacked query parameter handling and we had to react.


    With all that said,  Orion's Deferred.js, encoding-shim.js, EventTarget.js, HTMLTemplate.js, URL-shim.js, and xhr.js are very close to  ready to be removed in favor of their native counterparts. e.g. planned obsolescence in action


    -Simon


    Inactive hide details for Ken Finnigan ---05/04/2015 09:11:50 PM---Hi, I've been taking a look at the Orion UI code and am curiKen Finnigan ---05/04/2015 09:11:50 PM---Hi, I've been taking a look at the Orion UI code and am curious as to the

    From:
    Ken Finnigan <ken@xxxxxxxxxxxxxx>
    To:
    Orion developer discussions <orion-dev@xxxxxxxxxxx>
    Date:
    05/04/2015 09:11 PM
    Subject:
    [orion-dev] History of handcrafted _javascript_ in UI
    Sent by:
    orion-dev-bounces@xxxxxxxxxxx





    Hi,

    I've been taking a look at the Orion UI code and am curious as to the history of some of the choices that were made in the past around _javascript_.

    For instance, Deferred.js (
    https://github.com/eclipse/orion.client/blob/master/bundles/org.eclipse.orion.client.core/web/orion/Deferred.js) is a handcrafted _javascript_ implementation of a Promise API. Does anyone recall the reasons for handcrafting instead of using an existing library for Promises?

    The copyright of the file is 2012, so a library for _javascript_ Promises was not likely available at that time. Has there been any consideration to replacing handcrafted _javascript_ like this, or other usages, with libraries?

    Thanks

    Ken Finnigan_______________________________________________
    orion-dev mailing list

    orion-dev@xxxxxxxxxxx
    To change your delivery options, retrieve your password, or unsubscribe from this list, visit

    https://dev.eclipse.org/mailman/listinfo/orion-dev

    _______________________________________________
    orion-dev mailing list

    orion-dev@xxxxxxxxxxx
    To change your delivery options, retrieve your password, or unsubscribe from this list, visit

    https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev

GIF image


Back to the top