Google I/O 2014 – How we built Chrome Dev Editor with the Chrome platform

Google I/O 2014 – How we built Chrome Dev Editor with the Chrome platform

morning, folks. Welcome to our talk. So today we’re going to
be telling you a story. This is a story of how
we built the Chrome Dev Editor on the Chrome platform. This is our story for
the past eight months. And we’ll try to compress
it to the next 30 minutes. And along this
journey, you will learn how to build your own
awesome, multi device applications on the
Chrome platform. I’m Sriram Saroop, a Product
Manager on the Chrome team and also the Product Manager
for Chrome Dev Editor. DEVON CAREW: Good morning. And I’m Devon Carew. I’m an engineer on the
Dart Team and the Tech Lead of the Chrome Dev Editor. SRIRAM SAROOP: Awesome. So what is the
Chrome Dev Editor? It’s what you see on the screen. It’s a developer tool
for building apps on the Chrome platform. You can build web applications. You can also build
Chrome applications. You can write them in
JavaScript or in Dart. The Chrome Dev Editor itself
is built as a Chrome app. And it’s written in Dart
and uses Polymer for its UI. If you have no idea what
Polymer, Chrome Apps, or Dart are, no worries, we’ll
cover that in the talk. So being a Chrome app,
the Chrome Dev Editor runs not only on
Windows, Mac, and Linux, it also runs on
your Chromebooks. That’s right. So you can start– [APPLAUSE] SRIRAM SAROOP: –building
apps on your Chromebooks with the Chrome Dev Editor. So I told you that
the Chrome Dev Editor is built on the Chrome platform. So let’s define what
the Chrome platform is. There are three parts to this. Firstly, Chrome Apps. So Chrome Apps really
extend the web. They add new, rich
native capabilities that are not normally
available to web pages. These range from accessing
devices over Bluetooth and USB to getting access to the raw
file system, where you can read and write files to a
user selected folder. Chrome Apps run cross
platform by default. And that’s not limited just
to desktop operating systems. They run on Android
and iOS as well. We’ll be talking
about that shortly. So, Devon, you want
to talk about Dart? DEVON CAREW: Yeah. So what is Dart? Dart’s a structured programming
language for the web. It’s class-based
and object-oriented and is designed to be
familiar to developers. So if you’re familiar with
Java, or JavaScript, or C Sharp, Dart will seem very
familiar to you. It’s also designed to be
productive, to write code in. It’s statically analyzable and
really amenable to tooling. So you can get
errors and warnings as you type rather than at
run time or at deploy time. It supports good code
refactoring tools, so you can keep your code
healthy when it grows large. It has a native virtual machine. So if you’re running
in a browser that has Dart support natively, you
get that performance benefit. But it also compiles
to JavaScript. So with Dart you can target
any modern HTML5 browser. SRIRAM SAROOP: Awesome. So the third part that the
Chrome platform constitutes is Polymer. Polymer really brings software
encapsulation to the web. So with Polymer you can
encapsulate not only script, but also markup and styling. You can build your own
custom HTML elements that you can reuse both
within your project as well as across projects. In addition to the ability
to build your own custom HTML elements, you now have access
to a library of rich UI elements that we’ve made available
called Material Design. And you can use these elements
to make your apps much more beautiful out of the box. So the Chrome Editor
is built on these three pillars of the Chrome platform. Let’s take a step
back and tell you why we decided to
build the Chrome Dev Editor in the first place. Chrome Apps. So Chrome Apps launched
late last year. And we found some
really impressive apps that you, as web
developers, had built. Ranging from an online
DJ tool for mixing music to a fully offline
capable video editing app. Amidst all these
impressive apps, however, there was
one category of apps that we did not quite
see on the web store. And that was developer tools. That’s right. So we didn’t quite see
many developer tools coming up on the web store. And we challenged ourselves to
see if the Chrome platform can be extended so that you can
build developer tools on it. And more importantly, we wanted
to provide a great developer experience for you,
as web developers, using the Chrome platform. So the Chrome Apps
team was playing around with this idea of building
a prototype developer environment as a Chome app. And this was around
eight months back. And that’s when
our friends in Dart had a similar thought process. DEVON CAREW: Yeah, so why did
the Dart team get involved? So for some background, I work
on the part of the Dart team that’s doing the development
environment– the Dart Editor. And for those of you who don’t
know, most of Dart’s tools are themselves written in Dart. We’ve got
Dart-to-JavaScript Compiler, which was written in Dart. Our Dart Analysis tools
are written in Dart. And our Package Manager
Pub is written in Dart. And a big piece that isn’t, is
the part that I was working on, the Dart Editor. It’s written in Java as
an Eclipse application. So my team for awhile had
been thinking about ways that we could spend more
time writing Dart ourselves and re-host our developer
environment in Dart. As we were working
on the Dart team but spending all of
our time writing Java. And about a year ago, we heard
about the Chrome Apps platform, which really appealed to us
because it was going to give us a way to write native-like
applications in Dart. And basically it would
give us the vehicle for writing our development
environment in Dart. We’re really excited
about some of the features that the Chrome Apps
platform gave us. We could run across platform
on Windows, Mac, and Linux. We could target Chromebooks,
which would be awesome. And it has some other
time saving features, like auto update, which
we could write ourselves. But because it’s
built in the platform, it would save us
time, and we could focus on more domain
specific features. In addition, we were really
excited about the possibility of writing our UI
in HTML and CSS because it would give
us a lot of flexibility and sophistication and room
to experiment with new UIs, where our previous
technology really didn’t have that flexibility. So we’re really
excited to– we saw that writing our IDE in Dart and
building on the Chrome platform as a way of taking our
tooling into the next level. So we started a prototype. And we were about 8,000
lines in when we found out that the Chrome Apps guys
were doing the same thing. SRIRAM SAROOP: Yeah,
so it’s not often that you write 8,000
lines and then figure out that another team is pretty much
working on the same project. So Devon and I met
eight months back. And we realized that each
of us had prototypes. We had shared goals here. We wanted to provide a great
developer experience cross platform. And we decided to combine
forces and instead do a single developer environment
that targeted both the use case of building Chrome apps,
as well as web applications both in JavaScript,
as well as Dart. So this was around
seven months back. And we decided to
drop our prototypes and start from scratch. So in the next 20
minutes or so, we’ll give you a glimpse of
what we went through in the previous seven months. So the way we’re going
to do this is we’ll be building the Chrome Dev
Editor on stage from scratch. We’ll do this piece by piece. And with every piece
we’ll introduce a problem that you as a web
developer might face. And we’ll talk about a solution
that the Chrome platform provides, and then how we use
that solution in the Chrome Dev Editor. So let’s get started
on this journey. Devon’s going be rocking. Start from scratch. Pray to the demo gods. So how about starting with
a simple basic text editor? DEVON CAREW: Awesome. OK. So I’ll switch over
to my Chromebook. So this is the
Chrome Dev Editor. It’s a very stripped
down version of it. What you’re actually
looking at, is it’s editing its own
source code right now. And over the course of
the next 30 minutes, we’re going to be
adding features to it, using it to modify
its own source code, restart, cross our fingers, and
come up with a more improved version. And hopefully by
the end of the talk we’ll have the full deal back. So the editing component we’re
using in the Chrome Dev Editor is the Ace Code Editor. For those of you not familiar,
it’s a JavaScript library. And CDE is obviously
written in Dart. But Dart has a very
strong [INAUDIBLE]. So it’s easy for us to consume
best-of-breed JavaScript libraries. Ace gives us good editing
for CSS, HTML, Dart, and JavaScript. It’s fast. And it looks nice. SRIRAM SAROOP: Awesome. So it is fairly
easy to get started because of Dart’s [INAUDIBLE]. We were able to reuse an
existing JavaScript library. That pretty much give us the
[INAUDIBLE] that we wanted. So, Devon, you know what? It would be awesome if
most developers could build applications
with just one file. But we’ve got to support
multiple files and possibly folders as well. How about adding a
files and folders view to the Chrome Dev Editor? DEVON CAREW: Yeah. Absolutely. We need one. And we’re going to use
Polymer to build that UI up. SRIRAM SAROOP: Polymer? Of basic files and folders? Why can’t you do that
using plain HTML and CSS? DEVON CAREW: You can. There are a couple reasons
why we chose to use Polymer. The short answer is for
maintainability, reusability, and some scaling issues. And the even shorter
answer is div soup. So what is this? This is a files view
component written as a series of nested divs. And there’s nothing really
inherently wrong with this. I’ve written my UIs
like this in the past. And it’s functional. But it has some issues. And those issues scale up, get
larger as your code base grows. So a lot of these divs
are not really semantic. A lot of them exist
only for you to have places to hang
CSS styles off of. And the CSS styles that you’re
using to style this component can leak out of this
component and affect other parts of your UI. And, similarly, other
styles for your application can leak in and style this
component inadvertently. The code you write to manipulate
this component– the JavaScript or Dart– can develop
bad dependencies on the structure of it. So you have tight coupling
[INAUDIBLE] your HTML and your code. And reusing this code is hard. So if I want to create
another files view or similar component,
I can copy this HTML, hope I copy the
right CSS, and then have two places to
maintain things. So there’s maintainability
and reusability issues. SRIRAM SAROOP: So you’re
saying this div soup is messy. It’s not reusable. It’s not maintainable. And Polymer promises
to solve all of that? DEVON CAREW: Yes. SRIRAM SAROOP: How’s that? DEVON CAREW: All right. So Polymer, it’s a whole
bunch of technologies. But some of the things
it does for you, it encapsulates
your DOM structure so that places that are
outside your application don’t need to see into
your internal structure of each component. It scopes the CSS so your
styles don’t leak out, and other people’s
styles don’t leak in. And it essentially lets you
create reusable components that you can share
in your application and compose in your application. You can use other
people’s components. It brings really good software
engineering principles to the web. SRIRAM SAROOP: So what does the
Polymer solution for the files view look like? DEVON CAREW: Let’s see it. So this is it. It’s a new DOM
element files view. It’s a custom element. And you can use it
in your HTML just like you would use
divs, or paragraphs, or any other elements. SRIRAM SAROOP: No kidding? Just a single element? So where exactly is the
source code for all of that? DEVON CAREW: There’s
a bit more behind it. We can see. So here is the
Polymer implementation of our files view. You can see there’s
a clean separation between the structure of
our component and the HTML [? of ?] the style in the CSS
and the behavior in the Dart or JavaScript code. At the very top of the
HTML, Polymer element name equals files view. That’s where we’re defining
our new DOM element. The next line down
is template repeat. We’re iterating
over the children– the child nodes of each folder. So we’re basically
iterating over the files in a specific folder. And for each file in that
files view node element, we’re inserting a
new DOM element. So this files view node
is another Polymer element we would define elsewhere. So you can see the
code is more semantic. It’s easier to read. And the attribute names
are semantic– name, icon, and indent. And the elements
names are as well. SRIRAM SAROOP: Awesome. So, Devon, how about
getting our hands dirty, praying to the demo
gods, and adding this live to the Chrome Dev Editor? Let’s see how this goes. DEVON CAREW: Switch
over to my Chromebook. OK. All right. So, again, this is the source
code for the Chrome Dev Editor. This is our main
HTML entry point. This defines the Polymer
structure for our application. And we’ve pre-written
the files view. So I’m just going to
add it to our UI now. And add a tiny bit more. So you can see I just had to
reference this files view code. And it’s imported in our
Polymer imports up here. So now I’m going to restart. AUDIENCE: [INTERPOSING VOICES] DEVON CAREW: Oh, yeah,
that wouldn’t have worked. SRIRAM SAROOP: Thanks
for pointing that out. DEVON CAREW: It would’ve
been a short demo. OK. So all right. Now I’m going to restart
the Chrome Dev Editor. This is some demo magic for
the sake of the presentation to try and compress
this into 30 minutes. It’s going to restart,
load up the new source, and hopefully if you look
on the left hand side we should see this files
view on the left hand side of that splitter. OK. SRIRAM SAROOP: Awesome. [APPLAUSE] DEVON CAREW: Awesome. [APPLAUSE] SRIRAM SAROOP: All right. So now that we have
a multi file text editor, when we started
testing this on a Chromebook, the process was quite painful. And one thing which
was really hard, was getting files in and getting
files out of the Chrome Dev Editor. We had to zip a whole set of
files, email it to ourselves, extract it on Chromebook,
and then point the Chrome Dev Editor at it. So we really wanted to break
boundaries here and make it really easy for getting
files in and getting files out of the Dev Editor. So, Devon, what do
developers normally do for this kind of stuff? DEVON CAREW: Yeah. So they’re going to
use Git for that. They’re going to want to
clone a repo from GitHub and make local commits and push
their port request back up. SRIRAM SAROOP: Don’t
you need a command line to type your Git commands? Hoe does that work
on Chromebook? DEVON CAREW: Yeah. It’s not going to work great. But Git was such an important
use case for the Chrome Dev Editor that we decided to
build Git support directly into the tool. So we wrote our own Git
Client Library in Dart which can speak the Git protocol
to get servers and manipulate the file system just like the
Git command line client would. SRIRAM SAROOP: Let’s show that. DEVON CAREW: OK. So our Git library’s
pre-written. And it’s hosted on our package
hosting site, So what I’m going
to do is, I’m going to add a reference to
our Pub spec file, which is part of Dart’s technology. It’s a declarative manifest
of all the dependencies of your application. SRIRAM SAROOP: That’s
a lot of dependencies that we have there. DEVON CAREW: Yeah, so
the Chrome Dev Editor has about two dozen
direct dependencies on various open source
libraries and another two dozen transitive dependencies. But Pub lets you specify your
version constraints very well. And it helps you work at
a large scale application. All right. So I will add a reference
to our Git library. And I’ll spell it correctly. So now we basically told
Dart’s Pub Package Manager we want this dependency. I’m going to run Pub Get, which
will go to, and provision that
package locally. All right. So now it’s in our source base. I’m going to add a little
bit of pre-written UI to reference that library. Again, I’m going to
use Polymer to do this. So Git clone button. And restart Chrome Dev Editor. And if you look in the
toolbar on upper left hopefully we’ll
see a new button. Awesome. OK. So that’s that. SRIRAM SAROOP: So is
that going to work? Git clone? DEVON CAREW: Well,
let’s find out. I have a canned repository. This is actually a
JavaScript Chrome app written for I/O this year. You can try this Chrome
app out at the code lab. So if I clone, this is actually
speaking to GitHub right now and cloning. Awesome. OK. So this is just a regular
JavaScript Chrome app. And I’ll run it just quickly
to show you what it does. It’s a tic-tac-toe game. There we go. SRIRAM SAROOP: Awesome. So that’s Git working
on a Chromebook. [APPLAUSE] SRIRAM SAROOP: So
what Devon just showed you was the use of Dart’s
Package Management System, Pub. So with Pub you can not only
manage your dependencies well, you get access to a whole set
of libraries, including Git, that we’ve contributed
to Pub recently. So now that we have a multi file
text editor with Git built in, let’s figure out what
our next milestone was. We call this bootstrapping. And this was really an important
[INAUDIBLE] milestone for us. And what I mean by
bootstrapping is we wanted our software engineers
to start using the Chrome Dev Editor on a daily
basis to build itself. This was really
important because this was [INAUDIBLE] our own product. We could find lots of
issues at dev time. And the big, fun
part of this was that our developers find
issues and fix it themselves. We ran into lots of
issues during dogfood. And do you want to talk
about some of the stuff that we fixed? DEVON CAREW: Yeah. Dogfooding was very
important to us. And we started
dogfooding very early. Probably even earlier than
it was really possible. And the main issue we found
when we were writing code was basically we didn’t
have static analysis. We didn’t have errors
and warnings showing up as we typed code. And we were really
dependent on this. And it meant that we found
our errors at run time or after we deployed
it to the web store. So basically we really
needed Dart Static Analysis running in the
Chrome Dev Editor. SRIRAM SAROOP: So
we’ll show you how we added Dart Static Analysis. DEVON CAREW: OK. So similar to the
Git library, we’re going to add a new package
to the Chrome Dev Editor. Now this is a Dart
Static Analysis package, which is again available
for anybody to use. Analyzer. Any. So we declare that dependency. I’m going to run Pub
Get and download it from OK. Cool. So there’s no new
Polymer UI for this. I’m going to restart the Chrome
Dev Editor, though, and show you some changes to
our Dart support. OK. So actually you do see these new
these warnings on the left hand side of the files view. So we run the Dart analyzer in
a web worker or in [INAUDIBLE]. We run it in parallel. It uses fairly heavy processing. We don’t want it to
interrupt the DOM thread. So you see we have a warning on
this file called Death Star Dot Dart. It’s not normally part
of our source base. It is for the
purposes of this demo. And the warning is
on this constructor. It says the final variable
Death Star must be initialized. So we have this variable
declared it final. We never passed value into it. I’m going to do that now. And you see errors and warnings
show up and go away as I type. So that was a very
powerful feature. [APPLAUSE] DEVON CAREW: Thanks. It seem very simple, but it was
the single biggest impediment to us bootstrapping the tool. So we have a few
other features we get from having a
static analysis. We have good knowledge
of the code base, so we can have an outline view. SRIRAM SAROOP: If you
could resize that. DEVON CAREW: If I can resize it. You can quickly know what
your code base looks like and jump to it. We can jump to definition. So if I want to see where
this Death Star is defined, I can control click it and
jump to the definition. It makes a lot of sense. As your code base
scales you want to jump around to different
files and navigate it easily. SRIRAM SAROOP: So Dart really
takes developer productivity to a new level because it’s
a structured programming language. So, Devon, you’ve spoken a
lot about Chrome Apps so far. What’s the web app support
in Chrome Dev Editor? DEVON CAREW: Absolutely. Yeah. So web app support is
obviously equally important. And I’m going to demonstrate
number four here. Yup. So we have a number
of project templates to help you get started
with applications. I’m going to create
a new web app from one of those templates. So we have several web
templates you can use, a Chrome app, some
Polymer support. I’m going to use a template
called the Web Starter Kit, which was just introduced
at Google I/O this year as well. It’s basically a
best practices web kit to help you get your
application created quickly and keep it on the rails
in terms of performance and jank-free code and running
across multiple devices– so desktop and
tablets and phones. So I’ll create this application. And it’s created. HTML. Hit run. And cross my fingers. There we go. OK. SRIRAM SAROOP: Awesome. So the web page is actually
running on your Chromebook from within the
Chrome Dev Editor. How is that working actually? DEVON CAREW: Yeah. Absolutely. So obviously web paging
is a server to talk to. We built a web server
into the Chrome Dev Editor built on top of the
Chrome app APIs. And, again, they’re
very powerful. They give you access to
things like native sockets. So we built a web
server on top of that. So it makes it very
quick to get started with a web app and prototype. And you can always move
over to your own web server at some point. SRIRAM SAROOP: All right. So it’s not only
Git that we built. We also built a web server
in the Chrome Dev Editor which works on a Chromebook. Let’s move on. So this is a trick
question for you, Devon. There’s something that’s really
hot for developers these days and especially at I/O this year. You know what that is? DEVON CAREW: The giveaways. SRIRAM SAROOP: I’m
talking about mobile. Yeah, mobile is on fire. And there are any
number of graphs to show what the growth curves
are, but this one in particular shows you the explosive growth
that mobile devices have had over the past
couple of years, especially smartphones
and tablets. So if there’s one platform
that you need to target, it’s got to be mobile. You’ve got to be building
mobile first these days. So, Devon, Chrome
Dev Editor Mobile, can we come up with a really
dead simple mobile development workflow? DEVON CAREW: Yeah, absolutely. Yeah, mobile. We knew mobile was going to
be an important use case when we started designing this tool. So we built mobile support
into the Chrome Dev Editor. In fact, we made it as
easy to run an application on your mobile device
as it is to run locally. So I’m going to demonstrate
adding some mobile UI to Chrome Dev Editor. Let’s see. Mobile deploy. So this is pre-written UI. SRIRAM SAROOP: It’s
Polymer in action again. DEVON CAREW: And I’m
going to restart. And if you look at the
toolbar hopefully we’ll see a fourth button up there. Mobile deploy. OK. Awesome. Let me find that
application we cloned. So this is the Chrome
app we cloned earlier. I’m going to hit this
new mobile button. It’s going to show
me a dialogue. Deploy to mobile. I’m going to hit that. But let’s switch over to
my phone real quickly. So this phone is connected
to my Chromebook via USB. I’m hitting deploy now. And it’s updating. And– SRIRAM SAROOP: Fingers crossed. DEVON CAREW: Hm. Well, all right. It’s not totally happy. Let me try once more. OK. Yeah. SRIRAM SAROOP: All right. So I think we ran into an issue
where the background changed to black instead of showing
the tic-tac-toe game. But assumed that worked. So what you now have is
Chrome Apps running on mobile. And let’s switch to slides. So Chrome Apps work not only
on desktop operating systems, but they also work
on mobile platforms. So this is made possible an open
source framework called Apache Cordova So we’ve
been contributing to this project for
more than a year now. And we’ve contributed
several Cordova plug ins, which provide really
interesting mobile capabilities, ranging from accessing
your accounts on your phone to having a native payment
flow to getting messages sent over using Google
Cloud Messaging. So now with all these
awesome native capabilities, we also have a great
developer workflow that lets you quickly deploy
your mobile applications from Chrome Dev Editor
running on your Chromebooks onto your Android device. So, Devon, you think we can
talk about the debugging story for mobile apps? DEVON CAREW: It’s
going to be tough. SRIRAM SAROOP: Let’s
give it a shot. DEVON CAREW: It did
not come up on this, but I’ll give it a shot. SRIRAM SAROOP: Blame
Michael for that. DEVON CAREW: So our debugging
story for Chrome Dev Editor is just using DevTools. It’s a fantastic debugger. And it has great
support for mobile, too. So we’ll bring up DevTools. We’re going to accept. Actually, I should
probably switch over to my– [INAUDIBLE] OK. So I’m looking for something
that says tic-tac-toe. Hm. Yeah, I’m afraid this
is not going to fly. AUDIENCE: [INAUDIBLE] DEVON CAREW: Yeah. OK. OK. Oh, tic-tac-toe. Awesome. All right. SRIRAM SAROOP: Hold on. Let’s show the full version. So, yeah, that’s the app
which magically came up again. [APPLAUSE] SRIRAM SAROOP: OK. So I skipped a couple of beats. DEVON CAREW: Yeah. No, I didn’t– All right. Cool. All right. SRIRAM SAROOP: So let’s
go back to the debugging. DEVON CAREW: I’m
going to bring up a DevTools inspector on this. Yeah, it’s not cooperating. Anyway, so our development
story with Chrome Dev Editor, especially on
mobile, is DevTools. SRIRAM SAROOP: So
DevTools really compliments Chrome Dev Editor. DevTools provides a
great debugging story. And you have a great
development experience with Chrome Dev Editor. So to sum it up,
what we’ve shown you is Chrome Dev Editor was
built on the Chrome platform. Chrome Apps, Dart, Polymer. Chrome Apps really provides
the native capabilities that you need. And you can target multiple
platforms not just limited to desktop but also
Android and iOS. With Dart, you get awesome
developer productivity because it’s a structured
programming language. And with Polymer
you get the ability to encapsulate your
elements so that you can build your own custom
HTML elements that you can reuse across your projects. So the Chrome Dev
Editor itself has been open source since day one. And you can check
out our source code to find out how we use these
three parts of the Chrome platform together. So, Devon, you want
to talk about some of our external contributors? DEVON CAREW: Yeah, absolutely. Yeah, so like Sriram said, we’ve
been open source since day one. We’ve had only over
20 contributors that’s both Googlers
and non Googlers. I’d actually like to
thank our two biggest non-Google contributors,
thanks a lot, folks. And I really hope
that many of you can start contributing to the
Chrome Dev Editor as well. So if you’re interested in
building apps for the Chrome platform, check out
our documentation. I’m also happy to announce
an early developer preview version of the Chrome
Dev Editor, which is available from
our GitHub site. So there’s a link which
takes you to the web store. And you can install the Chrome
Dev Editor on your Chromebooks right today. And not only that,
at Google I/O we have several code labs which
use the Chrome Dev Editor. You can check them
out there as well. And Devon and I will
be at the Dart booth. We’ll also be at
the Chrome booth. So come talk to us to know more
about the Chrome Dev Editor. It’s at an early
stage, so we’d love to hear from you what feedback
you have on the current working version of the Chrome
Dev Editor, what features you would like to see, and more. Thanks a lot for
coming to our talk. Hope you enjoyed it. So there are mics
on either side. You can come over to the
mics and ask you questions. [APPLAUSE] AUDIENCE: Hi, I was wondering
where the file system is hosted, and does that scale
to much larger web projects? DEVON CAREW: Yeah. So the Chrome App APIs
basically give you fairly good access
to the file system. So the user selects the
folder, and then you can see everything in
that folder and below it. So we’re just using the
regular Chrome file system, and it scales up to
whatever size disk you have. AUDIENCE: OK. So when you’re cloning
it does actually bring the files
local to the machine, not host them on a
server somewhere. DEVON CAREW: Nope. Yeah, they’re local. You can disconnect your
network and run just like a regular native app. SRIRAM SAROOP: So we are
working on a feature which would allow the files to be
backed up by Google Drive. So it’s using the
same file system API. So that’s a feature
we’ll add pretty soon. So that will allow you to have
your files on Google Drive and sync automatically
across machines. AUDIENCE: Awesome. Thanks. AUDIENCE: Hey, I was wondering
if Dart is running natively on any of these
devices’ platforms? DEVON CAREW: So this is
actually the Chrome Dev Editor compiled to JavaScript. Our story right
now is that we’re developing against Dartium,
a Chromium version with Dart natively. It’s a very good
development story. When we’re deploying
the Chrome Dev Editor it’s compiled using Dart-to-JS
and distributed that way. AUDIENCE: Right. Thanks. AUDIENCE: Things
like Node and Grunt are a big part of my workflow. Is the bash-l supported
in Chrome Dev Editor? DEVON CAREW: Yeah. So the bash-l is not. We have to figure out how
[INAUDIBLE] Javascript development workflow. We have [INAUDIBLE]
support built in. That was important
to support Polymer while we need to be able to
provision those dependencies using [INAUDIBLE]. We still have to
figure out how we’re going to support
common JavaScript workflows like Grunt. SRIRAM SAROOP: So we are working
with a native client team to see how we can run native
code within the Chrome Dev Editor. And hopefully that will
allow us to support some of the native tools
that you’re talking about. AUDIENCE: Thanks. And are there any plans
to bake this directly into Chrome alongside DevTools? SRIRAM SAROOP: So right
now it’s a separate app that you need to install. We want to keep it that
way because it allows us to iterate outside
of Chrome much faster. So it’s just one install away. And it synchronizes across
all your Chrome profiles. AUDIENCE: Thank you. AUDIENCE: Are you going to have
anything like Push App Engine? DEVON CAREW: So we are going
to work on app engine support. And actually it’s very easy to
support or deploy theoretically because at App Engine you can
do a Git push to a specific URL. And it deploys your application. And we support Git. So we’ll probably go
that route at some point. SRIRAM SAROOP: All right. Cool. Thanks a lot, folks. [APPLAUSE] Looking forward
to your feedback. [APPLAUSE]


    Really interesting content. I'm just starting to build a Chrome App and had no idea this tool existed.

    Would be a better video if there was less screen time of them staring at the ChromeBook & more screen time showing what they were actually looking at (especially around the 20-minute mark).

    I'm sad they stopped working on this. It's the only decent chromebook IDE that runs offline. It works great but I'd really like to have seen it become so much more. We need this for chrome OS

Leave a Reply

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