Subscribe: isolani: weblog
Added By: Feedage Forager Feedage Grade B rated
Language: English
app  bespin  boot  browser  canvas  code editor  code  development  editor  flash  ubuntu  video  web app  web development  web  year 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: isolani: weblog

isolani: weblog

isolani: blogging about web standards, accessibility, semantic web, intelligent agents, gadgets and web development

Updated: 2015-03-24T19:45:02+01:00


Flash's slide into irrelevance


I got a new Macbook Air a year ago. In the weeks I spent setting it up as my main work machine I made the deliberate decision not to install Flash. I figured I would hit a case where it became clear I needed Flash. A year later and I still don't have Flash installed. Flash is no longer an essential plugin on the desktop/laptop Web. It is non-existent on mobile. It is no longer the default way to consume video on the Web. It didn't use to be that way, and I'm surprised how far Flash has fallen into irrelevance so quickly. For a long time, Flash had better support in browsers than CSS. SVG paled in comparison even in the realm of vector graphics. Flash's control of the web looked impregnable. How do you take on an immovable behemoth? It starts with a single blog post rant. Flash's failure on mobile The rise of mobile in the form of smartphones and tablets came with the declaration that Flash was not a welcome participant. Coinciding with the launch of the Apple iPad, in a rare Steve Jobs blog post Apple announced that Flash would not be allowed on iOS. The fallout from that decision destroyed Flash's incontestable ubiquity. This was a business decision on the long-term viability of Flash on platforms with performance and battery-life are primary concerns. In a world where Adobe pushed hard to make Flash all things for all people it went too far, every step making it less viable to the fast-approaching lower-spec mobile platforms. In effect, this was a declaration of no confidence in Flash, and in Adobe. Inside of a year there was no recognisable trace of Flash left in Android either. The days where Flash was a deal-breaker feature was over. Similar to Java retreating from the browser and emerging as a viable server-side platform, Flash tried recasting itself into the platform of choice for developing native mobile apps. But today Flash is fading into obscurity from even that avenue. Flash's reversal on the desktop In the desktop/laptop Web Flash has lost the prominence it once had. The binary Flash plugin is no longer an essential part of the Web browsing experience. Flash grew as a sandboxed environment inside the browser page to deliver rich content and engaging interactivity and cutting edge user interface. It prided itself as being a platform for building Web applications that couldn't be built with HTML and CSS. Scrollable and zoomable maps, playing video clips, animating vector graphics, playing games, streaming content. Flash enabled all that. But it was video-on-demand that became Flash's killer feature. The single page app didn't take off (unfortunately loading pages did, much to the disgust of visitor advocates). Over time, Flash was gaining a bad reputation for security issues and as a performance hog. Apple was critical of Flash and took the step into pushing the Flash runtime into a separate process so as to allow it's Safari browser to continue serving up web pages and continue being responsive. By separating processes it made Flash's performance issues more visible and measurable. Google Chrome dealt Adobe a blow by developing PepperFlash as an Adobe Flash runtime replacement. It is not as fully-featured as Adobe's flagship product, but on today's Web mostly about video, video-on-demand and live-streaming, Chrome's alternative is perfectly adequate. Even SVG has better out of the box support than Flash in browsers today. Flash trounced SVG in developer mindshare, and now it is SVG that survives and flourishes in the age of improved user-experience on both the Web and User interfaces. SVG has the last-ability Flash could only dream of, tackling user experience polish that Flash was primarily designed to enable. Flash losing video-on-demand Adobe turned Flash into the ubiquitous runtime for supporting cross-platform video-on-demand. The MPAA's (Motion Picture Association of America) insistence on DRM in principle, but no particular implementation created a headache Flash cured. Flash supported the mainstream DRM systems and thus became indispensable for vide[...]

Web App Mistakes: Condemned to repeat


The first two talks at this year's Full Frontal conference were extreme position pieces arguing about the relevance of HTML in building webapps. They were sparked by the growing number of web app frameworks that start off with an empty HTML document (or a series of nested empty div elements), such as the first version of SproutCore used prominently by Apple's failed MobileMe website. As my good friend Steve Webster describes SproutCore's development approach at that time: SproutCore doesn't just ignore progressive enhancement - it hacks it into tiny little pieces, urinates all over them and then mails them back to you one by one (Note that these frameworks have a track record of ignoring established web development best practices, and then attempt to bolt them back in later. Meteor is also heading down the same cobbled path, they added Google crawlability as a feature in later releases.) Enforcing imperative development The list of Web frameworks that perpetuate the empty-document technique grows; SenchaTouch and Meteor being two garnering attention today. John Allsopp notes the approach is about replacing a declarative set of technologies with an imperative model. Thus the idioms and patterns are quite different. The core of the argument is that apps built using web technologies are being left behind by app-specific development toolkits, and that web technologies need to improve to be better than these toolkits. Trying to succinctly express this runs headlong into absurdity, perhaps not through reductio ad absurdum: Apps built with app-specific technology are better apps than those built with non-app-specific technology. Obvious? But more pertinent is the question: so what? The Web's declarative model is what keeps the barrier of building websites as low as possible. (And web apps are just websites, just with a lot more JavaScript.) The shiny toy syndrome And yet, James Pearce's talk at FullFrontal 2012 kept plugging in this direction, resulting in this particular example of HTML minimisation: That is the entire HTML document for a web application. It's hard to understand whether this is a tongue-in-cheek, or a foot-in-mouth argument. Claiming it as just an extreme example of a web app and not meant for real world use is disingenuous; people seem compelled to use these odd curiosities in real world products. Take the "lets reimplement the browser in Canvas from scratch" noodling of Bespin. As the HTML5 Editor (at that time) Ian Hickson noted: Bespin is a great demo, but it's a horrible misuse of . Or Henri Svionen's less succinct, yet still brutally accurate: I think Bespin can be taken as an example of using being "doing it wrong" and the solution being not using . Despite this regular feedback, it still took the Bespin / SkyWriter developers a few years of fighting with performance and usability issues before they moved away from canvas. In that time, not least because of the initial attention Bespin received in tech circles, the "canvas as the browser" approache started to gain adoption as an acceptable way to build web applications. Bespin was no more than a proof-of-concept never intended to be used in a production setting (according to its developers). Doing it right the hard way Of course, modern web developers using new fangled content-less HTML aren't making the same mistakes as Bespin and SproutCore. Their conceptions reflect web development best practice; of a separation of concerns (for stability), progressive enhancement (for wide device compatibility), graceful degradation (for robustness), accessibility (as an extreme usability utility). Right? In the far-too recent past, web app developers jumped on the HashBang URLs as the technique that exemplifies the applification of the Web. Despite it being contrary to web development best practice, single-page webapp developers persisted with this technique in the name of better performance and more robu[...]

Ubuntu 12.04: Solving slow boot times on Toshiba NB300 Netbook


I picked up a Toshiba NB300-108 for just under £70 on an ebay auction a few weeks ago, and decided to clean install Ubuntu 12.04. True to form Ubuntu installed flawlessly. But, there was one annoying problem. It took about 5 to 7 minutes to boot.

It’s taken a couple of days of hacking around, trashing Ubuntu and re-installing it, but I’ve gotten to the bottom of the issue. Most of the 5 minute boot sequence seems to be the laptop just sitting there waiting for something to happen, there’s only a tiny amount of disk activity going on.

The first step is to figure out why the boot process is so slow. So in a Terminal, run dmesg which displays a timestamped log of each subsystem initialising. The timestamp counts the number of seconds from power on. Looking through this list I saw a huge leap in seconds (about 350 seconds), and that line said:

[  352.885250] ADDRCONF(NETDEV_UP): eth0: 
    link is not ready

Turns out Ubuntu can’t quite deal with the Ethernet card (possibly a Realtek network module). Opening the “Connection Information” in the Network menu (top right icon of up-and-down arrows) identifies the network card driver as r8169.

The solution turns out to delay the initialisation of the Ethernet card, removing it from the boot sequence and adding it to the rc.d initialisation. Here’s how to do that:

First we blacklist the card from the early boot initialisation steps (all on one line):

echo "blacklist r8169" | 
  sudo tee /etc/modprobe.d/blacklist-ethernet.conf

Second step is initialising it by editing /etc/rc.local and adding in modprobe r8169 just before the exit 0 line:

modprobe r8169
exit 0

Thirdly we need to rebuild the boot image to take into account the newly added blacklist item, so run the following:

sudo dpkg-reconfigure linux-image-$(uname -r)

Once that is done, reboot the laptop.

For me that reduced the boot time to 38 seconds, so a reduction of about 90%. There’s still a couple more seconds to be saved by disabling the ipv6 and parallel port support, but that’s for a rainy day.

Related links

Full Frontal 2011 - My Notes


Another November, and the third Full Frontal one-day conference took place at the Duke of York cinema in Brighton. Last year's conference was fairly interesting, if a little demo-heavy. This year's seems geared toward development tools and web applications. The headline speaker was ex-Yahoo Nicholas Zakas, but the supporting speakers were more impressive and fresh. Most interesting talk was Jeremy Ashekenas' CoffeeScript Design Decisions - which surprised me somewhat considering my opinion on the impracticability of CoffeeScript in a real-world web development team. I was also pleasantly surprised by Rik Arends' talk about the Cloud9 IDE. Phil Hawkesworth's talk was eminently listenable, but unfortunately impossible to live blog. Eloquent JavaScript author Marjin Haverbeke was incredibly interesting, but perhaps too technical for a conference talk. The final two talks, from Brendan Dawes and Marcin Wichary were both entertaining and (more importantly) inspiring. Glenn Jones provided us a very useful look at almost-ready features of browsers as a platform for sharing data. And Zakas rolled out a two-year old talk. CoffeeScript Design Decisions by Jeremy Ashkenas I covered Ashkenas on CoffeeScript Design Decisions in a separate blog post. It was that interesting and bloggable. Respectable Code-Editing in the Browser by Marijn Haverbeke Marijn Haverbeke talks about code editors in a browser; basically glorified text areas. Text areas themselves are too primitive for building a code editor on; indentation is unworkable, and good luck finding which line of your code you are currently on. The code editor in a browser received a massive boost from Bespin, a code editor written entirely in canvas, and basically recreated every pixel of a UI. As a demo Bespin was interesting, but using canvas is inappropriate solution. Thankfully this abysmal mess of inaccessibility is now mostly abandoned, and the code editors that have arisen from this work are well on track to being more conducive to the web environment, and more perceptive of the DOM. One significant limitation of canvas is its portability. So far there are only 3 serious implementations of in-browser code editors: ACE, which took the good parts of Bespin, and with new techniques it is much faster and more portable than Bespin. Orion, which is an Eclipse project, uses content editable / design mode as a basis. CodeMirror, which is Marjin's project. Currently in its second iteration. All three are open source projects, and to date there isn't a single commercial implementation of a browser-based code editor. Marijn is the sole developer behind CodeMirror. The first major version of CodeMirror used content-editable (or design mode); this is a browser supported mechanism of inline editing. But Marijn found the feature both underspecified and the browser support buggy or unsuitable for building a code editor. Issues ranged from Internet Explorer inserting paragraphs whenever it could, to the general unavailability of useful events. The original version of CodeMirror grew out of Marjin's previous project, an online JavaScript book called Eloquent JavaScript. The book contains exercises and demonstrations of JavaScript, code that could be written and run inline on the page. For the book Marjin's solution of a Firebug-like textarea console and output window worked. He later added colour syntax highlighting by overlaying the text area with coloured text DOM nodes, but this turned out to be too slow with the pure JavaScript DOM changes. This gave rise to the first version of CodeMirror. After content-editable proved insufficient (code folding was impossible, for example), Marjin started version 2.0 of CodeMirror which was based pure DOM. He limited the size of the DOM by creating a viewport of the document, so only the visible part of the document needed to be rendered on page, thus speeding up the overall rendering of the document. Marjin calls this a fake edi[...]