What’s coming up next?

Technology! The Badgers love their technology, both new and old – but what’s coming up next?

Recently, we spent a fantastic day discussing developer and testing topics ranging from new languages to new ways of working. This culminated in a bustling open spaces session to find out what the Badger collective thinks about our current, and future technological ecosystem.

The session began with every Badger being armed with trusty post-its and pens. Everyone then placed languages, frameworks and methodologies into categories of stop using, keep using and start using. If you agreed with something already in a particular category, you could add a dash of support by placing a mark on that post-it.

So what do the Badgers think lies on the horizon? What gained the most support? What was the most controversial? Have a peek below!

open-spaces-postits

CSS

CSS has been around for close to twenty years at this point, and many Badgers felt it had some fundamental flaws. Unpredictable side effects, subtly different rendering between browsers, inconsistent rules and its cascading nature make CSS difficult to combine with the a component based approach to creating web applications. These problems are explained fantastically in this talk by Pete Hunt.

While many agreed these are issues, the solution was less clear. Discipline approaches like BEM exist to minimise some of these pains, CSS Modules have proven popular, but maybe something more exotic like the recently released Styled Components or defining our styles in JS is the future?

Styling is definitely a hot topic in the community and we’re keen to experiment, so watch this space!

Node

Node was an interesting subject, appearing quite popular in both the stop using and keep using categories.

Red Badger has delivered quite a number of successful projects on the back of Node, but some thought that we had perhaps grown overly-reliant on it. The general conclusion from our discussion was that it’s a great tool for some problems, but not all, and it should retain a place in our toolbox. In future projects, perhaps we could explore other back-end technologies like Elixir for our upcoming projects.

Cucumber  and other automated UI testing tools

Automation testing forms the top of Mike Cohn’s oft-quoted testing pyramid, representing the smallest size and costing the most to both create and run.

Red Badger has a number of generously sizeable web projects where automation testing has been pushed to its limits – in speed, in maintainability and in value provided. Some Badgers felt that many automated testing tools provide little value, or can even be damaging. Automation testing processes can begin to add to the lifetime of pull requests, and unreliable or unwieldy integration tests inject uncertainty into the readiness of the product.

UI testing is a difficult problem, especially at scale, and no framework seems to be perfect for us at the moment. Perhaps snapshot testing through tools like Jest allow some of the automation testing to be filtered down to a middle layer, letting the automation tests remain lighter.

We’re thinking deeply on this one, lets see what we come up with!

AWS ☁️ + Serverless ⚡️

We’ve become big fans of AWS and look to continue using it and its products. Some Badger projects have a huge need to scale and AWS, combined with tools like Terraform, have served us well in decreasing our need to engage in traditional ‘DevOps’ activities.

Recently, we’ve been enamoured with a new offering called Serverless. Serverless leverages AWS’ Lambda and other services to provide infinitely scalable, immediately provision-able environments. This allows us to focus almost entirely on the meaty application parts of development, having abstracted away so much of our platform concerns.

We have high hopes for this technology in the future, and have already launched projects utilising it successfully. If you want to know a bit more about our attitudes to infrastructure problems, check out this smashing blog post by our CIO and half-pint scorner, Stuart Harris.

Java ☕️

Some Badgers have recently burrowed their paws deep into Java systems, which brings back memories for many! Java and its frameworks, especially for legacy systems, has both advantages and flaws that have been explored often.

Given the general internal trend towards functional programming, many were keen to perhaps try Clojure or Scala to allow firms to keep their JVM infrastructure while gaining the benefits of these whiz-bang languages.

Flow

Flow is an optional typing library released by Facebook that allows you to gain the benefits of static types in the normally dynamic language wonderland of javascript. These types can be defined by hand, and through Flow’s impressive type inference system.

So, what does that give you? Safety from all kinds of null errors, and through fantastic tooling such as Nuclide, great hints on possible pitfalls in your code and groovy developer experience niceties like on-the-fly parameter documentation.

While this can increase confidence and predictability of your code, some Badgers felt this removes from the dynamic core of JavaScript, while others mentioned that the current tooling caused them aggravating issues.

This technology was quite contentious amongst the Badger gathering, but the optional and incremental aspect of Flow means that for teams where it’s providing value, it can be used without treading on other people’s toes.

Keep an eye out on Flow, and maybe we’ll all be in agreement when the syntax settles and the tools mature, or perhaps we'll have moved on to something completely different!

GraphQL ፨ and Apollo

Generally, we’ve had great experiences with GraphQL. REST has carried us a long way, but anyone who has looked after a large API will know the cracks that begin to form. How do you approach API versioning? If you need just one more piece of data on a page, do you add another endpoint resulting in another call, or do you start to make a small amount of very fat endpoints? If you have fat endpoints, will it be terrible when you need to call two of them just for a small amount of data from each while discarding the rest?

GraphQL soothes many of these long-known problems, allowing you to declare exactly what data you require to a single endpoint, and allow the backend to resolve these needs.

Although we haven’t had the opportunity to use it at scale yet, many Badgers are scurrying in excitement about Apollo, an incrementally-adoptable data stack leveraging GraphQL that manages the flow of data between clients and backends. It seems like a well designed system that works fantastically with some of our favourite front-end core technologies like React and Redux.

Elixir

Elixir! A very exciting backend language that many Badgers are keen to embrace. It provides the tools to implement scalable, fault tolerant concurrent backend systems by utilising the power of the BEAM VM and the lessons of Erlang.

In addition to intrinsic language virtues, it provides a fantastic developer experience and a menagerie of tools. For example, Elixir can run code examples in your method documentation to ensure everything’s up to scratch! How cool is that‽

We’re all itching to put Elixir into production. If you’re around in London on the 21st of October, why not come to our Elixir Build Day, led by our chief Elixir artisan and propaganda minister, Louis Pilfold?

Elm

We were fortunate enough to be visited by Elm creator Evan Czaplicki a few months back, showing off his powerful, functional front-end language. Evan demonstrated how to write fantastically concise, run time safe, deterministic and confident front-end interfaces and the Badger huddle has kept close watch since.

Elm is an absolute joy to use, with the strong type system allowing it to have features such as exceptionally insightful compilation error message, should you ever lose your way.

Over the last year Elm has only been gathering steam, gaining features, and growing a vibrant and brilliantly helpful community. We’re definitely keen to use it in the future.

So what are the big themes here? Red Badger believes in Strong Opinions, Weakly Held, but for now the Badger Future looks a lot more Functional and Immutable than it did before!

Do you agree? What excites you? Let us know @redbadgerteam.