My past year as a HTML5/Javascript developer… Part1
I’ve been fairly mum on work for the past year, but I figured I should do a brain-dump of some of the things I have learned and experienced as a HTML5/Javascript developer.
Before we begin…
(feel free to skip this section if you don’t care about my disclaimer or full disclosure)
I feel like I should start by explaining a bit of my perspective. I’m not a traditional front-end web developer. I come from a long history of server-side rendered web development primarily using Microsoft technologies such as ASP classic, ASP.NET, et al.
Having said that, I have spent over 15 years jockeying around HTML, images, css, and yes, lots of Javascript. Back in the days when IE 4/5 won the browser wars, I was fairly successful building Javascript frameworks to power enterprise apps and extranet sites of varying sorts. Not that javascript/html development was great (it was quite bad actually) but everything got much worse after that once Microsoft lost their way and then the browser-wars erupted anew. During those bleak years I dabbled here and there with client-side dev but overall I was generally jaded towards treating JavaScript as nothing more than glue and spackling to smooth the cracks in my server-side rendering. Frankly, before this past year I hadn't even really thought of Javascript as a first-class language.
So, now having built a fairly complex real-time stock trading app targeting only modern browsers using the latest HTML5 & Node.js features (and no Microsoft technology in sight), I want to break it down a bit and think about what I have seen & done.
State of HTML5
It amazes me every day how far browsers and client-side webdev have come since the late 90’s when I was involved more with startups. The problem is that with new features and capabilities comes new compatibility problems.
The good:
- Enhanced Selectors
- session/localStorage
- Canvas
- SVG
- structural elements
- CSS transformations
- History navigation
- WebSockets
- WebWorkers
- video element (*codec support notwithstanding)
- audio element (*codec support notwithstanding)
- Html Editing
- MathML (*a cautionary ‘good’ at this point)
- WebFonts
The bad:
- new form fields and validation
- File API
- Drag and Drop (*bad mainly due to its mobile challenges)
- Full Screen (*mainly IE’s fault, but tablets also fail)
- Server-sent events
- Security sandboxing sub-apps
- WebRTC
- WebCam (*very experimental in most browsers)
Sure, there are a handful of really great HTML5 technologies that are functionally equivalent across Mozilla, webkit, and IE10 but the devil is in the details. If you are building fairly simplistic or single-purpose apps, you are fine, but as soon as you start trying to build something ‘interesting’ for a large audience you will quickly find that there are still important performance issues that arise. Add the shift to mobile and the plethora of new platforms such as Television and Gaming devices and the list of ‘good’ starts to get much shorter and muddled.
The holy grail of build-once-use-everywhere is still elusive with the need to adjust form factors for mobile devices and pair-down payloads to help meager bandwidth and processors. Sure, the very latest tablets and phones are now quad-core or better with even more RAM but their performance are still network and IO bound for the most part. This, plus the varying CPU performance leads to major issues with race-conditions and other fun device-profile issues.