It's a strange old time. In the middle of lockdown, my wife and I were expecting our second child, though we weren't quite expecting her this early. Two and a bit weeks before her due date, our littlest one arrives and I down tools to help. It's been a wonderful few weeks that I won't forget.
It did catch us all off guard though, as I'd been expecting to be part of a least another week's worth of the tech world, and then there was MS Build after that, and loads more. So, as I still scrolled through Twitter whilst seeing if she'll sleep, here's what I think I've missed in the last three weeks.
Part of my role at the office involves helping teams to code in a standardised way. We enforce this through a wide variety of tools that correct as you write (ESlint) and those that check your work (unit tests, Sonar).
To make life even easier we have a design system to standardise our HTML and CSS, and a common library of components that implement the basics of the design system in VueJS web components. This makes it hard to get the basics wrong.
Whilst making a large update to how this library is structured and compiled, I moved the library build process to Rollup. We had previously been publishing untranspiled JavaScript to apps that then had to transpile them themselves to meet our target browser support. This keeps bundle size minimal but can cause interoperability and portability problems, for example, configuring Jest is much harder.
On release day, I did a demo in front of the whole company's VueJS dev community - and the Vue build process reports that my bundle is 2MB for first load - up from 270KB!
💩
So, feeling bad that this has happened, and knowing that developers will start running into this on Monday morning, I start fixing it on Saturday night - I mean, entertainment options are limited right now.
Removing jQuery from your website is a big thing. We have become so reliant upon it that there are far more JavaScript plugins and modules that rely on it than that don't. You have to be so careful when we try to remove it, or you'll end up losing functionality. We need to plan to remove this code - we need to know what could break when we take jQuery away, and we need to know what holes we will need to plug to make our code work again.
HTML5 video players are incredibly useful, enabling developers to display video on non-flash devices (I'm looking at you, Apple). It's really simple to get started with HTML5 video, but when you want to do something more complicated, there's not much documentation. Thankfully, it's really quite simple, and this article will show you how to use the HTML5 video JavaScript API to interact with the videos.
February 2012's London Web Standards event at Forward London was an introduction to Node.js, the server-side javscript framework designed for high concurrency and real-time events. There were two sessions at the event, George Ornbo (@shapeshed) giving an introduction to Node, and a "Node & Tell" session, where four sets of developers came and told the gathered crowd how they'd been using Node in their work.
In my work, I'm parsing web services all of the time. Most of the time, they're XML, which does not make the best use of bandwidth/CPU time (compared to JSON), however, if it's all that you're given then you can certainly get by. I've been looking into ways to speed up the XML document traversal in with jQuery after the current best practice method was removed.
If you've developed for Microsoft's SharePoint before (I'm talking about 2007 here, but this applies to WSS2 and 2010 as well) , then you'll know that you can reach the limits of it's functionality very quickly. This is a big problem if you're making a zero-code solution, i.e. you have no access to Visual Studio and can't create web parts. This is more common than you'd think, especially in large organisations that use SharePoint extensively. For this, the only choice is to use SharePoint Designer 2007 (SPD), but it's not pleasant because, frankly, SPD sucks. I've not found a program that crashes as much as SPD, or that performs so poorly when presented with the most basic tasks. If you make a page that is too complex, has too many web parts, large data sources or lots of conditionals, connections and filters, it can take anywhere up to 20 minutes to perform a single action.
Web applications are the next big thing in the web. Being able to take web sites and make them run alongside native apps, having them work offline and perform just as well as their native counterparts is the next step along the road. As usual, with all new technology, there are some limitations.
Last night was London Web Standards' April 2011 event, Fun with JavaScript. Speakers Rob Hawkes of Mozilla and Seb Lee-Delisle of Plug-in Media came to talk about all the fun stuff you can do with JavaScript, canvas, and HTML5. Sketchnotes for both talks are below.
This week, Roger Johansson of 456 Berea Street posted about unique IDs in web applications. I read this and thought, "you're right, they should be unique, but what if you've got an AJAX repeater?" By this I mean when I'm loading functional parts of my application that I'll be referencing with JavaScript again, do I have to maintain a unique ID? Surely it knows what I added last or how to make them into an array?
With the impending release of Firefox 3, a new chapter to "browser wars" is upon us. In this short series, I'll be looking at what each browser offers to a user, and hopefully pick a champion.
