• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Tech Ecosystems

Mission: Improve the Web Ecosystem for Developers

July 22, 2018 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.

Ruby isn’t the only gem

May 27, 2016 Leave a Comment

… and that’s OK.

Ruby's on the rise in the TIOBE index again. Rumors of its death have been greatly exaggerated: https://t.co/tOk9HW7ayF

— Charles Nutter (@headius) May 27, 2016

I overheard someone talking about how Ruby has “failed to have the impact that it could have had”. I leaned in further when I heard that, and he continued to talk about how Ruby was set to jump and and be The Next Java, mainly thanks to Rails.

I think that Ruby and Rails have had a massive impact if you widen the lens of what “impact” means. If you look at its impact by connecting it to the number of lines of code of ruby out there (which would be ironic in the case of ruby), or the number of developers using it, then I can see how you come to the wrong conclusion.

I prefer to look at the impact across the computing landscape.

My brain has always connected to Ruby in a way that it never did with Java. It feels right-er to me, and I enjoy programming with it so much more. Rails came along and filled a need to develop CRUD based web apps in an opinionated way that was a breath of fresh air to many PHPers and Java practitioners alike. It did that thing well.

Ruby was particularly well suited to this opinionated approach, but the concepts behind Rails were adaptable to many other systems and programming languages, and we saw that. PHP developers looked to take some of the ideas via frameworks such as Symfony and Zend Framework. The same could be said for many other languages that people were using for the Web. Rails, and Ruby, has helped the evolution of all web frameworks from there…. even if they made very different choices, they thought about those choices differently due to Rails.

Ecosystems, not Languages

Right as Rails was getting bigger there was a shift in the force with mobile, and it turns out that ecosystems have a huge say in which languages are used.

JavaScript is as large of a player as it is due to the browser, and the fact that JavaScript is the only *first class* programming language allowed, and the Web platform APIs are designed with that in mind.

Objective-C developers had the shock of their lives when they went from “crap how do we make money?” to the clouds raining it down thanks to iOS. The language that Android was optimized for kept that world strong, working with Java on the backend.

Our backend needs also changed a lot again. We weren’t mainly interested in shooting out HTML, but instead we were focused on APIs and the push to microservices and network servers enabled much more freedom to choose solutions such as go and node.

Ruby didn’t come along and own the market. The VC’s that wanted to find Ruby or Rails Inc didn’t get exactly what they wanted, but please don’t underestimate the role that Ruby and Rails have, and will continue to play.

It may not be the only gem on the planet, but I like diversity and it would be a sad state of affairs if it was.

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • I have scissors all over my house
  • GenAI: Lessons working with LLMs
  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

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

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

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...