Thoughts on a Browser version?

[abritinthebay]

I'm using Call to create an isomorphic Router for code that will run on Hapi - Hoek pulls in several things (and has several features) that aren't really required for most Browser usage.

Any objection to me submitting a PR for adding a browser build (including in the package.json) for things like Browserify that minimizes the code for a front-end build?

[nlf]

So long as it's easy for me to maintain for future releases, I'm open to a PR adding a browser build

[abritinthebay]

It would basically involve making the core code a little more modular and then just have simple browser shims for things that weren't required (possibly in separate files)

A simple example would be - add a browser directive in the package.json that tells browserify not to pull in the Crypto lib (as none of that should be happening in the browser because.. oh god that's a bad idea).

But it may be possible to have a few other wins (like smaller browser only shims for some functionality in path or util) and the maintenance should be minimal - worst case scenario would be that browser functionality would lag behind server side, which isn't too bad.

I'd have a vested interest in keeping it up to date too ;)

[jeffbski]

Yes, I was thinking the same thing. I know the Crypto lib is huge in the browser, so that would be nice to eliminate that. Joi uses Hoek, so any wins we have in Hoek will also benefit Joi.

[abritinthebay]

Once my work project that spawned all this is over (next week or two) I'll be able to open a PR on this.

[jeffbski]

In my experiment, simply stubbing out crypto in package.json shaved off 82KB gzipped from original size.

"browser": {
    "crypto": false
  }

I was building Joi which included Hoek. I documented in this comment hapijs/joi#528 (comment)

[jeffbski]

I think crypto was only used in one place to create a random file name which probably doesn't even apply for browsers. This might be all that we need to do. Simply add the exclusion in package.json.

[abritinthebay]

Yeah, that's the major case. It's the single biggest difference at least.

[arb]

It might be worth shimming in Node util as well. Especially since all that Hoek uses is inherits and format.

[jeffbski]

I pushed a branch on my fork with this change for anyone that wants to try it out. Original is 96KB (gzipped), so it cuts out 82KB (gzipped) resulting in a browser size of 14KB (gzipped).

https://github.com/jeffbski/hoek/tree/browser

You can easily test this from a project using

browserify -r hoek -s Hoek -i | tee hoek.js | uglifyjs - -c warnings=false -m | tee hoek.min.js | gzip > hoek.min.js.gz

Try with normal hoek, then try npm i jeffbski/hoek#browser to see the reduced version.

[johnbrett]

@abritinthebay did you ever make progress on the isomorphic Router? Would like to see the code if there is any :)

[abritinthebay]

I did! The first version is live on BleacherReport.com atm - thought it's mostly in a "beta" form atm. Not published it as OSS yet tho....

[johnbrett]

Cool! Let me know if you ever do publish it! :)

[nlf]

per outmoded/hapi-contrib#67 (comment) closing this

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.