ZendCon 2014
27 - 30 Oct 2014 at Santa Clara, CA Convention Center

Another perspective to look into things. Good info.

ZS ZRAY could be a breakthrough. Anticipating to see it rolled out in the South East Asia.

Not very relevant and the speaker was not engaging, I'll also reiterate the first comment about giving that guy some cough drops!

Focus from the surface is very useful. Opens the mind to look at legacy codebase differently. Might save some bucks in attempting to rewrite a codebase. Requires in depth understanding to make real changes into a working team.

Great talk and great points. Kept me laughing considering I've experienced every scenario pointed out. It's easy to fall in to the 'it's good enough for internal users' mentality, but presenter gives very valid reasons to avoid the though patterns that promote that mindset. I enjoyed it very much.

I hate to be the dissenting voice here, but I felt that this session was more of a mixed bag than the other commenters. I've been working on web applications for 15 years now, and some of the tips and tricks mentioned will cause more problems than it will fix.

* Require.js: Using Require.js or another AMD javascript framework can definitely help -- in fact, I use it quite a bit. However, as the number of JS modules you use increases, the number of javascript files loaded increases, which causes the file download bottleneck issue again. That's why require.js has its own compiler/minifier to create one built javascript file, which is what is considered best practice for production by that project.

* Using iframes: I tried to find information after the session to see where using iframes were considered a "best practice" and failed. While it is true that using iframes will allow you to use multiple CPUs, I would contend that writing an application that *needs* multiple CPUs to perform well is a sign that something is wrong and not that iframes should be used.

* Inline CSS: First, we should differentiate "inline CSS" from "embedded CSS". Inline CSS is the act of modifying an HTML element with a style attribute. Embedded CSS is the act of using a <style> tag in your HTML, preferably in your head element. Embedded CSS is useful, especially when the CSS modifications are small and/or critical. Google's PageSpeed Module for Apache actually helps you do that automatically. Inline CSS, however, is much more controversial to use. If performance is your *only* metric, then perhaps it would win out. However, from a maintainability stance, it is making things harder to read and alter. Additionally, code running from other servers that have HTML5's Content Security Policy enabled will have problems -- by default, inline CSS is not allowed for CSP.

* Refresh/Reflow: This is a minor point, but frustrating nonetheless. Of the three reference points for this, one was from 2009 and another was from 2008 (and actually stated that it was most likely out-of-date!). This is a lifetime ago for browsers, and putting it into the session references seemed odd.

* CSS and browser-specific prefixes: There are a number of viewpoints on this, but a blanket "avoid" may not be the best idea. CSS animations are much MUCH more performant than trying to animate with javascript. Some of those animations are only written as browser-specific prefixes. I would suggest that developers know their userbase and code their CSS accordingly (if no one uses IE in your userbase, it would make sense to remove the 'ms-' prefix). I would also suggest using a CSS pre-processor to help with making your CSS more efficient such as Sass (http://www.sass-lang.com/) or Less.js (http://lesscss.org/). However, using a CSS pre-processor could be a session unto itself.

Finally, I felt the answer to the question asked at the end regarding how to implement this seemed more difficult than needed. The answer (as I heard it) was to have a script during deployment to rename or symlink files that need cachebusting and then to modify all html to have this cachebusting hash or number added to the files found. This seems like a dangerous way of handling this. I would suggest having a configuration variable that can be read by the application (e.g. $cssNum). Then if the configuration variable exists, the view that contains the filenames for the possibly-cached files can be modified like so:

<?php $cssFile = ((null !== $cssNum) ? "app.${cssNum}.css" : "app.css"; ?>

This allows the file to be given a cachebusting number only if the configuration is there (like in production). From there, it is easy to add a mod_rewrite rule to remove numbers from css or js files (this example found at http://html5boilerplate.com)

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+)\.(\d+)\.(bmp|css|cur|gif|ico|jpe?g|js|png|svgz?|webp)$ $1.$3 [L]
</IfModule>

While difficult to explain the details in a QA part of a session, it still would be something to use instead of modification of files as part of deployment.

Best talk of the day, clearly demonstrated common problems and solutions that were east to follow

The talk itself was good but I agree with the others, the topic does not fit a developers' conference.

Great talk. Mike was obviously very knowledgeable, while keeping the technical information light and fun. A lot of things to think about and investigate when I get back home.