The Deep Dive — JavaScript Widget

How to design, build and deploy a JavaScript Widget that runs on other people’s websites

“two gray pencils on yellow surface” by Joanna Kosinska on Unsplash


JavaScript is having web for lunch nowadays. That is “none of your business”! Or “Good for your business”. Either way, if having a good understanding on how to design, code or refactor, deploy and maintain a JavaScript SDK is your objective, please help yourself and read-on!


Before you jump into third party widget business, make sure you are making the right decision. You may not even need one.

  • Widgets are ubiquitous these days, and found everywhere the browser is functional. In server side NodeJS world, they are known as SDKs!
  • They are the building blocks of most browser plugins, customer support extensions, and embedded chat services, to name a few.

I put together this write up from frustration for not finding the right documentation on why and how to design and deploy a widget, an extension to my service’s offerings.

This blog post is under constant editing. You may bookmark it and return to it later. You can checkout on other blog posts in The Deep Dive series.

Use Cases

Widget delivered services examples that can be brought to your attention include, but not limited to

  • Get Site Control ~ This service offers various functionalities to existing websites via ready to use plugins. You can find Chat, Contact US, Leads etc.


Here is the list of most commonly asked questions about JavaScript widgets:

  • What is the difference between a plugin, a widget and an SDK?
  • Why — Why should you have a JavaScript widget, a.k.a widget, as an extension to your application.
  • UX — Managing Steps — using HTML List tag with CSS pseudo-classes for a better navigation feedback — Strategies to minimize controls without killing UX — How to reduce dependencies — the use case: finding alternatives of date picker, scrollbars etc — Reducing redundancy of prev/next and next step in same footer
  • Research — Which libraries may I consider to design my next widget. In other words, why you should consider hyperapp for your next widget.
  • Development — Adopting IIFE and HyperApp— Passing Settings Parameters to the application — Passing SDK API key via JavaScript loader
  • Production — What options do I have to distribute my widget — rolling out your own or adopting an existing CDN.
  • How to change the Look and feel of a Select HTML tag — this QA have more details.


Without which came first, UX or UI, let’s focus on usability. That will include the best time to add the widget on a web page, when to trigger it, how the UI can be optimized to better server customers needs.


There is a saying in tech community “Don’t re-invent the wheel”. Well except when you are NASA. Jokes aside, there are libraries that can allow to build the widget a little faster, with a small footprint. Here goes the list of some of them:

  • fetch — fetch is not a library but a browser native API. It is possible to establish communication on servers that are not under the same origin. The mechanisms is called CORS and the new fetch API is really an extension to Ajax paradigm, but on any host. There are a wide range of browsers that support this new API. Depending on your use case, you can easily forget all those customers on old browsers and focus on those who are really savvy. Not really, there is a polyfill for the library, but it is increases significantly the size of your application
Polyfill is a library that implement a feature that is not yet available in a given browser
  • hyperapp — there is always a need to minimize the JavaScript footprint, by delegating UI creation to a library that can do better. It used to be jQuery. Things changed since then, with an ever growing web, there is no limitation when it comes to where your widget can be deployed. Nevertheless, the footprint is, and should always be, hallmark. As we speak, hyperapp is 1kb gzipped. Which gives you a possibility to make UI and add business logic under 2kb gzipped and minified.
  • picostyle — CSS in JS yuk … I know what you are thinking. But seriously, if you want your widget to require one line of code, you should be willing to go extra mile. In this case, adding your CSS to JavaScript. Not the way you are thinking … in a controlled way. Picostyle marries well with hyperapp and comes as 1kb gzipped and minified.
  • parcel — this is not another tiny library. But it is a seriously big deal of a bundler out there. The reason I suggest it, is it has near to 0 learning curve, zero configuration, basically plug and play.
  • Testing — you can use testing stack you already use for your ES6 projects. Or can go with Jest — the React friendly testing stack can get you going a bit faster.
# in package.json's script section - following construct is enough
{ "test": "jest --coverage --no-cache"}
  • Workflow — Most modern JavaScript projects adheres to following events right after there is a change in development files: The tests execution starts, then the build task bundle and minify files, last but not least a task hot-reloads browsers for manual/visual testing
# in package.json's script section
"build" : "parcel build index.js -d build/"


You may find the following link useful. They helped a lot to put together this write-up. If you are curious, you may pay them a visit.


In this installment, we talked about reasons why to include JavaScript widget in your product offerings. We also showed how to get started, and how to measure value the widget is adding to your existing applications.