I never heard so much enthusiasm for it
so here we go
so as Paris said in Thank You Paris
my name is Jeremy Wagner I am a web
performance consultant and a sort of
general web tinkerer and I'd love to
thank the organizers for such a great
opportunity and for you for your
willingness to come to a talk called
make it boring at a JavaScript
conference so okay turn on presenter
remote I'm an adult okay so this talk is
the live version of an opinion piece
that I wrote earlier this year by the
same name so if you've read that post
you probably already know what you're
getting into and before warned there's
not much actual code in this talk so
like the post it's based on it's kind of
this melange of thoughts and
philosophies and opinions so if you're
like as they close the doors if you are
like you know I really kind of just want
to like maybe see something Cody the HP
track has an awesome talk by Simeon on
on Chrome extensions but if you're here
cool I won't be offended but thank you
for chilling out any in any case I hope
you like it okay so I think we have a
little echo on this mic okay I
originally wanted to open this talk with
a boring story or anecdote but that
would be boring so instead I'll kick
things off and talk about an exciting
thing and how that exciting thing ended
up being so risky and destructive that
it wiped out trillions of dollars of
wealth most of you probably remember the
subprime mortgage crisis which played
out between 2007 and 2008 before I
continue I'd like to assure you that
this is a talk about web development not
finance the subprime mortgage crisis was
an entirely avoidable economic
catastrophe that began with the creation
of the mortgage-backed security exciting
right the mortgage-backed security is a
financial product backed by home
mortgages it was created long before the
crisis ever occurred
and a big chunk of home loans get
bundled up into this product which
investment banks then offer to investors
it's generally considered a very safe
investment most people don't default on
their loans this limits the risk
so while returns are relatively modest
they're dependable seems pretty boring
so far right here's where it gets
exciting when Congress deregulated
Investment Banking in the 90s investment
banks got all ginned up the lack of
proper regulations allowed banks to
offer high-risk subprime mortgage loans
and sometimes even these disgusting
interest-only loans and then on the
investment side came credit default
swaps where investors could bet against
the US housing market effectively
rooting for and ultimately profiting
from the downfall of the US economy and
that's exactly what happened as the Fed
raised interest rates in an attempt to
cool things down
adjustable rate subprime loans adjusted
accordingly which spurred defaults on a
massive scale and then markets tanked
taking the economy with them all because
investing wasn't risky or exciting
enough already this is a perfect example
to me of when boring would have been
preferable to exciting
if markets and banks had been properly
regulated and yielded boringly
predictable returns things would be
different today people would have been
set who were set to retire would have
been able to at that time instead of
having to rebuild their portfolios some
people would have been able to keep
their homes and just as an aside and
it's a total aside this is why ethics
and regulations are critical because
just because you can fleece someone for
everything they've got doesn't mean you
should if it sounds like I'm drawing a
parallel between the state of modern
development and this kind of crisis it's
because I am but I acknowledge that we
are not hurtling toward a comparable
crisis with even remotely similar
consequences but we are headed towards
something and the trend doesn't look so
great and part of the reason why this
trend persists at least I believe is
because we're not operating with
sensible defaults and more and more web
development has become more like
software engineering in some respects I
believe this is a welcome in logical
progression but I do sometimes wonder in
the dead of night if we're ready for all
the responsibilities that that entails
because rather than evaluating each
individual projects requirements and
adapting our choice of tools to them we
tend to dive into right into what makes
development exciting and fun for us so
to that end what do we do when we start
a new project we npm install a preferred
framework and then we might install a
client-side router for that framework
and then maybe even a state management
library for the framework of course and
before you know it a project has started
with an amount of overhead that's baked
in until you decide to migrate away from
it somehow your preference for what
makes development more exciting or
perhaps I should say more convenient or
comfortable has forced you to make
trade-offs that could make your apps
lower less accessible and less usable
when it comes to software development
there's a word that I think is really
important and that word is constraints
think of your favorite video games from
your childhood most Super Nintendo games
of the time could fit on a 1 megabyte
cartridge sometimes even in a quarter of
that size this point has been done to
death I know but it endures because it
demonstrates how much can be done with
so very little yet I don't think it
fully acknowledges that the constraints
game developers faced at the time we're
far more fixed than ours are now so when
developers make console games they knew
every consumer had the same hardware
those were the constraints and they were
very predictable our constraints however
make our job uniquely difficult people
access the web on a variety of devices
with wide ranging capabilities such as
this affordable but slow moto G for
Android phone and this is to say nothing
of the varying quality of the networks
these devices access the web through
this is a reality which requires us to
make architectural choice
is that our best for people because
while our tools are convenient and they
help us to be productive they do
sometimes confer an external cost on
users that we must acknowledge and
redress in some capacity this is
relevant because for example here in the
US while many people live in large
cities which are typically well served
by fast broadband and mobile internet
connections there are gaps even
sometimes chasms in this coverage that
we must be mindful of this 2016 article
by the MIT Technology Review revealed
that 58% of the households in the
cleveland metro area with yearly income
under $20,000 had no broadband internet
access these are people who rely on
mobile internet connections often with
data caps and overages to access the web
internet access is not a luxury it's a
right and more striking as this passage
in which Pew Research found that
one-third of Americans don't have an
internet connection in their homes
faster than dial-up I sincerely doubt
this is significantly improved since the
article was written the economic and
infrastructural challenges have not been
sufficiently addressed to broaden
broadband access in these areas and to
me this is a compelling reason to make
things boring again I can empathize with
wanting to make web development exciting
it's a big reason why I started doing
this stuff in the first place and when I
started I wanted to do everything my
first experience with making webpages
was in a WYSIWYG editor in middle school
and once I hit the limits of what that
thing could do I had a novel thought
which was hey the hell happens when I
opened this here index dot HTM in a
notepad that thought clearly changed my
life for the better I think it's fair to
say that I wouldn't be standing here in
the stage if I hadn't done that everyone
in our industry has an origin story and
for many of us that story begins with
the making of the fanpage for whatever
thing we were obsessed with at the time
and for me that obsession was fixed on
the just fixed on the popular
first-person shooters of the day like
doom and hexan and quake and the ops
itself was irrelevant but but it gave me
an excuse to propel myself down a path
of relentless and sometimes reckless
experimentation I wanted to do
everything everything I mean everything
I wanted to put every last bit of new
knowledge I quite I acquired about
making webpages to work right away and
in the most glaringly obnoxious way
possible apparently yeah that's that's
mine don't go look for it and in my
fervor I was inspired to make countless
garish sites with horrid color schemes
crappy animated gifs guest books that no
one ever signed what web rings that no
one ever joined and then there was flash
Oh flash three iterations of my personal
website were crappy to advanced
knockoffs where cosmetics and flashy
animations won out over literally any
kind of sensibility and like anyone my
inspiration was just a conduit through
which I developed my skillset but what I
didn't develop for the longest time was
discipline I didn't understand basic
design principles accessibility
performance user experience or literally
anything that would help me to make
websites anyone would want to use and
that's not to say that my excitement for
the medium or our excitement for the
medium is ill motivated I was just
inexperienced but the work that we're
paid to do requires us to build boringly
useable things sometimes that work is
the equivalent of creating digital push
brooms they're ordinary as hell but yes
there are also tools that help people
accomplish tasks online banking job
applications buying essentials for the
home you name it
when our excitement for building for the
web is coupled with our thirst for
pushing it to do more all the time we
can inadvertently build heavy unusable
things that can hinder rather than
enable people to complete the tasks our
work enables them to achieve and so to
that end many new developers these days
aren't entering the industry with a
decade of learning and experimentation
under their belts or even a four-year
degree boot camps are a big thing
they're people who are both new to and
really excited about building
stuff for the web and making a living
from that work and we need these people
among us they're going to be the next
generation of developers that brings
renewed fervor to this industry and I
can't wait to see what they do but this
isn't an experience that I can speak to
as my path was so radically different I
didn't join a web developer boot camp
and make a living off of my skills
within a year I had ten years of
unfettered experimentation before I
could make anything that anyone would
want to use or consider usable it takes
time and continuing education to develop
these sensibilities and because
employers favor skill sets that
prioritize the fastest way of building
applications that means they're going to
hire people who know today's frameworks
and so the fastest way to start getting
paid after you graduate from boot camp
is to apply for jobs that match the
framework based skills they taught you
in boot camp
thus hiring in the industry has become
an Ouroboros where employers want
applicants with framework specifics
centered skillsets and consequently
developers learn those frameworks to get
gigs because hiring managers want to
tick off the boxes and get devs to ship
code fast and often and so in this
seemingly infinite loop frameworks
become the scaffolding upon which we
build our careers this isn't the worst
thing that can happen framework and
library specific knowledge can propel
you to learn their underpinnings I would
never would have went as deeply into
JavaScript as I have if not for the
awesomeness that was jQuery in the late
2000s but I believe that a sole reliance
on these abstractions can eventually
become a limiting factor in your
long-term growth and unless your
curriculum sufficiently covers the
fundamentals or you've had to learn them
on your own you'll always be reliant on
the abstractions to do the work
front-end development has been this way
for about a decade more so read the
resume of any veteran front-end
developer and you'll quickly see that it
resembles like a geologic column of
different skills this industry has
always chased what's so hot right now
and we're set up from day one of our
careers to feed into that arguably the
worst part of this is that our
continuing education in HTML CSS and
platform API is gets relegated to some
day or worse after hours where you have
to sacrifice some amount of work-life
balance just to keep up and by the way
not everyone has the time to devote in
their off hours to do that work they
have families they have responsibilities
in my opinion we shouldn't compel them
to but rather enable them to explore and
learn on the job and all of this is
ostensibly done in the name of
productivity sometimes at our own peril
this constant churn as Rachel Andrew
suggests in this very brilliant post I
suggest you read has us bound to a cycle
of never-ending site rebuilds and
framework migrations that can seem
counterproductive in hindsight and so
without careful consideration for which
abstractions are truly beneficial for
the purpose you're trying to serve being
lashed to this wheel becomes a brutal
affair where progress becomes difficult
to sustain over the long term
whether it was jQuery then or react now
these tools are designed to make us more
productive and they do blood if we were
pressed to admit it this constant churn
is at least in part due to our desire to
make our work more fun and exciting and
it's something I like to call laptop
sticker culture something will can't see
it from here but something I'm clearly
guilty of where everything we do
outwardly appears badass or glamorous
and if I didn't know any better I'd
swear some of us are on tour it's also
why even in the year of our Lord 2019
you still see job postings every so
often with with these superlatives like
rock star guru or ninja like am I
supposed to pack some shuriken z' with
my laptop like but hey hey why shouldn't
our work be more fun and exciting a lot
of career fields are boring Drudge work
shouldn't be shouldn't it be more
exciting right we're all propelled by
our interests
and for you that interest could be
JavaScript and friends could be HTML
could be CSS or it could be the various
abstractions of these technologies but
if you could for a second put aside your
interests and ask yourself what what's
the purpose you're trying to serve when
you build something for the web
what are you helping people to
accomplish the varying answers we give
to that question should form a curve
around which we adjust our philosophy
for how we build for the web because if
you're in charge of any remotely
critical resource on the web your desire
for a rich developer experience simply
must take a backseat to the task people
depend on the web for more than just
buying the web is a portal for many
critical resources stuff like job
applications public assistance crisis
intervention and other services we tend
not to think about until we need them
ours is a job done by people for people
plumbers might get excited about PEX
piping but they also understand that
their job is to ensure that the water
gets from the main to the faucet the
same as before
PEX pipe confers a material improvement
for both installers and end-users
without hampering functionality can we
consistently say the same thing about
all the conveniences that we rely on
data flows through pipes of sorts but
the environmental constraints imposed on
us by the network and the devices people
use demand our most careful
consideration factors like network
bandwidth and latency are quite evident
but others such as server protocol or
device capabilities are a little more
subtle and then there's the person
holding the phone or tablet or sitting
behind a laptop each of which is an
individual case study of capabilities
and limitations that demand our
attention and so knowing this I think
it's important we avoid one assumption
like the plague which is that our
conveniences always confer equal
benefits for users your enthusiasm for
virtual Dom frameworks probably doesn't
benefit someone who's been thrown out of
their home by an abusive partner when
they turn to the web to find shelter
someone trying to find public
assistance information or apply for a
job on spotty Wi-Fi isn't helped by your
client-side router somewhat arts are
conveniences have a time in a place and
that time is not always every time nor
is that place always everywhere and I'm
not shaming anyone here for their choice
of tools I use I use tools I love them
but to stress that simply using them
won't do the difficult work of design
and user experience for you and so as
developers our ethical Duty isn't
limited to identifying and removing
excesses in code we also need to
challenge excesses which may look nice
and design comps but only serve to
frustrate people in practice excesses in
design and development are necessarily
intertwined every interaction you can
simplify every boondoggle you can remove
represents a benefit for the end-user so
let's make it boring the web is
frustrating when it creates obstacles
for people an obtrusiveness in websites
are the result of every project manager
designer and developer unwilling or most
of the time unable to question
ill-conceived business requirements
design decisions or architectural
decisions or architectural choices it's
on all of us and josh clark wrote an
article about design systems a while
back and what struck me was his emphasis
on the role of boring in UX I'd be lying
if if I said I wasn't inspired by you
know this talk wasn't inspired by this a
little bit he discussed how when he
helped his clients to create design
systems he stressed the importance of
simplicity and I quote the more common
the problem the better design systems
should prioritize the mundane and in a
world where everyone feels like they
just want to disrupt without it
considering the consequences this is
sage advice and for me it's a kind of
revitalizing tonic avoiding
obtrusiveness in design is the very soul
of designs that work best for people
without acknowledging that we can only
create fast accessible and usable
websites entirely by accident a perfect
ample of obtrusive design was a
little-known visualization project
developed by Apple's research division
called hot sauce which was an attempt at
visualizing site maps for websites
instead of presenting this data in a
very straightforward way it was
presented as a 3d spatial field to its
credit hot sauce was a novel
presentation of this data it was neat it
was a fun experiment but no one wanted
to browse a spatial rendering of a
website's hierarchy as if they were on
the holodeck they wanted a boringly
predictable and utilitarian way to
access that information an unordered
list may be examples of obtrusive design
as they exist on the web are a little
different
I don't know about you I don't even like
one hamburger menu let alone three of
them it's not excitement that produces
patterns like this I don't think maybe I
god I hope not
but a sort of unwillingness or inability
to address the unsustainable growth of
an application over time eminently
usable designs and architectures result
when simplicity is the default it's one
of the iron laws it's why unstyled HTML
just works it so beautifully solves the
problem of presenting documents to the
screen that we don't consider all of the
careful thought that went into its jaw
achingly boring presentation now I'm not
holding a torch aloft and in marshalling
the Village People and demand that we
transport ourselves back to the
aesthetics of 1994 that would just
that's absurd and it's antithetical to
the spirit of progress but I do think
that this ideal is something that we can
carry on in our daily work especially
when more websites are consumed as web
apps we can make apps more resilient by
adhering to semantics platform solutions
and progressive enhancement and as it
stands we're accustomed to serving heaps
of div burgers on silver platters of
JavaScript that not everyone can access
in all the places they may need to
accessibility advocates aren't lecturing
you and screaming at you to use semantic
HTML because it's Joe
like so much fun you'll pass out but
because it's well understood how people
benefit from it the built-in
functionality you get from those
semantics allows you to travel lighter
as you won't need to build or install
accessible alternatives does this mean
your choice of tools are in direct
opposition to the goal of creating good
user experiences and depends depends on
how you use those tools it at least
requires us to understand the trade-offs
we might be making if we choose to use
them so we need to bifurcate our focus
on what we learn we should learn
frameworks and abstractions yes but we
also need to learn the platform api's
that server that serve as their
foundation so that we can adapt more
nimbly as the wind shifts the long-term
health of the web cannot be sustained if
we ignore what the web platform brings
to the table solely for our own
convenience and underscoring the
importance of those fundamentals is the
fact that we're wired to want things to
be boringly predictable
we not only want it we expect it and
subconsciously demand it so when things
are predictable they embody the expected
qualities of the essential we don't want
any surprises with the planes landing
gear as we come in for a landing
that is not excitement I can get behind
this is an example of a critical fixture
and some of what we preside over as
developers are also critical fixtures of
a sort these fixtures especially need to
remain fast and accessible part of
getting there necessarily involves
relying more on HTML CSS and platform
api's to reduce overhead and if your
reaction to what I'm saying is to assert
that this is boring work that will
create boring websites that users will
find boring then I must viciously retort
with the emergence of reader mode
features that exist in several browsers
at its core reader mode is just a boring
mode toggle that strips away scripts and
styles to distill a page down to its
core content people are so tired of
grass
playing with stuttering script Laden
pages that they'll gladly strip away
everything exciting to get to that
crucial nugget of content more easily
still reader mode won't work everywhere
and we shouldn't expect it to its
intended application for is for written
content like articles not rich
applications solving human problems does
require a human touch after all and so
to that end we are wired as human beings
to want external consistency which is
when an object's function and
recognizable appearance is reinforced by
other similar implementations in the
environment imagine a house with zero
external consistency we're turning on
turning the knob on the stove changes
the television channel or flipping the
lights which flushes the toilet
and as Eric Bailey notes in an article
on a list apart and I highly recommend
you read this and follow him he is an
excellent person in the accessibility
field browsers themselves are flush with
examples of external consistency and we
would do well to ensure that we don't
break those externally consistent
behaviors now I am fully aware of the
danger of saying this on stage at a
JavaScript conference so hold your
tomatoes for a second but one of the
most common subversions of external
consistency in browsers is the single
page application or s.p.a my personal
inclination is to avoid building sites
as SBA's this isn't because I hate them
or I don't understand how they work or I
think they're filthy filthy dirty awful
things it's just that the behavior they
replace is one that browsers already do
very well when we decide to take on the
task of implementing that ourselves we
are taking on a lot of unnecessary
responsibilities and risks in many cases
how browsers navigate from page to page
is part of a specification arrive to
after a deliberative process of debate
and consensus and continual improvement
and in my opinion it takes a whole lot
of courage with just a dash of hubris to
assume we can do this better than
browsers have done in 25 or so years
and when a client-side router is used
accessibility can become a casualty in
that effort there's a whole host of
things we end up reinventing or miss
altogether or shift beneath us as things
change history must be managed tabindex
and scrolling position must be accounted
for navigation cancelling can fail and
so on even if we get client-side routing
just perfect there's another problem we
have to grapple with which is when we
neglect to send server generated markup
in favor of rendering everything on the
client an app's contents are not only
inaccessible if and when when by the way
JavaScript fails but loading performance
suffers as well when we serve content
from the server sure we lose that
snappiness after the initial load I will
concede that gladly but we retain that
external consistency that people respect
or expect sorry that's not to say that
we can never use client-side routers if
you provide server-side versions of all
your client-side routes people will have
a way to access your site from literally
any context whether it's a link from the
outside or an internal link and then if
components are attached to server side
markup through client side hydration
people are going to get a progressively
enhanced experience that gives us
freedom a lot of freedom to try
different things perhaps only the
authenticated part of your app as an SP
a or and I like this and I've been
experimenting with it a little
perhaps client-side routing could be
opted into as an app setting ensuring it
only happens if people want it to where
we make no assumptions which brings me
to my final point and the end of my talk
no tool or any amount of automation will
ever be a perfect substitute for a
human's judgement which is a which is
finely honed over years of experience
solving human problems and solving human
problems necessarily requires that you
accept that humans have limitations
either inherent or imposed it also
requires you to accept that the tools
you use can fail you in some ways
and your judgment is necessary in those
situations now let me tell you another
story
this is stanislav petrov he was a
lieutenant colonel in the soviet air
forces during a dangerously tense period
of the Cold War while he was on duty in
1983 a brand-new Soviet missile
detection system reported that five
nuclear missiles were launched by the
United States and on the way to Russia
through a reason and no small amount of
intuition he was convinced that the
system was wrong in the moment he
concluded that five missiles was
illogical because the us strike would
have been all-out so he did not inform
his superiors and therefore a
retaliatory strike was never authorized
he turned out to be right the system was
wrong
turned out to be sunlight reflecting on
some clouds of both North Dakota that
triggered the false positive so while
we'll never know all the factors at play
of the various levels of command in this
situation it is not unreasonable to
speculate that his decision to
disbelieve the tools at his disposal
when the time came for it may have
averted a global nuclear war obviously
no JavaScript engine here in this room
will ever be charged with such a
perilous decision I hope not let's hope
that javascript isn't the mechanism on
which that operates but I think it is a
great lesson about how the tools we
depend on can still get things wrong if
that was if that wasn't the case every
github issues page would be a ghost town
zero issues zero pr's a million stars
for everyone yay so it is on us to
realize and own up to our responsibility
to people as well as how our preferences
as developers and the needs of real
people can intersect in a way that's
mutually beneficial and knowing where
that intersection lies involves
realizing that while an accessibility
inspector can tell you what semantic
elements you should use knowing why
those elements are preferable to a div
soup is just as vital
it's also realizing that y-you could
install a layout framework such problems
are best solved by relatively new and
widely supported CSS layout modes such
as flexbox and grid
in fact if you want to create layouts
that catch the eye and push the
boundaries beyond the ordinary you need
to rely on these new layout modes
you can't keep kicking that bootstrap
can down the road people because not
only is the overhead of bootstrap
ownerís it's just not where the web is
is destined to go nor will it allow you
access to the full power of these new
layout modes there are people called UI
engineers hire them for all of my
whinging about the evils of JavaScript
and all the simple excitement it and its
framework brethren brain I firmly
believe it has its place this is not a
diatribe against JavaScript
I believe javascript is great it's given
a lot of us a living and I'm thankful
for that but we do need to rebalance our
use of it against other parts of the web
platform javascript is most resilient
when we can use it with progressive
enhancement in mind that's to say when
we can build a baseline everyone
benefits from and then add that
candy-coating to enhance usability
further for those who can benefit from
it we're not just building better user
experiences but more inclusive ones and
that to me is the really good work
that's worth doing because inclusivity
is not something we should just make
room for at conferences it needs to be a
part of our daily work if you care about
the web as I know you all do because if
you're here you definitely care you'll
come to find out that this approach to
our work isn't boring at all but really
quite rewarding we have two objectives
as developers one work to make things
better this week than they were last
week and to continue our education to
ensure the success of the first
objective I genuinely truly believe our
work can never be boring so long as it
helps us deliver on these objectives in
the spirit of making the web faster more
accessible and therefore more usable
for everyone every where thank you
[Applause]
[Music]