HTML5 Rocks Updates

Please post the full code and configuration you are using. Your results don't match what I have seen nor the expected results.

Some notes:

- Socket.IO supports several different transports, including AJAX. To have persistent connections you need to make sure that you are using WebSockets (native or Flash) as your transport. Are you certain that you are actually using WebSockets? Socket.IO attempts to automatically pick the best transport and unless you verify, the only difference you will see is lower performance.

- You need to compare Socket.IO using AJAX as a transport, vs raw AJAX so that you can control for how much overhead the Socket.IO library (client and server) is adding to the test. Actually, comparing all the Socket.IO transport options would be useful. Doing a Socket.IO disconnect is not a good way to trigger a non-persistent transport in Socket.IO; you are likely causing both client and server to do a bunch of extra cleanup (Socket.IO has some advanced features that require tracking connections/channels/etc).

- If Socket.IO is using WebSockets as your transport, then your "Socket.IO non-persistent" test is still testing WebSockets, not AJAX or one of the other real non-persistent connections. I would not be surprised that WebSocket connection setup and teardown might be slightly slower than AJAX connection setup. HTTP connection setup has been around since the beginning and had a lot of time to be optimized. WebSockets are relatively new and connection setup…

First I would ditch any notion of teaching back end programming and focus on front-end only [0]. The things you can do with, and are required to learn and master to be good with, HTML/CSS/Javascript are so extensive and deep that alone could be overwhelming to people new to web development. So, first and foremost just focus the course on frontend technologies (and feel free to use things like Coffeescript or Clojurescript instead of Javascript, they probably make better teaching languages than the wtf-laden JS).

Also, if 2/3 are non-CS majors, you're going to need to teach basic problem-solving and analytical thinking skills. Teach and reinforce the basic problem solving process of taking a complex problem (or programming objective) and breaking down into its component parts, solving each, finding multiple solutions if possible, then building it back into a whole again. Set expectations of multiple possible answers, of hacking at the problem till you start grokking it, etc. It's not about getting that one right answer, it's about getting something that works then continually improving it. Learning programming carries a lot of frustration which can be very off-putting and demoralizing, so ingraining the expectations, problem-solving skills, and habits needed to overcome that is crucial (and also a super general life skill).

Look into using platforms designed for teaching like Processing [1] and its JS version Processing.js [2]. Also see if you can find…

So, there is a cheap way to communicate between the DOM thread and web worker threads. It's called Transferable Objects. The technique involves postMessage()'ing a Typed Array's ArrayBuffer as your message payload. Rather than making a copy of the bytes in your sending thread's Typed Array, the byte buffer is "detached" from the sender's ArrayBuffer and "attached" to a new ArrayBuffer on the receiver thread. This allows you to do huge bulk operations on a worker thread, generating megabytes of data for the DOM thread and not taking a penalty of allocating memory, copying the data, and garbage collecting a big allocation on the sender thread.

Transferable Objects are not as useful as, say, being able to access the DOM from a worker thread. But there are many tasks that ultimately feed DOM updates, are data intensive, and could be mostly offloaded to a worker thread with the final update payload fed to the DOM thread via Transferable Objects.

http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast

The DOM/Layout/CSS is a crufty document engine. Is it reasonable with today's hardware to have a 60Hz scroll rate benchmark of quality? I think expanding mobile main memories and CPU advances this decade will make it more reasonable.

How about framelocking us to 30Hz on mobile, could we be satisfied with that? Makes me wonder if there is a way to framelock a browser scroll with requestAnimationFrame().

-- edits clarifying ArrayBuffer

To review, it would seem that while you have a blog post from ian hickson making a passive reference to deprecating smil. Indeed he followed up by removing the feature from the ACID3 test. But the damage was already done:

evidence of actual standards activity and implementations from as recently as June 2014 show instead an active merging of css animation with svg animation into a single consistent model called "web animation" [1]

the implementation of this merging effort in chrome's blink rendering engine [2], and a rationalisation for this webanimation effort that promotes not a removal of the svg animation features (which are already implemented in everything but IE), but an expansion of their powers, being advocated by both google and mozilla [3]

Just because IE is lagging behind doesn't mean this feature is cut. Just because Ian Hickson says the feature is deprecated doesn't mean that it is, or that browser devs will follow whatever he says.

What it does mean though, is they are attempting to cut the feature's dependence on "SMIL", while retaining the currently implemented features. so I think that whatever works in browsers now, you can more or less rely on that working in future browsers as well. So yes, my suggestion is still useful and it's still awesome. And if you use css animations inside the svg (which totally works) instead of svg-smil animations, you can even get it working in IE10

[1]: http://dev.w3.org/fxtf/web-animations/

[2]:…

The abuse considerations were what led us to implement the engagement check. An API for this would absolutely be spammy.

If everyone is going to be calling it on every page-load, and if the browser is (predictably) not going to allow that to show every time (see window.open()), then why provide an API when we could just treat meeting the criteria we'd look for anyway as the same thing as calling such an API?

That's what the Chrome system does: you've implicitly called "addToHomescreen()" on every page load where your app meets the criteria. When we allow it to show is still mediated by the browser.

Chrome 44 is going to allow a measure of control: http://updates.html5rocks.com/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android#cancel

The event is cancelable, meaning that if you don't want it to show on a particular page, it'll trigger again on the next. We'll also be adding a way for you to delay the load; cancel and re-trigger inside the same page. The way to think about it is that you sometimes get a golden ticket. We'll give you the ability to spend it when you want in the near future, but making you do an API call when the intent is already clear just seemed like bad design.

In my humble opinion the best solution for layouts is CSS is the CSS Grid Layout Module[1]. Both powerful and easy to grasp. Sadly, it works only in IE (from version number 10, I believe)[2], but others[3][4][5] are getting there. And, of course, there's a polyfill[6].

1) http://www.w3.org/TR/css3-grid-layout/ - specification;

2) http://ie.microsoft.com/testdrive/graphics/hands-on-css3/hands-on_grid.htm - examples;

3) http://updates.html5rocks.com/2014/03/Get-on-the-CSS-Grid - Chrome/Opera/Blink;

4) https://bugs.webkit.org/show_bug.cgi?id=60731 - Safari/Webkit;

5) https://bugzilla.mozilla.org/show_bug.cgi?id=616605 - Firefox;

6) https://github.com/codler/Grid-Layout-Polyfill - JS polyfill.