Re: [orion-dev] History of handcrafted JavaScript in UI

[Ken Finnigan <ken@xxxxxxxxxxxxxx>]

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

Ken 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