I went to Edge conf yesterday; it was a fantastic day of meeting smart people and discussing the present and future of the web. Props to Facebook for superb hosting of the event and a big thank you to all the organizers.
The day was broken into four panels followed by three sets of “Break outs”. The day was accompanied by a Slack channel for discussion of the topics at hand, with questions in the chat often being fed into the panel discussion. This meant a very quick-fire exploration of the theme in which everyone had a say.
The first panel was on security on the web, moderated by Dan Appelquist and opened with a talk from Yan Zhu on why security is hard and what we can do about some common cases. Yan’s concern was that security is too damn hard and boring. A quick summary would be use CSPs and SSL everywhere.
The discussion mostly revolved around, the main sticking point for a lot of developers when trying to implement HTTPS, external sources not using HTTPS and causing insecure domain warnings. The solutions suggested ranged from carrots to sticks; ranking secure content higher in search results, only giving new web features to secure domains, and slowly deprecating features from HTTP sites. It was agreed that more pressure needs to be applied to ad networks to get them to move to HTTPS.
According to the panel getting HTTPS easily and for free will become a non-issue in the near future, with the release of LetsEncrypt. There was some concern that even though the process has been reduced to a single command it’s still not easy enough for the standard user.
The front end data panel was lead by Jake Archibald with a keynote by Nolan Lawson. The keynote started with a long list of the types of storage available to the front end developer and then went through a list of applications of front end storage. Just some examples were the php.net autocomplete box, the Chrome Dev Summit site, and npm-browser.com. The point being that using local storage can lead to some really cool websites and slick experiences. It was also to show how a lot of people don’t realise the capabilities of the web.
IndexDB was easily the most popular topic, if only to complain about it. The panelists suggested that it has a low level API, which, while definitely not perfect, isn’t supposed to be used manually and should be smoothed over by libraries (à la the extensible web).
There was also talk of how trustworthy front end data is. Firstly it can be cleaned up by the browser/OS whenever it decides it needs that space. A user could also accidentally remove the data when clearing browser cache or similar. The conclusion was that there needs to be drastic improvement on the usabilty of front end data by the end user. Whether that’s on a per app basis or a browser implementation, users need more information and control over what the browser is storing, especially when there’s large amounts of data involved.
Another concern was security. How can you be sure that the local storage hasn’t been corrupted through an XSS, for example. Questions were raised such as “Should we be encrypting all local storage?” and “Should we have mechanisms to clear all local data?”.
There was a lot of interest in the potential for shadow dom to hide complexity and the modularised model the web could move towards. However the discussion was dominated by the problems with Web Components in their current state. My take away was that web components are in no good state to use today and they might not be for a long time. Problems include:
ismay not make it into the spec.
The final panel of the day way moderated by Lyza Danger Gardner and keynoted by Remy Sharp. This was probably the most discussed item of the day, being an important undercurrent in almost every session.
Remy’s keynote started by explaining how the term progressive enhancement is often geared towards the lowest common denominator and is more often than not defined as making something work without JavaScipt; unfortunately these misconceptions are widely spread. He continued to talk about examples of apps that can and can’t work without JS and explaining why that can be fine.
The core to progressive enhancement is deciding what is core functionality and what is an enhancement, and setting your own baseline requirements to satisfy the users needs.
There was a lot of great discussion that would be too long to summarise in this post so I recommend having a skim of the notes.
The key takeaways were, however: