We like Vue at A+L. We think it's one of the best frontend frameworks, and a great choice pretty much anywhere you might otherwise be tempted to use React.

In Part 1, we looked at the features of the Fastify Node.js Web framework compared to Express.js. In Part 2, we'll work through migrating an example Express.js application to Fastify.

Express.js has for years been the dominant lightweight Web framework for Node.js, but over time its development has stalled, with its latest major version (5.0) still in pre-release nearly eight years after its first alpha release. There's a lot to be said for this sort of stability in a foundational dependency for a project, but it's worth assessing whether the added features of competing frameworks are worth making a switch. In this article we'll be looking at Fastify in particular, to understand what it has to offer compared to Express and how difficult it is to migrate an existing Express project.

This post assumes basic familiarity with Vue.js v2.x.

For web development, when all other considerations are equal, we recommend choosing Vue. Here’s why:

"It's going to be the coolest thing ever."

A young developer, new to the Tao of the client-side, comes to a Master of the way, and speaks thusly: "Oh Master, our application nears completion; and lo, cat pics can be drawn upon, and captions fixated thereto, for the creation of humour and the bounteous enjoyment of our users."

Last time we discussed the Fetch API in general, taking a look at how it differed from the XMLHttpRequest API, and some of its advantages. Today, we're going to take a look at a little library that you can include in your projects today that offers you localStorage caching for the Fetch API.

Long ago, we briefly brushed upon the topic of what has made jQuery such a valuable part of the web developer's toolset for such a long time - namely, a cleaner interface for interacting with the DOM, and the $.ajax abstraction over XMLHttpRequest.

You've built the web application of the century, and the users have rightly flooded to it. Cat pictures for everyone!

After long, grueling months (years? or does it only feel like years?), your web application nears completion. It is tightly coded, well documented, works across all modern browsers, and is well received by your beta testers. It's nearly time to go live, and a smile of pure relief plays upon your lips... and freezes into a rictus grin when your client turns to you, and asks, "so, hey, can we speed up the dynamic cat pic loading? Especially when I close the browser and come back to it later. I think that's really key to the whole application."

In a hurry? You can now use our HUp jquery plugin to read files in a chunked fashion as data URLs. Hooray!

JavaScript has the propensity to be very untidy if you let it be. This isn't a problem unique to JavaScript, of course - many other languages suffer from a lack of native organization, especially for specific tasks.

It's pretty seldom that anyone mentions web pages these days, other than in historical reference to days long gone by (yes, a whole few years ago). Web sites, sure, but not if what is really wanted is to replace something that, not so long ago, would have been some native code for a smartphone (or a little further back still, a desktop computer). Generally speaking, the most common term tripping from client's lips these days is 'web applications' - or webapps, because who has time for spaces and proper spelling, amirite?

JavaScript has the propensity to be very untidy - if you let it, it will sprawl all over the place. Hundreds of global variables scattered across dozens of files, messy half-measures towards object-orientation, mixed in seemingly at random with ungrouped functions - anyone who's had a client bring them a failed project from some other development team knows just how bad it can get.

Way back when I brought up the topic of promises (particularly, jQuery Deferred), and I promised we would come back to the topic someday.

Backbone's had some of its thunder stolen lately by trendier frameworks like Meteor and Angular; for good reason, in most cases, as without the prosthetic functionality offered by the likes of Marionette, Backbone's view handling (amongst a few other lacks and warts) is really just 'roughed in'.

April 30, 2014 at 3:22 am Remy says:

Here's the situation: You've got a select. Maybe a whole bunch of selects, with a ton of options each (metric ton - let's keep our imaginary hyperbolic units straight here); and these are meant to be complex interactive elements, with options made visible or not as some programmatic condition dictates.

When it comes time to relate the ephemeral world of data to the physical world, Maps are key in both enterprise and consumer applications. Whatever else you might think of it, Google Maps tends to be the default option - certainly, its the only one I've ever had clients ask for by name.

It's a pleasure to be able to interact with files in the browser at long last, isn't it? Reading files in without needing to bounce them against the server first opens up a lot of possibilities - and getting progress from a chunked ajax upload is miles away from the indeterminate form uploads of days past.

A big part of what makes jQuery a regular part of so many web projects is the clean interface it offers us for a number of sometimes messy built-in aspects of javascript. The most obvious is the DOM interface; and in second place, jquery ajax and its various shorthand methods. Abstracting away the difference between ActiveXObject and XMLHttpRequest is one of the most obvious benefits - but even if you don't need to worry about supporting old versions of IE, you might well enjoy the clean, object-based, promise-returning interface that jquery ajax offers.

During the course of any complex project (and even many simple ones), on the way to accomplish the actual goal, you're certain to encounter any number of small hurdles along the way - little problems which need to be resolved for the bigger picture to come into focus.

So, you've got a link that, in reality, is just a click target for performing some javascript function. You want the appearance of a standard anchor link, but if it's not performing the intended function, should it really be an anchor? And if so, what should we fill that 'href' attribute in with?

So, the client has told you their users should be able to upload their drunken party pictures for all the internet to see. "We want the very best experience possible," they tell you. "Simple, seamless - maybe using that new html5 thing I've heard so much about."

Inevitably, people want their files on the Internet. If your project is about cute cats, someone will task you with allowing users to upload photos of their cats, videos of their cats, long rambling audio clips in which they attempt to convince their cat to stop attacking the microphone, etcetera. If your project is about the nature and proclivities of mold, someone, somewhere will want to share detailed photographic evidence of their mold problem. The need to upload files is a given.

If you ever found JavaScript's prototypal inheritance confusing, do yourself a favor and open this article, open a JavaScript console and code each example in the article. You will definitely come away with a better understanding of how prototypal inheritance works in JavaScript.