Javascript
Microfrontends should be your last resort
In large tech companies these days, it is becoming common for front-end developers to talk about “micro frontends”. MFEs are analogous to microservices in backend systems. But just like we’ve all seen bad microservice architectures that simply worsened a distributed monolith, a bad micro-frontend architecture just spreads tightly-coupled code across many moving parts. My argument is not that MFEs never pay off their complexity. I think that for a sufficiently large team, with well factored domains, having separate pipelines within a monorepo arrangements is a reasonable design for keeping teams moving independently.
May 29, 2023
Modern JavaScript features you may have missed
Despite writing JavaScript almost every working day for the past seven years, I have to admit I don’t actually pay that much attention to ES language announcements. Major features like async/await and Proxies are one thing, but every year there’s a steady stream of small, incremental improvements that go under the radar for me, as there’s always something bigger to learn. So in this post, I’ve collected some modern JS features that didn’t get much airtime when they first came out. Some of these are just quality of life improvements, but others are genuinely handy and can save whole swathes of code. Here are a few you might have missed:
October 26, 2019
Parcel.js aims to make web development simple again
In the beginning, there was HTML, and the tag was <script type='application/javascript'>. With this little incantation a website author - or ‘webmaster’ - had the power to launch his or her visitors on a fantastic journey to infoscapes hewn from pure imagination. Exhilarating games, virtual shopping malls, columns of animated flames and those little visitor counters you never see any more. All powered by the humble <script> tag. OK, so the web of the 1990s and early 2000s wasn’t terribly elegant. But it was very easy to develop websites. All you had to do was plop some files on an Apache server and point a bit of XML at the appropriate resource. There was no notion of modules, or bundling, or minification, or code splitting. No Gulp or Grunt or Webpack or Broccoli. Just plain old HTML. What if I told you there was a way to make webdev simple again?
June 10, 2018
Why is Front-End Development So Unstable?
We all know the meme: by the time you’ve learned one front-end technology, another three have just been released. Also, that one you just learned? It’s deprecated. What we don’t often see is an examination why.
May 29, 2018
The JavaScript Single Var Style Is an Antipattern
I hate the single var style in JavaScript. For the sake of clarity, I’m talking about this: var alpha = 1, beta = 2, gamma = 3; It’s awkward to write, annoying to debug, misleading to read, and utterly unnecessary in 2017. Allow me to explain why.
January 28, 2017
Reactive Views in 500 Bytes
If you can use ES6 template strings, you can write reactive, componentized views using less than 500 bytes of helper code. Let me be clear. This approach isn’t intended as a serious replacement for React+Redux/RxJS. It doesn’t re-render views very quickly and the way it handles events is verbose. It’s simply an experimental way to write light, simple applications that need to load fast, without the hassle of transpiling JSX or rendering on the server. I’m sharing it as a curiosity more than anything else.
March 5, 2016
Spying on Third-party JavaScript
Very rarely, it is useful to intercept calls to hidden methods on third party scripts. I had recent need of this when I wanted to spy on calls to DFP’s undocumented googletag.debug_log.log method, so that I could report detailed advert timings. But working with undocumented APIs is always treacherous – those methods can change or disappear at any moment. We need a safe way to spy on third party code.
December 13, 2015
Ghetto Dependency Injection
So, you’re writing a piece of JavaScript that you want to test, but it has dependencies you need to stub or mock out somehow. You know that dependency injection would be really handy, but you’re not sure how to do it. You might have heard about JavaScript IOC containers like bottle or Intravenous. You may have also heard of Jest, which lets your tests inspect and override the behaviour of require. Let’s say, however, that right now, it’s just not appropriate – you’re writing something small, you’re writing something quickly, or you’re writing something before you have the chance to evaluate those technologies. Or maybe, like me… you’re just a lazy programmer. Look, I’m not going to judge – at least you’re testing your code, right? Whatever your reasoning, Ghetto Dependency Injection is here to help.
October 25, 2015
Writing a Non-blocking JavaScript Quicksort
I’ve recently had some fun writing a browser quicksort.
June 9, 2015
Testing Knockout Custom Bindings
In my last post, Testing Knockout.js Web Applications, I explained how to unit test a simple viewmodel using Karma and Jasmine, so you could validate the values and methods on the viewmodel bound to the DOM. This is all very well and good, but what happens when we want to bind our model data to the document in novel ways? If we can’t use the standard Knockout bindings, we need to write our own. Using custom bindings to handle view concerns is a good pattern for keeping viewmodels manageable and making view code reusable. But how can we test them?
March 23, 2015
Testing Knockout.js Web Applications
I’ve been working with Knockout.js for a few months now. I’m impressed, but one thing I’ve found lacking is much community documentation on how to test Knockout apps. I thought I’d write an introductory post on testing Knockout.js applications for those new to the idea – like I myself was, a few moons ago. What’s our goal?These days it seems that unit testing is more or less a prerequisite to any kind of serious JavaScript application development. But let’s remind ourselves what we’re trying to achieve here.
February 28, 2015
The State of JavaScript in 2015
The JavaScript world seems to be entering a crisis of churn rate. Frameworks and technologies are being pushed out and burned through at an unsustainable speed. But I think the community will adapt and adopt new practices in response. Developers will move, I believe, from monolithic frameworks like Angular.js and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk of churn and to allow solutions to different concerns to compete separately.
December 1, 2014
Some Thoughts on Knockout.js
I’ve been working with Knockout.js on a commercial project for a couple of months now and think I have a decent sense of its capabilities. However, I’ve never worked with any other web application frameworks before and wondered how others felt Knockout compared to them. So far I’ve been really impressed, but I’m not certain how much that is to do with Knockout and how much that is to do with not having to use jQuery to perform templating and update a ‘model’ that’s actually just a bunch of scattered global variables. Obviously, I’d been trying to keep a model – view distinction even with just jQuery, but the data binding alone is extremely onerous when you’re doing it manually.
November 16, 2014
A simple group checkbox for Knockout.js
I’ve been using Knockout for the first time on a new project and have been pretty impressed. Recently, I had a need to implement a simple ‘group checkbox’. The Knockout documentation already provided an example of a ‘select / deselect all’ checkbox, but the behaviour I wanted was slightly different. I wanted a checkbox that would be unchecked when its children were disabled, checked when any were enabled and would select / deselect all if I toggled it. With a little research into ‘computed properties’, it turned out this is quite easy to do.
October 4, 2014
Style only part of a line path with Raphael.js
If you have a vector line path in Raphael.js and would like to style part of it - highlighting a section of a line graph, for example - you can achieve this easily using the path.getSubPath() interface to get part of your path, then adding a new shape on top based on that pathstring.
September 21, 2014
Using jsPerf: a how-to guide
If you’re interested in testing the performance of a particular piece of JavaScript, you might be interested in jsPerf. jsPerf allows you to run and compare the speed of arbitrary snippets of JavaScript against a blob of HTML of your choice. This means you can test not just pure JavaScript, but DOM manipulation and jQuery calls too.
August 5, 2014
Protected members in JavaScript
If you’ve done much OOP in JavaScript, you can probably already simulate private member variables, by putting variables in a constructor’s closure (if not, go read this summary by Douglas Crockford). But you may not know that you can also emulate the protected status of C++ and Java — variables shared between parent and child classes, yet not exposed as public. This is occasionally useful, but is a little obscure to implement in JS if you don’t know how. The basic idea is use the ‘parasitic constructor’ pattern — where a child constructor directly calls the parent constructor — and passing in an object defined in the context of the child constructor. The parent constructor decorates this object, and because JavaScript object arguments are effectively passed by reference, the members of this object are visible within the child constructor. As such, your child and parent constructors have a ‘shared secret’ object that effectively acts as a map of all the protected members.
July 10, 2014
JavaScript function variables don't have to be anonymous
If you’ve used JavaScript much, you’ll probably know one of its very convenient features — the ability to assign functions to variables, send them as arguments, and return them as values. This lets you write code like this, where functions themselves return other functions: {% codeblock lang:javascript Anonymous function bonanza %} /* This code creates a basic ‘curry’ function (see my earlier post for an explanation) It relies heavily on function variables. */ var add = function(x, y) { // <- A function variable return x + y; }; var curryUtil = { curry : function(functionToCurry, x) { // <- A function object property return function(y) { // <- A function return value return functionToCurry(x,y); }; } }; var add7 = curryUtil.curry(add, 7); add7(3); // returns 10 var double = curryUtil.curry(function(x,y){ // <- A function literal argument return x * y; }, 2); double(8); // returns 16 The problem with this, however, is that all the functions in the above example are anonymous — they aren't named. Beyond making your code more obscure than it needs to be, this also makes debugging them a problem , because when you look at the browser's call stack, you're going to get something like this: {% img center /images/2014/callStackAnonymousFunctions.png Now they're all named! %} Yeah. Good luck with that. However, you can remedy the issue quite easily &mdash because JavaScript lets you name your function variables: {% codeblock lang:javascript Named function variables %} var myFunction = function myFunction(x) {...} var myObject = { myMethod : function myMethod(x) {...} }; function returnSomeFunction() { return function myReturnedFunction() {...} } …name your function values…
June 21, 2014
Why I like parasitic inheritance
When you’re starting out with JavaScript, it doesn’t take long for the question of object oriented programming to raise its head. As soon as you want to build anything non-trivial you’re going to want some means of structuring your solution and imposing some kind of abstraction on your code. Most tutorials these days emphasise use of the prototype chain - either through function.prototype or the ECMAScript 4 Object.create() interface. I, however, am still fond of the more basic parasitic inheritance approach - where inheritance is basically a special case of composition - and I wanted to outline my reasons why.
May 29, 2014
JavaScript curry
If you’ve had much exposure to functional programming, you might have heard of ‘currying’. This funny term refers to a kind of functional composition: taking a function that takes two (or more) parameters, and turning it into a function that takes less parameters, and automatically applies the other arguments, which have been ‘baked’ into it. For example, let’s say we have an ‘add’ function - function add(x,y) { return x + y }. I might have an instance where I want to add various numbers to a constant - say, 7. Rather than constantly calling add(7, x), currying lets me create an ‘add7’ function. Whatever I pass, add7 always adds seven to it.
May 11, 2014