字幕表 動画を再生する
Make Web Not War - Dominik Kundel
Welcome back, this is obviously the last talk before we get to go and have a snack, so try
to keep that energy level high.
Give your attention to the next speaker.
Dominik Kundel, he's a developer evangelist at Twilio, but there must be something pretty
magical in the water where he grew up, because when he started high school he was the shortest
person in his class and he's now 6-5 so they've doing something really well.
So everybody please give it up for Dominik Kundel.
>> All right, hi everyone.
Thanks to coming to my talk.
Like I know everyone is saying that, but maybe it's because I'm like an inch taller but this
is super-bright.
The slides are uploaded on that URL if you want to follow along.
I want to kick things off with a kind of important message, and that's that you're all wasting
your time learning frameworks, because we got web APIs and we have web components and
other things and there is really no need for any kind of frameworks.
But before I'm getting kicked off stage, I know this statement is not 100% true and the
story is much more complex, but I think I got everyone's attention now, and I got an
excuse to use the confetti animation in Keynote, so that's great.
So I'm Dominik, I work as a developer evangelist at Twilio.
We have a bunch of different APIs that allow you to send and receive SMS, doing phone calls,
video and a bunch of other things.
And I'm also a React developer.
I love building with React.
It's a great framework for a lot of the things I build.
I'm also an Angular developer.
I love using web components because I think there's a like a good use case for them.
I build things for the front end and the back end, and I love playing around with hardware,
as well, so I'm a hardware developer, as well, but if people ask, I describe myself as a
JavaScript developer, because all of the things that I talked about, I see much more frameworks
and libraries as tools, rather than anything else, and tools are here to solve problems,
and these problems might change over time, you know, based on my team, based on the project,
based on the time that like overall that I have for the project and that gets me back
to the statement that you're wasting time learning frameworks, because while I don't
believe t I think it was a got generalizer to get your attention and we've probably all
heard that you're wasting your time learning X because Y is faster or Y is better just
generally because I saw some benchmark saying that or it's just because Y is more popular
and I see it more often on my Twitter feed.
So I wanted to go back and talk about why we have frameworks in the first place, and
this is to solve problems.
As I said, any framework or tool is ultimately there to solve a specific problem, and if
you don't believe me, I wanted to go back in history and kind of talk about a couple
of things from the the web development history and the tools how they've developed over time,
and note that I'll be talking about a couple of things, but those are definitely not all
of them, and like there's more things that evolved over time, but those are some things
I personally interacted with, so I felt most connected to those.
And so I want to start off with JQuery.
I think we've all interacted at one time with JQuery regardless of how long you've been
doing web development and I want to figure out like why does JQuery exist in the first
place.
It's actually pretty easy to figure out because if we go to the website there is literally
a section called what is JQuery and it's an easy to use API that works across a multitude
of browsers and that might seem normal these days where we require everything to just work
in every browser, but in 2006, when JQuery was released, we were in the middle of the
browser wars, Firefox 2 was just released.
Internet explorer 7 was just released and according to Wired it was not as standards
compliant as people hoped for.
Chrome was not yet on the market and there were a couple of others, like Camino, Flock
and browser were some of the ones: If you were not sure why that seemed to be a problem,
this is how you had to attach an event in 2006.
You had to check if add event listener actually exists, because that didn't exist in Internet
Explorer, but hey, thet attach event.
And so JQuery gave you a way to actually set an event handler.
And similarly if you wanted to do a web request you had to check if you were in IE6 and get
an add object and you had to write all this boilerplate and AJAX streamlined that process
for you and so with better access to the DOM, we ended up building more applications that
are UI-heavy from a JavaScript perspective.
So to share and build reusable components, like date pickers accordions and other things
so you can build them into your application and so we all jumped on that and kind of started
building more complex user interfaces for the browser and so our need for tools to structure
more complex applications grew.
And so we got tools like backbone that literally focused on giving your application structure
to introduce models and views and things like that.
But at the same time, people didn't feel really comfortable that basically all of our document
structure moved into JavaScript and so some people wanted to go back to a more declarative
way of describing UIs rather than declarative through JavaScript.
Which created frameworks like Angular JS which focused on extending the HTML vocabulary rather
than having to write a bunch of JavaScript statements and as our codebases grew we needed
to have ways to handle that.
Concatenating JavaScript files was not the best use case anymore and so we came up with
module syntax like requireJS or bundlers.
And as people kept on developing those solutions and platforms developed, our problems kept
on changing and new frameworks and tools showed up, so by now, we got flooded with different
frameworks that could handle different use cases and so I think the important thing to
keep in mind here is all of these tools were created because people had problems and wanted
to find a way to solve these problems.
They got together with others and built these solutions.
But building a framework is very much more of a life cycle, so while some, you know,
gain mainstream popularity, others often kind of stay as like niche solutions and additionally
to that, we often have some that just disappear over time for various reasons.
For example, JQuery kind of went out of the spotlight, because we moved into standards
that solved exactly these problems, so we have query selector and add event listener
now to solve a lot of the common DOM accessing problems and we have tools like fetch that
don't require us to use Ajax anymore to have a kind of cross-platform thing.
But while standards might solve a problem, I also have to disappoint you, because if
your favorite solution gets standardized, it doesn't necessarily mean it gets standardized
the same way, because it standardization is hard and it has to take into consideration
a lot of different aspects, because it has to solve the problem for everyone and not
just a share of folks.
And the best way is with the extensible web manifesto.
It's a manifesto that was written by a bunch of folks that were involved with standardizing
web browser features and it focuses on four key concepts.
The first one is it focuses on adding new low-level capabilities to build the web platform
that are secure and efficient.
So what that means is if we look at things like webGL, for example, or features like
-- now, I have a hanger, oh, WebAssembly.
If you look at WebAssembly or webGL, those are very low-level things that we can build
tools on top of, like A frame or 3GS to use them, but they should also explain existing
features, so that's a good example for things like the Houdini API, or the web component
spec, because they explain how the browser already handles CSS or introduces new components,
and so it just exposes those to the outside, and then the other two are key, in my opinion,
for us to help browsers standardize things.
The first one is to create a constant virtuous cycle of feedback, so this is very important
because it shows sort of in some standards like the web component spec why it took so
long because developers were not eager to try new things and so the browser vendors
doesn't get any feedback on standardizing this this and the other thing is they were
focusing on prioritizing efforts and deprioritizing others, which again falls into the same thing.
If we want something to come and we want to have an impact, we need to try these things
as soon as there's polyfills and things like that.
But if you want to learn about how the standardization process, you want to check out the talk from
Monica Dinculescu of how the sausage gets made from 2017.
It's also a great talk to learn more about the extensible manifesto.
The other thing is if something is standardized, it might not actually look the same way.
So we already saw the example of AJAX turning into the fetch command so that it better integrates
with the ecosystem and is more future-proof.
The other thing is things like RequireJS and CommonJS
took kind of the asynchronous aspect of RequireJS and a couple of other concepts to merge them
into something that made sense for the browser and ultimately for the ecosystem.
One common one that I hear about at least on Twitter a lot these days is about the conversation
about standardizing JSX, and at least in my personal opinion, JSX for example makes it
fairly hard, because by nature, JSX is rendering independent.
We set the renderer to the compile time to JavaScript and it just translates that to
a bunch of function calls that we can use, and so we actually already have something
that allows you to do that, where you define a function of and then that returns some output
and we can use it in an easy way with an arbitrary syntax and that's tagged templates.
So we can perform any sort of function that takes care of the input that we put in, allows
us to interpolate values and then create any output we want, be it a new string or anything
else, and so Jason Miller, the creator of preact actually took that as an act which
allows you to use React, Preact or anything else without having to compile by using tagged
templates and yes, the tooling is not as great right now around this as JSX might be with
TypeScript and stuff like that, because that's because we are not as heavily invested in
this yet.
But even if things don't get standardized, sometimes projects drastically change or come
to an end, so Angular JS is a great example.
With React and other things around 2010, the Angular team took some time and took a step
back and looked at what the current ecosystem is and wanted to create a new thing that solved
their problems in a way that they thought made sense and Angular 2 was a drastic rewrite.
And frankly that meant people moved on to React or Vue or other things because they
felt that their problems lined up better with React or Vue.
And so sometimes I hear that Angular is dead, but Angular is very much not dead.
There's for example, 21 Angular-specific conferences in 2019, versus I think I found 22 React conferences
and also, additionally to that, like we tend to be and serve our JavaScript bubble of people
who are full-time JavaScript developers, but there's lots of other people who write JavaScript
on a regular basis without identifying themselves as JavaScript developers, be it people who
write.net or Java or any other language.
The other part of the framework life cycle I that want to talk about is how frameworks
inspire each other and learn from each other, I think one good example is the origins of
Vue.
So Vue was created by Evan Hugh at the time he worked at Google or had just left Google
but he wanted to solve some of his own problems and to quote him, I wanted something that