The Evolving State of Web Development

Wow, it looks like the web development is in a really sorry state! As I read the bileblog-esque post I found myself acknowledging some of the points, but also feeling like the baby was being thrown out of the bath water.

Writing my first web page to serve to lynx and mosaic was so simple. Man I miss it. I could telnet to my web server, pop open vi or emacs depending on my mood, add some <markup>, hit save (:wq!), and reload my browser.

Why can’t life be that simple?

• The Web platform can do a lot more…. you know… useful things for people
• The bar for great experiences has gone up.

I love developer ergonomics. I want to invest in my tooling so I can live reload to enable a very fast change, run, test life cycle. It is possible to wire up your babel build so they are watch’d, and you can tie into live reloading. Does it takes some upfront work? Sure. Is it worth it? yes.

The React Ecosystem, So Complex!

One of the poster boys for complaining about the complexity of Web development is taking the 2015 hot fave and tearing it down. Pete Hunt does a great job of reminding us how we got here. The initial concerns that React tried to solve hit a nerve for some folk, but once people got building applications we kept running into more issues and decided to do what we do as developers: we created abstractions to try to solve them.

If you haven’t been through this ride yourself it can be tough to understand what is going on. When we are born and join the world we are placed in environments where we use a ton of abstractions. Tools like knives, forks and spoons. Outlets at a particular voltage. They are everywhere and we don’t understand the evolutionary path that had us end up at this particular point.

Web development is evolving, and it needs to evolve fast. Many of us wish it would evolve faster, but this evolution always brings tension and pain. The problem is that true app developers who just want to build the right widget get tricked into the world of the engineer. They have to tie together a world that is changing rapidly, one that easily gets out of date. This is where you have a choice: do you reach for the new rung, knowing that you will pay the tax of keeping things up to date? Or, do we stick with something simpler, something that isn’t changing at quite the rapid rate.

You could easily argue that too many people join the rat race of the new shiny, and they jump on something that looks new but it won’t have any effect on the end user experience. It feels like you are jumping to a new rung, but really you just moved sideways.

One clue for us to understand how fast something changing is how “packaged” a solution can be. If the ecosystem is moving so fast that you can’t have a stable answer to the stack then this is a sign greater than the velocity of new releases (although breaking API changes is another sign).

I do agree with the pain of working with a package that doesn’t do anything out of the box. Convention over configuration works well when there are intelligent defaults that cover the majority use cases, while allowing people the escape hatch.

Jumping between top frameworks such as Ember, React, Angular, Polymer, etc isn’t going to do much for your users as is. I do think that we are at a point where it is time to reach for the next rung, and that is by re-thinking your web application to be offline-first.

When Google Maps came out, MapQuest instantly felt old and wrong. This is one of the apps that sparked the AJAX revolution (even though the panning Google Maps experience didn’t use XMLHttpRequest at all!) I think we will see similar examples as folks use service workers and friends to create offline capable applications. It will be stark, and it will happen fast. This time, users are already used to the capability via apps. Nothing frustrates me more than when I expect something to work, and find that it doesn’t. For example, using a task system that doesn’t allow you to add a new task unless you have a connection.

As you kick start 2016, what can you change that can genuinely change the user experience? Is there a change to your dev tool chain that allows you to build that experience so much faster that it will get more features to your users?