Archives for December 2015

The Goldilocks of Performance

December 29, 2015 Leave a Comment

I enjoy the opportunity to see family and friends over the winter break, and two conversations that I had back to back made me feel like I was in the goldilocks story.

Frontend Good, Backend Poor

I was reminiscing with a former colleague about The Old Times. We got onto the topic of a particular project where we were responsible for the frontend development but didn’t own the backend services. Between you and I, those services were fragile and unresponsive. Measurements could come back in the seconds.

What could we do about it? Well, we ended up building a tier in front of these services and doing everything we could to cache data as close to the client as possible. As you well know, caching is one of the Two Hard Things, so it brought pain upon us, but we had to do it. We had folks arguing about “Akamai Sandwiches” and all kinds of architectural contortions to squeeze the perception of performance for our end users.

We had to go through and meticulously think through each flow and decide what we truly had to wait for. This ends up with a system such as hapi’s catbox, where you can easily declare the policy of downstream services.

For example, imagine a product details screen for an ecommerce service. Do you really need to wait for all of the information on that screen before sending anything to the user? Is all of the information equally important? Of course not. Not only isn’t it equally important, but the level of staleness that you are willing to allow for is different. You want the price to be up to date, but does it matter if the absolute latest review comes back? No. This type of work can actually go nicely hand in hand with your general information architecture and UX.

The front end team had great pride on their performance. Profilers were always running. It was a touch gutting to use the system and see the latency in your face. How can we get people to really care about this?

The side by side comparison was always a great tool of choice to get the message across. On the data side we could show an increase in conversion for faster responses, but then you come with with the sucker punch. We would record a video where on one side you would see the app working against mocks with sensible response times, and next to these the same experience would hit the “real” services. I highly recommend the side by side comparison as it will kick in a distinction bias in the person you are trying to persuade.

So, that was an example where the frontend out performed the backend, but it could only fix the experience to a certain point 🙁

Backend Good, Frontend Poor

The other extreme is equally possible. Another friend was showing me a backend CMS system that had two frontends developed by separate teams. The average responsive time for the end user was double for one site versus the other, and they were very comparable sites.

This was a case study that Steve Souders would be proud of. The backend could sling that 200 back all nice and fast, but the front end performance varied. If you fire up Chrome DevTools you quickly see a slew of errors: loading JS in the wrong black, a lack of async/defer, and way too much being sent to the client on every page. Ouch.

RAILing on Performance

In the past there has been a large focus on initial load / paint with web performance. We are now seeing other areas of focus, as shown by examples such as RAIL, the “user centric performance model”.

Now, some people complain that each of those areas shouldn’t be considered equal (“Loading is much more important than animation!”), but it is fantastic to see the push to truly polish and perfect your work.

It is important for us to get past “load” as we have all been on those janky pages. The ones where a hamburger menu is there but it feels wonky. Scroll effects are strange. It looks like someone is trying to “copy” native but its just worse. If we want the Web to deliver more than simple content, then we need to nail the entirety of RAIL.

We want to be a smarter goldilocks and deliver the overall experience that is truly just right.

p.s. care about performance? did you check out the holiday perf calendar again this year?

Web Components Are Dead?

December 28, 2015 Leave a Comment

I sometimes hear web developers discuss how Web Components are dead. They were DOA. Done. A nice idea, but one that no one wanted. Hey, the spec has been around for awhile now and who is using them?

“It takes 10/20 years to become an overnight success”

Oh how often we fall for that trap. Remember the Ajax revolution? For the folks who were “doing Ajax before it was cool” it was almost comical to see how it surged after years of lying dormant. I remember giving talks about how to “build killer web sites with dhtml!” (or some other silly title) and the room was a lot more full once Jesse James Garrett pushed it out there in a way that made sense to folks.

Microsoft built an ActiveX component to solve a problem for the Outlook Web team. Later, Mozilla implemented it in Gecko. Multiple implementations, much needed in a world where Firefox was fighting for share from IE.

With Web Components we are still missing some crucial browser support, but it is on its way thanks to good browser engine folk. Once we can natively use Web Components, will that make a difference? I hope so.

Trust me, it tastes great

When <React cameOntoTheScene> there was an outcry

We believe in separating our concerns! I want my markup separate from my layout separate from my view logic. How dare you mix this up. Remember PHP/ASP/JSP? Ugh!

Those who gave it some time realized that the concerns were better separated this way. Being able to holistically look at a component was great. Being able to actually compose and abstract nicely was great. Once your eyes could see past syntax, you realized that it maybe was a feature and not a bug.

So, one thing React has done well, is that it has shown us that components can actually work well on the Web.

Now, React has had to work around the browser to give us the declarative development model that many of us enjoy. What if we could raise the browser platform to allow it to take on more? This way you maybe don’t run into the pain of the bugs that can occur when you have retained vs. immediate mode APIs. Could the browser then help developers with more fast by default?

When XHR came about it solved a real need. We want to do inline auto-completing. We need to talk back to the server. We don’t want to do so via Flash or iframe hacks. XHR eventually did enough to fix this. Do Web Components have a similar solution? Are we sick of not being able to share components on the Web? Are we tired of not having a foundation and having the “oh crap I really want that component but it is based on jQuery and I am on Prototype!” of old?

I really hope so. I am excited to see Web Components get more async and perf-y. I am excited to see more browser implementations. Oh, and I am excited to be able to work with components that I can compose and reuse.

You never know the future, but I am not writing off Web Components before it has the chance to be an overnight success.

As we see real world usage such as AMP, it may show developers that it is ready for prime time.

What are you missing out on working in that remote office?

December 22, 2015 Leave a Comment

I have worked at company head quarters, remote offices, and from my own home (rolling out of bed and falling to a computer at times).

There are definitely pros and cons to the various situations. I remember the time when I realized that I hadn’t left my house for three days, and it freaked me out. From that time on I made sure to set the lofty goal of “get out of the house” at least once a day 😉

We are survivors. One technique to help us in that quest for propagation is to try our best to predict the future. As anyone who watches the weather forecast or stock market knows, this isn’t an easy task. We have a very small sample of data that we need to run simulations against. We are also looking for the worst possible scenarios to make sure we are prepared for them. Why am I mentioning this? I think it is the root cause of the phenomenon that I see when folks outside of the nucleus of a company fear that they are missing out.

Just imagine all of the water cooler discussions you may be missing! What if you were sitting next to the CEO! Surely you would be more plugged in and understand the strategy and what you should be doing!

If you feel that way, find someone who has done the switch. The person who has been remote and local and I bet you find the following:

Sorry, there is no magic water here. I still have to do the hard work to tie what I am doing to the mission. I still have to hunt to find answers. I still feel uneasy that I don’t know the entire context

It isn’t crazy that we feel like we are missing out on things. For one, all it takes is one piece of information that you hear about second hand to get the mind turning…. “what else should I know that I don’t know?”

There are also times where there are real disconnects. Someone forgets to setup the VC. You aren’t invited to That Meeting. You don’t get to have a beer on a Friday with some of the team you really want to be well connected with.

Also remember though that they are remote to you. It is a two way street. It is most painful if you are a distributed employee working as the only remote worker on the team. That is the extreme. However most of the time these days people are all over the shop.

I used to enjoy the notion of a “Slack Week” where everyone was forbidden to work from the office so they can get a true feeling for what it is like to be distributed. It can help you empathize with your co-workers, and can also sometimes show you how productive you can be when you aren’t stuck in the same meetings all week 😉

So, what are you missing out on as a remote worker? Probably not as much as you think.