Why Are We Making Web Development So Hard?

I don’t think I’m the first person to think this by any stretch. There are lots of infographics around showing the difference between web tooling now and 10 years ago and it’s clearly ballooned at an extraordinary rate.

In the last year or so I’ve started working with Angular (as opposed to Angular.js a.k.a. Angular 1) and have also dabbled in Vue and React. All of these frameworks seem to share the same basic ideas – build everything as a component and push and pull them from the DOM as needed. Each component is made up of a HTML template, embedded CSS styles and a JavaScript controller.

This feels like an efficient way of working, very DRY. But is it? You create a component, let’s say a time picker. One it’s developed you can put it into multiple views or uses relatively quickly. However, if you later modify it to work slightly differently, using adding complexity, you have to test it in each use case and make sure it still works with no detrimental effects.

All UIs are basically built up of HTML, CSS and JavaScript. Traditionally HTML is for content, CSS for styling and JavaScript for reacting to user behaviour. With components we’re adding a whole load of JavaScript just to make the basic elements appear before we even get into any behavioural usage. This adds to page weight (size of files being transferred to the browser) and render times. There’s the library itself, often split into many smaller modules, plus a controller for the UI to assemble it and then the components. It could just be one HTML file, one CSS file and one JavaScript file.

Increasingly, what the developer writes in their editor is becoming further and further from what actually appears in the DOM. The frameworks insert a whole host of IDs and classes to elements, bloating the HTML and making it harder to read. Styles are inserted as inline <style> blocks rather than being cached in an external stylesheet. Opening the browser’s Dev Tools to track down and fix a problem is becoming harder, not easier.

Also, the more tools you use, the more you’ve got to maintain, keep up to date, upgrade and replace. It’s creating work just to keep up and inviting technical debt.

I think that what we’re gaining in terms of being able to develop new UI more quickly is all rooted in developer efficiency and production cost saving. It’s not thinking about the user. We’re making things slower for users. The mobile experience on most sites is still awful and the overhead of these frameworks is partly to blame.

The latest frameworks also rely on good browsers with all the JavaScript features. They do not use progressive enhancement but just grind to a halt on an older browser. This goes against the universal nature of the web – it should be easy to read and easy to write. The bells and whistles on the top is just that and should be optional, not prevent the basics from working.

I think we need to get back to making things simple. Write HTML, CSS and as little JavaScript as we can get away with. Go static wherever possible. Make it fast and simple for users. User experience should trump developer experience.

Super Fast Tree View in JavaScript

I thought I’d share a way of writing your JavaScript that will make a tree view hierarchy render and respond very quickly.

Firstly, the demo. I’ve got 100,000 items, quite a hefty data set, which is randomly generated in a function. You can change the number of items easily in the JS area. Click on the + or – icons to expand or collapse nodes.

See the Pen Super Fast JavaScript Data Tree by Chris Smith (@chris22smith) on CodePen.dark

It’s still quick, like instant, with 100,000 items. It can start to slow a little at a million but I’d say it’s still acceptable given that kind of data.

One Long List

The trick is in how the data is structured. It’s one big array, not hierarchical data with objects inside other objects. The reason for this is pretty simple, it’s all about iterations or looping. If you have a single array you can run through the whole list of items once. If it’s nested you have to get into loops inside other loops and it gets more complicated and takes longer. In fact, you’d be lucky for it to work at all without getting stack overflow errors.

JavaScript Magic

With a single array you can use the built in JavaScript Array methods, which are very fast – map(), filter() and some(). I’d definitely recommend reading up on these. All three work in IE9+ so hopefully you shouldn’t have to worry too much about browser support.

I use map() to convert each data item into a HTML list item which I can insert into the DOM. I use filter() to quickly find the children items of any item by returning a subset, and I use some() to see if an item has children. The beauty of some() is that once its found it child it stops iterating, saving time.

Easy on the DOM

The other part of this is keeping DOM manipulation to a minimum. Playing around with data in memory trivial for a browser but making changes to the DOM and rendering things on screen takes time. So, only the nodes that are needed right now exist in the DOM – there are not hidden items waiting on the sidelines. So, a new <ul> is added when you expand a node and the <ul> is removed when you collapse. A + icon is shown if the item has children of its own but we don’t know anything about how many it has or what they contain until it’s expanded.

More…

If you found this useful it might be worth looking at my older post Lightning Fast Filtering in JavaScript, which uses a lot of the same principles.

Different Conditional Syntaxes in JavaScript

There are a few ways of using conditionals in JavaScript. I’ve started thinking about it again as I’ve just discovered another new way.

Lets start off with some basic set up stuff for our examples – a variable, which can be true or false and functions to use in either case:

var isAllowed = false;

function admit() {
  console.log("admitted");
}

function reject() {
  console.log("rejected");
}

The first way I learned to write a conditional, which I consider the classic way, is with if and else clauses like this:

if (isAllowed) {
  admit();
} else {
  reject();
}

If you don’t need the else part, you can do it in one line, leaving out the curly braces like this:

if (isAllowed) admit();

Another way of writing it is to use a ternary operator. The first part before the question mark is evaluated. If it’s true the next part between the question mark and colon is used; if false the last part after the colon is used:

isAllowed ? admit() : reject();

If you want this style of expression, without actually writing “if” but you don’t want the else part there is yet another way.

Look at this:

!isAllowed || admit();

Weird, eh? With an OR expression using ||, the first part is evaluated or run if a function. If true it stops there. If false it evaluates or runs the second part. In case you’re new to this, the ! means NOT or inverts the meaning. So, we’re saying if isAllowed is false, stop; otherwise run the admit() function.

It’s the same technique often used to set default values, just turned around:

var carModel = getCarModel() || 'unknown';

If you’re free to use any of these I’d probably advise sticking to the classic if (else) with the braces. It’s so much more readable and can be understood by a developer at any level. I like the last technique but I’d only use it in solo projects or where I can’t use anything else.

Learning the Right Things

With so much happening so fast knowing what new tech to learn next can be difficult. Where should you invest your time and energy? What if you spend ages learning the shiny new framework and it’s gone within 2 years?

There are a lot of trends and a lot of new-fangled things do come and go. How do you spot the ones that are going to stick around. It’s not easy – you kind of have to go with the flow, not swim against the tide (2 water based metaphors in one sentence, tut).

In front end development there are currently a few big JavaScript frameworks – Angular, React and Vue. It seems obvious to me that none of these are going away any time soon. Which do you choose? It really doesn’t matter. Learning one in depth, finding its powers and limitations, will help you learn the others or other future technologies.

If you’re really not sure where to turn I’d focus on core learning. In the front-end world, learn plain JavaScript. With ES2015 and newer versions than that emerging there’s still plenty to take on and perfect. That knowledge will always be useful.

I guess my short answer would be to favour the evergreen HTML, CSS and JavaScript over associated tech like Pug, Sass, TypeScript, etc. As the core technologies get better over time these current convenience technologies may one day not be needed.

One word answer. JavaScript. :)

Developing in Codepen

A look at why and how I use Codepen for front end development work.

Background

I work on a web app with a development team. We use AngularJS with a RESTful API. My role is looking at the design and UX side of things and scoping out how a new feature will look and behave in a web browser, or, I should say, in various browsers at different screen sizes.

I generally do my work up front. I’ve always been a design in HTML and CSS kind of guy. To me, with my skill set, working in a graphics editor takes as long as coding it so it makes little sense for me to do the work twice.

Until recently, I’ve been using static HTML and then another developer has added the binding and data. Where the feature is on a new screen I can go a step further and create a dummy data object, to represent the data returned from the API, and actually do the binding as well as create any custom behaviour.

Working on existing screens has been much more difficult. It’s almost impossible to add new data, binding and behaviours without breaking the existing code. To use a dummy data object I need to intercept the real data retrieval and replace the object, which stops the page working when wired up again. However I work things, I’m having to check in code which is not releasable.

A new way of working

I’ve started using Codepen to abstract away the new feature. I set up a new pen, import any existing dependencies and then create the HTML, CSS and JavaScript for the new feature in isolation.

This means that the original project code does not get touched and broken. As the next developer brings in any model/schema changes he/she can bring in my front end code so we don’t have any breaking check-ins.

By importing the dependencies – JavaScript libraries, CSS – we avoid any clashes or inheritance issues and additional work trying to integrate my code.

It also means I can give the new feature my full attention without having to use other parts of the screen, for example, if I’m working on a modal window, I don’t have to go through the usual page processes in order to call it.

I’m using Codepen in the way it was intended, as a front end playground, an environment where I can experiment with different ways of doing things. The results are displayed in a frame, updated instantly as you type, which makes working much faster – no more manual refreshing or rebuilding.

From what I’ve described up to this point, this abstraction could be done by making a copy of the page but copying the HTML page, the CSS and JavaScript and changing all of the references between these files is quite a headache. Believe me, I’ve been there enough times.

One of the massive advantages of Codepen for a designer is the ability to fork pens, so you just hit one button and you’ve got an exact copy of the pen you were working in, making it very easy to create a few variations of a design.

As each pen is available on a public URL it’s easy to share designs with colleagues or clients and they can see a working prototype – much better than a static screenshot. It also means that links can be embedded in documentation. Personally, I feel that now web animation has become mainstream, it’s important to be able to show how screen elements transition between states, how things appear/disappear and demonstrate where the user’s attention is drawn through processes. Static screenshots just don’t cut it any more.

Final point. Designing in the browser with work stored in the cloud is awesome for design. I could be out and about and suddenly see some inspiration for something I’m working on or get a new idea. Rather than hope I’ll remember it, I can quickly create a new pen or fork an existing one and add some code or notes there and then from a phone or tablet. I don’t have to hope I’ll remember or wait until I’m back at my desktop. It’s exactly what the web should be.