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
captured the declarative nature of Angular's data binding but ... So here we can see one
of those classic examples actually written down as how they inspired each other.
Another example is toolkits.
I think we've all used something like you Vue CLI, Angular CLI, there's lots of different
CLIs around these days, but I want to talk about the Angular CLI.
And more specifically about the Ember CLI.
Because up until last year there were plenty of references in the Angular CLI about Ember
CLI.
So took inspiration one step further by relying on that and then building on top of that but
sometimes the inspiration comes from the community.
So if you didn't hear of the term ahead of time compiling that's basically the way that
things like Angular during a compiling step remove unnecessary code and improve the startup
time and bundle size by removing parts of the library that are not necessary.
And in inspired by that, the group from swell did the same thing and called it rawact, it
replaces with direct rendering instructions for the DOM.
But this also gets me to the fact that not everything works for every use case because
he points out in his repository that this is largely useful for things that your application
has less components than the size of the React source code, or if you're trying to do things
like building web components where you don't want to ship the entire React with every web
component so if you want to pick a date picker, you can do that without having to distribute
everything.
And fair warning, the rawact is very much a proof of concept but I hope that React is
picking that up over time.
But I can speak to the topic that people have different challenges and ultimately different
backgrounds and different challenges that they're trying to solve we tend to forget
about that.
A .net developer might feel more comfortable with an opinionated framework because that's
what they're used to.
And an enterprise developer might choose to use a framework that has batteries included.
But as much as frameworks are about solving problems, they're also about hype.
In fact they're very much about hype.
To quote Mark S, making a popular open source project is 10% idea, 15% code and 75% community
building and marketing and I think that's very true and by the way, you if you don't
know max Stoiber, he created.
I think two good examples are Aurelia
and Svelte.
It's actually a really good framework that is being used.
It's just not as widely known as Angular, for example, or React, and the other one is
Svelte, it's a framework that has a lot of great concepts, like the ahead of time compiling
and others.
It might actually be useful for your own project but chances are when you evaluated another
framework you might have just not heard of it and therefore didn't take it into consideration.
So hype really is what makes a framework, but less hype doesn't mean that it's killing
the framework, and that gets me to one of I think like the one thing I want you to take
away from this talk, and that's let's not call frameworks dead, because in JavaScript
nothing ever dies.
70% of the top million sites use JQuery and things like Angular and Ember and others have
vibrant communities and I think it's very disrespectful for the people who still maintain
these things but also the people who have to work with them on a regular basis.
But also, sometimes yes, some frameworks go unmaintained, but that still doesn't mean
that they are dead, because people don't have the luxury of being able to change overnight
to a new framework, because -- and so as long as those tools still solve problems for people,
the community likely is going to stick around.
It might shrink in size, but that still doesn't mean that it's dead.
And so I like the comparison of how frameworks and libraries are like hammers, there's like
an unlimited amount of them and they have different sizes, different manufacturers,
and different specialization, but please don't tell someone to buy a new hammer, because
if they already have one, and it solves their problem, because they only have to put a nail
into a wall like once a month or once a year, don't tell them they need to drop their hammer,
because it's not efficient and they need to buy a new carpenter hammer.
It's not their use case, because they don't need it that often.
So let's stop kind of making people feel bad about that.
Let's stop telling people they are wasting their time, because ultimately if they're
happy with their solution, they will -- they're totally fine to keep using it, so let's not
make them feel bad.
All right, to wrap things up, I want to update an ask from Dan Abramov from 2016 and I want
to update it to take some time and build a side project or something with a framework
or a tool that you're not familiar with.
And approach it with an open mind so that you can use the tools and the frameworks that
they build around it, the philosophies of how they structure that you are applications,
and learn from that.
And then don't look down on others and try to convince them to change to your favorite
tools.
Instead, talk to each other, talk about why they chose it and why you chose your solution,
what they like and dislike about it, share your own experiences, and help each other
and learn from each other.
Because if frameworks can learn from each other and evolve, then you can, too.
All right, if you want to check out the slides, they're on this URL.
And I'll tweet about them afterwards, as well, and with that, I would like to say thank you
and if you have any questions, I'll be around, so feel free to talk to me afterwards or hit
me up on Twitter or via email.
Thank you so much.
[applause]