Web Development is a Balancing Act
After receiving an email with an interesting set of questions, I figured it would be good to respond in the open.
Where do you draw the line between developer convenience and user satisfaction?
I don’t.
With anything I build, there has to be an end goal and that can consist of any number of factors. Whether its to reduce the amount of time I spend building it, make the page load as fast as possible, try out a new API and get something on the screen…..
This question is loaded with the notion that if a site is easier to build using some tool or approach and the end result is a slow and clunky site, should you use that tool or approach? See previous paragraph.
I’d argue you that if you build a site and you reach a stage where the user experience is awful or slow or <Insert reason here>, you should be falling into one of two camps:
- You have built something that is an experiment, a side project or simply a first crack at a project.
- You wanted to build a super awesome site for your users, but haven’t kept an eye on what the end user experience will be.
If you fall into the camp 2, then that’s bad, so try and fix it.
Paul Lewis offered some interesting thoughts on frameworks — do you think he is onto something, do you think frameworks are bad for the end user?
In short, no.
Paul doesn't like frameworks. Paul is a super awesome developer. Be like Paul.
I’m Matt. Matt’s not Paul. Matt has been building sites and working with web for at most, 1–2 years, before that he played with all the native mobile platforms.
If Paul had to write a website with a complex UI, I know he’d write something faster loading and more performant without a framework. If I had to write it, you’d be looking at a very different story in terms of quality and build time.
Are frameworks bad? No. I used all the frameworks under sun for building mobile apps and had great experiences using them, with many happy users.
Does that mean frameworks are good? No.
Compare the early versions of the Blackberry SDK to the early versions of the Android SDK, both Java, and yet violently different in terms of how easy and enjoyable they were to work with.
Why have I just mentioned native platforms? Two reasons. To highlight that frameworks can be similar and be good or bad. Secondly, because we need to step away from “frameworks” are bad and instead consider how Framework A could improve in area XYZ while Framework B doesn't have the features I need.
Web frameworks, for me, should have a place, otherwise you will be in the web platform with its mash up of low-level and high-level APIs.
Side note: I've often wondered if some of the problems with slow loading sites could be rectified if the majority of development was done on real devices. I always built on real devices when working on native platforms regardless of the state of the emulator, solely because performance and behaviour could only be determined by testing on actual hardware.
Regardless, Using a device for web development is considerably harder than developing on a desktop machine.
..with 4G, Google Fiber and whatnot, is web performance really that important? … Do you have any rules on what good enough means to you?
Good enough === What’s your use case.
- My personal site — I want to be as fast as I can make it (I aim for a speedindex of around 1000 on a cable network connection on webpagetest.org OR I just compare my results for webpagetest.org with aerotwist.com).
- For my home automation site which runs on a raspberry pi, all I really care about is whether it loads and whether it works.
Regarding network technologies (i.e. more bandwidth) — no that doesn’t matter. There are parts of the world where internet access isn’t fast, freely available or reliable.
If you are challenging the above point with — “Yeah but my audience isn't in those markets” then I strongly urge you to check out this article. I really can’t do it justice with a tl;dr, but….
By keeping your client side code small and lightweight, you can literally open your product up to new markets.
A blank website is inaccessible, so should website performance perhaps be placed in the same category as accessibility, colour contrast, legibility etc?
Initially I couldn't make much sense of this question.
But applying it to the article linked above, it makes a bit more sense. I don’t have an opinion on what category you put performance in to be honest. It’s all important and needs consideration.
Any closing thoughts on web performance?
Performance is hard. It’s hard to get right, hard to understand and hard to fix.
Some people are looking at frameworks as the main culprit for performance problems.
Give someone an API and tell them to break it and chances they’ll come back with something. Doesn't mean the API was bad, just requires someone to realise not to do that thing again and chances are the API could be changed to prevent it.
A slow website, no matter how it’s built, means someone didn't notice, didn't care or couldn't fix the problem. That doesn't mean the framework or tools used to build it is the problem, it could be the way those tools have been used.
When the framework is the problem, then guess what, the framework has some awesome new features / problems to work on. Maybe the browser even has some work to better support the framework…
As with anything in software engineering, think about what you need to achieve, how to measure that achievement and what tools will help along the way. Everything is a balancing act.
Paul Lewis wrote a response to these same questions which you can read here.
H/T @amlcurran, @elroid & James Healey for pointing out typos and mistakes.
