9:30am start for a Saturday conference is too early
Bit of a rambling opener from Telefonica talking about their experience building a new FirefoxOS phone. There didn't feel like a massive takeaway. I guess the interesting thing is that they are tackling traditional embedded device OS issues via standard APIs.
Bit of a rambling opener from Telefonica talking about their experience building a new FirefoxOS phone. There didn't feel like a massive takeaway. I guess the interesting thing is that they are tackling traditional embedded device OS issues via standard APIs.
Now; release the evangelists!
A slicker talk from a professional speaker (which also brings with it an agenda). However some interesting stuff about moving meta viewport from a vendor hack to a CSS standard, which brings with it a lot more flexibility in terms of defining how you want to use the screen.
Also some interesting pieces on new units of measurement that are relative to the viewport of the device (vh, vw) and for relating an item to its container.
However it lacked any idea on current state of support beyond being flag enabled in Webkit.
The last couple of talks were pretty poor. Essentially just talks through upcoming APIs that browsers are adding. One was about exposing O/S IO to the browser and the other about the ServiceWorker API which allows the interception of requests.
It feels like being in an enterprise conference where people are telling you about the cool features in the upcoming version 2.3 of an API.
Pretty good in-depth talk on what the IE team have been doing to think about performance on rendering
Lots of graphs and charts but no context which unhelpful. However if true then there is an interesting point that using multiple frameworks in a site creates JS garbage collection issues due to the large number of of objects the frameworks create on initialisation.
Wifi at the venue is getting too flaky to keep on posting, the dropping and connecting is also burning battery. Offline wins again!
The moderation of the panel was pretty shambolic and there wasn't really a plurality of voices. One question in particular on whether HTTP 2 had implications for responsive design was particularly cringeworthy.
There was an interesting tension between minimalism and maximalism at the conference. A lot of browser vendors were talking about testing with low end smart phones and restricted network speeds while at the same time evangelists were talking about controlling games and make entire devices browser controlled.
It is possible to have this massive spread of interests but then I'm not sure "the browser" has a cohesive and unifying meaning at this point.
A good point came up during the panel discussion that when technology moves on then evangelists have to start undoing the previous "best practices" that they have been teaching people.
Clearly then these weren't "best practices" but simply temporal solutions to problems.
So you get paid to work around problems and not solve them and then you get paid to work around your own workarounds. Nice work if you can get it.
The first sensible rationale for having a separate client-side build chain. You can easily undo the conventions of the previous generation of development philosophy.
A lot of the "chop" in web development is due to flaky platforms and underpinnings. Solid design choices like HTTP and HTML are few and far-between.
However web developers are eager for a miracle cure and too quick to adopt flawed approaches.
Which doesn't bode well for HTTP 2.
If a developer doesn't want to learn SQL or at least the basics of relational data they're not really a developer in my view.
The lack of ability to relate components to anything other than the viewport size is an obvious issue. I welcome anything that allows better parent-child (or rather child-ancestor) rules.
However this really should be a browser capability rather than hacked in by your build system. Media queries are under-powered, you can't fix that with Grunt.
People talking about push notifications in HTTP 2. Why are we talking about stateful protocols purely from this perspective?
If you're going to have persistent connections there is a bunch of things you could do about security and identity.
Things I learned about presenting today: animated gifs in presentations are great if you want people to stop paying attention to you and lose track of what you're saying.
Telling stories or framing parts of your talk as a story is new black slide.
There was quite an interesting discussion of why you want to use JPEGs instead of PNGs if you want faster rendering on browsers.
You have to consider not just the disk size but also the uncompressed size in memory when the browser is rendering the page. A smaller in-memory data size means that the image is quicker to blit to the GPU for rendering, apparently buffer sizes between the browser and the GPU are relatively small, no explanation of why though.
Also CSS animations are graphics accelerated whereas JS ones are obviously not. Nothing radical but again illustrates how browser vendors can optimise against standard behaviours rather than hand-rolled versions.