Dion Almaer

Software, Development, Products

Web

It’s time the Web did some Undergrounding

Leave a Comment


I live in a simple neighborhood in Palo Alto, California. My street is fortunate to have some nice old trees. We have small houses that the wealthy are slowly purchasing, tearing down, and then filling up the entire lot with house. From most vantage points it looks quaint, but then you get the wrong angle, or you go into someones back yard, and an ugly face is shown: a hodge podge of cables and wires are strung up from old pole to old pole.

I have asked neighbors why this is still the case, and I hear a variety of stories. Some believe that everyone has to come together to pay the city to underground this all, and no one has been able to get everyone on board. A hefty storm that knocks out power, or god forbid… Internet, will surely be the trick? Nope. It’s been long enough that surely it’s time to underground this infrastructure.

This is how I feel about the Web right now

We have had many successful undergrounding stories in the Web’s history. That is somewhat obvious, as the mere act of standardization is a key part of the process. It is long known that innovation in new and rapidly changing areas isn’t for the standards process (see Alex Russell’s amazing series on how that world works best). It’s too hard to “get it right, first time”, so basic risk management would suggest that you allow innovation to happen in a few branches and once you have enough data to suggest a decent (you don’t need to fall for the nirvana fallacy!) path, get enough consensus to drive the implementations that beget a true standard.

We see innovation happening all around us. Sometimes we look to other platforms to learn from (e.g. looking at iOS and Android to give us solid clues for how to bring mobile capabilities to the Web), and one other strong source is user space and the Web community. How are web developers solving their problems with various libraries and frameworks? In fact, as we push more capabilities into the platform, allowing a more Extensible Web, we should see even more of an ability for experiments in user land.

If we don’t come around and look for areas where we can take the experimentation and bake it into the platform, we will fail users when it comes to performance and the potential for richer user experiences.

Why will we fail?

The Web is an amazing streaming platform that allows for ephemeral applications that can be controlled, to a large degree, on the server. This is incredibly powerful, and we shouldn’t lose sight of this massive benefit.

However, a trade off like this doesn’t come with zero cost, and we should look at how to balance any cost. We have been doing some of this with stronger caching primitives, service workers, etc. That’s great, but until we can contort the law’s of physics, it will be true that shipping capabilities comes with a large cost. In an ideal world, a website that delivers a shopping experience for users will only send down capabilities tied strongly to said experience. It is less than ideal to also send down large infrastructure (affecting both load and runtime).

When we standardize and put something into the Web platform itself, we get the benefit of a shared core that user space can progressively rely on, and we are able to use a couple more tools as we do so. The platform in the browser has access to the native platform below it, in a way that you just don’t have working on top of the standard Web.

We see the benefits time and time again. With recent Observers, we can get away from the jank-ridden experiences that we have all felt from being on websites that take over scrolling and try to be too clever.

One of the largest undergrounding projects of late has been taking the great ideas in jQuery and bringing them to the platform via querySelector(s), fetch, classList and more. jQuery itself learned from the likes of Prototype, MooTools, Dojo, and others, and offered a slightly different approach. As we in turn learn from this corpus, it is important to realize that we didn’t just “take jQuery and bake it in”. We are often asked to do this, and it’s alluring. I instigated the Google Ajax CDN project back in the day, to answer “can we just cache things so we aren’t downloading the same darn APIs all day long?”

Caching is good, but it isn’t enough. There are tactical issues (how developers bundle, versioning) but there is also the fact that you need to do things differently when you bake something in.

Looking at cabling in my neighborhood again, when a city does this, they don’t just take the same cables and dig a quick hole to shove them in. Once those cables are underground you have new constraints. It’s hard to get to them when something goes wrong, so you want to protect them in a more rigorous manner. The same is true when you standardize something in the Web, as once it’s there you will be maintaining it for ~forever. You can learn, add the new constraints, as well as the new capabilities that the core platform gives you…. and the outcome should be *better* than before.

Ok, so what should we underground?

The details matter. What are the areas that are ripe for undergrounding in 2018? Let’s take a look at the landscape. Capabilities are unbundling across a diverse set of form factors, with new modalities and we are moving past the world of:

  • mobile == certain size screen, touch, camera, and location
  • desktop == keyboard, mouse, another size screen.

If you heard about the recent “Made By Google” event, you would have seen how these things are blurring (touch on laptops, voice and screens together, etc) and we haven’t even gotten to the world of mixed reality and friends.

What are the “jQuery of today” fashions around us? The world of React and Vue add to Web Components to show a world of strong componentization. We can also see other point solutions that many of us are using, e.g. fonts (google fonts and typekit), analytics (google analytics and friends), and adtech (has a huge impact on performance).

There is a lot of fertile ground, and I have been reflecting on:

UI Components


We have a series of components baked into the Web, but as we opened up the ability to create your own with custom elements, we slowed down any that just come with the platform. We started with a myriad of document related tags (including many that we rarely use…. <aside> etc). Then we had form controls, and shoved a universe into type=”mwhaha” on input. I think it would be worth spending more time on the UX of these form controls. It often feels like we get a lowest common denominator out there (which maybe works when we wire it to the native platform) and the user has to do something custom, from scratch, if they want it to differ in any real way. Now, I am looking at type=date, and the type=number where I picture users seeing tiny up and down arrows. We should allow developers the ability to style form controls easier, which would also help a lot with accessibility. This isn’t easy to change, for sure, and the edges are rough.

Left shows the old version, right shows Chrome 64 (thanks Henry!)

In other areas, we did keep iterating. For example, the first image picker on Android had an incredibly weak UI, with a simple file picker, compared to native apps that would show you recent photos that you quickly tap on to be done.

Then we had the need for application UI controls, going beyond documents and forms. How often have I heard:

“Just give me a UITableView that works!!!!!!

Often.

And you can say the same for many other common components. Surely, a developer can hunt around and maybe find a Web Component, or a component tied to a framework, but for many of these the platform could do more heavy lifting AND not require the download and runtime costs.

NOTE: Giving everyone the ability to build components in the platform is a huge win in my book. I am excited that I can build a leaf component that I know will be reusable for a long time to come, no matter which set of libraries of framework I am using in the future. In larger companies, you almost always see multiple frameworks in use (*takes a peak in google3…. oh my!*), so why not at least have the capability to share. This doesn’t mean that you leave your framework of choice behind, far from it. You will see some great examples at the upcoming Chrome DevSummit that marry custom elements with frameworks!

App Architecture

It’s not just about visual components. There are common app architecture patterns that we drag around with us. I would love the platform to offer me a rich state machine with a reactive data flow. For the devices that we run on, and for the multi-modal world, we need to think about how to offload work from the main UI thread. The browser continues to do more and more of this (e.g. compilation of JS, image decoding) but we also need to do more for developers to give us units of work that we can decide where to run. We are seeing good work here via APIs such as Workers (Comlink, WorkerDOM), and Worklets:

I start to get really excited about this world. If we put it all together, we can get a Web that finally has truly reliable jank free fluid UIs, with fantastic components, and needed architecture pieces, allowing the frameworks to up level and work on the next key areas of exploration.

The Web is all about collaboration. I am enjoying working with the community and especially the framework world. But what about yourself? What would you like to see?

I am enjoying Paul Lewis and Surma chatting about some of the possibilities, and how to keep a clean main thread, so you may too:

Mission: Improve the Web Ecosystem for Developers

Leave a Comment

Once the dust settled on Google I/O 2018, it was time for me to find a new adventure. I wanted to share where I ended up because I am quite excited about it!

A few teams within Google have joined forces inside Chrome to focus on improving the Web ecosystem, focused on those who build experiences, and create on the Web. I am incredibly excited to be working side by side with Ben once again, and take on a new mission:

“We want to make high quality experiences easy to build as that will enable more meaningful engagement on the Web for users and developers alike.”

What is meaningful engagement?

We have to be careful what we measure. If we only cared about the amount of time that was spent on the Web, it would be tempting to do things that addict and actually cause harm….. just to get a number further up and to the right. We have all experienced sites and apps that seem to do just that, and it goes against our goals for humanity. Google wants to “organize the world’s information and make it universally accessible and useful.” Useful, not wasteful. We want to be a force for good.

Some of the core attributes that show the nuance of what we really want are:

  • We are not striving to get humans to spend more time on devices. This is a strong non-goal, and we care about digital wellbeing.
  • When someone spends time on a device, we would love their time on the Web to be with a great experience.
  • When someone wants to get a task done, we would love to streamline the effort which will result in less time spent on that activity, which is great!
  • We aren’t here to judge the type of activity. E.g. entertainment is meaningful for our users.
  • High performing experiences enable engagement because: Poor performing experiences result in abandonment, frustration, and platform switches; Each good experience results in myelination for reengagement
  • We want all users (reach) to be able to engage with the best possible experience (capabilities) for them.

There is a ton of nuance, and it is fun to spend time as a team thinking about what we want the world to look like, and drive for that reality.

How is the ecosystem doing?


While we have a fantastic, creative, community, it is clear that the Web that you experience daily does not map to the current capabilities of the Web. We are looking to work together to make changes that help close the gap, as when we see great modern experiencecs ship they see huge upside.

tl;dr Pinterest’s example here is the prototype turn around situation. Once a team focused on making their experience great it “became the top platform for new signups and in less than 6 months already have 800 thousand weekly users using our PWA like a native app from their homescreen”).

The future is already here — it’s just not very evenly distributed

One of the core issues at hand is shortening the time from “idea that makes the Web better” to “developers can use this idea and it is better for users”. There are a huge number of steps in between, and we need to shorten each of them. For example:

WEB PLATFORM LAYER

Web standards: Alex Russell recently posted two articles on the world of standards and lessons for becoming more effective. WICG and friends have both brought more web dev practitioners into the fold, and also streamlined the work. Getting consensus takes time, as it kinda should when adding something to the Web platform at this stage of its evolution, but that community is getting better at it over time.

Web compatibility: it is one thing to have a standard, it is another to have compatible implementations for developers. The Web Platform Tests effort has been huge here, and we see continued convergence across the browsers, which results in predictability for developers and users.

Web runtime: it is one thing to have implementations, it is another to have them be the implementations that are used. Chrome started the charge with rolling 6 week release cycles, and pushing continuous updates to users so they are running on the latest and greatest Web. Other browsers have also gotten better here. Being able to update here is critical. Time and time again we have seen situations where users are left on a device that isn’t getting updates and they are left in the past.

WEB APPLICATION LAYER

We see many pieces at play at the Web application layer:

Polyfills: One way to keep working towards the future is to be able to code to it’s interfaces even if all browsers in the wild aren’t there yet. This is where polyfills come in, as without them you either leave users out in the cold, or you are stuck back in time yourself. Getting your loading strategy working up front is important here. We still see, time and time again, web applications service polyfills to browsers that support the features natively. This eats up precious network and CPU, for no reason. It is important that a plan is in place for progressive enhancement that allows you to reach everyone, but deliver the best possible experience when capabilities match.

Frameworks: How do you keep up to date with the versions of frameworks? It can be tedious to keep upgrading, especially with large API changes. What is your strategy for keeping up to date here? For many, the “frameworks” are CMSes such as WordPress and Drupal. It was a huge win for the Web when WordPress supported updates inside of the admin panel. If you have a CMS that requires you to download zip files and do manual work to update…. you are probably spending more time in an unsecure past.

Libraries: We all know how those npm installs can blow up our dependency tree of libraries, so it is important to keep a watchful eye on these and once again have a plan for staying up to date. The nature of this work is tricky, and it is easy to be working with older versions of libraries based on transitive dependencies.

Your App Code: Oh right, you have to write the app itself! Hopefully you have A/B/release infrastructure in place that allows you to roll out the future to some users so you can see if that future is bright or not. With service workers, you have even more control of your application code, but that control means you need to make sure you have bulletproof infrastructure in place so you don’t lose users in the past as they get stuck in a historic cache.

CLOUD / OS LAYER

I remember the days where you had to keep your kernel up to date with the latest in security and performance patches. Fortunately, for many of us, those days are somewhat behind us, which is going to be important for future proofing.

The infrastructure that I would love to see in place, would allow for changes such as a new image format is introduced that is waaaaay smaller and faster:

  • Some browsers implement support and users get the capability in their hands
  • A WASM implementation is made available for browsers that don’t have native support
  • The browser and server are smart enough to negotiate and serve the new format in an optimal way.

Ditto for new networking solutions (as we rolled out QUIC et al). One of the fantastic things about AMP is how this world is available. A developer only needs to create AMP documents, and the rest is taken care of for you. And, with the AMP team constantly improving the runtime and the components, the same AMP page can keep getting better without you lifting a finger. With Web Packaging and the like, it would be great to do more of this outside of AMP.

One of the key notions of the progressive web, is that we are continuously improving. It is one thing to get the processes and platform chain of improvement working, and it is another to …

Make high quality experiences easy to build

You will notice “high quality” and “easy” are both in the sentence above.

Paul Calvano’s great piece on page weight

HIGH QUALITY

We harp on performance a lot, and the cost of JavaScript in particular, these days. We have taken a medium that was designed for streaming content and fast progressive loading and chopped it at the knees. Web development should offer you a pit of success but instead many stacks deliver a poor experience by default. If we could come together to fix one thing, it would be this.

It is one thing to run Lighthouse on an old legacy site and see a low score. You sigh, and know that you need to slog through a slew of work to bring it back to snuff. However, it is another thing to build a brand new app and run Lighthouse on it and …. also see a really poor score. The future we need starts you off high, and keeps nudging you to stay there. It has constraints and a mental model that allows you to scale your application. If you keep adding functionality, the first time to load can’t keep getting longer. At runtime, we can’t end up with a DOM with a million nodes, where the browser can’t keep up on layout, even if you are actually just making changes in one “view”.

Quality isn’t solely about performance though. We all want a Web that is also: capable, reliable, delightful, discoverable, and accessible.

I often think about this when I am on a website that offers the opposite. I had two such experiences in the last couple days:

Commerce experience: I was asked to purchase a gift card from a well known retailer. I first tried to grab one quick on a mobile device. The UI kept jumping around and the form controls actively stopped me from doing correct selections. I then jumped to the desktop version, and it was equally bad, giving me bizarre error messages that made no sense (and were different to those that surfaced on mobile). I then turned to the mobile application to make the purchase and pictured the data folks looking at these types of experiences and thinking “ah, so users of the app have better conversion!” No!

Push the app experience: I was looking to answer a question and ended up on a website that did everything possible to get me to download the app. There are plenty of reasons that I may want an app on my phone, but the “frustrate the user to do so” drives me insane. I buggered off to the next search result to get what I needed. I also picture data folks there looking at engagement and doing comparisons that don’t take into account that they are measuring different user segments. I have run into this time and time again, where the app users are those who waded through everything to get the app and are thus the loyal customers who put up with it. However, how about also opening the funnel to convert “not loyal yet” customers to the next level over time.

EASY

It’s too hard to build a great web experience. I made my own case here when you read through the infrastructure that you need to setup to build an engine that delivers up to date experiences. We have a paradox of choice, and it is easy to second guess yourself all day long (React or Vue? Web Components? Redux or MobX? Webpack or Parcel? etc etc etc).

Once you have made your choices, you have to make sure that they deliver a flow that is productive, and also delivers solid experiences (the PWA starter kit is an example of putting together the pieces that will keep you in the lane). The Web has plenty of footguns, so your experience can quickly become janky. To help us keep on the path we are improving the platform and also setting up Feature Policies that aim to guide. If you are able to policy up, the browser can optimize and users will benefit.

With all this being said, it is easy to miss out on the fact that the Web is still the best way to build experiences that reach users across form factors, and it has key principles that can’t be beat. Being able to fully control deployment on one end, and be able to make live changes in development on the other, is an amazing combination. If we can push through and have a nice native setup that allows for the best of these worlds without making developers live in config hell, we will be in a great place, and with recent changes we are able to get there.

We need a power assistant to help make this all happen. We have so many of the pieces already:

  • Lighthouse as a way to continuously understand how your development, staging, and production are looking in the lab
  • Chrome User Experience Report, Page Speed Insights, and friends to get you data from the field
  • Chrome DevTools is there to help you inspect, develop, and debug your applications
  • There are a few great editors, that are able to tie into the ecosystem
  • Community efforts to guide you down the path.

But we need more. We need to give developers better guidance and help them along. We need the tools to give more insights and give you greater help. You should be able to do more development and design work in DevTools. We need to help frameworks and ecosystems such as CMSes (e.g. WordPress PWA) and Commerce deliver great experiences to a huge part of the Web.

Guess what? We are hiring. If you would like to help us take everything to the next level and light the way to the pit of success, please let me know! We have positions across Product Management, Engineering, DevRel, and more. If you want to help the ecosystem and platform, we are all ears. Please join me on the new journey, one that will help the developers of today, and help us get to the future of a Web across new modes and form factors.

Google: The Iron Man we strive to be

Leave a Comment


In a recent meeting we were playing with the question:

“If Google was a super hero, what would we be?”

The first thing that came to mind was Iron Man. You know, the innovative engineer who uses his technical ability to become super human.

In the developer group our mission is to make sure that Tony Stark uses his power for good. In our case, we want to give away the suits to democratize AI, computing, and more. We take this mission seriously.

Why do we need to innovate and also help developers? Let’s turn back to Tony again. His origin story included the need to create a source that can power an electromagnet keeping shrapnel from reaching his heart. Innovation due to necessity.

Google is a platform company, and one that thrives with open ecosystems. It is imperative that we do all we can to help the survival of open systems over closed ones. This is why we care so much about an open Web, Android, TensorFlow, and open cloud computing.

We also know that we are still young. Google is turning 19 a pivotal time for anyone. Can we keep our youthful optimism whilst gaining maturity?

Brother Chrome, Brother Android

I am currently in Krakow for the large European Google Developer Days (a beautiful city!) and a developer came up to me to ask how I felt about “Chrome vs. Android”. Someone else leaned in to ask if I was frustrated with the fact that we “have so many platforms.” I get it. We have multiple platforms, and they are sometimes a lil more messy due to their openness.

On the flip side though, I wouldn’t have it another way. Where some may see “Chrome vs. Android” I see “Chrome and Android”. Not only does Android literally give us a vehicle for us to build a world class mobile Web browser that can push on rich integration, but the reach that we have with both is amazing:

  • With Android we have a world mobile OS that is on billions of devices all over he world
  • With Chrome, and even more broadly — the Web, we extend the reach to non-Android devices.

That sounds like a killer duo to me. Ben and I actually just gave a short talk about the “brothers” of mobile native and the Web, and they journey as siblings growing up together.

I look forward to a bright future for all.

The right thing to do, is the right thing to do.