WEB PL AT FORM R EPOR T 2017
INTRO 3
LANGUAGES 12
WEB COMPONENT LIBRARIES 19
Which languages do people use for writing frontend?
Which web component libraries do you start with?
How do you write CSS?
Which web component collections do people use?
Experience
WEBDEV 13 - 14
POLYMER 20
Fun fact
Which desktop browsers do you target?
Who uses Polymer?
Which mobile browsers do you target?
What does Polymer do well?
COMPANIES 6
Top 9 browsers from Nov 2015 to Nov 2016
What do people dislike about Polymer?
Dev Experience
Responsive AppS
Retention
Reasons to build native apps instead of mobile web?
DEMOGRAPHICS 4 - 5
Who are they?
PROGRESSIVE WEB APPS 21 - 22
Who writes PWAs?
What PWA tech do people use?
Target
TESTS, PERFORMANCE, ACCESSIBILITY AND
SECURITY 15 - 16
Companies
Tests
What concerns do people have about web components?
Size
Perf, a11y, security
Frontend
Overall Importance
PROJECTS 7
PWA and Mobile
OTHER COMMENTS 23 - 25
What concerns do people have about web components?
TECH 8 - 9
How often do stacks change?
Decisions
Experience
FRONTEND LIBRARIES 10 - 11
Framework Use
jQuery
UI Library and Framework Use
WEB COMPONENTS 17 - 18
Other comments
Overall
What do people enjoy about developing with web
components?
Experience
At companies
Why web components?
How do people use web components?
What challenges do people face when using web
components?
Here are some interesting full comments
W EB COMP ON EN T S
In fall of 2016, teams from Vaadin, Polymer, and Skate worked
together to find out how people are using web components and
the web platform today.
Web components are a set of specifications for creating reusable
components with HTML, Javascript, and CSS. Web components are
built directly onto the web platform and allow for encapsulation
and interoperability of distinct components.
We designed this survey to gauge interest, expectations, and usage
of web components as they exist today. We believe that web
components are a modern, platform independent way of building
better web apps.
We hope this survey will help inform web components developers,
library owners, and even skeptics on who uses web components
and how they use them.
D EM OGRAPH IC S
Who are they?
In total we received
80%
7%
students
4%
architect
of respondents identified as
professional developers.
851 responses
from a range of companies large and
small, in addition to many students.
6%
hobbyists
Our respondents included:
8 designers
12 managers
10 other
•
•
•
Experience
30%
70%
of respondents reported having 20 or
more years of experience.
FUN FACT
Most used development tools of respondents
70%
50%
50%
50%
of respondents have been at their
current company for less than 2 years.
41%
Atom
38%
Sublime
38%
VS Code
Only 29 respondents said they use
Emacs.
CO M PAN IES
Dev Experience
Bigger companies have more experienced developers (80%
have more than 6 years of experience) compared to startups
(60% have more than 6 years of experience.)
Developers have more than 6 years of experience:
Large companies
80%
Startups
Retention
Larger companies have employees of greater tenure (56%
have been working there for 3 years or more) compared to
startups (35% have been working there for 3 years or more.)
60%
Developers have been working more than 3 years of
current company:
Large companies
56%
Definition: in this study, a startup is a company with
between 1 and 10 employees.
Startups
35%
P ROJ EC TS
Target
Size
There was a completely even split between people working
on internal apps, free public apps, and paid public apps.
Bigger companies tend to have more people working on
their project. (52% of respondents work on a team with more
than 5 people.) On the other hand, 83% of respondents at
smaller companies work on a project with 3 people or fewer.
Companies
36%
64%
At bigger companies, 45% of project take more than 60
person months.
36%
of projects
Bigger companies favor
internal apps
As smaller companies, most of their projects are less than 5
person months.
Frontend
25%
75%
of projects
75%
Smaller companies favor
public (free and paid) apps
80% of respondents say that frontend work is 50% or more
of their projects.
T ECH
How often do stacks change?
55%
of large companies change their frontend
stack only once every few years.
55%
of smaller companies change their
frontend stack at least once a year.
Decisions
In larger companies, most of the decision making comes from
above. Architects, tech lead, or manager make the stack decision
more than 65% of the time. In smaller companies, it’s less than
41% of the time.
NOTICE
•
•
•
Larger companies tend to care more about
aligning with the rest of their company.
Smaller companies tended to want to test new
technology.
All companies cared strongly about extensibility.
Experience
How was the frontend stack of your project chosen?
Why did you change stacks?
(851 responses)
(851 responses)
Wanted to test new technologies
I like to stay on the cutting edge
52.1%
Ease of use
45.6%
Aligned with my company's other projects
39.1%
Ease of extensibility
38.4%
Open source required
36.2%
Low cost
24.8%
Theming options
17.3%
Keeping up with competitors 10.1%
Commercial support available
7.4%
Other
7.4%
60.2%
Stack was no longer supported or maintained
30.7%
Too high a cost for teaching new people
19.7%
Promised features never appeared
14.6%
Changed to align with competitors’ offerings
11%
Acquisition uses a different stack
5.5%
Other
13.6%
F R ON TEN D LI BRA R IES
Frameworks
jQuery
Midsize companies use front-end frameworks about 80% of
the time, versus 70% for other companies.
Midsize companies use jQuery more (34% used jQuery) than
small companies (25% used jQuery) or large companies (28%
used jQuery.)
Front-end framework usage:
Midsize companies
jQuery usage:
Other companies
Midsize companies
34%
20%
80%
of the time
80%
70%
30%
VS
of the time
70%
Large companies
28%
Small companies
25%
UI Library and Framework Use
Which UI libraries do you use?
Which UI frameworks do you use?
(747 responses)
(823 responses)
Polymer Elements 57.8%
No framework
42.4%
Bootstrap 47.9%
jQuery
42.2%
jQuery UI 27.8%
Angular1
24.4%
Vaadin Elements 14.9%
React
21.5%
Foundation 6.8%
Angular2
16%
Semantic UI 2.5%
Backbone
7%
Kendo UI 2.1%
Ionic
Other 14.7%
6.3%
Knockout
4%
Ember JS
3.8%
Meteor
2.4%
Other
20%
L AN GUAG E S
Which languages do you use for writing
frontend?
How do you write CSS?
(850 responses)
(850 responses)
Plain Javascript
74.2%
Plain CSS
73.3%
ES2015 (ES6)
60.6%
Sass
44.1%
TypeScript
22.4%
Less
15.4%
Java
21.5%
Post-css
9.5%
PHP
20.%
CSS modules
6.6%
C#
11.9%
JSS (CSS in JS)
6.2%
Python
11.4%
Stylus
3.5%
Ruby
5.2%
Compass
2.1%
CoffeeScript
2.2%
Other
2.4%
Other
9.9%
W EB D EV
Which desktop browsers do you target?
Which mobile browsers do you target?
Top 9 browsers from Nov 2015 to Nov 2016
(851 responses)
(763 responses)
Source: gs.statcounter.com
Chrome
Chrome for Android
90%
Chrome
48.68%
Firefox
83.1%
iOS Safari
Safari
Safari
68.4%
Android Browser
32.4%
Firefox
8.24%
Edge
67.7%
Firefox Mobile
28.4%
UC Browser
7.56%
Internet Explorer 11
58.9%
Opera Mobile
9.7%
IE
6.91%
Opera
26.9%
Samsung Internet
Opera
Internet Explorer 10
Opera Mini
97.1%
24%
80.2%
9.2%
6.7%
13.17%
5.48%
Android
4.21%
Internet Explorer 9
10.7%
UC Browser for Android
4.8%
Samsung Internet
1.89%
Internet Explorer 8
Not a web project
2.5%
Edge
1.32%
Other
3.8%
Other
2.55%
4%
Not a web project
2.1%
Other
1.4%
Responsive Apps
Reasons to build native apps instead of mobile web?
(766 responses)
Performance
80% of respondents build responsive apps
(apps for more than one screen size.)
50.7%
Access to hardware
41.9%
9.3% want to build responsive apps, but
don’t.
None, I'm pleased with the mobile web
27.7%
App store - discoverability
26.6%
8.5% of respondents do not think responsive
design is necessary for their projects.
Offline functionality
25.3%
App store - monetization
23.1%
66% build for desktop, phone, and tablet.
Advanced graphics
20.8%
Push notifications
11% build for desktop and phone.
19.8%
Other
7.3%
T ES T S , P ER F O R MA N C E , ACC E S SI B I LI T Y A N D SE C U R I T Y
Tests
Perf, a11y, security
UI tests appear to be important,
but
of respondents said
Overall, performance is a greater concern than security,
which is more important that accessibility.
65%
they don’t do them.
Security, performance, a11y are all more important for public
apps than private
Other testing
Unit and manual
testing is done by
Public vs Private
70%
of respondents
Integration testing is slightly more important for
bigger companies.
Security
74%
67%
Performance
67%
54%
A11y
32%
17%
Public
Private
Overall Importance
Performance
Accessibility
Security
very important
60%
25%
65%
somewhat important
35%
45%
30%
5%
35%
5%
not important
of time
of time
of time
of time
of time
of time
of time
of time
of time
W EB COMP ON EN T S
Overall
Over
At companies
70%
of respondents say they have at least
tried using web components.
Launched with web components in cases:
Large companies
Experience
More experienced developers are more likely to use web
components.
50%
of developers with 10 years of
experience or more
have used web components for more than 1 year.
51%
Smaller companies
40%
Why web components?
How do people use web components?
(591 responses)
(579 responses)
The structure it brings to building our application
Entire app is built with Web Components
72.1%
Reduces code complexity
70.9%
Faster to develop with
64.3%
Ease of interoperability
57.5%
The quality of ready made components
45%
The number of ready made components
33.2%
I found a component I needed for my project
73.7%
Building simple widgets
53.7%
Layout is web component based
46.6%
Non-graphical web components, e.g. an ajax request
38%
Navigation is web component based component
36.8%
Used one or two small prebuilt components
27.5%
Advertisement
16.1%
1.6%
Other
Other
7.8%
5.4%
W EB COMP ON EN T LIBR A R IE S
Which web component libraries do you
start with?
Which web component collections do
people use?
(766 responses)
55%
of respondents who use web
components use Polymer
About 2% used Skate
Polymer Elements
83.2%
In-house developed set
51.5%
Google Web Components
41%
Vaadin Elements
23%
A-Frame
1.8%
About 2% used x-tag
Other
4%
What does Polymer do well?
P O LY M ER
documentation
quality
Encapsulation
easy
support
binding web use Syntactic
ready
material
create
Tooling Everything tools standards
nice
like
UI well
Makes ease other community build love
learn docs
etc
design
started
Who uses Polymer?
Polymer Elements seems to be used more at
larger companies versus smaller companies.
declarative
definition
API
data polyfills
pretty examples getting
really better things
lots
high big allows
layer sugaring
some
Bindings
js
boilerplate styling
library
component
creation
Provides
make structure
components
app
great framework
code
much
sugar syntax
project work
simple just
Google set write HTML
easier way lot made fast development close tutorials
CSS
awesome
native Using
platform
being Simplicity
Polymer
good catalog
element
all
Polycasts
Performance
databinding
custom
elements
Polymer usage:
Large companies
42%
Smaller companies
28%
What do people dislike about Polymer?
•
•
•
•
•
•
Data binding with structured data in 1.0 can be challenging
Community currently on the small-side
Confusion between Polymer-the-library vs the elements built by the Polymer team
Worry about adding a dependency to a web component
Difficulty getting started - high mental effort
Not enough docs - especially long form
P ROGR ESSI VE WE B A PPS
Who writes PWAs?
What PWA tech do people use?
(766 responses)
30%
of respondents say they have written a
progressive web app.
55%
of respondents have some knowledge of
PWAs, but have not yet written one.
SSL/S
70.9%
Websockets
59.3%
Service workers
Respondents working on free public apps are more
likely to build progressive web apps versus either
internal apps or paid public apps.
53.3%
HTTP2
43%
Web workers
Free public apps
38%
27.2%
Web push
21.3%
Internal apps
25%
Native hardware access
16.2%
Paid public apps
27%
PWA and Mobile
Reasons for writing a native mobile or progressive web
app does not depend on what kind of project it is
(private, public free/paid.)
Why might you prefer to write a mobile native
app instead of a mobile web app?
(766 responses)
Performance
50.7%
The main reasons someone might prefer to write a
native mobile app versus a progressive web app are
performance and hardware access.
Access to hardware
41.9%
None, I'm pleased with the mobile web
27.7%
App store - discoverability
26.6%
Offline functionality
25.3%
App store - monetization
23.1%
Advanced graphics
20.8%
Push notifications
19.8%
Other
7.3%
FR E EF OR M R E SP O N S E S
What concerns do people have about web components?
•
•
•
•
•
•
•
•
•
•
OTHER COMMENTS
Ubiquitous “browser support” comments.
Data binding seems like a big deal.
Learning resources could be better.
People who say they have
Styling/layout.
used web components wrote
1.5 times as many comments
Marketing is insufficient/makes a poor case.
as others.
Communication between components, chaining callbacks between components.
A handful of people are concerned about using forms with WC.
A bunch of people wanted “is” back.
Component upgrading / no-Javascript solutions.
People are vocal about HTML imports and others really dislike ES6
A handful of
responses
were written in
ALL CAPS.
What do people enjoy about
developing with web components?
modularity without
simple
reuse structure browser between
Isolation standard Interoperability
app
Separation
encapsulation
really
encapsulated each
fun
architecture apps
Use
data
fast
using
standards
just more
declarative working UI elements
API concerns
one project
all work brings
create
quality being
based
native time able
element across page build
good much modular
Simplicity different pieces
easy
complex extensibility built learn less features concept small
Composability
reusable close CSS
like
team
nice
great
application
other Speed
understand
DOM
HTML
reusability
custom
code building way integration
JavaScript
platform new
clean makes
framework
feels
performance functionality
everything
frameworks
development
component Web
community
Ease
What challenges do people face
when using web components?
web
browsers
polyfills HTML
element
sharing keep technology None styling
building
support
really Learning
issues
things
some
using management
polyfill documentation complex know
time
spec between binding dependencies angular
changing structure libraries flex native
JS use
like more
shadow
tag
VS
new
most people many
dom
IE performance different just code
CSS create need Lack design global difficult much
still
tooling
hard component work application any
think ES
great
having developers
all only
one version
other elements
components
Polymer
sometimes integration
custom challenge
change
frameworks
Browser
about
way
app
best
data
communication changes
functionality Progressive
compatibility especially
used react
often
Here are some interesting full comments:
Have a common use case "playground" with non-WC use
cases (e.g. form submission) alongside the same use
cases implemented with WC. This will help show the
differences in possible WC implementation and also
highlight gaps in the specs.
Web components should all have an isolated js context
with an api for exposing values between contexts. They
also need to integrate much better with js modules. The
problem is that what I *want* from web components is
not calendar widgets. Instead, I want marketing to be
able to expose to me a "recommended-products"
component that I could do a minimal amount of
configuration to and drop onto my page. In the current
implementation last I checked, I would have to carefully
manage all of *their* dependency tree. That means if
they use signalr and I use jquery 3, it will break their
signalR version unless I hack in manually a way of
providing a *separate* version to their component. This is
a huge problem that I’ve seen very little will to address.
I think, there will be the need for an other abstraction layer.
Because we're all going to build bricks (element,
components). With that we can build beautiful things. Use
bricks to build a house, an office, a tower, etc. But buildingcontractors need guidelines, need an architect who sketches
the building, makes the blue prints. Then you now which
elements you need, going to buy or create them by yourself.
And the architect need a lot of knowledge what there is on
the market and what the user needs / want.
As part of a bigger response:
As you may see, my approach is probably miles off of a lot of
other people. And I think that is the problem. Each person has
a different approach to web components, and while it makes
for brand new way forward, it feels there won't be enough
consensus to justify it's longevity. They seem to be competing
to be Angularjs, which I don't like