At many conferences, the hallway track is more interesting than the track during presentations. It’s the serendipity of a small group of people interested in solving a similar problem that run into each other and just start talking through it that makes the hallway track the most interactive experience at most conferences.
edge
EdgeConf capitalizes on these discussions by turning the hallway track into what the conference is all about! There are a selected set of topics covering emerging trends in web technologies and a panel of 5-6 people take the stage with one stepping forward to bring the audience quickly up to speed. The discussion begins!

The panelists work through a set of curated questions and there’s a system for the audience to participate and join the debate. Everyone is encouraged to spend less than a minute at a time talking, ideally 30 seconds or less. If the speaker goes over 2 minutes, there’s a nice warning across the screen on stage that tells the speaker that their time’s up. Oh, and the whole thing was streamed live! You can watch all 10 hours of coverage or read the gist below!

Topic 1: Installable apps and permissions

The first discussion was on installable apps and permissions. As Jake Archibald joked, we’re basically taking the easiest installation process (open a browser, type the URL) and screwing it up with complexity. The panel focused primarily on the state of features you need for web technologies to be a first class installed application and the mechanisms by which users are asked to grant permissions to an application. For example, what’s the current state of making an application work offline (not good), what level of device or platform capabilities are exposed via JavaScript or web APIs, etc.

One interesting point of note was that bookmarked home screen applications on iOS that request permission for Geolocation will show up in the list of applications under the geolocation permission settings. This is pretty nice because this isn’t just a PhoneGap-based application, but simply a normal website that has been added to the screen to be treated as if it was an app. Showing permissions for this app as if it was an installed application adds a lot of consistency for end users. The consensus of the panel was that this type of consistency is unfortunately more of the exception than the rule at this point in time.

One audience member asked if the recent announcement by Vox media that they are eliminating mobile-specific sites and apps was the start of a trend. Some panelists agreed. Brian LeRoux of PhoneGap fame made the interesting point that many apps are no better at working offline than web apps (he called out Uber as his T-Mobile connection early that morning was flaky and that was interfering with his transportation to the conference).

The conversation then moved on to the concept of permissions and a screen was shown where the entire iPhone screen was a set of permissions being asked of an end user. Jake Archibald made the argument that lawyers should be forced into a view of the web where they only see raw source code, since we as end users are forced to view raw legalese rather than easy to understand, user comprehensible terms and conditions.

The approach that Firefox OS takes is to ask users questions that impact privacy, but for security, they try to just do the right thing. For example, you don’t ask a user if they want to restrict a connection to SSL, but you ask them if they want to share their location.

The point was also made that sometimes the platform makes the permissions sound a lot more aggressive than they are. For example, if TweetDeck asks for permission to send Tweets on your behalf, if doesn’t mean they want to randomly spam your feed with marketing tweets, but rather, when you click publish in their app, they are effectively publishing a tweet on your behalf, because that’s how the API works. Chris Messina asked what you do for permissions when there are no pixels, e.g. a voice command system from your car. The panelists pretty much mumbled something inaudibly, shrugged their shoulders, and moved on to the next topic.

This panel talked a bit more about routing, pre-rendering, navigation transitions, application manifests, and service workers. The panel concluded with a brief discussion about the importance of URLs, even when they are human unreadable.

Overall this was a really informative session. Jake Archibald and Brian LeRoux are fun and entertaining speakers which made for a great start to the event. There are many subtle considerations to solve in order for web apps to be used the same as a native or hybrid app, and I was fairly impressed how far along some of these ideas are, and how much has been solved. While the concept of installable apps is important, I think the bigger challenge is to get the permissions approach solved efficiently. Today native apps automatically receive a lot more permission than they perhaps should, and web apps have a real challenge in asking for the right permissions as the default wording allowed by browser vendors give the impression that an app is overreaching with their requests. Solving both of these problems are essential for keeping web apps competitive with native mobile apps.

Topic 2: Layout performance

The next panel was focused on browser layout engine performance. Mike Shaver of Facebook led this discussion, and presented a nice short set of hand drawn slides. Layout is but one part of the pipeline (JS, Style, Paint, composition, etc.), and as developers, we fight with layout a lot. It’s brittle, it hurts performance, it’s hard to reason with, and it’s often difficult to understand what’s going on.

Fast loading and rendering pages are the key to perceived performance. When performance is slow, who’s problem is it?

  • Browser vendors? A comparison was made to defying reality, e.g. a car trying to tow a castle
  • Developers? A comparison was made to a car vendor specifying that you can only shift gears at exactly a specific RPM, or else the car breaks

The point was that these are both extreme perspectives, and reality needs to be somewhere in the middle.

We were reminded that we have a platform that grew out of the concept of a document. We end up reimplementing things over and over again because we sometimes settle for specifications without having long term insight.

It was asked if it makes sense to provide more hooks into the layout engine for developers. Generally people are in favor of this, with some pause for concern around the complexity this may add.

It was suggested that maybe there should be various hints application developers can provide to pre-tune the performance for their site or app, though others argued that a browser should be able to infer things without having to specify 50 different forms of strict mode style settings.

Well known web performance expert Steve Souders was in the audience, and discussed the lack of a benchmarking standard for layout. The panelists talked through some items that matter:

  • text rendering (Canvas has one that’s very difficult to use)
  • frame rates
  • large data sets
  • smoothness of layout
  • rendering complete for an item in a page
  • if a frame dropped, what caused it to drop
  • detecting that something major changed
  • different measurements for text, rectangles, line heights
  • how to dynamically fit text into a box (such a long lived problem)
  • font loaded event

In general, we want to make things less of a black box while making the best setting default to keep things simple where possible. iOS has some things that developers can measure, but the web lacks most of this.

The panelists were asked what’s the next thing to improve rendering speed? Ideas such as parallelism were thrown around, but the panelists seem to not really know where the next major breakthrough will come from.

It was pointed out that maybe the obvious goal should be to optimize for what people want, e.g. how to make web apps fast, or how to create DOM APIs that can batch operations more easily. What would be the impact of taking away the browser’s job of doing layout and doing it yourself?

It was mentioned that it would be relatively easy to add an API for polyfilling CSS properties, but much harder to create an API to add something to the layout engine. This reminds me that it was much easier to add an oncontextmenu event to replace the browser native contextmenu than it would have been to create an API to add items to the native context menu.

One of the final points could be summarized that it needs to be easy to do the right thing, and it’s not today. This point would come up over and over again in various formats throughout the day. In this case, it was mentioned that with iOS it’s difficult to make things that are janky if you follow the default best practices, whereas with the web it’s difficult to make things that are beautiful without learning many different things.

Layout has moved to the forefront of performance issues on the web, because it is complex, not easy for average developers to understand, and is an easy source of performance and user experience issues. It’s great to see so many people focused on trying to solve these problems and provide more insight into this area of the platform. I hope that browser vendors will work hard to provide the necessary insight and functionality without requiring all web software engineers to become experts on the layout features of each browser engine.

Topic 3: Security and Identity

The next debate was focused on security and identity. First they mentioned some recent advances to the platform:

Edward Snowden was a popular point of reference. A fun slide was presented from an Adobe password data breach, showing password hints that made it very obvious what the password was.

Another question that was asked was why SSL is difficult. Some answers included that the defaults are not good for Apache, IIS, and have not changed in years to reflect best practices. It was also mentioned that there is no simple end to end service that does it all for you. And it was mentioned that it becomes a lot more complex when you have a large organization with many servers and domains.

SSL mate and Better Crypto were mentioned as useful resources. One of the panelists mentioned that he bought an airline ticket, and the airline shared the itinerary with his bank to help reduce fraud. I’ve never heard of this, and could not find any details online to support his statement.

To the question, does the need for performance interfere with security, the answer provided was Is TLS fast yet.

Security and privacy have become beyond critical topics for the web, and we cannot move quickly enough to a web where everything is encrypted. In order to realize that vision, it needs to become much easier for people to enable SSL on basic web sites, and to encrypt communications. This session did not cover email, which is another big gap in the general need for secure communications.

Lunch

We then had a lunch break. I spent most of the lunch hour chatting with Wilson Page of Mozilla and Rob Dodson of Google, talking about Web Components, Polymer, Dijit, and Intern.

Topic 4: Package management

After lunch, the topic switched to package management, Domenic Denicola set the context by briefly explaining some key terms:

  • Modules: Reuse code, separate code
  • Packages: Distribute code
  • Registry: Where packages are hosted
  • Package manager: Helps install packages from a registry with its dependencies.

And then the discussion moved into how we have not really agreed on things for the web. Depending on your perspective, modules and packages are different things or not.

Encapsulating assets on the web was discussed as if it was difficult, but I think it’s mostly the issue that there’s nothing like a war file for bundling different types of resources together (nor should there be probably).

Different dependencies require different versions of the same package. And what if the package doesn’t use semver? I was pretty surprised to learn that the answer to confusion around pre 1.0 version numbering is to state that all projects should now start with version 1.0.0. That seems like a really bad idea, as historically, pre-1.0 meant that the API may still have pretty major changes.

There was a significant amount of back and forth on topics such as web components, the focus of package managers, why npm should or should not be the package manager for the web, why we have been unable to standardize on package.json, should the package manager provide insight on how to discover documentation, and more.

That said, the key takeaway for me in this space is that too many people have very specific opinions and have little incentive or reason to change their perspective. That has led to significant fragmentation, which unfortunately is not likely to change in the near future unless someone invests time and effort to solve a complex problem. Until then, the divergence of both module formats and package managers is likely to continue for the foreseeable future. And even then, the problem would be solved for the web, but may not integrate with existing package management solutions in other languages, e.g. Maven for Java.

Topic 5: Image formats

The next panel was focused on image formats. This topic wasn’t as interesting to me, so I spent this time doing a hallway track within a hallway track. Discussions were had about Dojo 2, web components, Intern, and Angular.

Breakout sessions

The next hour was spent with everyone standing in four groups, one for each of the four panel discussions from earlier in the day. I’m not sure how effective this format was, as it meant that you had about 200 people all talking in a relatively small space near each other. It’s a good idea, but I think maybe some separation between the groups would have helped a bit.

Topic 6: Standards and the Extensible Web Manifesto

The final topic of the day was intended to bring everything together. This was a talk about what works with the standards process and what is broken, and the move to try and make everything possible for developers. One of the panelists was from Intel, where they are working on exposing device APIs to the web.

The standards process is still broken. In many ways it reminds me of politics. The problem is, if you compromise, you end up with badly neutered standards (e.g. Promises, ES6 modules, ES6 Classes) and if you don’t compromise, you end up with a specification that isn’t vetted and only works well for a single vendor (e.g. AppCache).

In general, things take too long, and even after the process is supposedly done, people can still derail it. Some argue that you cannot have good standards until you have good experiments and implementations. Others argued that there’s already too much fragmentation. And the debate continues…

Conclusion

This conference is really well run and the content is very high quality. While this format would not work for everything, it’s an excellent way to get many intelligent and passionate people in the same room sharing and collaborating to push ideas to reality. More events structured like this may be just what we need to help further the progress and possibilities of the open web.