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.

Friend, can we agree that tests are a good idea? I won't scorn you for sometimes omitting them - time and budget constraints are what they are, and even the best intentioned of us sometimes have to just give our projects a lick and a promise. "Proper test coverage soon", you sweetly croon as you rock it to sleep, the knowledge that you're telling a dark, terrible lie twisting you up inside. Maybe you could just scrape enough budget together for some simple unit tests? Then, at least, you'd have "tests", right?

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."

Last time, we got into the nitty gritty on how to make your web application into a Progressive Web Application (PWA to it's friends). I promised we'd dig even deeper this time, and show you how to make your web app a little more 'native' on Android - and how to deal with iOS Safari's special snowflake syndrome.

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."

It's project kickoff time, and you're having a conversation with your client about what form the application will take:

So, it has come to this.

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.

Last time, we decided to embark on a brave new adventure and give our Django framework a big upgrade with the inclusion of Django Channels. We got just far enough to get the development server running, but while this may be an adequate start, it's better to develop against something like what we intend to deploy, right?

You stare mournfully into the mass of code you've inherited. At some point, it's clear, the requirements called for the server to push information to the client, because there's an unholy mix of Server-Side Events, long-polling, hidden iframes and even a Java applet in there, all supporting some level of long-term connectivity with the server. It's almost fascinating in its barely functional hideousness, and you would be inclined to leave well enough alone... except for the new feature specifications you've been assigned, which require the client to be able to send data back to the server in response to the received events, in as close to real-time as you can get.

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!

When it comes to user accounts, the standard litmus test is email validation. Besides the immediate benefits - of offering us a straightforward unique identifier for users, and making it more difficult to automate creating a mass of accounts on our service - by requiring that each account have an email address and interact therewith to confirm the addresses validity, it also offers us the chance to associate a known-working email account with a user account. This is important for transactional emails such as password resets or for potential two-factor authentication use... and if you're a little less ethical, for sending marketing desirable and informative emails about interesting products and services.

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.

Poor PHP. It's so lonely and unloved these days.

Deploying your webapp is an important part of the web development equation - your client's site isn't going to attract a lot of attention sitting in your local dev directory. Deployment concerns tend to fall to the bottom of the priority list, though, and the end result tends to be kludgy, hastily thrown-together deployment scripts; and because they are so kludgy and, often, time consuming, when time crunches threaten, a developer may resort to making changes directly on the remote server that need to be (but sometimes never are) backported to the code living in your version control.

Fair warning: The following article is long, rambly, and contains no code. It does, however, contain some rumination on the idea that everyone can and should learn to program.

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.

Not terribly long ago, XML was the darling of the web. HTML4 was reformulated as XHTML 1.0, SOAP messages were XML, and let us not forget XMLHttpRequest.

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.

Recently, I was engaged in a genial argument with a friend of an older generation, each of us taking an opposing stance on some obscure trivia neither of us was entirely certain about - but which we were both ready to defend with all the wit and rhetoric at our disposal. When we had finally exhausted all attempts to make the other budge on the matter, we turned to an authoritative 3rd-party source to lay the matter to rest for us - a Google search.

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?

Virtualization is one of the many benefits of the excess (metaphorical) horsepower available to us with modern hardware. Need to test against (Windows XP/7/8/NT || Fedora || Mint || Ubuntu || FreeBSD || MacOSX || etc)? Fire up the VM. Need a Linux environment for the packages your server relies on, but need to test in the iPad simulator? VM's to the rescue.

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.