October 15, 2019
Frameworks Panel (Chrome Dev Summit 2017)

Frameworks Panel (Chrome Dev Summit 2017)


[MUSIC PLAYING] ADDY OSMANI: Hey, folks. So the web benefits from
a healthy relationship between browser vendors
and web developers. And framework authors
and their users are often at the
forefront of trying to find a healthy balance
between DX and UX. So today we thought
we’d bring along a few folks from frameworks,
libraries, and their users to have a chat about what a
better future could look like. So joining us on the
stage, we, first of all, have Andrew Clark from React. Andrew? [APPLAUSE] Next up, we’ve got Jason
Miller from PREACT. [APPLAUSE] We have Steve Orvell
from the Polymer team. [APPLAUSE] Rob Wormald from Angular. [APPLAUSE] Tracy Lee from This Dot
JavaScript and RxJS. [APPLAUSE] Chad Hietala from
Glimmer and Ember. [APPLAUSE] Sean Larkin, representing
Vue.js and Webpack. [APPLAUSE] Malte Ubl, the tech lead of AMP. [APPLAUSE] And finally, Alex Russell
from the Chrome team, lover of frameworks. [APPLAUSE] All right. Sit down. So thank you to everyone that
managed get their questions in today. We have a very special prize
for the best question, courtesy of Alex. The very best question today
gets a very average Moto G4 phone. [LAUGHTER] That’s going to stay
over here for now. Awesome. So let’s get into it. Very first question that
came in was, “Which features, if any, would make your life
as a framework author or user easier if they were added
to the JavaScript language, or web platform more broadly?” Jason, do you want
to start us off? JASON MILLER: Sure. So there’s been some stuff
going around recently about a proposal
called DOM change list. And I think one of the
end games of this spec– it’s basically a way to
serialize a set of mutations to the DOM– one of the end
results of this would be we can start to run more
application code in a Web Worker. Web workers have existed
for a really long time, and are strangely
underused in our community. So it’s a primitive that– whether it’s polyfilled or
implemented in browsers– once we’ve got some of
these things in place, we can start to offload a lot
of work off of the main thread and reduce jank on mobile. So that’s a huge thing
that I’m hopeful for. ADDY OSMANI: What do you think
it is about Web Workers that have stopped them from getting
as much traction as they could? JASON MILLER: They’re scary. Also, by default, when
you construct a worker, you have to give it a URL. And it’s pretty easy– get a blob URL for
an inline string. But it’s not the
default behavior. So there’s a task
led API that might be proposed to solve that. That would be
another huge feature. So that a framework shipping
could instantiate a worker with some code in it. And that wouldn’t
be a weird thing. That would be expected. ADDY OSMANI: OK. So Web Workers. Rob, on the Angular
side– did you have any opinions about that? I know that Angular has
historically been trying to invest in Web Workers. ROB WORMALD: Yeah. I would second the
DOM change list API would be amazing for us. I think we could
put it in tomorrow, and it would be ready to go. So that would be a big one. And I think observables
would be the other big one that we’d like to see. Angular developers
using a ton of that. They seem to really enjoy it. It would be nice to not
have to ship that code and not pay for those bytes. And I think it opens up a lot
of interesting things on APIs like Intersection Observer
and Mutation Observer. I look at those
and go, those are perfect for this sort of
thing we’re talking about. So those would be
the big two for me. ADDY OSMANI: Is there
something specific, other than having to ship it, solve
this problem in user land, that shipping observables
and a browser would bring? ROB WORMALD: I could probably
talk for an hour about that. I think to me, it’s
kind of the same thing that we went through from
callbacks to promises. When you get a type,
and you get a thing you can pass around, and
treat like a real thing. I feel like we need the same
thing for events, right? And that’s more or less what
an observable is for me. Get a handle on the thing. Be able to pass it around. Treat it like an object. And it really changes how you
think about doing complex event things, drag and drop. All these really
highfalutin animation stuff we all want to do,
this interaction stuff, I think becomes
much easier when you have a primitive for handling
really what’s delivering it. ADDY OSMANI: Chad,
I was curious. What, from the Glimmer and Ember
side, do you feel is missing? CHAD HIETALA: So again,
the change list stuff. We actually have a straw
man like implementation of this in the Glimmer BM. A lot of the work that we’re
doing on the Glimmer side is, instead of compiling
a template, like how vast majority of these
frameworks, authors, projects do, what we are trying to do
is compile templates directly into a byte code format. And so the change list proposal
is more aligned with that. Because the whole idea is
that you would build up all of the operations that you
need to manipulate the DOM. That’s a typed array. You can transfer that
across different workers and then apply it
on the main thread. So yeah, I think something like
the change list would be great. ADDY OSMANI: OK, so
we’ve got change lists. CHAD HIETALA: I think
we’ve got a consensus. Can we just ship that now? I think we have consensus. JASON MILLER: You could do
change list plus worker DOM. There you go. ADDY OSMANI: Change
list and worker DOM? Alex, do you have any
opinions on change lists? ALEX RUSSELL: No. ADDY OSMANI: OK. It’s very straightforward. ALEX RUSSELL: I’m
taking bug reports here. I’ll just scribble down
that you want them. ANDREW CLARK: Tracy,
observables were mentioned. I know that in the
RxJS community, observables are a big
thing there, as well. Are observables
something browser vendors should seriously be taking
a look at baking in? TRACY LEE: Yeah. I totally think so. I know there’s the [? TCF39 ?]
observable spec happening. And hopefully that
moves somewhere. And just earlier, Rob was
talking about, hopefully– are you guys going to
champion that or somebody? ROB WORMALD: I think we may. We’re looking at it. TRACY LEE: So hopefully that
lands soon– observables in the browser. But I think if
we’re able to start getting those types of things
to happen that are more native, then what’s going to
happen is hopefully the ability for
people to use RxJS, and the learning curve is
a little bit less daunting. ADDY OSMANI: Awesome. Malte, I was curious
from the app side. Are there capabilities
you feel are missing? MALTE UBL: So what I would
like to say– because everyone mentioned workers. What browser windows
could do is hear us. We all talk about Workers. The developer experience in
DevTools isn’t great yet. So if you could
invest in the future, and say maybe in a year,
people actually use Workers, but then have the
DevTools already be good, that would be amazing. I also have something– AMP doesn’t really
need it, but I think everyone wants this, which
is just really good WeakMaps. So they launched a
feature called WeakMap. That’s not actually what you
usually would consider this. So just having a cache
that you can put stuff in, and maybe it’s still there. But it’s not considered
by garbage collection. If you build something
like Relay or even Redux. I think everyone wants this. And it’s not up and coming. And that’s really sad. ADDY OSMANI: OK. I saw Alex grinning at this. So Steve. I was curious. Did you feel like there were
any capabilities missing from the platform that
would benefit folks that are writing
applications using web components or Polymer? STEVE ORVELL: Yeah. I definitely second
the JavaScript APIs that are mentioned. Think a little bit more about
the DOM here, and just say, there’s tons of
cool stuff that we run into when
rendering that I think would be nice to
add to the platform. Specifically, a lot of the
stuff that the native elements can do that we can’t do
in custom element land. There’s cool stuff
that the dialog element can do that we can’t do– render
stuff on top of other things. Input element, of course,
and new infinity stack. It would be awesome to
deconstruct that, and really add that to our
tool kit, so that we can use other developers. ADDY OSMANI: And anything from
the React side– you folks? ANDREW CLARK: Yeah. Things that the browser can
do that frameworks can do. APIs that expose that are
always exciting to us. Our current favorite browser
API is requestIdleCallback. We use that everywhere. That’s kind of core to
how we’re thinking about. Basically, what our goal is
with REACT right now is– did everyone enjoy that
image async feature that you all talked about? What if you could make
any component async, and just make any
of your components stop blocking the main thread? So scheduling primitives,
like requestIdleCallback. There’s a really cool
proposal, I think the W-G– I always get the
different things confused. But there was a
really cool proposal called async append,
which I think is a very interesting
problem space. And this basically lets you
build up this tree of DOM, whether using React
or whatever, you could manually create
this, and asynchronously append it into the DOM. You get a promise
that says, once all of the layout and everything
has been done by the browser. And then, once the
promise resolves, you can decide when you want
to actually commit that change, or actually flush the changes. It’s really cool
reading that document, because it’s a description
of what we’re trying to do with React as well. But that’s the type of
thing that React can’t do or framework can’t do is– well, unless we re-implement
layout, which maybe we will. But realistically for
now, we can’t do that. So those are the kinds of APIs
that we get really excited about. ADDY OSMANI: So we saw some
convergence on DOM change list. Is async append
something that any other? I’m seeing lots of
nodding and fingers. And Alex is also
happy with this. Great. OK, we’ve got some
convergence on this. That’s great. Let’s move on to
another question. So folks are wondering,
what criteria should you use if you’re trying
to select the JavaScripts library or framework to build
a new application today? And given that he’s just written
a blog post about performance budgets, I was curious
on Alex’s take on this, and then everybody else’s. [LAUGHTER] JASON MILLER: Go read his post. ALEX RUSSELL: You might
get a different answer, depending on who you ask today. I work on Chrome. I used to work on frameworks. And working on a browser
means you represent the user. And so I wind up representing
the users’ interest in a lot of these conversations. And the way I see people
constructing applications today is incredibly well-suited to
the computers and networks that we were building and
using about five years ago. Six years ago, right? Networked computers that had
reasonable, and good, stable latency, fast pipes, copious
CPU, relatively small screens, compared to the amount
that you had to paint. So that’s not the
world we live in today. Mobile is much, much harder
than any of that ever was. The latency on the
networks was terrible. The pipes are
smaller and variable. And so we’ve been
working with lots of partners for a lot of years. And the way I would
think about this is, frameworks take some
amount of your headroom. How much headroom do you have? Is the next obvious question. And I think you
have, if you’re going to be building a
framework-based site, you’ve got about 130 kilobytes
on the wire, gzipped. So when you’re
selecting a framework, I think one of your primary
questions should be, how much of that
130K that you need to stuff all of your styles,
all of your critical JavaScript, all of your data,
all of your markup, templates, application
logic– everything has to go in that 130 kilobytes. How much of that is
your framework taking? Is a question you should ask. ADDY OSMANI: So one thing I was
curious, Andrew, about this. ANDREW CLARK: You’re
staring at us now. ADDY OSMANI: Yeah. Just looking at–
you’re right next to me. One thing I was curious
about from the React side. So we obviously see
a lot of applications being started today that
are targeted at mobile using Reacts. And they’re making a
bunch of ecosystem choices about using Redux, etc. Do you think that
folks understand the costs of the
ecosystem pieces they’re using, when it comes
to trying to target mobile? And is this an area that need– ANDREW CLARK: Do I think
people understand this problem? I probably depends
who you talk to. One downside of the React
ecosystem historically, relative to the way
maybe Ember view– I think view does a
good job with this– is that we have
resisted the frameworks. I could actually put frameworks
and libraries in the title. We’ve resisted the frameworks
label for a long time, because React was
designed to fit into the architecture of
Facebook from four years ago, five years ago. So in the beginning, we
never built React apps as single page applications. We were building little
tiny views all over a larger server-rendered app. So the first people that built
server-rendered applications were way out ahead of us. So we never provided
our own router. We never provided our own
solution for data fetching. So I think to the
extent that people don’t care about this enough
maybe in the React [INAUDIBLE] system, I think that is kind
of a consequence of that. In the future I think, with
things like create React app and really cool projects
like Next.js and Gatsby, that are starting to give a more
framework-y holistic approach to how you’re
supposed to do Service Workers, or
server-side rendering, which I think is a really
exciting, untapped area still, or data fetching, or whatever. I think that’s going to be a
really exciting important area in the next year or so. ADDY OSMANI: Cool One thing that
you touched on was things like Next.js being a good
place to maybe– so you see that as being
a good place for us to try defining
perhaps well-lit paths for people that are trying to
deliver applications on mobile? ANDREW CLARK: What
was the word you said? Well lit– ADDY OSMANI: Well-lit paths. ANDREW CLARK: OK. I don’t know what that is? ADDY OSMANI: An opinionated
path for folks that aren’t– ANDREW CLARK: Well lit. Is that what you said? ADDY OSMANI: Well lit. ANDREW CLARK: OK. Like a cow path. OK. ADDY OSMANI: Yes. JASON MILLER: Where
are you walking? ANDREW CLARK: I respond
to animal metaphors. Yeah. I think that we have resisted
taking super strong opinions on things, especially
because the infrastructure we use at Facebook is not– we don’t really use
Webpack, even though we think Webpack is really great. So we’ve resisted giving
too many opinions. But I can see us shifting
more in that direction. There are a lot of things
like server-side rendering, streaming service set rendering,
data fetching, data management, code delivery, like Sam
was talking about earlier. There’s a lot of these
things that are really the same problem space,
or overlapping problem space, that we don’t have
a great way of pushing our solution or our vision
of what they should be, because we don’t control
a framework-y framework. So that’s why Next
and stuff really excites me in the React space,
because they are offering a little bit more of this. And I think we will
maybe start to dip our toe even further than
create React app in the future. ADDY OSMANI: That’s awesome. Jason, so React is
in a similar spot, with respect to technically
being a library. What is your take on this? JASON MILLER: Yes. I would say if you’re making a
technology decision about how you are going to structure
your applications– if you’re picking something important
like your view renderer, but what you want to know
is, when I’m finished this, and I ship my version 1,
how large is it going to be? If you’re picking a
library, you probably need to look at what the
rest of the options you have are in that library space. So if you’re going
with React, you need to say, OK, how
large is a common router? Do I have a decent
selection there? For the various CLI tools, or
server side rendering tools like Next, what
is the end result of those kind of
ecosystem approaches? Because at the end of the day,
if you end up going with Next, the size of React
may not even have that much of an
effect on your bundle. It’s more the size of Next that
you want to be concerned with. And so even if you’re not doing
server-side rendering, or Next, or Gatsby, or whatever,
look at the common CLI tool, look at the boiler
plate you’re going to use, and see if
there’s a metric you can derive from that,
not just the library. ADDY OSMANI: Cool. Let’s switch up topics. Let’s talk about interop. So framework interop,
web component interop has been an
interesting hot topic in the community for a while. Tracy, I was curious– what’s
your take on this with respect to– is it important for frameworks
to interop together? If you’ve got teams that are
working in React, and view, and PREACT, et cetera. Is that important as a
thing for end developers? TRACY LEE: I think you look
at a lot of large companies who just do JavaScript. So a lot of
companies try to say, OK, I’m just going to
go the Ember route. I’m just going to
go the React route. I’m just going to go this route. But then you have
a lot of people who just have disparate
teams who try to say, OK, I have this Angular app. What’s the library
I’m going to build with all these components? And do I stick React in Angular? Or what do I do there? So I guess it would be nice. I think it’d be nicer
for some developers. And I think that there
are a lot of solutions, especially in the corporate
world, that people have sort of stuck together. It’d be nice if those
were more forward, or maybe you guys can come
up with solutions to do that. Or maybe Webpack can
solve all the problems. ADDY OSMANI: Well, since Tracy
put you on the spot, Sean. [LAUGHTER] What is your take on
framework interop? SEAN LARKIN: OK. I’ll speak from experience
what we do at Microsoft. So we have over 98 products
that ship in production that use Webpack. But no single one is the same. And one of the
biggest initiatives that is taking a
significant amount of time is trying to unify some sort
of component library or system. I think some of the biggest debt
that companies struggle with, and even one like
Microsoft, is that we have to be able to move
fast, add features. But then, as platforms
change, or features are added, or new frameworks
crop up, we want to be able to take advantage
of these technologies, but in a way that can still
be agnostic and provide interop between teams. I have my own opinions. And I think view is really going
to blaze the trail in terms of how we might see a generic
statically analyzed kind of Rosetta Stone for lots
of different frameworks to consume components. And you know, Jason and I have
worked on it a couple of times. JASON MILLER: Yeah. SEAN LARKIN: So he already has
a loader powered by Webpack that’s already taking
a view component and importing it into a
PREACT project, and it works. So there is a huge
amount of opportunities for lots of people to explore. ADDY OSMANI: So Jason,
I was actually curious. From the PREACT side,
you’ve been interested in web component support. I think that PREACT’s been
doing a decent job of looking at interop. You’ve also been, again,
working with Sean on ideas around, how can we take
inspiration from things, like the HTML imports approach
that libraries that Polymer have heavily been
using, and bringing it to other frameworks. Could you talk a little
bit about your opinions on what the future direction
of that might look like? JASON MILLER: Sure. So for me, a part
of the win here is, we actually have a
compiler model, right? The web is obviously a
target we write code for. But it’s also a target
we compile code for. Not just with WebAssembly
and these types of things, but even just compiling
to JavaScript. But if we take a look at
the way that we’re using these compilers, and we
try to model our input after existing specifications. Like if you have a compiler
that takes in something that is essentially a serialized
Web component– an HTML file with JavaScript, CSS,
and a template in it. That’s an understandable
independent layer. You don’t need to know how
whatever the framework that renders it after
compilation works. You could just sort of know
how web components works. And if the framework adequately
implements slots, then if you know how a web
component slot works, then you know how
this file works. I think that Sean had
mentioned Rosetta Stone. I think that’s a good
analogy for this. If we could start to converge,
at least a little bit, on what a component
looks like across all these different technologies. What is the substrate
that they’re all built on? Then we could start to
cross-compile between them. You could write a user
interface components library with beautiful
CSS, and encapsulation, and some behaviors. And then compile it
to whatever framework you’re currently using. And it won’t matter. 10 years from now you could
compile it to something else. ADDY OSMANI: Steve. I’m curious about
your take on this. There’s the
cross-compilation idea. And then there’s just having
everything work magically at runtime. What is your take on the
shape of this problem. STEVE ORVELL: As you
guys probably know, web components are designed
to solve this problem. So a little bit it
makes me slightly sad that everybody is not just
gravitating towards it. On the other hand, I think
the technology is evolving. It’s taken a long time. And I think it’s getting there. And hopefully we
will evolve it still, and make it a satisfying
answer to this issue. I think one of the
places that Polymer has seen a lot of
adoption, actually, is in big corporations
where they just have this polyglot
of different stuff. And they just need a
technology that works wherever the DOM is going to work. And this is really where
something like web components shine. And I think this is
something where, as now, this is kind of the year
of the web component specs being implemented widely. I hope there will
be more interest among the other frameworks here. And I think there’s– I want to give a shout out to– Taylor did this talk
earlier to custom elements everywhere that Rob
Dodson has done. Which is, I think that we took a
little bit for granted the fact that hey, we’re the platform. Everybody’s just
going to work with us. And I think to a lot of
different approaches, this is sort of a scary
concept, that now, an element in the
platform can be anything. It can be whatever. And I think this is partly
incredibly powerful, because it’s sort of this
democratic process of the cream of the crop can rise. But at the same
time, it’s also like, but that thing can do anything. It’s kind of scary. Do I really want to use that? And this is where I think
the approach between custom elements everywhere
is really interesting. Because it is this idea
that the framework authors and the community of
developers making these custom elements really have
to meet in the middle. And establish best
practices such that it makes sense to these to
use these things all together, and we can all benefit. So hopefully that happens. ADDY OSMANI: Rob, so
Angular has been investing in trying to improve their
interop with custom elements, and web components in
general for the last while. What’s your take on this? ROB WORMALD: So I feel
like the Rosetta Stone that Sean was talking about– I think that’s what
a custom element is. I think that that is. And I don’t think
this group of people would agree on
many things, right? Competing against the group. But I do think that we’ve
all more or less landed on this idea that
there are events, and there are props
or property– whatever you want to call them, right? We all have kind of an
API that, if you squint, it’s more or less the same. So to maybe make your
year a little bit better or today a little
bit better, I can say that our team has
decided that we’ve always consumed web components. That was a day one design
decision in Angular. I talk to enough
big companies, I’m sure, companies that
Polymer in, that have these very
disparate ecosystems, have a dozen
different frameworks. I think it’s very sad,
as a web developer, that everybody has
to rewrite the date picker in every framework
that exists, right? If I do one thing as somebody
who works on the web now, if we can just write one
date picker that’s awesome, and then use it
everywhere, I’ll just quit. Right? [APPLAUSE] So from our perspective, Angular
is a framework-y framework, as you said. We do try to solve a
lot of these problems. And so for us, I think
our bread and butter is these big applications
that everybody likes to build. But for me, it would be great
if Angular components could be spit out as web components. It’s a thing that you look
at it and it’s a no-brainer. And so six weeks ago we started
really looking into this. I’ve been complaining
about it for 18 months. I said to Alex Russell when
I joined Google that we’re going to make this happen. And finally it’s happening. So you’ll be able to
write an Angular component and spit it out as
a custom element. And I think that the
most important thing about that– the kind of crux
to all of this custom element stuff– is that nobody
has to know anything about how the component was
implemented to make it work. Because everybody
in this room already knows how the DOM works, right? And if that becomes the
common API we all talk to, it doesn’t really
matter what happens inside of the component. We can all have
this Rosetta Stone. We can all talk. And we can write
one date picker. And everybody can
be happy, right? [APPLAUSE] ADDY OSMANI: So on
that note, it sounds like there’s some interesting
convergence on the Rosetta Stone idea. I’m curious, from the
React perspective– what’s React’s take on web components? ANDREW CLARK: Yes. We have a slightly
different take. [LAUGHTER] Web components are really cool. I think they solve the
encapsulation problem, and they solve the
consumption problem, where you should be able to consume– you shouldn’t have to
learn 15 different ways to consume a component. And surely you can wrap any
React app in a web component. It’s not that hard. The question is
whether or not we should replace React components
as a primitive rebuilding your application
with just writing a bunch of web components. And on that note,
we’re not as convinced. Because we use– I could be wrong, but I think
another selling point for Web Components is that
perhaps it obviates the need for a
virtual DOM, or for us to have to manage our
own parallel in-memory representations of your view. And on that part, web components
don’t solve that for us. Because we use our
internal instances not just for encapsulation, but we
use it for memoization, we use it for computing changes,
we use it for scheduling. That’s the big one. I don’t know if you all have
heard of this recent effort. We had to rewrite React. But we’re moving in a
direction with React 16 and going forward where we’re
going to have async by default rendering. And what this means
is, we’re going to do all of our rendering work
inside of requestIdleCallback basically. And in order to do that, you
need this double-pass rendering system where you
have two phases. One, you have an
async render phase, where you do most of
your expensive work. It’s all in requestIdleCallback,
or maybe in the future, it’s on a Web
Worker or whatever. And then you have a
synchronization phase, where once you compute
all of your mutations into a DOM change list,
maybe, you can synchronously flush all of them all at once. And that’s the type
of architecture which we’re really excited about. There’s a lot of cool
features that you can build on top of this. But it’s not really possible
without implementing your own data structures. So we’re like thumbs
up on Web Components, but we don’t think it replaces
the need to have our own data structures. ADDY OSMANI: Alex. You have any takes on this? ALEX RUSSELL: Yeah. So full disclosure. Dimitri Glazkov,
Alex Komoroske, and I started the project at Google
that sort of started the Web Components effort. We’re sorry? [LAUGHTER] Apologize? Catch me later, buy you a beer. I don’t think Web
Components actually have any bearing
on whether or not you should have a virtual DOM. It’s virtual DOM becomes an
implementation detail about how your component decides to handle
getters, setters, attribute setting, and all this stuff. Web Components as
an implementation give you a surface area that
everybody knows, as Rob said. So you can just reuse the
date picker from wherever. And then how you want
to handle that question about how state gets handled
inside of your component is now up to you. It doesn’t do any
global coordination. So I think this is one
of these places where Web Components dis-aggregate
a bunch of things that frameworks used to do. Frameworks have
traditionally taken a bunch of different
responsibilities, between ensuring
compatibility across the DOM, giving you a component
model in the first place, making sure that those component
updates are coordinated in various places,
doing data distribution, and event handling. And Web Components sort of
disentangle a couple of those, and leave you with a
few of those problems. They don’t solve everything. So a few of those
still have to happen. And it’s interesting to see how
the various frameworks are sort of reorienting themselves
now that Web Components are kind of a thing. So, yeah. I’ve seen lots of people– SkateJS is doing
this great work where they’re using virtual DOM
inside of custom elements, which is super cool. They may be using
PREACT internally, which is not removing a virtual DOM. But it does leave that global
coordination question open. ADDY OSMANI: Cool. And– sorry. ANDREW CLARK: I was going to say
just a sentence on the interop thing, just to go
back a little bit. I’m going to sound
like a broken record. But the thing that we’ve
found is interesting about interop is this
coordination problem. At Facebook we use
React everywhere, but the other framework that we
use is server-side rendering. And if you think
about it, we have this system called BigPipe. The thing about it, both of
these are asynchronous systems. And it becomes a really
interesting problem, how to coordinate two
asynchronous renderers, so that things aren’t
popping in on the screen at different times. ADDY OSMANI: And
circling back to Malte. AMP is one of the largest
consumers of custom elements. I’m kind of curious on
your take about interop. MALTE UBL: So I just had this
conversation with the product manager, saying, hey, we
didn’t date picker in the app. And I’m like, oh, my god. Not again. What we ended up doing was
taking the Airbnb React date picker, using it with
PREACT, so it’s not actually like 60 kilobytes, and putting
it into a custom element. [LAUGHTER] And it works fine. Like AMP this
Airbnb date picker. And I’m getting worried
about the people that put all these massive frameworks
in these little un-capsulated things. I think we need to understand
that, just because something is great on the interop
level, and we don’t have to make a new date picker,
doesn’t mean we don’t need unification of framework. Now on the other
hand, AMP right now, it doesn’t actually
allow you to write code in any other framework. So interop is a bit awkward. But I think what our
goal is in the long term, that you could just use React
to render this stuff that you want to change in
undocumented runtime. I think the current state is
not where we want this to be. That’s just the thing we
could implement in fall, 2015. ADDY OSMANI: Switching
gears up a bit. We are running a
little bit over. But I’m just going to take
one or two final questions. What impact is WebAssembly
going to have, if any, on JavaScript frameworks
and libraries? Chad, do you have
any takes on this? CHAD HIETALA: So I
think WebAssembly is kind of interesting. There are certain
things I’d really like to talk today, basically. It’s not a replacement
for JavaScript. But there’s in places where
you need the performance, I think it will
play a larger part. Maybe not everyday
developers writing it, but framework authors
may opt into writing in a little bit of C
code to maybe eke out a little bit more performance. This is some things
that we’re experimenting with, with Glimmer, is in
very high critical performance scenarios we want to try to
eke out as much performance as possible. ADDY OSMANI: Awesome. Jason, did you have any
other takes on WebAssembly? JASON MILLER: I’m a
total WebAssembly noob. But something that
came up over lunch– [LAUGHS] you laugh. Truth. I know the API. That’s about it. Also, I wouldn’t trust
myself to write native code. But one interesting
area that got touched on was, for something like
a polyfill for a really performance critical feature,
having the ability to write at least parts of the
polyfill in WebAssembly could be really compelling. We were talking about
DOM change list. If there’s diff
computations, or something that needs to happen in there,
or the creation of that array buffer. If that’s better done in C,
and WebAssembly is available, why wouldn’t you do it? Seems like it’d
be powerful there. ADDY OSMANI: So our final
question is not strictly going to do with APIs. But we had a question around
what can we, as a group, do to improve diversity
in open source? Which I think is a really
important topic, and something that I’d personally love to
see us make some traction on. Tracy, I was interested
in your take on this. TRACY LEE: I think there’s a lot
of really great programs out. I’m a Google Developer
Group organizer. And there’s a Women Techmakers
initiative that happens. And it’s a really great way
to bring woman developers together, and give them
a safe space to learn. I think if you talk to women,
and just everybody in general. But I focus on women,
because I’m a female. If you talk to women
in general, everybody has varying ideas of
acceptance and inclusion. And what it should be,
and what it shouldn’t be. So I think not really forcing
your opinions on women, but just giving them a
way for them to contribute the way they want to. I think with just also
encouragement in general. I think in our industry, we
have this diversity problem. And a lot of
companies are looking for the senior developers
where, when you actually look at our industry, you see a
lot of junior female developers coming in. And what we need
to do is somehow figure out a way that
we’re able to encourage these junior developers, so that
we can build senior developers. And I think that’s the
biggest problem right now. That’s the biggest
disconnect we have. ADDY OSMANI: I agree with that. Sean, this is a problem that
you have some thoughts on. SEAN LARKIN: Yeah. If it wasn’t for open
source, I wouldn’t be here. I’d still be in tech support,
or just doing whatever. And so thanks to a little
bit of my privilege– why does this have to be a
unique story for just myself? We should be able
to not only elevate the opportunities for
every single person to be able to receive the same
blessings that many of us have, just by being involved and
passionate about something. And so one of the
things that we’ve seen is that we have specific
outreaches for Webpack, not only that span gender or
race, but even just countries. We have an initiative
called Webpack Africa that we’re starting. And a gentleman named Prosper– if you haven’t met him. Where’s– raise your hand maybe? He’s back there somewhere. He’s helping lead
that organization. And their goal was, we
need to prepare people for the web for the
next billion people. And so that means that we
could have the opportunity to elevate somebody
to a whole new life opportunity for the next million
contributions or developers. And so we want to find
as many ways as possible to essentially elevate or
provide more opportunities, so that these success stories
don’t have to be unique. They don’t have to be rare. [APPLAUSE] ADDY OSMANI: On that
note, we’re out of time. Please join me in giving a
hand to all of our panelists, who are very kind enough to take
time out to come here today. [APPLAUSE] [MUSIC PLAYING]

11 thoughts on “Frameworks Panel (Chrome Dev Summit 2017)

  1. re:interop and picking a framework based on size – If you have 10 components and each use different framework, wouldn't that mean 10 libraries to download in addition to the 10 components? These goals might be in conflict?

  2. Kudos to google for getting all these framework contributors together and kudos to the contributors for participating. Speaks to how everyone really is committed to the higher goal of making the web easier and not just promoting their framework.

  3. Lewis Mccasland developer of the year 2 years running I did build up 10 years ago over 10 years ago all built up hybrid hybrid transfer unit

  4. Off topic: I gotta ask… Has anybody thought what this panel would have been like if Shai Reznik would have been the host? 🙂
    On topic: great talk!

  5. really? safe space to learn just for woman? where I have my safe space?? I have an idea, stop wining and just learn and share your ideas. I guarantee you, when you come up with good idea and try to implement it on an open source project, nobody will say anything about your race gender or color of your nails 🙂 we have meritocracy here, I hope we still have it.

  6. The Preact panelist enters after (post), not before (pre) the React panelist – that is out of order!

Leave a Reply

Your email address will not be published. Required fields are marked *