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