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

[Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>]

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
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

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

_______________________________________________
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