The “OTHER” JavaScript Framework

Originally posted on https://lightningforjsdevelopers.com/the-other-javascript-framework/

As a web developer you’ll have heard the buzz of Angular (1, 2 and 4), React, Vue.js and others. But there’s another JavaScript framework that’s revolutionizing a platform for thousands of developers in a whole new way…

Lightning

Now I know that Salesforce often has a bad reputation among developers outside of its eco-system- Just check out the Stack Overflow 2017 for Most Dreaded Tech!

I was voting that way too a few years ago! However I hadn’t really dived into Salesforce to appreciate the complexity and problems they’re solving.

So please stick with me for this, even if you’re not interested or a fan of Salesforce! There’s a lot that can be taken from what Lightning is doing.

Angular vs React vs Vue vs Lightning

As a developer when I look at these frameworks from a high level, I see 4 different ways to solve similar problems. Reduce boilerplate code by providing a pattern to bind data to a view and add logic to handle user interactions in the view (excuse the Massive simplification here – I know they all offer a lot more features like Routing, eventing, etc, but again these are all to reduce boilerplate code that developers would have had to write themselves in vanilla JS).

So in what way is Lightning different to Angular, React and Vue?

There is one key problem that Lightning is trying to solve that the others don’t.

It’s a problem that other companies and frameworks have attempted solve in the past, but many did not succeed or stand the test of time:

Interactive components from unknown developers living and interacting on the same page without breaking each other and introducing security holes

Think back to the days of My Yahoo, iGoogle and Netvibes, customizable dashboards with gadgets and widgets from anyone and everyone.

• iGoogle

• Netvibes

• My Yahoo

A brief aside as to how I see and use Salesforce. The Salesforce platform is an eco-system whereby companies can quickly build applications on top of a number of builtin features. At Vlocity we’re enabling governments, telco’s and insurance companies to revolutionize their call centers and client facing account management screens quickly and easily. The reason we’re able to turnaround applications so fast is that we can ship re-usable processes on top of Salesforce that match with the common flows that we see in these industries.

One major challenge is how do you sandbox all these widgets from each other? How do I stop the CSS in that widget from BadHaxxor from messing with mine? Or how do I use DOM api’s in my widget when they’re locked down?

In the past the main solution to a lot of these problems has been to cram it in an iframe and do what you want in there. But that raises major performance problems and doesn’t necessarily solve all the Security problems either.

However, Locker Service in Lightning is a promising solution to this!

🙁 Locker Service

Even a brief mention of Locker Service is enough to cause a riot at a Salesforce meetup. People despise it! Check out the comments on this Blog Post from Salesforce earlier this year – LockerService and Lightning Container Component: Securely Using Third-Party Libraries in Lightning Components

I’ve picked out some choice rage for you!

Locker Service doesn’t help make our applications better, or more secure, or more maintainable; it makes them impossible to build.> 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. This has been a complete waste of time and money.> It seems you are doing impossible things with fragile backbone. There is no standard spec which asserts the Locker security always works as you expected. Bringing own DOM spec without ANY conformance test is the attempt of breaking the web, bringing fragmentations. The efforts from bad idea always will be in bad end. It is the time to reconsider the direction.

Clearly some people aren’t happy here! But in all honesty Locker Service is a very cool piece of Technology!

🙂 Locker Service

I’ve come around since first hearing and playing with it. It’s solving a very immediate need I’ve seen in a number of places and it’s Open Source!

Personally I think the way it solves the problem is great. Here’s a quick overview:

1. Enforce Strict Mode on all JS code… That’s not an unreasonable request
2. Enforce Content Security Policy rules on all components… Again that’s a smart idea:

• CSP helps to mitgate cross-site-scripting attacks by ensuring all resources (css, scripts, images, etc) come from a known domain (or set of domains).
• In addition one rule used by Lightning is to prevent the use of eval() or Function constructors

3. All JavaScript code is loaded into Locker Service into a safe Sandbox that injects proxies for global objects like Window, Document, Element, etc
4. All CSS rules for you component must be prefixed with .THIS which will be replaced at runtime with your a unique classname applied to your component

• This ensures your CSS rules aren’t written with selectors that affect anyone else’s components.

So what does this mean?

Your component is safe from my component. I won’t mess it for you… Lightning promises I won’t! Who wouldn’t want that?

However the downsides are you can’t use any old JavaScript library from the internet because:

• They may not work in a CSP environment
• They may try access DOM elements outside of your component:
  • If they use a DOM api like document.querySelectorAll() then it won’t work. If it’s a UI component you’re using then it’s best to submit a patch to the developers to get it working without that api
• CSS files with some JS libraries won’t work out of the box
  • You’ll need to modify them to support the .THIS prefix and embed them in the component itself

What’s next?

This is just a brief intro to Lightning and the main problem it’s trying to solve. I also wanted to shed light on some of the restrictions and limitations with Locker Service. There’s a lot of FUD around it which isn’t justified!

Lightning is a great JavaScript framework – it includes core features like Data Binding, Expressions, Events and Routing. It also supports some great features like Interfaces and Abstract Components that only come with languages like TypeScript (… ok it may look like a weird way to write an interface but it works great!). However when comparing with Angular, React, Vue and other popular JavaScript frameworks, it’s important to remember that one of the core problems that Lightning is really trying to solve is very different from those other frameworks.

I highly recommend checking out the Trailheads from Salesforce to learn more:

• Lightning Components Basics
• Lightning Components Developer Guide

Head to https://lightningforjsdevelopers.com for more Lightning tips and tricks.