Frameworks are artefacts of a conversation

In Six tips on front-end framework selection I talked a bit about how to go about choosing a front-end framework for a new project.

So, what is the bigger picture here. What are frameworks all about?

I think that frameworks are solidified artefacts from an ongoing conversation we are all having about how to develop products more effectively, easily, cheaply, or whateverly.

Artefacts from a ongoing conversation.

Over time, we develop stuff, and aim to improve the how of the development. In this process, people solidify ideas into frameworks at various points. They meet some shared pain or add an exciting capability and a frameworks becomes popular. People try it out. Their learning feeds the minds of those building the next framework: introducing new metaphors, tools, style and syntax as they go.

These artefacty frameworks also contain reactions to the environment around — available browser performance or particular browser features lead to new ideas being tested in a framework.

That is all I wanted to say: Using, testing, moaning, exclaiming about a framework are all part of the conversation we have to have. New frameworks follow old ones. The are built from previous experiments and ideas.

Why does this matter? Perspective helps make good decisions.

You could deny it, but every front-end framework is thus made of jQuery. From the jQuery experience, annoyances and inflexibility we all dealt with, we have the beginnings of the modern browser framework. jQuery informs AngularJS. AngularJS informs React. And so on.

Chat is not idle: keep your history

Both Slack and HipChat - and probably most competitors too - have these tasty free plans that have some limited amount of searchable message storage.  Fine.  This gives you a free way to get started using a chat tool.  Okay so far.

Now, here's the problem:  At some point you and your team will get beyond the free limit and you'll ask management to pay for the app and they'll look at the pricing and not quite manage to pay up.  Everything keeps working on the free level, so it all looks okay, but what is happening is actually pretty bad for your business.

You've got limited message storage.  Each new line of chat means that some previous useful how-to or solution or web address has disappeared forever (unless you pay up later).  So, you know that host name or phone number or set of steps is stored somewhere in the Slack, but it has gone.  So you ask that question again, and get answered again (with time wasted in the process), and so it goes on.

Losing this information is costly.   There's an unwritten contract that stuff in chat is still there, and we've violated that. We're keeping water in a leaky bucket and people sort of know that but forget.  And having a chat system handy stops people putting stuff in searchable email or a wiki or confluence or suchlike.  So, this is a double fail now.

Chat without history is expensive and time-wasting.  Beware.  Get a buying commitment early.

Six tips on front-end framework selection

React or Angular, or VueJS, or whatever?  What do I choose for this next app I'm building?

Framework selection isn't easy. Here I want to put down my thoughts on what I think matters.

1. Complex things are complex

Firstly, let's be honest about trivial examples. They are trivial.  Nothing I've encountered in building web apps is anywhere near as simple as a To Do app.  TodoMVC is lovely for comparing framework features BUT any non-trivial app will push the boundaries of the framework and build process and comparing via a simple SPA comparison won't be that helpful.

No matter what you choose there will be always be too much boilerplate code and too many untidy corners where it doesn't work nicely. One or more of the framework's metaphors will suck.  That will all just happen.  So, rather than look to the framework to solve your complexity, look how it can support you through it.  

How does it scale to many many components and pages? How easy is it to test within and write tests for?

2. Fashion

Fashion drives a lot of our choices.  One of the wonderful things about the web industry is that there is plenty of new to play with, and there is an ongoing 'conversation' between all the developers on how to build web pages and web applications.  As a part of the conversation new tools are developed, languages are enhanced,  and new ideas emerge.

There is a massive temptation to try the latest thing, and the latest thing sells itself as the best yet.  However, these are all steps in an ongoing conversation we developers are having about how to do things. New frameworks and new versions of existing frameworks are really just a few more sentences in the conversation.  There will be something more amazing next week.  

So, keeping the choices in this sort of context really helps with decision making.  It is worth calling out the fashion aspect as you are deciding.  At least be honest if you just want to do the latest thing :-)

3. Nothing lasts that long

Ideas get old. Things stop working. Support evaporates.  As a part of this drive to the future with tools and frameworks, this will happen to your favourite framework, language, operating system.  When it happens it may require you to upgrade, mothball, re-build etc.  This will probably happen sooner then you expect and will be complicated by dependencies. 

Especially: don't expect stuff to just sit in npm for ever.  Stuff will evaporate.  Have a plan.

4. Skills

I've just finished a re-building an app into Angular 2 from earlier Angular 1 app with a weird backend Java CMS.  Moving to Angular 2+ pretty much mandated TypeScript instead of JavaScript.  Now, guess what happened?  TypeScript typing looks a lot like Java - and it became pretty easy for the Java devs to join in the front end dev using TypeScript. That was unexpected and really helped the project along.  

My point here is:  what skills do you have, and therefore what do you choose?   Might be fun to take on the new thing, but it you are therefore niche-ing into tech that has little support from the people around you, or if it is nice or fashionable enough it is going to be hard to hire people.    The easier and less exciting path (which includes leaving work earlier each night) might be to pick something better supported around you, rather than the bleeding edge.

5. Appreciate simplicity, plan for difficulty; read the source

Framework simplicity is valuable; a framework that simply solves your problem is golden.  Given that your non-trivial application will get complex or have some sort of twisty corner in the URL scheme that doesn't quite work with the router, you'll end up beyond the documentation reading the source.  So why not start now?   I encourage you to code review at least some of the whole framework before you start using it.  You'll end up looking in the source anyway, so why not use this as a part of your evaluation.

6. Or just don't

Finally, maybe you don't need much framework, and maybe none.  If your page is free of routing, relatively simple, then why not consider the no-framework approach?  However, you are going to need good patterns and coding standard and testing or you may well create an organic mess.  Remember, a framework is holding you to certain patterns, so you'll need to decide on and apply your own to keep stuff maintainable.

I hope this is useful. Feel free to comment below on your framework choices, or contact me if you'd like some help or chat about framework selection.

My recent framework selections (in reverse time order) look like this: Angular 2+, No framework, Angular 1.5 + material, No framework, Angular 1.x.

Which agile tracking tool?

This is a pretty common question:  What tool should I use for tracking my Agile project or Sprint?  

In my humble opinion, based on what I've been using recently:

If you want a simple display for a few tasks with easy setup and easy start, go with Trello.  This is really a visual card column system, Kanban style.  It is beautifully ad-hoc, and you get a good usable tool quickly.  Create a board, add some columns, add some cards.  As easy as that.   I find the limits come when you can't fit all the cards on the screen.  It also does collaboration surprisingly well.  A favourite quick planning tool.

If you're looking for something that definitely pushes you into thinking in Scrum-like Sprints, I'd go with Pivotal Tracker.  It has opinions about how you'll plan and work.  It organises sprints for you, helps you build and manage a backlog easily.  I  like this and use it for a lot of my personal and small projects. Pivotal manages sprints and velocity fairly seamlessly and otherwise stays out of the way. 

If you've got time for configuration and are on the bigger project side of things, I'd take a look at Atlassian Jira Agile.  You get something that is more like a issue tracking system with reasonable add-ons for agile processes.  It works well when configured.  You will spend configuration time.

And if none of these sound like you: start with an on-line collaborative spreadsheet (e.g. Google Sheets) and use that.  If the point is to plan and communicate, you can go a long way with a single spreadsheet with a few tabs. 

There are a lot of tools in this space.  Ask Google if you want to go deeper.

Or give me a shout and I can chuck in some more ideas.