Placeholder Image

字幕表 動画を再生する

  • 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,