At a recent conference talk (sorry, I forget which one), there was a quick example of poor web performance in the form of a third-party widget. The example showed a site that installed the widget in order to add a “email us” button fixed to the bottom right of the viewport. Not even a live-chat widget — just an email thing. It weighed in at something like 470KB, which is straight bananas.
Just in case you are someone who feels trapped into using a ten-ton widget because you aren’t yet sure how to replicate the same functionality, I’ve prepared a small chunk of HTML for you.
It’s 602 Bytes, or about 1/10th of 1% of the size of that other widget — with nothing to download, parse or render block.
See the Pen
Mailto Fixed Postion Widget by Chris Coyier (@chriscoyier)
on CodePen.
Perhaps on your own site, you’d move the styles out to your stylesheet and add in some hover and focus styles.
It’s not that third-party JavaScript has to be bad. It just has a habit of being bad.
My friend Richard showed me a new product he built called Surfacer. It’s like an RSS widget that you can put anywhere.
See the Pen
Surfacer by Chris Coyier (@chriscoyier)
on CodePen.
That’s a 773 Byte JavaScript file that does a 3.5KB Ajax request for data, and you’d place it at the end of the document to avoid any render-blocking. It would be nice to see more of this kind of thing.
Cool. Please tell me more about widgets vrs. apps. I’m sorry, I’m a newbie but a fast , eager learner. Thank you! Diane Diamond
Hey Diane,
In this context of this article, I’m using the word “widget” to describe some arbitrary code that another service is asking you to put onto your site to add functionality.
Everyone has heard of Facebook, right? And those little Facebook “like” buttons that you might find on other sites that aren’t Facebook? You might think of that little button as a “widget”. I’m not sure there is an official definition of widget but that’s how I’m using it here.
Man…I have this argument with a junior dev on my team all the time. I assign task/define requirements and his first stop is npm. His argument is always “why reinvent the wheel?”. Well maybe that wheel you found came off a rolling dumpster fire. He’s got coding chops but I fear the instinct to always look for a pre built solution is stunting his growth as a dev. Then again I’m much closer to 40 than 20 and remember days of having to write everything from scratch. Us old guys used to have our own personal libraries we carried around like bag full of nerd badge pride.
On the other hand I’m not sure if you’d be much happier if he was insisting on writing everything himself. Checking for existing solutions is a good way to avoid a lot of unnecessary development and maintenance work. Obviously there are limits… dropping in a 500kB “email us” button widget is ridiculous.
Hahaha. I think you have given me good advice. I will start to write my own code more. These days I have also been avoiding coming up with my own logic thinking there is already written logic out there which I just have to import. I think its negatively affecting my growth as a dev too.
Your fears are justified. I’ve made silly mistakes because I was too accustomed to a plugin, I’ve also had conversations with very senior level devs (team leads, VPs) who literally have no working knowledge of how common UI components work because they’ve always used plugins. (Modals are a good example.)
Whenever I get into this conversation, I make these points:
– Open source means we can read the source code, not maintain it. We can only code around a plugin or copy it.
– Accountability: The plugin’s author has literally no contractual obligation to support us in most cases.
– Licensing: Could our company be sued for using this? Is it copyleft?
– Needs: Do we actually NEED to do everything this plugin does? Again, we still have to maintain around it.
– Bloat: We need to send the extra code over the network to the user’s device. That has financial costs to both our company and the user.
– Aesthetic consistency: Lack of consistency in the UI hurts the app’s credibility.
– Programatic consistency: Does it fit with our application structure? Would a new dev know how to approach it and what to expect, or is it a ball of exceptions to the norm?
If a dev insists on heavy use of third party tools, the last point you could make is that “tools that help you build things are good (React, Angular, Lodash), tools that build things for you are bad.”
You can also argue that the “wheel” has been re-invented many many times. That’s why tractor wheels don’t fit on roller skates, so the original metaphor was never true to begin with.
Hi Chris,
really interesting. Could you explain how something that simple could get to 470k?
Thanks
Those widgets could:
* load one animation from a full animation js library with 100 animations.
* load one style from a css file that contains 100 styles.
* have 100 extra features you don’t use but still loads all the assets for it.
A software widget is a relatively simple and easy-to-use software application or component made for one or more different software platforms. A desk accessory or applet is an example of a simple, stand-alone user interface, in contrast with a more complex application such as a spreadsheet or word processor.
This seems like it would be a good parallel discussion to use-cases of relying on a library or framework for one or two specific features. Like using jQuery because you want access to
$.ajax()or including Bootstrap in all of your projects so you can use their Carousel component.I’m not as well-versed with JavaScript as I would like to be… but when I encounter cases where the 3rd party library either doesn’t do the one specific thing I need, or does far too much, I generally use it as an opportunity to write something on my own. Doesn’t always work, but it’s a good way to learn.