BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Adobe System's Narciso Jaramillo on Brackets and Web Development
Recorded at:

Interview with Narciso Jaramillo by Martin Monroe on Feb 04, 2014 | NOTICE: The next QCon is in San Francisco Nov 3-7, Join us!
30:30

Bio Narciso (nj) Jaramillo is a Principal Scientist at Adobe. He created the initial prototype that grew into the Brackets project (https://github.com/adobe/brackets), and continues to help lead its design and development, as well as providing strategic and technical guidance for other web tooling initiatives at Adobe. In his spare time, nj is trying to get better at playing jazz piano.

Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

   

1. We are here with Narciso Jaramillo, product designer and engineer from Adobe Systems. We are at QCon 2013 in San Francisco. Welcome, Narciso.

Thank you. It is good to be here.

Martin: He is popularly known as "NJ" and he is currently working on an open source code editor known as "Brackets". Tell us about Brackets, NJ. How does the app work? I see it is popularly used on GitHub. With developers there teaming up with you to get Brackets online…

Brackets started as an idea that we are prototyping for a front-end code editor for web developers. It started with a few UI ideas that we had about ways that we could streamline the coding process for web development.

The byproduct of that while we were experimenting with it, we decided: “Hey. Why not just also build it using front-end web technologies instead of building in C++ or Java, or one of these traditional languages that we would typically built a desktop or some kind of tool in and we just built it on the web.

So we started experimenting with that and we found that actually, it turns out that that had a couple of advantages. One is that it is really easy to prototype interesting, novel UIs using HTML and CSS and JavaScript because it is actually a declarative UI stack.

Also, because it was written in these languages it turned out that we have been able to build this community of people around it who are helping develop it because the people who use it are often the same people who can develop using those technologies.

It is actually not even a 1.0 product or 1.0 project yet. We are still making it better and better. But we use it every day even though it is still missing some functionality and things like that.

We have got about maybe 50,000 or 60,000 regular people downloading every spread and using it. And we have had over 140 people contributing to it on GitHub and we have got a large community of people building extensions for it. So it has been really gratifying to see that kind of community support that has been built up around the project.

   

2. What type of solutions do you anticipate Brackets solving once it gets together?

Well, the primary thing that we were trying to focus on, like I said, as being a front-end web development tool.

There is a lot of really great text editors out there and we look at them all the time and we love them.

But one of the things we thought was if we focus specifically on the challenges around front-end development; JavaScript, HTML, CSS development, we could build UI and tooling around that that was maybe richer for people who were focused on those problems. As opposed to trying to build a more general tool that would work for anybody. So we have a few specific things like this idea of live development. Instead of the standard thing you would do where you type some code and then you hit save and then you have to reload it in the browser and things like that.

We have been experimenting with ways to make it so you can just edit your code and as you are editing it live you can see the result in the browser. Without having to reload it and stuff like that. We have that working now for CSS and HTML. JavaScript is harder, obviously, but we have been doing some experimentation with that as well. So that is one aspect of it. The other is just a lot of these things that you might call productivity enhancement. But one of the main examples of that is this thing that is called in-line editing, or quick edit.

The idea there is that when you are working, especially when you are working in these web technologies, you are often jumping around between a bunch of different kinds of files: you have your HTML file, you have your semantic markup and then you have got your CSS file where you are describing the presentation and you have got the JavaScript which is all the code and you are constantly bobbing back and forth between these files.

So rather than do that, we make it so that, for example, if you have an HTML file on a tag and you want to find out what CSS styles are associated with that tag or might affect that tag, then you can just hit that keyword shortcut and it actually finds the relevant rules and that it just opens up a little snippet of that in line in the same editor window.

And then you could just make some quick tweaks and that works with live development too. So you can make the tweaks and see what happens in the browser and then you can close it up. This is a very seamless experience and we have a lot of other tools that use that same UI metaphor.

So if you are in JavaScript and you are in a function call and you hit that same keyboard shortcut, then we bring up in the definition of that in an inline editor. So it just makes this so you do not have to leave your context as much, there is not as much switching back and forth and at least this is very fluid work flow where you are not just leaving, you are not breaking your flow just to go and find some snippet of code or something like that.

Then we have some other stuff like that, like when you mouse over a color you can either edit it inline like that or can see a little preview that pops up. The idea is to take a lot of these things that you might find in some of it was like an IDE. Traditionally, when people try to build more powerful editors for domain specific things, what they do is they try to build this dashboard style IDE where there is all this functionality, which is great, and it is very powerful.

But we are trying to build something that felt more just like a text editor, felt very simple and stream lined. And where these UI elements emerge from your code and then they go away when you want them to go away and they do not feel like they are taking over your whole workspace. And so you can just focus on your coding. Which is really what you are there for.

   

3. That is pretty awesome. Is this a separate product or will you incorporate it with the other Adobe family of products?

Yes. We are actually already doing that. Brackets itself is an open-source project and I mentioned at the beginning it is not Adobe Brackets. It is really a community project and, like I said, most of the contributors are actually outside Adobe.

But, what we do is we take the open source project and then we have an actual branded Adobe product that is called Adobe Edge Code, which is part of our Edge Tools and Services family. What that is, it is really just a distribution of Brackets, so it is a distribution of the open source project that has some additional extensions built in that access Adobe services. So there are a few of them already built in right now.

For example, I mentioned before that Brackets has this little inline color editor. So if you are on a color value, you can break it open and there is this nice visual color picker and you can use it to edit the color. If you use it in Edge Code it has an additional piece of functionality that connects to the Adobe Kuler service. Kuler is a kind of a social network for color palettes. It is sort of funny when you say it that way but basically, a lot of people who are either designers or who want to do design, they need to come up with a good idea for “what are the colors I should use on my website?” and sometimes if you are like me – and I am not really a designer but I sort of have an eye for color, I am not really good at coming up with my own colors.

Kuler is a service that lets you look at color palettes that other people have come up with and then you can also create your own and share. Anyway, when you are using Edge Code and you are bringing up that color picker, it shows you additionally stuff from Kuler, so it shows you color palettes that you have created or that other people have created.

That is just one example. We also have things that tie to a free web font service called Edge Web Fonts that provides free downloadable web fonts and so we have a way that easily takes those and puts them into your project on Edge Code.

The idea is that over time, Adobe Edge Code really is just Brackets at its core. But we are adding these useful extensions that will tie to specific Adobe services. And that is how we balance the stuff that we are doing for the community project versus stuff that is tied in more to Adobe’s products.

   

4. Brackets has an HTML, CSS and JavaScript - is this a sort of synthesis of those three?

Yes, that is both what it is focused on - editing as well in what is built in. Of course, it is also ancillary technologies like CSS preprocessors, node apps – things like that you could develop using Brackets.

   

6. Yes, to use all three languages to soup up your application. Is there any advice that you can give to developers?

Yes. It is interesting because, like I mentioned before, trying to build something that you would have built traditionally as a native application using C++ or using Java or something like that, building it with web technologies is a very different feel in a way.

I mean in some ways, it is very similar. It is basically a lot of Java Script in modules and things like that, but there are a couple of things that make it unique. One is the UI layer, because the UI layer is declarative, because HTML and CSS are not – they are not just pure imperative code you can actually just say “Add a new download here!” or “Tweak the style of this” or whatever.

What that means is that it actually becomes very easy to extend the UI of Brackets without us – as the core Brackets team – having to necessarily think of every possible thing you might do. So as analogy, if you took another IDE…so I worked in Eclipse for a long time and it is a Java based IDE as you might know and it is extremely extensible.

They spent a bunch of time thinking about how to make it really extensible and as a result there is a huge ecosystem of Eclipse programs, right? But when you want to create a new UI in Eclipse you have to do it using the APIs that they have already thought of.

They have to say, “Oh, you want to add a button to the tool bar. OK. Well, here is the tool bar, add an API." If you want to add something to the file tree you have to do this and that. Which makes a lot of sense. It is because there is not really declarative UI framework there, whereas in HTML what we can do is we can give people a little more freedom to just experiment.

People have come up with all kinds of interesting UI ideas that – some of which I will show off in my demo – where we did not really do any specific work to say “Hey, you can plug this thing at this point in the UI” because they could just put a download in there and just show whatever they want and attach styles to it and things like that.

And of course there are certain things they might try to do that might clash with something we are trying to do or things like that. One of the things we are doing is because work on such a rapid iteration cycle, so our team works on these two and a half to three weeks sprints.

Somebody comes up with some kind of extension and the UI they want to build for it somehow conflicts with something that is in the core Brackets UI, we can have a dialog about it, they can file an issue. By the next sprint we might have it fixed. Frankly, that has not happened that often.

A lot of people have been able to build really interesting stuff without having to modify it. So that is one big advantage. I would say the other thing that is great about it is just that there is this huge ecosystem of JavaScript frameworks and things like that, that just make it a lot easier to do more industrial strength development.

Again, one of the things about the JavaScript compared to a traditional language like Java or C++ or whatever it is, that it is very dynamic and it is not a type safe language. So you might think “How do you build a large application using that?” But the reality is that there is this modularity frameworks like Require, there are MVC frameworks, there is all these kinds of stuff. There are lots of frameworks and best practices out there that make it a lot easier to structure a large JavaScript code base.

So it does not have to be spaghetti code like you might imagine in a typical dynamic language. Now, there are still challenges with that and we still make mistakes. But I would say on the balance we had very few bugs that have come from lack of type safety or any of those safety nets that you would expect.

Obviously we use a linter and things like that to try to check for obvious mistakes, but in general that part has not been a problem. I would say the biggest challenge actually is more when we are dealing with the web runtime. Which is the browser. Obviously there are things that where it is not optimized for certain things.

For example, CSS historically has not been optimized for building UIs that look like desktop applications. It has been optimized for web pages and application web sites. And that is different from building something that feels like a desktop app. So we have had some challenges there. And then also performance obviously is something that you always have to worry about. So we use a lot of the tools that are built into the browser in order to figure out performance issues.

We have even done stuff like getting a high speed camera and just literally pointing it at the screen and the keyboard and then pressing a key and seeing how long it takes the letter to show up. And with a high-speed camera we can figure out that took like 100 milliseconds, that is what too slow.

So you can start doing that because the development tools only tell you so much and they typically focus on things like script performance. And they do tell you a little bit about rendering performance. But you cannot get as much detail on some of that stuff as you would like. And it is not always accurate. So there are definitely some challenges around doing great performance tuning for an app like this.

   

7. I see. So, you adjust the coding when you see the results of the camera performance?

Well, it at least gives us a real world. We know this is exactly how long something is taking because you can’t always tell just measuring it using the developer tools. If there is a problem there then we can go and take steps to figure out what the underlying issue is.

Obviously it is not ideal. It would be better if the browser developer tools captured absolutely every single thing they contributed to the issue. They are getting much better. Over time they have been rapidly evolving to the point where dev tools in the browsers now have these great dashboards.

Which you can use to see exactly how many frames per second you are getting and this frame it took this much rendering and this much script. So it is getting better and better so hopefully we can ditch the high-speed camera sometime in the near future.

   

8. When do you think the application developers like yourself and others will begin to support more application development actually occurring in the Android and iOS environments?

There are a few different aspects to that. As far as Brackets itself – right now it actually runs as a desktop application. So it is hosted inside essentially a thin shell. Which is based on Chromium. Which is the open source project that is underlying Chrome. We have a dedicated browser in a way. And the main reason for that is that we can have access to the local file system. Which typically you can’t do with a browser based application as well as things like native menus and things that make just a little bit more of a friendly desktop application.

That was primarily because we think that a lot of developers still work locally on files and they run local tools. And so they need an application that works like a traditional text editor. But of course because we built an HTML application in JavaScript, we can also bring it into the browser. And at that point we can also bring it on to other OS' through the browser.

Obviously there are a few things that we need to solve there. And one is of course the file access issue. So if you are working online then you have to work against some cloud-based back end. That is something that we are actively working on and in fact, we already -in this sprint- have just checked a new abstracted file system that makes it so that people can build their own file system back-ends; if they wanted to talk to Dropbox, Creative Cloud or some other back end.

There is that aspect of it and then of course, it is just the fact that if you want added code on something like an Android device or an iOS device, there is a sort of a form factor issue. You should write like selection and typing. There is other work we would need to do to make Brackets itself to be really accessible on something like a tablet device. But that is obviously a possibility given that it is built in web technologies.

Then as far as the people using Brackets to develop mobile sites, again you use whatever best practices you typically use for HTML and that would also have PhoneGap/Cordova.

Which is a runtime that makes it possible to build HTML based applications that run like native applications on a device. So if you create an App using Cordova -which is an open source project- or PhoneGap, which is the W branded version, it allows you to access native functionality from within essential HTML container.

And so that is one aspect that you can do. Of course, we have got other Adobe tools that target things like mobile development, which I think you have a question about.

   

9. It sounds like you are still a few years away from developing a mobile app from within iOS and Android then?

Well, you can do it now. Like I said with PhoneGap. For Brackets itself – I would not say it is years away. I mean – again- these are all things that people are doing now.

Martin: I am just trying to do my first application and they all want me to develop it in Mac OS or to develop it in Windows. That appears about your only choice really.

But it is so much easier now to get into web programming. Because there are all these frameworks and there are also great online learning resources for that stuff too. And again the power of having the in-browser tools for that is really significant.

   

10. So what do you think about the differences between using native tools to create mobile apps since there is a whole camp for native and a camp for HTML?

Well, it all depends on your context and what you are trying to do and frankly your cost sensitivity. There is no question that using a common code base to build an application across multiple platforms makes sense if what you need to do is to get a wide as possible reach in the quickest amount of time at the lowest cost.

And also to the extent that your application, if what you are doing is already based on something that is essentially web based. And it makes a lot of sense to at least take advantage of HTML rendering within your application even if it might be a native application. And so a lot of what people do is that they build these hybrid applications where part of it is implemented in HTML in a web viewer or something like that inside a native container so that they get the best of both. For other things where you are focused on a specific platform or you have certain performance needs like a game or things like that.

Again depending on what you are trying to do, it might be easier in a thread to game and HTML to using that. If you find that you cannot get the performance you need or whatever, then you use native for that.

So it is all just a matter of what kind of context you have and like I said, a lot of apps are really using the best of both. They are using HTML where it makes sense to get the flexibility, to be able to reuse code from a web presence but then using native stuff to do a native.

   

11. HTML 5 is so established, will there ever be an HTML 6?

Well, the way I think about it, frankly, I think it is just HTML. So it is a constantly evolving technology, it is a constantly evolving ecosystem. We are getting away from this old model of: stuff takes two or three years to get out there, right?

The reality is that there are multiple browsers out there. With this renewed interest I would say in the web space of improving the expressivity and richness of what you can do with web technologies, the evolution of the web zone is only going to continue to accelerate.

And now obviously you can’t just come up with an idea today and then see it in the browsers tomorrow. There is a lot of work that needs to be done in order to make sure that it works for everybody and security issues and things like that. So it is one of the things that Adobe is doing actually as well, in addition to the tools that Adobe is working on.

So we benched an Edge Code in Brackets, there are some other tools like all these sort of web tools for authoring rich web content. And there is a whole other half of the Adobe web organization that is devoted to basically working on what we call the web platform.

So we have a development team that both writes specs for proposals basically for new web features and also provides reference implementation of them working with a browser vendor. We have engineers who are committers to web kit.

Actually one of our first features that we worked on -which is called CSS Regions- allows you to create magazine style layouts for the web. So basically it lets you take content and then flow it into multiple columns and things that.

We proposed a spec for that working in conjunction with other browser vendors and other partners, we worked with the W3C so we have representation on the W3 spec committees, we worked on our reference implementation in web kit and in Blink and now that implementation has shipped in iOS version.

So now in Safari on iOS you can use CSS Regions. So, that is an example that it was not instantaneous. But by being able to leverage Adobe’s rich history with creating expressive – creating technology that allows people to express themselves creatively. So from desktop publishing through things like Dreamwaver and Flash to the present day we have been able to take that experience and help basically put that into the open web.

And so that everybody who is using the web can benefit from these technologies. We are continuing the operation and we have had other exciting stuff coming up around like CSS Shapes that you can take text and you can flow into a particular shape – so it does not just have to be a rectangular box anymore.

We have stuff around things like CSS Customs Filters which lets you do really complex working and coloration effects. So there is a lot that we are doing to try to help push forward the expressivity of the web.

   

12. Though as we speak it has only begun just a few hours ago, NJ what is your impression so far of QCon SF 2013?

Yes, I know. Unfortunately, I have only had time to go to one talk and I have not been to this conference before. But it was actually really interesting. I was looking at the tracks and it just seems like the breadth of things that you guys talk about here is really interesting.

So it is always with a focus at teams on large scale like enterprise systems. But there are some talks on front-end developers, there is a trial called “No back-end” which is all about people who are doing front-end development being able to do all their work without having to think about “Am I going to spin over back and then do all these complex stuff there? Let me just do it all using the technologies that I am familiar with”.

That is kind of in the front end and I just saw this really interesting talk about a virtualization and how instead of running whole OS in your virtual machines you can basically just take your application and compile just the pieces of the OS that you need, like the network stack and the TCP and all this kind of stuff and just take that slice of it, compile it into essentially a custom kernel and just run that directly in your virtual machine.

It's just like you cut the OS out of it entirely and that means that you can scale massively, horizontally and it was all done in OCamIL like functional. So it is just this very wide variety in breadth of topics which seems really interesting to me for a conference like this.

   

13. Awesome. Do you work more in groups or on your own at Adobe?

It is definitely work in teams more. It depends obviously on the stage of a project. Typically the way a project will happen is you will start with one or two people who have an idea. In the case of Brackets, I just had some ideas in my head and I started prototyping them.

In other cases where we are doing more directed learning about a particular area where we think that there might be an opportunity, what we will do is we will pair a product manager, an engineer and a designer and they will make this little team and they will go off and investigate the prototypes, they will talk to customers, they will do all this kind of stuff.

It is lean methods, the kind a Startup would do. Basically take this little team, sort of iterate on the idea, pivot as necessary and then at the point where it looks like there might be something here and there is a business case for it, then we will staff up and we will wrap a team around that and things like that.

So it is typically, but it is always in a team environment. We are all just trying to figure out which should we be investing in, what makes the most sense.

   

14. And when you are not working on your own I guess you would be just working together online. Do you guys use GitHub a lot?

Yes. Especially on Brackets because we have some remote team members so we have a couple of our core team members are in San Jose, we have got a guy in Michigan and then of course our external committers who do not even work for Adobe.

They are in places like in Spain and Germany and some in America and then of course in a wider contributor base, people who have committed code into our repo are from all over the world. I mean I do not know how many countries at this point. It is a lot. We obviously use things like GitHub, pull requests, things like that. We use distance communication technology. Adobe has its own which is called Connect. Which we use a lot, so that we could videoconference with each other, and that is how we do our daily Scrum meetings. So, it is definitely very much team effort. One of the nice things about working with GitHub, you can see I am a fan – I got the GitHub hoodie here, right? – is that it is this great balance between people working together on a project and people being able to do their individual contributions.

The whole pool request mechanism, the fact that I can work on my own and come up with whatever crazy idea I want and then I can submit it and then somebody else can review it in this real seamless way. It is not like we have not had tools like that before, but GitHub makes it so easy to do and in fact we have a culture of code review on our team.

Every single thing that goes in a code base gets code reviewed before it makes it in. It is really that social coding aspect that makes it that you can take a good idea from anywhere, something that you never heard of and as long as the code is good, it makes it in. That is a huge step forward I think for open source development.

   

15. Do Adobe's employees work from the main office or do they telecommute?

It depends. It varies from team to team. Some teams are very spread out geographically and so they mostly work from home or whatever. Our team, like I said is a mix of people who would commute and people who work in the office.

Our team just happens to have one day a week where we all just work at home. Like you are not supposed to have a lot of meetings and people can just focus on coding or whatever it is that they are doing. So we sort of try to strike a balance.

   

16. Who has been the greatest influence to you, NJ, in your career as a software engineer?

It is hard to say, but I would say that the really talented people that I have gotten the chance to work with over the course of my career. I have been lucky really to get to work with is a lot of people who – they are not good at just one thing. So you have this sort of traditional view of it: you have got your developers and you have got your designers, you have got your products managers and there are all kinds of those loggerheads. Whereas what I found is that, at least in the places where I have been privileged to work, a lot of people were kind of cross-disciplinary and there was a lot of cross-pollination between the different disciplines.

So a lot of the developers we hired at Adobe - they do not think of design or UI or whatever as this thing that you are going to try to stick on at the end to make everything look pretty. They understand that design is a fundamental piece of software development, that if you do not have design, if it is not usable, if it is not delightful, that people are not going to want to use your product.

So we have a lot of design sensitive developers, a lot of our designers know how to write code – they write HTML, CSS and JavaScript. So they understand the technology as well. And then a lot of the product managers also come from engineering, they come from design.

So, it is really nice to be able to work on these teams where people kind of speak each other’s language. It is not these weird looking silos where people do not understand what everybody is talking about. So I would say that the people who have really affected me the most are the people who have that skill of being able to move between the different worlds and kind of think bigger picture, pop up the level, not just get like focused on what they are doing in the day-to-day.

And really see how this is going to affect the business, how this is going to affect the user experience, how this is going to affect other people on the team, the people who can think about how their day-today work affects everything else.

   

17. So no one in particular comes to mind that helped you in your career, someone that understood the big picture?

Well, there is this one guy who I have worked with for a very long time. I think he is at Medium now actually, who was probably one of the best at that kind of stuff. He was super, really great; he was probably one of the best coders I have worked with. But also just has that great ability to step out and question assumptions and hop up and see the big picture and all that kind of stuff.

Martin: Well NJ, thanks for attending QCon SF and for consenting to the interview. It has been terrific!

All right. Thanks a lot. Take care.

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT