Lighter weight alternative?

[DavidWells]

It would appear that including this dependency is adding 496kb to our overall app size which is doubling our app size.

Is there a lighter weight version of this lib that doesn't include a copy of react + immutable etc?

Thanks!

[hzalaz]

There is no bundle of the lib without the copy of react and inmutable. You can bundle lock yourself along with your application to avoid having multiple copies of react or immutable. (or use auth0.js and build your own UI) We are thinking of a way to provide bundles without react so you are not forced to bundle Lock yourself.

[DavidWells]

Thanks for the reply :)

Are there any good examples of integrating just auth0.js (with Google + github + email) I can take a look at?

On Oct 28, 2016, at 1:36 PM, Hernan Zalazar notifications@github.com wrote:

There is no bundle of the lib without the copy of react and inmutable. You can bundle lock yourself along with your application to avoid having multiple copies of react or immutable. (or use auth0.js and build your own UI) We are thinking of a way to provide bundles without react so you are not forced to bundle Lock yourself.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[hzalaz]

Check our quickstarts: https://auth0.com/docs/quickstart/spa/vanillajs/02-custom-login

[theopak]

I'm a happy Auth0 Enterprise customer and I appreciate how much time Auth0 Lock saves me as well as the great user experience that it makes possible out of the box.

However, it's a big deal that auth0-lock is one of the largest dependencies in my React apps' entry points. I understand that it's possible to slightly reduce the footprint by bundling it from source during my apps' build processes, but I wonder why the size of this dependency's source is so large to begin with.

I just measured the pre-minified source of one of my apps using webpack visualizer, and this package is 524.1 kB! See image above. React and lodash are the only dependencies that take up more space (before minification and code splitting). Why is it so big?

Also, are the language dicts loaded synchronously by default? Can the distributed version defer the loading of those large text files until they're needed, if at all? For the majority of my use cases the app needs to support only 1 or 2 languages.

[glena]

The size of lock is the result of the amount of logic it has internally to support all the different uses cases it attempts to solve. We are working on finding a way to make it lighter by having a better understanding of its dependencies but from the src code point of view there is no easy way to accomplish that in the short term.

About the languages, only english is bundled by default. You can see that in the i18n directory:

Remember that you can always use plain auth0.js and build your own UI that targets to your specific needs instead of lock which takes cares of tons of different scenarios related to db, social and enterprise connections mixups with all the posible configurations they might have out of the box.

[theopak]

Thanks for the quick and thorough reply!

The size of lock is the result of the amount of logic it has internally to support all the different uses cases it attempts to solve.

That sounds perfectly reasonable. And again, the fact that Lock is so thoroughly design + implemented + tested around those complex use cases is one of the reasons that I like using it.

About the languages, only english is bundled by default.

Ah, I see. Thanks for pointing that out to me.

Remember that you can always use plain auth0.js and build your own UI that targets to your specific needs instead of lock which takes cares of tons of different scenarios related to db, social and enterprise connections mixups with all the posible configurations they might have out of the box.

Some of the use cases at our company where Auth0 really works for us involve using it for enterprisey stuff. We've avoided some headaches by simply dropping Lock.js in front of WordPress and MediaWiki installations. In those use cases, it's an explicit goal to keep everything as plain and un-customized as possible for security/compliance and maintainability reasons. Is there some kind of auth0-lock config option or a combination of alternate packages that would make it possible for me to speed up all our Lock.js instances by default?

I think this issue is related to https://github.com/auth0/lock/issues/113

[DavidWells]

I still think there are a bunch of ways this lib can be streamlined for improved performance.

A quick size win would be removing immutableJS. That would shave 57kb off the total size.

[hzalaz]

Yes but since the core is based on inmutable we need to add some of the features, which will probably reduce the savings, or use another approach internally that does not require such big library. We detected a couple of libraries we can move that when we sum them all will improve a bit the size of the bundle.

In the end, Lock is a big component that handles a lot of different scenarios, we'll try to provide a smaller bundle or at least provide some flavored bundles, if your use case is simple (e.g. only db and social). Also there is the auth0.js + custom UI route, if you are willing to spend some effort building your own UI, that will give you more control on how big the auth component is.

[DavidWells]

Thanks for the reply. We are planning on rolling our own to cut down on the size. Just need to get around to building it =P

Removing immutable.js and running tree-shaking on the build would probably give the package a pretty solid decrease.

For example 'password-sherif' includes all of underscore.js while only using a couple of its methods. Tree shaking via webpack2 or rollup would take care of a lot of the unused code being included.

I suppose this tree-shaking can be done in userland as well and will probably be what I try first to shrink this down.

[dcworldwide]

@DavidWells have you tried bundling with webpack 2 to measure the size benefits of tree shaking? My project is a month or 2 away from moving to wp2 unfortunately. But we would make that happen sooner if we could see a decent bundle size reduce of lock.

Good point about password-sheriff and underscore btw. Seems like a easy win.

[twgraham]

I guess another option would be changing from react to preact

[baptistemanson]

As auth0 is exposed only in commonjs format, it seems it is not tree-shakeable with webpack 2.

[luisrudge]

@baptistemanson yup. We're already using tree shaking, but it yielded little to no benefit when we added

[dcworldwide]

What about just making the deps on react and immutable peer deps or external deps? Would that solve the bundle size issue?

[luisrudge]

@dcworldwide no. https://github.com/auth0/lock/issues/113#issuecomment-292255745

[baptistemanson]

Implementing a custom set of screens seem complicated at this stage for us.

For tree shaking to kick in, one option would be to allow people to assemble a bit more what they wish to use, as well as exposing a es6 version of the plugin.

Devs more cautious about download times would be specifying a bit more the packages required for their usage, excluding Auth0LegacyAPIClient, i18n, mfa, or specific strategies if not needed in the particular project. I will never have facebook login on my entreprise project, but I still carry the weight of it.

It sounds to me this particular concern should be addressed, as for many the balance between value and cost make the apparent value of the lock not sufficient enough to commit.

[luisrudge]

@baptistemanson this was already addressed here: https://github.com/auth0/lock/issues/113#issuecomment-292255745