Forem: Binh Bui

Web Components statistics in 2017

Binh Bui — Mon, 30 Jul 2018 09:21:30 +0000

This article is the last story in the series "Testing 696 Web Components". The statistics in this article covers many topics: the number of components published on webcomponents.org, distribution of components based on its libraries, working and non-working components, and some more interesting stats.

Note: These statistics were yielded roughly a year ago. Some of them might become irrelevant in the current day.

300 elements in 3 months. That's an impressive number.

Let's break those numbers down:

Polymer consistently accounts for more than 90% of the published elements. It's evident that Polymer is dominating in the scene of web component libraries.
An impressive number of ~100 custom elements are published each month.
The most notable change here is the distribution of Polymer 1 and 2 components. Polymer 2 has a surge of 278 elements while Polymer 1 roughly stays the same.

Out of 696 tested elements, here is how many are functioning

Heads up! Every working component has its own live demo and screenshots for you to try in Vaadin Directory.

Browser Compatibility

Out of 489 working elements, here's how many that works in each browser:

Conclusion

Without any doubts, things have been revolving in favor of web components. More companies and technologies are betting on it. I hope you enjoy the series. If you have not read the previous two, here they are:

Article No Longer Available

If you have any question regarding testing web components, feel free to PM or send me an email. Thanks for reading!

For more news and writing pieces on Web Components, follow me on Twitter @binhbbbb
If you would like to try out Web Components, check out the series Web Components Wednesday, where I introduce and explain easy-to-use web components to beginners.

Top 5 obstacles I faced in testing 696 web components

Binh Bui — Thu, 26 Jul 2018 11:03:47 +0000

Image credit: thoughtsofascent

Following my last autobiography, I promised to post a story concerning the toughest barriers I faced during testing web components.

The fact is that, when the number of components reaches hundreds, there will be thousands of those obstacles you meet along the way. In this story, I will point out the 10 most common barriers.

No reliable content delivery network (CDN)

In short, CDN offers a fast, efficient and secure delivery of content to websites. To test remotely on sites like CodePen, JSFidde or JSBin, a reliable CDN is heavily needed.

Otherwise, you need to test it locally, which includes downloading the source code, installing the dependencies and serving the demo on the website (I say it's triple, if not more, the amount of work).

Import links for dependencies are inconsistent

Most of the times you will see the HTML imports are either

<link rel="import" href="../google-map/google-map.html">

<link rel="import href="bower_components/google-map/google-map.html">

So, which one is the correct way?

The answer is that they are both correct. When developing locally, bower_components is the folder that contains all of your dependencies. So it is logical to import codes from there, the problem comes when you want to make demos for example on CodePen, there is no bower_components folder because it's only installed locally.

How to make elements reusable through Bower #11

zenorocha posted on Mar 20, 2014

When we stopped to use the CDN and started to use Bower we had this default bower_components folder commited (which is now called lib).

We made this decision because we want people to be able to demonstrate their elements right from the gh-pages and debug them easily.

However this causes reusability problems. They cannot be shared with Bower and used by other apps.

View on GitHub

Polymer comes up with the relative path serving style to make online and local testing consistent. webcomponents.org CDN also behaves in a pretty similar way. So if you develop a web component using Polymer, always uses the relative path for imports and the command polymer serve for serving.

People usually forget to import the polyfill

Even though modern browsers are making progress in implementing Web Components standards, not all the technologies are natively supported. When I was testing, so far only Chrome & Opera supports Web Components natively. The rest of them provide partial support and usually need the polyfill, webcomponentsjs, to make web components function properly.

webcomponents / webcomponentsjs

A suite of polyfills supporting the HTML Web Components specs

🚨 Moved to `webcomponents/polyfills/packages/webcomponentsjs` 🚨

The webcomponents/webcomponentsjs repo has been migrated to packages/webcomponentsjs folder of the webcomponents/polyfills 🚝 monorepo.

We are actively working on migrating open Issues and PRs to the new repo. New Issues and PRs should be filed at webcomponents/polyfills.

View on GitHub

It's quite common that developers forget to import the polyfill in the demo. Hence, those samples will not work in any browsers except for Chrome or Opera.

No demo or documentation

I saw a lot of projects, getting published without a demo and a single word for how to use it. This is exceptionally careless considering the element was created with the author's own way of usage. Most of the time, I have to read the source code and figure out how to use it.

Naming convention is important

Even though not being official, it's always a good practice to name your main component the same name as your project's. For example, I've met cases where the primary element is named skeleton-layout.html, and the project is named good-component . Those projects leave me extremely confused.

Final word

"Testing a product is a learning process" - Brian Marick

The best thing about this journey is that I can learn the mistakes, which often go past the normal eyes, that people make. I have fun along the process, and will all the way again if given a chance.

Here is my last autobiography that I mentioned in the beginning, it’s a 4-min read. Feel free to check it out.

Article No Longer Available

If you have any question regarding testing web components, feel free to PM or send me an email.

For more news and writing pieces on Web Components, follow me on Twitter @binhbbbb
If you would like to try out Web Components, check out the series Web Components Wednesday, where I introduce and explain easy-to-use web components to beginners.

The story of a man who has tested 696 Web Components

Binh Bui — Fri, 20 Jul 2018 11:57:53 +0000

Image credit: DZone

“Do you know what Web Components is? How would you test hundreds of them?” — Sami Ekblad, my supervisor in our interview

That was the beginning of my journey to explore the world of web components. I, myself, was a 22-year-old IT student with no professional experience. And to make it even more interesting, that interview was the first time I heard the term “Web Components.”

Starting from zero

Things were rough in the beginning. No one in our company has done this task before, or anyone else publicly. There were no testing guidelines, no formats, no nothing. This was the scopes list I come up with:

Functionality: Is it working?
Design: How does it look?
Compatibility: Does it work on all platforms?

I begin by manually picking some from webcomponents.org and start testing them. Luckily, they feature JSFiddle demo (like this) for previewing components. The downside is that they are available only if the author provides the sample code. Nonetheless, those inline demos are the little sunshine! ☀️

To keep track of the records, I set up a spreadsheet. Everything was manual, the spreadsheet, the writing, and the testing. They were notably time-consuming, but my boss, he believes it’s the way to go before any automation takes place.

Automation kicks in. Well, not really!

With the discovery of webcomponents.org API, I managed to populate my spreadsheet with all the web components there, along with its author, description, etc. Python was my best friend during this time, it’s fast and convenient for making small scripts to work with the API and the spreadsheet. However, the reality kicks in, I still have to test the components manually.

Safari Tech Preview, Chrome Canary, Firefox Nightly, and Opera were the four browsers I used for testing the compatibility, mainly because Web Components standards are always implemented there first before the stable versions acquire them.

Testing requires patience

For the components that have demos, it was easy. You just copy and paste the Fiddle link to every browser to see if it works, right?

The answer is NO!

Let’s consider one person, who makes 5 web components, and each of them was made differently. Now multiply that one person by a hundred and there you go, hundreds of projects with fat-fingering and typos.

For the components that do not have demos, I need to understand what they are for, how they were created and how I should use them in order to write a sample code that works. It was a nightmare to deal with hundreds of code writing styles.

In the end, I’m not even sure if that component does not function because of the element or because of my code.

The result

As I become more familiar, things have processed much faster. I was able to analyze a component quickly.

After 5 months, I finally accumulated 696 tested elements (I will feature these statistics in another story).

“How did you do it?”

Well, the whole process was a trial and error. Experiencing is the answer.

“How do I feel after testing that much components?”

Tired but also proud, I did not have any prior experience to web components, testing or even coding before doing these. And the best thing about it? The records are public.

“Seriously, everything is public?”

Yes! Every working component that I have tested is included in Vaadin Directory. They come alone with a personal review and a demo sample, which I made in CodePen & JSFiddle.

Make sure you check it out!

Final word

“Am I the one who tested the most number of web components in the world?”

Maybe.

“Do I understand Web Components the best now?”

Definitely not, there are a lot of people who comprehend so much more of this beautiful standard, and I am merely a tester.

“What is the point of this story?”

It’s something I’ve been wanting to publish on Medium for a while now, I started testing one year ago. The journey was amazing to me, and I hope you might learn something from it.

Feel free to ask me anything regarding my journey or about Web Components. Thanks for reading!

For more news and writing pieces on Web Components, follow me on Twitter @binhbbbb
If you would like to try out Web Components, check out the series Web Components Wednesday, where I introduce and explain easy-to-use web components to beginners.

The emoji web components you never thought you need

Binh Bui — Tue, 17 Jul 2018 10:44:26 +0000

This July 17th, let us celebrate the World Emoji Day by looking at some of the coolest emoji web components by notwaldorf, our Emoji Ambassador 👩🏻‍✈️

🌧 emoji-rain 🌧

This funky component is gonna pour down a heavy rain of emojis. It's mesmerizing, colorful and beaujiful (Get it?).

Source code ◆ Demo ◆ CodePen

📚 emoji-selector 📚

emoji-selector features a large set of emojis. It provides users with a "Recently Used" windows, like how it is in most smartphone keyboard, and this is extremely handy if you're a ❤️ or 🔥 spammer.

Source code ◆ Demo ◆ CodePen

✨ emojillate ✨

emoji + pixellate = emojillate - It translates any picture to full-text of emojis, so you can even share it with people by simple copy & paste. Check out the CodePen demo for a surprise.

Source code ◆ Demo ◆ CodePen

For more news and writing pieces on Web Components, follow me on Twitter @binhbbbb
If you would like to try out Web Components, check out the series Web Components Wednesday, where I introduce and explain easy-to-use web components to beginners.

How to use the Google Map Web Component

Binh Bui — Wed, 11 Jul 2018 10:33:32 +0000

Everybody uses Google Map, or at least the people I know. It's handy, ubiquitous and accurate (most of the time). In order to integrate Google Map to your site, you need to have a good knowledge of the Maps JavaScript API. Now, with the invention of Web Components, this is all you need for a nice window of Google Map:

<google-map api-key="AIzaSyD3E1D9b-Z7ekrT3tbhl_dy8DCXuIuDDRc"></google-map>

The result:

Too good to be true? That's Web Components for ya 😉 Let's look at some more examples on how to utilize this powerful web component.

Displaying the marker and the poly in Google Map

The google-map web component also provides some other useful sub-elements to use with:

google-map-directions: provides the Directions API service.
google-map-marker: provides a map marker. It is used as a child of google-map.
google-map-point: provides a map point. It can be used as a child of all google-map-*.
google-map-poly: displays a series of connected lines segments. It is used inside google-map and needs at least two google-map-point.
google-map-search: provides the Places API functionalities.

For example, here's how you would use a marker (click HTML to show the code):

As you can see from the code, a longitude and a latitude value are needed for the marker. You may include as many markers in a single map as possible, the attribute fit-to-markers makes sure that all of them are in the view. Well, it does not function in my demo.

What is the difference between a google-map-point and a google-map-marker? A marker can be displayed directly inside google-map and draggable, while a point is fixed and can be only used as children of google-map-*, such as google-map-poly:

I couldn't succeed in making google-map-directions and google-map-search work, the same things happened several months ago when I first tried these. Feel free to check out and fork the pen here:

google-map-directions: https://codepen.io/vaadin/pen/NBPbVQ
google-map-search: https://codepen.io/vaadin/pen/mjyRXZ

And if you got it working, please leave a comment below to teach me :)

Final words

With the invention of Web Components, things might have gone two steps easier for developers to integrate technology like Google Map in a website. And the best thing about Web Components is that in a few years, all of its standards will be available in every browser natively.

For more news and writing pieces on Web Components, follow me on Twitter @binhbbbb
If you would like to try out Web Components, check out the series Web Components Wednesday, where I introduce and explain easy-to-use web components to beginners.

Comparison table of 5 datepicker web components

Binh Bui — Wed, 04 Jul 2018 11:51:54 +0000

I usually tested web components in my free time. This time, I tested some datepicker components and figured out I should make a short comparison table. The comparison includes some features, as well as, indicates which browser they are functioning properly (Chrome, Safari, Opera, Firefox, Edge, IE11). Mobile testing was performed on iPhone X.

There is also a more detailed blog version of these five datepicker components.

If you like this kind of blog, share or comment so I will make more of those in the future.

name	Mobile	I18n	Arrow Keys	Library	Working
calendar-element	✔	✔	✔	Polymer#^2.0.0	C,S,O,F,E,I
range-datepicker	✔	✔	✘	Polymer#^2.0.0	C,S,O
app-datepicker	✘	✔	✘	Polymer#1.9 - 2	C,S,O,F,E,I
vaadin-date-picker	✔	✔	✔	Polymer#^2.0.0	C,S,O,F,E,I
mp-calendar	✔	✔	✘	Polymer#^2.0.0	C,S,O,F,E

Upgrade to Polymer 3 or LitElement?

Binh Bui — Thu, 24 May 2018 11:03:29 +0000

From Roadmap update, part 2: FAQ, Polymer team states:

• For new projects, we suggest that you use LitElement (and if your project is an app, PWA Starter Kit, which incorporates LitElement).

• We recommend that you update existing apps and elements to use Polymer 3.0.

What is your opinion about this? I know that converting a big application is not easy so is it worth it, or can you survive with Polymer 2?

Forem: Binh Bui

Web Components statistics in 2017

300 elements in 3 months. That's an impressive number.

Out of 696 tested elements, here is how many are functioning

Browser Compatibility

Conclusion

Article No Longer Available

Article No Longer Available

Top 5 obstacles I faced in testing 696 web components

Image credit: thoughtsofascent

No reliable content delivery network (CDN)

Import links for dependencies are inconsistent

How to make elements reusable through Bower #11

People usually forget to import the polyfill

webcomponents / webcomponentsjs

A suite of polyfills supporting the HTML Web Components specs

🚨 Moved to webcomponents/polyfills/packages/webcomponentsjs 🚨

No demo or documentation

Naming convention is important

Final word

Article No Longer Available

The story of a man who has tested 696 Web Components

Image credit: DZone

Starting from zero

Automation kicks in. Well, not really!

Testing requires patience

The result

Final word

The emoji web components you never thought you need

🌧 emoji-rain 🌧

📚 emoji-selector 📚

✨ emojillate ✨

How to use the Google Map Web Component

Displaying the marker and the poly in Google Map

Final words

Comparison table of 5 datepicker web components

Upgrade to Polymer 3 or LitElement?

🚨 Moved to `webcomponents/polyfills/packages/webcomponentsjs` 🚨