Dependencies Dependency - Development

As I mentioned in my last post, I use a lot of article aggregators to help me to keep up to date with web design and development trends and tools. Most of the articles that come up include example UI kits, discussions around development challenges in a certain area, or perhaps discussions around newer HTML technologies or suggestions, such as the use of srcset or the picture element.

One of the sites I check regularly is cssauthor - it publishes articles with lots of useful development tools, free stock images, fonts, and icon sets. Some recent posts though were a clear example of how dependent Front End Developers can be on certain tools. These were: 50+ Best Free Bootstrap Admin Templates, 25+ Best Bootstrap Editors & Builders, 25+ Best Material Design Frameworks, and 100+ JavaScript Frameworks For Web Developers.

I’ll address these in turn:

Bootstrap

I should clarify this section by saying: I quite like Bootstrap, it’s a very useful tool for providing a lot of initial styles to help with building responsive, mobile-first, sites. But like with any other tool you start to rely on, if a project turns up at your doorstep with some requirements that the tool wasn’t built for, Bootstrap won’t be able to hold your hand through it.

One such example, and coincidentally why Bootstrap has never become part of my development workflow, is if you need to support IE7. Bootstrap does technically support back to IE8, but it can also be a problem there: if you’ve ever tried using heavily percentage based widths in IE8, then you’re well aware of how unreliable they can be! Sadly almost every site I’ve worked on has needed IE7 support, so fully hand-coded CSS has always been the way for me.

But putting the IE7 concern aside: once you’ve familiarised yourself with the class names Bootstrap likes to use, it’s as simple as adding its 6800 lines of CSS to your site so that you can then add even more CSS of your own to it to get the look your client asked for… Yes, uncompressed, Bootstrap’s core CSS is nearly 7000 lines - just under 150kb - most of which is probably not needed for your project at all. The compressed version isn’t much smaller at 122kb. That’s before adding any of the icon fonts, or themes. That’s a lot of CSS just to use as a baseline!

The main problem with Bootstrap - and any framework really - is that, if there’s a bug, you have to wait for someone else to fix it. One such issue with Bootstrap was that when the Less version was initially released, their use of the ‘&’ to refer to parent selectors wasn’t quite right. I was completely unaware of this until Mark Otto (the creator of Bootstrap) spoke about it when I went to the jQueryUK conference back in March - his mention of the bug can be found in the video of his talk about 17 minutes in.

You could of course fix any bugs you find yourself in the source code in your project and let it be overridden the next time you update the framework, hoping that it’s been fixed in the recent update, or alternatively, assuming your framework of choice is Open Source and on Github, you can make a change and submit a pull request, and then wait for your pull request to be accepted (assuming that it is) and a new version released…

Holistic Front-End Frameworks

By Holistic Front-End Frameworks, I mean frameworks such as Bootstrap, Semantic UI, and Foundation; frameworks that like to give you all the CSS and JS you need to just go off, produce some markup, and have a working site - a working site that looks and operates the way the authors of that framework feel a site should look and operate.

These frameworks don’t have to be used in this way; as mentioned above, they can just be used as a baseline. Granted, as building blocks for the foundations of a site, they can be very useful, but as I hinted above, they’re often fairly enormous, with a lot of extra code that you’re not going to use, that in many cases you won’t know the inner workings of. You sacrifice load speed, and having a firm understanding of what the code is actually doing, for the sake of development speed. It’s the same in many ways as opting to use a pre-built WordPress theme - they’re quick and easy, but when you then look into it in a bit more depth and notice that your site is loading multiple version of jQuery, three plugins that override normal mousewheel behaviour, and two independent parallax plugins, you realise your mistake. (Obviously a generalisation though - there are some brilliant WordPress themes out there, but a lot of terrible ones as well!)

Perhaps a naive view, but in my mind, the real purpose of such front-end frameworks is for use on personal projects - if you want to create a website to distribute an idea, or quickly advertise a product, but you still need something that’s relatively bespoke. In those cases, these frameworks really shine.

Javascript Frameworks

Javascript subsets and frameworks are all the rage at the moment. Everyone seems to want to write their Javascript with a bit of a helping hand. If it isn’t a sub-language such as CoffeeScript or TypeScript (which ultimately just compiles into Javascript in the end anyway…), then it’s a framework that does all of the extra handling for you.

But there are two questions I feel you need to ask yourself when considering Javascript frameworks. Firstly, do I need to use a framework? And secondly, which framework should I use?

Perhaps this is just my perception of it, but I regularly feel that the first question is ignored. Instead, people consider using a framework, realise there are loads out there, and then get lost in the absolute maze of them all. And who wouldn’t! There’s Angular, Backbone, Ember, Knockout, React, Durandal… there are loads! But which do you choose? It’s easy to see they’ve taken inspiration from each other: the sites for Durandal, React, and Angular look exactly the same! And of course, each of them has its own dependencies and recommendations.

So let’s put ourselves into the shoes of a not-so-confident developer looking into these frameworks - let’s call him Bob.

Bob looks into Ember as it’s had a lot of traction lately. He sees it integrates Handlebars templating, but he doesn’t quite know what this is - he sees that the homepage immediately points him to installing it via Node, which he’s also not familiar with. An immediate blocker really… He has a quick look at the Guides page out of curiosity and sees there’s a separate installer. Why didn’t they just mention that on the homepage? Now he’s looking through the Guides pages and he’s already lost in a maze of documentation - he’s not even looked at the API documentation yet. Let’s try Angular instead he thinks; it’s developed by Google, so that must be good right? It’s currently at version 1.4.3, but he remembers seeing talk that work on version 2 is underway. He has a quick look and finds that version 2 will be a complete re-write with no backwards compatibility and no upgrade path. So let’s try React, that’s developed by Facebook so might be another worthwhile contender. Hmm, there’s a lot of mention here about dealing with the View, but not much else. Perhaps I want something more extensive he thinks. So maybe I should use Durandal? Oh wait, it’s a single page app framework built on top of Knockout that’s also dependent on jQuery and requirejs. Let’s look at Knockout quickly then…

You get the idea. The world of Javascript frameworks has become a maze. Each has been built for a particular purpose, or a particular set of purposes, but that doesn’t stop developers from using them on anything they can think of. I’ve seen single page, seemingly static websites that use Angular just to populate data onto the page. I’ve read blog posts about people integrating React into their site so that they can create a single custom web component with a weird name. But this is all forgetting the first question: do you really need to use a framework?

I won’t pretend to know a lot about all the frameworks out there, but that’s because I don’t particularly need to. I’ve dabbled in Angular and Knockout briefly, and looked into the use of other smaller frameworks (Vue looks to be my favourite so far). But every time I’ve looked into using them, I end up wondering if I actually need them. And the simple answer is, I don’t (at least not for the projects I’ve worked on so far!).


Posted: July 19th, 2015
Categories: web, design, code