LockerService and Lightning Container Component: Securely Using Third-Party Libraries in Lightning Components

Regardless of the language, framework, or platform you use, modern applications are built by assembling discrete and composable components. On the Salesforce platform, the application composition infrastructure is provided by the Lightning Component Framework. That’s how the Salesforce Apps (Sales Cloud, Service Cloud, etc) are built, and that’s also how you can extend and customize these apps with your own components, or create completely new apps.

The components you assemble can come from different sources. For example, you can build an application (or a page) by assembling Salesforce components, third-party components, and your own components. Components can be built entirely from scratch or by leveraging third-party libraries. In this article, we discuss the different types of libraries you may want to use in a Lightning Component, and we compare two isolation mechanisms (LockerService and the Lightning Container Component) that allow you to use them securely and avoid security exploits.

Which Library Do You Need?

Third-party libraries usually fall in one of the following categories:

  • DOM manipulation libraries (jQuery, etc)
  • Specialized utility libraries (moment.js, numeral.js, etc)
  • UI libraries (Bootstrap, jQuery UI, etc)
  • Data visualization libraries (D3, Chart.js, Leaflet, etc)
  • MVC frameworks (React, Angular, etc)

Before we look at how you can use a third-party library in a Lightning Component, it’s useful to ask yourself why you are using it, and if you really need it. In some cases the answer will be a resounding yes: nobody wants to reinvent a data visualization library like D3 or a mapping library like Leaflet. In other cases the answer will be less clear. Let’s take a closer look at DOM manipulation libraries, UI libraries, and MVC frameworks in particular.

DOM Manipulation Libraries

JavaScript has come a long way in recent years. Many DOM manipulation utilities we couldn’t live without in libraries like jQuery are now standard in the language. Modern frameworks like the Lightning Component Framework also provide abstractions that make jQuery less relevant. For example, let’s say you have to set the value of a score input field to 100.

Using jQuery, you would:

  1. Assign a unique id to the input element
  2. Use a jQuery selector to find the input element in the DOM
  3. Assign the value to that DOM element
// Markup:
<input id="score" />

// Code:
var scoreElement = $("#score");

Using the Lightning Component Framework, you would:

  1. Declare a score attribute
  2. Bind the input field to the score attribute
  3. Set the value of the score attribute: the bound input field will automatically display the new value.
// Markup:
<aura: attribute name="score" type="integer" />
<input value="{!v.score}" />

// Code:
component.set("v.score", 100);

In the Lightning approach, the model and the view are decoupled: your code doesn’t have to reach into the DOM. This leads to more robust and more maintainable code. Avoiding direct DOM manipulation is a best practice in the Lightning Component Framework (like in most modern frameworks), and you might just discover that you no longer need your DOM manipulation library.

UI Libraries

You may also want to reconsider the use of UI libraries like Bootstrap and jQuery UI. Although these libraries provide useful components, they have their own UI identity that can clash with the Lightning Experience identity. The Base Lightning Components and the Lightning Design System offer similar capabilities while providing a consistent user experience.

MVC Frameworks

At a high level, libraries like React and AngularJS have the same focus as the Lightning Component Framework: They provide code organization and utilities to create components. If you are looking for a component framework to develop applications on the Salesforce platform, you should use the Lightning Component Framework because it’s tightly integrated with the platform. But you can also use other frameworks if you so desire. All you have to do is choose the isolation mechanism (LockerService or Lightning Container Component) that works with your framework to avoid security exploits (see below).

Avoiding Security Exploits

To avoid security exploits, an application composition framework should provide the right level of isolation between components. For example, an untrusted component shouldn’t be able to gain access to the part of the DOM owned by another component. Without the right level of isolation, a vulnerability in one component can provide access to sensitive data in other components and jeopardize the security of the entire system. Just like breaking into one apartment would provide access to all the apartments in the building if each apartment didn’t have its own secured door. Each component you use in an application is an attack vector, and as a corollary, each library you use in any component is an attack vector as well. The Lightning Component Framework comes with two isolation mechanisms: LockerService and the Lightning Container Component (in Developer Preview in Spring ’17).

LockerService Isolation

LockerService is the primary and preferred isolation mechanism for the Lightning Component Framework. LockerService wraps standard objects like window, document, and element inside a secure version of these objects (SecureWindow, SecureDocument and SecureElement) as a way to control access to APIs and regions of the DOM. When components are loaded, they are provided with the secure wrappers (secureWindow and secureDocument) in lieu of the standard objects (window and document). When a component invokes a method on the document or window object, the secure wrapper can apply appropriate security restrictions. For example, access to the DOM of another component will be:

  • Granted if the other component is in the same namespace.
  • Denied if the other component is in a different namespace.

In addition to providing a sophisticated namespace-based access control mechanism, LockerService enforces a series of rules to further avoid security exploits:

  • JavaScript ES5 strict mode is automatically enabled. Libraries that do not support strict mode will not work with LockerService.
  • Content Security Policy (CSP). unsafe-eval and unsafe-inline are disallowed. Libraries using eval() or inline JavaScript code execution will not work with LockerService.

The rules enforced by LockerService are recognized as industry best practices. However some libraries may not yet work with these restrictions enabled. In that case, we recommend you ask the library author to support strict mode and CSP. In the meantime, you can use the alternative Lightning Container Component isolation described below.

LockerService Advantages

  • No iframe. Components live in the same DOM (better performance)
  • Straightforward, natural communication between components
  • Cohesive UI
  • Eliminates DOM scraping vulnerabilities
  • Mitigates the impact of developer mistakes such as the lack of proper escaping
  • Cross-site scripting (XSS) and template injection are no longer possible
  • Eliminate server-side action invocation/spoofing

LockerService Limitations

  • Non-compliant libraries will not work with LockerService

Here is a non- exhaustive list of libraries that are known to work with LockerService:

Library Version
React 0.14.8
ChartJS 2.1.4
D3 4.4.0
Leaflet 0.7.7 and 1.0.2
RxJS Latest as of 12/5/16
Numeral.js 2.1.4
Underscore.js 1.8.3
FullCalendar 3.1.0
Gauge.js 1.2.1
jQuery 2.2.2 and 2.2.4
jQuery UI 1.11.4
DataTables 1.10.12
Select2 4.0.3
Disclaimer: The versions above are known to work. We can’t make any guarantee about future versions of these libraries.

Lightning Container Component Isolation

The HTML Inline Frame Element <iframe> allows you to embed an HTML page in the current HTML page. The embedded HTML page is loaded in a different DOM (with limited access to the parent DOM) and runs in its own context. The Lightning Container Component (lightning:container) is a convenience component that wraps an iframe and provides a simple API to communicate between the iframe container and its content. The Lightning Container Component is in Developer Preview in Spring ’17. The Lightning Container Component can be used to sandbox components or apps built with libraries that don’t run with LockerService. For example, you can use a Lightning Container Component to embed an AngularJS app in a Lightning Component. Here is what it might look like:

<aura:component access="global" implements="flexipage:availableForAllPageTypes">
    <lightning:container aura:id="MyAngularApp"
                         src="{!$Resource.MyAngularApp + '/index.html'}"

The Lightning Container Component is not an optimal solution for fine grained application composition where you would embed multiple iframed AngularJS components on a page: In that case, each component would load the AngularJS framework, communication between components would be limited (postMessage only), and the UI would be constrained by the boundaries of each iframe.

Lightning Container Component Advantages

  • Native isolation mechanism in the browser
  • Support for any third-party library, including ones that are not LockerService compliant (libraries are sandboxed in their own DOM/context)
  • OK for coarse-grained apps

Lightning Container Component Limitations

  • Limited communication mechanism between components (postMessage)
  • Components are constrained to a rectangle area on the page. Content may be clipped, rich interactions like drag-and-drop between components may not work, etc.
  • Heavier/Slower. If there are multiple iframes on a page, each iframe loads its own version of libraries.
  • Not great for fine-grained app composition


Before you decide to use a third-party library in a Lightning Component, you should reevaluate if you really need that library. DOM manipulation libraries and UI libraries in particular may no longer be needed when working with the Lightning Component Framework.

LockerService is the preferred isolation mechanism and should be your first choice because it’s more tightly integrated: components run in the same DOM, resulting in a faster and more cohesive user experience. If your library doesn’t support LockerService, you can fall back to iframe-based isolation using the lightning:container component.

LockerService Lightning Container Component
iframe-based No Yes
Components are loaded in the same DOM Yes No
Supports all third-party libraries No. Only compliant libraries will work. Yes. Libraries are sandboxed in their own DOM/context.
Cohesive UI Components can grow and shrink. Surrounding DOM elements will reflow. Components are constrained by iframe boundaries
Inter-component communication Native LC communication postMessage
Performance Faster. All components are loaded in the same DOM. Slower/Heavier. Each iframed component has to load its dependencies.
Check out the LockerService and the Lightning Container Component documentation to learn more.
Follow @ccoenraets on Twitter.
tagged , , , , Bookmark the permalink. Trackbacks are closed, but you can post a comment.
  • released lightning components for communities with the release of WINTER 16. We based our contract renew and purchased more community licenses based on this, in January 2016. After this, we got to work building out a custom community using lighting components based on features that were released. We spent tens of thousands of dollars on development.

    Then after we were about 80% done with our solution. announced locker service during the Summer 16 release that had a huge impact lightning components for communities. (Two releases later) This broke a lot of our code since where were using Jquery and Bootstrap. I opened a case and we were told it was bug and there was no eta to fix it. As of February 1st, this bug still exists.

    Since then, I have asked to release a list 3rd party libraries, this hasn’t happened despite Salesforce having sessions at Dreamforce on the topic until now.

    Bottom line, locker service has been a complete nightmare for us. We couldn’t launch our solution last August. If the code wouldn’t run with locker service last August or today, we shouldn’t assume it will run in the future. I have tried working with your team and our developers with no success. I also think locker service is going to be a nightmare for developers in the future, as libraries are upgraded, they could or will break. Also, not supporting IE 11, which is 3rd most used browser is mistake. Users in highly regulated industries such as healthcare still use this browser and it’s hard to get them to just upgrade since their IT Environments are highly controlled.

    We have decided to abandoned salesforce as a result. We have lost tens of thousands of dollars on development costs and lost money due to not being able to launch our solution as planned. I have been a partner, developer and customer since 2004, and I am very disappointed having this forced upon us AFTER we did all this development. One of’s promises is future releases won’t break your code. That clearly isn’t the case here.

    • Doug Chasman

      Discussions around locker always seem to completely ignore that security is only part of the reason we’ve built it – just as critical is Supportability. “One of’s promises is future releases won’t break your code. That clearly isn’t the case here.” is exactly what locker is setting us up to be able to do with Lightning. The current sans locker world is a free for all of custom code reverse engineering the intimate internal details of components and functionality that it does not own. These implicit dependencies are inherently unsupportable – guaranteed to break when you least expect it to and there would be no recourse when it happens. Locker enforces those boundaries and because of that we now know just how often these unsupportable implicit dependencies have been made and its a large number. In addition, because these are no longer possible we are having conversations and making improvements to components to fill gaps where hack-a-rounds would historically been used. Those conversation simply were not happening with any reliability prior to locker.

    • Doug Chasman

      Discussions around locker always seem to completely ignore that security is only part of the reason we’ve built it – just as critical is Supportability. “One of’s promises is future releases won’t break your code. That clearly isn’t the case here.” is exactly what locker is setting us up to be able to do with Lightning. The current sans locker world is a free for all of custom code reverse engineering the intimate internal details of components and functionality that it does not own. These implicit dependencies are inherently unsupportable – guaranteed to break when you least expect it to and there would be no recourse when it happens. Locker enforces those boundaries and because of that we now know just how often these unsupportable implicit dependencies have been made and its a large number. In addition, because these are no longer possible we are having conversations and making improvements to components that would never have happened in the past.

      • batson456

        I would argue to the contrary. I have never forgotten or ignored why Locker Service exists. I do agree that security should be a chief concern, and I do not believe people have an issue with that. The issue is that developers and users are being handicapped by Locker Service. I feel like in an effort to provide a secure tool, you forgot to provide a functional tool in the process. Many of these third party libraries that are now not functional within Locker Service have been used reliably for many years and in thousands of applications without issue. The cost of rewriting some of these libraries to comply with Locker Service would be astronomical, and in some cases impossible. Even basic Javascript concepts and core pieces of the language are being broken and/or restricted by Locker Service.

        Security is essential, even at the cost of functionality to a point, but if the security comes at the cost of not even being able to use the tool at all, then, you have a problem. Its like having an unbreakable lock, without a key. No matter how secure it is, if you can’t get into it, its useless. Lightning components at this stage are pretty much unusable. They are clumsy, slow, and unnecessarily restrictive. After overseeing a large scale development project with Lightning components, the amount of hoops we had to jump through, and hacks we had to come up with, to make it comply with Locker Service made the code impossible to maintain. This was even after we scrapped some of our coolest features because they were impossible to make work within the confines of Locker Service. For future projects, I will probably just use AngularJS in Visualforce, or even just Vanilla Javascript. Its faster, more reliable, and more scalable. Personally, I had a lot of hope for Lightning components, but that hope has turned to despair and frustration.

        The issue here is not that you are trying to solve a problem with security, its that the solution is worse than the problem. Locker Service doesn’t help make our applications better, or more secure, or more maintainable; it makes them impossible to build.

        • Thank you! I totally agree with this!

          • Doug Chasman

            I also agree with most of what you are saying but believe that we are actually very close to solving this – the secure virtual DOM in Locker is in significantly better shape than it was back in August. Since November its been the case more often than not that code just works. CSP restrictions (not being able to reference external CDNs, unsafe eval/inline) are another level on top of Locker but not really a part of it (part of the overall Lightning Security architecture) that is often understandably conflated with it.

            We have a handful of open bugs on the svDOM at this point so either things are in good shape or issues are not being reported (there is steady traffic of questions so I do not believe its because everyone has given up). We have logged bugs/cases for every Stack Exchange post, Lightning Trailblazer’s post, etc for over a year now and we’re down to the bottom of the barrel on known issues that have not been fixed.

            I am asking for your help along with everyone else in the community to quantify and classify any issues you are seeing that have not been addressed in Spring’17 or at the very least tracked with a case.

            Can we classify the issues under the items below?

            – The svDOM is 100% solvable and so far we have not met a single issue we could not fix – and the influx of new (unique) issues has dropped of since November’s update to Locker.

            – How many libraries that you have wanted to use fail the strict mode requirement?

            – How many libraries have been ruled out because they must be accessed from a non Salesforce CDN (e.g. Google Recaptcha)? This is a CSP restriction and is not Locker – part of the larger Salesforce Security mandated changes. Locker does not care one bit where the code comes from.

            – Are the reasons the libraries you want to use have not worked “in locker” because of CSP restrictions that block use of unsafe-inline/eval?

            – Other reasons I have not listed?

        • Completely agree with this, we’ve a similar nightmare experience, like Jeremy or Bryce.

          We are building since July 16 a very large community composed of many lightning components. Beside that the development time has been way slower than what it could have been with Angular2, AngularJS, React, Aurelia…, we are currently losing weeks to refactor part of the application which is not working with LockerService. And we have even some blockers, such as the GPS or the Camera in HTML5, which are currently not supported, so we are just crossing fingers Salesforce will add this to the LockerService in the next 3 months, or we will just have to remove these functionalities from the community. That’s really a terrible experience we are doing with Lightning, the LockerService and that’s quite ironic to read LockerService is for a better stability.

          I trust that Salesforce, when implementing the LockerService wanted to make things “better”, but the reality:
          1. security: it’s arguably the same (or are you seriously trying to protect developers from themselves, that for one reason or another they cannot access the native Window object within their own org namespace!?). Let be honest, this is ridiculous, LockerService shall just be disabled for Components developed within the same Org. And the ones going through a Security Review, why shall they be restricted of anything, there was a review, right?
          2. stability: terrible. I hear the argument, the LockerService is actually more for the stability, than for the security. Well… every release, we have something which does not work anymore. And let’s not blame it to the LockerService itself which is not even active yet, but Lightning alone has some silent breaking changes. This happened to us in the Winter release and now again for the Spring one.
          3. we have feature which may never work again (GPS / Camera).

          I’ve been developing, architecting, etc. with Salesforce since more than 7 years now and I’ve never seen anything like that before. That’s really a catastrophe I wish Salesforce is going to fix one way or another… In the meantime I will hugely encourage any upcoming project we have to go with anything but lightning, for the sake of stability and development speed… VF + JS Remoting is the good old way to go for probably a long time yet.

          • Doug Chasman

            1. Security reviews are only performed on published packages which represent a tiny fraction of the packages on app exchange. I’m going to try and get some of our security folks to chime in here on this one as these requirements have come form outside of R&D.

            I do want to address the selective disabling suggestion and who we are trying to protect. It not developers from themselves its developers from other developers that work at different organizations, have a very real need know that their components’ internal bits are encapsulated and protected from implicit dependencies that make it impossible to not break things in a push update environment we all work in. Because the DOM is unfortunately completely lacking in encapsulation we’ve had to polyfill it and for this to work we all have to be working with a virtualized global namespace, DOM, etc. Shadow DOM looked like it might help but is not locked down or really supported enough to be leverage. The TC39 spec committee is working, with Salesforce leading the charge, on built in support for secure DOM that would someday make it possible to do exactly what you ask. Someday – like maybe 5-8 years from now.

            2. Yes, and what you may not realize is that a macro level (not necessarily your company) many of those breakages have been because of encapsulation breakages (implicit DOM dependencies, use of undocumented APIs, etc). There have also been a couple of unfortunate incompatible, non versioned API breakages (e.g. lightning:card in November) – but the company response to these demonstrates why having encapsulation and a well defined API contract is so critical: the offending team had to drop everything and eRelease a fix. Not so in the case of those scenarios where liberties were taken with the DOM structure – the response was very different in those cases (as in nothing was changed because no API was violated).

            3. I have ben unable to find a case, investigation, bug, or even a post on stack exchange for either GPS or camera related issues and locker. How have you let Salesforce know about your blockers? Is this another situation like Jeremy’s where the right people never even got a chance to make it right? Do you have a case ID so I can follow up and find out why this never made it to engineering so we could get it fixed for you (the locker team’s turnaround on things that need to be whitelisted has been very fast in almost all instances)?

          • 1. Understood, but this shall not apply for code developed within the own org namespace. And then, I’m still struggling to understand why such a complex framework need to be put in place for third party plugin: how dangerous may be a lightning code, compared to an apex code, which would run something like “delete [select id from Account]” or anything like that? Obviously the third party app has anyway access to the whole client DB through Apex… Much like when we build an Angular, React, etc. application we always add some “modules” to such applications from likely Github where it’s already been multiple times commented, peer-reviewed, etc. A similar concept would have been much more developer friendly.

            3. there is an issue (idea) reported here: The reason why Camera & GPS do not work is simply because window.navigator.geolocation / .mediaDevices are not accessible.

          • If we continued with the camera and gps issue would have been a problem for us as well. This issue has been asked about.


            I am not sure why you say the right people never got engaged. We were the first one to comment on this post by Raja Rao, (see the first comment by Ajay). – Again no reply.


            Also we tweeted about this issue to Raja and we got a reply to our tweet.


            We opened up a case (Case#13874035.) which they said reached your team in the case notes. (We are a premier customer support customer).

            We posted about the issue in the Success Community “Lightning Components for Communities”
            and it was tagged “Locker Service”. A salesforce employee tagged two other employees who never even looked at it. I even I tagged them as well.


            I also brought up the issue with many salesforce employees at Dreamforce and in the locker service sessions I was able to make. But the common theme was “I don’t know”

            Developing on Salesforce takes 10x longer and cost 10x as much as other platforms.

          • @dougchasman:disqus.

            In reviewing all my posts, We did engage with you. Andy asked you about a document being published about 3rd party libraries with Locker Service. Then I also asked about it, under our company name Medtexter. Again, no reply to something that would have been very useful.



          • Doug Chasman

            Yes that one certainly fell through the cracks and I apologize for not responding. There has been a fairly heated debate internally from the start about how Salesforce should or should not handle this certification business and I was not permitted to answer beyond “no comment” at the time. This blog is actually the start of finally acknowledging that we can’t ignore this and whether we like it or not are in that business. I know this is coming very late for you and many others but its a start and hopefully most will see this as moving in the right direction.

          • Doug Chasman

            These all look to be from quite some time ago and are issues that have all been fixed, correct? Also, the case you referenced was marked closed 6/16/2016 and the corresponding Investigation (the thing that gets created for R&D from a Case) went to the Lightning SDK team – not Locker – but we did pick this one up, worked with Caesar Adames from Tier 3 Support and this is the end of that interaction:


            As you can see as far as R&D was concerned the issue had been resolved and in a timely fashion.

          • Nope, it never got resolved. Support insistent on closing the case not us since there was no ETA on a fix.

            “Hi Jeremy
            I consulted my Tier3 on this and they confirmed that as R&D is not sure which funcUonality of the locker service is not working properly they sUll need to work on this bug to find a soluUon or workaround. As of now there is no ETA that can be provided on this bug.”

            I have no idea who Caesar Adames is.

            This support case costed us thousands of dollars in consulting dev costs.

          • Doug Chasman

            To continue the theme of Supportability:

            Another critical, long standing, real world, happens every day issue that locker addresses is global namespace collisions and implicit dependencies on javascript libraries being loaded by Salesforce or partners/ISVs or your own org.

            An excellent example of this is MomentJS – the Aura Framework that Lightning is based on uses MomentJS internally – a very specific version that we have changed many times (just updated it to the latest and added more plugins etc in Summer’17). There are 2 distinct issues that we were seeing on an almost daily basis before locker:

            – customer/partner/ISV authored javascript was directly depending on our version of moment – a resource that is not part of any API contract, can not only change at any time (we updated in at least 1 patch) but can and is likely to disappear entirely when you least expect it to! Guess what happened when we’ve updated? Multiple cases and the result was not that Salesforce had to make a change – the offending party in this scenario is the developer making that unsupported dependency.

            – customers/partners/ISVs trying to do the right thing, or even completely unaware of our or other organizations use of this library, happily created a static resource for momentjs, loaded with ltng:require – and crunch – one or both are broken beyond recall.

            Take a look at the lack of sophistication around this problem in moment’s own bug database – something that is unique to the multi author, push upgrade world that is Salesforce. You will see this common pattern in almost all libraries and frameworks.

            We have been seeing this for years and with greater frequency as we all start to leverage more and more javascript. Try loading Angular more than once in the same scope – even the same version (something that is currently 100% non orchestrated in Salesforce) and see what happens. Google for solutions to loading multiple versions of Angular and you will find a small number of hits with no real solution that would work in our situation. Again this lack of built in support for mutli version, repeated initialization is almost universally absent from every library or framework.

            The fact is we get cases at an ever increasing rate that track back to a root cause often as simple as global variables colliding between authors. Locker does away with this by virtualizing the global namespace – you get your own private scope and can be assured that a simple collision cannot break your functionality because its just not possible.

      • Doug, It absolutely breaks our code. We spend tens of thousands of dollars developing our solution, then TWO releases later you announce this locker service that breaks our code. Then we spend tens of thousands of dollars more trying to get locker service to work with our code, we open up cases with premium support, post in the success community, talk to our account rep, certified letters with no or very little response. If I would have known you were coming out with this locker service when we made the decision to use lighting in January of 2016, I would have never used lightning for this solution. Complete waste of time and money.

        • Doug Chasman

          Jeremy your company did not get support from the actual Locker team (unlike thousands of others we have directly helped with locker and non-locker issues alike) which is unfortunate. I was peronally only made aware of the challenges you faced yesterday as a result of your posts. I am working aggressively to find ways to make sure this does not happen again.

          Locker in some form was always in the plan for Lightning Components – the free for all that existed in the interim was not something that could continue but this planned security model was not socialized effectively.

          “If I would have known you were coming out with this locker service when we made the decision to use lighting in January of 2016, I would have never used lightning for this solution” – am I correct in saying that only unfettered access to the DOM (even the parts that can and do change all the time and will break you when they change with no recourse), no CSP, etc would have been deemed acceptable?

        • I think we did talk to the locker service team. My developer was the first person to ask a question on this blog post, he also exchanged some tweets and emails with Raja Roa. See the post from Ajay. They told us to open up a support case, so we did.

          New versions of the the js libraries you list don’t work. I see that as a on going problem for the future. Then there is the lack of support of IE 11, which is the 3rd most used web browser. Almost all our users at hospitals use this as the main browser.

          I have found that developing on takes 10x longer and costs 10x as much as other platforms.

  • mattlacey

    Regarding D3: The .attr() method on D3 selections fails with locker service enabled. Is there a workaround for this?

    Locker Service only really seems to be designed to deal with components that may come from an untrusted source. Anything that’s come through security review should be already marked as safe, and data security is enforced by the platform at any rate. Frankly having to jump through hoops and find cludgy hacks to use major parts of the JavaScript ecosystem doesn’t make any sense… there was a lot of promise with Lightning for developers and it’s failing to deliver. Unless you absolutely need to build something inside of the core platform I’d argue that building elsewhere and integrating is now preferable for a lot of use cases.

    • Doug Chasman

      @mattlacey:disqus please see my comment on @jeremywhiteley:disqus’s post above.

      “Frankly having to jump through hoops and find cludgy hacks to use major parts of the JavaScript ecosystem doesn’t make any sense” – I could not agree more but can we quantify this a bit given where things stand with locker in Spring’17? There are very few gaps in the secure virtual DOM that preclude the use of javascript from any author. Strict mode and CSP unsafe-inline/eval are the 2 main requirements that are set in stone and outside of locker’s control. Both of these are industry standards that modern and maintained libraries and frameworks either comply with or are in the process of supporting. We’ve recently (Spring’17 .9 patch deployed in the past few days) removed one of the last remaining non security/non supportability constraints (lack of instanceof support) that was there entirely as an artifact of the locker architecture.

      Locker is also the only thing making it possible for custom Lightning component to !== iframe per component (unit of custom rectangular UI region really) ala Visualforce. Same origin policy enforcement using browser domains and iframes would have been the world we’d be in – custom components as second class citizens at best is not what any of us want I hope.

      The fact is if we were releasing Visualforce today it would have the exact same Content Security Policy constraints placed on it that Lightning does.

      Bundle into this the supportability aspects in my comments above we cannot allow implicit dependencies on internal details of things you do not own or control. This is something that I hope makes sense to everyone – a classic can’t have your cake and eat it too scenario. If we want to continue to maintain the release over release “we don’t break your stuff” values that we all see as critical in an environment where push updates are a daily occurrence I see no other way to achieve this.

      On the D3 attr() issue I will get back to you – I believe this has already been fix in Summer’17 and is awaiting back port to a Spring’17 patch.